Plus42 Equations, Preview Release

[Thomas Okken]

(06-12-2022 07:26 AM)Ajaja Wrote:  By the way, I find it very convenient to see simultaneously all values (#P, Interest, Principal, Balance) in the top display rows.
Is it possible to use them in user programs in the same way?
Original HP-42s commands VIEW, AVIEW and PROMPT work only with the header row.

Yes, I recently added a new function, XVIEW, to help with that. XVIEW works like AVIEW, except it takes the text from a string in the X register, instead of the alpha register, so you don't have the 44-character length limit.

[Thomas Okken]

For example, to view A, B, and C simultaneously:

Code:

00 { 46-Byte Prgm }
01▸LBL "TEST"
02 XSTR "A="
03 RCL "A"
04 APPEND
05 XSTR "[LF]B="
06 APPEND
07 RCL "B"
08 APPEND
09 XSTR "[LF]C="
10 APPEND
11 RCL "C"
12 APPEND
13 XVIEW
14 END

[Ajaja]

Thanks! Works great with "Line Feed" symbol

[Ajaja]

Playing with equations I found some strange behavior of Plus42 solver. Looks like the iterative search uses old (previous) initial value of variables, not values entered in CALC mode using the interactive menu:

Code:


                     DEG
             810 STO "X"
                     EQN
   EQNSLV '1=0×X+SIN(X)'
               0 STO "X"   <--- by pressing "X" in the interactive MENU
               SOLVE "X"
                     PRX
              810    ***

Is it a bug?

[Thomas Okken]

The solver uses two starting values, not one, and in the scenario you described, you're only providing one starting value. This means that the other starting value will be the previous value of the parameter, which in this case is a root.

To prevent the solver from just dropping straight back on the previous root, be sure to provide two starting values. If you only have one, just enter it twice, for example, 0 STO "X" ENTER STO "X" SOLVE "X" (0 X ENTER X X).

[Ajaja]

Understood. Sorry for newbie questions. I've never used such "equation/solver" approach for programming before and wasn't able to find old HP calculators ROMs to check in Emu42 if it's my misunderstanding of how it should work or a real bug.


I've just started to read "Step-by-Step Solutions: Technical Applications (27S/19B)" about this topic, it's really fascinating

[Thomas Okken]

The thing with the two starting guesses is how the original HP solver works as well. I'd recommend taking a look at the HP-42S manual, chapter 12, to get started with using the solver with programs, and the HP-17B or 19B manuals to get started with using the solver with equations. There are links to all of these manuals on my web site; see the Free42 page for the HP-42S manual, and the Plus42 page for the 17B and 19B manuals:

https://thomasokken.com/free42/#manual
https://thomasokken.com/plus42/#equations

[kwarda]

Hi,

when i'm in the BASE menu, switch to e.g. BINM and enter a invalid number (e.g. 2) and then press '<-' the application crashes (tested on Android and Linux).

In Free42 the wrong inputs are just ignored.

[Thomas Okken]

Noted! Will fix in the next release.

[Steve Simpkin]

(06-12-2022 06:57 PM)Ajaja Wrote:  ...
I've just started to read "Step-by-Step Solutions: Technical Applications (27S/19B)" about this topic, it's really fascinating

Ajaja,
As a quick note, here is a post from the author of that book, Steve Sabin, on his experiences writing it.
https://www.hpmuseum.org/forum/thread-15...#pid149679

[Ajaja]

I'm trying to use named equations recursively in Plus42 v1.0.7 but found that they EVAL very slow. Or maybe I'm doing something wrong.
My test equation is "FIB(N):IF(N≤1:N:FIB(N-2)+FIB(N-1))" and it takes significant amount of time to calculate even for N=30 on my smartphone.
Printer is OFF.
Any hints/suggestions?

(06-13-2022 01:27 AM)Steve Simpkin Wrote:  Ajaja,
As a quick note, here is a post from the author of that book, Steve Sabin, on his experiences writing it.
https://www.hpmuseum.org/forum/thread-15...#pid149679

Thanks

[Thomas Okken]

(06-16-2022 03:20 PM)Ajaja Wrote:  I'm trying to use named equations recursively in Plus42 v1.0.7 but found that they EVAL very slow. Or maybe I'm doing something wrong.
My test equation is "FIB(N):IF(N≤1:N:FIB(N-2)+FIB(N-1))" and it takes significant amount of time to calculate even for N=30 on my smartphone.
Printer is OFF.
Any hints/suggestions?

The number of evaluations of FIB grows exponentially with N. For N=30, FIB is called 2,692,537 times.

It could be sped up a lot using memoization...

[Ajaja]

Yes, I gravely underestimated the scale of the recursion. Just tested, the similar keystroke program works only 10-20% faster:

Code:

00 { 33-Byte Prgm }
01▸LBL "FB"
02 FUNC 11
03 RCL ST X
04 1
05 -
06 X>0?
07 GTO 01
08 X<>Y
09 RTN
10▸LBL 01
11 XEQ "FB"
12 LASTX
13 1
14 -
15 XEQ "FB"
16 +
17 END

P.S. With memorization it's MUCH faster

Code:

FIB(N):0*IF(MAT?(M):0:MROWS(L(M:NEWMAT(N:1))))+0*IF(MROWS(M)<N:MROWS(L(M:NEWMAT(N:1))):0)+IF(N≤1:N:IF(M[N:1]=0:L(M[N:1]:FIB(N-2)+FIB(N-1)):M[N:1]))

[Albert Chan]

(06-08-2022 12:46 PM)Thomas Okken Wrote:  there is a bug in PMT. In BEGIN mode, it should divide the calculated value by 1+i
(where i is the interest rate per period), and instead it multiplies by that factor.

Fix coming shortly!

There is an intuitive way to get the correct factor. Think of n+1 cash flows.

BEGIN mode ⇒ [pv + pmt, pmt, pmt, ..., pmt, fv]

This is equivalent to all payments paid late 1 period, with a bit of interest penalty.

END mode ⇒ [pv, pmt*(1+i), pmt*(1+i), ... pmt*(1+i), fv + pmt*(1+i)]

Shifted to END mode, we are really solving for pmt*(1+i)
To recover payment, BEGIN mode, we *divide* by (1+i)

[Ajaja]

BTW, HP calculators have some peculiarity with calculation of amortization when balance changes sign. At first, comparing results, I thought that Plus42 fails to calculate Interest parameter in AMORT program properly, but after some considerations I realized that HP-17b/19b/27s AMORT program does it mathematically wrong.
There is an example (look at "Interest"):
HP-17bII

Code:

I%YR=              10.00
PV=            10,000.00
PMT=             -514.14
P/YR=              12.00
END MODE

PMTS:1-12
INTEREST=        -756.34
PRINCIPAL=     -5,413.34
BALANCE=        4,586.66

PMTS:13-24
INTEREST=        -209.96
PRINCIPAL=     -5,980.18
BALANCE=       -1,393.52

PMTS:25-36
INTEREST=        -436.70
PRINCIPAL=     -6,606.38
BALANCE=       -7,999.90

Plus42:

Code:

I%YR=              10.00
PV=             10000.00
PMT=             -514.14
P/YR=              12.00
End Mode

PMTS:1-12
Interest=        -756.34
Principal=      -5413.34
Balance=         4586.66

PMTS:13-24
Interest=        -189.51
Principal=      -5980.17
Balance=        -1393.51

PMTS:25-36
Interest=         436.70
Principal=      -6606.38
Balance=        -7999.89

[Vincent Weber]

Yes, we had this interesting discussion with Thomas when he implemented TVM... And actually he is right and HP is wrong

One small difference though, if you set up the amortization table parameters (FIRST, LAST, INC), and exit TVM app and come back, these parameters are gone in both Plus42 and the HP-27S, but on Plus42 the number of payments is reset to 0, whereas on the 27S it is reset to 1, hence you get something (1 entry) if you press "GO".

Thomas, is this intended ?

Cheers

[toml_12953]

(06-17-2022 08:59 AM)Vincent Weber Wrote:  Yes, we had this interesting discussion with Thomas when he implemented TVM... And actually he is right and HP is wrong

So this brings up the question:

Do we want mathematically correct behavior or do we want HP compatibility?

[Marco Polo]

(06-17-2022 09:59 AM)toml_12953 Wrote:  

(06-17-2022 08:59 AM)Vincent Weber Wrote:  Yes, we had this interesting discussion with Thomas when he implemented TVM... And actually he is right and HP is wrong

So this brings up the question:

Do we want mathematically correct behavior or do we want HP compatibility?

IMHO, given that Plus42
- is a unique&peculiar calculator
- has few chances to move to a physical platform
- and considering that the original 42s had no TVM feature to preserve compatibility with
i would want a correct mathematical behavior.
Even the other new features (Units, Algebraic equation solver, etc) should, IMHO, be free to evolve even losing the compatibility with the original HP concept.

Just my two cents

[jonmoore]

The assumption that I would question is that HP is wrong. TVM calculations on the 12C have been proven to be robust by multiple institutions and individuals (within the confines of the calculator's precision).

HP wouldn't continue to sell the 12C 40 years down the line if it had mission-critical errors.

[EdS2]

I notice that 12C isn't listed among the accused:
> after some considerations I realized that HP-17b/19b/27s AMORT program does it mathematically wrong.

Is that important? Does the 12C do differently?