-
×InformationFix Windows 10 Update Issues
Resolve Windows 10 related issues for your HP computers or printers by HP Windows 10 Support Center
-
-
×InformationFix Windows 10 Update Issues
Resolve Windows 10 related issues for your HP computers or printers by HP Windows 10 Support Center
-
- HP Community
- >
- Other Products
- >
- Calculators
- >
- TRANSLATING 400 PROGRAM SYSTEM FROM HP-50G TO HP PRIME CALCU...
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Create an account on the HP Community to personalize your profile and ask a question

TRANSLATING 400 PROGRAM SYSTEM FROM HP-50G TO HP PRIME CALCULATORS
08-10-2018 07:02 PM

Thanks for your insights!!! I appreciate them and especially your prompt response.
You're right about the difficulties in "transfering" between two different platforms, BUT taking that into account what worries me more is the absence of structured directories in HP PRIME for such a tremendous amount of programs (400 - yes, four hundred). Is it possible for HP PRIME accomodate all of them? And how to manage these 400 programs without folders / sub-folders (like TI-Nspire) or without directories / sub-directories (like HP-50G)??
Thanks again for your kind attention.
09-11-2018 11:49 PM

Hello,
As said earlier, the problem is not feasability. Prime can handle much more than the 50G does...
The main issue is that, not only is the Prime programming language different (althrough a lot of the functions names are the same), but organizational concepts are completely different.
This means that not only will you need to transform your program from RPL to PPL, but you also might need to re-organize things in a way that you are not yet familiar with.
It is not that it is difficult, but to do it correctly does first require to learn/understand the new organizational concepts, a re-analysis of your programs, a re-fit of said programs within this new framework, and then the translation of the programs from RPL to Prime programming language...
If you just start takign each program one at a time and try to create an equivalent Prime program, you will most likely end up with a very messy system.
Main points to understand in Prime:
- Apps vs programs.
Apps are sandboxed environments that are design to separate a series of functionality from the rest of the system so that they are only "active" when the app is started (in some way similar to the "current" directory concept of the 50G).
Apps group programs, but also variables files and UI elements.
Programs are more "library" like in the fact that they are always accessible. They are more designed to provide "functions" that you might need to use all the time. As a general rule, you would avoid having any type of UI in them.
- Variables "extend".
They are LOTS of different type of variables in Prime.
System vars (A-Z). These are strongly typed (only Reals, only complex..)
System user vars/functions (vars you create from the command line by typing something like my_var:= value, or function created through the define dialog box). They act like the System vars
App variables. These act like system vars, BUT are only active when the app is active.
Program exported global variables (normal or app program). Global variables of a program. They are user accessible, but are controled by the program. If they are app programs, then they will only be accesible if the app is active
Program non exported globals. Non user accessible variables (but accessible from your program).
local variables in programs
Cas global variables
Cas local variables!
As you can see a LOT of choises. Each of them having a specific use/use case, accessibility and life time.
Anyhow, at the end of the day, what you want to do is feasable, probably not even that hard, but will be a significant amount of work (especially as RPL is kind of a write only language, easy to write, but hard to read), and you should really try to have a good understanding of both the Prime and your 50G system before starting...
Good luck!
Cyrille
09-12-2018 03:30 AM - edited 09-14-2018 10:39 AM

@cyrille wrote:
....(especially as RPL is kind of a write only language, easy to write, but hard to read) ....
Good luck!
Cyrille
I disagree with that statement. I think that RPL is not any more difficult to read than any other calculator program. In actual fact it is easier than e.g. HP10C/11C/12C/15C/16C programs which record key numbers only. It is no more difficult than an un-commented Pascal or C++ program (therein lies the catch that calculator programs are by nature un-commented). It often comes down to how well you know the language. I believe this is a myth that should not be propagated any further.
As for porting RPL programs to the Prime, it's going to take time as a re-write will be necessary.
The REAL problem is that RPL programs (and any program on an RPN calculator) intensively use the stack, which HPPPL programs do not have access to. Therefore it takes a complete re-think on how to structure the program before you can even think about writing it.
Note: edited to make it more polite.
_________________________________________________________
calculator enthusiast
09-14-2018 04:50 AM

To you it may not be difficult at all.
Cyrille was not giving help to you.
He considered also the other readers of this forum.
I can say that I know RPL better than the HPPPL
so to me it is also easy.
Yet I don't write "nonsense"
09-14-2018 11:03 AM

OK, I have changed the wording to try and be more polite.
In education such statements are called "negative reinforcement".
It could prevent people from starting something without even trying.
Please be assured that I have a lot of respect for Cyrille, Tim W, Joe H, yourself and others contributing to the forum - even though I may disagree from time to time (unfortunately when I disagree I tend to come across quite harsh).
Best regards
_________________________________________________________
calculator enthusiast
Didn't find what you were looking for? Ask the community