+- 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: Bug or Feature? val.x:=3 (/thread-17905.html)
Bug or Feature? val.x:=3 - IHarwell - 01-08-2022 09:35 PM
I ran into a curious behavior that I don't fully understand. Anyone know if this is a bug or feature?
In CAS mode, enter "val.x:=3". This constructs a special type of list (I'm not sure what the precise difference is, but it IS different somehow.)
At this point, val is a list according to TYPE(), but is shown like a matrix. The value of val is [[x 3]].
This looks like some form of associative list to my eyes, but this is where the weirdness starts.
Entering "val.x:=5" results in a curious situation. The value of val is now [[x 5][x 5]].
It appears that the instruction has both modified the existing entry and added a new identical row. I can't seem to figure out why this is. My current best guess is that the "val.x" syntax basically uses "val" as a separate namespace from the global CAS space, and the value of "val" looks like the sequence of instructions within that namespace.
Does anyone know more about this? What is the "val.x" syntax (AKA "val::x") in CAS mode?
What is this supposed to be used for, for example?
Short Addendum: I ran across this while looking for a way to better manage variables for complex systems. For example, using Beam1.tau to represent torque on Beam1, Beam1.F to represent the set of forces on Beam1, etc. The same could then be repeated for Beams 2 through N, and the resulting calculations would be, in theory, easier to follow. The main problems with this are that the CAS system doesn't show what you type before the ".", a mistake in entering values in the "modify AND add" system means you have to rebuild the whole Beam if you make a mistake in one variable, and I'm still unsure how the syntax above works with the rest of the CAS system.
As an aside, if I could get it to work, it would allow at least partial OOP in CAS programs. That would be really nice, as the Python implementation is still buggy and has significant startup lag and has quite a few bugs in it that make it impractical for larger programs.
RE: Bug or Feature? val.x:=3 - Joe Horn - 01-09-2022 01:46 AM
Turning off "Textbook Display" (Home Settings, page 2), or echoing the result onto the command line, displays the result as:
folder[[x,3]]
No idea what that means. I was not aware that Prime even supported folders.
RE: Bug or Feature? val.x:=3 - IHarwell - 01-11-2022 11:03 PM
Okay. Playing around with this gave some interesting results.
First, setting up a container variable using "{[x,5],[y,3]}->v" allows use of "v.x" and "v.y". The former evaluates to 5, and the latter to 3. This is effectively an associative list of sorts. Note that while "{{x,5},{y,3}}->v" also works, it doesn't mesh well with the "v.x:=8" syntax. The assignment syntax creates a new entry in the list in a vector. UNION(v,v) will consider the list form "{x,8}" to be different from the vector form "[x,8]" and won't correctly remove duplicates.
Second, the issue of "v.x:=8" creating a new entry in the table can be addressed by UNION(v,v), or INTERSECT(v,v). Still looking for a better way to remove redundant entries.
Third, I haven't found a way to cleanly parameterize the expressions yet. The best I can currently do uses "CAS(eval("v."+x))" where "x" is the name of the variable. It also works with a string containing the item to look up.
Fourth, I don't think you can reference an unassigned member of "v" in formulae. For instance, "v.s=v.y+v.x" is an invalid command with the example.
Finally, I think this does open the door for limited object-oriented programming in PPL. It would be a pretty manual process, but here's an example of a "method" in this system:
Code:
m(this):=
BEGIN
LOCAL p:=this;
RETURN p.x+p.y;
END;And this is an example of a property "set" method:
Code:
set_x(this,val):=
BEGIN
LOCAL p:=this;
p.x:=val;
p:=UNION(p,p);
RETURN p;
END;
// USAGE
v:=set_x(v,5);The syntax is still cumbersome, so I'm still looking at how to clean it up, but it looks like it can be made to work as-is.
As always, any additional input would be greatly appreciated, especially if any HP guys run across this. If this is an unintentional thing, it'd be nice to know if it'll still be around in a few updates.