newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(08-08-2019 09:55 PM)compsystems Wrote:  

(08-02-2019 02:29 PM)Claudio L. Wrote:  ... The next target will be the HP Prime hardware ...

And on the new NumWorks-2019?

https://www.hpmuseum.org/forum/thread-89...#pid119642

Don't think so. Because of this. Almost every word in my original post still applies to this newer model, 2 years later. Faster CPU and more flash doesn't even try to close the gap with the Prime hardware.

[Claudio L.]

(08-02-2019 07:57 PM)The Shadow Wrote:  Claudio, it might be worth looking at the PDQ algorithm as a replacement for the ->Q algorithm currently in use. Not only will it fix the "overshooting" problem I mentioned a while back, but it has other desirable properties. (Naturally for use in ->Q the tolerance would be taken from the system settings and one wouldn't bother calculating the error. But the full-blown PDQ might make a worthy command in its own right.)

I did replace the ->Q algorithm with PDQ (not published yet). Works nice but what should be the tolerance for ->Q? I did the obvious: Use the 10^(-prec) where prec is the current precision. However, the algorithm seems to have some glitches. Works great in some cases, bad in others for example:
12345678 13 / ->Q results in '12345678/13' (no surprises there)
12345678 7 / ->Q results in '1.763 667 051E31/9.999 993E24' (note: not all digits survived copy/paste from newRPL Desktop)
Doing ->NUM on this bizarre fraction, I get the original argument *exactly* with all 32 digits matching, so this fraction IS a correct result, just not what I thought I would get: '12345678/7'

(ohhhhhh.... moment) I just figured it out while typing this! Thanks to the forum...
If the argument has already 7 integer digits there's only 32-7=25 digits after the decimal point, so a tolerance of 10^-32 is simply "locking to zero" 7 digits after the last known digit.
So I'm adding 7 zeros after the number, and forcing the system to approximate *that* number.
Clearly, I just need to determine how many "fractional" digits are in the actual argument and use that as tolerance

[The Shadow]

(08-15-2019 10:49 PM)Claudio L. Wrote:  So I'm adding 7 zeros after the number, and forcing the system to approximate *that* number.
Clearly, I just need to determine how many "fractional" digits are in the actual argument and use that as tolerance

Huh! I have to admit, I didn't anticipate that problem, but it does make sense!

Also, it might make more sense to use 5*10^(-prec-1) rather than 10^(-prec). Adjusted for the integer digits, of course!

[Claudio L.]

(08-16-2019 11:21 AM)The Shadow Wrote:  

(08-15-2019 10:49 PM)Claudio L. Wrote:  So I'm adding 7 zeros after the number, and forcing the system to approximate *that* number.
Clearly, I just need to determine how many "fractional" digits are in the actual argument and use that as tolerance

Huh! I have to admit, I didn't anticipate that problem, but it does make sense!

Also, it might make more sense to use 5*10^(-prec-1) rather than 10^(-prec). Adjusted for the integer digits, of course!

Good suggestion, thanks. I now understand the algorithm better, if the tolerance is too tight all you get is:
aaa.bbb ->Q ----> 'aaabbb/1000' simplified, which is what the old ->Q did, and not the smallest "coolest" fraction as PDQ is supposed to produce.

Once it works nicely, I'll release an update for you to test and bug-check on corner cases.

[The Shadow]

(08-16-2019 01:22 PM)Claudio L. Wrote:  I now understand the algorithm better, if the tolerance is too tight all you get is:
aaa.bbb ->Q ----> 'aaabbb/1000' simplified, which is what the old ->Q did, and not the smallest "coolest" fraction as PDQ is supposed to produce.

That's because if the tolerance is too tight, that IS the smallest and coolest fraction. But yes, playing with the tolerance is probably called for to see what gives the nicest behavior.

Looking forward to it!

[Claudio L.]

All ROMs updated to 1288.

Small incremental changes...

* It has all the rules engine fixes for all previously reported issues (I'm sure there's more, so please keep test-torturing that engine until we make it good). Still not implemented the cool syntax we came up with to include hints and constraints in expressions. That's still in the TODO list, sorry.

* Replaced the algorithm of ->Q with PDQ by Joe. I think it works well.
* Reworked the menu for binary numbers, adding a base "cyclic" converter.
* Some keyboard moves...
a) Subscripts and superscripts are now on the alpha-hold plane.
b) :-> (rule separator) moved from Enter to RS-hold-0 (made sense to me)
c) | (given that) operator moved from Enter to LS-hold-2
d) ->Q is now at LS-Enter and LS-hold-Enter
e) Added the cyclic base converter to RS-hold-3 (the same BASE key, something like CONVERT being in the same key as the UNITS menu)

