WP 34S and 31S bugs and fixes

[walter b]

I didn't say it's a bad idea. But a good tool is one containing what's necessary (in a nice package) and nothing else. I don't see a need for EEX in fraction mode, also I don't see a benefit of EEX there - what you (want to) do with fraction mode is close to abuse IMHO.

If I had foreseen this discussion, I'd probably voted against fraction mode at all. Too late

d:-I

[Marcus von Cube]

(01-18-2015 09:59 PM)walter b Wrote:  I don't see a need for EEX in fraction mode

That's what made me suggest to abandon fraction mode if the user presses EEX.

[Nigel (UK)]

(01-18-2015 09:59 PM)walter b Wrote:  I didn't say it's a bad idea. But a good tool is one containing what's necessary (in a nice package) and nothing else. I don't see a need for EEX in fraction mode, also I don't see a benefit of EEX there - what you (want to) do with fraction mode is close to abuse IMHO.

If I had foreseen this discussion, I'd probably voted against fraction mode at all. Too late

d:-I

I'm sorry. I do sympathise: my students at school pretty much all use the Casio FX-83/5 series of calculators, set to Math input/output display format. The division key doesn't get used: they use fractions for all division calculations, being as happy to type in 1e-10 for a numerator and 3e8 as a denominator as they are to type in 4/3. (In fact, I think that a good number of them do not know that 4/3 means 4 divided by 3.) I guess that I feel the same way about this as you do about the proposed (mis-)use of the WP-34S fraction mode. However ...

I understand that any change to the user interface of the WP-34S is more likely to be harmful than neutral or beneficial. But I think that letting EEX terminate fraction mode is a rare exception to this rule. When I look at (4/3) pi r^3 I see the 4/3 as a fraction, like the (1/2) in the expression for kinetic energy. I can of course just do the divisions, but I do not see it as an abuse of fraction mode to multiply a fraction by a real number to obtain a real result. Even if you do not share this view I hope you can see the reasoning behind it.

Nigel (UK)

[Bit]

I've found a bug in ASR (arithmetic right shift): In sign & mantissa mode it used to always set the sign bit.

For example, with word size = 8, 0x23 ASR 1 gave 0x91 instead of the correct 0x11.

I've committed a fix to SVN.

[Bit]

I've committed a patch to make the three options discussed here independently configurable: whether EEX is allowed in fraction mode at all, whether it exits fraction mode, and whether decimal fractions exit fraction mode. For the sake of completeness, it's also configurable whether entering a fraction automatically switches to fraction mode, and whether entering a mixed/proper fraction vs. a simple/improper fraction automatically switches to the corresponding type of fraction mode.

At the same time I've rearranged the code related to INCLUDE_EEX_PI, made it configurable whether it depends on flag L, removed some redundancy and fixed two small problems. One was triggered by invalid input in the command line (incomplete fraction), the other by a command line that was full (very long negative fraction).

Walter, Pauli and Marcus determine what goes into the official WP 34S so by default all new features are inactive and everything continues to work exactly as before until they decide otherwise.

---

This issue seems to stir up emotions in a way I didn't expect but the discussion has made it clear to me that rational reasons to disable EEX can't be found. Marcus had a good idea and Nigel also that are worth exploring IMO. So instead of simply unblocking EEX as I originally intended, I've made EEX and decimal fractions exit fraction mode in my custom builds. I'm not yet fully convinced that automatically exiting fraction mode will prove to be an improvement so I'm open to further discussing its merits and I invite everyone to give it a try and see how well it works in practice.

(Edit: Fix typo.)

[Nigel (UK)]

(11-22-2014 07:49 PM)Bit Wrote:  This thread can be used to discuss those bugs found in, and fixes proposed for, the WP 34S and 31S that don't warrant having their own dedicated thread.

Not a bug, but an issue with three of the compilation options in features.h (if I've understood the situation correctly).

(i) If the INCLUDE_GUDERMANNIAN option is commented out the windows emulator doesn't compile because of the references to this function in console.c . This is easy to fix by adding compilation directives to console.c .

(ii) However, if either INCLUDE_XROOT or INCLUDE_MANTISSA are commented out compilation can't take place because these functions are used in the xrom code. I suggest that these compilation options be removed (so that both functions are always present).

(At least I now know what the gudermannian function is!)

Nigel (UK)

[walter b]

(01-23-2015 04:55 PM)Nigel (UK) Wrote:  At least I now know what the gudermannian function is!

Feel free to look into the manual.

d;-)

[walter b]

(01-18-2015 09:56 PM)Bit Wrote:  ... 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.

Hmmh. The latest emulator build shows "y/x Gt", being consistent with the stack contents. I agree on using ">" instead of "Gt" in the dot matrix display. "Gt" was just meant to be used in the exponent section.

d:-)

[Bit]

(01-23-2015 11:37 PM)walter b Wrote:  

(01-18-2015 09:56 PM)Bit Wrote:  ... 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.

Hmmh. The latest emulator build shows "y/x Gt", being consistent with the stack contents. I agree on using ">" instead of "Gt" in the dot matrix display. "Gt" was just meant to be used in the exponent section.

d:-)

It's indeed y/x. I've committed a patch.

Another minor issue:

After you press the arrow, you can deactivate all shift modes or activate h shift, even though neither makes much sense in 'arrow mode'. The code that handles the arrow (process_arrow() in keys.c) was clearly written to operate in way similar to 'HYP mode' where only the f or g shifts are allowed. It only checks for f shift, thus anything else, g shift, h shift or no shift, all produce the same result: effectively g shift.

For example, [->] [h] [EEX] will show the number in hexadecimal.

I suggest we make the arrow work the same as HYP: only the f and g shifts should be allowed.

[walter b]

(01-24-2015 04:37 AM)Bit Wrote:  After you press the arrow, you can deactivate all shift modes or activate h shift, even though neither makes much sense in 'arrow mode'. The code that handles the arrow (process_arrow() in keys.c) was clearly written to operate in way similar to 'HYP mode' where only the f or g shifts are allowed. It only checks for f shift, thus anything else, g shift, h shift or no shift, all produce the same result: effectively g shift.

I suggest [->]+[h] results in [h] instead. That would be consistent with the prefix rules on p. 70 of 374 of the manual since pressing [->] calls actually [->][g] and there is no h-shifted function which can be combined with [->].

• [->]+[g] results in [->][g][g] = [->] alone - prefixes [f] or [g] may follow then.
• [->] results in [->][g] as mentioned above, allowing for DEG, RAD, GRAD, 8, or 16 following.
• [->]+[f] results in [->][g][f] = [->][f], allowing for H.MS, H.d, 2, or 10 following.
• [->]+[h] results in [->][g][h] = [h] for reasons mentioned above.
  

d:-)

[Bit]

(01-25-2015 04:32 PM)walter b Wrote:  

(01-24-2015 04:37 AM)Bit Wrote:  After you press the arrow, you can deactivate all shift modes or activate h shift, even though neither makes much sense in 'arrow mode'. The code that handles the arrow (process_arrow() in keys.c) was clearly written to operate in way similar to 'HYP mode' where only the f or g shifts are allowed. It only checks for f shift, thus anything else, g shift, h shift or no shift, all produce the same result: effectively g shift.

I suggest [->]+[h] results in [h] instead. That would be consistent with the prefix rules on p. 70 of 374 of the manual since pressing [->] calls actually [->][g] and there is no h-shifted function which can be combined with [->].

• [->]+[g] results in [->][g][g] = [->] alone - prefixes [f] or [g] may follow then.
• [->] results in [->][g] as mentioned above, allowing for DEG, RAD, GRAD, 8, or 16 following.
• [->]+[f] results in [->][g][f] = [->][f], allowing for H.MS, H.d, 2, or 10 following.
• [->]+[h] results in [->][g][h] = [h] for reasons mentioned above.
  

d:-)

The above is easy to implement.

However, allowing all shifts to be turned off ([->] [g] [g]) isn't a very elegant solution in my opinion as the arrow by itself is useless, any key other than [f] or [g] will just cancel it.

Edit: The reason I don't think it's elegant is because pressing [->] again already turns of both the arrow and the (f or g) shift. Either it should leave the f or g shift alone:
[->] [->] [STO] = [g] [STO] = [DEG]

Or a 'no shift' state shouldn't be allowed with the arrow (my preference).

[walter b]

(01-25-2015 04:42 PM)Bit Wrote:  

(01-25-2015 04:32 PM)walter b Wrote:  

• [->]+[g] results in [->][g][g] = [->] alone - prefixes [f] or [g] may follow then.
• [->] results in [->][g] as mentioned above, allowing for DEG, RAD, GRAD, 8, or 16 following.
• [->]+[f] results in [->][g][f] = [->][f], allowing for H.MS, H.d, 2, or 10 following.
• [->]+[h] results in [->][g][h] = [h] for reasons mentioned above.
  

... allowing all shifts to be turned off ([->] [g] [g]) isn't a very elegant solution in my opinion as the arrow by itself is useless, any key other than [f] or [g] will just cancel it.

I didn't say it's elegant but it's allowed.

d:-)

[Bit]

(01-25-2015 05:04 PM)walter b Wrote:  

(01-25-2015 04:42 PM)Bit Wrote:  ... allowing all shifts to be turned off ([->] [g] [g]) isn't a very elegant solution in my opinion as the arrow by itself is useless, any key other than [f] or [g] will just cancel it.

I didn't say it's elegant but it's allowed.

d:-)

I've committed a fix that works as you proposed. If you change your mind about allowing no shift in arrow mode once you've tried it out, let me know.

[walter b]

(01-25-2015 05:27 PM)Bit Wrote:  I've committed a fix that works as you proposed.

You wrote in your commit: "Shift h clears arrow mode, arrow with no shift is NOP." The second part is not what I proposed. Please compare my earlier posts.

d:-?

[Bit]

(01-25-2015 05:45 PM)walter b Wrote:  

(01-25-2015 05:27 PM)Bit Wrote:  I've committed a fix that works as you proposed.

You wrote in your commit: "Shift h clears arrow mode, arrow with no shift is NOP." The second part is not what I proposed. Please compare my earlier posts.

d:-?

The NOP refers to the what I quoted below. [->] [g] [g] results in [->] alone so [f] or [g] can follow, but [->] alone isn't defined as far as I can see. Isn't that what you wanted?

(01-25-2015 04:32 PM)walter b Wrote:  

• [->]+[g] results in [->][g][g] = [->] alone - prefixes [f] or [g] may follow then.

[walter b]

(01-25-2015 05:50 PM)Bit Wrote:  The NOP refers to the what I quoted below. [->] [g] [g] results in [->] alone so [f] or [g] can follow, but [->] alone isn't defined as far as I can see. Isn't that what you wanted?

(01-25-2015 04:32 PM)walter b Wrote:  

• [->]+[g] results in [->][g][g] = [->] alone - prefixes [f] or [g] may follow then.

What I meant was:

• [->]+[g] results in [->][g][g] = [->] alone - prefixes [f] or [g] may follow [->] then.

d:-)

[Bit]

(01-25-2015 05:54 PM)walter b Wrote:  

(01-25-2015 05:50 PM)Bit Wrote:  The NOP refers to the what I quoted below. [->] [g] [g] results in [->] alone so [f] or [g] can follow, but [->] alone isn't defined as far as I can see. Isn't that what you wanted?

What I meant was:

• [->]+[g] results in [->][g][g] = [->] alone - prefixes [f] or [g] may follow [->] then.

d:-)

That's exactly what happens.

But you didn't specify what should happen when something else than [f] or [g] follows, so I took the route that was the simplest to implement: anything else cancels the arrow, i.e. it's effectively a NOP.

[Bit]

(01-25-2015 04:32 PM)walter b Wrote:  

• [->] results in [->][g] as mentioned above, allowing for DEG, RAD, GRAD, 8, or 16 following.
  

[->] [EXIT] used to open the register browser, which made little sense and it isn't listed above as one of the allowed options. I've committed a fix.

[Bit]

Displayed numbers weren't rounded correctly in double precision mode in SCI/ENG 10/11 display modes with SHOW_LARGE_EXPONENT enabled. For example, pi*10²⁰⁰⁰ shows the problem. The default builds are unaffected because they don't display large exponents.

I've committed a fix, which has a minor beneficial effect on the default builds, too: Y register display is faster (in all display modes) because fewer iterations of set_x_dn() are needed on average to get the number of displayed digits right.

[BarryMead]

(11-27-2014 02:13 AM)Bit Wrote:  

(11-26-2014 10:07 PM)pascal_meheut Wrote:  

Pascal, I've changed the function names as you requested.

The new NEXTP implementation still got stuck in a loop for positive infinity in double precision mode, I've fixed that, too.

Bit:

Should we expect a new build in the "Bits 34s and 31S patches and custom binaries" thread soon?
If not there where will the new stuff be posted?