Free42: Unlimited-length strings and other type extensions

[Dave Britten]

(01-26-2021 04:35 PM)Werner Wrote:  XTOA already does that (the ARCLM part I mean)
Werner

Oh yes, so it does! There would still need to be a function that recalls a full alpha register from multiple numbered storage registers, though.

[Werner]

(01-27-2021 01:34 PM)Dave Britten Wrote:  There would still need to be a function that recalls a full alpha register from multiple numbered storage registers, though.

Ah, but with FUNC, we can easily write that ourselves:

Code:

 LBL "ARCLX"
 FUNC 00
 LBL 10
 ARCL IND ST X
 ISG ST X
 GTO 10
 END

Werner

[J-F Garnier]

Although this is definitely interesting, my personal feeling is that it goes too far from what I appreciated in the initial Free42 that was a (much, much) faster HP-42S, with higher accuracy (decimal version with 25 then 34 digits) and lot of memory.
I enjoyed the few past extensions like the time functions modelled from the 41C, and would have appreciated more features from the HP-41 X-functions for running HP-41C programs that use these features, and some kind of HPIL-like I/O for accessing the host file system.

I believe this is the natural evolution of many applications, to be always more powerful, more complex and bigger, but I could also appreciate a simpler version such as a Free32 - a HP-32S replacement with the key Free42 features of speed and accuracy, and some limited extensions such as I proposed here.

Oh yes, I could do it by myself - yet another project idea. Very low priority for now, too many projects in mind and too little time. So if someone shares my point of view, feel free to use any of these ideas...

J-F

[Thomas Okken]

(01-31-2021 05:36 PM)J-F Garnier Wrote:  Although this is definitely interesting, my personal feeling is that it goes too far from what I appreciated in the initial Free42 that was a (much, much) faster HP-42S, with higher accuracy (decimal version with 25 then 34 digits) and lot of memory.

The cost of the features I have added so far is basically zero, they make the executable a few kilobytes larger and they increase the memory footprint by about 30 bytes (that's not a typo). And slower by a few nanoseconds per program step. Unless you stumble across the additions to the MODES and CATALOG menus (and, okay, the STRACE mode I added in the PRINT menu), you won't even notice that anything has changed. And that is important to me, Free42 will always be an HP-42S replacement first and foremost, as far as I'm concerned.

The really advanced functionality that I will be working on from here on out will be in a separate fork, so Free42 will remain the way it is now.

[Thomas Okken]

(01-31-2021 07:04 PM)Thomas Okken Wrote:  The really advanced functionality that I will be working on from here on out will be in a separate fork, so Free42 will remain the way it is now.

Actually, I could do the Free42/Free42+ fork before the point where I added the big stack. Or even earlier, but then I would end up taking away functionality that has already been released, and that feels a bit like cheating.

It is a difficult judgement call, as I'm sure you agree:

(01-31-2021 05:36 PM)J-F Garnier Wrote:  I enjoyed the few past extensions like the time functions modelled from the 41C, and would have appreciated more features from the HP-41 X-functions for running HP-41C programs that use these features, and some kind of HPIL-like I/O for accessing the host file system.

Even most purists enjoy some enhancements. Where to draw the line?

[Thomas Okken]

Filesystem access is not out of the question. A fork with HP-IL extensions does exist: https://github.com/jch42/free42

I have always been reluctant to add a lot of functionality to Free42 precisely because I prefer the elegance of the original myself, but then again, useful but lightweight additions, that don't add significantly to the footprint and don't get in the way in the UI, have happened from time to time, and I think FUNC and RTNYES/RTNNO/RTNERR belong in that category. The big stack seems like a bit of a borderline case, because it did require a lot of code changes, but I felt it was OK to add to the basic Free42 because despite all the code changes, it is nonetheless also quite lightweight.

But with Free42+, the whole idea is to go nuts and put in everything that seems useful, and if that means it ends up being a kind of 48S with RPN, why not?

[SammysHP]

What about doing it the other way around? Add all the bells and whistles to Free42 and create a fork like "Free42 Classic" that only contains features of the real HP 42s. So even features like time and location should be removed from the classic version. If someone wants these features he can use the "normal" version of Free42. As long as all changes are backwards compatible there are only very few reasons to not use that version and if someone prefers a clean version he can use "Free42 Classic".

[Thomas Okken]

That's a possibility... or the regular Free42 could have a setting in the preferences to select "classic" mode, which simply makes all the extra options disappear from the CATALOG, MODES, and PRINT menus, and maybe also prevents those functions from executing, for people using Free42 mainly for running legacy HP-42S programs and who are nervous about compatibility. Completely removing those functions so they're not even in the code just makes maintenance harder, and the cost of leaving them in is negligible.

I prefer for the version with equations, units, and big screen to be separate, and have a new name, so that it can be a separate (and paid) option in the iOS and Android app stores, and people not interested in that upgrade can continue to receive updates to the basic version.

[J-F Garnier]

(02-01-2021 09:50 PM)Thomas Okken Wrote:  That's a possibility... or the regular Free42 could have a setting in the preferences to select "classic" mode, which simply makes all the extra options disappear from the CATALOG, MODES, and PRINT menus, and maybe also prevents those functions from executing, for people using Free42 mainly for running legacy HP-42S programs and who are nervous about compatibility.

Hiding the extra features from the menus would be a nice solution. A "Classic" mode, a bit like the "Authentic speed" setting in Christoph's emulators. So the old-time users (e.g. me) will not be lost with the new commands/settings.
No need to prevent them to run, if the user deliberately or by chance loads a raw file with such extension.
But please don't remove the now "classic" extensions like the time functions and extra HP-41 X-functions. Don't be so purist :-)

