newRPL  build 1255 released! [updated to 1299]

08092019, 04:41 PM
Post: #561




RE: newRPL  build 1255 released! [updated to 1282]
(08082019 09:55 PM)compsystems Wrote:(08022019 02:29 PM)Claudio L. Wrote: ... The next target will be the HP Prime hardware ...And on the new NumWorks2019? 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. 

08152019, 10:49 PM
Post: #562




RE: newRPL  build 1255 released! [updated to 1282]
(08022019 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 fullblown 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 327=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 

08162019, 11:21 AM
(This post was last modified: 08162019 12:24 PM by The Shadow.)
Post: #563




RE: newRPL  build 1255 released! [updated to 1282]
(08152019 10:49 PM)Claudio L. Wrote: So I'm adding 7 zeros after the number, and forcing the system to approximate *that* number. 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^(prec1) rather than 10^(prec). Adjusted for the integer digits, of course! 

08162019, 01:22 PM
Post: #564




RE: newRPL  build 1255 released! [updated to 1282]
(08162019 11:21 AM)The Shadow Wrote:(08152019 10:49 PM)Claudio L. Wrote: So I'm adding 7 zeros after the number, and forcing the system to approximate *that* number. 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 bugcheck on corner cases. 

08162019, 01:46 PM
Post: #565




RE: newRPL  build 1255 released! [updated to 1282]
(08162019 01:22 PM)Claudio L. Wrote: I now understand the algorithm better, if the tolerance is too tight all you get is: 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! 

08172019, 09:28 PM
Post: #566




RE: newRPL  build 1255 released! [updated to 1282]
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 testtorturing 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 alphahold plane. b) :> (rule separator) moved from Enter to RShold0 (made sense to me) c)  (given that) operator moved from Enter to LShold2 d) >Q is now at LSEnter and LSholdEnter e) Added the cyclic base converter to RShold3 (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 ineditor base cycler that helps typing numbers in other bases, it's in the same RShold3 key but active while you are inside the editor. I know it isn't much (been quite busy with other stuff), but I think usabilitywise 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. 

08182019, 12:43 AM
(This post was last modified: 08182019 12:48 AM by The Shadow.)
Post: #567




RE: newRPL  build 1255 released! [updated to 1282]
>Q seems to be working great so far! You're right, it works really nice on LSEnter. For years I've had it on Hold1/x, but I may just change it on my regular 50g too.
If you could see your way to give us a builtin command to convert fractions to continued fractions and vice versa, that would be lovely! 

08182019, 08:24 PM
Post: #568




RE: newRPL  build 1255 released! [updated to 1282]
(08172019 09:28 PM)Claudio L. Wrote: * Reworked the menu for binary numbers, adding a base "cyclic" converter. I love the base cycler, and I love the ineditor version even more! In general, the new key assignments are wellthought, however I get "" only in Alpha LShold plane (which is good) but not in LShold plane. On the contrary, RS0 yields ">" but Alpha RS0 yields nothing. I'm gonna file a bug for these. 

08182019, 08:54 PM
Post: #569




RE: newRPL  build 1255 released! [updated to 1282]
(08182019 12:43 AM)The Shadow Wrote: >Q seems to be working great so far! You're right, it works really nice on LSEnter. For years I've had it on Hold1/x, but I may just change it on my regular 50g too. 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 offby1 error in setting the precision. Am I doing something wrong? Is >Q using the 5*10^(prec1) 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? 

08182019, 09:39 PM
Post: #570




RE: newRPL  build 1255 released! [updated to 1282]
(08182019 08:24 PM)JoJo1973 Wrote: I love the base cycler, and I love the ineditor version even more! 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 RSHOLD3 and will wrap it with #10101b but if you type 10201 RSHOLD3 will wrap it as #10201o (skips the binary base, since the number cannot be binary. 10801 RSHOLD3 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 RS2 and RSHOLD2 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, LS2 both outside and within alpha mode. Also the right arrow now it's properly bound in and out of alpha. 

08182019, 09:43 PM
(This post was last modified: 08182019 09:45 PM by Claudio L..)
Post: #571




RE: newRPL  build 1255 released! [updated to 1282]
(08182019 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 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^(prec1) tolerance. EDIT: I thought I took care of clearing the approx. bit. I missed something obviously... 

08192019, 08:45 AM
Post: #572




RE: newRPL  build 1255 released! [updated to 1282]
(08182019 09:39 PM)Claudio L. Wrote:(08182019 08:24 PM)JoJo1973 Wrote: I love the base cycler, and I love the ineditor version even more! Too late! Well, no problem, I'm gonna close it... 

09062019, 09:01 PM
Post: #573




RE: newRPL  build 1255 released! [updated to 1282]
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 caselists (whenever I say caselists, 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 nondimensional 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 nondimensional 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 nondimensional. Any other ideas? 

09062019, 10:21 PM
Post: #574




RE: newRPL  build 1255 released! [updated to 1282]
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. 

09062019, 10:26 PM
Post: #575




RE: newRPL  build 1255 released! [updated to 1282]
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.


09072019, 05:16 AM
Post: #576




RE: newRPL  build 1255 released! [updated to 1282]
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. 

09072019, 08:40 AM
(This post was last modified: 09072019 08:40 AM by JoJo1973.)
Post: #577




RE: newRPL  build 1255 released! [updated to 1282]
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.


09072019, 01:43 PM
Post: #578




RE: newRPL  build 1255 released! [updated to 1282]
(09072019 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). 

09072019, 04:02 PM
Post: #579




RE: newRPL  build 1255 released! [updated to 1282]  
09072019, 08:54 PM
Post: #580




RE: newRPL  build 1255 released! [updated to 1282]
hi, just starting to use newRPL again, after a while away (no time).
I run my Android phone (Samsung Note 10+) in highresolution 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. Cambridge, UK 41CL/DM41X 12/15C/16C DM15/16 17B/II/II+ 28S 42S/DM42 32SII 48GX 50g 35s WP34S PrimeG2 WP43S/pilot Casio, Rockwell 18R 

« Next Oldest  Next Newest »

User(s) browsing this thread: 2 Guest(s)