WP 34S and 31S bugs and fixes

[pascal_meheut]

Thanks. Let me know when we have a stable version so I can update the iOS version.

[Marcus von Cube]

(11-27-2014 05:45 AM)pascal_meheut Wrote:  Thanks. Let me know when we have a stable version so I can update the iOS version.

I'll rebuild everything shortly. Stay tuned.

[Bit]

This is not a bugfix but I might as well announce it here: I've refactored set_exp() in display.c to save about 20 bytes in the firmware and created a compile time option (disabled by default) to display all four digits of large exponents in double precision mode. I've added the changes to the 31S even though it has no double precision mode because of the slight reduction in firmware size.

[Bit]

With PRETTY_FRACTION_ENTRY enabled (as it is in the official build), longer fractions overflow into the exponent field because of the extra space and forward slash. The first such digit was displayed correctly but the second wasn't because disp_x() didn't take into account that there are fewer LCD segments in the exponent field.

Here's how to reproduce the problem:
[1] [2] [3] [4] [5] [.] [6] [7] [8] [9] [0] [.] [1] [2]

I've committed fixes for both the 34S and the 31S.

[Bit]

I've noticed some inconsistencies in how exponents can be entered in single precision mode and on the 31S:

1. Changing the sign
   
   You cannot enter e-384 in the following way because the calculator limits the negative exponent to -383:
   [EEX] [+/-] [3] [8] [4]
   
   However, you can enter it like this as exponents are not checked when the sign is changed:
   [EEX] [3] [8] [4] [+/-]
   
   This is inconsistent behavior, entering e-384 should either be allowed or not.
   
   
2. Domain errors and infinities
   
   Entering 12e384 will produce a domain error or an infinity depending on flag D because the number overflows. I consider this inconsistent behavior, too, because if infinities can be entered this way, I don't see why 1e399 shouldn't be allowed.
   

While experimenting with this, I created two patches:
A. Keep it simple: exponents up to +/- 384 are allowed. No digits are lost even with e-384 because the 12 digits you can enter always fit into the 16 digit mantissa as a denormalized number.
B. Figure out the precise maximum based on the number entered and only allow exponents that will neither result in infinities or domain errors, nor in entered digits lost.

Walter, since this is a user interface issue with no obvious "best" solution, please make a decision on how it should be handled. I don't mind creating a slightly different third patch if necessary.

[walter b]

The last build I can assess is 3697.

With respect to pretty fraction entry: I can reproduce that the last digit of the denominator in your example isn't displayed correctly. I must admit I don't like the overflowing in the exponent section at all. I don't know when this was introduced. IMHO, if anything shall overflow it shall be handled as described in the manual, top of p. 85. If that's not viable, I'd rely on the intelligence of the user not entering too long fractions (an error is thrown in build 3697 if you try entering one digit more).

With respect to your latest post:
1) 1e-383 is the smallest number that shall be allowed to enter directly (cf. p. 276). 1e-384 must not be a legal entry.
2) Please cf. p. 277. The behaviour looks pretty consistent to me.

d:-/

[Marcus von Cube]

(12-06-2014 05:13 PM)walter b Wrote:  The last build I can assess is 3697.

Try again!

[Bit]

(12-06-2014 05:13 PM)walter b Wrote:  With respect to pretty fraction entry: I can reproduce that the last digit of the denominator in your example isn't displayed correctly. I must admit I don't like the overflowing in the exponent section at all. I don't know when this was introduced. IMHO, if anything shall overflow it shall be handled as described in the manual, top of p. 85. If that's not viable, I'd rely on the intelligence of the user not entering too long fractions (an error is thrown in build 3697 if you try entering one digit more).

Hopefully I'll receive the printed manual soon but it hasn't arrived yet. Could you please quote the relevant sentence or refer to the manual that's publicly available?

I'm sure this digit overflow business can be handled in any way you like without a significant increase in code size, so once I receive the information about what exactly should happen, I'll create a patch.

(12-06-2014 05:13 PM)walter b Wrote:  With respect to your latest post:
1) 1e-383 is the smallest number that shall be allowed to enter directly (cf. p. 276). 1e-384 must not be a legal entry.

Again, it'd be really helpful, perhaps also for others who might be reading this thread, if you could quote publicly available documentation.

In the current official builds 1e-384 is a legal entry as long as you type it as such: [EEX] [3] [8] [4] [+/-]
What would you like to happen when the [+/-] key is pressed?

[walter b]

P. 85 (v3.3) corresponds to p. 42 (v3.1), p. 276 and 277 to p. 161.

d:-/

[walter b]

(12-06-2014 06:55 PM)Marcus von Cube Wrote:  

(12-06-2014 05:13 PM)walter b Wrote:  The last build I can assess is 3697.

Try again!

Danke! Pretty fraction entry now works even for the third digit in the exponent. Nevertheless, I stay with my opinion posted earlier about the topics mentioned.

d:-)

[Nigel (UK)]

(12-06-2014 08:44 PM)Bit Wrote:  

(12-06-2014 05:13 PM)walter b Wrote:  With respect to pretty fraction entry: I can reproduce that the last digit of the denominator in your example isn't displayed correctly. I must admit I don't like the overflowing in the exponent section at all. I don't know when this was introduced. IMHO, if anything shall overflow it shall be handled as described in the manual, top of p. 85. If that's not viable, I'd rely on the intelligence of the user not entering too long fractions (an error is thrown in build 3697 if you try entering one digit more).

Hopefully I'll receive the printed manual soon but it hasn't arrived yet. Could you please quote the relevant sentence or refer to the manual that's publicly available?

I'm sure this digit overflow business can be handled in any way you like without a significant increase in code size, so once I receive the information about what exactly should happen, I'll create a patch.

(12-06-2014 05:13 PM)walter b Wrote:  With respect to your latest post:
1) 1e-383 is the smallest number that shall be allowed to enter directly (cf. p. 276). 1e-384 must not be a legal entry.

Again, it'd be really helpful, perhaps also for others who might be reading this thread, if you could quote publicly available documentation.

In the current official builds 1e-384 is a legal entry as long as you type it as such: [EEX] [3] [8] [4] [+/-]
What would you like to happen when the [+/-] key is pressed?

Here are some thoughts from a user:

As a general principle, I'd like things to stay consistent with the manual unless the change fixes a bug. Any significant changes that find their way into the default build need to be clearly documented.

In the default build, 0.00123e-383 (for example), when entered, displays as 1.23e-386. Checking for numbers being too small or large once the command line has been processed might be easier than trying to prevent their entry, and would allow a consistent approach. Speaking for myself, not being permitted to enter 1.23e-386 directly has never been a source of frustration. In fact I rather enjoyed finding a way around the input restriction, but I accept that consistency is to be desired.

Finally: I'm really grateful for the effort that bit is putting into "torture testing" the WP34S firmware. Thank you!

Nigel (UK)

[Bit]

(12-06-2014 10:28 PM)walter b Wrote:  

(12-06-2014 06:55 PM)Marcus von Cube Wrote:  Try again!

Danke! Pretty fraction entry now works even for the third digit in the exponent. Nevertheless, I stay with my opinion posted earlier about the topics mentioned.

d:-)

I've just committed a change that makes fraction entry look similar to fraction display: instead of the last digits overflowing into the exponent field, the first digits disappear to the left.

[Bit]

(12-07-2014 08:54 PM)Nigel (UK) Wrote:  Here are some thoughts from a user:

As a general principle, I'd like things to stay consistent with the manual unless the change fixes a bug. Any significant changes that find their way into the default build need to be clearly documented.

In the default build, 0.00123e-383 (for example), when entered, displays as 1.23e-386. Checking for numbers being too small or large once the command line has been processed might be easier than trying to prevent their entry, and would allow a consistent approach. Speaking for myself, not being permitted to enter 1.23e-386 directly has never been a source of frustration. In fact I rather enjoyed finding a way around the input restriction, but I accept that consistency is to be desired.

Nigel, thank you for sharing your thoughts.

Regarding what's easy to check: A full-fledged mechanism that always knows the maximum exponent that can be entered without producing an infinity or losing any entered digits in denormalized numbers, costs about 10 extra lines of code, 40 bytes in the firmware and no measurable decrease in performance. It's very cheap, so in my opinion the decision should be based on what's the best user experience.

If I understood Walter correctly, in his opinion the current intended behavior of only permitting exponents between 384 and -383 is optimal. However, the actual behavior is that it's possible to enter 1e-384 directly.

[Nigel (UK)]

(12-07-2014 10:01 PM)Bit Wrote:  Nigel, thank you for sharing your thoughts.

Regarding what's easy to check: A full-fledged mechanism that always knows the maximum exponent that can be entered without producing an infinity or losing any entered digits in denormalized numbers, costs about 10 extra lines of code, 40 bytes in the firmware and no measurable decrease in performance. It's very cheap, so in my opinion the decision should be based on what's the best user experience.

If I understood Walter correctly, in his opinion the current intended behavior of only permitting exponents between 384 and -383 is optimal. However, the actual behavior is that it's possible to enter 1e-384 directly.

So how about using your mechanism to forbid the entry of any numbers smaller than 1e-383 (or greater than 9.9999...e384), no matter how they are entered? That seems to be how Walter (and Marcus, Pauli) intend the calculator to behave. Am I correct, Walter?

Nigel (UK)

[walter b]

(12-08-2014 09:43 AM)Nigel (UK) Wrote:  So how about using your mechanism to forbid the entry of any numbers smaller than 1e-383 (or greater than 9.9999...e384), no matter how they are entered? That seems to be how Walter (and Marcus, Pauli) intend the calculator to behave. Am I correct, Walter?

First of all: I concur with your thanks to Bit for torture testing. He keeps finding things.

Second: I concur with your thoughts about keeping consistency with the documentation.

I must admit I overlooked the possibility of entering 0.0001e-383 and alike when writing p. 161 of the v3.1 manual (and I didn't crosscheck that later anymore). Anyway, this page as is states 1e-383 "is the smallest number that can be entered directly". And subsequently it is written 9.999 999 999 99e384 "is the greatest that can be entered directly". So I'd appreciate if we can keep it that way.

If it's easier to just check the exponent being between 384 and -383 I could live with that as well. But as Bit pointed out I guess it isn't - entering [EEX] 384 [+/-] would need special treatment.

Thanks in advance. And sorry for my sloppyness.

d:-)

[walter b]

(12-07-2014 09:38 PM)Bit Wrote:  I've just committed a change that makes fraction entry look similar to fraction display: instead of the last digits overflowing into the exponent field, the first digits disappear to the left.

Thanks. Looks good to me in build 3710.

d:-)

[Bit]

(12-08-2014 10:39 AM)walter b Wrote:  First of all: I concur with your thanks to Bit for torture testing. He keeps finding things.

Second: I concur with your thoughts about keeping consistency with the documentation.

I must admit I overlooked the possibility of entering 0.0001e-383 and alike when writing p. 161 of the v3.1 manual (and I didn't crosscheck that later anymore). Anyway, this page as is states 1e-383 "is the smallest number that can be entered directly". And subsequently it is written 9.999 999 999 99e384 "is the greatest that can be entered directly". So I'd appreciate if we can keep it that way.

If it's easier to just check the exponent being between 384 and -383 I could live with that as well. But as Bit pointed out I guess it isn't - entering [EEX] 384 [+/-] would need special treatment.

Thanks in advance. And sorry for my sloppyness.

d:-)

Walter, Nigel, it's my pleasure to help out with torture testing. It's always fun to figure out ways to break things.

Regarding exponent entry, let's first establish what user interaction we'd ideally like to see, and only go back to the drawing board and consider compromises in the unlikely case that the implementation turns out to be impractical. All of this is "easy" in the sense that we're probably only talking about a few bytes of ARM machine code.

What shall happen in the following special cases?

1. The user already entered 1e384 and then attempts to change the sign, which would result in the illegal entry of 1e-384.
   • Silently ignore the [+/-] key?
   • Produce an error message and ignore the [+/-] key?
   • Shift the exponent so it becomes 84 to give the same result as if [+/-] was pressed first?
   • Consider it an overflow in the exponent, and make it -383?
   • Zero out the exponent?
   • Something else?
     
   
   
2. The user entered 0.01 and then proceeds to enter an exponent. According to the specification ("9.999 999 999 99e384 is the greatest that can be entered directly"), the largest exponent that could be allowed in this case is 386.
   • Allow e386 etc. as long as the resulting number isn't greater than 9.999 999 999 99e384?
   • Cap the exponent at 384 no matter what?
   • Something else?
     
   
   
3. The user entered 123 and then proceeds to enter a negative exponent. According to the specification ("1e-383 is the smallest number that can be entered directly"), we could allow e-385 here.
   • Allow e-385 etc. as long as the resulting number isn't smaller than 1e-383?
   • Cap the exponent at -383 no matter what?
   • Something else?
     
   
   
4. The user entered 0.01 and then proceeds to enter a negative exponent. According to the specification ("1e-383 is the smallest number that can be entered directly"), we could only allow e-381 here.
   • Only allow e-381 etc. in such cases and shift the exponent otherwise (e.g. -382 becomes -82)?
   • Only allow e-381 etc. in such cases and produce an error message otherwise?
   • Allow e-383 no matter what?
   • Something else?
     

Please comment.

[walter b]

Remember we want to stay with the features as documented. That's a constraint to be fulfilled. Luckily, the manual v3.1 reads on p. 37:

Quote:All keyboard input will be interpreted when the input is completed, according to the modes set at that time.

This is also found on p. 74 of the manual v3.3.

So, when entering a real number featuring an exponent, we can test the exponent alone being smaller than 385 and greater than -384; this is already done now and takes care of cases 2 through 4 in Bit's post. Only case 1 remains to be taken care of; for that I tend to vote for "Shift the exponent so it becomes 84 to give the same result as if [+/-] was pressed first" for sake of consistency with other methods entering such a negative exponent (i.e. [EEX] [+/-] 384 or [EEX] 3 [+/-] 84 or [EEX] 38 [+/-] 4).

IMHO, that suggestion would cover all special cases Bit mentioned. And it stays consistent with the manual.

d:-)

P.S. The alternative would be to start even elementary exponent testing not earlier than closing the entire input. That would also follow the quoted sentence (since it's a bit ambiguous) but violate the statements on p. 161 (v3.1) or 276f (v3.3) head on.

[Bit]

(12-08-2014 05:03 PM)walter b Wrote:  Remember we want to stay with the features as documented. That's a constraint to be fulfilled. Luckily, the manual v3.1 reads on p. 37:

Quote:All keyboard input will be interpreted when the input is completed, according to the modes set at that time.

This is also found on p. 74 of the manual v3.3.

So, when entering a real number featuring an exponent, we can test the exponent alone being smaller than 385 and greater than -384; this is already done now and takes care of cases 2 through 4 in Bit's post. Only case 1 remains to be taken care of; for that I tend to vote for "Shift the exponent so it becomes 84 to give the same result as if [+/-] was pressed first" for sake of consistency with other methods entering such a negative exponent (i.e. [EEX] [+/-] 384 or [EEX] 3 [+/-] 84 or [EEX] 38 [+/-] 4).

IMHO, that suggestion would cover all special cases Bit mentioned. And it stays consistent with the manual.

d:-)

This would still allow directly entering e.g. 1e-385 as 0.01e-383, which contradicts the rule "1e-383 is the smallest number that can be entered directly". I'm not suggesting it's a problem, just pointing it out. Is that what you want?

[Nigel (UK)]

My opinions:

Case 1: produce an error message saying "Too small".

Case 2: allow the exponent so long as the number is less than 1e385; if it isn't, produce an error message saying "Too big".

Case 3: allow the exponent so long as the number isn't smaller than 1e-383; if it is smaller, give the "Too small" error message.

Case 4: same as Case 3 - i.e., allow any entry that leads to a number no smaller than 1e-383, and give an error message for other entries.

I think that it is best to decide whether the number is allowed only after it has been entered. I accept that this isn't entirely consistent with what is in the manual, but it is consistent and is unlikely to cause problems. People should not expect numbers outside of the allowed range to be accepted; giving an error message is the clearest way to show them that there is a problem.

Nigel (UK)