Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.
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 |
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> |