[LON-CAPA-users] formula response and maxima floating point numbers
Lon H Mitchell
Thu, 16 Sep 2010 11:06:00 -0400
Thanks for the very detailed response. Can I ask, when you personally
are writing problems, how do you avoid this trouble? Do you try to
construct problems so they do not encounter it, or do you always use
sampling, or do you ask your students to always use fractions instead of
decimals, or a combination of these?
Peter Riegler wrote:
> Hi Lon!
> On 09.09.2010 15:54, Lon H Mitchell wrote:
>> According to the Maxima manual, a shortcut to getting a floating point
>> approximation to a function value is to use a decimal argument. For
>> example, sqrt(2.0) will return 1.414213562373095 while sqrt(2) will stay
>> as sqrt(2).
>> This shortcut can result in some seemingly incomprehensible answers. For
>> example, "is(sqrt(1.5) = sqrt(3/2))" returns /false/.
> Note that "is" checks on syntactical equality (see documentation of
> "is" in maxima, e.g. via "? is;" without double quotes on a maxima
> prompt). Contrast this with "equal" which tests on equivalence. See
> the manual for the exact meaning of equivalence (roughly
> What formularesponse does, is testing for equivalence in a more
> general sense, namley trigsimp(trigreduce(lhs-rhs)).
>> Further, a formula
>> response problem with answer "1+ sqrt(3/2)*x" will mark "1 +
>> sqrt(1.5)*x" as incorrect and vice versa. Since the behavior is inherent
>> to Maxima, math response problems can be similarly affected.
> Actually this is inherent to computer algebra systems. It is a
> question of precision. For instance 1 or 1/3 are expressions that have
> infinite precision while 1. or 0.333 have finite precision (and are of
> different type, namely float).
>> Note that this behavior only seems to arise when dealing with a function
>> value. For example, "x^(1.5)" and "x^(3/2)" are considered equivalent by
>> Maxima, as are "1.5" and "3/2".
>> While one possible solution is to use sampling rather than algebraic
>> checking, my guess would be that sqrt(1.5) = sqrt(3/2) would be an
>> expected equivalence on the part of most users.
> Sadly, that is true. Even Mathematica seems to have given up on that
> issue. Up to version 4 Mathematica strictly (an rightly - in my
> opinion) differentiated between e.g. 1 and 1.0. Now equality is
> defined somewhat arbitrarily. The manual says "Approximate numbers are
> considered equal if they differ in at most their last eight binary
> digits (roughly their last two decimal digits)."
> I couldn't find any documentation on how maxima precisely is handling
> the issue. However, it seems to me that maxima converts floats to
> rationals, e.g.
> (%i28) is(equal(3/2,1.5));
> `rat' replaced 0.0 by 0/1 = 0.0
> (%o28) true
> (%i29) is(equal(0.333,1/3));
> `rat' replaced -3.333333333332966E-4 by -1/3000 = -3.333333333333333E-4
> (%o29) false
> (%i30) is(equal(1/7,0.142857));
> `rat' replaced 1.4285714283746032E-7 by 1/7000000 = 1.4285714285714285E-7
> (%o30) false
>> The question then: is there a way to instruct Maxima to turn this
>> shortcut behavior off,
> I don't know of any environment variable or flag that forces maxima to
> do so. I even doubt that there is such a thing.
>> and, if so, is it possible to change formula
>> response problems (or lonmaxima) to make use of it?
> To do so we would need to precisely understand what maxima is doing.
> And we would need to be confident that maxima won't change that
> behavior (cf. Mathematica).
> My first recommendation would be to use mathresponse and to check the
> correctness via something like
> is(equal(float(1+ sqrt(3/2)*x),float(1+ sqrt(1.5)*x)));
> However, I am not quite sure what this is doing, as I don't exactly
> know how maxima is handling equality of floats and rationals (see above).
> Note that the whole issue is very similar to significant digits. Most
> users would expect 0.5 and 0.500 to be equivalent. Some, in particular
> physics authors, want loncapa to behave "scientific". The way to
> handle this discrepancy between "most users" and "scientific users" is
> to have a parameter by which you could switch of significant digits.
> If we can handle the issue maxima-wise we would need to have such a
> parameter instead of changing the current (limited) code of lonmaxima.
> I hope this helps to at least understand the trickiness of the issue.
> Maybe you could contact that maxima people to find out more on this.
>> Lon Mitchell
>> LON-CAPA-users mailing list