WP 34S and 31S bugs and fixes

[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.