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 <mailto: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 ?
It is a bit peculiar since 1/2 is printed
1
--
2
...
> * 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. And
one day some case which was previously an error is improved, so trapping
that case means you are not using solve to its full
capabilities. There are a number of areas in which trapping illegal
cases is a real loser. For example, evaluate the expression:
(3 + 1/( 1+1/0)). That could be "division by zero" or the much
more useful answer, 3.
> 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.
>
> 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.
> 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].
> 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.
RJF
>
> -s
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima