HP Forums
Strange behaviour STRING command in case STRING(√7) - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: Strange behaviour STRING command in case STRING(√7) (/thread-7271.html)



Strange behaviour STRING command in case STRING(√7) - Jan_D - 11-20-2016 04:58 PM

With reference to another thread I wanted to investigate the behaviour of STRING(√7).

In Home view it returns “2.6457513....” as expected.
In CAS view it returns “√7”. This is also good.

But now the strange things.
When I store STRING(√7) into the variable s and examine its properties I get the following:

Quote:STRING(√7) : “√7”

s:=STRING(√7) : “√7”

SIZE(s) : 4
s(1) : “”
s(2) : “”
s(3) : “”
s(4) : “7”
ASC(s(1)) : “Error: Invalid input”
ASC(s(2)) : “Error: Invalid input”
ASC(s(3)) : “Error: Invalid input”
ASC(s(4)) : {55}

So the length of the string is not 2 as expected but 4 and the first 3 elements do not have a unicode representation.

When I do the same things in the HP 50g I get results I like better: a string length of 2 and the characters √ and 7 as its elements.

On the other hand, the Prime can get √7 back once “√7” is given, and as far as I know the HP 50g can not do that:

Quote:EXPR(s): √7
EXPR(“√7”): √7



RE: Strange behaviour STRING command in case STRING(√7) - Mark Hardman - 11-20-2016 05:40 PM

Strings on the Prime are in Unicode. A size of 4 for the string "√7" is quite correct.

s:=string(√7) -> "√7"
asc(s) -> {226,136,154,55}
char({226,136,154,55}) -> "√7"
char({226,136,154}) -> "√"

If you look at the Unicode details for the "√" charater, its UTF-8 representation is:

0xE2 0x88 0x9A (226,136,154)

http://www.fileformat.info/info/unicode/char/221a/index.htm

Mark Hardman


RE: Strange behaviour STRING command in case STRING(√7) - Jan_D - 11-20-2016 06:23 PM

Hi Mark,
Thank you. Very interesting. I have to investigate this further.


RE: Strange behaviour STRING command in case STRING(√7) - cyrille de brébisson - 11-21-2016 06:52 AM

Hello,

The CAS works with strings in UTF8 encoding.
In home, strings are UTF16 encoded. And only supports characters up to 16 bits.

Cyrille


RE: Strange behaviour STRING command in case STRING(√7) - Jan_D - 11-21-2016 11:04 AM

(11-21-2016 06:52 AM)cyrille de brébisson Wrote:  Hello,

The CAS works with strings in UTF8 encoding.
In home, strings are UTF16 encoded. And only supports characters up to 16 bits.

Cyrille
Hi Cyrille,

This is valuable information for me.


RE: Strange behaviour STRING command in case STRING(√7) - Jan_D - 11-22-2016 04:51 PM

Let’s define a string in CAS view as follows: t:=”√7”

What happens is that 2 spaces are automatically added, and it is changed into “ √ 7”
This should not happen.

When I examine the string this is what the CAS view shows:

Code:

t:=” √ 7” :  “ √ 7” 

DIM(t) : 6
DIM(t) : 4
   ASC(t) : [32 226 136 154 32 55]
   ASC(t) : {32, 8730, 32, 55}
CHAR(8730) : “□”
CHAR(8730) : “√”
   CHAR({226,136,154}) : “√”
   CHAR({226,136,154}) : “â □ □”

Is not this confusing?
I will explain it.

I entered each command twice, the first time in lowercase, the second time in uppercase.
These commands are different but appear only once in the command Catalog.
I have to change them manually in the command line, but they always appear in uppercase in CAS view.

Question:

Do other people have this issue too, or is this due to the fact that I do not have the most recent firmware version but version 8151?


RE: Strange behaviour STRING command in case STRING(√7) - DrD - 11-22-2016 05:02 PM

How about this for variety:

t:=[shift][x^2]; // ==> √7
STRING(t); //==> "√7"
dim(t); // ==> 2

-Dale-


RE: Strange behaviour STRING command in case STRING(√7) - Joe Horn - 11-22-2016 06:32 PM

(11-22-2016 04:51 PM)Jan_D Wrote:  I entered each command twice, the first time in lowercase, the second time in uppercase.

If you turn off Textbook Display (N.B. not Textbook Entry), the CAS history will show your commands in the case you typed them in (usually). This helps tremendously when trying to figure out which spelling does what.

Please note that mixed case sometimes acts differently than either uppercase or lowercase spelling. For example, in CAS, Sign() is more accurate than either sign() or SIGN(). Try all three on epsilon to see this (be sure to turn Textbook Display off!):

sign(epsilon) --> 0.
SIGN(epsilon) --> 0.
Sign(epsilon) --> 1.

