WP 34S and 31S bugs and fixes
|
11-27-2014, 05:45 AM
Post: #21
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
Thanks. Let me know when we have a stable version so I can update the iOS version.
|
|||
11-27-2014, 10:23 PM
Post: #22
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(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. Marcus von Cube Wehrheim, Germany http://www.mvcsys.de http://wp34s.sf.net http://mvcsys.de/doc/basic-compare.html |
|||
11-29-2014, 08:31 PM
Post: #23
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
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.
|
|||
12-06-2014, 03:23 AM
Post: #24
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
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. |
|||
12-06-2014, 03:02 PM
Post: #25
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
I've noticed some inconsistencies in how exponents can be entered in single precision mode and on the 31S:
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. |
|||
12-06-2014, 05:13 PM
Post: #26
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
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:-/ |
|||
12-06-2014, 06:55 PM
Post: #27
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
Marcus von Cube Wehrheim, Germany http://www.mvcsys.de http://wp34s.sf.net http://mvcsys.de/doc/basic-compare.html |
|||
12-06-2014, 08:44 PM
Post: #28
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(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: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? |
|||
12-06-2014, 10:20 PM
Post: #29
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
P. 85 (v3.3) corresponds to p. 42 (v3.1), p. 276 and 277 to p. 161.
d:-/ |
|||
12-06-2014, 10:28 PM
Post: #30
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes | |||
12-07-2014, 08:54 PM
Post: #31
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(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? 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) |
|||
12-07-2014, 09:38 PM
Post: #32
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-06-2014 10:28 PM)walter b Wrote:(12-06-2014 06:55 PM)Marcus von Cube Wrote: Try again! 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. |
|||
12-07-2014, 10:01 PM
Post: #33
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-07-2014 08:54 PM)Nigel (UK) Wrote: Here are some thoughts from a user: 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. |
|||
12-08-2014, 09:43 AM
Post: #34
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-07-2014 10:01 PM)Bit Wrote: Nigel, thank you for sharing your thoughts. 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) |
|||
12-08-2014, 10:39 AM
(This post was last modified: 12-08-2014 10:40 AM by walter b.)
Post: #35
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(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:-) |
|||
12-08-2014, 03:11 PM
Post: #36
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes | |||
12-08-2014, 03:38 PM
(This post was last modified: 12-08-2014 03:54 PM by Bit.)
Post: #37
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(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. 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?
|
|||
12-08-2014, 05:03 PM
(This post was last modified: 12-08-2014 05:25 PM by walter b.)
Post: #38
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
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. |
|||
12-08-2014, 05:19 PM
Post: #39
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(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. 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? |
|||
12-08-2014, 05:33 PM
Post: #40
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
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) |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)