Well, I'm inclined to say that numbers and strings are incomparable
under "<", so is(1 < "a") should be an error (4 below).
The convenience of (2) or (3) is greatly outweighed by the confusion
they'll cause. (I know you are not advocating these, Stavros.)
Not sure about (1). It's not too bad, although the choice of strings
before numbers or numbers before strings is arbitrary and therefore
makes it a little more difficult to understand.
I guess I don't see a reason that all kinds of object in Maxima
should be comparable under "<". So we need not try too hard
to make strings and numbers comparable.
best
Robert Dodier
On 2/20/12, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> 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