Crazy, huh?


RE: Strange behaviour STRING command in case STRING(√7) - StephenG1CMZ - 11-22-2016 09:23 PM

(11-22-2016 06:32 PM)Joe Horn Wrote:  
(11-22-2016 04:51 PM)Jan_D Wrote:  I entered each command twice, the first time in lowercase, the second time in uppercase.

If you turn off Textbook Display (N.B. not Textbook Entry), the CAS history will show your commands in the case you typed them in (usually). This helps tremendously when trying to figure out which spelling does what.

Please note that mixed case sometimes acts differently than either uppercase or lowercase spelling. For example, in CAS, Sign() is more accurate than either sign() or SIGN(). Try all three on epsilon to see this (be sure to turn Textbook Display off!):

sign(epsilon) --> 0.
SIGN(epsilon) --> 0.
Sign(epsilon) --> 1.

Crazy, huh?

I have previously considered using some portable sign code, if only to avoid changing portable code from SIGN to SGN depending on compiler...It is surprising that something so short has such unexpected results.

Code:



 EXPORT Z_SGN(XX)
 BEGIN
  RETURN ((XX>0)-(XX<0));
 END;
 

EXPORT SG()
BEGIN
 Z_SGN(0.01);
 // Z_SGN(epsilon); where is epsilon? 
END;

I haven't checked that on epsilon - I get a syntax error whether I write epsilon or select "e" from the key Shift/9.


RE: Strange behaviour STRING command in case STRING(√7) - Jan_D - 11-22-2016 09:34 PM

(11-22-2016 06:32 PM)Joe Horn Wrote:  If you turn off Textbook Display (N.B. not Textbook Entry), the CAS history will show your commands in the case you typed them in (usually). This helps tremendously when trying to figure out which spelling does what.
Thank you Joe.

You are completely right.
I can now toggle between the view with everything in uppercase and the view which shows the different inputs.

But what a strange thing that Textbook Display converts these commands into uppercase!
Is this still so in the latest update? It seems not a good idea to me!


RE: Strange behaviour STRING command in case STRING(√7) - Joe Horn - 11-23-2016 04:07 AM

(11-22-2016 09:23 PM)StephenG1CMZ Wrote:  I haven't checked that on epsilon - I get a syntax error whether I write epsilon or select "e" from the key Shift/9.

"epsilon" is only recognized by the CAS. It cannot be used in Home or in non-CAS programs or functions.


RE: Strange behaviour STRING command in case STRING(√7) - StephenG1CMZ - 11-23-2016 08:41 AM

(11-23-2016 04:07 AM)Joe Horn Wrote:  
(11-22-2016 09:23 PM)StephenG1CMZ Wrote:  I haven't checked that on epsilon - I get a syntax error whether I write epsilon or select "e" from the key Shift/9.

"epsilon" is only recognized by the CAS. It cannot be used in Home or in non-CAS programs or functions.

That's right...
It crashes the calculator on Android...

Code:


 EXPORT Z_SGN(XX)
 BEGIN
  RETURN ((XX>0)-(XX<0));
 END;
 

EXPORT SG()
BEGIN
 {Z_SGN(0.01),Z_SGN(0),Z_SGN(−0.01)};
 Z_SGN(approx(CAS.epsilon)); // CRASHES ON ANDROID 
END;



RE: Strange behaviour STRING command in case STRING(√7) - Jan_D - 11-24-2016 01:06 PM

Things are clearer now.

We have to pay careful attention to the use of uppercase and lowercase commands and show them correctly by unchecking Textbook Display in second page of Home Settings.

In CAS we define once more the string s.

STRING(√7) : “2.645751....”

s:=string(√7) : “√7”

DIM(s) : 2
ASC(s) : {8730, 55}
CHAR(8730) : “√”
CHAR(55) : “7”
MID(s,1,1) : “√”
MID(s,2,1) : “7”

But....
s(1) : “ // asc(s(1)=226
s(2) : “ // asc(s(2)=136
s(3) : “ // asc(s(3)=154
s(4) : “7” // asc(s(4)=55

These results for s(i) I do not like very much.
But we can improve them by converting s to a string which is generated in Home view instead of CAS view.

We go to Home view and define t as t:=s.

We return to CAS view and see:

t(1) : 8730
t(2) : 55

This I like better.

As we knew already DIM(t)=2, however SIZE(t)=4
Probably SIZE in CAS view returns the number of bytes used in UTF8 encoding because when I define in Home view the strings a and b as: a:=”aaaaa” and b:=” √√√√√” I get in CAS view:

SIZE(a) : 5
SIZE(b) : 15

I define the strings in Home view because CAS view adds extra spaces when I define strings, which it should not do.