Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #2535 > unrolled thread

BASIC is 50

Back to article view | Back to comp.misc

Contents

  BASIC is 50 Gordon Henderson <gordon+usenet@drogon.net> - 2014-04-30 09:34 +0000
    Re: BASIC is 50 Ant <ant@zimage.comANT> - 2014-04-30 03:42 -0700
      Re: BASIC is 50 Bob Eager <news0002@eager.cx> - 2014-04-30 10:46 +0000
        Re: BASIC is 50 Gordon Henderson <gordon+usenet@drogon.net> - 2014-04-30 12:03 +0000
    Re: BASIC is 50 Rich <rich@example.com> - 2014-04-30 11:12 +0000
      Re: BASIC is 50 scott@alfter.diespammersdie.us (Scott Alfter) - 2014-04-30 15:56 +0000
        Re: BASIC is 50 Rich <rich@example.com> - 2014-04-30 20:41 +0000
          Re: BASIC is 50 Will Honea <whonea@whonea.net> - 2014-04-30 18:38 -0600
            Re: BASIC is 50 Rich <rich@example.com> - 2014-05-01 02:38 +0000
              Re: BASIC is 50 Will Honea <whonea@whonea.net> - 2014-04-30 22:50 -0600
        Re: BASIC is 50 Rich <rich@example.com> - 2014-04-30 20:48 +0000
          Re: BASIC is 50 Richard Kettlewell <rjk@greenend.org.uk> - 2014-05-02 09:27 +0100
            Re: BASIC is 50 Tim Streater <timstreater@greenbee.net> - 2014-05-02 09:50 +0100
          Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-07 10:48 +0100
            Re: BASIC is 50 Tim Streater <timstreater@greenbee.net> - 2014-05-07 10:57 +0100
            Re: BASIC is 50 Huge <Huge@nowhere.much.invalid> - 2014-05-07 11:20 +0000
              Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-07 13:14 +0100
                Re: BASIC is 50 Marko Rauhamaa <marko@pacujo.net> - 2014-05-07 16:05 +0300
                  Re: BASIC is 50 Paul Sture <nospam@sture.ch> - 2014-05-08 18:06 +0200
                    Re: BASIC is 50 Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 20:17 +0300
                Re: BASIC is 50 "James Harris" <james.harris.1@gmail.com> - 2014-05-07 16:08 +0100
                  Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-07 18:38 +0100
                    Re: BASIC is 50 "James Harris" <james.harris.1@gmail.com> - 2014-05-07 19:09 +0100
                      Re: BASIC is 50 Huge <Huge@nowhere.much.invalid> - 2014-05-07 19:08 +0000
                Re: BASIC is 50 greymausg@mail.com - 2014-05-08 10:15 +0000
                  Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-08 11:38 +0100
                Re: BASIC is 50 Paul Sture <nospam@sture.ch> - 2014-05-08 17:55 +0200
            Re: BASIC is 50 Paul Sture <nospam@sture.ch> - 2014-05-08 17:44 +0200
            Re: BASIC is 50 Rich <rich@example.com> - 2014-05-12 12:39 +0000
              Re: BASIC is 50 Marko Rauhamaa <marko@pacujo.net> - 2014-05-12 16:06 +0300
              Re: BASIC is 50 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-12 22:48 +0100
                Re: BASIC is 50 Rich <rich@example.com> - 2014-05-13 12:03 +0000
                  Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-13 13:23 +0100
                    Re: BASIC is 50 Rich <rich@example.com> - 2014-05-13 16:22 +0000
                      Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-13 19:42 +0100
                        Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-13 19:49 +0100
                          Re: BASIC is 50 Rich <rich@example.com> - 2014-05-14 01:09 +0000
                            Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-14 09:51 +0100
                        Re: BASIC is 50 bde@besplex.bde.org (Bruce Evans) - 2014-05-14 10:36 +0000
                          Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-14 12:58 +0100
                            Re: BASIC is 50 bde@besplex.bde.org (Bruce Evans) - 2014-05-14 16:13 +0000
                              Re: BASIC is 50 "BartC" <bc@freeuk.com> - 2014-05-14 19:24 +0100
                  Re: BASIC is 50 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-13 15:50 +0100
      Re: BASIC is 50 Johny B Good <johnny-b-good@invalid.ntlworld.com> - 2014-05-01 02:50 +0100
      Re: BASIC is 50 David Hume <David.Hume@example.com> - 2014-05-01 09:06 +0100
        Re: BASIC is 50 Gordon Henderson <gordon+usenet@drogon.net> - 2014-05-01 09:56 +0000
        Re: BASIC is 50 Rich <rich@example.com> - 2014-05-01 10:25 +0000
          Re: BASIC is 50 Marko Rauhamaa <marko@pacujo.net> - 2014-05-01 16:43 +0300
            Re: BASIC is 50 Gordon Henderson <gordon+usenet@drogon.net> - 2014-05-01 18:03 +0000
            Re: BASIC is 50 Bob Eager <news0002@eager.cx> - 2014-05-01 21:35 +0000
          Re: BASIC is 50 Rob <monst.oorzudo@ntlworld.com> - 2014-05-01 22:41 +0100
            Re: BASIC is 50 David Hume <David.Hume@example.com> - 2014-05-02 09:26 +0100
              Re: BASIC is 50 Hils <hils@saynotospam.net> - 2014-05-02 10:46 +0100
              Re: BASIC is 50 Johny B Good <johnny-b-good@invalid.ntlworld.com> - 2014-05-02 23:11 +0100
    Re: BASIC is 50 Anssi Saari <as@sci.fi> - 2014-04-30 17:51 +0300
    Re: BASIC is 50 Peter Percival <peterxpercival@hotmail.com> - 2014-05-14 17:40 +0100

