The quotes are from the thread "The Case For Dozenal", but since they deal with a very different topic, I'll start a new thread:

Did you try the straightforward right-button -> copy/paste method? <_<

That dozenal calculator is indeed very unsatisfactory, but for other reasons such as the buggy algorithms (it often turns up results of the kind 1.23BBBBBBBBBBBB instead of 1.24), the lack of support for other bases, the absence of functions to compute square roots and powers (!), or the unavailability of versions for other operating systems (moreover, it cannot be run comfortably using Wine, a Windows compatibility layer for Linux, because there seems to be a problem with the fixed size of the window).

I gave you one already... :rolleyes: but you replied spitting out that "one can program any rediculous thing imaginable but i have no need or use for it" (a typical answer of yours). Anyway, it's closed-source and the full version is commercial software, so you have to pay to use it legally after the 31-day evaluation period, and can't modify or expand it.



That's why I've started to program a calculator with similar features to be released as open-source freeware (GPL-licensed). The first very incomplete version will be ready in some weeks (only the most basic functions and no nice graphical interface yet, merely text-mode). I also plan to eventually include several features not available in the AddUp calculator, such as:

i) expanded clock and calendar functions, including support for hexadecimal, dozenal and decimal time, and for calendars such as the Maya, Chinese, Jewish, Muslim, Iranian, French Revolutionary, Symmetry454 and Darian, as well as digital and pictorial displays for the current date and time

ii) several calculator display modes (including text, dot-matrix and 7/16-segment displays, as well as support for Arabic, Indian, Chinese, Pitman's dozenal, Maya vigesimal, and cuneiform sexagesimal digit sets, along with Roman, Greek and Hebrew numerals); a larger set of launchable keypads, the default one matching the selected input mode (so if dozenal input mode is selected, numbers entered from the keyboard will be understood as dozenal by default and a dozenal keypad similar to that of the DSGB dozenal calculator will be shown); also, extended localization features, such as menus and help available in several languages and number and date formats adaptable to the user's conventions

iii) adequate treatment of inaccurate data, such as:

--the possibility of specifying the margin of error, especially needed when dealing with measures (e.g., 7.58 ±0.01 cm), with appropriate arithmetic for such data

--the use of flags to indicate whether a number is entered or displayed as an exact quantity, or instead, as one that has been chopped or rounded; for example, multiplying 3.1416 (which means 31,416 ten-thousandths, not pi) times 2 will result in 6.2832 as an exact quantity, which means you may add as many zeros to the right as you like: 6.283200000000... (the result is as exact as the input data: 2 times 31,416 ten-thousandths is exactly 62,832 ten-thousandths, not a bit more and not a bit less); while multiplying pi times 2 in five-digit fixed-point decimal mode will result in something like 6.2831... indicating the result has been chopped (last digit is correct, but the representation of the number doesn't end there: we know it's greater than 6.2831 and less than 6.2832) or 6.2832~ indicating the result has been rounded (last digit is not correct, but the string represents the closest five-digit decimal approximation: we know the actual value is somewhere between 6.28315 and 6.28325)

--finally, discarding non-significant digits in calculations with inexact data; e.g., the result of 1.1... + 2.34~ would be 3.5~ instead of 3.44, because the first operand restricts the maximum precision of the result to only two significant digits, so it would be meaningless to say the third digit of the result is 4 when we don't know what the third digit of the first operand is (for a dozenal number, the actual value could be anywhere between 1.10000...01 and 1.1BBBBB...BB) and not even the third digit of the second operand is exact (it could actually be a 3 if it was rounded from 2.336); in any case, the result would be between 3.436 and 3.546, so a rounded average 3.5~ is as far as we can tell

q) support for factorized representation, continued-fraction notation, and basic support for arithmetic with irrationals (so that you may enter something like 2e * (((3^2 - sqrt(4) - 1) / 4e) + sqrt(8)) and the result be shown as 3+4sqrt(2)e, instead of as an inaccurate positional-number approximation)

qi) basic algebra (matrices will be an early first step, but later it will be possible to do things like solving a system of linear equations) and basic calculus (things like composing two functions and getting its value for a certain x, finding the extremes, curvature and such, or computing the definite integral for a given interval; graphing functions would also be very nice, but this would certainly belong only in a very advanced development stage, if at all)

qii) availability of multiple memory registers (referenceable in the input line; for example, let's say you've entered the value 2 into memory slot 1, and the value 3 into memory slot 2; you could then type something like 2 + (mem1 * mem2) and the result would be 8, which you might then enter into memory slot 3), as well as programmable functions (macros); maybe a processor emulator function could be added at a very later stage (something along the lines of SimuProc, so that you could enter data into binary memory registers and have it run an assembler program to manipulate them, either ready-made programs implementing the calculator functions or those entered manually by the user, allowing you to see how the computation is carried out internally step by step)

As you can see, it's an ambitious project in the long run (it will take years to implement all of the above), so if anyone here can program in C++ or Java, help would be welcome. My goal is to release a cross-platform Java version, and native versions in C++ for at least Windows, Linux and Mac (I don't have access to a Mac, so help is definitely needed for this).

As ambitious as your project is, it looks like you'd be better off finding an open-source computer algebra system and adding nondecimal I/O to it.

Btw, have you seen the baseconv utility I posted on here?

I don't think that would do. Would such a program already represent numbers internally as fractions and include a way for storing its degree of accuracy (rounded, chopped or range of inexactitude)? I doubt it, and if it doesn't support that, then that's radically different from what I have in mind. I'm not looking for a program that would do a calculation such as 1.34_doz + 2.56_hex by converting both operands to some base, adding them, and then converting the result to the output base, or anything along those lines. My idea is to store those values internally as fractions, since the values representable in any rational base are a subset of the rationals: 1.24_doz + 3.56_hex = 184/144 + 854/256 = 10630/2304 = 4.61371527777777..._dec; there's no finite decimal representation for the result, so if stored in decimal (or in binary) form, inaccuracy is stored as well because rounding would be unavoidable, and if further calculations are made with that inaccurate value, the inaccuracy would spread (and the user would probably remain unaware or unable to tell how much the inaccuracy has spread and grown, if the program has no way to deal with inaccurate numbers and flag them as such); while the fractional representation preserves the accurate result internally regardless of what base one is using for output display at that moment.

That's also why I plan to introduce some basic support for at least the most common irrationals, so that a value such as pi would not be stored internally as the decimal value 3.1416 or 3.1415926535897932384626433832795 or whatever other rational approximation, but as "pi" (an object of the class of irrationals with a method implementing the Bailey-Borwein-Plouffe algorithm for finding an approximation of its value in whatever base to whatever precision is required, as well static attributes storing its approximation to a large number of digits in the most common bases for quick conversion).

Besides, I'm also doing it for the fun of it, so taking an already existing program and adding a few rather trivial functionalities for I/O would spoil most of the fun. :P

That program is nice, ;) but it only covers one functionality of the calculator, and since it's in Python, I can't reuse any part of that code for my project.

Google for "rational arithmetic" and you'll find some code you can use.

This is a great project. I wish you good success. However, I prefer doing calculations on paper as much as possible (but I'm probably just crazy).
And I like your use of dozenal Roman numbers! :)