newRPL  build 1089 released! [update:build 1158]

01212019, 04:51 PM
Post: #361




RE: newRPL  build 1089 released! [update:build 1127]
(01212019 01:43 PM)compsystems Wrote: 2 Crazy ideas =), If it is offtopic, I move it or I eliminate it, there is no problem Well... not meaning to be rude but yeah, it's far from what we are discussing right now. I would post them in a separate thread, then I'll reply with some ideas that may be more related to those ideas than newRPL. 

01222019, 02:41 PM
Post: #362




RE: newRPL  build 1089 released! [update:build 1127]
Yikes, that does seem very involved!
Incidentally, how does one enter subscripts on the keyboard? 

01222019, 09:39 PM
Post: #363




RE: newRPL  build 1089 released! [update:build 1127]  
01242019, 09:16 PM
Post: #364




RE: newRPL  build 1089 released! [update:build 1127]
All ROMs were updated to build 1157.
What's new: * Rules engine complete rewrite, now it won't miss a case. * Rules engine also supports attributes * Added '.oX' and '.eX' to match odd and even numbers (which can also be accomplished using attributes). * Operator  (given that) was added to properly parse rules and expressions. Rules engine doesn't use it yet. * Wiki was updated with more info on rules and attributes (the symbolics section) * Moved the rules symbol in the keyboard: Now LSEnter does :> (instead of ANS), and LSHoldEnter does the  operator. As a reminder: In alpha mode, RSholdnumber does subscript/superscript (when in L and C modes respectively). As usual, test and report bugs, the rules engine is quite new, so things are expected to go wrong. 

01252019, 02:50 PM
(This post was last modified: 01252019 03:11 PM by The Shadow.)
Post: #365




RE: newRPL  build 1089 released! [update:build 1157]
AUTOSIMPLIFY still doesn't turn 'X*X' to 'X^2', or 'X/X' to '1'. It does change 'X^2/X' to 'X', though, so that flag must be on. Are those flags somewhere in the menu system, btw? If not, how do we change them?
'SQRT(X)' gets changed to 'X^(1/2)' but not back, as in the original set of rules. What rules does AUTOSIMPLIFY use now? EDIT: Also, I just noticed that 'X*X^2' gets turned correctly into 'X^3' but 'X^2*X' does not. 

01252019, 03:25 PM
Post: #366




RE: newRPL  build 1089 released! [update:build 1157]
(01252019 02:50 PM)The Shadow Wrote: AUTOSIMPLIFY still doesn't turn 'X*X' to 'X^2', or 'X/X' to '1'. It does change 'X^2/X' to 'X', though, so that flag must be on. Are those flags somewhere in the menu system, btw? If not, how do we change them? Well of course, I finished the engine, tested and released, but didn't get to review and update the AUTOSIMPLIFY rules to actually use the new features. As of right now, there's no rule that would match 'X*X', I did 'm*X+n*X' and 'X+m*X', but forgot to include the simplest case That's where I need help: to come up with the best rule set possible for all the different commands. I want 'X/X' simplified to 1 but using attributes to only match real/complex variables that can't be zero. Same for 'X^m/X^n'. (01252019 02:50 PM)The Shadow Wrote: 'SQRT(X)' gets changed to 'X^(1/2)' but not back, as in the original set of rules. What rules does AUTOSIMPLIFY use now? Below is what I have so far (pasted from the source code, it's plain RPL so there's nothing difficult). Flags are as follows: 70 (when set) disables all rule processing in AUTOSIMPLIFY (it still does only trivial numeric reductions like fraction additions, but no algebraic manipulation) 71 to 78 (when set) disables rules in groups 1 through 8. The 8 groups are as defined as per the comments in the source code: Code:


01252019, 06:33 PM
Post: #367




RE: newRPL  build 1089 released! [update:build 1158]
Updated all ROMs to 1158.
I realized that the bit for the "infinity" attribute had inverted logic to all the rest. All attributes express a constraint (a restriction) on the set of values, so that for example a value that if a rule requires a value to be >=0, values that are >0 also meet this requirement by being a more specific subset. I achieved this by making the attribute be "cannot be zero" rather than "can be zero", but I had the infinity bit logic reversed, which resulted in real numbers + Infinity to be a subset of finite real numbers. Anyway, I reversed the logic and published 1158. I also played a bit with the AUTOSIMPLIFY rules, so I'm not even sure what rules I have active anymore. 

01262019, 04:55 PM
Post: #368




