newRPL: Alpha demo 0.9 released [UPDATED 2017-10-25]

[Claudio L.]

(08-30-2017 05:42 PM)The Shadow Wrote:  Some suggested extended types:

Vectors as opposed to matrices.

Vectors and matrices that contain symbolics as opposed to those don't.

Vectors and matrices that contain complex numbers as opposed to those that only contain reals.

Algebraics that contain undefined variables (and thus can't be ->NUM'd) as opposed to those that don't. (Alternatively or in addition, algebraics that contain identifiers as opposed to those that only contain numbers and operators.)

That's in the queue. The matrix library is incomplete and in much need of a revision. It was written before TYPE was implemented, now it's time to revisit and provide all that information.
Soon I'll attack that library and make a big push in terms of new commands implemented and better algorithms. I'll keep these suggestions in mind. Some might be time consuming, like the last one. There's no way to know if it can be ->NUM'ed unless you actually do it, but there will be a way to identify if a matrix is numeric, symbolic but with all numeric constants (in other words, numeric with fractions or non-rationals).

(08-30-2017 05:42 PM)The Shadow Wrote:  Also, I just discovered that '0' counts as non-zero for purposes of IF, but not for NOT. I don't know if this is intended, but it's definitely unexpected.

To clarify, IF '0' THEN 1 ELSE 0 END and IF '0' NOT THEN 1 ELSE 0 END both return 1. You can fix it by doing EVAL or ->NUM on the '0' first, of course, but it's still unexpected. I'm guessing that any algebraic counts as "something"?

Likewise, IF 'X' THEN 1 ELSE 0 END returns 1, while oldRPL gives an undefined name error.

In newRPL the definition is that FALSE is real or complex zero, everything else is true. The IF command only checks if the argument is false, because in the modular architecture, the idea was that IF should be independent of the object types, so adding new objects makes them automatically work well with IF. So far it worked well, but on symbolics there's an incompatibility, since classic RPL evaluates the symbolic (and newRPL should too).
I'm still debating how to resolve this issue. I think to keep IF independent of object types, it should ->NUM its argument before checking if it's false, but this might make it non-atomic as ->NUM might execute RPL code (specifically on lists it does MAP to each element). There's also the possibility of adding an overloadable unary operator ISFALSE to all object types. This way it each object can define its own behavior. For example an empty list or a list containing all zeros could be false too, but that's something the list library should define.
Anyway, it will be fixed eventually, but it needs some more thought.

(08-30-2017 05:42 PM)The Shadow Wrote:  EDIT: I also just discovered that trying to find the inverse of the matrix:

[ [ 0 1 ] [ -1 0 ] ]

gives an 'Undefined result' error. If I then try to invert

[ [ '0' '1' ] [ '-1' '0' ] ]

I get

[ [ '0/0' '0/0'] [ '1' '0' ] ]

which may give some insight as to why this is happening.

EDIT:

I've emailed you two programs in which SAME, or possibly IFERR, is acting very oddly.

The algorithm for matrix inversion doesn't do partial pivoting yet, so any zeros in the diagonal will make it fail. Like I said, the matrix library is next in line for an overhaul.

I'll look at those programs., and the list you sent me. Will keep you updated.