I think you should use the built in assumptions on the variables (such
as is_real, is_positive, and so on). You can return a symbol that has
a real assumption on it if you need that. Other than that, I would
use re() and im() to access the imaginary parts, and the sign()
function to represent the sign of an expression. This is what other
CAS's seem to do, such as Maple.
I am not familiar with the quartic solution, but as a general example,
if x = Symbol("x"), which is complex by default, then you could do
re(x) + im(x)*I to obtain the real and imaginary parts (see also
expand(x, complex=True) ), and sign(re(x))*abs(re(x)) +
sign(im(x))*abs(im(x))*I to separate those parts into positive part
times sign (is there an function that does this anyone?).
Like I said, I am not totally familiar with what you are saying, but I
hope this gives you some good pointers.
Aaron Meurer
On Jul 17, 2009, at 1:14 AM, smichr wrote:
>
> I have found that the quartics routine can return two sets of 4 roots
> (that can be selected by exchanging the signs in A and B of the
> routine). The present set returned is correct if there are 4 real
> roots or if there are 2 real and all the coefficients are real. The
> other set (according to the tests that I have done so far) is needed
> for all other cases.
>
> This poses a problem that I am interested in getting some opinions:
>
> 1) to maintain backward compatibility I can make the arguments be (f,
> sign=-1) but is that
> wise? One really should be selecting which set is desired.
>
> 2) If the number of real roots can't be determined then I should send
> back the solution set with a symbol replacing the sign. Perhaps this
> is the answer to (1), too: if no sign is specified then send back a
> solution set with a symbol for the sign. If the user had sent a
> polynomial for which the number of real roots could be determined,
> then the sign will be known. But if they don't they will get an answer
> with a new symbol in it for the sign. The question is, what type of
> symbol should be used, and what would be a good name (sign,
> sign_1_if_cmplx_roots_neg1_if_all_real, ...)? If I use a regular
> symbol the user can access it in the sending code but there might be a
> conflict with the user's symbols. That can be avoided by using a dummy
> symbol, but then how will the user do a subs() to specify the sign?
>
> ###
>>>> def test(a,b):
> ... return a+Symbol('s',dummy=True)*b, a+Symbol('s')*b
> ...
>>>> f1, f2 = test(1,2); f1, f2
> (1 + 2*_s, 1 + 2*s)
>>>> f2.subs(s,1)
> 3
>>>> f1.subs(Symbol('_s'),1) #how do I replace the dummy with 1?
> 1 + 2*_s
>>>>
>>>> f1, f2 = test(s,2); f1, f2 #conflicting variable 's' combines
>>>> with the one in test()
> (s + 2*_s, 3*s)
> ###
>
> /c
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com
To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sympy?hl=en
-~----------~----~----~----~------~----~------~--~---