* Finally, improved the +/- key functioning. Now it is smarter to find a number in the middle of your text to change the sign.
* Implemented an in-editor base cycler that helps typing numbers in other bases, it's in the same RS-hold-3 key but active while you are inside the editor.

I know it isn't much (been quite busy with other stuff), but I think usability-wise it's a nice improvement. If you ever needed to work with numbers in other base, the base cycler is really useful.
Also, converting number to fraction back and forth just changing shifts is quite convenient.

[The Shadow]

->Q seems to be working great so far! You're right, it works really nice on LS-Enter. For years I've had it on Hold-1/x, but I may just change it on my regular 50g too.

If you could see your way to give us a built-in command to convert fractions to continued fractions and vice versa, that would be lovely!

[JoJo1973]

(08-17-2019 09:28 PM)Claudio L. Wrote:  * Reworked the menu for binary numbers, adding a base "cyclic" converter.
* Some keyboard moves...
a) Subscripts and superscripts are now on the alpha-hold plane.
b) :-> (rule separator) moved from Enter to RS-hold-0 (made sense to me)
c) | (given that) operator moved from Enter to LS-hold-2
d) ->Q is now at LS-Enter and LS-hold-Enter
e) Added the cyclic base converter to RS-hold-3 (the same BASE key, something like CONVERT being in the same key as the UNITS menu)

* Implemented an in-editor base cycler that helps typing numbers in other bases, it's in the same RS-hold-3 key but active while you are inside the editor.

I love the base cycler, and I love the in-editor version even more!

In general, the new key assignments are well-thought, however I get "|" only in Alpha LS-hold plane (which is good) but not in LS-hold plane. On the contrary, RS-0 yields "->" but Alpha RS-0 yields nothing. I'm gonna file a bug for these.

[JoJo1973]

(08-18-2019 12:43 AM)The Shadow Wrote:  ->Q seems to be working great so far! You're right, it works really nice on LS-Enter. For years I've had it on Hold-1/x, but I may just change it on my regular 50g too.

If you could see your way to give us a built-in command to convert fractions to continued fractions and vice versa, that would be lovely!

I tied to replicate some of the results in Joe Horn's thread. Using the current implementation the only example I could replicate would be #2 but

14 SET PREC
π ->NUM
->Q

returns 5419351 / 1725033 which is different from the results of pdq(PI500,14) or pdq(PI,14) from Joe's thread.

I tried for fun a little test:

<< 4 20 FOR i i SETPREC π ->NUM ->Q NEXT >> which rules out an off-by-1 error in setting the precision.

Am I doing something wrong? Is ->Q using the 5*10^(-prec-1) tolerance instead of the 10^(-prec) rule? (I don't have a Prime so I can't compare results...)

PS: why are the numerators in approx form while the denominators in exact form?

[Claudio L.]

(08-18-2019 08:24 PM)JoJo1973 Wrote:  I love the base cycler, and I love the in-editor version even more!

In general, the new key assignments are well-thought, however I get "|" only in Alpha LS-hold plane (which is good) but not in LS-hold plane. On the contrary, RS-0 yields "->" but Alpha RS-0 yields nothing. I'm gonna file a bug for these.

No need to file bug reports. I updated all ROMS to 1291.

I fixed a couple of bugs in the cycler, the +/- key and the EEX key which all share the number detection routine. Now the cycler is smart enough that if a number cannot be expressed in a base, it won't wrap it.

So typing a number now it's:

10101 RS-HOLD-3 and will wrap it with #10101b

but if you type
10201 RS-HOLD-3 will wrap it as #10201o (skips the binary base, since the number cannot be binary.

10801 RS-HOLD-3 will wrap it as #10801h (skips both binary and octal). When you keep pressing it will only alternate between decimal and hexa.

10E6 will alternate between hex and decimal as well, but 10EE6 will wrap it in #h and won't change it anymore (no other base can have a number like that).

I also fixed all the keyboard bindings. The "given that" operator moved to RS-2 and RS-HOLD-2 but it's only available when in alpha mode (when typing equations, you'll be in alpha 99% of the times so it makes sense).
The factorial symbol stays where it was, LS-2 both outside and within alpha mode.
Also the right arrow now it's properly bound in and out of alpha.

[Claudio L.]

(08-18-2019 08:54 PM)JoJo1973 Wrote:  I tied to replicate some of the results in Joe Horn's thread. Using the current implementation the only example I could replicate would be #2 but

14 SET PREC
π ->NUM
->Q

returns 5419351 / 1725033 which is different from the results of pdq(PI500,14) or pdq(PI,14) from Joe's thread.

I tried for fun a little test:

<< 4 20 FOR i i SETPREC π ->NUM ->Q NEXT >> which rules out an off-by-1 error in setting the precision.