RE: newRPL  build 1089 released! [update:build 1158]
In the new version, 'X*X' now becomes 'X^2'. Whew! However, while 'X^2*X' becomes 'X^3', 'X*X^2' does not. If that's because you're using noncommutative multiplication, you needn't bother for that case  it takes quite a lot of warping and spindling of the multiplication operator before powers stop making sense. Even sedenions, for which multiplication isn't commutative, associative, or even alternative have welldefined powers which are the same from the left and from the right (or indeed, in any order with any set of parentheses). True, rectangular matrices don't have powers, but then those expressions would error in any case.
I'm also a little puzzled by the parity attribute. What is the difference between a number being 'known to be odd' and being 'known to be an odd integer'? Are there nonintegers for which parity is defined? I suppose you could define halfintegers (ie, '1/2', '3/2', '5/2' and so on) to be odd in some sense, but I've never run across it before. By the way, parity can be defined for complex numbers too  at least in the Gaussian integers. Anything divisible by '1+i' (which has a norm of 2) is even, all other Gaussian integers are odd. That works out to, "If the real and imaginary parts have the same parity, the complex number is even. If they have different parity, it's odd." For the real integers, that gives the usual parity, but in the Gaussian integers as a whole, you get a checkerboard pattern. Of course, there are many ways to define 'integers' in the complex plane, of which the Gaussian integers are only one. (Though the simplest.) 

01262019, 05:23 PM
Post: #369




RE: newRPL  build 1089 released! [update:build 1158]
(01262019 04:55 PM)The Shadow Wrote: In the new version, 'X*X' now becomes 'X^2'. Whew! However, while 'X^2*X' becomes 'X^3', 'X*X^2' does not. If that's because you're using noncommutative multiplication, you needn't bother for that case  it takes quite a lot of warping and spindling of the multiplication operator before powers stop making sense. Even sedenions, for which multiplication isn't commutative, associative, or even alternative have welldefined powers which are the same from the left and from the right (or indeed, in any order with any set of parentheses). True, rectangular matrices don't have powers, but then those expressions would error in any case.You are correct but you are missing the case with more factors. If we accept commutative multiplication it will shuffle all factors until it matches, so X*Y*X^2 will also match and become Y*X^3 which is incorrect for matrices. I just need to add the other noncommutative cases (01262019 04:55 PM)The Shadow Wrote: I'm also a little puzzled by the parity attribute. What is the difference between a number being 'known to be odd' and being 'known to be an odd integer'? Are there nonintegers for which parity is defined? I suppose you could define halfintegers (ie, '1/2', '3/2', '5/2' and so on) to be odd in some sense, but I've never run across it before.It needs to be a separate bit, so that odd integers are a subset of integers when you AND their attributes. As a result, some weird combinations can result like numbers with the odd bit set but not the integer bit. Whether we ignore those cases mathematically or not doesn't really matter. It's a way to keep performance to a decent level. I just AND the attributes and check the result to determine if the expression matches or not. (01262019 04:55 PM)The Shadow Wrote: By the way, parity can be defined for complex numbers too  at least in the Gaussian integers. Anything divisible by '1+i' (which has a norm of 2) is even, all other Gaussian integers are odd. That works out to, "If the real and imaginary parts have the same parity, the complex number is even. If they have different parity, it's odd." For the real integers, that gives the usual parity, but in the Gaussian integers as a whole, you get a checkerboard pattern. Is there a simple way to check if a complex is odd or even? If it won't perform I can't add it. For real numbers I just get the last digit and test one bit, that's fast enough so it doesn't bog the system (the idea is that some commands will be running hundreds of rules, so this needs to be fast). 

01262019, 06:09 PM
Post: #370




RE: newRPL  build 1089 released! [update:build 1158]
(01262019 05:23 PM)Claudio L. Wrote: You are correct but you are missing the case with more factors. If we accept commutative multiplication it will shuffle all factors until it matches, so X*Y*X^2 will also match and become Y*X^3 which is incorrect for matrices. I just need to add the other noncommutative cases Sigh. Curses, foiled again! Claudio Wrote:Is there a simple way to check if a complex is odd or even? If it won't perform I can't add it. For real numbers I just get the last digit and test one bit, that's fast enough so it doesn't bog the system (the idea is that some commands will be running hundreds of rules, so this needs to be fast). I don't know if it's fast enough for your purposes, but you could XOR the parities of the real and imaginary parts. Upon further reflection, though, I'm not sure it's worth implementing... I'm having trouble thinking of rules or conditions that would use Gaussian parity. 

01282019, 09:11 PM
Post: #371




