01-22-2017, 08:30 PM
Post: #519
 Claudio L. Senior Member Posts: 1,885 Joined: Dec 2013
(01-22-2017 01:38 AM)Claudio L. Wrote:  Updates will no longer require to recompile anything. Starting with the first official release of 0.8Alpha a month ago, things will stay where they are.

Ah, good to know.

Quote:The demo is identical to the calculator, any bugs will happen on the 50g too, so please describe what you call oddities. Bear in mind many of the commands will show up in autocomplete but will issue an "Invalid opcode" error because they are not implemented. Anything else might be a bug, either in symbolics or in the matrix lib.

Okay. (I've got my calculator now, btw, and newRPL installed without incident.) I started with the vector [1 2 3], and then divided by '3'. I expected to get:

[ '1/3' '2/3' '3/3' ]

'[ 1 2 3 ]/3'

So then I tried [ '1' '2' '3' ] and divided by '3'. This time I got an error, "/ Error: Not allowed in symbolics".

Finally I tried [ '1' '2' '3' ] and divided by 3. (Well, "3" not "3.") This time I got the decimal versions of the three fractions in the vector. ie, [0.333... 0.666... 0.999...] That last one in particular seems odd - why not just 1?

I would expect the symbolics inside the vector to work just like symbolics on the stack or in a list, but they don't.

It seems you caught a glitch in my definition of the '/' operation for vectors. Since division doesn't exist in matrix/vector world, it was implemented as "multiply by the inverse", so if you divide a matrix by another one it inverts the right argument then attempts to multiply. I obviously need to work on some special cases:

[ 1 2 3 ] 3 / --> First it does 3 INV --> 0.333333333.... then multiplies that, hence you get the 0.9999999999.... instead of one. For the case matrix / number this doesn't work well and needs to be fixed. It would work much better for scalars when you use the actual '/' operator element-by-element.

[ '1' '2' '3' ] 3 / --> Similarly, 3 INV returns an approximated value, then when multiplied by other numbers it spreads the approximation virally, and you end up with all approximated numeric answers (this is by design). Same fix as previous issue.

[ 1 2 3 ] '1/3' * --> Not allowed in symbolics. Because the interaction between them wasn't quite ready yet, you can't have vectors and lists inside a symbolic: '{ 1 2 }' will fail the same way. I think it's trying to create a symbolic '[ 1 2 3 ]*(1/3)' which is not permitted. I will have to work on that so it does the element-by-element multiplication, then of course I have to enable it.
It was giving me problems with lists, so I disabled it. The idea is to allow multiple inputs and multiple outputs:

{ 2 4 6 } 'X' STO
'X^2/2' ->NUM
should produce { 4 8 18 } as a result. This isn't working well yet.

(01-22-2017 04:01 AM)The Shadow Wrote:  (Incidentally, is there a command to change an integer into the symbolic version of that integer? ->Q changes 2 to '2/1' rather than '2'. Not sure if that's intended behavior - RPL changes real "2." to integer "2".)
I need to fix ->Q, denominator of 1 is supposed to be removed.

(01-22-2017 04:01 AM)The Shadow Wrote:  A somewhat larger issue: Currently, if you do EVAL or EVAL1 on '2/1' or '2', you get 2. I wonder if that's a good idea? ->NUM should do that, certainly, but I don't see why EVAL should. I'd expect it to be '2' in both cases.
There's no way to 'convert' an object into symbolic, other than operate on it with a symbolic object. All symbolics are passed through an autosimplify step that removes the symbolic ticks if the result is an exact number. If you have '1/3' EVAL it won't remove the quotes and the result will remain '1/3' because it wouldn't have an exact result.
It shouldn't cause any problems, if you find a use case where you need to keep an integer number symbolic let me know, I might have to add such a command.

(01-22-2017 04:01 AM)The Shadow Wrote:  (By the way, let me thank you from the bottom of my heart for letting EVAL and EVAL1 evaluate the elements of matrices and lists, respectively. The number of times I have typed AXL <<EVAL>> MAP AXL on the regular 50g is ridiculous.)

It seemed natural to extend the element-by-element operation of EVAL1. Notice that EVAL on lists explodes the list, so you still have to do << EVAL >> MAP, but EVAL1 does it element-by-element. This was done for compatibility, but I'm open to a change.
 « Next Oldest | Next Newest »