Am I doing something wrong? Is ->Q using the 5*10^(-prec-1) tolerance instead of the 10^(-prec) rule? (I don't have a Prime so I can't compare results...)

PS: why are the numerators in approx form while the denominators in exact form?

His results were done using a prime, but since the prime uses a different internal representation (binary) and newRPL uses decimal, the target number is not the same in both systems. I think it's fine that it returns a different fraction as long as the result of ->NUM on that fraction is within the requested 5*10^(-prec-1) tolerance.

EDIT: I thought I took care of clearing the approx. bit. I missed something obviously...

[JoJo1973]

(08-18-2019 09:39 PM)Claudio L. Wrote:  

(08-18-2019 08:24 PM)JoJo1973 Wrote:  I love the base cycler, and I love the in-editor version even more!

In general, the new key assignments are well-thought, however I get "|" only in Alpha LS-hold plane (which is good) but not in LS-hold plane. On the contrary, RS-0 yields "->" but Alpha RS-0 yields nothing. I'm gonna file a bug for these.

No need to file bug reports. I updated all ROMS to 1291.

Too late! Well, no problem, I'm gonna close it...

[Claudio L.]

I've decided to take on the big task of reviewing *ALL* commands and make sure they work properly with unit objects and do parallel processing with lists. This is so that expressions using those commands don't fail when the variable used contains units or case-lists (whenever I say case-lists, feel free to read it as "multiple results"). Once expressions work well with units, Phase II of this work would be to make sure the solvers work properly with units.

But before I can even begin, I have some questions that I want to open for debate:

LN(X) and EXP(X): What are these functions supposed to return when working with units?

Same for a^X where either X or both 'a' and X have units

Let's start at the beginning:

X^n is fine if n is just a number.
I guess I could extend that case to where 'n' does have units but it's actually a non-dimensional number, like n=1.609_km/mi. Cancelling out all units turns out n=1, so X^(1.609_km/mi) should EVAL to X^1 = X.
What if n has units? Do we issue a "inconsistent units" error?

EXP(X) is I guess similar to e^X so the same as above should apply?

It seems to me in physics the exponential function should only be used with non-dimensional numbers... but I'm not so sure this is 100% valid.

An example with vibration analysis (images borrowed from Wikipedia):





In the example above, the argument to EXP() is non-dimensional.
Any other ideas?

[JoJo1973]

Hi Claudio,

as you pointed out, units in transcendental (and trigonometric) functions make sense only if the argument is adimensional.

To convince yourself, just remind that these functions can be expressed as a Taylor series (e.g. e^x = 1 + x + x^2/2 + ...) and you can see that if x had a unit attached, each term of the series would have a different dimension.

[The Shadow]

I concur - transcendental functions only make sense with dimensionless arguments. It's fine to cancel units to get a dimensionless value, though - like your km/mi example.

[The Shadow]

Thinking about this some more...

One wretched case is angles. Technically radians are dimensionless, so any angles should be translated to radians for use as arguments of exp() or ln(). (This actually comes up in complex analysis all the time.)

Temperature is annoying too. In things like the Arrhenius equation, where you have exp(E/RT), it is essential for temperature to be in Kelvin (or Rankine, if you're feeling masochistic). Scaling from anything but absolute zero messes everything up.

[JoJo1973]

Well, angles and gauge units are different cans of worms, but this doesn't affect the fact that arguments of these functions ultimately always simplify to dimensionless units.

[John Keith]

(09-07-2019 05:16 AM)The Shadow Wrote:  One wretched case is angles. Technically radians are dimensionless, so any angles should be translated to radians for use as arguments of exp() or ln(). (This actually comes up in complex analysis all the time.)

This is why many CAS functions in the HP 50 require the calc to be in radians mode.

I also concur that functions of temperature only make sense for absolute temperature (K).

[The Shadow]

(09-07-2019 08:40 AM)JoJo1973 Wrote:  Well, angles and gauge units are different cans of worms,

They aren't, though. In addition to newRPL's angle objects, there are also angle units.

Though it's true that angle objects should be handled properly by transcendental functions too, just as units are.

[cdmackay]

hi, just starting to use newRPL again, after a while away (no time).

I run my Android phone (Samsung Note 10+) in high-resolution mode (3040x1440); in this mode, the newRPL skin doesn't fit the screen: it's too wide. The skin does look OK in the lower res mode (2280x1080). Would you be able to provide a skin that works for the high res mode, please?

Also, when the app starts, there's a popup: "Detected problems with API compatibility". The phone runs Android 9.

Finally, I note that File->Exit doesn't actually exit. It pops up the prompt "do you want to save" twice, but doesn't actually exit.

Known issues?

thanks very much indeed.