How much memory may a HPPL program use on a G2?

[jte]

(09-21-2023 04:27 AM)komame Wrote:  

(09-21-2023 04:19 AM)jte Wrote:  Yes, this seems quite natural. At least to us two, as when thinking about the more general REPLACE semantics, this popped into my head too. But then I thought: wouldn't it be nice to be able to do multiple rules of this sort? And that leads to REPLACE(str1,{{"é", "è", "ê"},{"à","â"}}, {"e","a"})! Hmmm...

The solution proposed by Tyann (a single multi-rule) makes sense and will indeed be more efficient. However, if you add more rules, we go back to the topic of iteration because each multi-rule must be considered independently, and here there will be no performance gain beyond avoiding the PPL call itself.
⋮

Well, in either case, I'd think I'd have the REPLACE code look for the special case and employ a special routine when that case is identified.

While I didn't design or implement PPL, I've implemented special-case handling in some parts of the project. The Function app, for example, doesn't use the main PPL interpreter for the sorts of things typically graphed by high-school students. Instead, it uses something closer to a "bytecode" interpreter. Before graphing begins, the PPL (the part after the "F1(X)=") is analyzed. If it is of a simple-enough form to fit the special-case interpreter, a simple list of instructions is generated for an abstract machine (of a "push" form - things like "add register 1 to register 5, put the result in register 7"). Things like common subexpressions are recognized and only evaluated once (when evaluating a user-defined function for a particular value).

I implemented this first for the Graph 3D app as even very simple plots do involve many function evaluations. With the Graph 3D app, the analysis (of PPL structures) breaks apart the function so that things like SIN(X) can be evaluated only once per column rather than once per cell. (The Function app similarly analyzes for dependencies, but there, in effect, it is just constant folding as the categories are either "depends on X" or "doesn't depend on X".) The "bytecode" evaluation engine should produce identical numerical results (down to the last digit) as the standard PPL interpreter.

My intuition is that part of the speed variability that can be seen with the standard PPL interpreter has to do with the heap. (The special-case interpreters I've just mentioned above do not use the heap during evaluations.)

(The "first for the Graph 3D app": the Advanced Graphing app also uses a "bytecode" interpreter, and I implemented this earlier, although that case is a bit different.)

There's a whole variety of approaches that could be considered for increasing the speed of PPL evaluations. Things like benchmarks can help guide development. To date, my focus has been more on the parts typically used by typical high-school students in typical high-school settings (as that was my role).