Xojo Conferences
XDCMay2019MiamiUSA

Re: Re: math error (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: re: listbox
Next thread: ANN: SQLtAlarm - Alarm monitor for SQLite Databases


Re: Re: math error   -   Peter K. Stys
  Re: Re: math error   -   Bob Delaney
  Re: Re: Re: math error   -   Peter K. Stys
  Re: Re: Re: math error   -   Bob Delaney
  Re: Re: Re: Re: math error   -   Peter K. Stys
  Re: math error   -   Michael Sharpe
   Math Error?   -   ac644 tcnet.org
    Re: Math Error?   -   Norman Palardy
     RE: Math Error?   -   Joseph
      RE: Math Error?   -   Joseph
    Re: Math Error?   -   Harrie Westphal
    Re: Math Error?   -   William Squires
    Re: Math Error?   -   Phil M
    Re: Math Error?   -   Norman Palardy
    Re: Math Error?   -   Phil M
    Re: Re: Math Error?   -   Peter K. Stys
    Re: Math Error?   -   Phil M
    Re: Re: Math Error?   -   Peter K. Stys
    Re: Math Error?   -   Norman Palardy
    Re: Re: Math Error?   -   Peter K. Stys
     RE: Re: Math Error?   -   Joseph
      68k Was: Re: Math Error?   -   William Squires
    Re: Re: Math Error?   -   Robert Delaney
   Re: Math Error?   -   ac644 tcnet.org
    Re: Math Error?   -   Jonathan Johnson
    Re: Math Error?   -   Norman Palardy
    Re: Math Error?   -   Craig A. Finseth
   Re: Math Error?   -   ac644 tcnet.org
    Re: Math Error?   -   Norman Palardy
  Re: math error   -   Michael Sharpe
  Math Error?   -   Art Peters
  Re: Re: math error   -   Peter K. Stys
  Re: Math Error?   -   Mathieu Langlois
  Re: Math Error?   -   Craig A. Finseth
  Re: Math Error?   -   Craig A. Finseth
  Re: math error   -   Phil M
  Re: math error   -   Charles Yeomans
  Re: Math Error?   -   Norman Palardy
   RE: Math Error?   -   Joseph
    Re: Math Error?   -   Norman Palardy

Re: Re: math error
Date: 02.08.06 22:50 (Wed, 2 Aug 2006 17:50:49 -0400)
From: Peter K. Stys
I've often wondered about trying Maple (any good?).

Anyway, here is a reply from Wolfram tech support, turns out I wasn't
using Mathematica correctly (a common occurrence with me, not a simple
app to use). Os other were correct, 0.036 is not base-2
representable, and this explains the integer round-down "error" first
reported in this thread.

=wDgDI believe Mathematica is working correctly.

As specified in help of RealDigits, RealDigits[x]normally returns a list of
digits whose length is equal to Precision[x].

Please use the correct precision.

RealDigits[0.036`100, 2, 100]

returns:

{{1, 0, 0, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0,
0,
1, 1, 0, 1, 0, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 1,
1,
1, 0, 1, 1, 0, 1, 1, 0, 0, 1, 0, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 0, 0,
1,
1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1,
1,
0, 0, 1}, -4}

On 7/28/06, Charles Yeomans <<email address removed>> wrote:
> Shouldn't you be using Maple?
>
> Charles Yeomans
>
> On Jul 28, 2006, at 3:12 PM, Peter K. Stys wrote:
>
> > Good point Michael. It is disconcerting that Mathematica reports 0's
> > when in fact the values are unknown. I guess you can't even trust the
> > king of math programs.
> >
> > Cheers,
> > Peter.
> >
> >
> > Tho looking at the result of RealDigits[0.036,2,100], I infer that
> > 0.036 is
> >
> > On 7/28/06, Michael Sharpe <<email address removed>> wrote:
> >> Peter,
> >>
> >> Mathematica is misleading you here. At least in recent versions (I'm
> >> using 5.2), the last 48 positions are not 0, but are Indeterminate,
> >> indicating that the precision you requested goes beyond the numerical
> >> precision in the floating point number .036. The only numbers capable
> >> of an exact finite binary representation are those whose fractional
> >> representation as m/n (ie, all common factors removed) have n as a
> >> power of 2. As 36/1000 reduces to 9/250, and 250 is not a power of 2.
> >> In your first example, where you compute N[72/1000*750,100], what you
> >> are observing is the ability of Mathematica to do exact arithmetic
> >> calculations, not using any internal representation as a floating
> >> point number, at least when the number you enter is not manifestly
> >> approximate.
> >>
> >> Michael
> >>
> >> > Subject: Re: Re: Math Error?
> >> > From: "Peter K. Stys" <<email address removed>>
> >> > Date: Fri, 28 Jul 2006 12:35:56 -0400
> >> >
> >> > On 7/28/06, Norman Palardy <<email address removed>>
> >> wrote:
> >> >>
> >> >> On Jul 28, 2006, at 8:53 AM, Peter K. Stys wrote:
> >> >>
> >> >>>
> >> >>> In[26]:= N[72/2000*750,100]
> >> >>>
> >> >>> Out[26]> >> >>>
> >> 27.00000000000000000000000000000000000000000000000000000000000000000
> >> >>> 00
> >> >>> 0000000000000000000000000000000
> >> >>>
> >> >>> In[27]:= N[72/2000*750]
> >> >>>
> >> >>> Out[27]= 27.
> >> >>>
> >> >>> Still suggests all these numbers and intermediate results are
> >> >>> representable exactly at machine precision.
> >> >>
> >> >> I'm quite certain that 72/2000 is not.
> >> >> Write it as the simple sum of powers of 2 and you find the
> >> problem.
> >> >> 72/2000 = 2^-2 + 2^-4 + 2^-5 + 2^-6 + 2^-11 + 2^-15 ..... and
> >> so on
> >> >> and you never get exactly the result you get from 72/2000.
> >> >> In the machine all you have is powers of 2
> >> >>
> >> >>
> >> >
> >> > Actually we're both right and wrong:
> >> >
> >> > In[55]:=RealDigits[0.036,2,100]
> >> >
> >> > Out[55]> >> >
> >> {{1,0,0,1,0,0,1,1,0,1,1,1,0,1,0,0,1,0,1,1,1,1,0,0,0,1,1,0,1,0,1,0,0,1
> >> ,
> >> > 1,1,1,
> >> >
> >> >
> >> 1,1,0,1,1,1,1,1,0,0,1,1,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
> >> ,
> >> > 0,
> >> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},-4}
> >> >
> >> > Shows that 0.036 can be represented exactly in binary, but
> >> requires 51
> >> > significant digits (if I counted correctly to the last 1). So
> >> with a
> >> > 64 bit double, it probably just missed the # of digits in the
> >> mantissa
> >> > to represent 0.036 exactly.
> >> > Nuf time wasted on this, just a curiosity.
> >> >
> >> > P.
> >>
> >> _______________________________________________
> >> Unsubscribe or switch delivery mode:
> >> <http://www.realsoftware.com/support/listmanager/>
> >>
> >> Search the archives of this list here:
> >> <http://support.realsoftware.com/listarchives/lists.html>
> >>
> >
> >
> > --
> > ----------------------------------------------------------------------
> > ---------
> > Peter K. Stys, MD
> > Professor of Medicine(Neurology), Senior Scientist
> > Ottawa Health Research Institute, Div. of Neuroscience
> > Ottawa Hospital / University of Ottawa
> > Ontario, CANADA
> > tel: (613)761-5444
> > fax: (613)761-5330
> > http://www.ohri.ca/profiles/stys.asp
> > ----------------------------------------------------------------------
> > ---------
> > _______________________________________________
> > Unsubscribe or switch delivery mode:
> > <http://www.realsoftware.com/support/listmanager/>
> >
> > Search the archives of this list here:
> > <http://support.realsoftware.com/listarchives/lists.html>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

Re: Re: math error
Date: 02.08.06 23:41 (Wed, 2 Aug 2006 17:41:21 -0500)
From: Bob Delaney
Peter,

Because the "-4" means times 2^(-4), your result represents .036
accurate to 104 places following the binary point.

Bob



>I've often wondered about trying Maple (any good?).
>
>Anyway, here is a reply from Wolfram tech support, turns out I wasn't
>using Mathematica correctly (a common occurrence with me, not a simple
>app to use). Os other were correct, 0.036 is not base-2
>representable, and this explains the integer round-down "error" first
>reported in this thread.
>
>=ODwD>I believe Mathematica is working correctly.
>
>As specified in help of RealDigits, RealDigits[x]normally returns a list of
>digits whose length is equal to Precision[x].
>
>Please use the correct precision.
>
>RealDigits[0.036`100, 2, 100]
>
>returns:
>
>{{1, 0, 0, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0,
>0,
> 1, 1, 0, 1, 0, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 1,
>1,
> 1, 0, 1, 1, 0, 1, 1, 0, 0, 1, 0, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 0, 0,
>1,
> 1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1,
>1,
> 0, 0, 1}, -4}
>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Re: Re: math error
Date: 03.08.06 00:07 (Wed, 2 Aug 2006 19:07:12 -0400)
From: Peter K. Stys
Yes, i understand, but the PRECISION (if I use the term correctly) is
100 places.

Cheers,
P.

On 8/2/06, Bob Delaney <<email address removed>> wrote:
> Peter,
>
> Because the "-4" means times 2^(-4), your result represents .036
> accurate to 104 places following the binary point.
>
> Bob
>
> >I've often wondered about trying Maple (any good?).
> >
> >Anyway, here is a reply from Wolfram tech support, turns out I wasn't
> >using Mathematica correctly (a common occurrence with me, not a simple
> >app to use). Os other were correct, 0.036 is not base-2
> >representable, and this explains the integer round-down "error" first
> >reported in this thread.
> >
> >=#DcD> >I believe Mathematica is working correctly.
> >
> >As specified in help of RealDigits, RealDigits[x]normally returns a list of
> >digits whose length is equal to Precision[x].
> >
> >Please use the correct precision.
> >
> >RealDigits[0.036`100, 2, 100]
> >
> >returns:
> >
> >{{1, 0, 0, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0,
> >0,
> > 1, 1, 0, 1, 0, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 1,
> >1,
> > 1, 0, 1, 1, 0, 1, 1, 0, 0, 1, 0, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 0, 0,
> >1,
> > 1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1,
> >1,
> > 0, 0, 1}, -4}
> >
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

Re: Re: Re: math error
Date: 03.08.06 00:22 (Wed, 2 Aug 2006 18:22:10 -0500)
From: Bob Delaney
Peter,

I agree, the precision is 100 places.

Looking at Mathematica's result again, it appears to be formally
incorrect. There is no binary point in front of the binary bits!
Shouldn't the "-4" be "-104"?

Or does "RealDigits[0.036`100, 2, 100]" imply that one first
multiplies .036 by 2^100. Then the answer is formally correct. That
would really be confusing!

Bob

>Yes, i understand, but the PRECISION (if I use the term correctly) is
>100 places.
>
>Cheers,
>P.
>
>On 8/2/06, Bob Delaney <<email address removed>> wrote:
>>Peter,
>>
>>Because the "-4" means times 2^(-4), your result represents .036
>>accurate to 104 places following the binary point.
>>
>>Bob
>>
>>>I've often wondered about trying Maple (any good?).
>>>
>>>Anyway, here is a reply from Wolfram tech support, turns out I wasn't
>>>using Mathematica correctly (a common occurrence with me, not a simple
>>>app to use). Os other were correct, 0.036 is not base-2
>>>representable, and this explains the integer round-down "error" first
>>>reported in this thread.
>>>
>>>=kDwD>>>I believe Mathematica is working correctly.
>>>
>>>As specified in help of RealDigits, RealDigits[x]normally returns a list of
>>>digits whose length is equal to Precision[x].
>>>
>>>Please use the correct precision.
>>>
>> >RealDigits[0.036`100, 2, 100]
>>>
>>>returns:
>>>
>>>{{1, 0, 0, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0,
>>>0,
>>> 1, 1, 0, 1, 0, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 1,
>>>1,
>>> 1, 0, 1, 1, 0, 1, 1, 0, 0, 1, 0, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 0, 0,
>>>1,
>>> 1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1,
>>>1,
>>> 0, 0, 1}, -4}
>>>
>>_______________________________________________
>>Unsubscribe or switch delivery mode:
>><http://www.realsoftware.com/support/listmanager/>
>>
>>Search the archives of this list here:
>><http://support.realsoftware.com/listarchives/lists.html>
>>
>--
>-------------------------------------------------------------------------------
>Peter K. Stys, MD
>Professor of Medicine(Neurology), Senior Scientist
>Ottawa Health Research Institute, Div. of Neuroscience
>Ottawa Hospital / University of Ottawa
>Ontario, CANADA
>tel: (613)761-5444
>fax: (613)761-5330
>http://www.ohri.ca/profiles/stys.asp
>-------------------------------------------------------------------------------
>_______________________________________________
>Unsubscribe or switch delivery mode:
><http://www.realsoftware.com/support/listmanager/>
>Search the archives of this list here:
><http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Re: Re: Re: math error
Date: 03.08.06 16:05 (Thu, 3 Aug 2006 11:05:38 -0400)
From: Peter K. Stys
"confusing" is Mathematica's middle name IMHO. I believe the -4 means
that the result begins 4 places to the right of the binary "decimal"
point.

P.

On 8/2/06, Bob Delaney <<email address removed>> wrote:
> Peter,
>
> I agree, the precision is 100 places.
>
> Looking at Mathematica's result again, it appears to be formally
> incorrect. There is no binary point in front of the binary bits!
> Shouldn't the "-4" be "-104"?
>
> Or does "RealDigits[0.036`100, 2, 100]" imply that one first
> multiplies .036 by 2^100. Then the answer is formally correct. That
> would really be confusing!
>
> Bob
>
> >Yes, i understand, but the PRECISION (if I use the term correctly) is
> >100 places.
> >
> >Cheers,
> >P.
> >
> >
> >On 8/2/06, Bob Delaney <<email address removed>> wrote:
> >>Peter,
> >>
> >>Because the "-4" means times 2^(-4), your result represents .036
> >>accurate to 104 places following the binary point.
> >>
> >>Bob
> >>
> >>
> >>
> >>
> >>>I've often wondered about trying Maple (any good?).
> >>>
> >>>Anyway, here is a reply from Wolfram tech support, turns out I wasn't
> >>>using Mathematica correctly (a common occurrence with me, not a simple
> >>>app to use). Os other were correct, 0.036 is not base-2
> >>>representable, and this explains the integer round-down "error" first
> >>>reported in this thread.
> >>>
> >>>=wD#D> >>>I believe Mathematica is working correctly.
> >>>
> >>>As specified in help of RealDigits, RealDigits[x]normally returns a list of
> >>>digits whose length is equal to Precision[x].
> >>>
> >>>Please use the correct precision.
> >>>
> >> >RealDigits[0.036`100, 2, 100]
> >>>
> >>>returns:
> >>>
> >>>{{1, 0, 0, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0,
> >>>0,
> >>> 1, 1, 0, 1, 0, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 1,
> >>>1,
> >>> 1, 0, 1, 1, 0, 1, 1, 0, 0, 1, 0, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 0, 0,
> >>>1,
> >>> 1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1,
> >>>1,
> >>> 0, 0, 1}, -4}
> >>>
> >>_______________________________________________
> >>Unsubscribe or switch delivery mode:
> >><http://www.realsoftware.com/support/listmanager/>
> >>
> >>Search the archives of this list here:
> >><http://support.realsoftware.com/listarchives/lists.html>
> >>
> >
> >
> >--
> >-------------------------------------------------------------------------------
> >Peter K. Stys, MD
> >Professor of Medicine(Neurology), Senior Scientist
> >Ottawa Health Research Institute, Div. of Neuroscience
> >Ottawa Hospital / University of Ottawa
> >Ontario, CANADA
> >tel: (613)761-5444
> >fax: (613)761-5330
> >http://www.ohri.ca/profiles/stys.asp
> >-------------------------------------------------------------------------------
> >_______________________________________________
> >Unsubscribe or switch delivery mode:
> ><http://www.realsoftware.com/support/listmanager/>
> >
> >Search the archives of this list here:
> ><http://support.realsoftware.com/listarchives/lists.html>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

Re: math error
Date: 03.08.06 17:37 (Thu, 3 Aug 2006 09:37:14 -0700)
From: Michael Sharpe
Peter,

Mathematica requires an unfortunate degree of relearning each time
you use it for something non-standard, unless you use it constantly
enough to keep its quirks at the top of your brain. In this instance,
precision, as used in Mathematica, refers to the relative error,
measured in terms of (approximately) the number of significant
decimal places of accuracy, so that if a number x is known to within
a possible absolute error dx, the precision is -Log[10,dx/x]. When
using machine precision (IEE 64 bit representation on current Mac and
PC), there are 53 bits available to represent the mantissa
(exceptional cases aside, effectively a number between 1/2 and 1) and
so the precision of an approximate real number x between 1/2 and 1 so
represented is -Log[10,2^(-54)/x] which is at least -Log[10,2^(-53)]
S Log[10,2], which is just under 16. The precision of an
approximate real number x does not depend on its (base 2) exponent---
only its mantissa. By contrast, Mathematica uses the term accuracy
for absolute error rather than relative error.

The value returned by RealDigits[x,2,100] is (a) the sequence of the
first 100 binary digits in the mantissa, which always starts with the
digit 1; (b) the base 2 exponent of x. If x is an approximate real
number with machine precision, only the first 53 entries will be
meaningful in (a). If you increase the precision to 31 (corresponds
to at least 100 binary digits), by entering x as an expression like .
036`31 or N[36/1000,31], then all entries in (a) will be meaningful.
As I mentioned above, the exponent is not relevant to the precision,
though it would be to the accuracy, which has to do with absolute error.

Michael

On Aug 3, 2006, at 8:23 AM, Peter K. Stys wrote:

>
> "confusing" is Mathematica's middle name IMHO. I believe the -4 means
> that the result begins 4 places to the right of the binary "decimal"
> point.
>
> P.
>
> On 8/2/06, Bob Delaney <<email address removed>> wrote:
>> Peter,
>>
>> I agree, the precision is 100 places.
>>
>> Looking at Mathematica's result again, it appears to be formally
>> incorrect. There is no binary point in front of the binary bits!
>> Shouldn't the "-4" be "-104"?
>>
>> Or does "RealDigits[0.036`100, 2, 100]" imply that one first
>> multiplies .036 by 2^100. Then the answer is formally correct. That
>> would really be confusing!
>>
>> Bob
>>
>>> Yes, i understand, but the PRECISION (if I use the term
>>> correctly) is
>>> 100 places.
>>>
>>> Cheers,
>>> P.
>>>
>>>
>>> On 8/2/06, Bob Delaney <<email address removed>> wrote:
>>>> Peter,
>>>>
>>>> Because the "-4" means times 2^(-4), your result represents .036
>>>> accurate to 104 places following the binary point.
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>>
>>>>> I've often wondered about trying Maple (any good?).
>>>>>
>>>>> Anyway, here is a reply from Wolfram tech support, turns out I
>>>>> wasn't
>>>>> using Mathematica correctly (a common occurrence with me, not a
>>>>> simple
>>>>> app to use). Os other were correct, 0.036 is not base-2
>>>>> representable, and this explains the integer round-down "error"
>>>>> first
>>>>> reported in this thread.
>>>>>
>>>>> =kD#D>>>>> I believe Mathematica is working correctly.
>>>>>
>>>>> As specified in help of RealDigits, RealDigits[x]normally
>>>>> returns a list of
>>>>> digits whose length is equal to Precision[x].
>>>>>
>>>>> Please use the correct precision.
>>>>>
>>>>> RealDigits[0.036`100, 2, 100]
>>>>>
>>>>> returns:
>>>>>
>>>>> {{1, 0, 0, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1,
>>>>> 1, 1, 0, 0,
>>>>> 0,
>>>>> 1, 1, 0, 1, 0, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1,
>>>>> 1, 0, 0, 1,
>>>>> 1,
>>>>> 1, 0, 1, 1, 0, 1, 1, 0, 0, 1, 0, 0, 0, 1, 0, 1, 1, 0, 1,
>>>>> 0, 0, 0, 0,
>>>>> 1,
>>>>> 1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0,
>>>>> 0, 0, 0, 1,
>>>>> 1,
>>>>> 0, 0, 1}, -4}
>>>>>
>>>> _______________________________________________
>>>> Unsubscribe or switch delivery mode:
>>>> <http://www.realsoftware.com/support/listmanager/>
>>>>
>>>> Search the archives of this list here:
>>>> <http://support.realsoftware.com/listarchives/lists.html>
>>>>
>>>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Math Error?
Date: 27.07.06 19:32 (Thu, 27 Jul 2006 14:32:38 -0400)
From: ac644 tcnet.org
dim d as double
dim i as integer

d = 72.0 / 2000.0
d = d * 750.0

i = d

MsgBox str(d)
msgbox str(i)

Why does this code produce a 26 for the second message box instead of a
27? How can I make RB produce a 27 like every other language/calculator
that I tried?

--Seth

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 27.07.06 19:40 (Thu, 27 Jul 2006 12:40:28 -0600)
From: Norman Palardy

On Jul 27, 2006, at 12:32 PM, <email address removed> wrote:

> dim d as double
> dim i as integer
>
> d = 72.0 / 2000.0
> d = d * 750.0
>
> i = d
>
> MsgBox str(d)
> msgbox str(i)
>
> Why does this code produce a 26 for the second message box
> instead of a
> 27? How can I make RB produce a 27 like every other language/
> calculator
> that I tried?

OS X calculator gives 26.999999999

Since i is an integer and d is a double you effectively truncated
the .999999 portion

So try rounding it when you assign it

i = round(d)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

RE: Math Error?
Date: 27.07.06 19:46 (Thu, 27 Jul 2006 13:46:38 -0500)
From: Joseph
That's weird... The calculator on XP gives 27.777777777778.

?!?!

~joe

-----Original Message-----
From: <email address removed>
[mailto:<email address removed>] On Behalf Of Norman
Palardy
Sent: Thursday, July 27, 2006 1:40 PM
To: REALbasic NUG
Subject: Re: Math Error?
OS X calculator gives 26.999999999

Since i is an integer and d is a double you effectively truncated
the .999999 portion

So try rounding it when you assign it

i = round(d)
_______________________________________________

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

RE: Math Error?
Date: 27.07.06 19:49 (Thu, 27 Jul 2006 13:49:50 -0500)
From: Joseph
Scratch that I get 27. I must have clicked something wrong.

This is an example of 'measure twice send once'...

~joe

-----Original Message-----
From: <email address removed>
[mailto:<email address removed>] On Behalf Of Joseph
Sent: Thursday, July 27, 2006 1:47 PM
To: 'REALbasic NUG'
Subject: RE: Math Error?

That's weird... The calculator on XP gives 27.777777777778.

?!?!

~joe

-----Original Message-----
From: <email address removed>
[mailto:<email address removed>] On Behalf Of Norman
Palardy
Sent: Thursday, July 27, 2006 1:40 PM
To: REALbasic NUG
Subject: Re: Math Error?
OS X calculator gives 26.999999999

Since i is an integer and d is a double you effectively truncated
the .999999 portion

So try rounding it when you assign it

i = round(d)
_______________________________________________



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 27.07.06 19:55 (Thu, 27 Jul 2006 13:55:05 -0500)
From: Harrie Westphal

On Jul 27, 2006, at 1:32 PM, <email address removed> wrote:

> dim d as double
> dim i as integer
>
> d = 72.0 / 2000.0
> d = d * 750.0
>
> i = d
>
> MsgBox str(d)
> msgbox str(i)
>
> Why does this code produce a 26 for the second message box
> instead of a
> 27? How can I make RB produce a 27 like every other language/
> calculator
> that I tried?

Are you sure about the "every other language" portion of your
statement? In my experience it is normal for the fractional portion
of a double or single to be thrown away when assigning to an integer
property. To compensate for this use the statement:

i = d + 0.50000001

and you will get the 27 for i instead of the 26.

Do not just use

i = d + 0.5

since I do not believe that 0.5 can be represented exactly in a
double it will be something like 0.4999999999. By throwing in the
extra 1 way out there you are making sure that you get the desired
rounding.

There is also a ROUND function, but I have not used it and therefore
cannot vouch for it.

i = Round(d)

=_D A Mac addict in Tennessee =n
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 28.07.06 02:58 (Thu, 27 Jul 2006 20:58:52 -0500)
From: William Squires
??!?
I get exactly 27 on Calculator.App... :O
Even if I refactor as (72 * 2000) / 750, I still get 27 exactly.
Which makes sense as - in base 10 - dividing by 2000 will produce a
rational, non-repeating decimal (unless you start with an irrational
number in the numerator - like pi, say, or sqrt(2) - or the numerator
is itself a repeating decimal fraction like 1/3.)

On Jul 27, 2006, at 1:40 PM, Norman Palardy wrote:

>
> On Jul 27, 2006, at 12:32 PM, <email address removed> wrote:
>
>> dim d as double
>> dim i as integer
>>
>> d = 72.0 / 2000.0
>> d = d * 750.0
>>
>> i = d
>>
>> MsgBox str(d)
>> msgbox str(i)
>>
>> Why does this code produce a 26 for the second message box instead
>> of a
>> 27? How can I make RB produce a 27 like every other
>> language/calculator
>> that I tried?
>
> OS X calculator gives 26.999999999
>
> Since i is an integer and d is a double you effectively truncated the
> .999999 portion
>
> So try rounding it when you assign it
>
> i = round(d)
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>
William H Squires Jr
4400 Horizon Hill #4006
San Antonio, TX 78229
<email address removed>am <- remove the .nospam

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 28.07.06 03:25 (Thu, 27 Jul 2006 22:25:17 -0400)
From: Phil M
On Jul 27, 2006, at 9:58 PM, William Squires wrote:

> ??!?
> I get exactly 27 on Calculator.App... :O
> Even if I refactor as (72 * 2000) / 750, I still get 27 exactly.
> Which makes sense as - in base 10 - dividing by 2000 will produce a
> rational, non-repeating decimal (unless you start with an
> irrational number in the numerator - like pi, say, or sqrt(2) - or
> the numerator is itself a repeating decimal fraction like 1/3.)

Calculator has a "precision" function, which will round to the range
selected. Set the precision to "2" and enter "2 / 3" which you know
should be 0.6666666666666666666666666 but is displayed as "0.67".

Calculator is also taking a numeric value and displaying it on the
screen as an string (using a precision function).

The Str() function is similar in that it also provides some sort of
precision rounding, but often as not, it will have undesirable
results (scientific notation). This is why the Format() function is
more often used, but this function does *not* have a precision
rounding feature (although it will trim to the format you specify).

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 28.07.06 04:21 (Thu, 27 Jul 2006 21:21:09 -0600)
From: Norman Palardy

On Jul 27, 2006, at 7:58 PM, William Squires wrote:

> I get exactly 27 on Calculator.App... :O

I dont
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 28.07.06 13:52 (Fri, 28 Jul 2006 08:52:29 -0400)
From: Phil M
On Jul 27, 2006, at 11:21 PM, Norman Palardy wrote:

> On Jul 27, 2006, at 7:58 PM, William Squires wrote:
>
>> I get exactly 27 on Calculator.App... :O
>
> I dont

When you refactor the expression, I also get 27 no matter what the
precision is set to. But if I go back to the original formula ((72 /
2000) * 750) then I get the following value with Calculator precision
set to 16:

26.9999999999999964

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Re: Math Error?
Date: 28.07.06 15:35 (Fri, 28 Jul 2006 10:35:15 -0400)
From: Peter K. Stys
On 7/28/06, Phil M <<email address removed>> wrote:
> On Jul 27, 2006, at 11:21 PM, Norman Palardy wrote:
>
> > On Jul 27, 2006, at 7:58 PM, William Squires wrote:
> >
> >> I get exactly 27 on Calculator.App... :O
> >
> > I dont
>
> When you refactor the expression, I also get 27 no matter what the
> precision is set to. But if I go back to the original formula ((72 /
> 2000) * 750) then I get the following value with Calculator precision
> set to 16:
>
> 26.9999999999999964
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

Interesting discussion. To muddy the waters further, using Mathematica:

N[72/2000, 100] (ie calculate to 100 significant digits of precision)

you get:

0.03600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

No argument here, 72/2000 is really 0.036 exactly.

As people said, this real number may not be representable exactly as a
binary floating point number, however:

N[72/2000] (calculate to machine precision)

gives 0.036, implying that the machine is indeed able to represent
0.036 exactly.

P.

Re: Math Error?
Date: 28.07.06 15:47 (Fri, 28 Jul 2006 10:47:25 -0400)
From: Phil M
On Jul 28, 2006, at 10:35 AM, Peter K. Stys wrote:

> Interesting discussion. To muddy the waters further, using
> Mathematica:
>
> N[72/2000, 100] (ie calculate to 100 significant digits of precision)
>
> you get:
>
> 0.03600000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000
>
> No argument here, 72/2000 is really 0.036 exactly.
>
> As people said, this real number may not be representable exactly as a
> binary floating point number, however:
>
> N[72/2000] (calculate to machine precision)
>
> gives 0.036, implying that the machine is indeed able to represent
> 0.036 exactly.

Yes, Calculator.app shows exactly "0.036" even with 16 digit
precision. Now try "0.036 * 750".

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Re: Math Error?
Date: 28.07.06 15:53 (Fri, 28 Jul 2006 10:53:51 -0400)
From: Peter K. Stys
On 7/28/06, Phil M <<email address removed>> wrote:
> On Jul 28, 2006, at 10:35 AM, Peter K. Stys wrote:
>
> > Interesting discussion. To muddy the waters further, using
> > Mathematica:
> >
> > N[72/2000, 100] (ie calculate to 100 significant digits of precision)
> >
> > you get:
> >
> > 0.03600000000000000000000000000000000000000000000000000000000000000000
> > 000000000000000000000000000000000
> >
> > No argument here, 72/2000 is really 0.036 exactly.
> >
> > As people said, this real number may not be representable exactly as a
> > binary floating point number, however:
> >
> > N[72/2000] (calculate to machine precision)
> >
> > gives 0.036, implying that the machine is indeed able to represent
> > 0.036 exactly.
>
> Yes, Calculator.app shows exactly "0.036" even with 16 digit
> precision. Now try "0.036 * 750".
>

In[26]:= N[72/2000*750,100]

Out[26]= 27.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

In[27]:= N[72/2000*750]

Out[27]= 27.

Still suggests all these numbers and intermediate results are
representable exactly at machine precision.

Odd indeed.

P.

Re: Math Error?
Date: 28.07.06 17:08 (Fri, 28 Jul 2006 10:08:01 -0600)
From: Norman Palardy

On Jul 28, 2006, at 8:53 AM, Peter K. Stys wrote:

>
> In[26]:= N[72/2000*750,100]
>
> Out[26]=
> 27.0000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000
>
> In[27]:= N[72/2000*750]
>
> Out[27]= 27.
>
> Still suggests all these numbers and intermediate results are
> representable exactly at machine precision.

I'm quite certain that 72/2000 is not.
Write it as the simple sum of powers of 2 and you find the problem.
72/2000 = 2^-2 + 2^-4 + 2^-5 + 2^-6 + 2^-11 + 2^-15 ..... and so on
and you never get exactly the result you get from 72/2000.
In the machine all you have is powers of 2

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Re: Math Error?
Date: 28.07.06 17:35 (Fri, 28 Jul 2006 12:35:56 -0400)
From: Peter K. Stys
On 7/28/06, Norman Palardy <<email address removed>> wrote:
>
> On Jul 28, 2006, at 8:53 AM, Peter K. Stys wrote:
>
> >
> > In[26]:= N[72/2000*750,100]
> >
> > Out[26]> > 27.0000000000000000000000000000000000000000000000000000000000000000000
> > 0000000000000000000000000000000
> >
> > In[27]:= N[72/2000*750]
> >
> > Out[27]= 27.
> >
> > Still suggests all these numbers and intermediate results are
> > representable exactly at machine precision.
>
> I'm quite certain that 72/2000 is not.
> Write it as the simple sum of powers of 2 and you find the problem.
> 72/2000 = 2^-2 + 2^-4 + 2^-5 + 2^-6 + 2^-11 + 2^-15 ..... and so on
> and you never get exactly the result you get from 72/2000.
> In the machine all you have is powers of 2
>

Actually we're both right and wrong:

In[55]:=RealDigits[0.036,2,100]

Out[55]={{1,0,0,1,0,0,1,1,0,1,1,1,0,1,0,0,1,0,1,1,1,1,0,0,0,1,1,0,1,0,1,0,0,1,1,1,1,
1,1,0,1,1,1,1,1,0,0,1,1,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},-4}

Shows that 0.036 can be represented exactly in binary, but requires 51
significant digits (if I counted correctly to the last 1). So with a
64 bit double, it probably just missed the # of digits in the mantissa
to represent 0.036 exactly.
Nuf time wasted on this, just a curiosity.

P.

RE: Re: Math Error?
Date: 28.07.06 18:45 (Fri, 28 Jul 2006 12:45:55 -0500)
From: Joseph
If I recall correctly the intel chip has an "extended precision" format that
uses 80 bits when doing calculation. These are used during calculation
regardless of the original floating point format. So if the values in the
calculation are single precision (one's compliment 24 bit mantissa with an 8
bit exponent) the full 80 bits are used as 'guard bits' to increase the
precision of the calculation. Of course the result is then truncated to
single precision. In High Level Assembly (Randall Hyde's interesting fusion
of assembly and high level language constructs) you can declare an 80 bit
value.

~joe

-----Original Message-----
From: <email address removed>
[mailto:<email address removed>] On Behalf Of Peter K.
Stys
Sent: Friday, July 28, 2006 11:36 AM
To: REALbasic NUG
Subject: Re: Re: Math Error?
Actually we're both right and wrong:

In[55]:=RealDigits[0.036,2,100]

Out[55]={{1,0,0,1,0,0,1,1,0,1,1,1,0,1,0,0,1,0,1,1,1,1,0,0,0,1,1,0,1,0,1,0,0,
1,1,1,1,
1,1,0,1,1,1,1,1,0,0,1,1,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},-4}

Shows that 0.036 can be represented exactly in binary, but requires 51
significant digits (if I counted correctly to the last 1). So with a
64 bit double, it probably just missed the # of digits in the mantissa
to represent 0.036 exactly.
Nuf time wasted on this, just a curiosity.

P.

Re: Re: Math Error?
Date: 30.07.06 22:13 (Sun, 30 Jul 2006 16:13:42 -0500)
From: Robert Delaney
At 12:35 PM -0400 7/28/06, Peter K. Stys wrote:
>Actually we're both right and wrong:
>
>In[55]:=RealDigits[0.036,2,100]
>
>Out[55]={{1,0,0,1,0,0,1,1,0,1,1,1,0,1,0,0,1,0,1,1,1,1,0,0,0,1,1,0,1,0,1,0,0,1,1,1,1,
> 1,1,0,1,1,1,1,1,0,0,1,1,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},-4}
>
>Shows that 0.036 can be represented exactly in binary, but requires 51
>significant digits (if I counted correctly to the last 1). So with a
>64 bit double, it probably just missed the # of digits in the mantissa
>to represent 0.036 exactly.

I couldn't reply in this thread in a timely manner because of a
change in earthlink's SMTP server which prevented me from sending any
email.

The above binary representation of .036 is incorrect. My Base
Converter application shows and verifies that to 100 binary point
places the correct representation is:

.000010010011011101001011110001101010011111101111100111011011001000101101000011100101011000000100001

So the first part of Out[55] is correct, but the final group of all
zeroes is not. I saw that someone else has proven that .036 requires
an infinite number of binary point places for an exact representation
.

Base Converter is a Universal Cocoa application for Mac OS X only.
It's freeware and can be found at:

http://homepage.mac.com/delaneyrm/BaseConverter.html

I wrote it to develop my Cocoa skills. If there's any demand I'll
write a REALbasic version.

Bob
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 27.07.06 20:18 (Thu, 27 Jul 2006 15:18:33 -0400)
From: ac644 tcnet.org
> Are you sure about the "every other language" portion of your
> statement?

Positive. My statement was "that I tried". I tried several of each.

> In my experience it is normal for the fractional portion
> of a double or single to be thrown away when assigning to an integer
> property.

But there is no fractional portion to throw away.

72 / 2000 = .036, it does not equal .0359999999999999 like the examples
have implied. .036 * 750 is 27.0, again, not 26.99999999.

I've seen lots of examples where different calculators come with
different values when faced with .9999999, but this number stops at just 3
decimal places. If there were any .3333s or .666666s in the calculation, I
could accept a rounding “issue”. But since there are no number to round, it
sure looks like a bug.

--Seth


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 27.07.06 20:23 (Thu, 27 Jul 2006 14:23:18 -0500)
From: Jonathan Johnson

On Jul 27, 2006, at 2:18 PM, <email address removed> wrote:

>> Are you sure about the "every other language" portion of your
>> statement?
>
> Positive. My statement was "that I tried". I tried several of each.
>
>> In my experience it is normal for the fractional portion
>> of a double or single to be thrown away when assigning to an integer
>> property.
>
> But there is no fractional portion to throw away.
>
> 72 / 2000 = .036, it does not equal .0359999999999999 like the
> examples
> have implied. .036 * 750 is 27.0, again, not 26.99999999.
>
> I've seen lots of examples where different calculators come with
> different values when faced with .9999999, but this number stops at
> just 3
> decimal places. If there were any .3333s or .666666s in the
> calculation, I
> could accept a rounding “issue”. But since there are no number to
> round, it
> sure looks like a bug.

Unfortunately, floating point numbers (single and double) are not
able to represent .036 exactly because of how they work. REALbasic
simply uses the floating point capabilities of the processor at hand.
If you want a more detailed explanation, the archives probably
contain them -- it's something that comes up every few months.

If you want something with guaranteed precision, you should check out
Bob Delaney's free plugins here: <http://homepage.mac.com/delaneyrm/>

HTH,
Jon

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 27.07.06 20:32 (Thu, 27 Jul 2006 13:32:13 -0600)
From: Norman Palardy

On Jul 27, 2006, at 1:18 PM, <email address removed> wrote:

>> Are you sure about the "every other language" portion of your
>> statement?
>
> Positive. My statement was "that I tried". I tried several of each.
>
>> In my experience it is normal for the fractional portion
>> of a double or single to be thrown away when assigning to an integer
>> property.
>
> But there is no fractional portion to throw away.
>
> 72 / 2000 = .036, it does not equal .0359999999999999 like the
> examples
> have implied. .036 * 750 is 27.0, again, not 26.99999999.
>
> I've seen lots of examples where different calculators come with
> different values when faced with .9999999, but this number stops at
> just 3
> decimal places. If there were any .3333s or .666666s in the
> calculation, I
> could accept a rounding “issue”. But since there are no number to
> round, it
> sure looks like a bug.
>
> --Seth

Try this code out and you'll see why it is the way it is.
It has everything to do with floating point math in a system based on
binary.

dim d as double
dim i as integer

d = 72.0 / 2000.0

msgbox " d = " + format(d,"-#,###.000000000000000000")
d = d * 750.0
msgbox " d = " + format(d,"-#,###.000000000000000000")

i = d
msgbox " i = " + format(i,"-#,###.000000000000000000")
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 27.07.06 21:58 (Thu, 27 Jul 2006 15:58:40 -0500 (CDT))
From: Craig A. Finseth
72 / 2000 = .036, it does not equal .0359999999999999 like the examples
have implied. .036 * 750 is 27.0, again, not 26.99999999.

In decimal.

In binary, .036 is not representable exactly (that's true of most
"round" decimal values).

This is pretty standard floating point arithmetic stuff. <insert
obligitory mention of how some of us "cut our teeth" on this stuff
*ahem* many years ago and how they probably don't cover it anymore
(:-)>

Craig

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 27.07.06 20:42 (Thu, 27 Jul 2006 15:42:58 -0400)
From: ac644 tcnet.org
> Try this code out and you'll see why it is the way it is.
> It has everything to do with floating point math in a system based on
> binary.

Thanks for the example.

I can accept the limitations of floating point math, but shouldn't the
language and IDE at least be consistant? If you walk through the code line
by line the IDE shows .036, 27 and then magically jumps to 26. Shouldn't
the IDE be showing the "real" values, which in RB's case would be
.035999999997, 26.9999999 and 26. This would create a lot less confusion.
Another example is the str() command. It converts d to "27", if d is really
26.9999, then str() should convert d to 26.99999.

--Seth

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 27.07.06 20:52 (Thu, 27 Jul 2006 13:52:40 -0600)
From: Norman Palardy

On Jul 27, 2006, at 1:42 PM, <email address removed> wrote:

>> Try this code out and you'll see why it is the way it is.
>> It has everything to do with floating point math in a system based on
>> binary.
>
> Thanks for the example.
>
> I can accept the limitations of floating point math, but
> shouldn't the
> language and IDE at least be consistant? If you walk through the
> code line
> by line the IDE shows .036, 27 and then magically jumps to 26.

The debugger does show a "nice" representation of the value

> Shouldn't the IDE be showing the "real" values, which in RB's case
> would be
> .035999999997, 26.9999999 and 26. This would create a lot less
> confusion.
> Another example is the str() command. It converts d to "27", if d
> is really
> 26.9999, then str() should convert d to 26.99999.

Depends on what version of RB you are using.
There have been some subtle changes in the way those functions worked
and in how the debugger shows values.
I NEVER use STR and always use format. It gives you much more control.

In a situation like that you would be able to change the format and
see what's going on.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: math error
Date: 28.07.06 19:01 (Fri, 28 Jul 2006 11:01:01 -0700)
From: Michael Sharpe
Peter,

Mathematica is misleading you here. At least in recent versions (I'm
using 5.2), the last 48 positions are not 0, but are Indeterminate,
indicating that the precision you requested goes beyond the numerical
precision in the floating point number .036. The only numbers capable
of an exact finite binary representation are those whose fractional
representation as m/n (ie, all common factors removed) have n as a
power of 2. As 36/1000 reduces to 9/250, and 250 is not a power of 2.
In your first example, where you compute N[72/1000*750,100], what you
are observing is the ability of Mathematica to do exact arithmetic
calculations, not using any internal representation as a floating
point number, at least when the number you enter is not manifestly
approximate.

Michael

> Subject: Re: Re: Math Error?
> From: "Peter K. Stys" <<email address removed>>
> Date: Fri, 28 Jul 2006 12:35:56 -0400
>
> On 7/28/06, Norman Palardy <<email address removed>> wrote:
>>
>> On Jul 28, 2006, at 8:53 AM, Peter K. Stys wrote:
>>
>>>
>>> In[26]:= N[72/2000*750,100]
>>>
>>> Out[26]>>> 27.00000000000000000000000000000000000000000000000000000000000000000
>>> 00
>>> 0000000000000000000000000000000
>>>
>>> In[27]:= N[72/2000*750]
>>>
>>> Out[27]= 27.
>>>
>>> Still suggests all these numbers and intermediate results are
>>> representable exactly at machine precision.
>>
>> I'm quite certain that 72/2000 is not.
>> Write it as the simple sum of powers of 2 and you find the problem.
>> 72/2000 = 2^-2 + 2^-4 + 2^-5 + 2^-6 + 2^-11 + 2^-15 ..... and so on
>> and you never get exactly the result you get from 72/2000.
>> In the machine all you have is powers of 2
>>
> Actually we're both right and wrong:
>
> In[55]:=RealDigits[0.036,2,100]
>
> Out[55]=
> {{1,0,0,1,0,0,1,1,0,1,1,1,0,1,0,0,1,0,1,1,1,1,0,0,0,1,1,0,1,0,1,0,0,1,
> 1,1,1,
>
> 1,1,0,1,1,1,1,1,0,0,1,1,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 0,
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},-4}
>
> Shows that 0.036 can be represented exactly in binary, but requires 51
> significant digits (if I counted correctly to the last 1). So with a
> 64 bit double, it probably just missed the # of digits in the mantissa
> to represent 0.036 exactly.
> Nuf time wasted on this, just a curiosity.
>
> P.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Math Error?
Date: 28.07.06 19:25 (Fri, 28 Jul 2006 14:25:29 -0400)
From: Art Peters
I believe:

Calculators typically use base 10 calculations, computers typically
employ base 2. In base 2 the numbers here can't be represented
exactly because each term in the binary sequence (1/(2^n)) can only
get arbitrarily close to the number. In base 10 the number can be
represented exactly.

When you limit the precision of binary calculations to some number of
places n, the binary machine code likely automatically rounds at the
n + 1 digit, like the format() function.

PCs use IEEE calculations and truncate without rounding, giving the
binary result. One of the reasons the IEEE was requested to
standardize was to eliminate the differences between results given by
different OS's.

Cheers,

Art


On Jul 28, 2006, at 11:58 AM, realbasic-nug-
<email address removed> wrote:

> Subject: Re: Re: Math Error?
> From: "Peter K. Stys" <<email address removed>>
> Date: Fri, 28 Jul 2006 10:53:51 -0400
>
> On 7/28/06, Phil M <<email address removed>> wrote:
>> On Jul 28, 2006, at 10:35 AM, Peter K. Stys wrote:
>>
>>> Interesting discussion. To muddy the waters further, using
>>> Mathematica:
>>>
>>> N[72/2000, 100] (ie calculate to 100 significant digits of
>>> precision)
>>>
>>> you get:
>>>
>>> 0.036000000000000000000000000000000000000000000000000000000000000000
>>> 00
>>> 000000000000000000000000000000000
>>>
>>> No argument here, 72/2000 is really 0.036 exactly.
>>>
>>> As people said, this real number may not be representable exactly
>>> as a
>>> binary floating point number, however:
>>>
>>> N[72/2000] (calculate to machine precision)
>>>
>>> gives 0.036, implying that the machine is indeed able to represent
>>> 0.036 exactly.
>>
>> Yes, Calculator.app shows exactly "0.036" even with 16 digit
>> precision. Now try "0.036 * 750".
>>
> In[26]:= N[72/2000*750,100]
>
> Out[26]=
> 27.0000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000
>
> In[27]:= N[72/2000*750]
>
> Out[27]= 27.
>
> Still suggests all these numbers and intermediate results are
> representable exactly at machine precision.
>
> Odd indeed.
>
> P.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Re: math error
Date: 28.07.06 20:12 (Fri, 28 Jul 2006 15:12:04 -0400)
From: Peter K. Stys
Good point Michael. It is disconcerting that Mathematica reports 0's
when in fact the values are unknown. I guess you can't even trust the
king of math programs.

Cheers,
Peter.

Tho looking at the result of RealDigits[0.036,2,100], I infer that 0.036 is

On 7/28/06, Michael Sharpe <<email address removed>> wrote:
> Peter,
>
> Mathematica is misleading you here. At least in recent versions (I'm
> using 5.2), the last 48 positions are not 0, but are Indeterminate,
> indicating that the precision you requested goes beyond the numerical
> precision in the floating point number .036. The only numbers capable
> of an exact finite binary representation are those whose fractional
> representation as m/n (ie, all common factors removed) have n as a
> power of 2. As 36/1000 reduces to 9/250, and 250 is not a power of 2.
> In your first example, where you compute N[72/1000*750,100], what you
> are observing is the ability of Mathematica to do exact arithmetic
> calculations, not using any internal representation as a floating
> point number, at least when the number you enter is not manifestly
> approximate.
>
> Michael
>
> > Subject: Re: Re: Math Error?
> > From: "Peter K. Stys" <<email address removed>>
> > Date: Fri, 28 Jul 2006 12:35:56 -0400
> >
> > On 7/28/06, Norman Palardy <<email address removed>> wrote:
> >>
> >> On Jul 28, 2006, at 8:53 AM, Peter K. Stys wrote:
> >>
> >>>
> >>> In[26]:= N[72/2000*750,100]
> >>>
> >>> Out[26]> >>> 27.00000000000000000000000000000000000000000000000000000000000000000
> >>> 00
> >>> 0000000000000000000000000000000
> >>>
> >>> In[27]:= N[72/2000*750]
> >>>
> >>> Out[27]= 27.
> >>>
> >>> Still suggests all these numbers and intermediate results are
> >>> representable exactly at machine precision.
> >>
> >> I'm quite certain that 72/2000 is not.
> >> Write it as the simple sum of powers of 2 and you find the problem.
> >> 72/2000 = 2^-2 + 2^-4 + 2^-5 + 2^-6 + 2^-11 + 2^-15 ..... and so on
> >> and you never get exactly the result you get from 72/2000.
> >> In the machine all you have is powers of 2
> >>
> >>
> >
> > Actually we're both right and wrong:
> >
> > In[55]:=RealDigits[0.036,2,100]
> >
> > Out[55]> > {{1,0,0,1,0,0,1,1,0,1,1,1,0,1,0,0,1,0,1,1,1,1,0,0,0,1,1,0,1,0,1,0,0,1,
> > 1,1,1,
> >
> > 1,1,0,1,1,1,1,1,0,0,1,1,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},-4}
> >
> > Shows that 0.036 can be represented exactly in binary, but requires 51
> > significant digits (if I counted correctly to the last 1). So with a
> > 64 bit double, it probably just missed the # of digits in the mantissa
> > to represent 0.036 exactly.
> > Nuf time wasted on this, just a curiosity.
> >
> > P.
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 28.07.06 20:29 (Fri, 28 Jul 2006 15:29:07 -0400)
From: Mathieu Langlois
Wrong, anything digital uses base 2. It's just the nature of digital,
there is either electricity or there is not. When you start measuring
the level of the electricity, you enter the analog world.

On 7/28/06, Art Peters <<email address removed>> wrote:
> Calculators typically use base 10 calculations, computers typically
> employ base 2. In base 2 the numbers here can't be represented
> exactly because each term in the binary sequence (1/(2^n)) can only
> get arbitrarily close to the number. In base 10 the number can be
> represented exactly.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 28.07.06 21:13 (Fri, 28 Jul 2006 15:13:57 -0500 (CDT))
From: Craig A. Finseth
...
Calculators typically use base 10 calculations, computers typically
employ base 2. In base 2 the numbers here can't be represented
exactly because each term in the binary sequence (1/(2^n)) can only
get arbitrarily close to the number. In base 10 the number can be
represented exactly.
...

Further, I belive that, given an exact fraction in base 2, it can
always be represented exactly in base 10. (But not vice versa, of
course). However, there's nothing "magic" about base 10 and this
doesn't hold for all bases.

For example, exact fractions in bases 3 and 7 can't be represented
exactly in base 10. (I don't know about bases 4 and 8.)

Craig
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 28.07.06 21:19 (Fri, 28 Jul 2006 15:19:09 -0500 (CDT))
From: Craig A. Finseth
Wrong, anything digital uses base 2. It's just the nature of digital,
there is either electricity or there is not. When you start measuring
the level of the electricity, you enter the analog world.

Not at all: you can have digital things that use base 3, 4, or other
bases and, in fact, most modern signalling technology (56 k modems,
100 Mbps Ethernet, digital television) uses very large bases (e.g.,
256).

It's a trade-off: the larger the base, the more care you have to take
in recovering the signal and the less loss budget you have.

Think of the difference between a DC signal and one with a frequency
of, say, .00001 sec.

In any event, you're confusing "base 10" with BCD. Calculators indeed
use base 2, but they do their math in base 10 using BCD. So they
don't have the base 2 representation problems.

Craig

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: math error
Date: 28.07.06 21:48 (Fri, 28 Jul 2006 16:48:19 -0400)
From: Phil M
On Jul 28, 2006, at 3:12 PM, Peter K. Stys wrote:

> Good point Michael. It is disconcerting that Mathematica reports
> 0's when in fact the values are unknown. I guess you can't even
> trust the king of math programs.

I don't think the point of Mathematica is to report the Binary
representation of a floating point number, but instead the goal is to
calculate the numeric value at a greater precision than standard math
ops. Mathematica is for scientists and engineers where a precision
error of 1.0e-50 could mean the difference between life and death
(think NASA).

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: math error
Date: 28.07.06 22:01 (Fri, 28 Jul 2006 17:01:24 -0400)
From: Charles Yeomans
Shouldn't you be using Maple?

Charles Yeomans

On Jul 28, 2006, at 3:12 PM, Peter K. Stys wrote:

> Good point Michael. It is disconcerting that Mathematica reports 0's
> when in fact the values are unknown. I guess you can't even trust the
> king of math programs.
>
> Cheers,
> Peter.
>
> Tho looking at the result of RealDigits[0.036,2,100], I infer that
> 0.036 is
>
> On 7/28/06, Michael Sharpe <<email address removed>> wrote:
>> Peter,
>>
>> Mathematica is misleading you here. At least in recent versions (I'm
>> using 5.2), the last 48 positions are not 0, but are Indeterminate,
>> indicating that the precision you requested goes beyond the numerical
>> precision in the floating point number .036. The only numbers capable
>> of an exact finite binary representation are those whose fractional
>> representation as m/n (ie, all common factors removed) have n as a
>> power of 2. As 36/1000 reduces to 9/250, and 250 is not a power of 2.
>> In your first example, where you compute N[72/1000*750,100], what you
>> are observing is the ability of Mathematica to do exact arithmetic
>> calculations, not using any internal representation as a floating
>> point number, at least when the number you enter is not manifestly
>> approximate.
>>
>> Michael
>>
>> > Subject: Re: Re: Math Error?
>> > From: "Peter K. Stys" <<email address removed>>
>> > Date: Fri, 28 Jul 2006 12:35:56 -0400
>> >
>> > On 7/28/06, Norman Palardy <<email address removed>>
>> wrote:
>> >>
>> >> On Jul 28, 2006, at 8:53 AM, Peter K. Stys wrote:
>> >>
>> >>>
>> >>> In[26]:= N[72/2000*750,100]
>> >>>
>> >>> Out[26]>> >>>
>> 27.00000000000000000000000000000000000000000000000000000000000000000
>> >>> 00
>> >>> 0000000000000000000000000000000
>> >>>
>> >>> In[27]:= N[72/2000*750]
>> >>>
>> >>> Out[27]= 27.
>> >>>
>> >>> Still suggests all these numbers and intermediate results are
>> >>> representable exactly at machine precision.
>> >>
>> >> I'm quite certain that 72/2000 is not.
>> >> Write it as the simple sum of powers of 2 and you find the
>> problem.
>> >> 72/2000 = 2^-2 + 2^-4 + 2^-5 + 2^-6 + 2^-11 + 2^-15 ..... and
>> so on
>> >> and you never get exactly the result you get from 72/2000.
>> >> In the machine all you have is powers of 2
>> >>
>> >>
>> >
>> > Actually we're both right and wrong:
>> >
>> > In[55]:=RealDigits[0.036,2,100]
>> >
>> > Out[55]>> >
>> {{1,0,0,1,0,0,1,1,0,1,1,1,0,1,0,0,1,0,1,1,1,1,0,0,0,1,1,0,1,0,1,0,0,1
>> ,
>> > 1,1,1,
>> >
>> >
>> 1,1,0,1,1,1,1,1,0,0,1,1,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
>> ,
>> > 0,
>> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},-4}
>> >
>> > Shows that 0.036 can be represented exactly in binary, but
>> requires 51
>> > significant digits (if I counted correctly to the last 1). So
>> with a
>> > 64 bit double, it probably just missed the # of digits in the
>> mantissa
>> > to represent 0.036 exactly.
>> > Nuf time wasted on this, just a curiosity.
>> >
>> > P.
>>
>> _______________________________________________
>> Unsubscribe or switch delivery mode:
>> <http://www.realsoftware.com/support/listmanager/>
>>
>> Search the archives of this list here:
>> <http://support.realsoftware.com/listarchives/lists.html>
>>
> --
> ----------------------------------------------------------------------
> ---------
> Peter K. Stys, MD
> Professor of Medicine(Neurology), Senior Scientist
> Ottawa Health Research Institute, Div. of Neuroscience
> Ottawa Hospital / University of Ottawa
> Ontario, CANADA
> tel: (613)761-5444
> fax: (613)761-5330
> http://www.ohri.ca/profiles/stys.asp
> ----------------------------------------------------------------------
> ---------
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 30.07.06 03:25 (Sat, 29 Jul 2006 20:25:51 -0600)
From: Norman Palardy

On Jul 28, 2006, at 1:29 PM, Mathieu Langlois wrote:

> Wrong, anything digital uses base 2. It's just the nature of digital,
> there is either electricity or there is not. When you start measuring
> the level of the electricity, you enter the analog world.

Eniac, one of the first digital computers, was actually base 10
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

RE: Math Error?
Date: 31.07.06 17:38 (Mon, 31 Jul 2006 11:38:06 -0500)
From: Joseph
I recall reading somewhere (???) that the term "digital" computer meant
computers that ran in base 10 while "binary" computers were those that ran
in base 2. Evidently it comes from "digit" being a finger and the fact that
we have 10 of them (thus base 10). Somewhere along the line "digital"
became a more generic term.

~joe

-----Original Message-----
From: <email address removed>
[mailto:<email address removed>] On Behalf Of Norman
Palardy
Sent: Saturday, July 29, 2006 9:26 PM
To: REALbasic NUG
Subject: Re: Math Error?

On Jul 28, 2006, at 1:29 PM, Mathieu Langlois wrote:

> Wrong, anything digital uses base 2. It's just the nature of digital,
> there is either electricity or there is not. When you start measuring
> the level of the electricity, you enter the analog world.

Eniac, one of the first digital computers, was actually base 10
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Math Error?
Date: 31.07.06 23:35 (Mon, 31 Jul 2006 16:35:17 -0600)
From: Norman Palardy

On Jul 31, 2006, at 10:38 AM, Joseph wrote:

> I recall reading somewhere (???) that the term "digital" computer
> meant
> computers that ran in base 10 while "binary" computers were those
> that ran
> in base 2. Evidently it comes from "digit" being a finger and the
> fact that
> we have 10 of them (thus base 10). Somewhere along the line "digital"
> became a more generic term.
>
> ~joe

Digital as opposed to analog computers (which there are)

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>