Glad we are agreeing, mostly.
As for 4^(1/2), regardless of what kind of 1/2, there are two square
roots.
Without some other context, it might make sense to leave it alone.
As an example, (z^2)^(1/2) in Mathematica just stays the same.
I think that is better than what Maxima gives, which is abs(z).
one could patch simpexpt so that a^b works by converting b to ((rat) ...)
just as 4 ^rat(1/2) or 4^poissimp(1/2) works.
But the strategy for simplifying functions can be based on object dispatch.
That is, expt(<type_of_a>, <type_of_b>) is defined.
What doesn't work well with object dispatch is
simplify(2+rat(1/2)+x+3+sin(x)+ (2*x+3)^2)...
What kind of object is the key to this?.
I'm ok with giving error messages for meaningless or malformed input, if we
can figure that out.
Who's gonna do this?
RJF
On 9/27/2013 3:18 PM, Stavros Macrakis wrote:
> On Fri, Sep 27, 2013 at 2:08 PM, Richard Fateman <fateman at gmail.com
> <mailto: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 <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 ?
>
>
> 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
> <http://www.cs.berkeley.edu/%7Efateman/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 list
>> Maxima at math.utexas.edu <mailto:Maxima at math.utexas.edu>
>> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu <mailto:Maxima at math.utexas.edu>
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>