"Enrique Perez-Terron" <enrio at online.no> writes:
> 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 have looked into solve some time ago, and IIRC it is as follows: First
all reals are replaced by rationals. Then solve transforms (part of) the
equation to something like (a^t)^n=b, or a^(t*n)=b, where n is a natural
number. It then generates a list of solutions with the log(b)/log(a) as
the real part, and the logs of all the complex n-th roots of 1 as
imaginary parts. Essentially the imaginary parts are k*2?i/n for
0<=k<n. Solve generates all of them, whereas %solve gives them in
symbolic manner with the k as a free variable. If the solution of t lies
in the microsecond range (supposing it is a time) then n is in the order
of a million. It really gets unmanageable when t is in the nano- or
picosecond range.
--
Piet van Oostrum <piet at vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]