# HP Forums

Full Version: Complex solve BUG FW 2016 04 14 (10077)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I have to solve the following equation for variable x:

eqn: (C1/C2)-(C3/C2)*C4*(1-i*tan(acos(C5)))/(3*conj(x)) - x = 0

C1 to C5 are constant numbers, either real or complex values.

Example:
C1:=231.0e3
C2:=0.91+i*0.012
C3:=13.2+i*97.55
C4:=400.0e6
C5:=0.9

With these parameters the equation has two solutions (e.g. solved with Matlab)
x1=(60.22-i*52.95)*1e3
x2=(192.21-54.69)*1e3

After updating to FW 10077 it is no longer possible to solve this equation using "cSolve" or "solve" in CAS environment or in program. I have tried with various settings, but no success. The result is always: []

This is especially annoying since there was absolutely no problem to solve the equation before updating the firmware. I need to solve this equation with various parameters C1 to C5 within a very large program that took me very long time of development. With this problem I can no longer use the software (Grrrr). Before the firmware update everything was fine and Prime solutions always were in line with Matlab etc.

Interestingly, when C2 is real and not complex, it seems to work, at least in some cases.

cSolve and solve have obviously a bug with the new firmware. Any idea??

Regards
Maro
if you type:

csolve(((c1/c2)-((c3/c2)*c4*(1-i*tan(acos(c5)))/(3*conj(x)))-x) = 0,x)

with lower case c1 thru c5 you get:

{60220.1785789-52949.8773819*i,192206.543606-54690.3569208*i}

edited to add some i's that didn't get copied
(05-19-2016 06:22 PM)Maro Wrote: [ -> ]C1 to C5 are constant numbers, either real or complex values.

C1-C5 are the data columns in the 2-var stat application. Previously, things like this were allowed in programs but that created a lot of potential pitfalls and issues when sharing programs with others. We made it tighter in terms of not allowing you to create variables that are named after specific system functions/variables/etc. I suspect this is what happened to your program. Should someone have used your program with the stat app open, strange results would have happened I think.

Just rename to c1, c2, etc and I suspect you should be good again.
when changing C1-C5 to lower case c1-c5 I still have the same problem. Neither in CAS nor in a program it works. If c2 is complex the result is still []. Only if I change c2 to real value c2:=0.91 I get two solutions:

x1=193.89e3-i*52.616e3
x2=59.956e3-i*52.616e3

BTW, in my original program the constants are not named c1-c5. I only used that here to have short names. In the original program the constant have some names that are definitely not used as specific system variables.

I have nothing changed with the program, just made a FW update and since then the program fails in finding solutions ...
(05-19-2016 08:57 PM)Maro Wrote: [ -> ]I have nothing changed with the program, just made a FW update and since then the program fails in finding solutions ...

Mind either sending me a PM with the program (or and email to calchelp at_ hp.com), or posting it if you don't care if anyone else sees it?
I have made a short test program for this and have tried it also on the emulator. It is really strange since on the emulator indeed it works with c2 = complex. On the Prime hardware the same test routine doesn't work with c2 = complex (same settings).

Edit: the test routine fails with c2=complex on both, hardware version A and hardware version C; exactly the same behavior as original program.

Code:
```EXPORT TEST_Solve() BEGIN LOCAL c1,c2,c3,c4,c5; LOCAL Result,temp; c1:=231.0ᴇ3; c2:=0.91+i*0.012; //c2:=0.91; c3:=13.2+i*97.55; c4:=400.0ᴇ6; c5:=0.9; temp:="((c1/c2)-(c3/c2)*c4*(1-i*tan(acos(c5)))/(3*conj(x))-x)=0"; Result:=CAS.cSolve(EVAL(temp),"x"); END;```
If you are using csolve, then it's a good idea to run it inside the CAS. The reason of your failure might be that conj(x) normally evals to x (because variables are assumed to be real), csolve has special evaluation rules to prevent evaluation of conj(x) to x, this is fragile and perhaps does not work from Home EVALuating a string.
Code:
``` c1:=231.0e3; c2:=0.91+i*0.012; c3:=13.2+i*97.55; c4:=400.0e6; c5:=0.9; csolve((c1/c2)-(c3/c2)*c4*(1-i*tan(acos(c5)))/(3*conj(x))-x=0);```
(05-20-2016 05:18 AM)parisse Wrote: [ -> ]If you are using csolve, then it's a good idea to run it inside the CAS. The reason of your failure might be that conj(x) normally evals to x (because variables are assumed to be real), csolve has special evaluation rules to prevent evaluation of conj(x) to x, this is fragile and perhaps does not work from Home EVALuating a string.

