On Fri, Sep 27, 2013 at 2:08 PM, Richard Fateman <fateman at gmail.com> wrote:
> On 9/27/2013 9:17 AM, Stavros Macrakis wrote:
>
> ...
>
> On Fri, Sep 27, 2013 at 11:42 AM, John Lapeyre <lapeyre.math122a at gmail.com
> > wrote:
>
>> The main counterargument I can think of is: It would take a lot of
>> these small changes before it could be very useful. And in the
>> meantime, the complexity of the code is increased without benefit.
>> It's a reasonable argument. If it were up to me, I'd put it in. But,
>> I have no interest in persuading people to put it in the main branch.
>>
>
> I have two counterarguments:
>
> * We shouldn't document Maxima as supporting Lisp rationals/complexes
> until our support is believed to be comprehensive (modulo bugs); until we
> do that, what value does partial support have?
>
> We don't have to advertise it. There is a tradition that when an
> additional case can be
> handled by adding code that doesn't break anything, we add it. That is,
> we could
> signal an error when attempting to display
> ?/(1,2), the common lisp rational number 1/2, but why bother? Why
> not print 1/2 ?
>
I'm not sure about this "tradition".... You're saying you're happy with
this?:
(%i1) ?/(1,2); <<< in a realistic scenario, this would be a call to some
Lisp function I loaded
(%o1) 1/2 <<< by printing it out, Maxima confirms that this is an OK
number
(%i2) 4^%; <<< how can this go wrong?
Maxima encountered a Lisp error: <<< but it is not an OK number
The value 1/2 is not of type LIST.
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
The user reasonably expects that 4^(1/2) should be well defined. Why
would s/he expect that the problem was with line %i1? Even worse of course
if it was xx:?/(1,2) and xx was used 30 lines later.
You should trap illegal cases whenever you see them to prevent users from
running into cases where we *silently* return incorrect answers.
This is a good principle, but we often can't follow it. That is, a command
calls "solve" not knowing if solve can do the problem.
Not being able to solve the problem is different from getting malformed
input.
(...)
Throwing errors isn't so bad -- at least the user knows that there is no
result. The case that worries me is actually returning an answer which is
incorrect.
The general approach in our case is of course to return an unevaluated
answer, like if(a<b) ... in case we don't know anything about
the values of a and/or b. or an unsolved equation from solve.
So you're suggesting then that the correct result for 4^(1/2) (where 1/2 is
a Lisp rational) should be 4^(1/2)?
I don't object to someone going through the code and making it Lisp
rational/complex clean. But I don't think it has all that much value.
There's potentially more at stake here, but I'm hesitant to push it. Oh
well, here's the potential. There are gobs of other foreign
things out there, like MPFR library (comparable to bigfloats) whose objects
probably look like atoms. Right now they
can be brought in to Maxima, at least on some Lisp platforms by wrapping
them as ((mpfr) <pointer to something>) and
unwrapping them when doing operations. There are also libraries for
numerical intervals, .. whatever.
If Maxima were more fluent in conversing with other types, it might be
nice. This could be done by object dispatches.
Alternatively, we can check for and wrap/unwrap each thingee. But the
object approach means we can add new
thingees with relatively independent code. At least sometimes.
Exactly what I'm talking about.
I'd think it would be much more valuable to go through the whole
codebase and enable support for arbitrary numerical objects such as bfloats
(which aren't supported in CREs), intervals, etc.
If we did object-oriented numerical coding, that would work.
http://www.cs.berkeley.edu/~fateman/generic
has a bunch of code, but also includes as objects quad-double floats,
intervals, and strange things
like lisp programs f(x) that compute both f(x) and f'(x) [automatic
differentiation].
Yes.
That does require a bit of design work since not all objects support all
operations (for example, interval comparison doesn't support trichotomy).
Maxima doesn't support intervals, though I think I know how it should. This
is probably not as big a problem regarding comparison as
whether to use assumptions. (e.g. Is (a>b) ? not obviously so, but
should I spend the time to prove this from assumptions and current
bindings?
)
I don't think this is that huge a task, but it does require careful
attention to the logic (e.g. a function assumes that an atom can't be
complex because it is not $%i).
I think the way to approach this is to start at the bottom and see if we
can make use of common lisp
functionality on common lisp objects like numbers. Not everything that
common lisp does is good
for us (sin 1/2) comes out as a float. However (+ 1/2 1/3) works. And
we can define a generic
two-arg-+ to add any 2 numeric types.
I
think we're agreeing.
RJF
-s
_______________________________________________
Maxima mailing listMaxima at math.utexas.eduhttp://www.math.utexas.edu/mailman/listinfo/maxima
_______________________________________________
Maxima mailing list
Maxima at math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima