Stavros has provided a solution, but there is an underlying issue that
comes up
in many guises. Essentially, people have a view of some topic in
mathematics
and wonder why Maxima doesn't have the same view.
Sometimes it is that Maxima's view is from a more advanced or sophisticated
perspective. The people with the question assume that (say) square root of
a negative number is an error because they have not heard of complex
numbers.
Or that sin/cos/tan should be in degrees because they haven't heard of
radians.
Or log of a negative number because they haven't heard of branch cuts.
It is possible to try to make Maxima do something in an "elementary" way,
even if that way is fundamentally flawed. What is better sometimes is
for the
questioner to be educated just a bit as to why Maxima was written the way
it was.
In this case the rationale for base 10 logarithms is not exactly flawed,
just
that doing symbolic manipulations with it is deprecated for good reason.
Occasionally people find something in Maxima that can be improved by
taking another view -- one that is more applicable or general or "correct".
We are lucky if Maxima can be simply "fixed" to include this finding and
still work as expected in old cases, but that is progress..
On 5/14/2013 11:07 PM, Stavros Macrakis wrote:
> Maxima's knowledge of the properties of log is not localized, but
> spread out over various subsystems, including numerical evaluation,
> solve, taylor series, integration, differentiation, limits,
> simplification, logcontract, etc.
>
> Once you get into calculus operations, it becomes clear why log base
> /e/ is called "natural" -- for example, diff(log10(x),x) =>
> 1/(x*log(10)), but diff(log(x),x)=>1/x.
>
> A simple approach is to convert log10 to log, perform the calculation,
> then convert from log back to log10, like this:
>
> log10_to_log(ex) := subst(lambda([x],log(x)/log(10)),'log10,ex)$
> log_to_log10(ex) := subst(lambda([x],log10(x)*log(10)),'log,ex)$
>
> For example,
>
> eq: log10(x)+3=log10(x+1);
> eq1: log10_to_log(eq);
> load(to_poly_solve)$ <<< good for equations with multiple logs
> %solve(eq1,x);
> => %union([x = 1/999])
>
> In this case, there aren't even any logs in the result, so no
> conversion back to log10 is necessary.
>
> In general, the log_to_log10 part should be a bit more elaborate, so
> that log10(100)=>2 and so on.
>
> -s
>
>
> On Tue, May 14, 2013 at 5:46 PM, Bill Eaton <wpeaton4 at gmail.com
> <mailto:wpeaton4 at gmail.com>> wrote:
>
> I have an interest in being able to do useful symbolic and numeric
> calculations with logarithms in base 10. I know there is a contrib
> module called log10. It works fine for doing numeric calculations,
> but doesn't behave how I'd like for generic symbolic manipulation.
> For example the natural log can solve for x:
> (%i1) solve(y=log(x),x);
> (%o1) [x=%e^y]
> But log10 gives this:
> (%i2) solve(y=log10(x),x);
> (%o2) [log10(x)=y] /* I'd prefer to get x=10^y */
> There are many of other examples of symbolic manipulation of log10
> where log shows up in the answer. I'd really like to leave log out
> of it altogether.
> 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.
> I don't even know where to start, but suggestions are welcome.
> Thanks in advance,
>
> Bill Eaton
>
>
> _______________________________________________
> 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
> http://www.math.utexas.edu/mailman/listinfo/maxima