BASIC's WONDER !!!!!!!!!!
Author 
Message 
Pawe #1 / 13

BASIC's WONDER !!!!!!!!!!
I use Visual Basic 6.0 SP3. Can anybody explain me this: ============================== Private Sub Command1_Click() Dim a As Double Dim b As Double a = 1.1 a = a + 3.0 a = a + 2.1 b = 6.2 If a = b Then MsgBox "equal" Else MsgBox "not equal" End If End Sub =================================

Mon, 01 Nov 2004 18:31:49 GMT 


Bori #2 / 13

BASIC's WONDER !!!!!!!!!!
In realBasic double does the same. Single returns "equal". Shows that it is safe to be single and avoid double standards. Beyond this m{*filter*} statement my guess is that double is stored in a funny floating point way which means that the Nth decimal is different in a and b. Test for abs(a  b) < 0.000000000000001 and you get equal but add one zero and you get not equal. Boris
Quote:
> I use visual Basic 6.0 SP3. > Can anybody explain me this: > ============================== > Private Sub Command1_Click() > Dim a As Double > Dim b As Double > a = 1.1 > a = a + 3.0 > a = a + 2.1 > b = 6.2 > If a = b Then > MsgBox "equal" > Else > MsgBox "not equal" > End If > End Sub > =================================

Mon, 01 Nov 2004 19:36:15 GMT 


Craig A. Finse #3 / 13

BASIC's WONDER !!!!!!!!!!
Quote:
>In realBasic double does the same. Single returns "equal". Shows that it >is safe to be single and avoid double standards. Beyond this m{*filter*} >statement my guess is that double is stored in a funny floating point >way which means that the Nth decimal is different in a and b. >Test for abs(a  b) < 0.000000000000001 and you get equal but add >one zero and you get not equal.
Close, but not quite. It is not possible to represent a decimal value (as in 0.1, 0.2, .. 0.9 except for 0.5) exactly in any finite binary value as the representation is a repeating sequence. Given that any such representation is an approximation, the exact outcome of any sequence of operations depends on the idiosyncrasies of the implementation. In other words, in a different implmentation, it could well be that Single doesn't "work" but Double does. (Sorry if that interferes with the m{*filter*}lesson (:).) This inexactness is why financial applications don't use floating point for math. Instead they use BCD, integer cents, or the equivalent. In general, you can never assume that floating point math is exact. For example, instead of: Dim a, b as Double ... if a = b then ... do: Dim a, b as Double ... if abs(a  b) < EPSILON then ... where EPSILON is whatever difference you are willing to allow to for "good enough." An example value might be 1e10. You may have to modify this comparision if a or b have a large enough magnitude that the comparison becomes problematic. For example, if the mantissa is, say, 48 bits (and therefore contains 14+ decimal digits), the example would have to be modified if either a or b was larger than 1000. Craig Quote:
>> I use visual Basic 6.0 SP3. >> Can anybody explain me this: >> ============================== >> Private Sub Command1_Click() >> Dim a As Double >> Dim b As Double >> a = 1.1 >> a = a + 3.0 >> a = a + 2.1 >> b = 6.2 >> If a = b Then >> MsgBox "equal" >> Else >> MsgBox "not equal" >> End If >> End Sub >> =================================

Mon, 01 Nov 2004 22:29:27 GMT 


Joe Strou #4 / 13

