WP 34S and 31S bugs and fixes

[Bit]

(01-17-2015 10:43 AM)walter b Wrote:  While DEG and GRAD may make some sense, RAD and H.MS don't. And conversions don't either. So, for sake of coherence, DEG, RAD, GRAD, H.MS, and the menu CONV should be disabled in integer mode.

Certainly, "advanced statistics" doesn't make sense, so this should be disabled as well (i.e. the entire menus STAT and PROB). Not so sure about summation*. And one could think about [x_bar] which inevitably goes with [s]. You see, statistics isn't black or white but also grey.

d:-)

(Luckily, my reasoning matches the manual so far AFAICS - I crosschecked after writing the text above.
* I found we also disabled summation - for sake of completeness, I'd guess.)

I've committed a change to disable DEG, RAD and GRAD in integer mode. The rest appear to be disabled already.

Edit: The conversion and statistics catalogs used to be accessible with [h] held down, but my previous patch fixed that.

[Bit]

(01-08-2015 07:09 AM)walter b Wrote:  

(01-08-2015 05:28 AM)Bit Wrote:  

1. Incomplete or invalid fractions cause delayed error messages ...
2. CLx produces domain error if the command line contains a bad fraction ...
3. EEX not allowed in fractions mode even if no fraction was entered ...
   

...
3. is done on purpose. Fractions on the WP 34S have a very limited range. Well, it's larger than on the HP-33Sii but anyway EEX doesn't make real sense here. So please leave that as it is.
...

Walter, I've been thinking about this, and I'd like to point out a real life scenario in which it matters:

It happened several times that the calculator was in fraction mode because of previous calculations and when I tried to enter a number with an exponent, I was surprised that I couldn't. I was forced to take steps that were unnecessary in my workflow as it made no difference to me at that point whether or not numbers were displayed as fractions. I had to exit fraction mode and either retype the number or multiply it by the exponent. If the calculator simply allowed EEX while in fraction mode, the user would have the freedom to switch back to decimal mode at any point during calculations (e.g. after a result is displayed), not only at the beginning.

On the other hand, I cannot think of an example when forbidding EEX would help the user avoid some confusing situation that they unintentionally got themselves into. I'm not sure how the limited range of fractions is relevant here since very large numbers are already allowed: you can enter 1e11 as 100000000000.

Fractions mode in the WP 34S doesn't affect how calculations are carried out or which operations are allowed, it's just a display mode: another way to look at the content of the registers. As far as I can tell, disallowing EEX is the only exception.

Could you please consider the above?

[walter b]

(01-17-2015 04:50 PM)Bit Wrote:  If the calculator simply allowed EEX while in fraction mode, the user would have the freedom to switch back to decimal mode at any point during calculations (e.g. after a result is displayed), not only at the beginning.

On the other hand, I cannot think of an example when forbidding EEX would help the user avoid some confusing situation that they unintentionally got themselves into. I'm not sure how the limited range of fractions is relevant here since very large numbers are already allowed: you can enter 1e11 as 100000000000.

Hmmh. Fraction mode is designed for calculating with fractions (surprise!). Very big (>1e5) as well as very small (<1e-4) numbers are out of scope. Cf. e.g. p. 54 of 149 of the WP 31S manual. Now, why do you want to enter an exponent while calculating with fractions?? If you want to enter a number >1e5 I assume you know this immediately before putting it in* - so you can press [H.d] before. What's wrong with that?

d:-?

* If you don't know that may be another problem though that can't be solved by a calc.

[Bit]

Pauli discovered a bug caused by my "Fewer screen updates on data entry" commit that affected the console build. I've just applied a fix that disables the WasDataEntry variable only in console builds.

[Bit]

(01-17-2015 09:53 PM)walter b Wrote:  Hmmh. Fraction mode is designed for calculating with fractions (surprise!). Very big (>1e5) as well as very small (<1e-4) numbers are out of scope. Cf. e.g. p. 54 of 149 of the WP 31S manual. Now, why do you want to enter an exponent while calculating with fractions?? If you want to enter a number >1e5 I assume you know this immediately before putting it in* - so you can press [H.d] before. What's wrong with that?

There are two kinds of problems:

1. It's inefficient for some workflows. If you'd like to mix fractions and exponents, either because you need very small/big numbers or because some numbers are simply more convenient to enter in scientific notation, you need extra key presses for [H.d]. Some of the numbers you enter may be out of scope for fractions but the end result of such mixed calculations could be in scope, which is why you may want to stay in fraction mode.
   
   It can also be inefficient if you need to alternate between calculations with fractions and exponents.
   
   
2. It's less forgiving of mistakes. If you forget to press [H.d] before you start typing a number that needs an exponent, you'll have to either abandon the number and retype it, wasting effort, or you can enter it without an exponent and then multiply it with the exponent, again wasting some effort and also losing the top level of the stack.
   

If the above costs were offset by some gain, this would be a trade-off worth considering. However, there's no gain: If your workflow doesn't involve mixing fractions and exponents, you simply don't press the [EEX] key. If you press it accidentally, the mistake isn't costly, because [<-] clears the exponent without affecting the number you entered.

There's another small cost, although it's minor compared to the above:
3. A few extra bytes in the firmware for the check that disables [EEX].

Ultimately, not allowing [EEX] hinders some workflows and users but benefits absolutely nobody.

[walter b]

(01-18-2015 03:42 AM)Bit Wrote:  It's inefficient for some workflows.

(Emphasis added.)

Please tell me some real world examples at least.

d:-)

