Threaded Mode | Linear Mode

Vincent Weber · (This post was last modified: 03-06-2021 06:10 PM by Vincent Weber.)

(02-25-2021 10:46 PM)rprosperi Wrote:
(02-25-2021 05:39 PM)Thomas Okken Wrote: The way I see it, you should be able to write, for example,

QUAD:X^2-3*X+2

Or

LBL "QUAD" MVAR "X" RCL "X" X^2 LASTX 3 * - 2 + END

and use both exactly the same way, calling them using XEQ, or from SOLVE or INTEG.

This beings up an interesting point - if the user has in fact created an RPN program and an equation with the exact same name, which would be used if invoked? It's probably best to not allow one if the other exists, to avoid ambiguity... then again that's also hard as what if you edit a program's name from something non-conflicting to something that does conflict, and other weird scenarios... Hmmm???

Reading again this interesting discussion made me think of something: the 35S handles equations in programs not by pointing to the equation list using a name, but directly: you enter the equation in the program by pressing EQN, this puts the equation in the program as a single step, directly readable when reviewing the program. Quite convenient. A flag indicates whether this step should be treated as a mere comment (just text to be ignored) or as an actual equation to evaluate.

Now I like your solution, Thomas, of calling equations by names, just as programs. It should indeed be kept. But this is not 100% satisfactory, because (i) you don't directly see what equation this is when reviewing the program, you need to go to the equation list for that, and (ii) this equation list will be quickly polluted with small equations that should really kept private within the program they belong...

Could we imagine (probably not now, but after the parser is done) that while in program mode, going to SOLVER then selecting the equation list symbol would allow you to type directly an equation in the program, that will be treated either as a comment or an actual equation, depending on a flag ? When reviewing this step, the equation editor would be launched so that you can scroll/edit...

Thanks and cheers,

Vincent

Vincent Weber · (This post was last modified: 03-06-2021 06:02 PM by Vincent Weber.)

(02-25-2021 05:39 PM)Thomas Okken Wrote:
(02-25-2021 05:32 PM)Vincent Weber Wrote: Also, it would be great to define functions rather than just equations, like DEF F(X,Y,Z)=X+Y+Z, and reuse them in either equations or RPN program.

The DEF syntax isn't needed. The function already defines its formal parameters simply by using them, i.e. the mechanism by which the calculator decides which variables to show in the CALC menu.

The way I see it, you should be able to write, for example,

QUAD:X^2-3*X+2

Or

LBL "QUAD" MVAR "X" RCL "X" X^2 LASTX 3 * - 2 + END

and use both exactly the same way, calling them using XEQ, or from SOLVE or INTEG.

(An expression containing an equals sign would be evaluated by evaluating the LHS and RHS separately and then subtracting them from each other. I believe this is how the numerical solver in the 17B and 27S works as well. Conversely, an expression without an equals sign is interpreted by adding =0 to it when solved symbolically.)

Also given this another thought. How will this work to reuse functions in other equations ? Will the implied ordering of variables based on "first appeared / first in the list", i.e if I define F:X+Y+Z, then using F(1:2:3) in another equation will mean calling F with X=1, Y=2, Z=3 ? Then we need to keep in mind that the order of appearance of variables in the 27S can be altered using G(), e.g. F:X+Y+Z+Y^2 will show X,Y,Z, but F: X+G(Y)+Z+Y^2, while functionally equivalent, will show X,Z,Y - not too sure how to articulate that the order of formal parameters for a function...

Cheers

BruceH · 03-06-2021, 07:10 PM

(03-05-2021 12:37 AM)Vincent Weber Wrote: Hi Thomas,
Cool !
Btw I think I found a non-disruptive way of entering one-step complex numbers, à la 35S, like I mentioned before.
While in number entry mode, there are two keys that are forbidden to type twice in a row: "." and "E". So on the second keypress, "." could be changed to "i" and "E" to "theta", thus allowing complex entry without altering 42S normal behaviour, nor changing the skin. This also could be used in equation mode, to solve complex values (and allowing complex equation variables) symbolically when possible, as discussed earlier.

What do you think ?

Cheers

On the HP32SII pressing 1..2 enters 1/2. What if we ever wanted to introduce a fraction mode? ;-)

