Re: [Maxima-discuss] Other number forms.

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

Dear Richard,

before I answer your mail, let me give another simple example:

(%i6) eq:float(log(2))*x^2+float(log(3))*x+float(log(5));
(%o6) 0.6931471805599453*x^2+1.09861228866811*x+1.6094379124341

(%i7) solve(eq,x);
rat: replaced 1.6094379124341 by 16125974/10019631 = 1.609437912434101
rat: replaced 1.09861228866811 by 28672937/26099232 = 1.098612288668111
rat: replaced 0.6931471805599453 by 13614799/19642003 = 0.693147180559946

(%o7) [x=-(1880998401821696284247+sqrt(9543046281783398211736728328496623165148783)*%i)/2373555716259335585472,x=(sqrt(9543046281783398211736728328496623165148783)*%i-1880998401821696284247)/2373555716259335585472]

Honestly, I don’t think that this is an appropriate answer for the question asked. I mean this is just a simple quadratic equation. Don’t you think that new users will think “what is happening to me here” when they see this?

Of cause it is an interesting question here how to handle the roots. I guess with fractions as internal representation Maxima could come to this solution without taking the numerator and denominator apart. I think if the roots are not evaluated, the results with numbers in decimal notation would still be much more readable. One would get an impression on the size of numbers with counting numerator and denominator digits and thinking about what effect the roots have on this. But the main advantage is if the user decides to “floatify” this, he wouldn’t get something like this:

(%i8) solve(eq,x),float;
rat: replaced 1.6094379124341 by 16125974/10019631 = 1.609437912434101
rat: replaced 1.09861228866811 by 28672937/26099232 = 1.098612288668111
rat: replaced 0.6931471805599453 by 13614799/19642003 = 0.693147180559946
rat: replaced 1.609437912434101 by 16125974/10019631 = 1.609437912434101
rat: replaced 1.098612288668111 by 28672937/26099232 = 1.098612288668111
rat: replaced 0.693147180559946 by 13614799/19642003 = 0.693147180559946
rat: replaced 5.840580659739714E-22 by 1/1712158530560495976448 = 5.840580659739714E-22
rat: replaced 3.089182138007307E+21 by 3089182138007307157504/1 = 3.089182138007307E+21
rat: replaced 3.089182138007307E+21 by 3089182138007307157504/1 = 3.089182138007307E+21

(%o8) [x=-4.213088376859234*10^-22*(1880998401821696284247+3089182138007307157504*%i),x=4.213088376859234*10^-22*(3089182138007307157504*%i-1880998401821696284247)]


(%i10) solve(eq,x),float,expand;
rat: replaced 1.6094379124341 by 16125974/10019631 = 1.609437912434101
rat: replaced 1.09861228866811 by 28672937/26099232 = 1.098612288668111
rat: replaced 0.6931471805599453 by 13614799/19642003 = 0.693147180559946
rat: replaced 1.609437912434101 by 16125974/10019631 = 1.609437912434101
rat: replaced 1.098612288668111 by 28672937/26099232 = 1.098612288668111
rat: replaced 0.693147180559946 by 13614799/19642003 = 0.693147180559946
rat: replaced 1.609437912434101 by 16125974/10019631 = 1.609437912434101
rat: replaced 1.098612288668111 by 27033780/24607207 = 1.098612288668112
rat: replaced 0.693147180559946 by 13614799/19642003 = 0.693147180559946
rat: replaced 8.737744964753944E+21 by 8737744964753944477696/1 = 8.737744964753944E+21
rat: replaced 8.737744964753944E+21 by 8737744964753944477696/1 = 8.737744964753944E+21

(%o10) [x=-1.301499735963974*%i-0.7924812503605795,x=1.301499735963974*%i-0.7924812503605795]

Expanding does help here, but in most cases where one has mixed numeric / symbolic expressions, expand will massively bloat up the symbolic parts. It can then get really tricky to transform the expression returned by Maxima into a form useful for the application.


> If you want a brief human-readable depiction of a long number, repeating decimals
> may not be the solution. One of them is the issue of length.  Another is that
> it is redundant -- ratios work.  Another is that it doesn't work at all for irrational
> or transcendental numbers.

So how about the format I proposed (truncate after 2*N+1 digits, where N is the max number of digits in numerator and denominator)? Of cause this doesn’t work for irrational numbers either, but these can be either kept symbolic or transformed to imprecise numbers.

> I've mentioned before that interval arithmetic may be useful in that an answer of the
> form [low, high]   means the correct answer x  is   low<=x<=high.  Is that enough?

For me the essential question is if basic Maxima algorithms like solve can live with these numbers without converting them to something which is not appropriate for the user. I don’t know why solve calls radcan and with which numbers solve could live or not, but I would assume it can be modified such that it can live with atomic integer fractions.

> There are 2 separate issues. What can you represent internally
> and what do you want to print for a human.

So why are these two tied together so tightly? Why not have an option to display fractions as decimals if this would be more appropriate for the user, but fractions would be more appropriate for Maxima’s internals.
> ...  The puzzle then becomes how to mix them if they occur in the
> same arithmetic sum, product, log()  etc.

For this reason I think fractions are a superior internal representation. They don’t have the problem of mixing. The problem that numbers get large exists anyway if the user calls solve, which calls radcan.
> And maybe how to print them so as to reveal the value, the data-type,
> and in the case of precision-N, what N is.
> And I suppose how to type them in  (how to parse a bigfloat).

Of cause this is also a problem, but I think a secondary one. For me the major question is how to represent numbers in a CAS internally and how to represent them externally approximately (e.g. as fraction or decimal).

> thought this problem was solved by using expand(),  and then maybe float().

In some cases it helps, in other cases you don’t want to call expand, because it would massively blow up the symbolic part of the result.

> There is, I think, very little justification for decimal floats unless the user types them
> in as decimal. That is,  ConvertToFloat(1/3) could result in binary or decimal, but
> neither is exactly 1/3. But  1.0L0/3   could arguably be decimal. What about
> 1.0L0/3.0B0 ?

I think if the user want floats, binary floats are fine. I think there should be a  “Show as decimal” option or function which just displays 1/3 as 0.333… without converting its internal representation. Also fractions should be atomic and should have some hint/mark if they should be displayed as decimal or as fraction, so that a ConvertToDecimal function would just set such a flag.

Best regards,

Michael
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