[pascal_meheut]

Sorry to interrupt, just to say that I have updated the emulators to incorporate the last bug fixes.
I'll update the iOS one later because I'm looking at a "user color change" possible improvement.

[Bit]

(01-18-2015 08:00 AM)walter b Wrote:  

(01-18-2015 03:42 AM)Bit Wrote:  It's inefficient for some workflows.

(Emphasis added.)

Please tell me some real world examples at least.

d:-)

Unfortunately I didn't keep notes but the last time I ran into this, I think it was simply because some externally provided input data was given as fractions. I'd type the fractions, the calculator would automatically switch to fraction mode, and then I had to switch back to decimal mode in order to be able to enter an exponent a little later. Next time I entered a fraction, I had to switch back again. I don't remember precisely but it could've been measurements like 1/64 inch mixed with metric data that I normally convert everything into.

I also specifically remember that I had run into point 2 multiple times: I had to backtrack because I forgot to press [H.d] in advance.

I don't think the specific examples are important. The point I'm trying to make is in the last sentence of my previous post. I doubt anyone can come up with an example where disabling [EEX] is actually helpful. No one is going to say "I hate that I'm able to press [EEX] in fraction mode, it impedes my calculations, I wish the calculator prevented me from doing it". :-) Restricting [EEX] aids nobody, but in some cases it's an inconvenience.

(Edit: Fixed typo.)

[Marcus von Cube]

(01-18-2015 05:32 PM)Bit Wrote:  Restricting [EEX] aids nobody, but in some cases it's inconvenience.

I'd go a step farther. If entering a fraction automatically switches to fraction mode than it would be consistent behavior if EEX switched back to decimal mode.

[Bit]

(01-18-2015 06:13 PM)Marcus von Cube Wrote:  

(01-18-2015 05:32 PM)Bit Wrote:  Restricting [EEX] aids nobody, but in some cases it's inconvenience.

I'd go a step farther. If entering a fraction automatically switches to fraction mode than it would be consistent behavior if EEX switched back to decimal mode.

That'd be extremely easy to implement (and as far as I can see, it wouldn't contradict the existing documentation). Wouldn't it make sense if numbers with one decimal mark (e.g. 1.25) also switched back to decimal mode?

(I'm just asking a question as I don't currently have a strong opinion on the topic of switching back to decimal mode. It's not something that repeatedly frustrated me like the blocked EEX key.)

[Nigel (UK)]

(01-18-2015 06:47 PM)Bit Wrote:  

(01-18-2015 06:13 PM)Marcus von Cube Wrote:  I'd go a step farther. If entering a fraction automatically switches to fraction mode than it would be consistent behavior if EEX switched back to decimal mode.

That'd be extremely easy to implement (and as far as I can see, it wouldn't contradict the existing documentation). Wouldn't it make sense if numbers with one decimal mark (e.g. 1.25) also switched back to decimal mode?

(I'm just asking a question as I don't currently have a strong opinion on the topic of switching back to decimal mode. It's not something that repeatedly frustrated me like the blocked EEX key.)

From my perspective, if I'm mixing fractions and decimals (e.g., when finding the volume of a sphere) I want the decimals to win. This calculation is a situation in which having entered 4..3 (or .4.3 if you prefer!) I have to change out of fraction mode before entering the radius if it is in standard form (which it often is, for stars or atoms). Others may feel differently about decimals causing a mode change but I can't see any objection to EEX triggering the change. A great idea!

Nigel (UK)

[walter b]

(01-18-2015 06:47 PM)Bit Wrote:  

(01-18-2015 06:13 PM)Marcus von Cube Wrote:  I'd go a step farther. If entering a fraction automatically switches to fraction mode than it would be consistent behavior if EEX switched back to decimal mode.

That'd be extremely easy to implement (and as far as I can see, it wouldn't contradict the existing documentation).

Not really true. Cf. p. 201 of 374 of the manual.

d:-/

[Bit]

(01-18-2015 08:40 PM)walter b Wrote:  

(01-18-2015 06:47 PM)Bit Wrote:  That'd be extremely easy to implement (and as far as I can see, it wouldn't contradict the existing documentation).

Not really true. Cf. p. 201 of 374 of the manual.

d:-/

