WP 34S and 31S bugs and fixes
|
12-08-2014, 05:40 PM
Post: #41
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
Nice ideas. Those errror messages are not featured yet, however.
d:-/ |
|||
12-08-2014, 05:42 PM
(This post was last modified: 12-08-2014 05:54 PM by walter b.)
Post: #42
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-08-2014 05:19 PM)Bit Wrote: 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". Correct. That can be only caught by range checking with the entire input closed. I understood that we can do that spending a few bytes (not that I assess that solution a perfect one - but it looks viable to me under the constraints given). Alternative 1: we follow Nigel - but we don't have suitable error messages AFAICS. 12e384 returns a "+infinity error" as it should - we don't have a "zero error" taking care of the other end. Alternative 2: we quietly allow denormalized number entry like 0.01e-383. It's my fault in the doc as admitted above. I should have written "1e-383 is the smallest normalized number that can be entered directly." d:-/ |
|||
12-08-2014, 05:49 PM
Post: #43
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-08-2014 05:42 PM)walter b Wrote:(12-08-2014 05:19 PM)Bit Wrote: 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". Walter, that problem can be very easily caught immediately during number entry, without spending any CPU cycles on converting the input into a floating point number. That check is practically free. The only question is if you'd prefer such a check to be performed. And I'm happy to add a few extra error messages, it's really no effort. Let's try to figure out what's the best user interface and worry about coding later. |
|||
12-08-2014, 06:25 PM
Post: #44
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
Summarizing the status of the discussion:
We've to choose between the devil and the deep blue sea. If we want to stick to the documentation as is (as Nigel suggested with good reason), I pointed out two ways to go. Else the world is wide open but we'd either introduce new undocumented features or violate the docs. d:-? |
|||
12-08-2014, 06:34 PM
Post: #45
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-08-2014 06:25 PM)walter b Wrote: Summarizing the status of the discussion: Once a conclusion has been reached, I'll create an implementation. By the way, my personal preference is to eliminate surprises as such:
|
|||
12-12-2014, 03:20 PM
Post: #46
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-08-2014 03:11 PM)walter b Wrote:(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. I've noticed a problem with my original implementation: Very long fractions could eat up the whole command line and leave no space for the minus sign and so the sign of such fractions couldn't be changed. I've committed a fix to both the 34S and the 31S. |
|||
12-12-2014, 03:37 PM
Post: #47
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-12-2014 03:20 PM)Bit Wrote: I've noticed a problem with my original implementation: Very long fractions could eat up the whole command line and leave no space for the minus sign and so the sign of such fractions couldn't be changed. I've committed a fix to both the 34S and the 31S. Just verified. Good catch! d:-) |
|||
12-12-2014, 06:58 PM
(This post was last modified: 12-13-2014 09:57 AM by Marcus von Cube.)
Post: #48
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-12-2014 03:37 PM)walter b Wrote: Just verified. Good catch!Try again, please! Edited to please Walter. ![]() Marcus von Cube Wehrheim, Germany http://www.mvcsys.de http://wp34s.sf.net http://mvcsys.de/doc/basic-compare.html |
|||
12-12-2014, 08:46 PM
Post: #49
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes | |||
12-16-2014, 02:57 AM
(This post was last modified: 12-17-2014 04:35 AM by Bit.)
Post: #50
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
While the best way to handle exponent entry is being elaborated, I've reworked the infrastructure that deals with it and introduced fine-grained compile time options to control what happens when exponents are entered.
Options available for negative exponents:
A zero mantissa can be handled in these ways:
I've added the following optional new features:
I've attached a 34S flash image and a Windows binary to showcase the new functionality: - With flag D cleared, denormal numbers and overflowing into infinity are not allowed, and additionally exponents are limited to the -383..384 range. E.g. 1e384 is OK, 10e384 isn't, 1e-383 is OK, 0.1-383 isn't. - With flag D set, denormal numbers are allowed as long as all entered digits can be stored, overflowing into infinity still isn't allowed, but exponents aren't capped. All of these are OK: 0.01e386, 1000e-401, 0.12e-396, 0.1e-397. - In both cases, changing the sign is only allowed if the resulting exponent is legal. - Exponents are left justified, and digits aren't shifted, warnings are produced instead. - Warnings appear in the upper line only, the entered number doesn't get hidden. It's a relatively large number of changes and while I made an effort to test every code path and combination, it's possible that some bugs remained in the code, which I'll fix in subsequent updates. As usual, feedback would be welcome. We can do basically anything we want with the exponents without a very big increase in firmware size. Q.E.D. (Edited to add a third option to how a zero mantissa can be handled, as requested by Nigel.) |
|||
12-16-2014, 10:20 PM
(This post was last modified: 12-16-2014 11:19 PM by Nigel (UK).)
Post: #51
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
Thank you Bit! There's (surely) something here to satisfy everyone. I have not explored every possible combination of options but so far I have found no bugs. Those of you who do not compile the code yourself might nevertheless like to take a look at the file trunk/features.h to see the fine-grained control that Bit's code allows.
Here are the options that I would choose for the default build:
Going beyond these, it would be nice to allow any exponent if the mantissa is zero - i.e., 0 EEX 9 9 9 should not throw a TOO BIG error. This isn't currently an option in the code so far as I can see. I don't feel strongly about this, but the errors are odd. These choices are not fully consistent with the existing documentation but I feel that any small discrepancies are a price worth paying for the consistency in number entry that Bit's code allows. Nigel (UK) [Edited for clarity and correctness. I had not fully understood the rather large range of options available at the time of my first post. Edited again for the same reason. I hope I've understood it properly this time!] |
|||
12-17-2014, 12:55 AM
Post: #52
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-16-2014 10:20 PM)Nigel (UK) Wrote: Going beyond these, it would be nice to allow any exponent if the mantissa is zero - i.e., 0 EEX 9 9 9 should not throw a TOO BIG error. This isn't currently an option in the code so far as I can see. I don't feel strongly about this, but the errors are odd. That sounds like a reasonable alternative to the choices I originally included. I've added it as an option. |
|||
12-22-2014, 09:42 PM
Post: #53
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
All seems rather quiet here!
The present code (3716) allows the user to choose between two different ways of handling the entry of large or small numbers using Flag D. A decision on which settings should be compiled in by default would allow the dependence on Flag D to be removed from the code. I have my own preference (mentioned in a previous post) but I don't feel strongly that they should be the default settings because I can compile my own code. So which settings should appear by default in future firmware versions? Any opinions? Nigel (UK) |
|||
12-23-2014, 02:42 AM
Post: #54
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
I know it is far to late to speak about this, because the documentation is already printed, the memory is full, and the product is on the market. But I have to.
One of my first experiences with the WP34S, playing around with it, not knowing anything about this calculator, was staring at this "2c64" cryptic numbers in the upper left display, which somehow had appeared by any keystroke, no chance to remember when it exactly happened, but the hell did not want to disappear again, even after Clx or switch off and on. Now everybody knows what it means and knows how to get back to a "normal" display. But the first impression counts, and it was somehow negative. Obviously I was not the first, who was irritated about that, because in the manual I discovered at the very first pages for beginners the instruction to get rid of this. There must have been complaints about it. IMO the wordsize and complement mode are not important enough, that they must be shown all the time. Also they will not be changed very often. And integer mode is already indicated by the letters right of the X number. And they are wasting the place to show the Y register in integer mode. Wouldn't it be better, to leave the Y line clear and show wordsize and mode only when STATUS is invoked, like the HP-16C did? This would allow to show the Y-register in integer mode when YDON is active, and would avoid making 34S newbies nervous, like I was, when I was playing around before reading the manual, not knowing what was going on with this damned/wonderful calculator. Bernhard |
|||
12-23-2014, 04:03 AM
Post: #55
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-22-2014 09:42 PM)Nigel (UK) Wrote: All seems rather quiet here! Taking flag D into account is intentional: Flag D already allows NaNs and infinities in the results without producing an error. In a similar way entering denormal numbers, for example, could be allowed only when flag D is set. I'm not suggesting that it necessarily be so, just offering it as an option. I made an effort to structure the code in such a way that if any of the settings are the same for flag D cleared and set, then only one code branch will be compiled in for the appropriate function instead of two. There's no need to remove anything from the code, unused portions are automatically eliminated. |
|||
12-23-2014, 04:48 AM
(This post was last modified: 12-23-2014 05:08 AM by Bit.)
Post: #56
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-23-2014 02:42 AM)PANAMATIK Wrote: I know it is far to late to speak about this, because the documentation is already printed, the memory is full, and the product is on the market. But I have to. Changes have been made before and I'm sure further changes will happen if they're deemed justified. And the firmware memory isn't strictly full, it's only almost full. ![]() Seeing 2c64 may be confusing but it'd be much more confusing if the calculator operated in integer mode but it wasn't very obviously signaled to the user that something was off. The right solution in my opinion is to explain very clearly at the very beginning of the documentation what's going on and how to return to normal mode. I gave some of these calculators to a few people and included a two page executive summary whose second paragraph mentions the RESET function and later on [f] [H.d] is pointed out as well, because first impressions matter indeed. A case can definitely be made for allowing Y register display in integer mode, but in my opinion it'd only benefit advanced users who know what integer mode is, not beginners. I do think that word size and signed integer representation are important and as someone who actually uses integer mode, I wouldn't say they're only changed very rarely. The bigger problem is that there's no way to contract integers like you can reals with the exponent notation, therefore, especially when working in binary mode, you scroll using the [f] [<] and [g] [>] keys and the little bars in the upper right corner indicate which portion of the digits you see. With Y register display enabled, you wouldn't have that. Another problem is that I'm not sure how an integer Y register should be displayed in the limited space without exponent notation. Maybe it could be scrolled together with the X register? I considered adding Y register display to integer modes when I created the current Y register display implementation but decided against it because of the above reasons. If someone can suggest a more or less reasonable way it should work, I don't mind implementing it. |
|||
12-23-2014, 09:16 AM
Post: #57
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-23-2014 04:03 AM)Bit Wrote:(12-22-2014 09:42 PM)Nigel (UK) Wrote: All seems rather quiet here! I'd missed that completely. Thanks for the explanation. So there is no need for any further action unless someone is unhappy with the defaults you have chosen. Nigel (UK) |
|||
12-23-2014, 12:02 PM
(This post was last modified: 12-23-2014 12:04 PM by PANAMATIK.)
Post: #58
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-23-2014 04:48 AM)Bit Wrote: Seeing 2c64 may be confusing but it'd be much more confusing if the calculator operated in integer mode but it wasn't very obviously signaled to the user that something was off. Integer mode is clearly signaled by the base incdicator b,o,d,h,3,4,5... (12-23-2014 04:48 AM)Bit Wrote: The bigger problem is that there's no way to contract integers like you can reals with the exponent notation. IMO a logical integer contraction would be: mantissa, then 'e' followed by the decimal number of digits that are not shown. i.e. in binary 10011011 -> 1001e04 decimal 1234567 -> 1234e3. Its like a non normalized exponential display in real mode and easy to understand. 'e' is for: exponent in the current base, expressed as decimal number. The little bars can still be shown, there is a maximum of 8 bars used in binary mode at wordsize 64, and there are enough matrix columns left when you show 3 digits of mantissa. The not used decimal point gives you another 3 columns. ![]() Bernhard |
|||
12-23-2014, 01:23 PM
Post: #59
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-23-2014 09:16 AM)Nigel (UK) Wrote:(12-23-2014 04:03 AM)Bit Wrote: Taking flag D into account is intentional: Flag D already allows NaNs and infinities in the results without producing an error. In a similar way entering denormal numbers, for example, could be allowed only when flag D is set. I'm not suggesting that it necessarily be so, just offering it as an option. Many are probably unhappy with the current defaults because (1) they mimic the old behavior with simple limits and don't take advantage of the newly introduced intelligence in the code and (2) they also reproduce the odd and inconsistent behavior that allows [EEX] [3] [8] [4] [+/-] but not [EEX] [+/-] [3] [8] [4]. I set these defaults so they don't have to be changed yet again once a decision has been made. (The attached demo binary uses completely different settings than what's in mainline.) I expect that once Walter, Pauli and Marcus figured out what should happen during exponent entry, we'll change the defaults. In the meantime I'm happy to discuss further ideas if anyone wants to suggest something I haven't already implemented as an option. |
|||
12-23-2014, 01:38 PM
Post: #60
|
|||
|
|||
RE: WP 34S and 31S bugs and fixes
(12-23-2014 12:02 PM)PANAMATIK Wrote:(12-23-2014 04:48 AM)Bit Wrote: The bigger problem is that there's no way to contract integers like you can reals with the exponent notation. I'm a little hesitant about using the exponent notation for integers but it might just fit my description of "a more or less reasonable way it should work". Even if I decide to, I won't be able to work on this for a while right now. Would anyone else like to share their thoughts regarding how good of a user interface the above may be? |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 2 Guest(s)