[Maxima-bugs] [ maxima-Bugs-660948 ] simplification of exp(%i*...) From: - 2003-01-02 04:23 ```Bugs item #660948, was opened at 2003-01-01 23:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simplification of exp(%i*...) Initial Comment: There are some weirdnesses and inconsistencies in the simplification of exp(%i*...). First, let's look at the case exp(%i*%pi*q). If q is (m/n) with n in {1,2,3,4,6}, it returns a solution in rationals and radicals, e.g. for q=11/3, we get 1/2-SQRT (3)*%I/2. For other n's, it reduces q to the range (-1,+1]. If q is a float which is exactly m/n as above, it rationalizes it: exp(%i*%pi*.25) => SQRT(2)*%I/2+SQRT(2)/2 I am not comfortable with this, because a floating point number is supposed to be an approximation, and we're getting an exact result here. It does the same thing for x^1.0 and (x^3)^float(1/3), though not for x^0.5 or x^2.0 or (x^3)^float(5/3). However, it does a weird thing if q is very near m/n: exp(%i*%pi*.166666666) => (%I/2+SQRT(3)/2)*%E^-(6.666666663157628E-10*%I*% PI) Of course this is accurate, but it seems pointless and bizarre. It is also inconsistent in its handling of purely floating exponents: exp(%i*%pi*.333) => %E^(0.333*%I*%PI) (OK) but exp(%i*%pi*5.333) => %E^-(667*%I*%PI/1000) (why rationalized here?) Now let's look at the case exp(%i*q). If q = 1.0 exactly, it acts as though q=1: exp(%i*1.0) => %e^%i. This follows the (in my opinion anomalous) case x^1.0 => x, as above. I don't know why this should be; after all, 2^1.0 => 2.0, not 2. And for other floats, it does no reduction at all to (-pi,pi]: exp(%i*ev(%pi,numer)) => %E^(3.141592653589793*%I) exp(%i*ev(%pi*100,numer)) => %E^(314.1592653589793*%I) exp(%i*300.0) => exp(%i*300.0) All this needs to be made consistent and clear. In my opinion, floats should NEVER be coerced to exact numbers, unless the user asks for it (e.g. by converting to Rat form). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-660948 ] simplification of exp(%i*...) From: SourceForge.net - 2006-07-01 06:16 ```Bugs item #660948, was opened at 2003-01-01 21:23 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&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 - Complex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simplification of exp(%i*...) Initial Comment: There are some weirdnesses and inconsistencies in the simplification of exp(%i*...). First, let's look at the case exp(%i*%pi*q). If q is (m/n) with n in {1,2,3,4,6}, it returns a solution in rationals and radicals, e.g. for q=11/3, we get 1/2-SQRT (3)*%I/2. For other n's, it reduces q to the range (-1,+1]. If q is a float which is exactly m/n as above, it rationalizes it: exp(%i*%pi*.25) => SQRT(2)*%I/2+SQRT(2)/2 I am not comfortable with this, because a floating point number is supposed to be an approximation, and we're getting an exact result here. It does the same thing for x^1.0 and (x^3)^float(1/3), though not for x^0.5 or x^2.0 or (x^3)^float(5/3). However, it does a weird thing if q is very near m/n: exp(%i*%pi*.166666666) => (%I/2+SQRT(3)/2)*%E^-(6.666666663157628E-10*%I*% PI) Of course this is accurate, but it seems pointless and bizarre. It is also inconsistent in its handling of purely floating exponents: exp(%i*%pi*.333) => %E^(0.333*%I*%PI) (OK) but exp(%i*%pi*5.333) => %E^-(667*%I*%PI/1000) (why rationalized here?) Now let's look at the case exp(%i*q). If q = 1.0 exactly, it acts as though q=1: exp(%i*1.0) => %e^%i. This follows the (in my opinion anomalous) case x^1.0 => x, as above. I don't know why this should be; after all, 2^1.0 => 2.0, not 2. And for other floats, it does no reduction at all to (-pi,pi]: exp(%i*ev(%pi,numer)) => %E^(3.141592653589793*%I) exp(%i*ev(%pi*100,numer)) => %E^(314.1592653589793*%I) exp(%i*300.0) => exp(%i*300.0) All this needs to be made consistent and clear. In my opinion, floats should NEVER be coerced to exact numbers, unless the user asks for it (e.g. by converting to Rat form). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-660948 ] simplification of exp(%i*...) From: SourceForge.net - 2009-07-25 22:12 ```Bugs item #660948, was opened at 2003-01-02 05:23 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&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 - Complex Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simplification of exp(%i*...) Initial Comment: There are some weirdnesses and inconsistencies in the simplification of exp(%i*...). First, let's look at the case exp(%i*%pi*q). If q is (m/n) with n in {1,2,3,4,6}, it returns a solution in rationals and radicals, e.g. for q=11/3, we get 1/2-SQRT (3)*%I/2. For other n's, it reduces q to the range (-1,+1]. If q is a float which is exactly m/n as above, it rationalizes it: exp(%i*%pi*.25) => SQRT(2)*%I/2+SQRT(2)/2 I am not comfortable with this, because a floating point number is supposed to be an approximation, and we're getting an exact result here. It does the same thing for x^1.0 and (x^3)^float(1/3), though not for x^0.5 or x^2.0 or (x^3)^float(5/3). However, it does a weird thing if q is very near m/n: exp(%i*%pi*.166666666) => (%I/2+SQRT(3)/2)*%E^-(6.666666663157628E-10*%I*% PI) Of course this is accurate, but it seems pointless and bizarre. It is also inconsistent in its handling of purely floating exponents: exp(%i*%pi*.333) => %E^(0.333*%I*%PI) (OK) but exp(%i*%pi*5.333) => %E^-(667*%I*%PI/1000) (why rationalized here?) Now let's look at the case exp(%i*q). If q = 1.0 exactly, it acts as though q=1: exp(%i*1.0) => %e^%i. This follows the (in my opinion anomalous) case x^1.0 => x, as above. I don't know why this should be; after all, 2^1.0 => 2.0, not 2. And for other floats, it does no reduction at all to (-pi,pi]: exp(%i*ev(%pi,numer)) => %E^(3.141592653589793*%I) exp(%i*ev(%pi*100,numer)) => %E^(314.1592653589793*%I) exp(%i*300.0) => exp(%i*300.0) All this needs to be made consistent and clear. In my opinion, floats should NEVER be coerced to exact numbers, unless the user asks for it (e.g. by converting to Rat form). ---------------------------------------------------------------------- >Comment By: Dieter Kaiser (crategus) Date: 2009-07-26 00:12 Message: I think the problems of this bug report are no longer present. These are the results for the given examples: No rationalizing of float numbers: (%i2) exp(%i*%pi*0.25); (%o2) %e^(0.25*%i*%pi) No simplification to an exact result: (%i3) x^1.0; (%o3) x^1.0 (%i4) (x^3)^float(1/3); (%o4) x^1.0 More examples for float numbers: (%i5) exp(%i*%pi*0.166666666); (%o5) %e^(0.166666666*%i*%pi) (%i6) exp(%i*%pi*5.333); (%o6) %e^(5.333*%i*%pi) The exp function with a complex float argument evaluate numerically: (%i7) exp(%i*1.0); (%o7) .8414709848078965*%i+.5403023058681398 (%i8) exp(%i*ev(%pi,numer)); (%o8) 1.224500708041116E-16*%i-1.0 (%i9) exp(%i*ev(%pi*100,numer)); (%o9) 1.961926030129856E-15*%i+1.0 (%i10) exp(%i*300.0); (%o10) -.9997558399011495*%i-.02209661927868395 Closing this bug report as fixed. Dieter Kaiser ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&group_id=4933 ```