Threaded Mode | Linear Mode

John Keith · 06-03-2023, 03:34 PM

(06-03-2023 10:08 AM)jonmoore Wrote: Back to the Prime, I really hope that Moravia carries on developing the OS. Unlike Casio, HP always stuck powerful processing capabilities in the Prime and the G2 processor will keep the Prime trucking for a few years yet. Plus the Prime is the only calculator that breaks free from its primary marketing segment, namely education. Even though it has a weak RPN capability, it's far more interactive than using the Nspire or the ClassPad. And much as the bling design is aimed at students, it looks less like a student calculator than the other options.

Unfortunately the decisions that HP made to appease standardized testing boards (locked firmware, the wall between Home and CAS) make the Prime unattractive to enthusiasts or professional users. The Prime is more powerful than its Casio and TI competitors but the restrictions essentially relegate the Prime to being a student calculator.

If Moravia, etc. wanted to produce an "enthusiast-friendly" version, it could be done with minimal hardware changes- just a different bezel color and the elimination of the "test mode" LEDs. Such a calculator could be marketed as the "Prime Pro" and would have unlocked firmware and integrated CAS, and the hardware changes would allow teachers to easily distinguish it from the standard student model.

I am not holding my breath in expectation of such a product but I would certainly purchase one if available.

parisse · 06-04-2023, 09:51 AM

(06-03-2023 10:08 AM)jonmoore Wrote: I know the two major distributors of educational calculators here in the UK fairly well, Oxford Supplies and ScienceStudio. It's their opinion that the era of large graphical/scientific calculators, with or without CAS, is over. Look at the number of refreshes Casio has made to their mid-market education calculators since they launched the FX-CP400 ClassPad II back in 2013. It's had refreshes but mainly to add an examination/test mode to appease examination boards. The OS itself has hardly changed since Casio launched the ClassPad back in 2003. To make matters worse, all models are using an ancient ARM SoC, which was underpowered back in 2013.

I believe that the Classpad calculator is dead, at least it's what you deduce from amazon sales. It's not really a calculator because you need the stylus, and it's not a touchscreen like the Prime. You can not predict the future of graphing (CAS or non CAS, Casio or other brands) calculators from the Classpad.
My opinion is that the total number of high-end calculator sales (price>125$) will continue to decline, but at the same time, lower priced calculators will have more and more capabilities. As an illustration, I estimate that the Casio CAS most popular calculator is no more the Classpad but the FXCG50 with KhiCAS: I got a new record of 580 downloads of the English addin version last month (and 1840 hits on the documentation).
And it's not that clear that tablets or smartphones will replace calculators in the educational market, this was already predicted 10 years ago but dit not happen yet. Calculators keep some advantages: hardware keyboard, lower battery consumption, more robust, no social network distraction, it's easier to allow them during tests.

Steve Simpkin · 06-04-2023, 11:40 AM

Meanwhile in the U.S., Texas Instruments graphing calculators have a lock on the U.S. school system. Specific TI models have been written into many textbooks and the usage of Casio, HP or Sharp calculators are relatively rare. This situation has been going on for over 30 years and is unlikely to change in the foreseeable future.

https://www.extremetech.com/mobile/21562...tor-ripoff

jonmoore · 06-04-2023, 04:45 PM

(06-04-2023 09:51 AM)parisse Wrote: I believe that the Classpad calculator is dead, at least it's what you deduce from amazon sales. It's not really a calculator because you need the stylus, and it's not a touchscreen like the Prime. You can not predict the future of graphing (CAS or non CAS, Casio or other brands) calculators from the Classpad.
My opinion is that the total number of high-end calculator sales (price>125$) will continue to decline, but at the same time, lower priced calculators will have more and more capabilities. As an illustration, I estimate that the Casio CAS most popular calculator is no more the Classpad but the FXCG50 with KhiCAS: I got a new record of 580 downloads of the English addin version last month (and 1840 hits on the documentation).
And it's not that clear that tablets or smartphones will replace calculators in the educational market, this was already predicted 10 years ago but dit not happen yet. Calculators keep some advantages: hardware keyboard, lower battery consumption, more robust, no social network distraction, it's easier to allow them during tests.

I agree ref the ClassPad calculator being a dead hardware offering. But this is what Casio see as the future of ClassPad - https://classpad.net/intl/ - and it's already been a big success in Australasia, where it made a big splash during COVID. It subsequently won a number of prestigious awards from the education sector. I'm sure Texas Instruments have been taking notes, and will likely launch something similar for the US education sector.

Rather than writing an essay on the subject, I've taken a number of screen grabs and have put together a mini presentation to give a flavour of how the service works, what's free, and what has to be paid for as a subscription. Texas Instruments and Casio have always supplemented their hardware calculators with desktop facsimiles. This is the first time one of them has completely replaced the hardware calculator with a browser based alternative.

[Image: uh3YqR]

parisse · (This post was last modified: 06-04-2023 06:50 PM by parisse.)

Of course Casio and TI are developping solutions for tablets based on their calculator softwares, they must have some solutions in competition with ggb and desmos if some countries decide to switch to tablets.
But that does not mean they are planning to stop calculators. If you look at their offerings, then it's very expensive. At 25$/year, you could buy a new FXCG50 after 3.5 years. With the software, you must provide the hardware and at the end of the subscription, you have nothing left. Perhaps they don't want to kill the calculator market, but that's not serious, ggb is free... The only way such a pricing model could work is if they can convince educational institutions to enforce some specific features they are the only one to provide. I hope these institutions will keep the markets open, but I fear they won't.

jonmoore · 06-04-2023, 07:21 PM

(06-04-2023 06:49 PM)parisse Wrote: Of course Casio and TI are developping solutions for tablets based on their calculator softwares, they must have some solutions in competition with ggb and desmos if some countries decide to switch to tablets.
But that does not mean they are planning to stop calculators. If you look at their offerings, then it's very expensive. At 25$/year, you could buy a new FXCG50 after 3.5 years. With the software, you must provide the hardware and at the end of the subscription, you have nothing left. Perhaps they don't want to kill the calculator market, but that's not serious, ggb is free... The only way such a pricing model could work is if they can convince educational institutions to enforce some specific features they are the only one to provide. I hope these institutions will keep the markets open, but I fear they won't.

I hear what you're saying, and agree. I'm simply communicating what they're up to.

I forget the number of occasions I've applauded you for making KhiCas available on so many devices for free, not to mention the wider distribution of Xcas. Smile

dkostan · (This post was last modified: 06-30-2023 02:04 AM by dkostan.)

Pretty "simple" for me:

HW:

USB C
WiFi/BLE
A Row of 6 Function/HW menu keys below the screen
(48/49/50g style but can be a bit smaller vertically than standard keys)
Maybe a slightly better display resolution. On the fence since I think 7 (or more) color e-ink
display might be better for a calculator for power and persistent reasons. Normally I use a calculator in well lit areas (I think most do, right?) so backlight seems like a waste of juice and its annoying when it dims (on a calculator) to save power. E-ink seems better here to me.

SW:

Add back in full engineering RPN support. That would include support to run RPL code.
Maybe built in emulation for the older platforms with support by adding a key mapping compatibility setting/file that could solve most issues due to the keys being different.
I use base48 and its great but I would prefer built in base number support similar to 48-50g (just add an option/setting for this style)
Seems like support for many interpreted and compiled languages would be "easy" these days. Many like python. I prefer C and hp ppl, but really seems like all of these could be supported with loadable packages & libs. Storage and cpu is not the limiter these days. Good community support could make this happen if the SDK was opened up.

Eddie W. Shore · (This post was last modified: 06-30-2023 04:40 PM by Eddie W. Shore.)

Python desires:

1. A command to clear the console
2. You don't have create another app to run another python file
3. When you make changes to the python file in the emulator: the changes are saved! I am currently editing a Python file and several times a copied in a code. The new code wouldn't save, not even after deleting the copied app and redoing a new one. (Learned that in the HP Connectivity Kit, the refresh command is my friend)

Python is not friendly at all on the HP Prime.

CyberAngel · 07-17-2023, 07:25 AM

New Prime?
Is it feasible to have a HP-28S or HP-18/19 Business -like wallet calculator?
When doing any calculator key (button) manipulation
the extra keys on the left side could be assigned as complex numbers using the imaginary part as the new key_id.
ISKEYDOWN(key_id); GETKET, ...
I mean if pressing [ 1 ] returns 42 then on left side [ Z ] could return (0, 42)
OR use negative numbers for the left OR alphabet stringsm
hmmm...
ISKEYDOWNALPHA(key_id); GETKETALPHA, ... would get the key name!
Exactly as written on a key, eg. "SIN"
Programming as usual:
KEY K_A...Z, LC, ENTER, SHIFT or whatever HP 28S had on the left. side of the calculator.
[Image: HP-28S.jpg]

m_a_s · 07-17-2023, 01:01 PM