RE: newRPL  build 1089 released! [update:build 1158]
(01262019 06:09 PM)The Shadow Wrote: I don't know if it's fast enough for your purposes, but you could XOR the parities of the real and imaginary parts. Upon further reflection, though, I'm not sure it's worth implementing... I'm having trouble thinking of rules or conditions that would use Gaussian parity. I've been reading a little about it (I don't claim to have any authority in the matter, though). For reals, it's clear that odd/even exponents are useful for simplifications, but I don't see any rules that could require identifying parity in complex numbers, so I'll leave it be. 

02152019, 06:58 PM
Post: #372




RE: newRPL  build 1089 released! [update:build 1171]
All ROMs were updated to 1171.
Warning: Due to big internal changes, it is required to ARCHIVE your data first, update the firmware, then RESTORE it (either via USB or SD card). In general, you won't lose your data if you don't do it this way, but your settings will be lost (fonts, flags, current precision, etc.). What's new: * Rules engine is finally stable for general use. * New constants library, adds pi, e, i and j for now (i and j are both defined as (0,1), so no quaternions) * New "case" list type. Prepending a 'c' before the list it becomes a caselist. It only differs from regular lists in how overloaded operators work. Caselists elements are considered alternative values of the same result. A variable X that contains c{ 1 2 }, means that X could take either the value of 1 or 2. For example, adding { 1 2 } { 3 4 } + would normally result in { 4 6 } (addition elementbyelement). with caselists, c{ 1 2 } c{ 3 4 } + results in c{ 4 5 5 6 }, which represents all possible combinations adding A+B where A could be 1 or 2 and B could be 3 or 4. Therefore A+B can be either: (1+3) (1+4) (2+3) or (2+4). Now the big question: WHY??? so that functions can return alternative results. For example √4 could return c{ 2 2 }, and if that's embedded within a larger expression, computations will carry on normally. * New command ALLROOTS: Doing '√4+3' ALLROOTS returns c{ 5 1 } after >NUM, as expected. * Bug fix: Added argument checks for NUMINT * Added support for lists, caselists and angle objects compiled within symbolic expressions. * Added a 10pixel font (somebody requested one for the 50g in another thread, and I thought it was a good idea to have one). These latest additions might still be a little glitchy. Please test and report. 

02152019, 08:24 PM
Post: #373




RE: newRPL  build 1089 released! [update:build 1158]
Oooh! I *like* the idea of case lists!! I'm going to have to sit down and do some serious pondering about how to take best advantage of them.
Is there a >CLIST command or equivalent? c{ 1 1 } might be worth adding as a constant, not sure yet. It probably comes up more often than any other set of cases, though. I won't be able to test until I get home from work, but I'll dive right in at that point! Is there any way to add to the constant library? 

02152019, 09:48 PM
(This post was last modified: 02152019 10:02 PM by compsystems.)
Post: #374




RE: newRPL  build 1089 released! [update:build 1158]
(02152019 06:58 PM)Claudio L. Wrote: ...* New constants library, adds pi, e, i and j for now (i and j are both defined as (0,1), so no quaternions) In electrical and electronic engineering we use the j letter as the imaginary unit =) How is the character i / j of the imaginary unit defined in newrpl? and if it is possible to assign it to another variable name to use it, for example, as counters i, j in the for cycle. The good enough is the enemy of the excellent. 

02152019, 11:03 PM
Post: #375




RE: newRPL  build 1089 released! [update:build 1158]
(02152019 08:24 PM)The Shadow Wrote: Oooh! I *like* the idea of case lists!! I'm going to have to sit down and do some serious pondering about how to take best advantage of them. There's no >CLIST command at the moment. For now you can type them in, I added only one command RANGE(start, end,step) similar to the python range() function that I needed to implement ALLROOTS rules. It returns a case list. Regarding adding to the constant library, if you mean add constants in ROM yes you can, the source code is plain RPL. If you want to add user constants, just store the value in a variable and make it read only with LOCKVAR. It will essentially become a constant, I'm not sure there's any practical difference with doing it as a constant object. 

02152019, 11:08 PM
Post: #376




RE: newRPL  build 1089 released! [update:build 1158]
(02152019 09:48 PM)compsystems Wrote:(02152019 06:58 PM)Claudio L. Wrote: ...* New constants library, adds pi, e, i and j for now (i and j are both defined as (0,1), so no quaternions) For now i and j are both identical, because some people prefer different designation, they are the same imaginary unit. The constants e, i and j use symbols from the Cyrillic alphabet, so there's no conflict with the normal letters. e is in the e^x key, alpha plane and the white shift as expected. The imaginary constants are in the number 7 key, I forgot what shift planes, try all of them but it's quite intuitive once you get used to. 

02172019, 05:13 AM
(This post was last modified: 02172019 05:27 AM by The Shadow.)
Post: #377