Vincent Weber · (This post was last modified: 03-06-2021 08:07 PM by Vincent Weber.)

(03-06-2021 07:10 PM)BruceH Wrote:
(03-05-2021 12:37 AM)Vincent Weber Wrote: Hi Thomas,
Cool !
Btw I think I found a non-disruptive way of entering one-step complex numbers, à la 35S, like I mentioned before.
While in number entry mode, there are two keys that are forbidden to type twice in a row: "." and "E". So on the second keypress, "." could be changed to "i" and "E" to "theta", thus allowing complex entry without altering 42S normal behaviour, nor changing the skin. This also could be used in equation mode, to solve complex values (and allowing complex equation variables) symbolically when possible, as discussed earlier.

What do you think ?

Cheers

On the HP32SII pressing 1..2 enters 1/2. What if we ever wanted to introduce a fraction mode? ;-)

I thought of this.
I personnally couldn't care less about the fraction mode, it is not on my wishlist. For exact fraction conversion on the 42S, we have the great user program ->QPI that is way more powerful than the 32SII/35S mode (can also deal with PI, LN, SQRT).
For approximated mode, I personnally don't need that. Now I understand from Valentin's feature request document that engineers sometimes need this to gear something, but I guess a user program could take care of this.

Of course, should Thomas decide that this fraction mode is useful, that would conflict with my suggested solution for one keystroke complex number entry, indeed...

**rprosperi** · 03-06-2021, 08:13 PM

(03-06-2021 04:38 PM)Vincent Weber Wrote: Reading again this interesting discussion made me think of something: the 35S handles equations in programs not by pointing to the equation list using a name, but directly: you enter the equation in the program by pressing EQN, this puts the equation in the program as a single step, directly readable when reviewing the program. Quite convenient. A flag indicates whether this step should be treated as a mere comment (just text to be ignored) or as an actual equation to evaluate.

Now I like your solution, Thomas, of calling equations by names, just as programs. It should indeed be kept. But this is not 100% satisfactory, because (i) you don't directly see what equation this is when reviewing the program, you need to go to the equation list for that, and (ii) this equation list will be quickly polluted with small equations that should really kept private within the program they belong...

Could we imagine (probably not now, but after the parser is done) that while in program mode, going to SOLVER then selecting the equation list symbol would allow you to type directly an equation in the program, that will be treated either as a comment or an actual equation, depending on a flag ? When reviewing this step, the equation editor would be launched so that you can scroll/edit...

Very interesting suggestion!! I like it! Smile