(01-31-2021 08:56 PM)Thomas Okken Wrote:  Even most purists enjoy some enhancements. Where to draw the line?

Sure there is no unique point of view regarding enhancements. Valentin recently proposed a whole set of Free42 enhancements in a different direction.
Again my personal point of view, from my own experience of HP calculators/computers: I welcome enhancements that have some roots or connections with the HP calculators of about the same era. This is what drove me in developing the enhanced HP-71 Math Pac 2.
It should not stop you from developing more progressive extensions :-)

J-F

[Werner]

(02-02-2021 09:05 AM)J-F Garnier Wrote:  Valentin recently proposed a whole set of Free42 enhancements in a different direction.

Yes, I saw those, and for once, I did not agree.
I like extensions that we cannot do ourselves, like RTNYES/NO and the unlimited stack, the local variables..
With those, you can implement most of Valentin's suggestions very easily, and have them behave like built-in functions.
I can understand that, with the limited memory and speed of the 41 (and even the 42S) , his suggestions would have been welcome.. but in Free42, and to some lesser extent, the DM42, there is no need to have everything and the kitchen sink installed - a large part of the fun is to create them yourself?
My 2 cents..

Werner

[Thomas Okken]

I'm about to start on long strings... They will be needed anyway in order to fully integrate equations into the type system, and I think I can do them in a way that people will like. There's certainly no danger of the Big Stack controversy here, the Long Strings will be fully backwards compatible, there will be no special mode to use them, just some new capabilities that one can freely use, or safely ignore. And, as with the big stack, if the new capability is not used, the only downside of its presence is the few kilobytes added to the executable.

I'm also going to expose the new List type. That type already exists and I used it to implement FUNC, L4STK, and LNSTK, and it could be manipulated using the same set of functions as strings. The concepts string/characters and list/elements are similar enough to make that pretty intuitive, I think.

(Note that all of this will be in Plus42 only, not in the basic version. Once the basic version is released with the big stack, it will be in maintenance mode; no further enhancements are planned. At least for now. But of course bugs will continue to be fixed.)

Here is a tentative list of functions:

APPEND: adds the object in X to the string or list in Y and returns the combined string or list. If Y is a string, the contents of X will be converted to a string in the same way as ARCL. If Y is a list, X will be added to it unchanged. If X is a list, it will be added to Y as one element.

