Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: SourceForge.net <noreply@so...>  20090830 14:24:34

Bugs item #711885, was opened at 20030329 19:18 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=711885&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Rootscontract with imaginaries fails Initial Comment: q: ((SQRT(3)*%I+1)^(3/2)4*%I)/SQRT(SQRT(3)*%I+1) rootscontract(q) gives the error "SIGN called on an imaginary argument". The error happens within SIMPEXPT, which is not prepared to deal with (1/(SQRT(3)+1))^(1/2) in the form ((MEXPT) ((MEXPT SIMP) ((MPLUS SIMP) 1 ((MEXPT SIMP) 3 ((RAT SIMP) 1 2))) 1) ((RAT) 1 2)) Maxima 5.9.0 GCL 2.5.0 Windows 2000  >Comment By: Dieter Kaiser (crategus) Date: 20090830 16:24 Message: I had a further look at the problem. First, I think that ((MEXPT SIMP) ((MPLUS SIMP) 1 ((MEXPT SIMP) 3 ((RAT SIMP) 1 2))) 1) is a valid expression. It is generated by (%i20) (1/(1+sqrt(3))),radexpand:false; (%o20) 1/(sqrt(3)+1) The problem is the function sign, which can not handle complex expressions. This function is called by simpexpt via the routine noneg to determine the sign of the base, when the power is a even rational number. I think we have two possibilities: 1. Do a workaround for the function rootscontract. In the routine rtcfixitup we set radexpand to true and resimplify the expression. Expressions like sqrt(3) will be simplified to sqrt(3)*%i and the routine sign has no longer a problem. The routine rootscontract will work correctly. 2. Strengthen the routine noneg in simp.lisp in general. If we replace the call to sign in noneg with a call to $csign complex expressions are handled more completely (defun noneg (p) (member ($csign p) '($pos $pz $zero))) With this change we no longer have a problem and get (%i23) (1/(1+sqrt(3))),radexpand:false; (%o23) 1/(sqrt(3)+1) (%i24) sqrt(%); (%o24) 1/sqrt(sqrt(3)+1) I have run the testsuite and the share_testsuite with this change and I have got no problems. Only seven examples in rtest_integrate.mac have a different, but equivalent result. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090830 02:30 Message: I think it is not a problem of rootscontract, but a problem of the simplifier. The following user input generates the error: (%i1) sqrt(1/(sqrt(3)+1)),radexpand:false; sign: argument cannot be imaginary; found sqrt( 3)  an error. To debug this try debugmode(true); With radexpand set to false sqrt(3) does not simplify to sqrt(3)*%i but both expressions are valid user input. The problem is in simpepxt. In rootscontract the flag radexpand is set to false too. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060706 07:47 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20030815 05:59 Message: Logged In: YES user_id=588346 cf bug report 789059 The reason I submitted separate bug reports is that in this case, it may be that rootscontract is passing a malformed expression to rootscontract, while in 789059, it is clearly a general simplifier problem.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=711885&group_id=4933 