From: Simon W. <si...@ge...> - 2011-08-11 08:22:03
|
Hi there, is it possible to combine log10s like the switch combinelogs does for log? eg. log10(20)+log10(50) should get log10(1000) or better 3. I tried to add a rule, but let {log10(~a)+log10(~w) => log10(a*w)} yields to the error message "***** Unmatched free variable(s) ~w". Does anybody have an idea how to solve that problem? Thank you, Simon |
From: Arthur N. <ac...@ca...> - 2011-08-11 08:51:49
|
If you search the Reduce sources for !*combinelogs you find that it triggers code in alg/logsort.red where the actual work is done. Right now that checks for "log" and is unaware of "log10". Bu that code gives and idea of how much is involved - it is aroound 140 lines. It seems plausible to me that the entrypoint to it (I think I can only see clogsq!* being called from elsewhere?) could be arranged so that the rest of teh code in logsort.red was parameterised with an extra arg that was going to be "log" or "log2" or "log10" and then clogsq!* did three passes to combine each of the three sorts of logs. That should be fairly easy and if most people do not have combinelogs switched on most of the time it can not hurt performance for them. As a SHORT TERM HACK if geogebra wants to see if that would serve them maybe they just edit log -> log10 in that file, rebuild their reduce image and see if that does the trick? That would obviously lose combining log while it put in combining log10, but hey! Are any people ever going to have views about combining say (log x + log10 y) ??? The numeric evaluation log10(1000) => 3 is a separate issue, but you are going to have to be inventine if you want that reduction made and log10(20) not turned into 1.3010300.... Does anybody have a a wonderful idea about that? I guess I would observe that sqrt(4) => 2 but sqrt(3) remains unchanged - and that is done by sqrt having a 'simpfn that carefully tests for options and cases. And if one went that way with logs one could be forced into wanting a switch that caused log10(1000) to be left as is rather than instantly turned into 3. Switch proliferation is bad too! A 'simpfn for log10 that merely checked for 10, 100, 1000, 10000 etc and if found returned an integer would not be a lot of code... Arthur On Thu, 11 Aug 2011, Simon Weitzhofer wrote: > Hi there, > > is it possible to combine log10s like the switch combinelogs does for log? > > eg. log10(20)+log10(50) should get log10(1000) or better 3. > > I tried to add a rule, but let {log10(~a)+log10(~w) => log10(a*w)} yields to > the error message "***** Unmatched free variable(s) ~w". > > Does anybody have an idea how to solve that problem? > > Thank you, > Simon > |
From: Rainer S. <rai...@gm...> - 2011-08-13 16:19:13
|
On Thu, 11 Aug 2011 at 09:51 +0100, Arthur Norman wrote: > The numeric evaluation log10(1000) => 3 is a separate issue, but you are > going to have to be inventine if you want that reduction made and > log10(20) not turned into 1.3010300.... > > Does anybody have a a wonderful idea about that? I guess I would observe > that sqrt(4) => 2 but sqrt(3) remains unchanged - and that is done by sqrt > having a 'simpfn that carefully tests for options and cases. And if one > went that way with logs one could be forced into wanting a switch that > caused log10(1000) to be left as is rather than instantly turned into 3. > Switch proliferation is bad too! A 'simpfn for log10 that merely checked > for 10, 100, 1000, 10000 etc and if found returned an integer would not be > a lot of code... There is the code in alg/simplog.red, which handles log but not log10 (nor logb) - which it should do, in my opinion. There is even a procedure simplogn for logs of integers, but it is called only if expandlogs in on and precise is off (which looks wrong to me: precise shouldn't matter for positive integer arguments). As it is now, the code in simplogn factors the log's argument and changes log(1000) to 3*(log(5)+log(2)) - correct but not very useful for log10. Ie, one needs to check for prime factors 2 and 5, recombining them to 10 as necessary. Rainer |
From: Rainer S. <rai...@gm...> - 2011-08-21 13:02:15
|
Regarding the simplification of log10(1000): this will now always simplify to 3. log10 of an integer that is not an exact power of 10 simplifies only with the switch EXPANDLOGS on, e.g., OFF EXPANDLOGS; LOG10(2000); => LOG10(2000) ON EXPANDLOGS; LOG10(2000); => LOG10(2) + 3 Rainer |