BASIC's WONDER !!!!!!!!!!
[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]]
Quote:
> In general, you can never assume that floating point math is exact. > For example, instead of: > Dim a, b as Double > ... > if a = b then > ... > do: > Dim a, b as Double > ... > if abs(a  b) < EPSILON then > ... > where EPSILON is whatever difference you are willing to allow to for > "good enough." An example value might be 1e10. > You may have to modify this comparision if a or b have a large enough > magnitude that the comparison becomes problematic. For example, if > the mantissa is, say, 48 bits (and therefore contains 14+ decimal > digits), the example would have to be modified if either a or b was > larger than 1000.
It might be interesting to have an "approximately equal" operator built in, wouldn't it? Perhaps you could simply write: if a ~= b then // they're close enough to equal end if This could be implemented by the compiler much faster (and probably more accurate) than what you could do yourself. Or maybe '=' should always work this way with singles and doubles, and some other operator or function should be provided if you want to know when the two are exactly equal? Cheers,  Joe  ,.  Joseph J. Strout Check out the Mac Web Directory: 
`'

Mon, 01 Nov 2004 23:29:20 GMT 


Denni #5 / 13

BASIC's WONDER !!!!!!!!!!
Many years ago, Microsoft made a Basic for Macintosh. It came with two versions: "Scientific" and "Financial." (I think those were the terms, it's been a while.) A program run in the Scientific version used floating point for reals. In the Financial version, BCD was used for reals. I would love to see a BCD type in REALbasic. Writing one for REALbasic in C would work I guess. But without operator overloading "a = b" has to become something like bcdIsEqual(a, b) which is less intuitive for something that ought to be a basic type. I guess it could be done directly in REALbasic using strings or other arrays, but some part of me cringes at using more that a nibble to represent a single decimal digit.
Quote: > This inexactness is why financial applications don't use floating point > for math. Instead they use BCD, integer cents, or the equivalent.

Tue, 02 Nov 2004 05:46:06 GMT 


Peter Robinso #6 / 13

BASIC's WONDER !!!!!!!!!!
Quote:
> > In general, you can never assume that floating point math is exact. > It might be interesting to have an "approximately equal" operator built > in, wouldn't it? Perhaps you could simply write: > if a ~= b then > // they're close enough to equal > end if > This could be implemented by the compiler much faster (and probably > more accurate) than what you could do yourself.
I don't think it is feasible to have this kind of comparison done automatically and accurately: the compiler cannot know how close two reals should be in order to be considered equal. The problem is that floating point errors are not fixed, rather they depend on the particular calculations done to arrive at an answer. What would the compiler do if you were foolish enough to try the following? Dim a as Double Dim i,k as integer k=20 // better not be too big! a=1.1 For i=1 to k a=(a+5.1)*1485.7 // 'should' replace a with 1.1 If i=4 then EditField2.text=Str(a) // sanity check End Next EditField1.text=Str(a) If a ~= 1.1 // how close is close enough? End After running this, a might differ from 1.1 by as much as the order of e*(14^k), where e is 'machine epsilon'the smallest number you can add to 1 and notice the difference. [When I tried it, I got ~120 million instead of 1.1, which is consistent with e =~ 2*10^15, but probably I've made a mistake somewhere.] ^^ I don't like that 2. You could implement all floating point calculations by calculating upper and lower bounds for each result, but that would be tricky and slow. IMHO, understanding floating point maths really is nontrivial, and you shouldn't try to hide it from the user. Peter

Tue, 02 Nov 2004 06:22:25 GMT 


Al Staffieri J #7 / 13

BASIC's WONDER !!!!!!!!!!
Quote: >Many years ago, Microsoft made a Basic for Macintosh. It came with two >versions: "Scientific" and "Financial." (I think those were the terms, >it's been a while.)
The 2 versions were Binary and Decimal.  Al Staffieri Jr. http://members.aol.com/AlStaff/index.html Mac Game Creator Toolkit CDROM http://www.macgamecreator.com (Remove NOSPAM from my Email address when replying by mail) 

Tue, 02 Nov 2004 09:27:00 GMT 


Bori #8 / 13

BASIC's WONDER !!!!!!!!!!
I thought of this but did not suggest it. Independently of whether you are single or not it is difficult to know when you are close enough. You might know when you end up in court. Perhaps we will one day see a RealAccountantsBasic where you can define a fixed decimal precision. Boris Quote: > if a ~= b then > // they're close enough to equal > end if

Tue, 02 Nov 2004 16:27:18 GMT 


Joe Strou #9 / 13

BASIC's WONDER !!!!!!!!!!
Quote:
> I don't think it is feasible to have this kind of comparison done > automatically and accurately: the compiler cannot know how close two > reals should be in order to be considered equal.
No, but it can know if they're equal within the precision of the number (i.e., within machine epsilon). That's what I had in mind. But you're quite right, after doing some calculations your error may very well be greater than that. But I see that as a different issue. Quote: > You could implement all floating point calculations by calculating upper > and lower bounds for each result, but that would be tricky and slow.
Agreed. Quote: > IMHO, understanding floating point maths really is nontrivial, and you > shouldn't try to hide it from the user.
Maybe  except that most people aren't doing any serious math. And most serious math doesn't involve the "=" comparison operator. So it might be safe to make that mean "equal within epsilon".  Joe  ,.  Joseph J. Strout Check out the Mac Web Directory: 
`'

