What would you like to see in a future HP Prime II? (HP Prime², HP Prime 2X)
|
10-18-2023, 09:07 PM
(This post was last modified: 10-18-2023 10:51 PM by c3d.)
Post: #155
|
|||
|
|||
RE: What would you like to see in a future HP Prime II? (HP Prime², HP Prime 2X)
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. 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. 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!) 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. 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) 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. 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. 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. 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 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, 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: 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). 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 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 [...] 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. 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. 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:
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:
and then '1/X' or 'Det', you get Code:
and Code:
The approach taken also ensures that matrix operations and even some numerical operations will stay with fractions. For example, inverting Code:
will give you Code:
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 ...) |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 39 Guest(s)