(04-06-2020 08:53 PM)Dands Wrote: Would you guys trade the mechanical keys for a huge cellphone-like calculator?

No. Mechanical keys are a must. Besides, what's the point. May as well just update the app.

Eddie W. Shore · 07-17-2023, 01:43 PM

I would take a HP 28S with a few improvements:

* Change the battery cover or make it rechargeable
* USB connectivity
* Larger screen. It doesn't have to be touchable but large enough for a graphing calculator.

john gustaf stebbins · 07-18-2023, 12:38 AM

(07-17-2023 01:01 PM)m_a_s Wrote: No. Mechanical keys are a must. Besides, what's the point. May as well just update the app.

Has anyone looked into creating a Bluetooth calculator keyboard for use with phones and computers? It seems that there are off the shelf components for makers that could implement the electronics. The tough part would be assembling good feeling keys and deciding on a layout. Using overlays it might be something that could support different types of calculators and data entry modes. I've got regular keyboard and mice that handle switching between multiple devices so I can use them on my phones and computers. I'd like to see something with more keys than a standard 10-key pad, but not necessarily the full key set of a Prime.

gwh · 10-17-2023, 01:20 PM

(07-18-2023 12:38 AM)john gustaf stebbins Wrote:
(07-17-2023 01:01 PM)m_a_s Wrote: No. Mechanical keys are a must. Besides, what's the point. May as well just update the app.

Has anyone looked into creating a Bluetooth calculator keyboard for use with phones and computers? It seems that there are off the shelf components for makers that could implement the electronics. The tough part would be assembling good feeling keys and deciding on a layout. Using overlays it might be something that could support different types of calculators and data entry modes. I've got regular keyboard and mice that handle switching between multiple devices so I can use them on my phones and computers. I'd like to see something with more keys than a standard 10-key pad, but not necessarily the full key set of a Prime.

Someone did it the perfect way @ https://hackaday.com/2019/08/16/broken-h...-keyboard/

john gustaf stebbins · 10-18-2023, 12:26 AM

(10-17-2023 01:20 PM)gwh Wrote: Someone did it the perfect way @ https://hackaday.com/2019/08/16/broken-h...-keyboard/

Wow. Yep, proof of concept. A bit bulkier than I would like, but exactly the right keyboard.

I'll have to keep an eye out for a donor 48g.

c3d · (This post was last modified: 10-18-2023 10:51 PM by c3d.)

I would like to bring up DB48X in this thread. DB48X is a from-scratch reimplementation of RPL, that runs today on SwissMicros DM32 and DM42 hardware. My goal is to make the best RPL calculator possible in this form factor, with a special focus on usability. The project is fully open-source, meaning that you can tailor it the way you want (and I really hope others will fork and tweak it to their taste).

A Prime port might happen one day. As a matter of fact, the first iteration of db48x was a port of newRPL to DM42, but newRPL proved simply too big for that (the DM42 has very limited flash space). Unfortunately for that highly desirable Prime port of DB48X, I only have a Prime G2, which is hard to flash, so for now this is a standstill.

The SwissMicros variant of the DB48X project already has two variants, dubbed DB48X and DB50X, the latter being a larger version that fits in the larger DM32 flash space, but not in the DM42. Some features might later be only available on DB50X. For now, it's just that the DB48X optimizes the code for space, and DB50X for speed.

I invite you to visit the GitHub project to see what it does today. But I'd like to pick some highlights of this thread to see how DB48X responds. This makes this message a bit long... I would appreciate if contributors to this thread could take the time to enter GitHub issues in the project for the features they'd like to see.

(04-06-2020 09:14 PM)John Keith Wrote:
(04-06-2020 08:53 PM)Dands Wrote: Would you guys trade the mechanical keys for a huge cellphone-like calculator?
[...] IMHO the main thing that differentiates a physical calculator from a cell phone is a mechanical keyboard. Haptic feedback is nice as far as it goes but not a complete substitute for mechanical keys.

I am a big fan of mechanical keys. If I could change one thing to the Prime, it would be adding 6 physical keys to trigger the softmenus without hiding them with my fingers. DB48X takes full advantage of the DM42 function keys, with typically up to 18 functions that can be accessed (using shift and double-shift), and are all shown on screen (menu behaviour is configurable, e.g. 1-row menu if you prefer). The DM42 has no "next" key, unlike the HP48, so when a menu grows too large, F6 acts as "Next".

Quote:On the subject of new features, real RPL (or New RPL) would be my first request, and ideally replacing PPL in its entirety with Python. Mathematically I would like to see the addition of Lambert W, LogGamma and hypergeometric functions to name a few...

RPL: Check. LogGamma: Check (can also be spelled lgamma). The others, not yet (but feel free to contribute them, viva free software).

(04-06-2020 09:48 PM)Jenab6 Wrote: I want an HP Prime II that has a much greater diversity of function types to model data with.

Curve fitting is not yet implemented, but will definitely take that remark into consideration when we get there. Could you add an issue to the project please?

Quote:While you're at it, think about putting in a Fast Fourier Transform function, too.

Not yet implemented, but planned.

(04-06-2020 10:54 PM)BruceH Wrote: I'd quite like to see a way of defining custom alternate number formats.

Regarding number formats, DB48X assigns the EEX key to a Cycle function that cycles between representations of a number. For example, it will cycle between 1/5 and 0.2, or between polar and rectangular for complex numbers.

Having a way to customize number parsing and display is vaguely on my list, but no good design yet.

(04-07-2020 03:20 AM)Dands Wrote: Maybe another thing to consider is to not have Home and CAS separately. Maybe it would be simpler to just combine both in just one "calculator". This would make things easier to the end user.

The Home/CAS split seems to be a recurring theme in this thread. RPL did not have this split, nor does DB48X. My vision for "apps" is closer to the HP48 than the Prime, i.e. views on a shared integrated runtime, not separate runtimes.

(04-07-2020 07:14 AM)grsbanks Wrote: What I would like to see is probably incompatible with the educational direction that HP seem to have taken, but I'll put it out there nonetheless.

I would like to see a machine with the power and format of the Prime G2 but with a full implementation of RPL, without the bugs introduced in the HP 50g by Kinpo (alarms not working properly for starters).

Alarms are not implemented yet, but it's planned and possible on SwissMicros hardware. The implementation of RPL is almost complete (the main stuff that is missing at the moment is the CASE statement and support for unit objects). As for bugs, being free software means they will be fixed.

(04-07-2020 08:36 AM)andylithia Wrote:
(04-07-2020 07:14 AM)grsbanks Wrote: What I would like to see is probably incompatible with the educational direction that HP seem to have taken…
[...] I hope HP can find a way to allow SDK programming. For example: give the user a choice to blow a fuse to access the third-party program loader, and the fuse is hard wired to the exam-mode LEDs, or whatever.

This is also a recurring theme. I can't comment on what HP/Moravia would do for an actual HP calculator, but they are indeed constrained by relatively braindead regulations. SwissMicros does not have this problem, their hardware is fully flashable.

(04-07-2020 03:28 PM)John Keith Wrote: It has been mentioned previously that the Prime does not have enough built-in flash to hold "full" Python, which would presumably include NumPy, SciPy, and SymPy. I think that the best we could hope for is for existing Prime functions to be merged into Python, possibly as a custom package.

I have said many times before that I would vastly prefer a modernized RPL to PPL but Python has seemingly taken over the world, and doubly so in education and scientific programming. I wish that the Prime had been based on Python from the beginning, but I hope it will continue to move in that direction.

Definitely no Python support on a DM42. However, I am considering an SDK that would let you have loadable binary libraries on the 6M of available flash disk, presumably written in C++.

(04-07-2020 04:48 PM)TheLastMillennial Wrote: [...] There's a lot I'd like to keep from the current Prime. First off, keep sharing batteries from smartphones! The fact you can increase the original Prime's battery from 1,500mAh to 2,500mAh is fantastic! Keep the current button feel (or make the calculator an inch thicker just to add fully mechanical keys ). Keep the high refresh rate capabilities! Keep using Phillips head screws instead of some proprietary screw or a form of Torx. Also, keep all the screws visible without needing a heat gun unlike the Nspire. Finally, keep the awesome CPU, RAM, ROM, and RTC specs (or improve them farther!)

Honestly I'm still not a big fan of the current software setup[...]

This seems to be another major trend in this thread is that the Prime hardware is overall fantastic. If someone from HP/Moravia wants to find a way for DB48X to run on this platform, I'd be enthusiastic. Because the original iteration had the prime as a target, graphic routines already support color, for example, and adding back Prime keyboard support would be very easy. It works on simulator ;-)

(04-07-2020 07:55 PM)ramon_ea1gth Wrote: As written in a previous post, I miss some kind of [LastMENU] and [LastCMD] softkeys to reuse the last operations at one touch

Both available in DB48X. The LastMenu and LastCmd are both 8-level deep.

Quote:Some more edition options while editing a program on the calculator, e.g.: double touch to select a word in the text, triple touch to select a line.

DB48X is fully keyboard-centric, since it runs on hardware that has no touch screen. But it has text selection, word movements, search and replace, cut/copy/paste, and as mentioned earlier, 8-level of command-line history.

Quote:Custom softkey menus

Planned, but not implemented yet, except to the extent that the 'VAR' menu shows variables in the current directory and you can execute the programs there. The "CustomMenu" (CST key on HP48) is on the short-list of features.

Quote:As said, when I use the calculator, I don’t expect to have a computer next to me most of the time (for documents I use an e-reader). I have to say that the more I check the machine with the HP Prime manuals but also with the GIAC/XCAS specific manuals, the more I see that the software capabilities are awesome.

DB48X has a built-in help that is in markdown format, and is the same as what is visible on the web. Holding a key for more than one second (which would cancel the function on HP41, for example) brings up the on-line help for that key. This is an important aspect of discoverability. The online help supports internal hyperlinks, and has higher-level sections. It can be searched with the HELP function (2nd shift and + key), which applies to the first level of the stack. If you type a complex number and HELP, it shows the help on complex numbers. If you type "Authors" and HELP, it shows the list of authors, and so on.

I would like this on-line help to be reference-level, not newRPL level. It's stored in a file on disk, there are 6M available and the current documentation is 92K.

Another important aspect of discoverability is the catalog. If you are in "Alpha" mode and hit the + key, it brings up a dynamic softkey menu (also available with shift-+ in normal mode) that lists all available functions beginning with what was typed. For example, if I type 'eq' in the current version, I see "equiv" (a logical operation) and "EquationMenu" (a menu dealing with equations). If I type "AD", I see "+", because it's also known as "Add".

(04-12-2020 05:02 PM)John Keith Wrote: I am not optimistic either, but I would also like to see a "Prime Pro": Minimal hardware and software changes, just remove the test mode LEDs and perhaps also a distinctively different bezel color so that teachers and test proctors can tell it at a glance.

Most importantly, unlocked OS flash so that alternative OS's such as New RPL can be added without hardware mods. Along with Eric's proposals, the Prime Pro G3 would be a true enthusiast's calculator.

I realize that education is the main market for calculators today but the small cost of the changes just might make the Pro feasible. We can still dream, can't we?

I like the idea, and if this platform became available, I would quickly port DB48X to it.

(04-13-2020 12:02 AM)Jacob Wall Wrote: - Either one or both of a) microSD card, b) more memory, and simpler method to transfer files (no CK, calculator shows up as drive)
[...]
- Support for a major programming language, Python would probably be suitable

On the existing DM42/DM32, it's possible to present the internal disk as a regular USB FAT-formatted Flash drive.

As indicated above, my plan for major programming language is C++. Running a Python interpreter on SwissMicros machines seems hard. On Prime-level hardware, sure.

(04-13-2020 10:52 PM)John Keith Wrote: I don't use CAS functions very often but I do use large integers which are supported by the CAS, not Home. Also the G2 has gobs of memory so removing the CAS would serve no purpose that I can see.

It would also be great to get rid of the 10000 digit limitation for integers and the 10000 element limitation for lists and arrays but that may require major software changes.

DB48X supports big integers, and I plan to support big real numbers newRPL style someday. The maximum size of a big integer is configurable in bits. That being said, I tried 2000! on a DM32, which is a 5737-digit number, and it takes a while to compute. More annoyingly, it takes a while to display or edit. That's a good case for further optimizations :-)

(04-14-2020 04:10 AM)Jacob Wall Wrote: I forgot to mention better RPN mode, intuitive (to me anyways) methods of entering, editing and working with lists, vectors and matrices directly from the stack like the 50g was fantastic. Heck, currently in RPN mode the right cursor doesn't even SWAP the top two levels of the stack. Small detail, but which if you're used to the 50g in RPN mode will probably be a bit of a let down.

Last thought (for now), I think having the function keys for the menu would still be great even with the touchscreen.

Check and check. I think you would be pleased by the improvements DB48X brings over even the HP50G in terms of context-awareness and efficiency of the command-line. A lot of this was inspired by newRPL.

Juts a recent change: shift-0 is : which enters : when inside a text, but :: otherwise (with cursor in the middle) for a tagged object.

There is also a "ToolsMenu" which is context-aware, looking for example at the first level of the stack to bring you a menu that works with this kind of object. So if you have a complex number on the stack, you don't need a shifted key to bring up the complex menu, the tools key will do that. It's mapped on the "Sigma+" on the DM42.

(04-15-2020 03:09 PM)rogr Wrote: 1. A backlit keyboard would be great.
2. A system wide "back button".
3. A row of programmable hardware keys I can use without switching to a "user mode".
4. A key to make screenshots that are stored as .png files on the HP Prime.
5. I would like to drag simple .txt or .png files from the PC to the HP Prime. So to speak a file browser App with a folder structure.

1 is a hardware feature, skipping.

2: there are commands for last menu, last command, last stack, last args and last x. All have direct key bindings except lastx, which is mostly there to help porting RPN programs that use LastX and not LastArg.

3. Check on DM42 and DM32.

4. Planned feature, available with the default firmware of the DM42 but not implemented yet on DB48X. Like the DM42, it's likely to be mapped on held-shift-EEX (shift-EEX brings up the display menu). There will be an RPL command as well.

5. As indicated above, the DM42 can mount as a USB disk. The state of the calculator can be saved in standard text format to the disk. A key binding to save the state to the current state file is shift-shift-EXIT (shift-shift-ON on DM32). You can have as many state files as you want. There is also a built-in file browser.

(04-15-2020 05:29 PM)John Keith Wrote: I gather that the opinion at HP HQ is "who needs more than 10000 digits on a $@%#! calculator?" I would say that if a 20 year old calculator (HP-49) could handle more than 10000 digits, why would anyone want to go backwards?

It's really more a problem of performance. Computing 2000! on the DM32 takes 5.6s, which is not too bad. Converting that number to text for display, however, makes that jump to 94s. you need a bunch of "bignum" divisions to compute all the digits. By comparison, it takes about 746ms on an Apple M1 chip, so faster CPUs would definitely help here.

(04-17-2020 07:41 PM)Hans S. Wrote: 1.) Owner's Handbook
2.) Problem-Solving Guide
3.) Advanced User's Reference Manual

Please feel free to contribute to the DB48X documentation so that it reaches that level. Crowdsourcing this will ensure the material is really good.

(04-21-2020 11:04 PM)acoto Wrote: I will like to see a congruent family of calculators, same look and feel, but with a steep up path. All of them with default RPN entry mode. ( Not sure about wanting Algebraic as secondary option)

DB48X is RPL, not RPN. It does support algebraic in the HP48 spirit, i.e. you can type an equation like '1+3' and hit EVAL. The EVAL key has a triple role: Evaluate in direct mode, Space in text editing mode, and = sign in equation mode. If there is a DM48 one day, it might have an equal sign on the keyboard ;-)

It already has some optional features, and will get more as I hit the memory wall on the DM42. But the idea is also to have a configurable firmware with variants that focus on this or that use case. That's a key driver for having this as free software. It makes a lot of sense to me to have simplified versions that share the same look and feel but have, for example, a less crowded keyboard.

Quote: - Advanced RPN scientific,
- Full blown engineering RPN, programmable, CAS, statistics, financial
- Intermediate Financial, RPN
- Advanced Financial, RPN

At the moment, the focus is on full-blown (and that includes financial). But carving out subsets that are otherwise almost 100% compatible is clearly in the spirit of what is being developed.

(04-22-2020 09:13 PM)Tugdual Wrote: The hardware of the g2 is very powerfull and the only weakness in my opinion is the screen. Software wise I never adopted the Prime, my favorite calc remains the 50g.

I really hope you will like DB48X.

(04-24-2020 05:57 PM)Jake Schwartz Wrote: Perhaps this could be on the Swiss Micros "wish list" ? :-)

It is now :-) I have been discussing this project with SwissMicros, and I think they like it. As a matter of fact, the DM32 SDK was released early "just for me", because I was seeing the point where I would hit the limits of the DM42. Since then, I learned a new trick from the C47 team that allowed me to put more stuff in the QSPI, so I went further on the DM42 than I initially thought would be possible.

(04-24-2020 09:01 PM)John Keith Wrote: I was told once that the Swiss Micros people are not interested in HP-48 series calculators. Even if there was interest the hardware would have to be different- a fast ARM Cortex processor and much larger RAM and flash than their current offerings for starters.

To be fair, having a good RPL implementation within the constraints of the existing SwissMicros platform is hard. As I pointed out, my initial plan to port newRPL did not pan out. I had to devise a more compact firmware.

I believe that the existing DM32 hardware will allow us to reach HP50-level capabilities, and the DM42 hardware will be HP48-level. Hence the names of the subprojects. Time will tell, meet you back in a few months.

(04-25-2020 10:56 PM)Orome Wrote:

An RPL stack (e.g., ‹‹...›› for RPN macros, '...' for algebraics).

Python (for anything more than macro or simple expression programming)

Check for the RPL stack. Python probably out of scope on SwissMicros hardware. But who knows, maybe a creative C++ library will be able to bring that in. We'll see.

(04-26-2020 10:08 AM)BruceH Wrote: Last time I spoke to Michael from SwissMicros he said that a 48SX was possible within the RAM/ROM constraints of the ARMs available. The main problem is that the 48SX ROM has not been released for commercial use - only non-commercial - so Emu48 can't be ported.

It cannot be a true HP48, that much is certain. It has to be a reimplementation. The good news is that the reimplementation exists and runs relatively well today.

(04-26-2020 02:47 PM)Tonig00 Wrote: The hardware of the G2 prime is very very good. I just would add USB-c.

The DM32 has USB-C. I'm not sure what I can do with it yet.

Quote:R packages for probability (tosscoin, etc).
Bessel functions.
Two/three variables calculus functions.
Better 3d graphics interphace
Improve units treatment.

All of these are doable on the platform, but not planned, except units. If you could open issues on the project with precise descriptions of what you have in mind, it would help me keep track of it.

Quote:Maybe some more numerical precision. Not as much as SwissMicros but 16 digits would be nice. That is difficult I saw that many algorithms have to be rewritten.

DB48X currently uses decimal128, so 34 digits of precision like SwissMicros calculators. It also automatically stores numbers in decimal32 and decimal64, so a small number uses less memory. I plan to support variable-precision decimals as soon as time permits (but I probably want to have a feature-complete version 1.0 before I get there)

(04-26-2020 03:42 PM)jonmoore Wrote: And unfortunately, I can't see that happening anytime soon.

It's now sooner than you thought. And the good news is that you can help, if only with the documentation.

Note: in that respect, I find it perfectly acceptable to submit a feature request by writing the documentation for it, and letting someone else write the code. We can easily make a "future features" section in the doc. Much of C47 (formerly WP43) was developed that way, with the manual being written before the software.

(04-26-2020 05:48 PM)John Keith Wrote: I personally consider the 48SX to be the nicest looking of the RPL series but too limited in power. I would prefer New RPL running on modern hardware as in my post above, provided that Claudio could reach a software agreement as Thomas did with the DM42.

There seems to be little interest in such things at the moment though.

There is interest now. No commitment yet, but definitely renewed interest.

(04-27-2020 10:24 AM)jonmoore Wrote: 100% agreement. I maintain two 50g's so that one is a dedicated newRPL unit. And for my money newRPL is reaching a level of maturity where it can be considered a v1 OS. Much as the 49+/50g hardware is fast by historic HP calculator standards (outside of the Prime of course), newRPL shows what could have been possible if the 50g hadn't been running on top of an emulation layer.

Compared to newRPL, DB48X is a bit slower, but no slouch either. For example, the N-queens problem currently executes in 1.4s on DM42 on USB power. The best time I had was around 500ms earlier in the lifetime of the project, but that's with optimizations I had to disable for space reasons. This is on hardware that is much slower than the HP50G used for newRPL benchmarks, and there is still plenty of room for optimizations (e.g. I'd really like an incremental garbage collector that runs while you are typing stuff).

Quote:I'm pretty certain that SM could build a bespoke newRPL machine that would still be competitively priced yet offer far more than current 50g hardware.

I don't know how much SwissMicros would be willing to deviate from their existing platform to give more oomf to an RPL model. I think that with DB48X, they might not even need to.

Quote:I don't see the Prime returning to RPL [...]

Much as the 35s has a maligned reputation, it's easy enough to keystroke program the kind of things pre-university students need - better vector/matrix support, GCD/LCM, Prime Factorisation, P/R conversion etc etc, and with Valentín Albillo's excellent solver, it breathes a vital oxygen supply to the 35's stunted complex number support. It's sluggish performance may feel like wading through molasses but at least it's allowed in the examination room (and for a far wider set of subjects than US engineering examinations).

I think that DB48X strikes a good balance here, with good usability and performance. But feedback is appreciated.

Quote:Back to the Prime, one relatively simple feature request I'd love to see in a revision of the Prime operating system is touchscreen support for the stack. There's a nifty little iOS app based of the 28s that does this and it makes most of the standard RPL stack manipulation tools redundant during normal use. Programming workflows obviously still rely of the old school standards but for real time manipulations, a touch based stack is far more flexible.

The HP48 interactive stack is still missing in DB48X. So are equation and matrix writers. Planned, but not there yet, and if I have to drop something on DB48X vs DB50X, that might be part of it.

(05-04-2020 01:01 PM)Marco Polo Wrote: IMHO (and i am not a license guru, so i am likely wrong) the ROM non commercial release might be a false problem: SM could provide the hardware running a ported version of EMU48, eventually with a kit (bezel+keys) for SX/GX conversion, but no rom(s) at all.
It would be in charge of the end user to procure and install the desired rom on the calculator

I don't think that would fly for three reasons:

1/ License-wise, it is shady, even if you let the user download the ROMs.

2/ It's stuck in the past, because the ROM is not open-source and written in an obscure SystemRPL that very few people know about. DB48X is written in C++. A special use of C++ to enable garbage collection and a really super-compact object representation (an integer like 123 takes 2 bytes, a text like "ABC" takes 5).

3/ The required hardware would be much more expensive and power-hungry that SwissMicros' current platforms.

(05-04-2020 03:01 PM)jonmoore Wrote: EMU 48 can be sluggish on all but the latest iOS and Android hardware so I doubt whether the DM hardware would be able to run it with sufficient performance. The DM folk could always specify new hardware, but they wouldn't be able to maintain the DM42 price point (they don't have the economies of scale to compete with the likes of Casio, HP and TI).

I agree with you regarding SwissMicros hardware. I hope that you will find DB48X reasonably fast, even on DM42 hardware. It's definitely much much faster than the HP48, notably with graphing.

(05-06-2020 07:15 AM)Marco Polo Wrote: What about porting NewRPL to DM42 platform?

Tried this, as mentioned above. It was too big by a factor of about 2, both in flash space and RAM usage. It was designed for much beefier hardware. It was a huge disappointment, because it worked so well on simulator ;-)

I think that DB48X has now reached the point where it is superior to newRPL in important areas, notably usability and graphics.

(05-06-2020 05:13 PM)jonmoore Wrote: NewRPL is designed for embedded chips so it's highly likely that this will be a more feasible ambition - as John Keith and I alluded to a few posts back.

Much as NewRPL is in beta on the 50g, that hardware is simply the base test platform. The use case ambition is far wider than a chipset that's more than 15 years old!

Indeed, but that would require a new SwissMicros platform, or some really significant engineering on the newRPL side.

(06-24-2020 06:25 PM)Anders Wrote: Personally, I want to see the prime platform move forward not backwards to some sort of "good old days" which were quite frankly not that great anyway…

Actually, they were great. There is a reason so many people run an HP48 emulator on their iPhone. I don't have numbers, but I suspect it dwarfs the number of people running a Prime emulator on that same iPhone.

But I agree on the "moving forward" part, which is why I undertook this rewrite from scratch.

Quote:I would like to minimizing mundane task so you can operate at the conceptual level letting the machine do the mundane takes. Like in the past where you spent time on the wrong things, putting huge effort into: obscure programing, minimizing key strokes, using programming models developed for another time and much less capable h/w, where focus was counting # of bytes, minimizing # of clock cycles and fitting stuff into kilobytes of storage (and believe me I have done that). Trying to fit stuff within memory and CPU constrains is interesting topic on its own, but not if you are taking an EE, ME etc class in 2020. In year 2020+, you want solution solving productivity!

But minimizing keystrokes is problem solving productivity. And in terms of the time it takes to program some computational-intensive problem on a hand-held device, I think that RPL beats both RPN / keystroke programming and Python / PPL. RPN does not have the expressive power (and in some cases, neither does PPL - Variable names are a good example). PPL or Python are way less efficient and much too verbose for a calculator.

Quote:I want to see:[...[ Completely different level of integration and consistency between CAS and Home view. [...] The move between Home and CAS should be seamless. Most of the time to day, I find myself doing lots of copy paste to fit the format on either side.

This is exactly what makes RPL so great.

Quote:For this to work you need a more fully fledged and richer CAS, including the home view functionality of course but also specifics (like various transformations etc.) for the various branches of engineering and math. For instance: trying to solve a simple systems problem moving back and forth between time and S (Laplace) domain with a mix of unknown and known variables, and actual numbers, is just plain painful.

Like in newRPL, DB48X has a general-purpose Rewrite function that lets you perform arbitrary algebraic transforms, including illegal ones. For example, let's say that you want the 'sq(sin(x))+sq(cos(x))' expressions to be transformed not as '1' but as 'x/x' for some reason, you can do that with:

Code:

<< 'sq(sin(x)) + sq(cos(x))' 'x/x' Rewrite >>

'MyIdent' STO

Then you type something like 'sq(sin(A+B-C))+sq(cos(A+B-C))' MyIdent and you get '(A+B-C)/(A+B-C)'. There are even special variable names to match only non-zero positive integers or an expression that only appears once inside the pattern.

So while the CAS in DB48X is not full-featured yet, it already has powerful tools to add your own rules.

Quote:It’s a good example because it includes Laplace or Z transformation, (potentially) solving multiple 2nd or higher order equations, partial fraction expansion decompositions, followed by inverse Laplace or Z transformations (potentially) also involving matrix and vector manipulations (eigen values etc) in the more general case. Multiple issues with today’s Prime (and I don’t expect a future Prime to solve it all in one go with one button – not at all).

If you could spend the time explaining on GitHub how you would expect this to work (e.g. by writing the documentation for future commands doing what you want), I'd appreciate it.

Quote:Today it is just too cumbersome: some can be done in CAS some has to be done in home, but moving between the two modes and transfer intermediate results is just too hard, so end up doing most on paper and just re-enter stuff. Of course you can write CAS program to do this but that is just the problem – you write programs to solve the home view CAS view inconstancies and lack of integration.

To me, that's definitely a problem that RPL does not have. Even the algebraic mode on HP50G could make sense on DB50X, but not the split-brain approach on the Prime.

Quote:a. polar coordinates conversion between rectangular and polar form with any mix of symbols (of course) and/or numbers

Already there in DB48X. Today in DB48X, you can enter "A+Bⅈ" then use ->Polar and you get "'A⊿B'∡'B∠A'", where the two sides are the infix representation of "hypot" and "atan2". Conversely, if you type "A∡B" and then ->Rectangular, you get "'A×cos B'+'A×sin B'ⅈ"

Similarly, if you enter

Code:

[

    [ A B C ]

    [ D E F ]

    [ G H I ]

]

and then '1/X' or 'Det', you get

Code:

    [ 'A⁻¹-B÷A×((-D)÷(A×E-D×B))-(C÷A-B÷A×((A×F-D×C)÷(A×E-D×B)))×(((A×E-D×B)×(-G)-(A×H-G×B)×(-D))÷((A×E-D×B)×(A×I-G×C)-(A×H-G×B)×(A×F-D×C)))' '-(B÷A×(A÷(A×E-D×B)))-(C÷A-B÷A×((A×F-D×C)÷(A×E-D×B)))×((-((A×H-G×B)×A))÷((A×E-D×B)×(A×I-G×C)-(A×H-G×B)×(A×F-D×C)))' '-((C÷A-B÷A×((A×F-D×C)÷(A×E-D×B)))×((A×E-D×B)×A÷((A×E-D×B)×(A×I-G×C)-(A×H-G×B)×(A×F-D×C))))' ]

    [ '(-D)÷(A×E-D×B)-(A×F-D×C)÷(A×E-D×B)×(((A×E-D×B)×(-G)-(A×H-G×B)×(-D))÷((A×E-D×B)×(A×I-G×C)-(A×H-G×B)×(A×F-D×C)))' 'A÷(A×E-D×B)-(A×F-D×C)÷(A×E-D×B)×((-((A×H-G×B)×A))÷((A×E-D×B)×(A×I-G×C)-(A×H-G×B)×(A×F-D×C)))' '-((A×F-D×C)÷(A×E-D×B)×((A×E-D×B)×A÷((A×E-D×B)×(A×I-G×C)-(A×H-G×B)×(A×F-D×C))))' ]

    [ '((A×E-D×B)×(-G)-(A×H-G×B)×(-D))÷((A×E-D×B)×(A×I-G×C)-(A×H-G×B)×(A×F-D×C))' '(-((A×H-G×B)×A))÷((A×E-D×B)×(A×I-G×C)-(A×H-G×B)×(A×F-D×C))' '(A×E-D×B)×A÷((A×E-D×B)×(A×I-G×C)-(A×H-G×B)×(A×F-D×C))' ]

]

and

Code:

'A×(A×E-D×B)×((A×E-D×B)×(A×I-G×C)-(A×H-G×B)×(A×F-D×C))÷(A²×(A×E-D×B))'

The approach taken also ensures that matrix operations and even some numerical operations will stay with fractions. For example, inverting

Code:

[

    [ 1 2 3 ]

    [ 4 5 6 ]

    [ 7 8 19 ]

]

will give you

Code:

[

    [ -47/30 7/15 1/10 ]

    [ 17/15 1/15 -1/5 ]

    [ 1/10 -1/5 1/10 ]

]

So that's like the CAS mode of the Prime, but I'm in "RPN" mode.

Similarly, entering "1 3 'sq(x)' 'x' Integrate" gives you 26/3.

Quote:proper engineering number formatting like an ENG -> (that you can shift either way) button (and a setting) that formats all numbers into 3* exponentials: x.xxx * 10^3y so you can easily convert to milli, micro, nano, pico, … kilo mega, giga etc.

Exactly my plan as soon as units become available. This will be the role of the EEX key in direct mode (the Cycle feature I already mentioned). In other words, 3_km EEX will give you 3000_m.

Quote:I can think of many more annoying small things… like how many key strokes certain functions take etc

Minimizing keystrokes is exactly where RPL shines. I've really tried to optimize things in that respect. Here are three examples:

1. There is only one shift key on the DM42, unlike the HP48 and HP50. So the secondary shift is achieved by clicking shift twice, and alpha by holding shift. However, since alpha is very important in RPL, you can also get it by holding the up and down key together with an alpha key (for uppercase and lowercase respectively).

2. As I mentioned earlier, hitting + in alpha mode brings up the catalog, which you can use to enter functions by name with a minimal number of keystrokes.

3. The matrix above is entered with the following sequence: Shift 9 Shift 9 Down 1 SPC 2 SPC 3 Down Shift 9 4 SPC 5 SPC 6 Down Shift 9 7 8 1 9 ENTER. That's 26 keystrokes, shifts included. If the Matrix menu is open, then you will soon be able to replace all the Shift 9 combos with F1, so you'd have F1 F1 Down 1 SPC 2 SPC 3 Down F1 4 SPC 5 SPC 6 Down F1 7 8 1 9 ENTER, 22 keystrokes. On the Prime, I need many more keystrokes, or precise taps on the screen, and it gives me a syntax error if I insert spaces in my matrix.

4. I use a lot of "context awareness" to tweak the behaviour depending on what you are doing. I already mentioned for example that Shift 0 will insert a double colon, except if it's inside text, or that the Space key turns into an equal sign inside equations.

Quote:Full python implementation of course (math and science libraries…)

That seems really hard on existing SwissMicros hardware for space reasons. But giving you the possibility to load a binary library written in C++ might be feasible, and would give you C++ math and science libraries. Not as good as Python, but certainly faster, which matters on small-sized machines like that.

Quote:A proper manual how to use it all to get maximum value out of all the functionality including special books by engineering/science branch (remember HP 42S, 48S, 28S etc. booklets)

YES! And the great news is that you can contribute to it. As I mentioned, it's even OK to contribute documentation for non-existent features, giving developers a clear guide on how a given feature should behave.

Quote:Not saying I want full wolfram in a calculator format (yet ) but much more in that direction.

Wolfram is just fantastic, and I was amazed to see that running on a Raspberry Pi. So there's hope. But making that keystroke efficient is another matter entirely.

(continued ...)

c3d · (This post was last modified: 10-18-2023 11:21 PM by c3d.)

(07-11-2020 04:42 AM)NetMage Wrote: While I have not put too much effort into using my Prime, mostly because I don’t find it very inviting (I actually prefer the TI-Inspire CX) I am surprised no one mentioned units handling.
My main calculator is a DM42 and my second is either my 50g or more often an emulated 48Gx on my iPhone and those are pulled out for units calculation.

I would like to see a full RPL environment with unit handling on par with the 48Gx.

That's next on my to-do list. Unit objects are the last user-level remaining RPL type to implement I believe (discounting developer-level types like libraries or assembly code blobs, which will have to be implemented differently).

Quote:I don’t think languages like micro Python or Python are very good choices for a handheld programming environment which has a small keyboard. Maybe APL but not many would use it ?

APL? Interesting idea.

(07-11-2020 02:38 PM)mfleming Wrote: Agreed, regular programming languages are quite fat while APL is terse, expressive, and able to handle large datasets. But you could probably count the number of potential users on one hand

I think that looking at APL operators to see if any would fit in an RPL context can be a great idea.

(07-11-2020 02:47 PM)grsbanks Wrote: +1 -- which is why I really don't understand the whole "python on a calculator" thing, be it HP, TI or any other manufacturer. Even HP-PPL on the Prime is pushing it IMO. Keystroke programming and RPL are about the best adapted to calculators, which is but one of many reasons why machines such as the HP-41C and HP-42S (and HP 35s, although I don't care for that one very much) are so sought after today, 30 or 40 years after their release.

I am seriously considering adding some level of support for keystroke programming in DB48X. Specifically:

0. LastX command (already done) in addition to LastArg.

1. An editor that shows each RPL object as one numbered step

2. Label and Goto instructions. One question about those is whether we should RPL-ify them the way STO was, i.e. you'd have to state "Foo" Label and "Foo" Goto... :-) This would solve problems like indirect Goto, but what would indirect labels even mean? Alternatively, have some smart logic that would show 'X' Sto as Sto X when in this editor.

3. Other more obscure instructions like DSZ, etc, including their really weird counting semantics. They are not hard to implement.

4. Operators like X<0? with "Skip if false" behaviour.

That being said, DB48X is already quite efficient memory-wise. This NQueens benchmark is only 68 bytes long, vs. 135 for the HP48.

Code:

<<

  0

  DO

    8 SWAP 1 +

    WHILE

      DUP2

      DO 1 -

      UNTIL

        DUP2 5 + PICK - ABS

        DUP2 - * NOT

      END

    REPEAT

      DROP

      WHILE SWAP DUP 1 SAME

      REPEAT -

      END

      1 - SWAP

    END

    DROP

  UNTIL DUP 8 SAME

  END

  ->LIST

 >>

(07-11-2020 04:05 PM)Anders Wrote: Yeah so the reason why Python is preferable with math and science libraries is of course because of it's richness and massive active community of developers extending the libraries.

Indeed. This is one aspect that cannot be brought to the SwissMicros platform, it does not fit. It could fit in Prime-class or Raspberry-class hardware.

Quote:In the year of 2020, I do not sit and program complex solutions on a calculator if I am interested in solution productivity (both in terms of development and usage). Doing so would be nuts!

Depends on whether you are interested in delivering something that works today on existing hardware available for purchase today ;-)

Quote:In 2020, you of course do the development on a PC including debugging. You then transfer it to the calculator to solve problems in small form factor. The calculator becomes a problem solution machine - ideally! This can be extremely powerful. Wolfram is great but the form factor is not there (yet).

At least on the SwissMicros platform, the only way I see that makes this objective even remotely possible is to have a C++ SDK available for developers to build libraries you can then store on the FAT partition. 6M is plenty of space for relatively complicated computations, but RAM is a real issue (there's about 70K free on a DM42, which is plenty for RPL, but not a whole lot for complicated C++ algorithms).

Quote:20-40 years ago we had restrictions on memory and CPU speed that forced us to use more efficient programming models and languages (counting bytes and cpu cycles), but today those restrictions are gone. Further, fast forward a few more years and those restrictions will be even like gone, gone. like irrelevant.

Not at all. The trade-off SwissMicros picked is that you run on a single Lithium battery for years without ever recharging. That has value too.

I would not mind an open Prime-class calculator, and as written above, would happily port DB48X to it. But should that become available, the trade-offs would still remain vastly different from what you do on a PC.

Quote:We need to move forward not backwards. Backwards to the "good old days" of stack based languages (they are called 2nd generation programming languages for a reason) feel like a hobby for retired engineers or some form of calculator archeology with extremely small market potential for HP - not professional solution productive in 2020+.

I thought this thread was about the future not the past.

I believe DB48X is an RPL platform that can last a few decades, because it is open, and that I hope it will extend way beyond this humble DM42 beginning. But in terms of keyboard efficiency, I want it firmly stuck in the past.

The three primary reasons I don't use the Prime as a main calculator are:

1) requires to touch the screen with precision, with tiny targets that are visible for students in a classroom but not really practical for an engineer in a moving train.
2) Programming language is not convenient in the field
3) Does not support large binary numbers and arbitrary bases (e.g. 512-bit or base 3, both of which DB48X does happily).

Two of these reasons are because the Prime chose the "future" over the "past".

Let me just ask a question here: who else uses a calculator app on their PC or Mac? I certainly do. I use iHP48, running an HP50 ROM image. Do you know what is really bad about it? It's actually an iPhone app, so no keyboard support at all, which on a Mac forces me to click click click. Aaaaargh!

(07-11-2020 06:11 PM)John Keith Wrote: I agree in general that Python is not the ideal language for a hand-held calculator but it has become close to a de facto standard for educational and scientific programming. Since several other calculators support Python I would prefer to see Python replace PPL, which is not ideal for hand held use either IMHO.

The educational aspect has changed the face of HP calculators for the worse. While the original HP35 was designed for engineers, since the year 2000 at least the focus shifted towards education markets. For a good reason: they are by far the largest market for such devices.

Since then, various legislations were introduced, and they all required the most advanced calculators to be artificially restricted in what they could do. No restriction, no market. Before that, it was possible for HP to develop a high-end calculator that was actually funded by students, but still could satisfy engineers. The HP48 and HP50 were the culmination of that trend. They were a model of openness, with access to all internals, then-current interfaces with computers or measurement devices, built-in libraries to even do assembly-level coding, and so on.

The Prime had to renegade on all this for one reason and one reason only: legislations that forced HP to choose between education and scientists. HP chose education, and it was the only possible choice from a business standpoint. The Prime is a closed device, and worse, it's focused more on people learning about mathematics than on people who actually need to do mathematics.

The only interest of Python on a hand-held device, frankly, is the education market. For engineers, I see very little practical value, unless you have a device that is actually connected and on-line, i.e. one that has Wi-Fi and does not need numpy integrated because you can pip-install it when you need it. For all those who argue that there is a huge Python ecosystem out there ready to be tapped into: that's only true if your system is truly open and on-line. For engineers, it works on a Raspberry Pi. It does not work half as well on a closed Prime. Having Wi-Fi and pip-install won't work for a device that must pass the "can be used during exams" test.

Quote:Aside from being obscure and unreadable, APL is not a modern language and lacks many features programmers have come to expect. It was designed originally for array processing and not as a general-purpose programming language.

Yes. But it's interesting to see if some APL operators would make sense in RPL. I had not thought about that, and will look into it.

Quote:If I had to pick a modern programming language for a hand held calculator I would choose Haskell. It is a concise and powerful language without the mystic runes and bass-ackward syntax of APL. Haskell is also the basis of the GoferLists library for the HP 50g, which extends the "automatic list processing" features introduced on the HP-48.

Good choice for something you develop on your PC and transfer to the calculator. Haskell bindings for the C++ SDK I talked about could make a lot of sense. But typing Haskell on a calculator? Not my cup of tea!

Quote:Replacing the Prime's vestigial RPN mode with either true HP 50 emulation or New RPL would probably be the best solution overall.

I agree that the "vestigial" approach was half-hearted and does not work, see all comments about CAS mode vs. Home.

(07-12-2020 05:57 PM)Anders Wrote: I think you are right in our different perspectives is because some view a next gen calculator as tool for calculation and some want a tool of thought - truly amplifying your solution solving capabilities at conceptual level.

I think that reasonably speaking, the "tool of thought" is better handled by a PC or a tablet, notably because so much "thought" is on the Internet. So indeed, I am focusing on calculations, and on making such calculations definitely more efficient than with, say, an iPhone app. The major differentiator is a physical keyboard and software stack optimized for efficient calculations. The programmable aspect is only to extend the kind of calculations that can be done, not to perform heavy number-crunching that is best done on more powerful platforms.

Quote:I'm looking for a productive "solution solving machine" in a handheld format which is basically a tool of thought. The idea of reinventing yet another tool for calculations in 2020 is pretty meaningless in my view. HP Prime, HP42S, HP48xx, HP50g or some of Swiss micros flavor will do just nicely.

Prime does not satisfy me for the reason explained above: it targets another market than me, so it moved backwards relative to earlier generations as far as my own needs are concerned.

Quote:I do not think a Prime II should have to goal of perfecting a HP50g or similar in a new case with a modern CPU and more memory, perfecting number of key strokes it takes to perform a function, moving a few buttons around on the key board to perfect the layout or add more highly specialized functions to libraries.

It's likely DB48X will not be for you ;-)

Quote:As I wrote above in the thread, a rich CAS machine that can mix variables (unknowns), variables (known) and numbers is where it needs to go (all CAS stuff disabled in Exam mode). Take Giac, roll in new releases and aim towards Wolfram alpha.

Improving the CAS or graphic capabilities is important to me. This is one area where having Prime-class open hardware would help. DB48X has plotting features today (you can see them in the Demo package). But plotting is nowhere as fast as on a Prime. At some point, I will need to implement hardware-accelerated FP numbers to see if I can get things a bit faster that way. Also interesting would be to implement hardware-accelerated FP in the simulator. That would certainly beat the Prime.

Quote:To make the "Prime II" tool of thought truly usable in education at high schools but also at engineering universities and professionally, it has to be extendible with math and science libraries, with largest broadest spread that has the biggest market size (all students + all professionals), flourishing development and a future. Python is where the puck is going (or already is). We should also allow to leverage (which Python can do) the libraries written in R - that would open up an entire new world for a handheld device.

Where I differ with you is that I don't think you can target both educational and engineering markets, for the reasons I outlined above. So in the end, any hand-held device with a mass-market educational appeal will have to put restritions that will frustrate engineers.

Quote:The point is that a handheld platform that can leverage all the massive development that takes place to day in Python and R etc. would be truly next gen. This would truly amplify a users solution solving capability also at the high end!

Obviously programming is done an a PC/mac and transferred to the handheld device. (all programs are disabled in Exam mode).

I want the best of both worlds maximum capability in a handheld format.

I believe you are describing the iPad or the iPhone. I have one. But I don't like using it for calculations (even though I frequently do). Presently, I have 12 calculator apps installed on it, including the Prime emulator... I mostly use the HP48 emulator. But still, like on the Mac, click click click is not the same as a real HP keyboard.

(07-12-2020 07:23 PM)John Keith Wrote: This is one point I disagree with. Having to do programming on a PC defeats the point of a programmable calculator. Certainly writing large complex programs is best done on a PC but to me programming is an important part of interactive problem solving.

If I had to choose only one language I would choose Python because of its wide appeal and large base of users and freely available code. However, I still think of RPL as unbeatable for quick'n'dirty problem solving and I can't see a reason not to have both.

The reason not to have both at least on SwissMicros hardware is that one barely fits.

Clearly, a Prime version of DB48X would probably have a Python object type ;-)

That being said, Python does not work at all as a calculator user interface, including for immediate calculations.

(07-12-2020 09:47 PM)Anders Wrote: I understand that I am being sacrilegious to many here when I write this, but
RPL and other other stack based languages is not the future of programming it belong to the past - a very interesting past and that has it charm from many perspectives and so on - but nonetheless the past. We should leave it there on our old loved calculators and not continue to introduce it on a next gen machine.

As an interactive language on a hand-held device, it is close to ideal though. The HP implementation can be improved on, and DB48X improves on HP's implementation in many ways. But RPL remains much better than Python as a basic calculator UI, and better than RPN as expressiveness. This is particularly true as far as CAS-style operations are concerned.

Quote:Just for reference, I wrote an full screen editor in Forth in 1984 (I swear, I do not want inflict that pain on anyone ever!), massive volumes of programs on HP-42S 28S 48S etc. over the years. It is not a good programming model for any complexity beyond trivial and shall not be used in a future machine point, period. It is a second generation language model form the past that current generation students do not care much about - except a perhaps a Computer Science major.

Yet it is fully homoiconic, which makes it inherently more powerful than Python.

It also has a much better support for mathematical data types, and treats them very uniformly.

BTW, one area where I plan to really extend RPL is support for user-defined types. But that's for another post.

Quote:Yes, quick and dirty programming would be the only potential reason for RPL, but you might as well use Python for that too (yes it might take a bit longer to code, but a good contextual and lexical sensitive editor could fix much of that).

Well, I make a different choice: I don't want it to take longer to code while I'm in the field. My problem at that moment is not that my code can be read later, is that I need to code something to address a problem where there is no built-in solution in the device.

Quote:That way, next gen students can actually read and understand our code - even quick and dirty one.

RPL is never easy to read. That much is true.

Quote:An owner of: HP-12c, HP-15c, HP-16c, 3 HP-28S, 2 HP-42S, 3 various HP-48xx, 1 HP-50g, 1 HP-35S, HP-32S, 3 HP Primes all flavors, all the Swiss micros flavors of the same DM-xx. Let see Casio FX-602p, FX-603p and a few more I do not even remember off the top of my head...

So you have a DM42? Then you can try DB48X right away and report bugs (there are many, it's still only 0.4.7 at the moment).

(07-16-2020 08:12 PM)John Keith Wrote: Actually it may be a better thing- NewRPL is native code and much faster than the Saturn emulator the HP 50g runs on. It should really fly on the Prime which has a higher clock speed and uses a newer ARM version.

On similar hardware, NewRPL and DB48X should be in the same order of magnitude. DB48X trades some performance for memory usage, so I expect it to be a bit slower, but also to garbage-collect less often. It does fly on a MacBook Pro with a Apple M1 processor though (NQueens is less than 20ms).

(04-28-2021 02:32 PM)obelix Wrote: Perhaps the best option would be:

a) Open source the firmware
b) Create a new calculator, just cosmetically different from the HP Prime, without exam mode and without limitations to install custom firmware, just like the old 50g.

From this point the community could do anything. Perhaps integrate xcas in NewRPL just like Erable was integrated in old RPL?

I'd love both a and b. But I think the market is too small for this to ever happen. The best we have at the moment in terms of HP-style open platform is SwissMicros (there are other open calculators, I like them less overall).

(05-03-2021 02:53 AM)toml_12953 Wrote: I know I'm alone in this but I'd like to see a machine with either: CAS fully integrated or no CAS at all. I'd like no dedicated variables.

Check and check.

Quote:My main use for any machine is to be able to program it and having to know which variables are used by CAS and which are used in Home isn't helpful. So I'd like NO predefined variables. Let the user define the ones (s)he wants.

Check.

Quote:I'd also like a full version of either C, Pascal, Python, JavaScript or other standard language similar to those.

C++ SDK would be my answer.

Quote: I'd also like to be able to use USB peripherals such as a keyboard, mouse, printer, game controller, SSD, etc. Having HDMI or at least VGA video output would be good.

SwissMicros DM32 has USB-C, but I doubt it can do any of these. Storage might be within reach, and only with very simple file formats (think FAT but no ExFAT).

(01-23-2022 07:56 PM)celltx Wrote: I'd like to see a better number formatting:

- in normal mode, I'm tired counting zeros in numbers like 0.000002. It would be great to have something like Norm1 in Casio calculators, where numbers smaller than 0.01 are displayed with exponent.
- Larger numbers could have an option to be displayed with exponent too: either 10,000 or 1e4, by user choice

DB48X has a StandardExponent setting precisely for that purpose. Set it to 3, and anything below 1E-3 or above 1E3 switches to scientific mode.

There is also a "SIG" mode inspired from WP34S / C47, which shows "significant digits". Mimicking the HP48 12-digit STD mode on a 34-digit DB48X is achieved by using 12 SIG.

Recently, I added another refinement, which is MinimumSignificantDigits. It means that 0.0055 in FIX 2 does not necessarily display as 0.01. You can instead choose how many signficant digits you want in FIX mode.

Quote:- in scientific format, please remove trailing zeros in mantissa: Let 2.1e7 look like this, rather than a long 2.100000e7

You can achieve that by setting the StandardExponent to 0.

Quote:- Add engineering symbols option, so that answer 2e-12 could be shown as 2p, or 2e6 as 2M

Planned, will be part of units support. As indicateda above, for 2e-12, I would expect EEX to cycle between 2e-12 and 2_p, with possibly a display of the next level, i.e. in that case 0.0002_n and 2000_f. The underscore is the sign used in RPL, but on display, it will be a non-breaking thin space.

Quote:So far, HP number formatting is weaker than both TI's and Casio's and this leaves bad impression in everyday use. I'd guess, this gap is easy to close.

In addition to the above, DB48X lets you select between 1'000 1,000 1.000 1_000 1 000 (a "space medium math" unicode character that displays as a thin space on screen - Did I mention DB48X is 100% Unicode and utf8?). It lets you select a comma or dot as decimal separator. You can adjust spacing independently for based numbers, so you can have 1'000 and #ABCD'EFGH. There is a distinct setting for whole and fractional part, e.g. 10_000,12345_65789. And numbers are adjusted dynamically in the editor as you type them. Which was a bit hellish to code, to be honest ;-)

Also, the exponent part in scientific mode can show as 'E' or with a fancy x10 character and a superscript exponent. Similarly, based numbers show the base as a subscript on the stack display.

(01-26-2022 02:05 PM)Stefan Falk Wrote: 1. *Simple* Keyboard-based programming with only the built-in keyboard and no PC around!

I hear you. I hope that this is partly achieved with DB48X today, as long as you accept RPL as your programming model.

If you prefer RPN-style keystroke programming, as mentioned earlier, I would like to improve that with a step-oriented editor, but before that, by adding RPL commands that mimic common RPN construct. LastX is the first one.

Quote:This is doable on my 41C, and I found what Microsoft Research did with the first versions of TouchDevelop a *huge* improvement!

There is a world of difference between the two ;-) DB48X is defintely is closer to the 41C than TouchDevelop, but much more powerful.

Quote:Every bit of brainstorming to this field would be highly appreciated. So: Let us do simple programming with *much* less keystrokes than now using HPPL - directly on the device, while sitting in the train!

Exactly. If you have an opportunity to try DB48X, all feedback will lead to improvements.