EXTEND: adds the object in X to the string or list in Y and returns the combined string or list. If Y is a string, the contents of X will be converted to a string in the same way as ARCL. If Y is a list, X will be added to it unchanged. If X is a list, it will be added to Y element by element.

SUBSTR: from the string or list in Z, gets the substring/sublist starting at index Y and ending at index X. If X and/or Y are negative, they are counts from the end, rather than the beginning. The very end of the string or list can be specified by leaving off the 'end' parameter, i.e. by having the string or list in Y and the starting index in X.

LENGTH: returns the length of the string or list in X.

HEAD <param>: removes and returns the first character or element from the string or list named by <param>. If the string or list is empty, skip the next instruction.

REV: reverse the string or list in X

POS: finds the first occurrence of the string or list X in Y. Or with three parameters: find the first occurrence of string or list X in Z, starting the search from position Y.

S→N, N→S: convert string to number or number to string, like ANUM and ARCL
C→N, N→C: convert character to number or number to character, like ATOX and XTOA

XASTO, LXASTO: like ASTO and LASTO, but the entire ALPHA register, not just the first 6 characters.

LIST?: tests whether the object in X is a list

NEWLIST: returns a new empty list

NEWSTR: returns a new empty string

[Thomas Okken]

I uploaded builds for Windows, MacOS, and Linux, of Free42 with the latest bug fixes, and Plus42, with the long string and list functions, as described in my previous post. Android builds to follow tomorrow... Work on equations starts after that.
This is very new and the paint is still wet, so use with caution. I have managed to test it all evening without crashing it, so it seems usable, at least on MacOS.

https://thomasokken.com/free42/download/test/

[Thomas Okken]

Added Android builds.

[Jonathan Busby]

(01-31-2021 05:36 PM)J-F Garnier Wrote:  Oh yes, I could do it by myself - yet another project idea. Very low priority for now, too many projects in mind and too little time.

You just about summed up my problem with the dozens of major ( and perhaps hundreds of minor ) projects that I've started over the years but never fully finished due to my pathological perfectionism

Regards,

Jonathan

[Thomas Okken]

Fixed another bug and uploaded new builds.

(Just one bug, a crash when copying a matrix containing long strings.)

[Thomas Okken]

Fixed a crash in RCL+ and RCL- and uploaded new builds.

[ferni123]

Hi Thomas,

Thanks for the release of Free42 3.0.0!

I have one doubt. Will the unlimited-length strings be part of Free42 or Plus42?

Cheers,
Fernando

[Thomas Okken]

I wasn't planning on adding the long string and list functions to Free42. They're currently only in Plus42... Plus42 really needs them because equations are stored as long strings, and I'll also need them for units.

They could be added easily in Free42 as well. The infrastructure is there.

[richmit]

The little LISPer in me says you can't have lists without map & zip!

The map function takes a single parameter function & a list/string/matrix. It applies the function to every element. It returns a new list/string/matrix of the function results.

map(abs, {1 -2 3}) => {1 2 3}

zip takes a two parameter function and two lists/strings/matrices. It applies the function to the first element of each container, then the second, etc... It returns one list/string/matrix containing the function results.

zip(+, {1,2,3}, {1,2,1}) => {2, 4, 4}

A GETELT would be nice -- i.e. get element of the list/string/matrix. For lists & strings it would take an integer. For a matrix it could take a list like the 28s did, or you could use one (the Nth item in the array) or two (row & column) integers on the stack. This is not ambiguous. If Y has an integer, then we assume Z is a matrix. If Y is not an integer, then we assume it is the collection from which we extract our element.

It would be also be cool if NEWLIST took an integer argument which tells it to make the list from the bottom N stack elements. With an unlimited stack this kind of functionality is more natural.

[ferni123]

Thanks for the quick reply.

On my side, I do not currently have any need for them. I think that the current behaviour is good to keep the spirit of Hp42s. I personally find more useful the functions that you have added to extend the catalog of HP42s. But this is just my personal opinion. I do not know what the rest of the community thinks.