One more thing: now that we have dedicaded keys for UNITS and DIRS, making them first-class citizens in the CATALOG seems overkill. Why not restoring the original 42s catalog, with FCN and MEM on the first page ? FCN especially can be accessed often, and it is cleaner to stick with the original 42S behaviour, making the extra features accessible on extra keys... My 2 cents.
Thomas, in your post #305, you ask about TVM. May be it is availaible to use the program name 'FINANCE' in your programs collection. It is coming from HP17, I use it sometime and the TVM is the solver form.
Good day.
Yes, but Plus42 already has the TVM functions, I implemented them in the equation language. I just need to do some work to expose that functionality in the RPN environment.
The existing functions are a bit cumbersome in RPN mode, since they all take six parameters: the four knowns of N, I%YR, PV, PMT, and FV, and two additional parameters to specify begin/end mode and the number of payments per year. You need NSTK mode just to be able to push all those parameters onto the stack.
One option would be to simply create an equation like N=N(I%YR:PV:PMT:FV:P_YR:BEGIN), pass it to EQNSLV, and rely on the SOLVER menu and the direct solver's ability to directly solve this equation. But that seems a bit messy. If I can't get that to work the way I want, I'll just implement the desired functionality directly, which will mean more work to implement it, but should result in a cleaner user interface.
I just realized I forgot to mention an important detail regarding the parameter count check (
here): the code generated by the equation compiler uses a built-in function named →PAR to assign the actual parameters to the local variables the function expects, and that →PAR function now takes an extra parameter, namely, the supplied parameter count, and code generated by the equation compiler now provides that parameter.
What this means is that the code generated by the function compiler
before this change is not correct for the current execution environment, and is going to misbehave in very non-obvious ways if executed. To prevent this, please be sure to re-parse any equations you may have that call other equations or user code functions. (Calls to built-in functions are not affected.)
New update:
1. Implemented the TVM menu.
2. The Plus42 skin is now built in. Make sure to delete your local copy, or it will override the built-in one, and that would be bad, because there have been a few changes!
3. In the CATALOG, FCN/DIRS and MEM/UNITS are now swapped only when using a Free42 skin, not when using the Plus42 skin, since it has DIRS and UNITS right on the keyboard, so they don't need to be in the first row of the catalog.
4. When using the Plus42 skin, Shift-0 activates TVM; with Free42 skins, it still activates TOP.FCN.
New update:
1. Fixed programmability of TVM functions.
The TVM functions, N, I%YR, PV, PMT, and FV, exist in two flavors: one that is used in equations, and another, which I implemented today, for RPN mode. Both sets of functions perform the same calculations, of course, but the equation-mode functions take their parameters from the stack and return their results only to the stack, while the RPN-mode functions take their parameters from variables, and return their results to the stack and those same variables.
In the previous build, the RPN-mode functions weren't programmable. They are now, and they can be distinguished by their names: the equation-mode functions are now named $N, $I%YR, $PV, $PMT, and $FV, while the RPN-mode versions have no dollar signs in their names.
Even though their names have changed, the equation-mode functions still use the same XROM codes, so this change has no impact on previously generated code for compiled functions.
When I interpret the code correctly, existing skins can be converted to Plus42 skins and then a line with Flags: 7 indicates it is a Plus42 and not a Free42 skin. I assume that, at least for now, loading a Plus42 skin in Free42 won't be a good idea?
The "flags" line is a combination of these options: 1 = put FCN on the first row of CATALOG and DIRS on the second, instead of the other way around; 2 = put MEM on the first row of CATALOG and UNITS on the second, instead of the other way around; and 4 = put TVM on Shift-0 instead of TOP.FCN. When there is no "flags," that's the same as Flags: 0.
You can use the Plus42 skin in Free42, but the second keyboard row won't be very useful...
Bitflags in a textfile... It has been a long time since I've seen that. It has gotten a bit out of fashion these days. :-)
(01-30-2022 08:10 PM)Thomas Okken Wrote: [ -> ]You can use the Plus42 skin in Free42, but the second keyboard row won't be very useful...
Perhaps you could add a method to Free42 to ignore those buttons when Flags are present?
Are there any plans to adapt the landscape skins any further?
I'm trying to make sure Plus42 is usable even when used with skins designed for Free42... Adding logic to Free42 to make it work with skins designed for Plus42 isn't on my roadmap.
But if anyone wants to take the Plus42 skin and remove the second row of keys, while keeping the dedicated function keys, I'll be happy to add it to my collection of skins for Free42!
(01-30-2022 08:33 PM)johanw Wrote: [ -> ]Are there any plans to adapt the landscape skins any further?
I am planning to create a landscape skin, and also a second portrait skin, one that fits better on 16:9 screens. Those will be built into the iOS and Android versions. The 16:9 portrait skin will be based on the current Plus42 skin, with the keyboard rows moved closer together and the bezels made smaller. I haven't really thought about the layout of the new landscape skin yet, but it will be based on one of the tyge_nova skins, to get a matching visual style for both orientations.
Hi,
I am asking myself if you have in mind to implément the all calculations with %, procentages in business.
In my HP19 B, Business consultant II, we see this in page 56 of manual (in french). But may be I ask too many things
BTW, I love the blue light around the keys when we press !
(01-31-2022 09:51 AM)ggauny@live.fr Wrote: [ -> ]I am asking myself if you have in mind to implément the all calculations with %, procentages in business.
Not right now, but possibly later...
New update:
1. Setting P/YR to 12 initially now, which should be a bit more useful than 0.
2. P/YR and BEGIN / END indication in header line while TVM is active.
3. Fixed EQN.FCN menu stickiness.
4. DIRS and UNITS, when entered using the dedicated keyboard keys, now use a menu level between application menus and plain function menus. This means you can, for example, use functions from UNIT.FCN without losing your place in UNITS, and do all this on top of SOLVER, without losing your place there either.
The to-do list for the first official release is getting short: just a couple of skins, and the GRAPH menu. Of course the GRAPH menu could be a lot of work, since I haven't even figured out what I want to put there yet!
New update:
1. P/YR now restricted to integers in the range 1 to 999.
2. Displaying P/YR and BEGIN / END mode as a message when entering the TVM application menu, if the header isn't active (i.e. HEADER is off, or the display has fewer than 4 rows).
Not much going on until work starts on GRAPH...
New update. More little things:
1. In the TVM app menu, when the header is turned off, or not showing because the display has fewer than 4 rows: show the P/YR and BEGIN / END information banner whenever P/YR or BEGIN / END settings are changed.
2. The messages shown by pressing a variable key with Shift, in VARMENU, SOLVER or ∫f(x) menus, or TVM, are supposed to go away after 2 seconds or after the key is released, whichever comes later... but they weren't disappearing if the key was held down for more than 2 seconds. (Free42 has this bug as well; it will be fixed in the next release.)
(01-31-2022 12:04 AM)Thomas Okken Wrote: [ -> ]I am planning to create a landscape skin, and also a second portrait skin, one that fits better on 16:9 screens. Those will be built into the iOS and Android versions. The 16:9 portrait skin will be based on the current Plus42 skin, with the keyboard rows moved closer together and the bezels made smaller. I haven't really thought about the layout of the new landscape skin yet, but it will be based on one of the tyge_nova skins, to get a matching visual style for both orientations.
Is it possible to minimize skin borders (i.e. reduce bezel borders) to gain room for larger screen and more distanced keys?
(02-02-2022 07:15 PM)Ajaja Wrote: [ -> ] (02-02-2022 05:56 PM)Marco Polo Wrote: [ -> ]Is it possible to minimize skin borders (i.e. reduce bezel borders) to gain room for larger screen and more distanced keys?
I don't like the big borders too and I made some changes.
There are screenshots how it looks and the skins.
That's what i had in mind.
Furthermore, you have an higher font for stack. I like it as the standard one is somewhat too small for my eyes. How did you obtained it?
For me the best would be the 48sx/gx font.
Regarding GRAPH functions, there is already a good part that works on this fantastically flexible screen. PIXEL and AGRAPH work across the screen. From run mode you can use ROW+/- and COL+/- to adjust the screen resolution so that graphs with arbitrary resolution can be drawn. Using ROW+/- and COL+/- is not (yet?) possible from within a program. This Plus42 calculator outperforms the HP42s in all areas. Fantastic!
(11-25-2021 07:00 PM)Thomas Okken Wrote: [ -> ] (11-25-2021 02:10 PM)rprosperi Wrote: [ -> ]For some future enhancement, how about a feature that lets you paste a string with a valid algebraic equation (similar to "∫(X^4:X:0:1)") and it creates an equivalent 42 FOCAL RPN program? Now that would be a very Magic Paste.
Well, you can paste an equation, PARSE it, and EVALuate it, and when you then switch to PRGM mode, you'll see the generated code.
? I must be doing something wrong, because I can't see any generated code. Maybe I missed the feature becoming unavailable somewhere in the 15 pages of this thread.
Cheers, Werner
The generated code isn't really hidden, but I did add a bit of logic that will prevent you from seeing it in the most common scenario: when an equation is executed from the keyboard, the final RTN sets the program pointer back to the last "normal" user code location, rather than leaving it just after the final RTN. But you can still see the generated code if you SST into it, and when you execute equations in TRACE mode.