I suppose you mean the EEX [d & FRC] part. I missed that but in this case I think that the tiny update to the documentation is totally worth it because we'd improve the user interface. Nigel provided another example of why it matters in practice.

[walter b]

(01-18-2015 05:32 PM)Bit Wrote:  ... I think it was simply because some externally provided input data was given as fractions. I'd type the fractions, the calculator would automatically switch to fraction mode, and then I had to switch back to decimal mode in order to be able to enter an exponent a little later. Next time I entered a fraction, I had to switch back again. I don't remember precisely but it could've been measurements like 1/64 inch mixed with metric data that I normally convert everything into.

OK, that's solved easily: Assume you have some calculation like 4 1/64 * 5e-3 + 1 2/3. Then I'd recommend to solve it this way:

64 1/x 4 + 5 EEX 3 +/- * 1 + 2 ENTER 3 / +

No need for fraction mode, no switching between modes (that's a quick and easy solution - in the long range, get rid of measures requiring such fractional values ).

As I wrote before, fraction mode is designed to deal with fractions - i.e. to help students (pupils?) who have to calculate using them. That's one reason IMHO why fractions appeared on HP calculators not earlier than the HP-32SII - they aren't really needed in professional life.

d:-)

[Bit]

(01-18-2015 08:57 PM)walter b Wrote:  OK, that's solved easily: ...

Sure, you can work around everything, you could even solve the same problems on paper. I don't see how providing an inferior workaround is relevant in this discussion. The workaround is inferior because it requires extra mental effort to keep in mind that the calculation should be performed in some other way than what's obvious.

Walter, you've been explaining why you don't think allowing EEX in fraction mode is necessary. Fair enough, you don't need it. But you haven't mentioned any reason at all for why it would be a bad idea. Can you give any such reason?

[walter b]

(01-18-2015 09:12 PM)Bit Wrote:  The workaround is inferior because it requires extra mental effort to keep in mind that the calculation should be performed in some other way than what's obvious.

Look, Bit, we should agree we disagree in that matter. For me, it's no extra mental effort to solve that example the way I suggested - it's the obvious way for me. In fact, I wouldn't even think of using fraction mode for such stuff.

Fraction mode is nice to have for demonstration purposes. And to check the homework of students as mentioned earlier. YMMV (and obviously does).

d:-)

[walter b]

(01-18-2015 07:08 PM)Nigel (UK) Wrote:  From my perspective, if I'm mixing fractions and decimals (e.g., when finding the volume of a sphere) I want the decimals to win. This calculation is a situation in which having entered 4..3 (or .4.3 if you prefer!) I have to change out of fraction mode before entering the radius if it is in standard form (which it often is, for stars or atoms).

Good grief! Didn't they teach you in school that 4/3 equals 4 divided by 3 ?!?

d:-/

[Bit]

(01-18-2015 09:30 PM)walter b Wrote:  

(01-18-2015 09:12 PM)Bit Wrote:  The workaround is inferior because it requires extra mental effort to keep in mind that the calculation should be performed in some other way than what's obvious.

Look, Bit, we should agree we disagree in that matter. For me, it's no extra mental effort to solve that example the way I suggested - it's the obvious way for me. In fact, I wouldn't even think of using fraction mode for such stuff.

Fraction mode is nice to have for demonstration purposes. And to check the homework of students as mentioned earlier. YMMV (and obviously does).

d:-)

You're certainly right that fraction mode is probably not used very often. But I'm still curious if you have an answer to my last question. Why is it a bad idea rather than something that's at worst unnecessary but harmless?

[Bit]

Walter, while checking what the manual says about fraction mode, I noticed that the output of the DECOMP command on the top of page 86 of 374 in the latest printed manual (3.3) is different from what the calculator shows. In the manual it's "x/y >", but in the real device it's "x/y Gt".

I suggest we change the calculator to agree with the manual. The Y register display already uses < and > instead of Lt and Gt because space is tight. This way DECOMP would be consistent with that as well. Please comment.

[Nigel (UK)]

(01-18-2015 09:36 PM)walter b Wrote:  

(01-18-2015 07:08 PM)Nigel (UK) Wrote:  From my perspective, if I'm mixing fractions and decimals (e.g., when finding the volume of a sphere) I want the decimals to win. This calculation is a situation in which having entered 4..3 (or .4.3 if you prefer!) I have to change out of fraction mode before entering the radius if it is in standard form (which it often is, for stars or atoms).

Good grief! Didn't they teach you in school that 4/3 equals 4 divided by 3 ?!?

d

Yes, they did. But given that the WP-34S supports fractions and that "4/3" in the formula for the volume of a sphere is a fraction, why should I not be able to enter it as such if I want to? I understand your point - you would never think of using fraction mode for this purpose. But not every user would think that way. Why not accommodate these fraction-lovers? What would be lost by doing so?

Nigel (UK)