On 8/1/2011 10:34 PM, Robert Dodier wrote:
> On 8/1/11, Stavros Macrakis<macrakis at alum.mit.edu> wrote:
>
>> format1 (called by subst, part, displa, etc.) does
>> conversions like ((mexpt) x -1) => ((mquotient) 1 x); it could equally well
>> transform #c(1 2) => ((mplus) 1 ((mtimes) 2 $%i)).
> Yeah, that makes sense to me.
matching programs do not call format1. I never use part if time is of
any concern.
Inpart, which does not call format1, is much much much much faster. I
was not aware that
subst called format1. (It doesn't show on tracing . maybe you are really
talking about a program
with a different name, not format1?)
> In general, I'd like to see Maxima take a laissez-faire attitude
> toward Lisp complexes and rationals.
> It's OK if Maxima doesn't know what to make of sin(z) where z is
> a Lisp complex or rational, but it's not OK if it triggers an error.
I agree. But I think that is not the point here.
The point here is how many different ways should maxima maintain and
continue to maintain in
its processing through simplification, solving, matching, etc. for
representing the same abstract
concept. ((mquotient) 1 2) ((mexpt) 2 -1) ((rat) 1 2), common lisp
1/2 are all the same number. All are converted to
((rat) 1 2).
allowing #c(1 2) as a special form for a+bi where a,b are both common
lisp reals can be easily handled if the first time it is encountered it
is converted to something that already exists. Doing otherwise requires
a huge amount of rewriting of code, and probably a decade of debugging.
If the parser never produces #c(1 2), and it is not produced as a value
by any maxima program, it is
not likely that cosine will ever see it. Allowing 'other' lisp objects
to be treated nicely by cosine (if you mean
a nice error message) is OK. Actually computing cosines is another
matter. What about CL arrays?
defstructs? CLOS objects? files? Mathematica, for example, allows
Cos[array].
If we spread "CL complex is OK" in as many places as we can find, I
think it will merely make processing slower for everyone, and buggier
for people who do use them. It will only slow things down a little if
you check for CL at the entry to cosine (etc) with numer:true. I suspect
you will have to diddle with bigfloat cosine (etc) as well...
>
> I claim the correct mathematical approach to unknown objects
> is to leave them alone; that way an interested party can devise
> the functions or identities or whatever to handle them.
For Maxima to operate as usual, the unknown objects must have a certain
form:
((objectname simp) other stuff goes here) or these objects might be OK
if they
are viewed as "atoms" (e.g. pathnames?) and fall out in the processing,
> Triggering an error is essentially a declaration that there can
> never be a way to handle the objects in question.
> Maybe in some limited cases, an error is appropriate.
> But that certainly shouldn't be the option of first resort.
Yes, the issue here is what to do with Lisp complex numbers if they are
not treated as foreign objects.
They happen to pass the "numberp" test so they are not entirely foreign.
If they didn't, they would just be atoms like x, y,,z.