[Date Index] [Thread Index] [Author Index]

Re: Is there a simple way to transform 1.1 to 11/10?

• To: mathgroup at smc.vnet.net
• Subject: [mg92987] Re: Is there a simple way to transform 1.1 to 11/10?
• From: "Szabolcs HorvÃt" <szhorvat at gmail.com>
• Date: Wed, 22 Oct 2008 05:37:44 -0400 (EDT)
• References: <gdkajv$4r2$1@smc.vnet.net> <48FDBF08.5040207@gmail.com>

On Tue, Oct 21, 2008 at 16:52, Alain Cochard
<alain at geophysik.uni-muenchen.de> wrote:
> Szabolcs Horvát writes:
>  > On Tue, Oct 21, 2008 at 14:49, Alain Cochard
>  > <alain at geophysik.uni-muenchen.de> wrote:
>  > > Szabolcs Horvat writes:
>  > >  > Alain Cochard wrote:
>  > >  > > The obvious
>  > >  > >
>  > >  > >     In[1]:= x=1.1`Infinity
>  > >  > >
>  > >  > > is not syntactically correct.
>  > >  > >
>  > >  > > I understand that SetPrecision[1.1,Infinity] does not work either:
>  > >  > >
>  > >  > >     In[3]:= SetPrecision[1.1,Infinity]
>  > >  > >
>  > >  > >             2476979795053773
>  > >  > >     Out[3]= ----------------
>  > >  > >             2251799813685248
>  > >  > >
>  > >  > >     In[4]:= N[%,20]
>  > >  > >
>  > >  > >     Out[4]= 1.1000000000000000888
>  > >  > >
>  > >  > > I searched the newsgroup and thought I had the solution with Rationalize:
>  > >  > >
>  > >  > >     In[5]:= Rationalize[1.1,0]
>  > >  > >
>  > >  > >             11
>  > >  > >     Out[5]= --
>  > >  > >             10
>  > >  > >
>  > >  > > But
>  > >  > >
>  > >  > >     In[9]:= Rationalize[1.000000001,0]
>  > >  > >
>  > >  > >             999999918
>  > >  > >     Out[9]= ---------
>  > >  > >             999999917
>  > >  > >
>  > >  > >     In[10]:= N[%,20]
>  > >  > >
>  > >  > >     Out[10]= 1.0000000010000000830
>  > >  > >
>  > >  > > So any simple way?
>  > >  > >
>  > >  >
>  > >  > Hello Alain,
>  > >  >
>  > >  > Rationalize is the way to go.  Floating point numbers are usually stored
>  > >  > in a binary (not decimal) representation on computers.  1.000000001 is
>  > >  > not exactly representable in binary (in the same way as 1/3 =
>  > >  > 0.3333333... is not exactly representable in decimal).  Note that in
>  > >  > your example you start with a MachinePrecision number (approximately 15
>  > >  > digits), and then convert back to a number with 20 digits of precision.
>  > >  >   If you start with 1.000000001`20 then everything will be fine.
>  > >  >
>  > >  > In[1]:= Rationalize[1.000000001`20, 0]
>  > >  > Out[1]= 1000000001/1000000000
>  > >  >
>  > >  > In[2]:= N[%, 20]
>  > >  > Out[2]= 1.0000000010000000000
>  > >  >
>  > >  > Another example:
>  > >  >
>  > >  > In[1]:= Rationalize[N[Sqrt[2], 30], 0]
>  > >  > Out[1]= 1023286908188737/723573111879672
>  > >  >
>  > >  > In[2]:= N[%, 30]
>  > >  > Out[2]= 1.41421356237309504880168872421
>  > >  >
>  > >  > In[3]:= % - Sqrt[2]
>  > >  > Out[3]= 0.*10^-30
>  > >
>  > > I don't really convert back to a number with 20 digits of precision.
>  >
>  > You used N[%,20] in your example where % was the rationalization of a
>  > MachinePrecision number.  If you convert it back to a MachinePrecision
>  > number (simply N[%]), then you'll get the same number that you started
>  > with, and not a different one.
>  >
>  > > It was just to convince myself that it was not 1000000001/1000000000
>  >
>  > Actually 1.000000001 isn't 1000000001/1000000000 either ... see below.
>  >
>  > > The solution you give will not be fully general (as that by bob) since
>  > > you have to adapt the '20' or the '30' for each case.  This is a bit
>  > > painful for a given number and impossible to do in a program, it seems
>  > > to me.
>  > >
>  >
>  > No, you misunderstood me.  I did not offer a solution.  I just tried
>  > to explain why the result returned by Rationalize[1.000000001,0] is
>  > correct, and why the "problem" does not exist at all.
>
> Sorry that I misundertood you.  Also, I wasn't implying the mma does
> not give the correct result.
>
> There is a problem for me because when I play with mathematical
> numbers like 1.608910743981704391 with an infinite number of zeroes
> afterwards, it is painful to manually count the figures and write it
> as 1608910743981704391/1000000000000000000
>
>  > You asked how you can transform 1.1 to 11/10.  This is not a
>  > precisely defined question.  Why do you prefer 11/10?  Why not
>  > 1100000000000000088/1000000000000000000, for example?
>
> Because I'd say that for pure mathematics, 11/10 is closer to 1.1 than
> 1100000000000000088/1000000000000000000 is...

But in Mathematica (and practically any other computer program) it is
really closer to 1100000000000000088/1000000000000000000.  As I said,
it is represented in binary internally.  And this particular number
does not have an exact binary representation, just as 1/3 or 1/7 does
not have an exact representation in decimal.  So when you write 1.1,
and use the default machine precision, the computer really understands
1.0001100110011001100110011001100110011001100110011010,
which in decimal is exactly
1.100000000000000088817841970012523233890533447265625.

If you increase the precision to 20, and type 1.1`20, you'll get a
more precise (but still not exact) binary representation of 1.1:

1.000110011001100110011001100110011001100110011001100110011001100111

The corresponding decimal is not 1.1, but

1.100000000000000000008131516293641283255055896006524562835693359375.

>
>  >
>  > [...]
>  >
>  > What I meant was that you have to decide what precision to use.  [...]
>
> I want infinite precision, juste like when you enter 1, Pi, or 11/10.
>

If you want infinite precision, then you have to use integers,
rational, or symbols like Pi.  As I already said, floating point
numbers are always treated as inexact numbers, and their precision is
tracked by the system.