On 5/15/2013 5:44 PM, Robert Dodier wrote:
> On 2013-05-15, Bill Eaton <wpeaton4 at gmail.com> wrote:
>
>> It would be really handy if I could teach Maxima the various properties of
>> logarithms and inverse logarithms. My interest is base 10, but it seems that
>> it would be fairly generic for other integer bases.
> That's a useful & interesting idea, but it isn't easy in Maxima. One
> would have to create simplification rules for all properties of
> interest, perhaps observing the same flags as for the built-in log.
> It is likely that some interesting properties of built-in log are
> implicit in the way that it is treated by functions such as 'solve' or
> 'integrate'. The only way to get base-10 log to inherit those (short of
> reimplementing all the functions of interest) is to convert from base-10
> log to natural log, apply the function, and try to convert back
> afterwards.
I pretty much agree with this assessment.
>
> The claim about the natural log being more fundamental and therefore
> preferable is mistaken -- for one thing, Maxima has already quite a
> collection of conveniences and shortcuts.
There are undoubtedly such things, but there is fundamentally a tendency
to reduce
conveniences and shortcuts to a uniform internal representation.
Thus you might say that sqrt(%e) , 1/%e, exp(x) are all convenient
things and that
Maxima should represent them all. Yes indeed. But internally they are
((mexpt simp) %e ((rat) 1 2))
((mexpt simp) %e -1)
((mexpt simp) %e x)
So all of these are simplified by the same procedure, simpexpt. And
furthermore,
they look rather similar.
This choice of minimizing unnecessary diversity comes with some hazards, but
as an overall design decision seems to have held up pretty well.
So now when you suggest that in addition to log there should also be
another
function log10 and maybe log(base, argument) as a "convenience" it is a
a suggestion that fits with the design philosophy that has survived and
maybe
prospered.
(tangent: is there a difference between sqrt(x) and x^(1/2)
semantically?
I don't know. I have seen arguments that exp(x) is identical semantically
to the taylor series for exp, and that maybe %e^x has multiple branches...)
> More fundamentally,
> mathematics is just logic applied to some collection of assumptions.
I think that is an oversimplification.
> Maxima would be more powerful
um, how do you define power? Certainly not computational completeness.
> if it could be less invested in any
> given assumptions, and more flexible about introducing new ones which
> are suitable for a particular problem domain. As it stands, it's
> somewhat messy to extend or retract Maxima's mathematical knowledge.
> That is a bug, not a feature.
There is a history of trying to build computer algebra systems starting
with a language
and system that is completely bare, and contains only what you insert
into it by
means of rules. In these systems pattern matching or unification is the
main or
sole technique for computing new results (or another common goal,
proving theorems).
Such systems have not been successful as general computational engines,
though in the domain of automated proofs, they have the advantage of being
far more plausible because they are transparent.
While it is hardly a selling point to be "messy to extend or retract
..." it is
a consequence of the design that makes trade-offs between
size/speed/restricted domain/user-friendliness
on the one hand, and "generality with no preconceived assumptions"
on the other.
To see how to build a computer algebra system that starts by knowing
nothing, see Robert Fenichel's PhD dissertation on a program called
FAMOUS circa 1966.
http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-035.pdf
Duplicating its functionality inside Maxima should not be too challenging
given the detailed description. I do not know if the original (Lisp
1.5) code
is available.