Page 1 of 3  [1] 2 3  Next page →

#2535 — BASIC is 50

So there you go. I'm a shade older than BASIC but wouldn't have
appreciated it at the time...

More here: http://www.dartmouth.edu/basicfifty/

The first BASIC program appears to be:

  10 LET X = (7 + 8) / 3
  20 PRINT X
  30 END

but of-course millions of us (not me, of-course!) did the 

  10 PRINT "<insert name here> IS <expletive> COOL!"
  20 GOTO 10

then ran out of the shop...

Gordon

[toc] | [next] | [standalone]

#2536

I learned BASIC on Apple 2s as a callow ant. :)


On 4/30/2014 2:34 AM PT, Gordon Henderson typed:

> So there you go. I'm a shade older than BASIC but wouldn't have
> appreciated it at the time...
>
> More here: http://www.dartmouth.edu/basicfifty/
>
> The first BASIC program appears to be:
>
>    10 LET X = (7 + 8) / 3
>    20 PRINT X
>    30 END
>
> but of-course millions of us (not me, of-course!) did the
>
>    10 PRINT "<insert name here> IS <expletive> COOL!"
>    20 GOTO 10
>
> then ran out of the shop...
>
> Gordon
-- 
"Bother," said Winnie the Pooh, as the ants devoured him.
    /\___/\         Ant(Dude) @ http://antfarm.ma.cx (Personal Web Site)
   / /\ /\ \                Ant's Quality Foraged Links: http://aqfl.net
  | |o   o| |
     \ _ /        If crediting, then use Ant nickname and AQFL URL/link.
      ( )         If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.

[toc] | [prev] | [next] | [standalone]

#2537

On Wed, 30 Apr 2014 03:42:44 -0700, Ant wrote:

> On 4/30/2014 2:34 AM PT, Gordon Henderson typed:
> 
>> So there you go. I'm a shade older than BASIC but wouldn't have
>> appreciated it at the time...
>>
>> More here: http://www.dartmouth.edu/basicfifty/
>>
>> The first BASIC program appears to be:
>>
>>    10 LET X = (7 + 8) / 3 20 PRINT X 30 END
>>
>> but of-course millions of us (not me, of-course!) did the
>>
>>    10 PRINT "<insert name here> IS <expletive> COOL!"
>>    20 GOTO 10
>>
>> then ran out of the shop...
>>
>> Gordon

> I learned BASIC on Apple 2s as a callow ant. :)

I learned it on teletypes like those in the pictures. Using the book 
written by Kemeny and Kurtz.


-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#2540

