newRPL - build 1255 released! [updated to 1299]
|
12-21-2019, 12:45 AM
(This post was last modified: 12-22-2019 06:18 AM by The Shadow.)
Post: #629
|
|||
|
|||
RE: newRPL - build 1255 released! [updated to 1299]
(12-20-2019 10:36 PM)Claudio L. Wrote: With a vector/matrix object, having a pair of (i,j) is actually useful, and using a symbolic in place of a program is an idea I (cough) stole (cough) from MAKEMAT() on the Prime. "Good authors borrow. Great authors steal." Quote:I don't see why I couldn't add a local variable tracking an index for the regular MAP (other than slowing down the entire process, it doesn't cause any problems), much like the NSUB/ENDSUB commands do for DOSUBS. I'd be down, as long as the slowdown isn't too extreme - and I can't see why it would be. Quote:The variable 'Ai' wouldn't make sense, since MAP does not accept a symbolic, only a program, and the program receives the element in the stack. Same thing with MMAP, Aij does not exist when you use a program, only for symbolics. Good to know about Aij not existing for programs. Can a program just refer to i and j, or do you need something like << -> i j << >> >>? Quote:The way I saw it originally is that simplifying for example A*0 with 0 is completely wrong unless you have certain knowledge about the variable A (in this case, you know A cannot be infinite). So the system should act on the safe side and leave it alone unless the user explicitly provides that knowledge. See, I'm approaching it from the point of view that no real or complex number is infinite. You have to deliberately extend the real number line or complex plane to allow for infinite numbers, and there's multiple ways to do it. Quote:On the other hand, when actually using it, it quickly gets annoying that all these trivial things don't get simplified: A/A, 0*A, A^0, etc. so I'd say a flag controlling the default assumptions is completely warranted (and I hate flags): This too. Your default flags are probably a good compromise (I'd probably use 'Force FINITE' constantly, the others seldom), but even they won't handle A/A or A^0. Do we need to add 'Force NONZERO' too? EDIT: It's definitely riskier, since of course zero IS a real and complex number. And assuming things nonzero is a classic way to miss solutions. But: 1. OldRPL does it that way. 2. Most of the time, if you've got a situation where something can be zero, you're not going to be dividing by it anyway. (Famous last words, I know.) 3. The annoyance factor you mentioned above. 'X^2/X' not being the same as 'X' is technically correct but in a practical sense often wrong - it obscures rather than illuminating an expression. OldRPL made a similar design choice regarding absolute values - relegating most uses of them in simplification to "rigorous mode". |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 24 Guest(s)