Re: [Maxima-discuss] Other number forms.

[Doug S. <dou...@gm...>]

I have been lurking on Maxima list for years and would like to put in my 2C

A long time ago when I had a student version of Matlab  it hat a maple add
on to do symbolic math.
The one thing that was very helpful was a simplifier that did the question
about 10 different ways and
printed out the method and the answer.

The discussion I see here about the output could be handled the same way.
Make a solve (for beginners ) that uses  all the techniques that have been
presented here and then the beginner would soon learn which way matches
his/her way of  thinking.

Obviously us engineers want a different result than the pure math student
would want.

What I found frustrating is that there was always a way to get what I
wanted but "the way"
was always just out of my reach.

My 2c

Doug Stewart


On Thu, Feb 4, 2016 at 4:12 PM, Richard Fateman <fa...@be...>
wrote:

> On 2/4/2016 8:19 AM, Soegtrop, Michael wrote:
>
> 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?
>
> I  think new users should be told to use allroots(eq)  for this problem.
> Alternatively, take the answer and transform it, for instance, this way:
>
> ratprint:false$
>  ev(solve(eq,x),numer,expand);
>
> Solve documentation could be more appropriate, I think.
>
>
>
> 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.
>
> I think the results from allroots  or the ... expand .. are about the
> same,  differing in the last digit.
> The ratprint lines are suggestive to the user that the problem has been
> converted to an exact
> problem (which may or may not be what the user intended.)
>
> Perhaps the system should say, oh, I think you want to find polynomial
> roots. Do you
> want me to use the numerical method in the allroots() command?
>
> Some people want to avoid all such questions, so there could be yet
> another flag
> SolveShouldUseAllrootsWhenFloatCoefficientArePresentIfPossible...
>
> 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:
>
> well, you have to floatify the right way, as you observe.   As for
> unintended expands, this may be reversed
> by applying, locally,  ratsimp.  This is not always ideal, but it is not
> possible to read peoples' minds :)
> ,
>
>
> (%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.
>
> Do you think this is easier in terms of understanding to just using floats
> rounded to precision N?
>
>
>
> > 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.
>
> Generally the algorithms use whatever (a) does the job,  (b) is supported
> by the underlying system, (c) is "efficient enough".
> Therefore, using arbitrary-length integers (supported by all Common Lisp
> implementations) makes sense.
> Common Lisp also supports exact rational numbers, though Maxima has its
> own implementation.
> Common Lisp has double-float-complex, but Maxima doesn't use this.  The
> support for IEEE 754 binary
> float is not mandated in CL, and its support is implementation dependent.
>
> I don’t know why solve calls radcan
>
> It doesn't have to... there is a flag  solveradcan.  See its
> documentation..
>
> 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?
>
> They are not inherently.  Just some people feel that the display should
> also
> reflect some facts about the internals.   Thus  rat(x^2) ;   x^2;  display
> slightly differently.
> 1, 1.0, 1.0b0   all represent exactly the same mathematical value but
> display differently.
>
>
> 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.
>
> If the user was likely to understand this option, sure.   The change is
> actually trivial (in lisp).
> Type into Maxima
>
> :lisp  (setf (get 'rat 'formatter)  #'(lambda(form)(coerce (/ (cadr
> form)(caddr form)) 'double-float)))
>
> and then typing 1/2 ;  displays as 0.5
>
> Obviously, something other than (coerce ... 'double-float)   could be used
> there.
>
> This does not directly solve the problem of   (  <huge integer1>*x +<huge
> integer2>)/<huge integer3>
>
>
>
>
> > ...  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.
>
> The problem in your example also involves sqrt().
>
> > 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).
>
> The routines for formatting numbers are entirely re-programmable by
> any user.  How much lisp do you want to know??
>
>
>
> > 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
>
> They are in Common Lisp,  but Maxima constructs its own for historical
> reasons.
>
> and should have some hint/mark if they should be displayed as decimal or
> as fraction,
>
> How should 1.0b0+2.0L0+1/2   be displayed?
>
> so that a ConvertToDecimal function would just set such a flag.
>
> Every exact decimal can be represented as an exact binary, since 2 is a
> factor of 5..
> a*10^b  =>  (a*5^b) * 2^b
> but
> a*2^b =>     (a/5^b) * 10^b  ... requires that a  be divisible by 5^b.
>
> So there is an argument that  decimal is superior.
>
>
> on the other hand
> neither works for 1/3
>
>
>
> RJF
>
>
> ------------------------------------------------------------------------------
> 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=272487151&iu=/4140
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
>


-- 
DAS[image: Certificate for 206392]

<https://linuxcounter.net/user/206392.html>