I get the same problem when trying it inside the CAS without string evaluation, just in CAS on the command line: it works with c2=real, it doesn't work with c2= complex and I never had any problems with conj(x) before the FW update. If conj(x) was the problem, then I would expect a problem also with c2=real, because the solutions for x are in general complex numbers for this equation
(05-20-2016 05:18 AM)parisse Wrote: [ -> ]
Code:
``` csolve((c1/c2)-(c3/c2)*c4*(1-i*tan(acos(c5)))/(3*conj(x))-x=0);```

it seems that (c1/c2) is the problem: if this term is complex it fails on my hardware, no matter if in CAS, program, command line ... On the emulator everything is fine. Same behavior when using "solve" instead of "csolve"

EDIT: SOLUTION: When rearranging the equation to:

Code:
``` csolve( x=(c1*3*conj(x)-c3*c4*(1-i*tan(acos(c5))))/(c2*3*conj(x)) );```

it works! But I still wonder why this rearrangement is needed after the FW update and why the emulator and the hardware behave quite different. Obviously with different FWs and emulator/hardware there is sometimes a cumbersome lack of consistency ...
I tried CONJ(x) using upper case and lower case. In your posting, the eqn uses lower case, conj(x). The upper case version worked. The lower case version returns an empty list. Have you tried your original equation, using upper case CONJ(x), (as shown in the toolbox, and help description)?

The command gets case-changed from lower case to upper case when viewed in history, but remains in lower case when recalled to the command line. If entered in upper case, it remains in upper case when recalled to the command line. This may be another of those HOME vs CAS things, where case matters.

-Dale-

[attachment=3575]
(05-20-2016 10:22 AM)DrD Wrote: [ -> ]I tried CONJ(x) using upper case and lower case. In your posting, the eqn uses lower case, conj(x). The upper case version worked. The lower case version returns an empty list. Have you tried your original equation, using upper case CONJ(x), (as shown in the toolbox, and help description)?

Yes I have tried this, but lower case and upper case version both give an empty list with the original equation. It only works after rearranging the equation as described above. Thanks for your advise.
Other than the direct [CAS] command line entry I mentioned previously, programmatically, this code snippet returned the expected result:

Code:
``` EXPORT Test() BEGIN   LOCAL c1:=231.0e3, c2:=0.91+i*0.012, c3:=13.2+i*97.55, c4:=400.0e6, c5:=0.9;   CAS.csolve("(c1/c2)-(c3/c2)*c4*(1-i*tan(acos(c5)))/(3*CONJ(x))-x=0",x); END;```

Whereas, this program snippet returns empty list:

Code:
``` EXPORT Test() BEGIN   LOCAL c1:=231.0e3, c2:=0.91+i*0.012, c3:=13.2+i*97.55, c4:=400.0e6, c5:=0.9;   CAS.csolve("(c1/c2)-(c3/c2)*c4*(1-i*tan(acos(c5)))/(3*conj(x))-x=0",x); END;```

The difference is the UPPER CASE CONJ(x) in the successful first snippet. I know this may be viewed as a bug in r10077, and a change from earlier releases, but CONJ() is a [HOME] command, shown in upper case, and described as such in the help file. It isn't a smooth operation, for sure. The lower case command is changed to upper case in the history view, so it *could* get changed during program execution, (or command line parsing), as well. It could be made to fail at compile time. It could be made to work in either case and solve things as anticipated. There are things that can facilitate the use of this command. With the many related topic discussions associated with solve, et al, it sure seems like this is a popular area seeking improvement. Maybe the gods will bless us with another release that solves solve sufficiently, soon!

