> This problem has been discussed at various times, under the name
> 'warting problem' among others. This is a issue that has to be resolved
> somehow,
> as more code gets written in maxima, instead of lisp where its easier to work
> around.
I don't understand why you think it would be better to write in maxima.
After all, programs written in lisp don't have this problem. it is a
problem of the maxima language. I do agree however that the semantics of
the language really should be changed.
> > 1 Exit SOLVE [u = (1/(l*t+t)-t/(l*t+t))^(1/l)]
> > 1 Enter SOLVE
> > [-((l*((-(t-1)/((l+1)*t))^(1/l)+1)+1)*t-l*(-(t-1)/((l+1)*t))^(1/l))/(l+1),t]
> > 1 Exit SOLVE [t =
> > l*(-(t-1)/((l+1)*t))^(1/l)/(l*(-(t-1)/((l+1)*t))^(1/l)+l+1)]
> > (D9) [[u = (-(t-1)/((l+1)*t))^(1/l),
> > [-((l*((-(t-1)/((l+1)*t))^(1/l)+1)+1)*t-l*(-(t-1)/((l+1)*t))^(1/l))
> > /(l+1)]]]
> >
> > The second item of the solution does not make t explicit, although solve
> > did...
> >
>
> No, t is still implicitly defined. The solve of the commercial macsyma cannot
> solve this either.
You are very right, sorry. Bad news for me though, because there is an
explicit solution (maple finds it at least, I didn't check)
> > 2. second bug (I think this is known, but I'm not sure)
> >
> > the second time solver is invoked, it is silently assumed that l is an
> > integer. I think this assumption should be removed...
> >
>
> This has to do with solve setting the integer property of L, when it asked.
> It is the way maxima works. You can remove this property with remove.
OK (I knew that I can get rid of the property) However, my feeling is that
it should be as follows: If the property of L is set *before* a program is
invoked, it should use the property and should not ask. If the property is
set *during* the invocation of a program, there should be a switch that
controls whether properties should be removed or not. This "feeling" of
mine might be complete rubbish...)
> Is there something you cant work around for now?
yes, the solve problem and the feeling that is more probable that a result
is wrong than that it is right. Sorry. (and thank you for your help)
I wonder whether the serious (= math) bugs on the buglist will be cleaned
up in the near future. But considering the struggle to get taylor right, I
can't believe this.
Martin