Re: (* 2.4 3) => 7.2000003 WTF?! Let's Fix Lisp! Noob Programming Challenge

Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:

In article <2hodpy89tc.fsf@xxxxxxxxxxxxxxxxx>,
Frode Vatvedt Fjeld <frodef@xxxxxxxxx> wrote:

Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:

Still, Decimal seems better than rationals for processing monetary
transactions because a) no additional effort is required on the part
of the programmer to output a Decimal in the expected format and b)
it does not hide questionable mathematical operations on monetary
quantities, like dividing $1.00 by 3.

Now I am curious, what is $1.00 divided by 3 in this "decimal" system?

Well, that's the point. It's not really well defined. But in Python
this is more evident than in Lisp:

? (format t "~$" 1/4)
0.25
NIL
? (format t "~$" 1/2)
0.50
NIL
? (format t "~$" 1/3)
0.33
NIL
?

versus:

import decimal
D=decimal.Decimal
D('1.00')/D('4')
Decimal("0.25")
D('1.00')/D('2')
Decimal("0.50")
D('1.00')/D('3')
Decimal("0.3333333333333333333333333333")


Lisp covers up the fact that there is something funky going on under the
hood. Python doesn't.

What?

You are comparing apples and oranges.

In the Lisp case, you are looking at the formatted output, where you
have implicitly told the formatter that you only want to look at two
decimal places.

Although there is no decimal arithmetic class in CommonLisp, you don't
get any coverup if you try to do the conversion explicitly. But you
won't even hit the issue unless you ask Lisp to convert something from
rational to floating point.

1/3 in CommonLisp is exactly 1/3 without any limitations imposed by
limited decimal length. In Python, it appears that there is a limit to
the decimal representation.

Consider the following (in ACL):

(coerce 1/3 'double-float) => 0.3333333333333333d0
(coerce 1/3 'single-float) => 0.33333334


Now, it would be nice if the emerging IEEE decimal floating point
standard would begin to be adopted. If enough programming languages
embrace it, there may eventually even be dedicated hardware support.

Now entering fantasy land:

But in the meantime, it would probably be a nice feature if the default
"real" number representation of programming languages were a base 10
floating point number instead of base 2. (In other words, IEEE 854
instead of IEEE 754). Most computations that involve money aren't
repeated that often in any application (unlike scientific computing),
and for the cases where speed is more important, one could choose to use
base 2 floats. But it should be slightly more difficult to invoke.
That will probably be a good design choice.

Similarly, it would be good if unlimited precision integers were the
default representation for things like "int" in languages like C++ and
Java, with the current types being renamed more evocatively into
something like intmod32 or something that suggests their limited range
and wrap-around behavior. Might as well make them unsigned, too, while
we're at it. ;)

Ref: <http://ieeexplore.ieee.org/iel1/2502/1121/00027840.pdf>

--
Thomas A. Russ, USC/Information Sciences Institute

.

Relevant Pages

  • Re: Spartns (fast and flexible tensor representation for Common Lisp)
    ... distinct floating point types. ... The ANSI spec gives a lot of leeway in some areas, ... obvious correspondence between Lisp types and IEEE 754 types, ...
    (comp.lang.lisp)
  • Re: demonic problem descriptions
    ... >> that are not conveniently represented by floating point? ... Because floating point is how all computer programming languages, ... including Lisp, do arithmetic when they see a number with a decimal point. ...
    (comp.lang.lisp)
  • Re: LISPPA
    ... > memory resources. ... do in Common Lisp with code that runs about as fast. ... >> comparing Lisp with languages like C, Pascal and Basic, ... If by "visual programming" you mean the sort of ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... I could list some web servers written in Common Lisp. ... If a programming infrastructure fails ... underpinning than the p* languages. ...
    (comp.lang.lisp)
  • Re: LISPPA
    ... >> memory resources. ... > do in Common Lisp with code that runs about as fast. ... in "weaks languages": iteration instead of recursion and "local" ... I'm programming in Pascal since 1990 year, ...
    (comp.lang.lisp)