A new RPL firmware for the 50g

[Han]

(01-02-2014 10:17 PM)David Hayden Wrote:  Han and Claudio, send me your email address in a private message and I'll send you what I have. Look it over and we can decide where to go from there.

David,

I sent an "email" using the messageboard -- was this what you meant?

[Claudio L.]

(01-02-2014 10:17 PM)David Hayden Wrote:  I suspect that most of the ten zillion existing stack manipulation commands could be replaced with calls to SHUFFLE or REARRANGE and rather than spending 20 minutes figuring that SWAPUNROT 4PICKDUPDUP is the sequence that you need to get the stack arranged the way you want it, you can just tell SHUFFLE or REARRANGE what you want.

This is really cool, and it doesn't make the language any less compatible. Perhaps we should start writing a language specification of some sort? Something simple, with the base functions we need, the object types we need, etc., which will then serve as a guideline to implement things.
It'll be interesting to gather ideas to define the language **before** we attempt an actual implementation, otherwise we might end up redoing a lot of code.
For example, what type of numbers are we going to use? what precision?
One possibility:
BINTS = 32-bit (64 would take a lot of space, or is it justified?)
REALS = (binary or decimal?) how many digits? we have decNumber which supports a lot of different precisions, but memory use and speed might suffer if we increase precision. Perhaps 34 digits (decimal128) is a good tradeoff? or an overkill?

Claudio

[Marcus von Cube]

Claudio,

what about advanced objects like lists, matrices, programs, strings?

The 50g is a CAS machine, so expressions, undefined variables and more come into my mind.

[Claudio L.]

(01-03-2014 05:25 AM)David Hayden Wrote:  Something that Bruce and I talked about was an RPL optimizer. It could replace stack manipulations like Pauli suggested, along with things like built-in constants. But the real benefit would come from knowing the stack diagrams of the entries and analyzing the types and number of values on the stack. For example, if it knows that the previous execution put two REALs on the stack and the next instruction is the UserRPL "*" command then it could replace that with %* (the SysRPL command to multiply two REAL numbers for readers who don't recognize it). I'm sure there are all sorts of other optimizations that can be made.

With the speed of C implemented routines, we probably won't need this type of optimization. But I always thought that there should've been a flag in userRPL to turn on/off argument checking, so when you write a complex program, you check your user arguments first, then disable checking for all your internal calculations, where you know the arguments are good.

Claudio

[Claudio L.]

(01-03-2014 06:46 PM)Marcus von Cube Wrote:  Claudio,

what about advanced objects like lists, matrices, programs, strings?

The 50g is a CAS machine, so expressions, undefined variables and more come into my mind.

Yes, of course. We have to define them all, though I always like to start with atomic fixed-size objects.

Claudio

[David Hayden]

(01-03-2014 06:43 PM)Claudio L. Wrote:  It'll be interesting to gather ideas to define the language **before** we attempt an actual implementation, otherwise we might end up redoing a lot of code.
For example, what type of numbers are we going to use? what precision?
One possibility:
BINTS = 32-bit (64 would take a lot of space, or is it justified?)
REALS = (binary or decimal?) how many digits? we have decNumber which supports a lot of different precisions, but memory use and speed might suffer if we increase precision. Perhaps 34 digits (decimal128) is a good tradeoff? or an overkill?

Here's what I have so far:

• BINTs are 32 bits
• REALs are 64 bit C "doubles". I hope to change them to some decimal representation eventually. But we may want to consider keeping the binary reals in addition since they will probably be faster.
• I don't have extended reals yet but decimal128 seems like a natural fit for these.
• STRING
• CHR
• CMP, but just barely: I haven't implemented any math routines for them.
• LAM (local variables)
• IDNT, but just barely since I haven't coded directories yet.
• TAG
• ARRY
• LIST
• HEX string
• COL (RPL program)
  

[Paul Dale]

If REALs are double, extended reals shouldn't be decimal128 -- the conversion between the two is horrendous and inaccurate. I contemplated the reverse for a while, you get lots of rounding issues that make correct rounding very difficult if not impossible.

I'd use either double and long double or decimal64 and decimal128. I wouldn't expose decNumber to the user -- internally it will be required but it is quite space inefficient. Fortunately, conversion from decimal64 or decimal128 to decNumber and back is fast.

For reference, OpenRPN supported both binary and decimal reals as separate types. For a scientific calculator, I don't see a significant problem with using binary reals. Many others would hate this however.

One other thing I have contemplated is for the function to decide its return type -- e.g. SIN would always return a binary real rather than a decimal one because there is no benefit staying decimal here. The advantage being that there is lots of high quality numeric code written for binary reals but not for decimal ones.


I'd make BINT either 64 bit or unlimited length. Again OpenRPN has a fairly comprehensive integer suite predominately written in RPL. Integers there being 64 bits but with a word size setting like HP's RPL devices.


- Pauli