Re: [Maxima-discuss] A proposal to solve Re: float(exp(10000)) works, but float(exp(10000/3)) doesn't

[Soegtrop, M. <mic...@in...>]

Dear Richard,

I fully agree that getting it right is more important than performance, especially on today’s computers. Using machine doubles is an optimization and should only be done on explicit user request when such optimizations make sense.

Your proposal of treating floating point numbers as exact decimal numbers would also solve another problem of Maxima: conversion of numbers to rationals when an algorithm requires exact arithmetic. E.g. when you work with quotients of polynomials (like Laplace transforms), put in some numerical values and then do some factorization, you easily get something like integer quotients in the range of 10^200/10^198. This is not a very useful representation of numbers for analyzing differential equations and also not that easy to convert to something more useful in a mix of numbers and symbolic terms. Exact decimal floating point numbers should have similar performance as such huge integers, but it is much easier to display numbers in a useful way.

Other languages go into a similar direction (away from native machine representations). E.g. python 3 (unlike python 2) has an unrestricted size integer as default. If someone wants a 32 bit integer, he has to state it explicitly.

Best regards,

Michael

From: Richard Fateman [mailto:fa...@be...]
Sent: Thursday, January 28, 2016 12:51 AM
To: max...@li...
Subject: [Maxima-discuss] A proposal to solve Re: float(exp(10000)) works, but float(exp(10000/3)) doesn't

On 1/27/2016 12:33 PM, Stavros Macrakis (Σταῦρος Μακράκης) wrote:
Is auto-promotion of floats to bfloats a good idea?

There is an argument to be made that machine floats are
just too confusing to use.  We probably all recall newbie questions
about why Maxima floats come up as x.999999999  .  The answer
being  "That's the way binary floats work" in every language.

Here's one alternative.  (Parts were/are? used in Maple).
1. All numeric input is treated as exact decimal and stored as decimal.
2. All internal numbers are, in effect, decimal bigfloats.
3. bigfloat precision is a simple decimal number of digits.
4. underlying representation can be the existing decimal bigfloats
  already in Maxima. (Maxima has both decimal and binary.  The decimal
bigfloats are used for computing output forms.  Multiplying/dividing by 10
is presumably slower than shifting, but what's the hurry?)

Consequences:

1. no newbie questions.
2. no overflow.  The exponent is an arbitrary integer. At least the bound is
what comes with your lisp/hardware.
3. no underflow. The exponent is an arbitrary negative integer.
4. There is a clear separation between very large numbers and "Infinity" symbol(s).
5. The discrepancy between lisp implementations will disappear -- we will not
see the handling of overflows as exceptions in system 1 and the production of In.fty
in system 2.
6. We  could have a set of routines that "converts to machine float and calls
numeric libraries" for quadrature, numeric float linear algebra subroutines,  etc.

Negative consequences

1. Eh, not so fast?  Would anyone notice the machine float speed in the blizzard
of other operations surrounding each operation?
2. The reverse newbie questions,  which is to say, someone says How is it that
0.1 is exactly the same as 1/10 on Maxima, when I know they differ by 5.2e-18
in binary.
3. There is still rounding error, setting precision appropriately matters.
4. Reprogramming, redocumentation,.




Please feel free to comment/ elaborate/implement?

RJF




Are there practical applications, where a user will get a useful answer rather than an error to a substantive problem
​ ? I doubt it; I suspect this only happens with

​ ​
artificial problem
​ s​
designed to test Maxima's limit
​ s.)​

No, I think people fall into underflow/overflow traps unintentionally.  Not deliberately
testing Maxima, but at the border of their smarts.  So the purpose would be to
give an answer that deserves further thought instead of "darn, it bombed out".

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928