Nor can you represent every number with powers of 10: 10 is a totally arbitrary base.

Your posts still strongly suggest that you don't really know what you want because you don't seem to be able to grasp what is going on.

If you want your calculator to round to decimal values, then round to decimal values. Most calculators already do this: if you enter 1/3, then multiply the answer by 3, you will get 1 again, despite the fact that 1/3 can be expressed in neither decimal nor binary.

I still don't see strong enough grounds for using a decimal base for what you are doing. In fact any hand calculator could quite easily be running on base 2 and you'd never even know.

The only real grounds for a decimal base is working financial purposes. It is certainly not appropriate for your purposes, and if you intend to do any sort of numerical integration or any real number crunching for that matter, you will be slowing down your application 10-50 fold by using a decimal base.

Utter nonsense.
When using any kind of tool, whether software or not, you have to understand its limitations. One of the limitations of computers is that floating point arithmetic has finite accuracy. There is ultimately no way around it and it's a bad idea to try to fake it in specific circumstances. It'll break down in other points.
Now, it may be appropriate to define operations on rational numbers (which is just a pair of integers), of which a decimal representation is just a subset. If that's what you want, then that's what you should implement (which is not difficult and is somewhat fun to do; it's not generally useful though).

As James Lohr said, you're simply not understanding what you see in calculators. Some of them are in base 2, some are in decimal, and you generally don't notice the difference. Different ones use different precision, but they generally display accurate integer answers to operations with divisors that don't fit in to their base evenly by the simple trick of displaying fewer digits than they calculate internally. If you divide 1 by 3 and then multiply it by 3 it displays the result as 1.0 not because it internally calculates the result as 1.0 (most calculators don't) but because it displays fewer digits then it tracks internally. Which is sort of like the opposite of the property you asked for - the destringification of the stringification is not equal to the original number, and that loss of precision is what gives them the property you like.

Arthur Kalliokoski: I wouldn't recommend actually using the BCD opcodes. It's comparable in efficiency to emulate that using normal integers (the BCD opcodes are slow on many x86s), and compiler support / etc is much better for non-BCD stuff.

The Introduction to LIDIA seems to indicate that it is highly specialized in things I don't have a use for, and it makes no mention of trig / power / logarithm / other standard C/C++ functions. Thanks anyway.

I don't see why strtod would give different results than sscanf would. As written, calling the program with 5.1/0.1 as the argument produces 51 as the answer. The problem is, I can't rely on %lg to correctly round the number in all cases. If I change it to use %.30lg I get 50.999999999999993 as the answer. What if the answer actually was 50.999999999999993 and I used %lg and got 51 as the output instead?

I just can't rely on doubles to do what I want them to do.

How does your library compare to MAPM?

You can represent more with powers of 10 than you can with powers of 1/2. If doubles used positive powers of 2 and tracked the decimal point and exponent, we wouldn't be having this discussion.

Figure it out dude, I want an exact representation (as much as possible) when converting from string to data and back. I've said this several times. Perhaps you have poor reading comprehension, I don't know. I know what is going on, I already stated that powers of 1/2 are insufficient for my needs for data representation. Since you're so smart, why don't you enlighten me and tell me 'what is going on'.

The problem is, how much precision should I choose to lose? If I decide to round everything to 10ths then I lose a lot of precision in my operations and the user may want to specify precision in the 1000ths. The MAPM library specifically allows me to choose how many significant digits their numbers should use, which makes it a lot easier for me.

The base itself doesn't bother me, what bothers me is using negative powers of that base to represent a number, which is stupid because it usually can't be done precisely (but negative powers of base 10 are more precise than negative powers of base 2).

Well, actually I'm not, but thanks for the support.

No, what is nonsense is to return an inexact number for a mathematical operation that should have an exact value. It's the implementation of floating point arithmetic that sucks here, as you can represent any rational number with any positive base using positive powers if you track the decimal point and exponent as well. You shouldn't have to round the result of 5.1/0.1 to get the exact answer that obviously exists already. eg...

5.1 e0 = 51 e-1
/         / 
0.1 e0 =  1 e-1
----------------
         51 e0

When you represent the number in positive powers of any positive base greater than 1, there is no precision lost, ever (not accounting for irrational numbers here).

But the problem is deciding how many digits to round the answer to. 2? 10? When you have an exact answer, you don't need to round anything.

I think you meant that the other way round, but I don't want 0.1 represented as 0.099999999whatever, that's just not acceptable.

In any case, I'm leaning more and more towards using the MAPM library - it has a really nice C++ class called MAPM that wraps all the C code into nice operators and you can set a global precision level for all the operations. I'll have to give it a test run here over the next few days and report back. And its example calculator program knows what 5.1/0.1 is.

Both the Windows calculator and my CASIO fx-115ES give the answer of zero.

It's a CASIO, but it's rather complex. I just opened it up after it sitting there for a year or so. It looks like it can do simple equations, do calculations on regular and complex numbers, handle matrices and vectors and some other stuff. I used to have a really nice TI-80 something graphical calculator back in high school. That thing was great til it crapped out.

facepalm

<<<

