BASIC's WONDER !!!!!!!!!! 
Author Message
 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  
 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  
 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 1e-10.

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  
 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 1e-10.

> 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  
 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 over-loading "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  
 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)*14-85.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 non-trivial, and you
shouldn't try to hide it from the user.

Peter



Tue, 02 Nov 2004 06:22:25 GMT  
 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 CD-ROM
http://www.macgamecreator.com

(Remove NOSPAM from my E-mail address when replying by mail)
-----



Tue, 02 Nov 2004 09:27:00 GMT  
 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  
 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 non-trivial, 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  
 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 MPCalc-Plugin from Bob Delaney here:

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

Admittedly, I'm a long-term HP48-user (RPN) and a physicist too, so I'm
biased. Notwithstanding: I think the plug-in 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  
 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 MPCalc-Plugin from Bob Delaney here:

> http://homepage.mac.com/delaneyrm/MPCalcPlugin.html

> Admittedly, I'm a long-term HP48-user (RPN) and a physicist too, so I'm
> biased. Notwithstanding: I think the plug-in 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 non-RPN version, there is my Precision
Plugin:

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

Bob



Wed, 03 Nov 2004 06:36:58 GMT  
 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 non-trivial, 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  
 BASIC's WONDER !!!!!!!!!!

Quote:
> Thanks for the kind words!

Thanks for your continously improving plug-in!

Quote:
> For those who prefer a lighter non-RPN 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.markus-fritze.de/x48/

Science is fun. Should be fun, at least. Give it a try!

Cheers,

Knut



Wed, 03 Nov 2004 07:34:56 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. Wonders of IBM's REXX compiler

2. VA's table --wondering how

3. Wondering about Domingo's Rational Mean book

4. It's No Wonder Why the Jews are Scared

5. Seeking BASIC manual on the 'net

6. PB DLL's for Visual Basic

7. Old Basic's INPUT command RealBasic Style???

8. Ten Things We'd Like To See In Real Basic

9. Stuggling with DLL's....basic problem

10. Phil's Basic bugs?

11. Visual Basic 5.0 calling Fujitsu COBOL 4.0 created DLL's

 

 
Powered by phpBB® Forum Software