In article <bsc2kfFflsgU3@mid.individual.net>,
Bob Eager  <news0002@eager.cx> wrote:
>On Wed, 30 Apr 2014 03:42:44 -0700, Ant wrote:
>
>> On 4/30/2014 2:34 AM PT, Gordon Henderson typed:
>> 
>>> So there you go. I'm a shade older than BASIC but wouldn't have
>>> appreciated it at the time...
>>>
>>> More here: http://www.dartmouth.edu/basicfifty/
>>>
>>> The first BASIC program appears to be:
>>>
>>>    10 LET X = (7 + 8) / 3 20 PRINT X 30 END
>>>
>>> but of-course millions of us (not me, of-course!) did the
>>>
>>>    10 PRINT "<insert name here> IS <expletive> COOL!"
>>>    20 GOTO 10
>>>
>>> then ran out of the shop...
>>>
>>> Gordon
>
>> I learned BASIC on Apple 2s as a callow ant. :)

http://unicorn.drogon.net/basics.jpg

>I learned it on teletypes like those in the pictures. Using the book 
>written by Kemeny and Kurtz.

At school we had an HP mini of some sorts - and a TTY33 complete with
acoustic coupler modem!

Then we got an Apple II.

>Using UNIX since v6 (1975)...

You're older than me - I didn't get to use v6 until 1980... (and it was
old then!)

Gordon

[toc] | [prev] | [next] | [standalone]

#2538

Gordon Henderson <gordon+usenet@drogon.net> wrote:
> So there you go. I'm a shade older than BASIC but wouldn't have
> appreciated it at the time...

> but of-course millions of us (not me, of-course!) did the 

>   10 PRINT "<insert name here> IS <expletive> COOL!"
>   20 GOTO 10

> then ran out of the shop...

The other fun one to do on IBM-PC's of the day in the "shops" was:

10 LET X=100
20 PRINT $X
30 LET X=X-0.01
40 GOTO 20

This one would always flummox those who didn't understand why a
"Business" machine could not subtract one penny at a time from 100
dollars and get an accurate answer.

What would appear would be something like:
99.99
99.98
99.9762638428234
99.9677272384
99.9588273747234
...

[toc] | [prev] | [next] | [standalone]

#2544

In article <5360da8d$0$17144$c3e8da3$dd9697d2@news.astraweb.com>,
Rich  <rich@example.com> wrote:
>The other fun one to do on IBM-PC's of the day in the "shops" was:
>
>10 LET X=100
>20 PRINT $X
>30 LET X=X-0.01
>40 GOTO 20
>
>This one would always flummox those who didn't understand why a
>"Business" machine could not subtract one penny at a time from 100
>dollars and get an accurate answer.
>
>What would appear would be something like:
>99.99
>99.98
>99.9762638428234
>99.9677272384
>99.9588273747234

It diverged that quickly, and with that much "garbage" tacked on the end?  I
just tried that code in an Apple II emulator and got this:

100
99.99
99.98
99.97
99.96
99.95
99.9400001
99.9300001
99.9200001
99.9100001
99.9000001
99.8900001
99.8800001
99.8700001
99.8600002
99.8500002
...

BASIC in both machines was supplied by Microsoft, so I wouldn't think it
would be that different.

  _/_
 / v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/            Top-posting!
 \_^_/                              >What's the most annoying thing on Usenet?

[toc] | [prev] | [next] | [standalone]

#2548

Scott Alfter <scott@alfter.diespammersdie.us> wrote:
> In article <5360da8d$0$17144$c3e8da3$dd9697d2@news.astraweb.com>,
> Rich  <rich@example.com> wrote:
> >The other fun one to do on IBM-PC's of the day in the "shops" was:
> >
> >10 LET X=100
> >20 PRINT $X
> >30 LET X=X-0.01
> >40 GOTO 20
> >
> >This one would always flummox those who didn't understand why a
> >"Business" machine could not subtract one penny at a time from 100
> >dollars and get an accurate answer.
> >
> >What would appear would be something like:
> >99.99
> >99.98
> >99.9762638428234
> >99.9677272384
> >99.9588273747234

> It diverged that quickly, and with that much "garbage" tacked on the end?  I
> just tried that code in an Apple II emulator and got this:

> 100
> 99.99
> 99.98
> 99.97
> 99.96
> 99.95
> 99.9400001
> 99.9300001
> 99.9200001
> 99.9100001
> 99.9000001
> 99.8900001
> 99.8800001
> 99.8700001
> 99.8600002
> 99.8500002
> ...

> BASIC in both machines was supplied by Microsoft, so I wouldn't think it
> would be that different.

If memory serves, yes, indeed, it started to diverge after subtracting
no more than about 10 cents, and quickly had lots of garbage on the end
(although probably a shorter amount of garbage, as I was just typing a
bunch of random digits above).

The other half of the trick I always did (for those places like Sears
where the IBM-PC sat next to an Atari 800 or 400, was setup the same
loop on both.  The IBM-PC would diverge quickly, and be an ugly mess. 
The Atari would count down perfectly to the cent all the way to zero.

The reason why was the Atari's used binary coded decimal floating
point, so they were actually doing base 10 calculations, no conversion
to binary, no loss for decimals without an exact representation in
binary.

But I'd have to find a working IBM-PC to actually verify my
recollection of how quickly it diverged.

Even today, with single precision floats, the calculation diverges
quicky:

  #include <stdio.h>
  #include <unistd.h>

  int main( int argc, char ** argv ) {

    float f = 100;
    
    while (1) {
      fprintf(stderr, "%f\n", f);
      f=f-0.01;
      sleep(1);
    }
  }

Compile (on linux) like so: gcc -o fp fp.c

Assuming you put it into a file named fp.c.

Output from a short run:

$ ./fp
100.000000
99.989998
99.979996
99.969994
99.959991
99.949989
99.939987
99.929985
99.919983
99.909981
99.899979
99.889977
99.879974
99.869972
99.859970
99.849968
99.839966
99.829964
99.819962

It is very likely GWBasic on an original IBM-PC was using single
precision floats.

[toc] | [prev] | [next] | [standalone]

#2552

Rich wrote:

> Even today, with single precision floats, the calculation diverges
> quicky:
> 

"Even today"??  Binary representation of decimal numbers will always be 
plagued by decimal values which are irrational in that base.  Combine that 
with the irrational values resulting by operations on decimal numbers even 
in decimal representations and you get similar result sets, especially with 
division.

A friend of mine published a paper back in the early 70's outlining methods 
of estimating error bounds for binary operations.  The genesis of the report 
was the coming transition navigation system for rocket control where the 
number of operations grew to extremely long duration.  The results he 
demonstrated resulted in retention of analog controls for many years and 
involved the frequency response of the system as well as the mission 
duration.  At the time, digital implementation of feedback control systems 
was a hot topic. 

-- 
Will Honea

[toc] | [prev] | [next] | [standalone]

#2555

Will Honea <whonea@whonea.net> wrote:
> Rich wrote:

> > Even today, with single precision floats, the calculation diverges
> > quicky:
> > 

> "Even today"??  Binary representation of decimal numbers will always
> be plagued by decimal values which are irrational in that base.

Exactly my point.  Nothing's changed, even with modern hardware,
because it is the math underlying the representation that results in
the divergence.  More significant bits just allows the divergence to
hide in the shadows for longer.

> Combine that with the irrational values resulting by operations on
> decimal numbers even in decimal representations and you get similar
> result sets, especially with division.

True, but the one difference is that there are far more irrationals in
base-2 representations of base-10 numbers vs. pure base-10 systems such
that most non-mathematicians can easily fall afoul of the divergences. 
With decimal numbers, most reasonably math aware CS folks will
understand where the irrationals will appear and have a more intuitive
feel for what might be going wrong.

> A friend of mine published a paper back in the early 70's outlining
> methods of estimating error bounds for binary operations.  The
> genesis of the report was the coming transition navigation system for
> rocket control where the number of operations grew to extremely long
> duration.  The results he demonstrated resulted in retention of
> analog controls for many years and involved the frequency response of
> the system as well as the mission duration.  At the time, digital
> implementation of feedback control systems was a hot topic.

Nice.  Any possibility the paper is available on the 'net anywhere? 

[toc] | [prev] | [next] | [standalone]

#2557

Rich wrote:

> Nice.  Any possibility the paper is available on the 'net anywhere?
> 

Probably in the University of Wisconsin archives but it may have succumbed 
to bit rot in the 45 years since it was written.  Next time I see Al I'll 
ask if he has a copy I could share.  We were at grad school on AF orders so 
anything we published was either public domain or classified ;0)

