[LON-CAPA-users] formula response and maxima floating point numbers
Mon, 20 Sep 2010 03:48:43 +0200
that is a hard question. In general I am very strict about the
distinction between an exact number and a decimal approximation to it. I
have been trained that way and I am in a computer science department
(with all these modern strongly typed languages around).
I am trying to teach my students about this distinction (I am not saying
that I am successful).
I don't see any solution in not distinguishing between exact number and
float approximation. Any definition of equality of exact number and
float will be arbitrary, resulting in cases where students enter a too
coarse a float and hence being graded as incorrect. At the end it will
be harder to explain to the students when and why their inputs will be
considered as wrong rather than teaching them about the distinction of
exact number and float.
However, there are cases, where I do use sampling to avoid the trouble
under discussion. Placement tests for new student are such a case.
Descriptive statistics is another. Also, more often than not, I am
unhappy with maxima's somewhat sloppy handling of the issue (e.g. 2
So, in essence, I try to do my best in deciding whether I want the
result to be entered in an exact fashion, or whether it is o.k. to have
a float approximation. Again, I am not saying that I am successful at this.
On 16.09.2010 17:06, Lon H Mitchell wrote:
> Hi Peter,
> 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
> LON-CAPA-users mailing list
Ostfalia Hochschule für angewandte Wissenschaften
Salzdahlumer Str. 46/48
Fon: ++49 5331 939 31540