newRPL - build 1255 released! [updated to 1299]
|
01-10-2019, 02:56 PM
(This post was last modified: 01-10-2019 03:00 PM by Claudio L..)
Post: #351
|
|||
|
|||
RE: newRPL - build 1089 released! [update:build 1127]
(01-10-2019 12:43 AM)The Shadow Wrote: Very nice. Are user rules done before or after the built-in rules? Oh - and have the list of AUTOSIMPLIFY rules changed from the last time you posted them? (I know they've been organized into groups. Maybe document them on the wiki?) Once it works and I stop changing things it will be fully documented in the wiki (this will be the foundation for reimplementing many of the 50g commands, so it needs to be well documented). Algorithm works well now, still squashing the last few bugs (some crashes) and testing corner cases to make sure every subtlety is handled correctly. I'll test it internally at least for another week before letting it out. Failing to process corner cases would be OK for preview, but crashing the calc is not acceptable in my book. Regarding IFTE: Mathematica calls them "constraints" and aren't exactly IFTE expressions. My thought was to have a single condition expression (then you can use AND() and OR() to pack multiple ones in one), in which you can use the special variables defined. This would be evaluated only when a match is found and is ready to make a replacement (hence all special variables have a definition). The problem is this expression cannot be evaluated with ->NUM, variables that exist need to be replaced, then any equality needs to be tested by structure, not by value. In other words, we'd have to symbolically simplify this expression until we can check the equality to be true or false (we need to fire up the rules engine from within the engine to simplify the expression within the rule!). This recursive embedded behavior can be a pain to handle, not to mention make everything slow to a crawl if every time a candidate replacement is found, we need to replace variables, simplify and test the condition. But, dreaming out loud, what could be a good syntax to include such conditional expression? Rules are 'Left:->Right' Perhaps the | (given that) operator is a good choice? 'Left:->Right|Condition' for example, a condition to test for odd : '√(.xX^.iN):->.xX^((.iN-1)/2)*√.xX | FP(.iN/2)≠0' Mmmmm... this would need to be evaluated numerically as well, not just structure... need to think some more about this... |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)