HP Forum Archive 20

[ Return to Index | Top of Index ]

RPL+ Message #1 Posted by Oliver Unter Ecker on 3 Apr 2011, 9:39 a.m. This does not relate to HPs, but to an RPL platform being built: I think that RPL, the language, can be improved. I've started to implement a few strictly optional language features that I think make for a better language. The result is called "RPL+". I just posted another round of planned features here. These are pretty drastic, yet I hope they will do good. Is code like this \<< =n 0 'n>295' {R\->I} IFT =zero n mkpents =pents [0 1 1 0] =signs {1} =partitions 1 n FOR j zero @ running sum 1 =k WHILE pents[k] j \=< REPEAT partitions[pents[k] j -] signs[k 4 MOD] {+} {-} IFTE ++k END partitions push @ add to partitions NEXT partitions[n] \>> recognizable to you as RPL? Would you like to write code like this? Or do you think RPL should not be changed? I'd love some input. Edited: 3 Apr 2011, 12:13 p.m.

Re: RPL+ Message #2 Posted by Namir on 3 Apr 2011, 2:24 p.m., in response to message #1 by Oliver Unter Ecker Do you have an emulator for RPL+??? A few years ago I implemented RPN2 (an extension to RPN) using Excel. The Excel interface helped type in and run RPN2 programs which supported a whole variety of registers (stack, multiple Alpha registers, multiple array indexing registers), strings, matrices, and flags. I presented RPN2 in HHC2009 (i believe). The point I am making is the having an emulator allows you to breath life into your concepts. Namir

Re: RPL+ Message #3 Posted by Oliver Unter Ecker on 3 Apr 2011, 3:56 p.m., in response to message #2 by Namir Namir, RPN2? That sounds cool. (I will confess to you, though, that I barely know RPN...) >Do you have an emulator for RPL+??? Well. I'm not re-purposing hardware (my hat's off to everyone involved in the WP34s project, btw; it's beautiful), so I don't need an emulator. I'm building the real thing. In the post I referred to, what is not flagged as "(planned)" already exists. And it's out in the wild, actually. Today, there're many thousands of RPL+ calculators (really: apps; currently ND0 and ND1) in the hands of users. So, RPL+ is real. (Caveat: app buyers are not like calculator buyers. Most of my users don't know what RPL is, and, I suspect, don't use it. But then, 50g language capability and one-tap downloading of code only appeared in an update a month ago.) What I'm proposing today, I may implement today. And you may download it in two weeks. (The framework that enables me to do that I built over the course of two years.)

RPN2 Message #4 Posted by Oliver Unter Ecker on 3 Apr 2011, 4:17 p.m., in response to message #2 by Namir Namir, I don't want to be annoying, but let me tell you that you *could* implement your RPN2 for MorphEngine calculators (the two mentioned before for iOS, but more are in the pipeline, for more OSes; see the road-map). Either in JavaScript. Using or not using the math and type functionality that is provided by MorphEngine (which is much easier to use than you'd think; essentially, if you know your calculator command-set, you know how to use it after 20 minutes of reading documentation). Or in RPL. (Is there possibly even something like an RPN emulator implemented in RPL? Should be possible.) You don't need a development environment. You can do this on the device! (In either language.) (Though, if you have an iPad, you may want to wait for CalcPad (another MorphEngine calc) for a larger editing window.) You could also develop on a desktop, in JavaScript, and transfer files to run on the device. Setting up a custom server is described in the ND1 reference docs and makes this a one-tap, one-second affair. If you have a stand-alone JavaScript implementation, developed on a desktop, it takes very little time (probably minutes!) to adapt to MorphEngine, and make it run in the calculator. You could then make it available to all users as a (free) shared folder download. There's a concept of an "extension" and your language could be permanently installed in all calculators of users who press your Install button. It will then be as if the calculator had RPN2 built-in! If you'd like any of this, I'd be happy to point you the right way and lend some support.

Re: RPN2 Message #5 Posted by Namir on 4 Apr 2011, 12:30 a.m., in response to message #4 by Oliver Unter Ecker The Excel interface allowed me to view a lot of information simultaneously. Behind the RPN's functions and operation stands thousands of lines of VBA code. The main goal for RPN2 is to provide structured or modular programming that allows the development of reusable code where one can not worry about clashing register number/names and label names. RPN2 supports modules and each module define a scope for its memory registers and labels. Anyway, this project of mine is not active. I may add a few small features to enhance decision-making, but there is no rush now. Namir

Re: RPN2 Message #6 Posted by Oliver Unter Ecker on 4 Apr 2011, 3:06 a.m., in response to message #5 by Namir Sounds like a really nice project. Love the idea of using Excel as emulator. Cheers.

