Post Reply 
Bug? accessing LOCAL var in shared scope
12-03-2014, 10:37 PM
Post: #1
Bug? accessing LOCAL var in shared scope
I have been using LOCAL vars declared outside the programs, to get the equivalent of variables shared between routines in the same program, but not exported globally.

There is something strange going on whenever I try to use these variables as function arguments; they are not accessed at all. I always have to copy them to a local variable first. Example:

Code:
LOCAL foo=[[1,2],[3,4]];
EXPORT GlobalVarIgnored()
BEGIN
  PRINT();
  PRINT(foo);
  PRINT(colDim(foo));

  LOCAL bar=foo;
  PRINT(bar);
  PRINT(colDim(bar));
END;

I would expect both PRINT(colDim(foo)) and PRINT(colDim(bar)) to print out same number (2), but instead the output of the program is:
Code:
[[1,2],[3,4]]
colDim(foo)
 Error: Bad Argument Value
[[1,2],[3,4]]
2
What's going on? Is this a bug or have I missed something?

(Discovered in 6030; confirmed in 6940.)

/Lennart Börjeson
Stockholm, Sweden
Find all posts by this user
Quote this message in a reply
12-03-2014, 11:42 PM (This post was last modified: 12-03-2014 11:48 PM by Snorre.)
Post: #2
RE: Bug? accessing LOCAL var in shared scope
Hello lenborje,

I think you shouldn't use LOCAL outside functions.
To my knowledge there are 3 types of variables:
a: LOCALs inside functions: only accessible and existent within the function.
b: global (in program context) but not EXPORTed: only accessible within the program, but keeping their value even if the program is left (a kind of private vars).
c: EXPORTed: accessible from everywhere and also keeping their value.

The first type has to be declared inside a function, the last two types have to be declared outside functions:

EXPORT c;
b;
myFunction() BEGIN LOCAL a; END;

Type b variables are a nice feature to preserve some program state without polluting the variable menu and without having to fear the user or another program may accidently set them to an invalid value.

Greetings
(sorry, English is not my mother tongue)
Find all posts by this user
Quote this message in a reply
12-04-2014, 07:15 AM
Post: #3
RE: Bug? accessing LOCAL var in shared scope
(12-03-2014 11:42 PM)Snorre Wrote:  I think you shouldn't use LOCAL outside functions.

I get the same error even if I leave out the "LOCAL" on the declaration of "foo".

Your "global" variable kind is exactly what I'm trying to achieve, i.e. variables local to the program, accessible to all its routines, but not exported to other programs.

/Lennart Börjeson
Stockholm, Sweden
Find all posts by this user
Quote this message in a reply
12-04-2014, 10:58 AM
Post: #4
RE: Bug? accessing LOCAL var in shared scope
Sorry. My fault. You're right. Now it seems to me as a bug too.
Find all posts by this user
Quote this message in a reply
11-12-2015, 04:22 PM
Post: #5
RE: Bug? accessing LOCAL var in shared scope
Sorry to dig up an old thread.

This is an issue related to CAS commands and the separation of Home and CAS views. They (CAS commands) currently can only see local variables inside HPPPL (i.e. non-CAS) programs, not ones declared outside. Even EXPORTed variables don't always behave as expected (referencing an entry inside a matrix using square brackets, for example, comes to mind).

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
11-18-2015, 06:19 PM (This post was last modified: 11-18-2015 06:23 PM by StephenG1CMZ.)
Post: #6
RE: Bug? accessing LOCAL var in shared scope
May not be relevant but should
Local foo equals ... =
Be
Local foo assignment :=
Or are these equivalent?

Stephen Lewkowicz (G1CMZ)
My Astronomy: Lunar program celebrates Apollo 11 landing on the Moon 50 years ago.
Visit this user's website Find all posts by this user
Quote this message in a reply
11-23-2015, 06:19 AM
Post: #7
RE: Bug? accessing LOCAL var in shared scope
Hello,

The local in the global scope of the program is optional (it is the default, EXPORT is a must if you want to export however).
= and := in variable creation are absolutely equivalent.

so, the syntax is (if my memory on syntax writing is correct):
[LOCAL|EXPORT] name[[:]=expression][, name[[:]=expression]]+;

Cyrille

Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP.
Find all posts by this user
Quote this message in a reply
11-23-2015, 08:10 AM
Post: #8
RE: Bug? accessing LOCAL var in shared scope
Cyrille,

may I ask if you have some insight on my original question in this thread?

Best regards,

/Lennart Börjeson
Stockholm, Sweden
Find all posts by this user
Quote this message in a reply
11-24-2015, 07:49 PM
Post: #9
RE: Bug? accessing LOCAL var in shared scope
Hello,

Yes, the problem, as explained to some extend by Han is that the CAS is not local or program aware.

To access a local (as is function local), or program global variable (exported or local), the CAS would need to know what program/function is running. Which it does not because the Home/Cas interconnection is not 'that great'.

The result is that you can access from the CAS a program exported variable (because the CAS can find it), although it is dangerous because if you have 2 programs that export a variable with the same name (remember, they are still 2 variables in this case), then the CAS might pick any of them (actually, the one from the first program in the list...) but can not find a function local or program non exported variable.

Now, in order to try to 'hide' the problem as much as possible for 'non advanced' programs, when you call a cas function from a HPPL function, if they are any function local variables in the arguements, they will be replaced by their values, but this does not happen with program globals (maybe it should)...

One of the issue is that HPPL never knows when the cas need symbolic data or value data when it is called, this makes it fairly hard to know/guess what the user wants to do.

Cyrille

Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP.
Find all posts by this user
Quote this message in a reply
11-24-2015, 10:26 PM
Post: #10
RE: Bug? accessing LOCAL var in shared scope
Thank you for the explanation.

I must add that what confused me in Han's hint was that I did not understand what CAS had to do with it.

I understand now that colDim is a CAS function. This was not immediately apparent to me.

Are all functions with mixed case names CAS functions, or is there some other way to distinguish between CAS and "normal" functions?

/Lennart Börjeson
Stockholm, Sweden
Find all posts by this user
Quote this message in a reply
11-25-2015, 06:35 AM
Post: #11
RE: Bug? accessing LOCAL var in shared scope
Hello,

As a general rule, lower case function are CAS function. UPPERCASE functions are home functions. When CAS and HOME share a function, to allow HOME/CAS compatibility, CAS will also use uppercase.
The above is mostly legacy from the 38 series times.

Home later on added more functions which are often Mixed case (because it's more modern and nicer).
As a general rule, HOME functions are NOT case sensitive TeXtOuT will be recognized. CAS does accept some functions in both UPPERCASE and lowercase form, but never using a random mixed case. But they are some exceptions :-)
Most Mixed case functions in home are in fact app functions, not 'main' functions.

Hope that this does help.

Cyrille

Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP.
Find all posts by this user
Quote this message in a reply
11-25-2015, 07:55 AM
Post: #12
RE: Bug? accessing LOCAL var in shared scope
Well, at least I understand I must be more careful in order to avoid CAS functions.

(I thought I had to prefix them all with "CAS." when called from HOME.)

You learn something new every day.

Thanks,

/Lennart Börjeson
Stockholm, Sweden
Find all posts by this user
Quote this message in a reply
11-26-2015, 06:38 AM
Post: #13
RE: Bug? accessing LOCAL var in shared scope
Hello,

the CAS.name syntax is only necessary if there is a conflict with a home function.
for example CAS.sin will call the CAS sin from home. sin would call the home sin.

But when a function exists only in cas, you can call it directly.

Cyrille

Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP.
Find all posts by this user
Quote this message in a reply
11-26-2015, 12:24 PM
Post: #14
RE: Bug? accessing LOCAL var in shared scope
Hi Cyrille,

Thank you for your explanation about Home and CAS variables.
You write about; general rule, CAS/Home share functions, mixed cases, some exceptions, most mixed case functions, app/main functions, etc.

I have read more threads about Home/CAS functions/commands. I think it is still confusing, specially for me.
My question is; which of ALL functions are specially for Home, which are for CAS, which are the same for Home and CAS and what are the exceptions?

As an example:
SIN for Home and sin for CAS.
In the catalog you can only select SIN in uppercase and not in lowercase. My simple conclusion is that SIN in uppercase is a Home function, but you can also use it in CAS but you must type in lowercase and that is not selectable in the catalog.
Proposal:
Don't use a general rule but use a straight forward rule with no exceptions; everything in uppercase are Home functions and everything in lowercase are CAS functions.
So, implement in the catalog also sin in lowercase, do this for all other (shared) functions.
Do it consistently/logically, then you have never questions about which are Home and CAS functions (I hope).
Implement also other hidden functions in the catalog.

Thanks!

— Dirk Hartland
Find all posts by this user
Quote this message in a reply
11-28-2015, 11:58 AM
Post: #15
RE: Bug? accessing LOCAL var in shared scope
(11-26-2015 12:24 PM)Dirk.nl Wrote:  As an example:
SIN for Home and sin for CAS.

The function used depends on the environment from where the catalog is opened. While in CAS, sin() is returned to the command line. If you insert π in the parentheses and hit ENTER you get SIN(π) in the history and 0 as the result.

The rewriting to uppercase looks a bit strange but the zero result proves that the CAS.sin function is called.

Marcus von Cube
Wehrheim, Germany
http://www.mvcsys.de
http://wp34s.sf.net
http://mvcsys.de/doc/basic-compare.html
Find all posts by this user
Quote this message in a reply
11-28-2015, 06:22 PM
Post: #16
RE: Bug? accessing LOCAL var in shared scope
Hi Marcus,

When I select the catalog in CAS, I see SIN in uppercase. Conclusion, it's a Home function, but maybe yes or no, after selecting it, it will be copied in lowercase to the command line. New conclusion, if you are not be sure if it is also a CAS function, try to copy it to the command line!

I have used length() in a Home program, it was not copied in uppercase, but it works in my program! A lowercase CAS function that works well in a Home program without CAS. before the function!
I think that the difference (maybe not the good word for it) between Home/CAS is not consistent enough. Request to HP; make this more clearer!!

— Dirk Hartland
Find all posts by this user
Quote this message in a reply
Post Reply 




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