New Acron RPN Calculator for Android

[vanLudwig]

I just made my Acron RPN Calculator available in the Google Play store, and I'd love to get some constructive feedback from RPN enthusiasts. The full version isn't normally free, but I'd be willing to give a promo code for a free full version to the first handful of people who ask. There is also a free version in the Play store named Acron RPN Calculator FREE with a subset of functionality.

This is not just an attempt to get a plug for my product. I am genuinely interested in some feedback. I'm the only person I know who likes RPN.

[rprosperi]

(06-19-2016 11:41 PM)vanLudwig Wrote:  I am genuinely interested in some feedback.

Stand back, and I hope you've got thick skin...

(06-19-2016 11:41 PM)vanLudwig Wrote:  I'm the only person I know who likes RPN.

Boy have you found the right place...

[Nigel (UK)]

I hope that thick skin won't be needed; I like this calculator very much! I splashed out the full 0.79 GBP for the paid version. No special permissions are required for installation.

There's an image in the HP Prime user manual showing an RPN mode display, but with the calculation leading to each stack entry visible in algebraic form at the left of the screen. The Prime doesn't actually do this, but the Acron RPN calculator does. I like this a lot - new RPN users would probably find it helpful too.

Another nice feature is the way in which a small keyboard allows access to all the usual functions. Pressing the "y^x" key brings up a menu including x^2, sqrt(x), 1/x, and y^x; pressing "sin" brings up a menu including sin(x in degrees), inverse sine in degrees of x, the corresponding functions in radians, sinh and inverse sinh. So each operation needs a couple of keypresses but the system works well. I particularly like the absence of degrees or radians mode that this approach allows.

I've only played with it for a few minutes and I have to do some work now, but it's well worth looking at. Only one minor complaint - the keyboard isn't quite as responsive as I would like, but my phone (Samsung S5 galaxy neo) is generally rather slow to respond so this may not be a feature of the program.

Nigel (UK)

[rprosperi]

I agree, this is a very interesting design, rather different from most I've seen. All the green keys bring up menus of (mostly) related functions.

Separate trig functions for degree and radian modes is unique, it will take some time using it to see if this is a positive or negative.

The stack seems to be unlimited (or perhaps just rather high, 10 at least) and there are several functions for juggling the stack like SWAP (2) Roll 3 (up and down) and Roll 4 (up and down).

Entering a calculation whose result can be expressed as a proper fraction is shown that way, so 89 [ENTER] 3 [*] 100 [/] is displayed as 267 / 100 with 2.67 seen in parenthesis).

It seems to have a fairly wide numeric range, appears to be 10^-324 to 10^308.

I have not had a chance to explore precision levels yet, but some odd things happen, e.g. entering 10 E-324[ENTER] yields 9.88131281682493 E-324.

Also, 2 [ENTER] 3 [/] => 6.6666666664833 E-7.

The [<=] key to backspace the current entry is very close to the currently open menu so it's easy to hit a function instead of the backspace, however this is nicely offset by the undo key.

The primary thing I find missing from the feature set is any kind or storage or memory register. Since it's not programmable, not too many are needed, but having at least one would be useful.

An unexpected feature, or perhaps bug, is the status of the stack is not maintained between sessions.

Quite interesting design. I agree it feels somewhat slow, however my phone is also somewhat old so perhaps this is the cause. That said, I do not have the same lag on FREE42 or other calculator Apps.

Users interested in new/different designs should definitely check this out.

[vanLudwig]

(06-20-2016 01:43 PM)rprosperi Wrote:  I have not had a chance to explore precision levels yet, but some odd things happen, e.g. entering 10 E-324[ENTER] yields 9.88131281682493 E-324.

You are running into the limitations of floating point numbers. For 64-bit floating point values, the smallest positive number (referred to as machine epsilon) is 4.94065645841247E-324. The second smallest number would be 2 * epsilon (which is what you were seeing), the third smallest number would be 3 * epsilon. This continues for the first 2^51 numbers; then the binary exponent increases and so does the gap between representable numbers.

(06-20-2016 01:43 PM)rprosperi Wrote:  Also, 2 [ENTER] 3 [/] => 6.6666666664833 E-7.

Can you explain this further? It seems like you were pointing out a rounding error, but 2/3 is 0.6666667, not 6.66667E-7. Either way, I can't replicate the round off error or the decimal being wrong by 7 places.

[rprosperi]

(06-20-2016 07:36 PM)vanLudwig Wrote:  Can you explain this further? It seems like you were pointing out a rounding error, but 2/3 is 0.6666667, not 6.66667E-7. Either way, I can't replicate the round off error or the decimal being wrong by 7 places.

Yes, I can explain (blush). I was in a hurry this morning and botched the notes.

It SHOULD say:

Also, 2 [ENTER] 3 [/] 0.666666 [-] => 6.6666666664833 E-7.

And thanks for the comments on the floating number range, knowing its using 64-bit floating point clarifies some things.

As I become more used to it, I like it better. I am finding the buttons a bit small for my fat fingers, but I doubt I would trade the vertical space needed by larger keys for smaller stack display.

Is the stack depth limited by anything other than available memory? In practice, how many levels have you been able to use safely/quickly?

Thanks for your quick comments and assistance.

[vanLudwig]

Ah, I see what you were trying to do. So you get about fifteen consecutive 6s before it starts to stray. I think that's pretty consistent with the capabilities of 64 bit floating point.

FYI - if you select the parenthetical view and press enter, it will push the floating point value to the console with all sig-figs. That's a lot easier than subtracting off the digits you can see.

There isn't a fixed cap on the stack depth - it will keep going until you run out of memory. The complexity of each line on the stack will have as much impact on memory as the number of lines on the stack. I've had over 100 lines on my Nexus 5X. I think you will get bored of typing before you hit the limit.

[Maximilian Hohmann]

Hello!

One bug report: My Andoid phone (Samsung Galaxy Grand Prime) is set up for European/German number and time formats. I guess this is the reason why this calculator seems to be unable to generate a decimal point on my phone. The "." is not recognised as a decimal sepator and I can only get whole numbers.

Otherwise the concept is interesting like the others already said. On my phone there is a very pronunciated latency between keystrokes and display, together with a lack of tactile feedback I find it difficult to enter more than a few digits (*). And, as already written, I would wish to have a storage register and a "constant memory" function on a useful device.

Regards
Max

(*) You might want to have a look at "RPNplus" (http://www.hpmuseum.org/forum/thread-6271.html) to see what zero latency and tactile feedback look like on an Android phone.

[vanLudwig]

I'll do something about the German decimal point in the next update. I'm not promising that it will display a comma decimal, but it will at least let you correctly enter numbers with a period decimal.

I'll see what I can do about the responsiveness of buttons too. It isn't slow at all on my Nexus 5X. It is a little sluggish on my 2012 Nexus 7, but I thought the performance was acceptable for a 4 year old device.

There is tactile feedback on my Nexus 5X and a Galaxy S6 I had access to for development. I noticed that it's not there on the Nexus 7, so I thought it was a Kitkat vs Lollipop/Marshmallow problem. But today I tried a coworker's Kitkat phone and it has tactile feedback, so at the moment, I'm at a loss as to which devices it will work on. I'm going to look through the API to see if there's different function that doesn't have such inconsistent results.

Look for an update for the numeric locale and button performance within the next week. I'm also looking into adding memory register(s) and long-pressing C to clear the stack, but these will probably take longer.

[rprosperi]

(06-21-2016 02:36 AM)vanLudwig Wrote:  FYI - if you select the parenthetical view and press enter, it will push the floating point value to the console with all sig-figs. That's a lot easier than subtracting off the digits you can see.

Thx, I had not discovered that feature yet.

However if I do that, it displays: 0.666666666666667, so not actually revealing the full accuracy used internally, which is the point of doing what I did (a stupidly simple but effective trick I learned from JKH).

(06-21-2016 02:36 AM)vanLudwig Wrote:  There isn't a fixed cap on the stack depth - it will keep going until you run out of memory. The complexity of each line on the stack will have as much impact on memory as the number of lines on the stack. I've had over 100 lines on my Nexus 5X. I think you will get bored of typing before you hit the limit.

Great news, thanks for clarifying.

From reading other posts, I see more enhancements coming, thanks for looking into those issues, but what about retaining the stack across sessions? If this were a simple four-banger, there's probably little need to retain history, but a lot of effort can go into assembling a stack full of meaningful numbers, it's a shame to lose that when quitting the app.

FYI My Motorola phone is Android 4.4.2 and I DO get haptic feedback.

[vanLudwig]

Okay, I'll add persisting the stack to the feature request list. Right now, I kinda like that it doesn't persist, because it makes it easier to clear the stack. But once you can long-press C, persisting will be a good improvement.

[Nigel (UK)]

(06-22-2016 02:30 AM)vanLudwig Wrote:  Okay, I'll add persisting the stack to the feature request list. Right now, I kinda like that it doesn't persist, because it makes it easier to clear the stack. But once you can long-press C, persisting will be a good improvement.

I second the request for the stack to persist.

Also, does anyone else feel that the "0" and "." keys are the wrong way around for a calculator?

Nigel (UK)

[Werner]

Machine epsilon is the smallest number x for which 1-x < 1, or 2^-53 (1.1e-16) in this case.

Cheers, Werner

[vanLudwig]

(06-22-2016 08:33 AM)Nigel (UK) Wrote:  Also, does anyone else feel that the "0" and "." keys are the wrong way around for a calculator?

Wow, I thought you were nuts on this, so I googled pictures of physical calculators. You're 100% right, I can't find any with the zero exclusively under the two, it is always under the one or double-wide under the one and two. I'll change it.

[Nigel (UK)]

(06-22-2016 02:49 PM)vanLudwig Wrote:  

(06-22-2016 08:33 AM)Nigel (UK) Wrote:  Also, does anyone else feel that the "0" and "." keys are the wrong way around for a calculator?

Wow, I thought you were nuts on this, so I googled pictures of physical calculators. You're 100% right, I can't find any with the zero exclusively under the two, it is always under the one or double-wide under the one and two. I'll change it.

Much appreciated! Thank you. I'm surprised that no-one else commented; you should see some of the endless discussions regarding keyboard layout on some other threads...

Nigel (UK)

[vanLudwig]

I just pushed a new beta build to the Play store. You can try it using the following links:

Full Version:
https://play.google.com/apps/testing/com...calculator

Free Version:
https://play.google.com/apps/testing/com...lator.free

If no one finds any new bugs in the next day or so, I'll move the beta to a full release.

Addressed issues:
- Performance is significantly improved, especially on Android 4.x devices. I accomplished this be only doing partial redraws until the device has sat idle for 2.5 seconds. So, be on the lookout for drawing glitches that rectify themselves after a short wait.

- Added support for numeric locales that don't use a period as a decimal. This should draw using your locale's decimal, including the label on the decimal button.

- Swapped the zero and decimal button locations.

- Fixed a scaling issue when switching between bases.

[Nigel (UK)]

It seems fine to me. The keyboard is genuinely more responsive on both my phone and tablet (running Android 5.1.1 in each case).

One possible "bug": after a series of calculations giving the answer "11." I calculated its factorial. The result was "11." still. What had happened is that the "11." was really "10.99999999999" rounded for display, and calculating the factorial of a number with a decimal part returns the argument unchanged with no error message. I'd prefer an error message, or (better) an implementation of the factorial for non-integer arguments.

Let me repeat what others have said: this is an excellent implementation of RPN. The algebraic expression next to each number in the stack makes everything so much clearer. The "undo" feature unwraps each expression one step at a time: fantastic! Once stack persistence is implemented it will be close to perfect.

A suggestion - currently, the key to enter an exponent is in one of the menus. Just one more row of keys - perhaps as an option - would still leave plenty of screen space on many modern phones and allow exponent entry, square, square root, 1/x and y^x to be one-touch entries. I'm a Physics teacher so I enter exponents a lot! Others may feel differently; I quite understand.

Nigel (UK)

[vanLudwig]

Acron RPN takes more care than most calculators in distinguishing between floating point and "perfect" mathematical answers. Floating point answers are always displayed with a decimal, even if it is just "11."; perfect answers never have a decimal. Acron RPN will only allow you to do a factorial on a perfect integer. You can use round, int, or iPart to turn a floating point back into a integer. The PC version will beep to tell you that you are trying to perform an operation on an incompatible type, but I thought that was annoying on a phone. I guess I should probably find some other way to notify you.

When you say exponent, do you mean y^x, or EE? If you mean y^x, I would think this calculator would be better than most, because once you've displayed the y^x menu, all five power and root functions are available in a single press. Most calculators you would need to use a 2nd button to access some of those functions. If you use EE a lot, I could see how switching between the y^x and PI menus might use more button presses than using a 2nd button. I've been considering allowing more than one concurrent toolbar. I think that would probably solve your problem.

[Nigel (UK)]

(06-28-2016 02:58 PM)vanLudwig Wrote:  Acron RPN takes more care than most calculators in distinguishing between floating point and "perfect" mathematical answers. Floating point answers are always displayed with a decimal, even if it is just "11."; perfect answers never have a decimal. Acron RPN will only allow you to do a factorial on a perfect integer. You can use round, int, or iPart to turn a floating point back into a integer. The PC version will beep to tell you that you are trying to perform an operation on an incompatible type, but I thought that was annoying on a phone. I guess I should probably find some other way to notify you.

If you don't want to allow factorials of non-integers, you could return NaN as you do with square roots of negative numbers.

Quote:When you say exponent, do you mean y^x, or EE? If you mean y^x, I would think this calculator would be better than most, because once you've displayed the y^x menu, all five power and root functions are available in a single press. Most calculators you would need to use a 2nd button to access some of those functions. If you use EE a lot, I could see how switching between the y^x and PI menus might use more button presses than using a 2nd button. I've been considering allowing more than one concurrent toolbar. I think that would probably solve your problem.

It's EE that I find myself using all the time, probably more often than (-). Allowing two concurrent toolbars would solve this. With this one exception I do appreciate the efficiency of the menu system on this calculator. You might also consider allowing a long-press on the decimal point, or two consecutive decimal points, to enter EE. - e.g., pressing 6.02..23 to enter 6.02*10^{23}.

Nigel (UK)

[rprosperi]

Just got to try the new version today; a definite improvement in performance, particularly during numeric entry.

Though I admit I barely noticed the "wrong" key layout for the Zero and Decimal point, this small change truly makes it feel more natural; an interesting effect from this simple improvement.

I agree that requiring a menu to access EE is the most annoying aspect of data entry, accessing functions by topical menus is naturally slower as you have to think about the next functions to access, whereas the exponent is actually part of the argument.

Long-press or double-press on decimal point may work, it would probably require test-driving to see if it is natural feeling, though I think the better solution would be to have multiple menus; perhaps one is sticky and the other comes and goes like the current implementation.

That said, I think simply swapping Factorial and EE would produce the most bang for just a little work. We all do different things with these calcs. of course, but I would think that EE is used far more often than factorial in day-to-day scientific calculations.

Thanks for the improvements and continued refinement.