Re: was: All we have is integers.
- To: mathgroup at smc.vnet.net
- Subject: [mg117800] Re: was: All we have is integers.
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Thu, 31 Mar 2011 04:05:46 -0500 (EST)
Richard Fateman wrote: > [...] >> (DL) I agree with that. But one does not always work with integers. Or >> with "nice" decimals (defined howsoever you like, provided >> 1.2345678765998821 is not regarded as "nice"). > > "God invented the integers; all else is the work of man." (Kronecker) > > Consider that the decimal number 0.1 converted to IEEE double float is > > 7205759403792794 x 2^(-56). > > These are all integers. You can add zeros to that by simultaneously > doubling that first number, the one that starts with 72.. and > subtracting one from the exponent, the one that starts with -56. You > can write a Mathematica program to do this of course. Yes. But the number to which you extend by zeros is not 1/10, or 0.1, but rather an approximation thereof. > All the manipulations that you can do with floats can be done with > (pairs of) integers, along with a bit for the sign. > So in some sense all you are doing is working with integers, even when > you think you are doing floating adds, multiplies etc. > And Mathematica presumably does the moral equivalent of this for its > software floats. Yes, integers are always used behind the scenes (didn't I mentioned that we build bigfloat arithmetic on GMP integer arithmetic?). So yes, Mathematica is using integers to implement arbitrary precision floats. All that does not change my earlier point regarding decimal-to-binary issues. > The radix for input and output is a red herring, in my view. That > number 72057.... can be written in any radix whatsoever, and so can the > exponent. The base here is 2, but it could be 10, or 16 or 1024 ... > If you have a number, that's the number that you have. Not quite. See bottom. > If you want to > print it in decimal, rounded to 3 decimal places, then that is a > formatting operation and should not affect the number. True enough, but not really pertinent. Here is why. We were discussing fixed precision *arithmetic* (not printing). In that scenario, truncation (or rounding) *should* affect the number. If it does not, then you did not truncate. People use guard bits to improve on matters, but that is of course imperfect. > If you want to > print it in decimal and read it back in, then you will generally have a > nearby number, but not necessarily exactly the same number you started > with. (If you do this in a cycle, you can find a nearby number that > can be read in exactly, but that is another story. ) We both understand that 1/10 is not representable in binary. That is the salient matter, in that it is responsible for several of the issues I have raised. In this case, one has a number, but the machine has a different number. Daniel Lichtblau Wolfram Research