Post Reply 
a type bug
11-30-2015, 09:53 PM (This post was last modified: 11-30-2015 09:54 PM by ji3m.)
Post: #1
a type bug
In the cas window, 'type ("abc")' returns DOM_STRING which is 12

But in a program

EXPORT yup()
BEGIN
LOCAL a := "abcder",Z;
Z :=CAS("LEFT(a,3)");
{Z, CAS.type (Z), TYPE (Z)};
END;

in cas wibdow , 'a:= yup' gives {"abc", 6, 2}

The cas type returned is 6 which is DOM_IDENT. but its
clearly a string.

Nasty workaround checks TYPE also.

I work with android Prime only for now on my
Galaxy Tab Pro/Note 2
Find all posts by this user
Quote this message in a reply
11-30-2015, 10:01 PM (This post was last modified: 11-30-2015 10:03 PM by Han.)
Post: #2
RE: a type bug
(11-30-2015 09:53 PM)ji3m Wrote:  In the cas window, 'type ("abc")' returns DOM_STRING which is 12

But in a program

EXPORT yup()
BEGIN
LOCAL a := "abcder",Z;
Z :=CAS("LEFT(a,3)");
{Z, CAS.type (Z), TYPE (Z)};
END;

in cas wibdow , 'a:= yup' gives {"abc", 6, 2}

The cas type returned is 6 which is DOM_IDENT. but its
clearly a string.

Nasty workaround checks TYPE also.

That's because CAS.command() takes strings as arguments in order to be able to pass "symbolic" arguments (which would not be possible without strings). Thus, when you do CAS.type("abc") you are actually executing: type(abc). And if 'abc' does not exist, then the type returned is that of a variable name.

http://www.hpmuseum.org/forum/thread-3590.html

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
11-30-2015, 10:42 PM (This post was last modified: 11-30-2015 10:48 PM by ji3m.)
Post: #3
RE: a type bug
So a string functions like LEFT ("abc",2) is not a cas function.

So i cant check the return type unless i know it apriori.?

But what is the function 'type()' which i can use in a cas window?

It takes a string and returns DOM_STRING not an identifier.

In a program, type ( returns the same thing as TYPE () so i used CAS.type.


If 'type' is not a cas function then what could possibly be used
in a program that would return DOM_STRING..when given
a string.??

It is quite bizzare to me that just asking a mechanical question
like type of would evaluate anything. I can see that CAS () evaluates
but what exactly is the point of having a function 'type'?

I work with android Prime only for now on my
Galaxy Tab Pro/Note 2
Find all posts by this user
Quote this message in a reply
12-01-2015, 12:01 AM
Post: #4
RE: a type bug
(11-30-2015 10:42 PM)ji3m Wrote:  So a string functions like LEFT ("abc",2) is not a cas function.

So i cant check the return type unless i know it apriori.?

I do not understand the question. Why would you expect LEFT() to return anything except a string? So in this particular case, yes, you already know the type a priori as LEFT() is a documented command.

(11-30-2015 10:42 PM)ji3m Wrote:  If 'type' is not a cas function then what could possibly be used
in a program that would return DOM_STRING..when given
a string.??

It is quite bizzare to me that just asking a mechanical question
like type of would evaluate anything. I can see that CAS () evaluates
but what exactly is the point of having a function 'type'?

Lower-case "type" _IS_ a CAS function. In HPPPL, upper/lower case does not matter. Type, TYPE, type, tYpE are all interpreted as the TYPE() command -- the non-CAS variety. To access the CAS type() command, you can use CAS.type(). However, when called from non-CAS HPPPL programs via CAS.command(arg) the argument arg can either be a non-string expression, or an expression in the form of a string. Perhaps a better example would be the solve() command.

In CAS view, one could type solve(x^2-1,x) to get the solution (note the lower-case x). However, one cannot simply type CAS.solve(x^2-1,x) within an HPPPL program, because the expressions x^2-1 and x must be resolvable. So in order to feed the expressions x^2-1 and x (as is) as arguments without evaluation, we have to use the other option, which is to encapsulate them as a string: CAS.solve("x^2-1", "x") -- or even CAS.solve("x^2-1,x").

Thus, when using CAS.command(arg), 'arg' itself must be either completely resolvable (because we are in HPPPL land), or it must resolve to a string (or comma-separated strings). And if it is a string, then the expression inside the string is used as the actual argument from the CAS view (this is how to pass "symbolic expressions" as arguments; it also has to do with the way LOCAL variables and CAS interact per the discussion in your other posts). In your example, if 'abc' had been a variable containing a string, you would have gotten DOM_STRING. However, since 'abc' likely did not exist as a variable, this is why you got DOM_IDENT.

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
12-01-2015, 05:24 PM
Post: #5
RE: a type bug
Wow. Thanks. Im getting closer to getting it.

I have pretty good luck with CAS.type for everything but strings.

So i now use

mytype (any)
begin
if TYPE(any)== 2 then DOM_STRING else CAS.type(any) end;
end;

which behaves like typing: type (any) in the cas window.

Its just that i had previously believed that

CAS.fun (..) in a program would behave like

fun (...) typed manually in the cas window

I work with android Prime only for now on my
Galaxy Tab Pro/Note 2
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 2 Guest(s)