-- 
Will Honea

[toc] | [prev] | [next] | [standalone]

#2549

Scott Alfter <scott@alfter.diespammersdie.us> wrote:
> In article <5360da8d$0$17144$c3e8da3$dd9697d2@news.astraweb.com>,
> Rich  <rich@example.com> wrote:
> >The other fun one to do on IBM-PC's of the day in the "shops" was:
> >
> >10 LET X=100
> >20 PRINT $X
> >30 LET X=X-0.01
> >40 GOTO 20
> >
> >This one would always flummox those who didn't understand why a
> >"Business" machine could not subtract one penny at a time from 100
> >dollars and get an accurate answer.
> >
> >What would appear would be something like:
> >99.99
> >99.98
> >99.9762638428234
> >99.9677272384
> >99.9588273747234

> It diverged that quickly, and with that much "garbage" tacked on the end?  I
> just tried that code in an Apple II emulator and got this:

Just tried with a long double and a very long printf precision (to
avoid printf doing roundoff) and even a long double diverges quickly:

  #include <stdio.h>
  #include <unistd.h>

  int main( int argc, char ** argv ) {

    long double f = 100;
    
    while (1) {
      fprintf(stderr, "%.70Lf\n", f);
      f=f-0.01;
      sleep(1);
    }

  }

Output from a run:

$ ./fp
100.0000000000000000000000000000000000000000000000000000000000000000000000
99.9899999999999999980571097069059760542586445808410644531250000000000000
99.9799999999999999961142194138119521085172891616821289062500000000000000
99.9699999999999999941713291207179281627759337425231933593750000000000000
99.9599999999999999922284388276239042170345783233642578125000000000000000
99.9499999999999999902855485345298802712932229042053222656250000000000000
99.9399999999999999883426582414358563255518674850463867187500000000000000
99.9299999999999999863997679483418323798105120658874511718750000000000000
99.9199999999999999844568776552478084340691566467285156250000000000000000
99.9099999999999999825139873621537844883278012275695800781250000000000000
99.8999999999999999805710970690597605425864458084106445312500000000000000
99.8899999999999999786282067759657365968450903892517089843750000000000000
99.8799999999999999766853164828717126511037349700927734375000000000000000
99.8699999999999999747424261897776887053623795509338378906250000000000000
99.8599999999999999727995358966836647596210241317749023437500000000000000
99.8499999999999999708566456035896408138796687126159667968750000000000000
99.8399999999999999689137553104956168681383132934570312500000000000000000
99.8299999999999999669708650174015929223969578742980957031250000000000000
99.8199999999999999650279747243075689766556024551391601562500000000000000
99.8099999999999999630850844312135450309142470359802246093750000000000000
99.7999999999999999611421941381195210851728916168212890625000000000000000
99.7899999999999999591993038450254971394315361976623535156250000000000000
99.7799999999999999572564135519314731936901807785034179687500000000000000
99.7699999999999999553135232588374492479488253593444824218750000000000000
99.7599999999999999533706329657434253022074699401855468750000000000000000
99.7499999999999999514277426726494013564661145210266113281250000000000000
99.7399999999999999494848523795553774107247591018676757812500000000000000
99.7299999999999999475419620864613534649834036827087402343750000000000000
99.7199999999999999455990717933673295192420482635498046875000000000000000
99.7099999999999999436561815002733055735006928443908691406250000000000000

This is why floating point can be dangerous, and why floating point
should _NEVER_ ever be used to compute monetary values:

  What Every Computer Scientist Should Know About Floating-Point
  Arithmetic
  http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

[toc] | [prev] | [next] | [standalone]

#2596

Rich <rich@example.com> writes:
> Scott Alfter <scott@alfter.diespammersdie.us> wrote:

> 99.7199999999999999455990717933673295192420482635498046875000000000000000
> 99.7099999999999999436561815002733055735006928443908691406250000000000000
>
> This is why floating point can be dangerous, and why floating point
> should _NEVER_ ever be used to compute monetary values:

The specific problem is nothing to do with floating point as such,
rather it’s due to the base-2 exponent and bounded precision.  Binary
fixed point representation would run into the same problem with tenths;
decimal floating point on the other hand would not.  (It would have
analogous problems with thirds, though.)

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#2597

In article
<wwvtx98fuvt.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf87AxnpFoA.invalid>,
Richard Kettlewell <rjk@greenend.org.uk> wrote:

> Rich <rich@example.com> writes:
> > Scott Alfter <scott@alfter.diespammersdie.us> wrote:
> 
> > 99.7199999999999999455990717933673295192420482635498046875000000000000000
> > 99.7099999999999999436561815002733055735006928443908691406250000000000000
> >
> > This is why floating point can be dangerous, and why floating point
> > should _NEVER_ ever be used to compute monetary values:
> 
> The specific problem is nothing to do with floating point as such,
> rather it’s due to the base-2 exponent and bounded precision.  Binary
> fixed point representation would run into the same problem with tenths;
> decimal floating point on the other hand would not.  (It would have
> analogous problems with thirds, though.)

That's why one computes currency in pence and not pounds. Converting
for subsequent display is then easy.

-- 
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

[toc] | [prev] | [next] | [standalone]

#2670

"Rich" <rich@example.com> wrote in message
news:53616180$0$59815$c3e8da3$e074e489@news.astraweb.com...
> Scott Alfter <scott@alfter.diespammersdie.us> wrote:

> 99.7099999999999999436561815002733055735006928443908691406250000000000000
>
> This is why floating point can be dangerous, and why floating point
> should _NEVER_ ever be used to compute monetary values:

Why not? Because the result might be off by a quadrillionth of a cent?

Use rounding properly and it can be made to work (unless you're dealing with 
very large amounts such as the US debt then it's a bit trickier to avoid 
errors starting to affect the cents).

You can also work with whole cents or pence for fewer problems, but at some
point (for tax calculations, compound interest etc) you will need to do more
complex arithmetic.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2671

In article <gknav.371282$sa2.196137@fx33.am4>, BartC <bc@freeuk.com>
wrote:

> "Rich" <rich@example.com> wrote in message
> news:53616180$0$59815$c3e8da3$e074e489@news.astraweb.com...
> > Scott Alfter <scott@alfter.diespammersdie.us> wrote:
> 
> > 99.7099999999999999436561815002733055735006928443908691406250000000000000
> >
> > This is why floating point can be dangerous, and why floating point
> > should _NEVER_ ever be used to compute monetary values:
> 
> Why not? Because the result might be off by a quadrillionth of a cent?
> 
> Use rounding properly and it can be made to work (unless you're dealing with 
> very large amounts such as the US debt then it's a bit trickier to avoid 
> errors starting to affect the cents).
> 
> You can also work with whole cents or pence for fewer problems, but at some
> point (for tax calculations, compound interest etc) you will need to do more
> complex arithmetic.

You do that as late in the process as possible to mitigate the effects.

-- 
"The idea that Bill Gates has appeared like a knight in shining armour to
 lead all customers out of a mire of technological chaos neatly ignores 
 the fact that it was he who, by peddling second-rate technology, led them
 into it in the first place."                             - Douglas Adams

[toc] | [prev] | [next] | [standalone]

#2672

On 2014-05-07, BartC <bc@freeuk.com> wrote:
> "Rich" <rich@example.com> wrote in message
> news:53616180$0$59815$c3e8da3$e074e489@news.astraweb.com...
>> Scott Alfter <scott@alfter.diespammersdie.us> wrote:
>
>> 99.7099999999999999436561815002733055735006928443908691406250000000000000
>>
>> This is why floating point can be dangerous, and why floating point
>> should _NEVER_ ever be used to compute monetary values:
>
> Why not? Because the result might be off by a quadrillionth of a cent?
>
> Use rounding properly and it can be made to work (unless you're dealing with 
> very large amounts such as the US debt then it's a bit trickier to avoid 
> errors starting to affect the cents).

Pretty obvious you've never worked in finance or banking.