Wed, 03 Nov 2004 04:56:48 GMT 


Knut Lorenze #10 / 13

BASIC's WONDER !!!!!!!!!!
Quote: > Maybe  except that most people aren't doing any serious math.
True enough, sad enough. Others should consider using bc via the shell or download the outstandingly great MPCalcPlugin from Bob Delaney here: http://homepage.mac.com/delaneyrm/MPCalcPlugin.html Admittedly, I'm a longterm HP48user (RPN) and a physicist too, so I'm biased. Notwithstanding: I think the plugin is sophisticated enough to fit virtually all mathematical needs this newsgroups might ever think of. BTW: Thanks, Bob! Cheers, Knut

Wed, 03 Nov 2004 05:58:55 GMT 


Bob Delane #11 / 13

BASIC's WONDER !!!!!!!!!!
Quote:
> > Maybe  except that most people aren't doing any serious math. > True enough, sad enough. > Others should consider using bc via the shell or download the outstandingly > great MPCalcPlugin from Bob Delaney here: > http://homepage.mac.com/delaneyrm/MPCalcPlugin.html > Admittedly, I'm a longterm HP48user (RPN) and a physicist too, so I'm > biased. Notwithstanding: I think the plugin is sophisticated enough to fit > virtually all mathematical needs this newsgroups might ever think of. > BTW: Thanks, Bob! > Cheers, > Knut
Knut, Thanks for the kind words! For those who prefer a lighter nonRPN version, there is my Precision Plugin: http://homepage.mac.com/delaneyrm/PrecisionPlugin.html Bob

Wed, 03 Nov 2004 06:36:58 GMT 


Peter Robinso #12 / 13

BASIC's WONDER !!!!!!!!!!
Quote:
> > I don't think it is feasible to have this kind of comparison done > > automatically and accurately: the compiler cannot know how close two > > reals should be in order to be considered equal. > No, but it can know if they're equal within the precision of the number > (i.e., within machine epsilon). That's what I had in mind.
Certainly it can check within machine epsilon, but I wouldn't call that 'the precision of the number' because to me the latter requires knowledge of the 'calculation history' of the number IYSWIM. Quote: > But you're quite right, after doing some calculations your error may > very well be greater than that. But I see that as a different issue.
To me it is all part of the same issue. I don't think floating point inaccuracy can ever arise in practise without doing *any* calculation. E.g. if you try this: Dim a as Double a=3.1 If( a = 3.1 ) Beep End the comparison will always return true, even though 3.1 isn't stored precisely in a. To get the error to manifest itself, you have to do a calculation. (In general) after a single floating point addition you're accurate to within 1 epsilon[1]. After two additions, you're accurate to 2 epsilon. Etc.. All I'm saying is that it's not helpful to think of machine epsilon as some canonical bound on floating point errors: it's only the correct bound in very specific circumstances. Quote: > > IMHO, understanding floating point maths really is nontrivial, and you > > shouldn't try to hide it from the user. > Maybe  except that most people aren't doing any serious math.
True. Quote: > And most serious math doesn't involve the "=" comparison operator.
Yes! I had not crystallised that thought in my own mind, but I see that it's true. Quote: > So it might be safe to make that mean "equal within epsilon".
Safe maybe, but I don't think it would gain you anything. You'd still get threads about this, with subjects like "BASIC's WONDER !!!!!!!!!!", the code examples would just be a few lines longer. [1] I think it's understood that to say x is accurate to within e means that the true value of x lies in [ x  x*e , x + x*e ] ^^ ^^ 

Wed, 03 Nov 2004 06:40:18 GMT 


Knut Lorenze #13 / 13

BASIC's WONDER !!!!!!!!!!
Quote: > Thanks for the kind words!
Thanks for your continously improving plugin! Quote: > For those who prefer a lighter nonRPN version, there is my Precision > Plugin: > http://homepage.mac.com/delaneyrm/PrecisionPlugin.html
Exactly. And for those who would like to learn about the HP48 (free!): http://www.markusfritze.de/x48/ Science is fun. Should be fun, at least. Give it a try! Cheers, Knut

Wed, 03 Nov 2004 07:34:56 GMT 