I'm not really sure what you mean by powers of 10 vs. powers of 2... In any case, the inaccuracy of number storage basically come down to finite storage. Infinite numbers cannot be stored in finite space and very long numbers cannot feasibly be processed either. Your basic options are floating-point numbers, which can represent a larger range of numbers with less precision, and fixed-point numbers, which can represent a smaller range of numbers with greater precision (and perhaps slower, since there are no fixed-point processing units in CPUs that I'm aware of). According to Wikipedia, fixed-point data types are split into two categories: binary (base 2) and decimal (base 10). The binary ones can benefit from bitwise operations to increase performance, but suffer from worse accuracy as a result. The decimal ones would therefore be slower, but more accurate. It all depends on exactly what you're using the numbers for.

>>>Prepend

I think what you basically want is a fixed-point data type. Apparently GCC partially supports a draft for one in C.^[1] Of course, I don't know if the appropriate facilities are implemented to serialize and deserialize it. If you have to convert to/from a floating-point number to serialize/deserialize then you'll lose the precision anyway. It certainly would be nice to have fixed-point data types in all programming language standard libraries. There are some applications (financial, in particular) that can benefit a lot from the accuracy, and in those applications speed is often less important than accuracy.

<<<Append

Personally, I find it annoying too to get incorrect results with floating-point numbers. Perhaps that is my obsessive/perfectionist nature. I never have really wrapped my head around how to handle floating-point numbers appropriately. Though since I predominantly write business applications the floating point numbers usually represent money, where accuracy usually does matter...

>>>

I can deal with that. What I can't deal with is not being able to represent powers of 10 exactly, since that is what the decimal system is based on.

You're contradicting yourself. First you say they're equally valid and then you admit that powers of 10 can represent more numbers than powers of 2. Are powers of 10 a better representation of numbers than powers of 2 or not? Well, yes they are.

What is imprecise about 5.1? It is exactly 51 10ths. The fact that a double can't represent 51 10ths is what bothers me. I get it just fine, thanks.

If they were represented as sums of any base greater than 1 with powers greater than or equal to 0 with a decimal point and exponent tracked separately, then any rational number could be represented exactly by them. The entire problem stems from the fact that negative powers are used to represent numbers less than one.

Yes you can represent it in binary if you use positive powers of two and track the decimal point and exponent.

"5.1" = 0x33 decimal2 e-1

Floating point numbers are broken if they can't represent a decimal string exactly. I've said numerous times that I expect a string to be represented exactly in data format and to get the same string out when converting back. Why do I have to keep saying this?

Edit for your edit

Not true.

x != x + n (for n != 0)

I understand I can't exactly represent irrational numbers. I'm not trying to either.

I love nerd fights.

Perhaps they are broken for your particular application, but they make good sense in terms of speed and functionality trade off.

If all it takes is a little extra space to get accurate results, I'm fine with that.

Negative powers of 2 do not have more precision than negative powers of 10, otherwise they could represent more numbers than negative powers of 10 could, which they can't. Any real number that is rational can be represented in base 10. The same can't be said for base 2 unless you use positive powers to represent the number and track the exponent.

It makes perfect sense, given that my intended application is accurate calculation of expresssions where possible.

In any case, you've babbled on enough about how I don't really know what I want, about how I can't grasp what is going on, blah blah blah. If you don't have any suggestions about how to achieve what I have plainly asked for numerous times, then stop posting in this thread already.

I think that the statement that put everybody off-track was move from string to double and back.
I'm pretty sure it was not intended with infinite number of decimal places that can be obtained during a computation (ex: 1/3), but rather for the numbers that are input by humans.
The answer is a decimal floating-point or a decimal fixed-point number representation, as already proposed : Not because it would be more exact than a base-2 system, but because the rounding rules are on the same digits that a human would apply, and thus they appear more 'natural'.

Everybody asked "what's it for" because the choice between the two (fixed or floating) depends on what kind of actual numbers you'll handle... if they are "distance in meters", it still depends if you measure the distance between electrons or between galaxies (or a mix of the two).

As has already been pointed out in this thread, there are rational real numbers that cannot be represented in base-10 with non-repeating digits (1/3rd was previously mentioned, but any simple integer fraction with a divisor that has any prime factor other than 2 or 5 also qualifies).

Use of "positive powers to represent the number and track the exponent" (ie a decimal point and/or scientific notation aka floating point) is generally equally necessary or unnecessary for binary or decimal representations.
It is (sort of) true that a wider variety of numbers can be represented exactly without repeating digits in decimal than binary since 10 has more prime factors than 2, but that does not mean that base 10 is more precise, and if you desired that basic property then you would be better off using base 210 than base 10 (as 210 has a wider variety of prime factors than 10 or 2). Such base are neither more nor less precise because for any fixed amount of information the number of values that can precisely be represented is the same.

The only significant advantage to decimal on modern computers is that it is often less complicated to interface to other decimal systems (ie input or output to/from human-readable decimal sources, standard decimal precisions/rounding rules in financial codes, etc). There are numerous strategies for dealing with the binary-decimal interface issues, and they mostly work well.

Your discussion of the subject repeatedly appears to show a misunderstanding of the concepts involved, though it is hard to tell for sure how much is miscommunication vs misunderstanding.

The binary-vs-decimal issues are almost completely unrelated to fixed-vs-floating point issues, fixed-vs-variable-vs-infinite precision issues, etc.