i'm using qbasic 1.1 to write a simulation program where the time
step is very small, so i have to use double precision variables.
if i enter a line like
   Capacity# = 93.4#  ,
qbasic automatically changes it into
   Capacity# = 93.40000000000001#   .
the 1 at the 12th decimal does not really bother me, but i find it
a little strange that qbasic changes some numbers one way, other
numbers another way, and some numbers stay the way i wrote
them.

for example,

93.4# is changed to 93.40000000000001#
34.3# stays 34.3#

.0006# is changed to 5.999999999999999D-04#
.0005# stays .0005#

now how should i react to this? should i scream "witchcraft!" and
burn the whole thing? should i nod and say, "it's alright. my
equations are unreadable now but who am i to question a
computer?" will it just go away? is there some logical reason for
this behavior? or is my comp just having a little fun with me?

hoping for realistic or philosophical explanations,

cheers,

der prinz

.........................................

* remove the 'xxx' part from my return address
* to answer by email.

This is a well known phenomenon (to computer science folks, at least), and it
is caused by the fact that, though you can express every integer in any base,
you cannot express every fractional value in any base, and you can express
fractional values exactly in one base which cannot be expressed exactly in
another base.  QBasic uses binary floating point math internally, but numbers
are entered and displayed in decimal.  Exact decimal fractions which cannot
be expressed in binary are rounded to a binary value.  When those values are
printed, they are again rounded to a decimal value, the result being what you
describe below.  The only answer is to use decimal math internally, but that
is slower and takes up more memory.  One of the reasons businesses like COBOL
is that COBOL has scaled decimal math.  Your pennies always add up correctly.
 Run this little program and imagine what an auditor would say if your
company added money this way:

  FOR Money = 0 TO 1 STEP .01
    PRINT Money,
  NEXT

The Microsoft PDS 7.1 supports a CURRENCY type which avoids this problem
similarly to the way COBOL does.  Currency is actually a 'scaled decimal'
integer field that is internally binary, but understood to be divided by
10000 for input and printing (e.g. internal 1 = decimal .0001, internal 10000
= decimal 1)  Decimal values down to .0001 can be expressed exactly.  Beyond
that, you have to use binary float and put up with the rounding errors.  Or
use COBOL or PL/I or another language which supports decimal math.
--
Judson McClendon          This is a faithful saying and worthy of all
Sun Valley Systems        acceptance, that Christ Jesus came into the

(please remove zzz from email id to respond)

Welcome to the wonderful world of 'Merlin and Friends'. We're sooooo happy you
joined us and would like to know that all stakes, {*filter*}s, and torches are,
and have been, forever banned from our little kingdom. :D

You may now take out the ole Model 97 and unload both barrels into the CPU for
better number crunching power....

C'ya,

  ____    _    ____      ____  _____
 |  _ \  / \  / ___) __ | ___)(_   _)
 | |_)  / _ \ \____\/  \|  _)   | |
 |____//_/ \_\(____/\__/|_|     |_|

     www.basicguru.com/schullian