For me, simply letting the user pick an existing equation to insert into the current program (retaining other features as you've explained, e.g. comments) is plenty good enough; I see no need to include the ability to create/edit the equation while already in the program editor, that seems unnecessary complexity. Simply let the user step through a list of currently defined equations to select the one to insert.

An issue to consider is how to treat such an 'inserted' equation if the user chooses to delete the equation from the set of stored. Ultimately, this is no different from a normal [XEQ] "ABC" instruction when the user has removed the "ABC" program, I only bring it up here to note it for consideration when building it, assuming this makes sense in the overall scheme.

This will be a nice touch!

**rprosperi** · 03-06-2021, 08:20 PM

(03-06-2021 05:48 PM)Vincent Weber Wrote: Also given this another thought. How will this work to reuse functions in other equations ? Will the implied ordering of variables based on "first appeared / first in the list", i.e if I define F:X+Y+Z, then using F(1:2:3) in another equation will mean calling F with X=1, Y=2, Z=3 ? Then we need to keep in mind that the order of appearance of variables in the 27S can be altered using G(), e.g. F:X+Y+Z+Y^2 will show X,Y,Z, but F: X+G(Y)+Z+Y^2, while functionally equivalent, will show X,Z,Y - not too sure how to articulate that the order of formal parameters for a function...

The changing order of the formal arguments has long puzzled me and I've always thought that was some fall-out of the specific implementation they used (i.e. possibly not having sufficient resources in ROM/RAM to reorder it, just spit them out as they are produced - possibly from bolting L() and G() onto the core, later in development); since one can input the parameters in any order, the displayed sequence isn't a driver, and with more resources available, assume the original order could be preserved. But maybe I've missed something subtle...

Vincent Weber · 03-06-2021, 08:21 PM

(03-06-2021 08:13 PM)rprosperi Wrote: Very interesting suggestion!! I like it!

For me, simply letting the user pick an existing equation to insert into the current program (retaining other features as you've explained, e.g. comments) is plenty good enough; I see no need to include the ability to create/edit the equation while already in the program editor, that seems unnecessary complexity. Simply let the user step through a list of currently defined equations to select the one to insert.

An issue to consider is how to treat such an 'inserted' equation if the user chooses to delete the equation from the set of stored. Ultimately, this is no different from a normal [XEQ] "ABC" instruction when the user has removed the "ABC" program, I only bring it up here to note it for consideration when building it, assuming this makes sense in the overall scheme.

This will be a nice touch!

The 32SII/35S manage this very smoothly, with no complexity from a user perspective. Of course to do this Thomas will have a bit of work to do - adding another instruction type for equations in programs. We'll see what he thinks, but that seems doable for me.
As I mentioned, if you have 'XEQ NAME" rather than the actual equation in the program, the drawback is that the program is less readable - you have to go the equation list to see what it refers too. Also, your equation list (which is global to the calculator) will soon be crowed with lots of small equations that are relevant only to one particular program - which makes this list less easy to read and maintain. I think both systems should coexist...

Cheers

Vincent Weber · 03-06-2021, 08:26 PM

(03-06-2021 08:20 PM)rprosperi Wrote: The changing order of the formal arguments has long puzzled me and I've always thought that was some fall-out of the specific implementation they used (i.e. possibly not having sufficient resources in ROM/RAM to reorder it, just spit them out as they are produced - possibly from bolting L() and G() onto the core, later in development); since one can input the parameters in any order, the displayed sequence isn't a driver, and with more resources available, assume the original order could be preserved. But maybe I've missed something subtle...

I don't think that there is any ressource problem here. Being able to change the display order of variables from the order of appearance in the equation is a good UI confort feature, as there is no reason why these 2 orders should be the same. You may want to show the variables in order of frequency of change when solving a problem, which is good for the UI...

Thomas Okken · 03-07-2021, 12:10 AM

Equation list clutter will hopefully be less of an issue once I implement directories.
No comment on the equations-in-programs idea for the time being!

BTW, Vincent, have you ever encountered another UnsuppVarType object after that first time? I haven't been able to get that to happen myself, and haven't noticed anything while reviewing the code, but I can't just close this issue without understanding what happened. It doesn't seem likely it was a cosmic ray...

Vincent Weber · 03-07-2021, 12:18 AM

Hi Thomas,

Yes, I understand you want to think it over, about the equation-in-programs, it is heavy stuff Smile

So there will be directories of equations ? How will this work since equations are stored in a single matrix ?

And what do you think about my reasonning about F:X+Y+Z and F(1:2:3) (in a earlier post ) ?

Regarding UnsupVarType, it didn't happen again, but I have stopped playing the fool with STR stuff. I'm not too sure about how I got there in the first place...

Cheers

Thomas Okken · 03-07-2021, 12:45 AM

(03-07-2021 12:18 AM)Vincent Weber Wrote: So there will be directories of equations ? How will this work since equations are stored in a single matrix ?

No, directories for programs and variables. Since the equation list is stored in a variable, it is thus localized as well. With something like PATH so you can keep commonly used stuff somewhere out of the way where it doesn't clutter up your catalogs but is still accessible. Details to be worked out...

Thomas Okken · 03-07-2021, 12:53 AM

(03-06-2021 05:48 PM)Vincent Weber Wrote: Also given this another thought. How will this work to reuse functions in other equations ? Will the implied ordering of variables based on "first appeared / first in the list", i.e if I define F:X+Y+Z, then using F(1:2:3) in another equation will mean calling F with X=1, Y=2, Z=3 ? Then we need to keep in mind that the order of appearance of variables in the 27S can be altered using G(), e.g. F:X+Y+Z+Y^2 will show X,Y,Z, but F: X+G(Y)+Z+Y^2, while functionally equivalent, will show X,Z,Y - not too sure how to articulate that the order of formal parameters for a function...

You can always force the order of parameters by putting them at the front of the equation like 0*X+0*Y+0*Z+<rest of equation>. It's not very elegant but it works, and I think I even read that suggestion in one of the manuals somewhere...

Vincent Weber · (This post was last modified: 03-07-2021 12:59 AM by Vincent Weber.)

(03-07-2021 12:53 AM)Thomas Okken Wrote:
(03-06-2021 05:48 PM)Vincent Weber Wrote: Also given this another thought. How will this work to reuse functions in other equations ? Will the implied ordering of variables based on "first appeared / first in the list", i.e if I define F:X+Y+Z, then using F(1:2:3) in another equation will mean calling F with X=1, Y=2, Z=3 ? Then we need to keep in mind that the order of appearance of variables in the 27S can be altered using G(), e.g. F:X+Y+Z+Y^2 will show X,Y,Z, but F: X+G(Y)+Z+Y^2, while functionally equivalent, will show X,Z,Y - not too sure how to articulate that the order of formal parameters for a function...

You can always force the order of parameters by putting them at the front of the equation like 0*X+0*Y+0*Z+<rest of equation>. It's not very elegant but it works, and I think I even read that suggestion in one of the manuals somewhere...

Yes, the 19B/27S technical application book (the Bible for the subject - covers all tricks of L(), G(), S() - the important solving function, IF and SIGMA) mentions that: to reorder, you can use 0x, and/or G() that will skip the variable.
Anyway, so I will be able to use F(1:2:3) in another equation ? That's good news Smile

Thomas Okken · 03-07-2021, 01:15 AM

Yes, programs and equations will all be able to call each other. And yes, I was planning to make the order of parameters in the F(A:B:C) notation match the order in which they are shown in the CALC menu, or the order of MVARs when calling a program. I suppose an additional, position-independent syntax like F(X=1:Y=2:Z=3) is also an option, but that's a minor implementation detail, I'm not worrying about that yet.

Thomas Okken · 03-07-2021, 04:19 AM

On further thought, the order of parameters could be specified as part of the equation name, so instead of FOO:3*X+5*Y+2 you could write FOO(X:Y):3*X+5*Y+2. As before, without the explicit parameter list, the order of the parameters would be the order in which they are found when scanning the equation from left to right, not counting occurrences inside G() etc.

Vincent Weber · 03-07-2021, 07:28 AM

That's excellent Thomas, that's going to be a killer !
Where are you with the parser ? So far so good ?

Cheers

Thomas Okken · 03-07-2021, 07:46 AM

It's getting there. I'm using a hand-rolled recursive-descent parser that I originally wrote in Java and used in a simple function plotter. Translate to C++, adapt to changes in precedence and syntax, hook into the Free42 UI and execution environment. Lots and lots of details to deal with but no big challenges...

Vincent Weber · (This post was last modified: 03-07-2021 07:59 AM by Vincent Weber.)

Thanks Thomas, I can't wait, that's going to be the ultimate pocket programmable calculator, not only taking the best out the 41CX/42S/27S/35S, but also going way further in programming with this function stuff !

Don't forget the S() function (solving), it can mess up with your algorithm (doing different actions depending on the variable you solve).

Cheers

johanw · (This post was last modified: 03-09-2021 01:42 AM by johanw.)

I know it's off-topic and also discussed before, but now Free42 is getting an overhaul, could you also consider allowing non-integer inputs for the factorial function? All other HP's (or reproductions) I know, like my DM15's, interpret x! = Gamma(x + 1).

Or are there programs that would be broken by this change?

Thomas Okken · 03-09-2021, 03:43 AM

(03-09-2021 01:41 AM)johanw Wrote: I know it's off-topic and also discussed before, but now Free42 is getting an overhaul, could you also consider allowing non-integer inputs for the factorial function? All other HP's (or reproductions) I know, like my DM15's, interpret x! = Gamma(x + 1).

No, I'm not going to do that, because...

(03-09-2021 01:41 AM)johanw Wrote: Or are there programs that would be broken by this change?

...there is no way to know that.

I assume the reason why the HP-42S has separate N! and GAMMA functions is because of compatibility with the HP-41C FACT function, which takes only integer arguments, and for the sake of compatibility with the 42S, I'm keeping it that way as well.