-Dale-
Code:
``` EXPORT Test() BEGIN   LOCAL c1:=231.0e3, c2:=0.91+i*0.012, c3:=13.2+i*97.55, c4:=400.0e6, c5:=0.9;   CAS.csolve("(c1/c2)-(c3/c2)*c4*(1-i*tan(acos(c5)))/(3*CONJ(x))-x=0",x); END;```

Dale, thanks a lot for your support. I tested with your code snippet and it is getting more and more strange, so what happens with your code on my machine:

a) it is not compiled and a syntax error appears as long as CAS.csolve("...",x); is used.
It only compiles with: CAS.csolve("...","x"); or with CAS.csolve("...,x");

b) it gives indeed the correct complex results on the emulator(!) (EDIT)

c) on the Prime hardware it still results in an empty list {}

Obviously my hardware behave different than others and I'm getting more and more confused.
(05-20-2016 06:03 AM)Maro Wrote: [ -> ]I get the same problem when trying it inside the CAS without string evaluation, just in CAS on the command line: it works with c2=real, it doesn't work with c2= complex

Is it only when calling in the "csolve" routine? Or you mean evaluating c1/c2 directly is giving a different result.

Just for grins, could you go to HOME settings and CAS settings both, do a CLEAR to reset to default, and see if anything is different?
(05-20-2016 03:19 PM)Tim Wessman Wrote: [ -> ]
(05-20-2016 06:03 AM)Maro Wrote: [ -> ]I get the same problem when trying it inside the CAS without string evaluation, just in CAS on the command line: it works with c2=real, it doesn't work with c2= complex

Is it only when calling in the "csolve" routine? Or you mean evaluating c1/c2 directly is giving a different result.

Hi Tim, I'm not sure if I understand your question right, but what I meant was that in the CAS environment on the command line typing
csolve((c1/c2)-(c3/c2)*c4*(1-i*tan(acos(c5)))/(3*conj(x))-x)=0,x) works with (c1/c2) being a real value and it doesn't work with (c1/c2) being a complex value. c1-c5 are user defined variables. It doesn't matter if I use csolve or solve. Only rearrangement of the equation helps (see posts above). Behavior on the CAS command line and using csolve or solve in a program is consistent.

(05-20-2016 03:19 PM)Tim Wessman Wrote: [ -> ]Just for grins, could you go to HOME settings and CAS settings both, do a CLEAR to reset to default, and see if anything is different?

This doesn't change anything, same behavior.
(05-20-2016 03:00 PM)Maro Wrote: [ -> ]b) it gives indeed the correct complex results on the emulator(!) (EDIT)

I should have mentioned that I was using the emulator. However, I just now tested those same snippets on the physical device, and with the same result. CONJ(x) must be uppercase, or an empty list results.

I'm using English language in this setting, and the [CAS] setting checkbox for "Complex" is ticked. (Include complex results in variables). I may have read somewhere that other language settings have not always worked quite the same, but I am VERY unsure on that point. I do know that I tried a lot of things that did not work before I posted those snippets. If only the exact syntax required for each command were known, it would be very helpful. Unfortunately, the documentation just isn't as explicit or timely, as we might need.

In earlier releases when things didn't go well (on the emulator), I would use the emulator menu: Calculator | Reset, to clear all memory, and often things worked more predictably. Also, previous contents in variables that don't get initialized at run time, might have an effect (var x, in this case). I intentionally left var x out of the LOCAL declaration, since that is the same as given in this thread. It didn't seem to matter, from my testing though.

-Dale-

-Dale-
thanks again Dale for your "testing time". I have tried a lot of things too in the meanwhile, but uppercase CONJ(x) doesn't help on my hardware. Even reseting the calculator didn't change anything. Indeed I'm using English language setting too, since the German translations are sometimes rather strange and not really appropriate, which is sometimes more confusing than helpful.

I fully agree that a detailed (!) and timely documentation on specific aspects would be really great.
Reference URL's
• HP Forums: https://www.hpmuseum.org/forum/index.php
• :