RE: newRPL  build 1089 released! [update:build 1158]
The rules system does indeed seem more robust, however 'XX' causes a crash when EVAL'd, and 'X2*X' gives 'X' twice for some reason. And 'X/X' still doesn't become '1', even though all other divisions simplify correctly when the flags allow for it.
ALLROOTS doesn't work properly on square roots of negative numbers. For example, sqrt(3) gives the same result as sqrt(3) when ALLROOTS is used on it. EDIT: On the other hand, it does a really nifty job on things like '(1)^(1/3)'! The caselists work beautifully. One oddity, though  they have the same extended type as regular lists. I'd suggest giving them an extension of their own. Also, the 'case' property is perhaps a shade too fragile  it gets lost if you ADD two caselists together, which seems like something worth doing. Likewise if you PUT something in one. It could be interesting to produce other list variants. One that immediately comes to mind is sets: Basically lists that can't have more than one of a given element. ADDing them would do union. Once tagged objects are in, a Pythonstyle 'dictionary' list might also be useful. For future reference, the Cyrillic 'i' is AlphaLS7, and the Cyrillic 'j' is AlphaLSHold7. Adding a Cyrillic 'k' would be appreciated, so I can program in quaternions without them looking funny. (Though I suppose I could get away with just calling it 'i*j', or even 'ij'.) Where is the constant library located? I haven't seen it yet. P.S. Is there a 'plus or minus' symbol on the calculator? That'd be perfect for c{1 1}. 

02172019, 04:53 PM
Post: #378




RE: newRPL  build 1089 released! [update:build 1158]
(02172019 05:13 AM)The Shadow Wrote: It could be interesting to produce other list variants. One that immediately comes to mind is sets: Basically lists that can't have more than one of a given element. ADDing them would do union. Enthusiastic yes to both! 

02172019, 09:48 PM
(This post was last modified: 02172019 09:58 PM by The Shadow.)
Post: #379




RE: newRPL  build 1089 released! [update:build 1158]
Oh, and now that we have symbolic imaginary units, it'd be nice to see RE and IM interact with them. They *kind of* do now, but you have to follow up with >NUM.
Perhaps a flag could control whether Cyrillic 'i' or 'j' is used as the imaginary unit? It's a bit awkward having them both in play at the same time. And it's a similar sort of preference thing as, for example, which month/day/year format to use. 

02182019, 02:32 AM
Post: #380




RE: newRPL  build 1089 released! [update:build 1158]
(02172019 05:13 AM)The Shadow Wrote: The rules system does indeed seem more robust, however 'XX' causes a crash when EVAL'd, and 'X2*X' gives 'X' twice for some reason. And 'X/X' still doesn't become '1', even though all other divisions simplify correctly when the flags allow for it.I must've broken something, that was working before... I'll investigate, thanks for the report. (02172019 05:13 AM)The Shadow Wrote: ALLROOTS doesn't work properly on square roots of negative numbers. For example, sqrt(3) gives the same result as sqrt(3) when ALLROOTS is used on it. EDIT: On the other hand, it does a really nifty job on things like '(1)^(1/3)'! I'll check the rules, I think I need a separate rule to transform sqrt(.xX) into i*sqrt(.xX). (02172019 05:13 AM)The Shadow Wrote: The caselists work beautifully. One oddity, though  they have the same extended type as regular lists. I'd suggest giving them an extension of their own.That's a bug, they have a different library number, should report a different type. I'll check that as well, thanks! (02172019 05:13 AM)The Shadow Wrote: Also, the 'case' property is perhaps a shade too fragile  it gets lost if you ADD two caselists together, which seems like something worth doing. Likewise if you PUT something in one. There's many existing commands that are not caselist aware yet. They do recognize a list but I need to updaste them to keep the type of the list given untouched. (02172019 05:13 AM)The Shadow Wrote: It could be interesting to produce other list variants. One that immediately comes to mind is sets: Basically lists that can't have more than one of a given element. ADDing them would do union. Yes, except I want them more flexible than Python. Lua tables are good examples, this would also make it simple too add a Lua2RPL library to allow people to code in Lua within the newRPL environment. That's a future improvement... For future reference, the Cyrillic 'i' is AlphaLS7, and the Cyrillic 'j' is AlphaLSHold7. Adding a Cyrillic 'k' would be appreciated, so I can program in quaternions without them looking funny. (Though I suppose I could get away with just calling it 'i*j', or even 'ij'.) Where is the constant library located? I haven't seen it yet. P.S. Is there a 'plus or minus' symbol on the calculator? That'd be perfect for c{1 1}. [/quote] (02172019 04:53 PM)John Keith Wrote: Enthusiastic yes to both! I'm feeling the pressure now... (02172019 09:48 PM)The Shadow Wrote: Oh, and now that we have symbolic imaginary units, it'd be nice to see RE and IM interact with them. They *kind of* do now, but you have to follow up with >NUM. Many commands need to also be updated to better interact with constants as well. Adding a new type when there's 400 commands already implemented is hard... Regarding the letter choice. I think: * People who like I or j typically use them consistently * Having i and j at the same equation is still useful for people who want to define rules on them to try to implement quaternions for example. As long as you don't use >NUM, they are two different things. 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)