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

[Stavros M. (Σ. Μ. <mac...@al...>]

​Maxima has had arbitrary-precision exact integers and rationals for about
40 years, long before Python 3.

Fateman's proposal is not about "exact decimal numbers"; it is about
*approximate* (finite-precision) numbers using base 10 instead of base 2.
Decimal floating point (with arbitrarily large powers of 10) is still
approximate. Though 2/5 can be represented exactly in decimal floating
point, 2/3 cannot.

On Thu, Jan 28, 2016 at 3:38 AM, Soegtrop, Michael <
mic...@in...> wrote:

> 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
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
>