Quote:2. While I understand that the CAS and Home separation is due to using the open source CAS software, I guess most of us feel that this is somewhat unnatural. Having a merged experience would be very fine and save us from things like getting a CAS function graphed and having to manually replace x with X, or having to store the function into a variable before plotting. A well-integrated world of both would highly polish the product imho.

Check.

Quote:5. RPN as a more prominent feature. Hard to do with CAS, I know, but just wanted to mention it. As just a calculator, nothing beats RPN.

I think RPL does. But you tell me.

Quote:6. I/O. Lets have the Prime control experiments and machines, take measurements from sensors, record them, plot them, and analyze them up to matching to functions and having full error propagation calculation, and easily transfer the results to the PC to write a document about the experiment. The new USB and I²C features look very promising, and I still have to try them.

That's the kind of stuff I'd like to do with the USB on the DM32 and DM42. It's not there yet, and right now, the DMCP platform provided by SwissMicros does not make the hardware accessible at a low-enough level.

Things would be different on another platform, like an open Prime.

(01-31-2022 08:19 PM)robve Wrote: Lua 5.3
Perhaps it is a long shot to ask for Lua, but Lua is small yet versatile and would make an excellent addition to HP Prime.

Lua could be a good choice. My own XL programming language could be another alternative (but it's not standard and does not have a real ecosystem, though its 3D or graphics support is stellar)

(01-31-2022 08:51 PM)KlaasKuperus Wrote: I love all your suggestions and ideas! We are always looking into making our products better and I will certainly add these points to the list. I cannot promise anything, but there's a lot I would love to see in real life!

If HP / Moravia is interested in providing a platform capable of running DB48X, I'm all ears.

(02-02-2022 09:15 PM)ndzied1 Wrote: I think it's been mentioned before but changing the Units functions to work like the 50g would be wonderful. I am especially talking about the way you can quickly convert units using the left shift key in conjunction with the soft menu.

For instance you need to convert 12in^3 to cm^3. With the Units/Volume menu up, you can type 12 (softkey in^3) then left shift (softkey cm^3). You can left shift / soft menu to convert to any compatible units. So fast and intuitive.

That's next on my to-do list.

(02-05-2022 10:09 AM)Tonig00 Wrote: Sure its been said but it would be interesting to have the precision of the dm42 from swiss micro:
Floating point standard IEEE 754-2008, 128-bit floating point precision implementation.

Done.

Quote:Additionally, related to the manual, it would be very interesting to collect many application examples given in this forum.
There are brilliant ones which could expand the actual manual.

I really would like this to happen on the DM48X documentation.

(04-25-2022 05:59 PM)Jim Horn Wrote: What would *I* like to see? A shipping date!

Shipping today in version 0.4.7 on DM32 and DM42 (shipping today from SwissMicros).

Estimated date for a 1.0: Around Christmas time, but no promise.

No idea if SwissMicros will ever ship a machine with DB48X preinstalled and a suitable keyboard layout.. You can get overlays for the DM32 or DM42 from @jeff72.

(06-02-2023 10:37 PM)Insoft Wrote: If HP did decide to get back into calculator market with a new HP Prime it would have to be a Retina display, Type-C support third party native app development using C/C++ retain PPL and allow PPL to interact with C/C++ written functions

The SwissMicros screens are quite good except in low-light conditions.
Third-party native app development: Check (and the planned library SDK would complete that).

Quote:The keyboard needs to feel like CASIO keyboard and Bluetooth for external mouse and keyboard input

One thing I certainly did not expect in a discussion about HP calculators is to get the CASIO keyboard feel! If I had to give a keyboard feel notation out of 10, HP48 would be 10, HP15C would be 9.8, HP Prime would be 9.5, DM42 would be 8.5, most TI calculators betwen 3 and 8 depending on the generation, and CASIO would consistently be between 3 and 4. The iPhone would be at 1. All a matter of taste, of course.

(06-03-2023 12:20 AM)Steve Simpkin Wrote: * Supporting third party native app development using C/C++ would be a large, expensive effort that would not make this calculator more sellable in the educational marketplace. It could also introduce security risks which could make this model unsuitable for the educational marketplace.

None of these objections applies to an open-source SDK.

Quote:* Making the keys feel more like Casio keys would eliminate one of the key elements that makes HP calculators more attractive to buyers. HP put a lot of effort into making the keys work and feel like they do. If you want the Casio keyboard feel, just buy a Casio or a TI or a Sharp.

I have to agree.

(06-30-2023 01:59 AM)dkostan Wrote: A Row of 6 Function/HW menu keys below the screen

Yes. One of my primary gripes with the Prime too.

Quote:Maybe a slightly better display resolution. On the fence since I think 7 (or more) color e-ink
display might be better for a calculator for power and persistent reasons.

I wonder if SwissMicros is considering color e-Ink displays. The ones I found were relatively expensive relative to monochrome. Does anyone have a link?

Quote:Normally I use a calculator in well lit areas (I think most do, right?) so backlight seems like a waste of juice and its annoying when it dims (on a calculator) to save power. E-ink seems better here to me.

Normally, yes, but the glass in front of the DM42 e-ink display can make it hard to read in "evening" conditions. I often have to reorient the calculator to avoid direct light sources.

The DM42 is rarely more readable than the Prime, except in really bright conditions, but the Prime is clearly ahead as soon as I have to switch the light on in my office. The DM42 is still always way ahead of the HP48, irrespective of conditions, and that alone makes DM42+DB48X a better choice than HP48 for me.

Quote:Add back in full engineering RPN support. That would include support to run RPL code.

Check.

Quote:Maybe built in emulation for the older platforms with support by adding a key mapping compatibility setting/file that could solve most issues due to the keys being different.
I use base48 and its great but I would prefer built in base number support similar to 48-50g (just add an option/setting for this style)

DB48X already has support for:

- Based number in any base, e.g. 3#212121110 is 16#433B, and 'Base' command to select arbitrary display base.

- Separators and fancy rendering of based numbers, e.g. something that shows as #433B'EF0A₁₆

- Word size higher than 64. For example 512 STWS and then #0 NOT gives you a 512-bit number.

- A large number of binary operations (shifts are still missing)

There is configurable support for based numbers with fixed base, so that you stack can display both a binary and an hexadecimal number at the same time. That is disabled at the moment, but I intend to re-enable it shortly for DB50X.

Quote:Seems like support for many interpreted and compiled languages would be "easy" these days. Many like python. I prefer C and hp ppl, but really seems like all of these could be supported with loadable packages & libs. Storage and cpu is not the limiter these days. Good community support could make this happen if the SDK was opened up.

It's not that easy on really small, power-efficient systems. But the SDK will definitely be open like the rest of the firmware.

deSitter · 12-24-2023, 06:18 AM

(04-06-2020 02:42 PM)Dands Wrote: IF HP was to release a totally new model, what would you like to see?

I'd love to see a completely redesigned system, new keyboard layout, better connectivity, bigger and better screen, new apps and most importantly: better phasor notation (polar) capabilities for power engineers.

Let's discuss and maybe give them some ideas!

Math, math, and more math. Abramowicz and Stegun, all of it. An incisive approach to complex functions. Sophisticated linear algebra. Sophisticated algebra period. Lie groups. Application specific software like celestial mechanics. I could go on for a long time. I just now had to wrestle with the gamma function of a complex argument. That's just lame.

A Prime for engineers and scientists.

Fun thread, have only read some of it but that's what I have always wanted.

Anyway there is no excuse for not having on hand a vast repository of all sorts of things, from simple formulas to asymptotic expansions. All that can be in firmware.

-drl

lvt · 12-25-2023, 01:29 AM

It could be nice if I can watch YouTube on the future HP Prime.

The screen size is not very suitable for browsing websites, but I think it's perfect for watching YouTube at the lowest resolution.

BruceH · 12-25-2023, 12:29 PM

(12-25-2023 01:29 AM)lvt Wrote: It could be nice if I can watch YouTube on the future HP Prime.

The screen size is not very suitable for browsing websites, but I think it's perfect for watching YouTube at the lowest resolution.

That's not a very good idea because then someone would post a Youtube video of a Prime being used to watch a Youtube video of someone using a Prime to watch a Youtube video of someone using a Prime to watch a Youtube video and then the Universe would collapse in on itself.

**rprosperi** · 12-25-2023, 02:26 PM

(12-25-2023 12:29 PM)BruceH Wrote:
(12-25-2023 01:29 AM)lvt Wrote: It could be nice if I can watch YouTube on the future HP Prime.

The screen size is not very suitable for browsing websites, but I think it's perfect for watching YouTube at the lowest resolution.

That's not a very good idea because then someone would post a Youtube video of a Prime being used to watch a Youtube video of someone using a Prime to watch a Youtube video of someone using a Prime to watch a Youtube video and then the Universe would collapse in on itself.

True, but it would be cool to watch that happen... I dunno, maybe I watch too much YouTube... Smile