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.

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.

>         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

-----

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.

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.

> 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
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

 Page 1 of 1 [ 13 post ]

Relevant Pages