Re: Aren't decimals safely lumped under rationals?



Kent M Pitman wrote:
Ken Tilton <kentilton@xxxxxxxxx> writes:


(- 7.1 6.4) -> 0.6999998

I can fix that using significant digits, but still.

I would not have a question if Lisp did not go to the trouble to
handle ratios so nicely.


I understand what you're saying, and I only disagree slightly, in that
I don't think it's true that Lisp avoids things like floats, substituting another single way of doing things. To the extent there is a Lisp Way,
I think it's the path of pluralism, so I might wish to see:

*read-decimal-number* would be either FLOAT or DECIMAL-RATIO
When this value is FLOAT, decimal ratios are printed as << syntax with prefix A >>.
When this value is DECIMAL-RATIO, floats are printed as << syntax with prefix B >>.
And we could all fight over what the initial and standard values of this variable was.

where, of course, DECIMAL-RATIO is the type we've been discussing.

We'd probably also fight over whether (= #o0.4 0.5) in decimal ratios, too,
since #o4/10 is 1/2. :) [Just trying to inject a REAL debate into this, pardon weak pun.]

And we'd need to fight over the digits of precision problem, which I
think is the lurking huge problem that probably always really kept it
from happening. I have personally advocated that when you multiply
something of low precision by something of high precision, you should
get the low precision result. Many have suggested this would (a)
quickly yield very little precision for anything and (b) ignore the
complicated question of the differences between measurement precision
and computational/expressional precision. For example, 0.5 might be
extremely precise, even though expressed to only one digit,...

Ah, fond memories of whacky Mr. Visco in 9th grade physical science spending a week or two on significant digits (which I think is how I will handle my requirements. ie, 0.5 and 0.00005 each have one significant digit, 0.500 has three significant digits.

btw, I am doing an educational app, so I will have to deal with decimals myself to avoid the alarming (= 0.7 (- 4.1 3.4)) -> nil

This not really a problem, since I am already reading in mathematical notation and converting to internal.

or it
might be only accurate to +/- 0.05 ... the fact that this is not
manifest makes it hard to build an alegbra that is appropriately
precise upon it. And making the output "look good" appears to say
"it is good". So there's some philosophical reason for saying that floats have a place, not just for efficiency, but because they keep
the precision ugliness up front where it belongs.

There are some domains, like money, where the precision issues are
usually well-understood, but even then a simple algorithm for
computing interest runs head-on into the question of whether
fractional pennies are kept secretly or lopped on every computation.
And while there are domain-level answers to this (common conventions
about how to do the computation), I'll bet we'd find that the very
same floating point numbers may be treated differently in different computations.

And as a result, doing the right thing may require domain knowledge,
making it more of an application-level issue than a language-level
issue.

yep.

thx, ken

--
Cells: http://common-lisp.net/project/cells/

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
.

Relevant Pages

  • Re: Arent decimals safely lumped under rationals?
    ... I don't think it's true that Lisp avoids things like floats, ... And we'd need to fight over the digits of precision problem, ... print your own user-defined DECIMAL-RATIO type shouldn't be that hard. ... Alan Turing ...
    (comp.lang.lisp)
  • Re: status of quadruple precision arithmetic in g95 and gfortran?
    ... But, a loop like ... will accumulate the representation error. ... the most significant digits cancel ... precision, using the Intel compiler which supports Real*16 (and ...
    (comp.lang.fortran)
  • Re: Criticism of a proposed floating point (cs)prng requested.
    ... providing gratuitious extra precision. ... If you really *need* that many significant digits in other fields ... Since you are using *all the bits* for crypto, ... *IF* you specify IEEE 754, and rounding modes, and which size to ...
    (sci.crypt)
  • Re: interpretation of PRECISION
    ... PRECISION work together is based on the output from different Forth ... the number of significant digits to be output by F.. ... we may conclude that the DPANS94 spec. ... Also, the Gforth output for example 2) has, by ...
    (comp.lang.forth)
  • Re: its just simple questions..please answer these.
    ... >operations on a calculator. ... >expressed with the precision of the least precise number. ... Your book should discuss 'significant digits' or 'significant ... It is not correct to 'round' intermediate calculations the way I did ...
    (sci.math)