Suppose a := "12345";
Then a (1) gives "1" as advertised
BUT
a (1) := "Q" gives "1Q345" odd
And
a (0) := "Q" gives "Q2345" !!!
So LHS strings are 0..n-1 indexed
but RHS are are 1..n. indexed
Very curious. Good to know.If you play with string theory.
Pretty sure it's a bug; all indices typically start at 1.
Careful. It bites back.
Seems this is true in cas view entry.(and maybe in #cas)
Not so in a ppl pgm or in home view with a home created variable.
But then in home view or pgm,
A:= "abc" A (1) returns the asc integer 65 IF A was created as a home var
but
A (1) gives "a" if A is a cas variable.
Welcome to oz.
(10-17-2015 02:45 PM)ji3m Wrote: [ -> ]Welcome to oz.
hahaha proper definition
The variable A is a reserved variable for type real.
If you were to use a non-reserved variable, for example: AA:="abc" then the ascii value for the first item in the string, as referenced by AA(1), is returned as 97, (not 65, which is upper case A), and so forth.
-Dale-
I really didnt use A. Just in my post.
That wasnt the point anyhow.
It seem that cas does treat left and rigtht hand reference differently.
Home and ppl treat MYSTRING (n) differently.
Home gives character codes, cas gives characters.
Sorry i forgot about predefined variables.
Never use them.
Dont use home screen.
hello,
To get 1 character in home, do var(1,1)
Cyrille
Perhaps useful(?):
If a variable contains a string, then (example):
var:="abcd";
n:=length(var);
var(2); // => ascii value of 2nd char: 98
var(2,2); // => sub string starting at the 2nd char for 2 chars length: "bc"
var(2,n); // => sub string starting at the 2nd char for length of string: "bcd"
If a string is an element within a list:
L0:={var}; // L0 is set to the contents of var
then:
L0(1); // => "abc"
L0(1,2); // => ascii value of the 2nd character of the 1st element: 98
L0(1,2,2); // => sub string beginning at the 2nd char for 2 chars: "bc"
L0(1,2,n); // => sub string beginning at the 2nd char for length of string: "bcd"
Nice shorthand for the SUB() function!
-Dale-