Re: RPN2 Message #7 Posted by Namir on 4 Apr 2011, 8:01 a.m., in response to message #6 by Oliver Unter Ecker Click here to go to my web page and click on HHC2009 RPN2 to download the file RPN2.ZIP. Edited: 4 Apr 2011, 8:02 a.m.

Re: RPN2 Message #8 Posted by Oliver Unter Ecker on 4 Apr 2011, 9:37 a.m., in response to message #7 by Namir Hi Namir, I didn't know you were a prolific writer, and a language whiz. Thanks for the link. I started to peruse the RPN2 material and am well impressed. Also, I found the root finding articles interesting and may come back to it (my project is in dire need of a capable solver). Your R "tutorial" is a book! (But you know that...) It's a pity your RPN2 project's not active. You put a lot of work into that! (It looks really good to me.) Edited: 4 Apr 2011, 9:38 a.m.

Re: RPN2 Message #9 Posted by Namir on 4 Apr 2011, 11:36 a.m., in response to message #8 by Oliver Unter Ecker Oliver, Thank you for your most kind compliments. I am very glad that the R tutorials attracted your attention. I agree, they can be a book. Regards, Namir

[] operator Message #10 Posted by Oliver Unter Ecker on 3 Apr 2011, 4:35 p.m., in response to message #1 by Oliver Unter Ecker Ok. I know I want the array access operator "[]". But which one of the following two would you choose: A | syntax | v v v v ex1 partitions[pents[k] j -] ex2 signs[k 4 MOD] ^ ^ | local | any RPL or B ex1 partitions[pents[k] - j] ex2 signs[MOD(k, 4)] ^ ^ | local | an expression (w/o quotes) ? Note, B makes array access look identical to a C-like language. Is this too scary for the RPL mind? Think of it as replacing signs 'MOD(k, 4)' EVAL 1 + GET To me "signs[MOD(k, 4)]" reads better. (And the comfort doesn't come at a price. Quite the opposite. It's way faster to run.) Edited: 4 Apr 2011, 3:01 a.m.

Re: [] operator Message #11 Posted by David Hayden on 4 Apr 2011, 4:29 p.m., in response to message #10 by Oliver Unter Ecker Oliver, I think it's really a question of what syntax will you use for an expression. In both cases, the general syntax appears to be partitions[ any expression ] example: partitions[pents[k] + 2] Note that HP solved this by inventing the algebraic object, so in RPL it might be 'partitions[pents[k] + 2]' But I'm not sure how you'd distinguish between an array reference and an object followed by a single entry array. For example, is partitions [1] a reference to an element in partitions, or does it put the value of partitions on the stack, followed by the array [1]? Dave

Re: [] operator Message #12 Posted by Oliver Unter Ecker on 4 Apr 2011, 8:16 p.m., in response to message #11 by David Hayden David, The overall structure of both cases is array[something] In case A, "something" is RPL. In case B, "something" is an algebraic expression without quotes. Each case gives two examples. I'm getting an "invalid syntax" error if I try to place brackets inside an expression, so 'partitions[pents[k] + 2]' does not work for me (on an HP-49). Maybe you mean 'partitions(pents(k) + 2)'? Yes, case B partitions[pents[k] + 2] would indeed be equivalent to 'partitions(pents(k) + 2)' EVAL Thanks for pointing this out. This should make the syntax look friendlier in RPL eyes. I know the lack of quotes may be weird. But the proposed syntax is equivalent to the one in C-like languages. (Conversely, the expression syntax, what with having "()"s, needing quotes, and an EVAL, is probably very weird from the point of view of most other languages.) Unsurprisingly, this \<< [1 2 3] \-> x \<< 1. 1000. START 'x(1)' EVAL DROP NEXT \>> runs 6.5x slower than this \<< [1 2 3] \-> x \<< 1. 1000. START x 1 GET DROP NEXT \>> on Emu-48/HP-49. So, using expressions instead of GET for array access seems unfeasible. But, again, thank you for pointing out that my proposed syntax B looks almost like the whole thing wrapped in an expression. > partitions [1] This one is easy. The proposed operators are "fused": they *must* be connected to the name of a local. No white-space inbetween allowed. So, your example has the regular meaning. Only partitions[1] would be the new thing. If you try to enter "partitions[1]" on an HP-calc you get "partitions [ 1 ]" on the stack, so that wouldn't work. But, then, RPL+ is not meant to (or, rather, cannot) be retro-fitted to existing HP calcs. Thanks for feeding in! Edited: 5 Apr 2011, 6:13 a.m.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall