Hello,

When I put INSTRING("√7","√") directly into CAS, it returns 1 as expected.

However when I put the exact same thing into programs, it returns 0. CAS or non-CAS, it doesn't matter.

Code:

`EXPORT norm_instring_bug(expression)`

BEGIN

return instring(string(expression),"√");

END;

#cas

cas_instring_bug(expression):=

BEGIN

return instring(string(expression),"√");

END;

#end

It might have something to do with Prime auto-adding spaces, which I found to have caused some issues during my testing. For example, Prime changes "√" to " √ ". If we now calculate INSTRING("√7"," √ "), it returns 0.

An upper-case INSTRING seems to work.

Code:

EXPORT TRYST()

BEGIN

RETURN INSTRING("√7","√");

END;

If an extra space is being inserted, it might be worth trying the equivalent Unicode numeric instead of a string.

(10-26-2016 08:37 AM)CH3791 Wrote: [ -> ]Hello,

When I put INSTRING("√7","√") directly into CAS, it returns 1 as expected.

However when I put the exact same thing into programs, it returns 0. CAS or non-CAS, it doesn't matter.

Code:

`EXPORT norm_instring_bug(expression)`

BEGIN

return instring(string(expression),"√");

END;

#cas

cas_instring_bug(expression):=

BEGIN

return instring(string(expression),"√");

END;

#end

It might have something to do with Prime auto-adding spaces, which I found to have caused some issues during my testing. For example, Prime changes "√" to " √ ". If we now calculate INSTRING("√7"," √ "), it returns 0.

I don't have a calc or a copy of the VC in my reach, but I wonder if there is any difference between running the programs from CAS vs from HOME. My thought process is that in CAS, entering in √7 leaves the quantity in exact form (assuming the necessary settings are in place) whereas in HOME, the quantity is reduced to a decimal approximation. If this simplification happens before that program is even run (as part of the parsing routine), then this may explain why you get 0 as the result all the time.

Han

Hello,

It might be because your expression is evaluated before the string function is called on it, thus removing the sqrt symbol?

Cyrille

(10-26-2016 08:37 AM)CH3791 Wrote: [ -> ]Hello,

When I put INSTRING("√7","√") directly into CAS, it returns 1 as expected.

However when I put the exact same thing into programs, it returns 0. CAS or non-CAS, it doesn't matter.

Code:

`EXPORT norm_instring_bug(expression)`

BEGIN

return instring(string(expression),"√");

END;

#cas

cas_instring_bug(expression):=

BEGIN

return instring(string(expression),"√");

END;

#end

It might have something to do with Prime auto-adding spaces, which I found to have caused some issues during my testing. For example, Prime changes "√" to " √ ". If we now calculate INSTRING("√7"," √ "), it returns 0.

When I put in the following:

Code:

`EXPORT norm_instring_bug(expression)`

BEGIN

RETURN INSTRING(STRING(expression),"√");

END;

I get 2 in RPN mode when I enter "√7". I tried with all capitals as well as lowercase keywords. I get 2 every time.

Tom L

To Stephen:

How do I program using unicode numeric?

To Han:

norm_instring_bug(√7)

cas_instring_bug(√7)

returns 0 in both Home and CAS. Even if the "exact" setting is ticked in CAS.

To Cyrille:

At least with the CAS program, it shouldn't have been evaluated right? Because if we have a program like say

Code:

`#cas`

return_expression(expression):=

BEGIN

return expression;

END;

#end

entering return_expression(√7) in CAS will return √7 in exact form. Even without using double quotations marks.

To Tom:

Is your answer of 2 after Prime has automatically added in spaces (so creating a string like this: " √7 ")? Because the answer should be 1 since the √ is in the first position of the string.

To represent the square root symbol as a Unicode numeric use this syntax:

Code:

MSGBOX(ASC("√"));//shows the number 8730 is Unicode for sqrt char

MSGBOX(CHAR(8730));//returns the sqrt Character from the number

//Perhaps that representation will avoid the extra space?

Note: If you look through Shift Chars you can discover other code numbers.

But beware that there may be several similar-looking symbols.

(10-27-2016 02:03 PM)moonbeam Wrote: [ -> ] (10-27-2016 01:47 PM)StephenG1CMZ Wrote: [ -> ]To represent the square root symbol as a Unicode numeric use this syntax:

Code:

MSGBOX(CHAR(10003));

To find the number required look it up on Wikipedia...

The one I have here I found using Shift/Chars, but might not be the best for start.

I'm getting 8730 for ASC("√") when keying the symbol directly (shift x^2).

My apologies. In my original post, I had used shift/chars and picked up a value that looked like a sqrt or tick on my little screen, and wrote the call syntax.

I then used asc(sqrrtsymbol) to find out the actual number and updated my post with the right number - but I was too slow and you read the 1st version.

BTW, I am surprised that when using Shift/Chars/More/Maths the symbol for squareroot is not immediately seen - I would have thought it would be one of the first/commonest symbols. But I guess that sequence is Unicode's, not HP Prime's.

(10-27-2016 03:11 PM)StephenG1CMZ Wrote: [ -> ]BTW, I am surprised that when using Shift/Chars/More/Maths the symbol for squareroot is not immediately seen - I would have thought it would be one of the first/commonest symbols. But I guess that sequence is Unicode's, not HP Prime's.

Welcome to unicode! :-) Yes, the character browser is exclusively showing the codepoints in the font.

There are plenty of places where characters appear in more then 1 place, don't appear in the same sequence because they already existed somewhere else, and other strange things.

Just take a look at the superscript/subscript block...

https://en.wikipedia.org/wiki/Unicode_su...ipts_block
Cheers guys,

the program works now!

(10-28-2016 07:10 AM)CH3791 Wrote: [ -> ]Cheers guys,

the program works now!

Hi CH3791,

You have marked the thread as having been solved.

Could you please tell us what the solution is because I do not see it anywhere.

Hello Jan

If you want to check for square root symbol, you use this code:

Code:

`instring(yourstring,char(226,136,154))`

This bypasses a problem that occurs with Prime (it automatically adds spaces into strings sometimes).