Using the same operator for string and number comparison naturally poses
the question of mixed types. Some possibilities:
(1) All numbers are smaller than all strings (or vice versa) -- I think
this is what orderlessp does
(2) Convert numbers to strings, then compare.
Some systems do this for *all* mixed operations, so that 3+"5foo" =>
"35foo" (concatenation)
Problem: 3 < 20 and 20 < "3", but "3" == 3; also "3e3" < "4e2", but
3e3 > 4e2
(3) Convert strings to numbers, then compare.
Some systems do this for *all* mixed operations, so that 3+"5foo" => 8
Problem: what do you do with "foo"? with "3foo"? with "foo3"? with
"4/4/2010"?
(4) Undefined/Error
Since Maxima can manipulate symbolic inequalities, it's especially
important that the system be consistent. I think the only consistent
possibilities are (1) and (4). I would say: if you want orderlessp
behavior, use orderlessp.
-s
On Mon, Feb 20, 2012 at 07:15, John Lapeyre <lapeyre.math122a at gmail.com>wrote:
>
> On 02/20/2012 08:38 AM, Robert Dodier wrote:
> > On 2/16/12, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> >
> >> Since strings are not (currently) in the domain of the Maxima comparison
> >> operators, this should either give an error or return 'unknown'. I
> think I
> >> know what Robert's preference would be....
>
> > string value. (At present, is("a" < "b") triggers an error, but that's
> > a separate problem; it should be true.)
>
> Just to keep the mailing list record straight, it triggers
> an untrapped lisp error (I filed a bug report). gcl even makes me
> think my RAM maybe got too hot ("memory may be damaged").
>
> I wonder about the history of why languages differ on how
> they implement string comparison, and where maxima fits in.
> Mathematica does not transform "a" < "b", but the user can
> redefine this to do a string comparison. perl, although
> untyped, uses different symbols from numeric for all string
> comparisons. I guess that was a choice, perhaps for efficiency.
>
> A related issue is, Mma gives Length[<string>] --> 0, maxima
> length(<string>) triggers a lisp error. You could argue
> that both Mma and maxima behavior are better than returning
> the string length because Part and part won't look inside a
> string. One could change length(<string>) to return the
> input form with no message. I imagine this would cause much
> confusion because many users would try it and be confused by
> the results.
>
> But, this stuff could be configurable, at different
> levels. The maxima function definition macro defmfun1 (in a
> version that I did not post yet) allows a runtime attribute
> to be set to choose whether argument checks trigger a maxima
> error or just print a message and return the form, like
> Mathematica.
>
> (%i2) nest(f,x,3);
> (%o2) f(f(f(x)))
> (%i3) nest(8,x,3);
>
> nest: Argument '8' is not a function in nest(8,x,3).
>
> (%i4) set_match_form(nest); /* maybe not a good name*/
> (%o4) true
> (%i5) nest(8,x,3);
> nest: Argument '8' is not a function in nest(8,x,3).
> (%o5) nest(8,x,3)
>
> By the way, many Mathematica users who write largish
> programs find debugging and controlling the number of
> messages difficult.
>
> P.S. The untrapped lisp error for length("dog") is better
> than the trapped error for length(1).
>
> (%i1) length("dog");
> Maxima encountered a Lisp error:
> The value "dog" is not of type LIST.
>
> (%i1) length(1)
> length: argument cannot be a number; found 1 /* what argument would be
> valid ? */
> -- an error. To debug this try: debugmode(true);
> /* The user has seen this 10^6 times, and decides not to take another
> crash
> course in lisp syntax and printing a stack trace */
>
> The reason the first kind of message is better is because it came from a
> generic
> error trapping mechanism where some thought or review of the message is
> possible. The second message is ad-hoc, written into the body of length().
>
> P.P.S. But, apparently '-1' is not a number if inflag is false;
> (%i1) length(-1);
> (%o1) 1
>
>
> -- John Lapeyre
>