HP Prime [ Matrix Function ] BUG ln( [[0,1][1,1]] ) in Exact and Approximate CAS Mode

[profrd]

I would like to Report a BUG in HP Prime CAS [ Matrix Functions ], specifically in calculating

ln( [[0,1][1,1]] )

which resulted in a matrix response with WRONG Matrix[1,2] and Matrix[2,1] elements.

I'am using the Newest version ROM 6030 in calculator and 6031 in emulator, and the problem in CAS mode
results both in Exact and Approximate Mode, for which the

[[−0.215204470482+2.2732777998989*i , 0.430408940964]
[0.430408940964+1.40496294621*i , 0.21520447048202+0.868314853691*i]]

approximate numerical result returned simply does not match with the Correct numerical answer which should be

[[−0.215204470482+2.2732777998989*i , 0.430408940964-1.4049629462081*i]
[0.430408940964-1.40496294621*i , 0.21520447048202+0.868314853691*i]]

which in this case returns back approximately [[0.,1.][1.,1.]] by taking e^Correct Result,

and produces a Wrong result by taking e^Wrong Answer ( produced by ln( [[0,1][1,1]] ) in HP Prime ),

which returned a totally distinct matrix ( with all complex numbers ) instead of the [[0.,1.][1.,1.]] expected result.

Yours Sincerely, hoping this Post would be Directed to the Right HP Prime Staff Personnel so as to provide
a future BUG Correction in a next ROM release, wishing a Nice day and work to all.

[parisse]

I can not reproduce, the latest version of Xcas returns for ln([[0,1],[1,1]]) (don't forget the comma between the two rows):
[[(sqrt(5)+5)/10*ln((-(sqrt(5))+1)/2)+(-(sqrt(5))+5)/10*ln((sqrt(5)+1)/2),(-(sqrt(5))/5)*ln((-(sqrt(5))+1)/2)+(sqrt(5))/5*ln((sqrt(5)+1)/2)],[(-(sqrt(5))/5)*ln((-(sqrt(5))+1)/2)+(sqrt(5))/5*ln((sqrt(5)+1)/2),(-(sqrt(5))+5)/10*ln((-(sqrt(5))+1)/2)+(sqrt(5)+5)/10*ln((sqrt(5)+1)/2)]]
and evalf
[[-0.215204470482+2.2732777999*i,0.430408940964-1.40496294621*i],[0.430408940964-1.40496294621*i,0.215204470482+0.868314853691*i]]

[Gilles]

Hi profrd,Parisse

I get the right results both on emulator (Rev 6031) and calculator in Exact and Approximate Mode. Very strange, could you try again?

EDIT : Haha, I get it ! It works in RADIAN but bug occurs in DEGREE.

[parisse]

I still get the right ln in degree mode (in Xcas).

[Tim Wessman]

(10-30-2014 05:55 AM)profrd Wrote:  I'am using the Newest version ROM 6030

I think mine might be just a bit newer... ;-)

Quote:[[−0.215204470482+2.2732777998989*i , 0.430408940964-1.4049629462081*i]
[0.430408940964-1.40496294621*i , 0.21520447048202+0.868314853691*i]]

[[−0.215204470482+2.2732777999*i,0.430408940964-1.40496294621*i],[0.430408940964-1.40496294621*i,0.215204470482+0.868314853691*i]]

Is what I see with degrees on (or radians), and the input you gave. So looks like that problem was resolved in the CAS. Thanks for the report. Glad to see that it already appears to be resolved.

[Gilles]

(10-30-2014 03:55 PM)Tim Wessman Wrote:  

(10-30-2014 05:55 AM)profrd Wrote:  I'am using the Newest version ROM 6030

I think mine might be just a bit newer... ;-)

I hope that the 'textbook' display will be improve in the future... You can take the old 49G in example for this

And one day, perhaps, we could forget these orange and cyan colors I think that consumers ' eyes are more important than marketing, no ?

[Tim Wessman]

(10-31-2014 10:54 AM)Gilles Wrote:  I hope that the 'textbook' display will be improve in the future...

What do you think needs improving?

[Gilles]

(10-31-2014 12:55 PM)Tim Wessman Wrote:  

(10-31-2014 10:54 AM)Gilles Wrote:  I hope that the 'textbook' display will be improve in the future...

What do you think needs improving?

- The major point for me is to use a special character like the . of the 50G instead of '*'.

- But you sometimes get strange things with SIGMA symbol and loose the texbook mode.

- or try:
e^iΣ ... with implicit multiplication ...

[Tim Wessman]

(11-01-2014 01:38 PM)Gilles Wrote:  - But you sometimes get strange things with SIGMA symbol and loose the texbook mode.

- or try:
e^iΣ ... with implicit multiplication ...

I really am not understanding either of those... could you provide images or more details?

[Han]

I think he was saying he preferred the \( \cdot \) for multiplication over the \( * \) for multiplication in the way products are displayed; or how in some cases the multiplication symbol is left off via implicit multiplication.

[Gilles]

(11-01-2014 04:28 PM)Han Wrote:  I think he was saying he preferred the \( \cdot \) for multiplication over the \( * \) for multiplication in the way products are displayed; or how in some cases the multiplication symbol is left off via implicit multiplication.

Here is an example :

[Gilles]

(11-01-2014 03:21 PM)Tim Wessman Wrote:  

(11-01-2014 01:38 PM)Gilles Wrote:  - or try:
e^iΣ ... with implicit multiplication ...

I really am not understanding either of those... could you provide images or more details?

Example :



I can't input the last formula in the Prime

[Tim Wessman]

(11-01-2014 10:21 PM)Gilles Wrote:  I can't input the last formula in the Prime

Let's not be dramatic. Pressing [*] while in the CAS doesn't qualify as "can't enter it". :-)

Works fine in home, but I'll ask Bernard if there is a reason why implicit multiplication isn't handled after a complex i.

[Tim Wessman]

(11-01-2014 10:06 PM)Gilles Wrote:  Here is an example :

So is your concern here around the CAS pulling out the 3? I am not seeing how this is an entry issue like you seem to be reporting.

[parisse]

Support for i*... without * would require adding a few rules in the parser. I think it is feasible, but I'll do it, because it does not happen frequently and it would not change the fact that the CAS parser does not support implicit multiplication, it only supports a few shortcuts like 2x instead of 2*x (and if you have the math level to work with i, you can understand it's important to write explicit *).
For the 3 outside of the exponent, this is pre-simplification, so that expression have a polynomial dependency with respect to fewer variables.

[Marcus von Cube]

(11-01-2014 10:06 PM)Gilles Wrote:  

(11-01-2014 04:28 PM)Han Wrote:  I think he was saying he preferred the \( \cdot \) for multiplication over the \( * \) for multiplication in the way products are displayed; or how in some cases the multiplication symbol is left off via implicit multiplication.

Here is an example :

If I understand Gilles correctly he is complaining about the display of the multiplication sign as '*' on the Prime versus '∙' on the 50G.

[mlpalacios8]

I agree.

I prefer the dot symbol '∙' for multiplication rather than the asterisk '*' .
With the dot symbol '∙' , the equations look cleaner, leaner, and smaller.
It's easier and faster to read them with the dot than with the medium sized asterisk '*'

Maybe this can be changed.
I hope so.