-- 
Today is Boomtime, the 54th day of Discord in the YOLD 3180
“Stupidity cannot be cured. Stupidity is the only universal capital crime;
 the sentence is death. There is no appeal, and execution is carried out
                 automatically and without pity.”

[toc] | [prev] | [next] | [standalone]

#2673

"Huge" <Huge@nowhere.much.invalid> wrote in message
news:bsuj7gFd631U1@mid.individual.net...
> On 2014-05-07, BartC <bc@freeuk.com> wrote:
>> "Rich" <rich@example.com> wrote in message
>> news:53616180$0$59815$c3e8da3$e074e489@news.astraweb.com...
>>> Scott Alfter <scott@alfter.diespammersdie.us> wrote:
>>
>>> 99.7099999999999999436561815002733055735006928443908691406250000000000000
>>>
>>> This is why floating point can be dangerous, and why floating point
>>> should _NEVER_ ever be used to compute monetary values:
>>
>> Why not? Because the result might be off by a quadrillionth of a cent?
>>
>> Use rounding properly and it can be made to work (unless you're dealing
>> with
>> very large amounts such as the US debt then it's a bit trickier to avoid
>> errors starting to affect the cents).
>
> Pretty obvious you've never worked in finance or banking.

I've written software that worked with currency. I used floating point. But
not for banking. (In that particular application, it needed to work in two
linked currencies. The conversion rate between them was such that one or the
other would generally always be a fraction of a cent wrong, rounded to the 
nearest cent.)

The only issue that might arise (and I can't remember it happening in my
code), is in rounding a value ending in 0.5 cents or very close, then you
have to decide to round up or down. The result might however have to match
the same calculation done elsewhere, where the rounding might be the other
way because their floating point result is different. (But there are ways of
getting consistent, portable floating point results too.)

(In any case, typical 64-bit floating point can represent amounts up to
nearly $100 trillion, expressed in whole cents.)

-- 
Bartc

 

[toc] | [prev] | [next] | [standalone]

#2674

"BartC" <bc@freeuk.com>:

> (In any case, typical 64-bit floating point can represent amounts up to
> nearly $100 trillion, expressed in whole cents.)

If you operate on whole cents, you should stick to 64-bit integers,
which can express a much wider range:

   -$92,233,720,368,547,758.08 .. $92,233,720,368,547,758.07

By the time the US national debt grows out of those bounds (around the
year 2020), we might have 128-bit integers available to us.

(And no, the Americans still won't be willing to let go of the penny.)


Marko

[toc] | [prev] | [next] | [standalone]

#2704

On 2014-05-07, Marko Rauhamaa <marko@pacujo.net> wrote:
> "BartC" <bc@freeuk.com>:
>
>> (In any case, typical 64-bit floating point can represent amounts up to
>> nearly $100 trillion, expressed in whole cents.)
>
> If you operate on whole cents, you should stick to 64-bit integers,
> which can express a much wider range:
>
>    -$92,233,720,368,547,758.08 .. $92,233,720,368,547,758.07
>
> By the time the US national debt grows out of those bounds (around the
> year 2020), we might have 128-bit integers available to us.
>
> (And no, the Americans still won't be willing to let go of the penny.)

I actually starting using 64 bit integers in a project back in 1995.
By then COBOL had that capability even on 32 bit systems.

One of the first things I was taught about integer arithmetic on computers
was that for multiplications you need an intermediate field at least as
large as the sum of the number of digits in each component.  You really
don't need to be dealing in trillions to get here, the balances of asset
accounts for a largish city are sufficient (no points for guessing how I
know that).

-- 
Paul Sture

The final step of #heartbleed recovery is to call your mother, and advise
her to change her maiden name                                  -- @gojomo

[toc] | [prev] | [next] | [standalone]

#2706

Paul Sture <nospam@sture.ch>:

> One of the first things I was taught about integer arithmetic on
> computers was that for multiplications you need an intermediate field
> at least as large as the sum of the number of digits in each
> component.

True. Luckily 128-bit arithmetics isn't hard to come by or implement by
hand.

The other thing is that 2's-complement multiplication behaves nicely wrt
integer overflows (division not so much). So even if you multiplication
overflows, many times your bottom line is correct anyway.


Marko

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.misc

csiph-web