On Thu, 13 Dec 2012 12:44:41 +0100, Jaime Villate <villate at fe.up.pt> wrote:
> On 12/13/2012 10:38 AM, Enrique Perez-Terron wrote:
>> realp(x) := if imagpart(x) = 0 then true else false$
>> solution: solve(...)$
>> sublist(solution, realp)
> Thanks for that idea.
> I think realp() needs a change:
>
> (%i8) realp(x) := if imagpart(rhs(x)) = 0 then true else false$
Thanks, you are right. Of course, the list is a list of equations 't=xxx'.
I tried only with a list of numbers, my bad :)
> In any case, by changing the units used for t one can make the length of
> the list obtained by solve grow to thousands taking too long for solve
> to finish. Of course, this is a trivial example that could be solve by
> taking log on both sides of the equation but this is only to illustrate
> a problem that arises in more complicated cases.
Yes, I think it is important to find out why the number of solutions found
varies in this way with scale. Unfortunately I do not have the time to
explore the workings of the "solve()" function.
I might try to guess, though. The equation has infintely many solutions in
the complex plane, so perhaps the solve() function just lists all
solutions with absolute value (modulus) within some bound.
Since the solution formally is
t = 50175/10 * (log(2) + 2n%pi%i)
for n in the set of integers, where 50175/10 is the scale factor, when
this scale factor is larger, fewer solutions are within the bound. Notice
that this scale factor is the mulitplicative inverse of the scale factor
in the original equation. When you measured in microseconds, the solution
was 5017500 * log(2), which gives fewer solutions within the hypothetical
bound.
Hm, if this is the case, I would want a "solve" functions that treats 'n'
above the same way as integration constants, even if its range is only the
integers. I am not a longtime user of Maxima, so I don't know if there are
some flags that control this behavior. Maybe somebody else knows.
-Enrique