WP 34S and 31S bugs and fixes

[walter b]

Nice ideas. Those errror messages are not featured yet, however.

d:-/

[walter b]

(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:-/

[Bit]

(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".

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: we follow Nigel - but we don't have suitable error messages AFAICS.

d:-/

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.

[walter b]

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:-?

[Bit]

(12-08-2014 06:25 PM)walter b Wrote:  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:-?

Once a conclusion has been reached, I'll create an implementation.

By the way, my personal preference is to eliminate surprises as such:

• Permit everything that can be stored, permit nothing that cannot be stored.
  Allow entering all numbers with any combination of decimal mark placement and exponent as long as they can be stored without overflow or loss of precision, but don't allow anything else. Pressing Enter after a number would thus never produce an infinity or domain error or fewer digits in the mantissa than entered.
• Instant error messages.
  Produce an error message immediately if the user tries to enter a digit (or change the sign) that would result in a number that can't be accepted according to the above, just like you get a "too long" error if you try to enter more than 12 digits. This implies that the exponent would not be shifted.
  

[Bit]

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

Thanks. Looks good to me in build 3710.

d:-)

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.

[walter b]

(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:-)

[Marcus von Cube]

(12-12-2014 03:37 PM)walter b Wrote:  Just verified. Good catch!

Try again, please!

Edited to please Walter.

[walter b]

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

... please! AFAICS quickly, build 3713 works as advertized.

d:-)

[Bit]

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:

• Use a configurable fixed limit, e.g. -383.
• Don't allow denormal numbers but allow everything else: 100e-385, 1e-383, 0.1e-382 are legal, 0.1e-383 isn't.
• Allow denormal numbers only if all entered digits can be stored.
• Allow denormal numbers if at least one entered digit can be stored.
  

Options available for positive exponents:

• Use a configurable fixed limit, e.g. 384.
• Don't allow numbers that overflow to infinity: 10e383, 1e384, 0.1e385 are legal, 10e384 isn't.
  

A high or low absolute limit that further restricts exponents in addition to the above rules can be optionally set for negative exponents and separately for positive exponents.

A zero mantissa can be handled in these ways:

• Treat it as a number with one significant digit and apply normal rules.
• Allow any exponent, within the absolute limits configured if any, since zero will remain zero no matter the exponent.
• Allow any exponent even if absolute limits are configured.
  

Options available for changing the sign of the exponent:

• Limit exponents so that changing the sign is always allowed. E.g. if the permitted range without this rule is -383..384, only -383..383 will be allowed.
• Don't allow changing the sign if the resulting exponent would be out of the allowed range. Digits will be shifted or a warning will be produced.
• Changing the sign is always allowed, even if the resulting exponent violates other rules.
• Extend the range of exponents so changing the sign is always allowed. E.g. if the permitted range without this rule is -383..384, then -384..384 will be allowed.
  

All of the above can be configured independently for using the calculator with flag D cleared or set. There's also a debug option present that allows all of the above to be controlled at run-time using numbered registers and flags.

I've added the following optional new features:

• Produce a warning (too long, too big or too small) instead of shifting the digits in the exponent when the entered number would be out of range. With dynamic exponent limits I think this is more useful behavior.
• Warnings during number entry (bad digit, too long, too big, too small) occupy the upper line only and don't hide the number you're typing. Warnings are just as informative but less disruptive.
• Entered exponents aren't zero padded, instead they're displayed left justified. If digits are not shifted, some may prefer this.
• Entered exponents are padded with spaces instead of zeros. If digits are not shifted, some may prefer this.
  

I've fixed the following issues:

• The calculator could be tricked into accepting too large exponents.
  Try this: [EEX] [4] [0] [0] [9] [9] [9]
  It happened because leading zeros were not removed after digits were shifted.
• If a minus sign was followed immediately by a decimal mark, a zero was not inserted before the decimal mark.
  Try this: [0] [+/-] [<-] [.] [5]
  The display will show -5 but you'll be entering -0.5
  The same bug caused domain errors when entering fractions: [0] [+/-] [<-] [.] [1] [.] [2] [ENTER]
• If the command line was full, the digits in the exponent couldn't be shifted as expected:
  Enter this: [1] [.] [2] [3] [4] [5] [6] [7] [8] [9] [0] [1] [2] [+/-] [EEX] [+/-] [1] [2] [3] [4]
  You'll get a "too long" warning rather than the exponent -234.
  

The code is structured in such a way that the compiler can eliminate unused branches. Despite the extra features and fixes, if the new code is configured to mimic the old behavior (minus the bugs), the size of the compiled code is slightly smaller. That's the default configuration I've committed, considering that the decision about exponents is still pending. The same changes have been applied to both the 34S and the 31S.

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

[Nigel (UK)]

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:

• Both positive and negative exponent entry to be type 1, so that exponents outside the range of the limits are allowed so long as the complete number is within range. So 0.1 EEX 385 is fine.
• Don't allow sign changing if it results in an illegal exponent (SP_EXP_ENTRY_CHS type 1). This removes the anomaly of 1 EEX 3 8 4 +/- being legal while 1 EEX +/- 384 is forbidden; both are now forbidden.
• Show a warning on illegal exponent entry rather than silently blocking the entry of illegal digits. This error should be clear and so should take up two lines.
  

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!]

[Bit]

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

[Nigel (UK)]

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)

[PANAMATIK]

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

[Bit]

(12-22-2014 09:42 PM)Nigel (UK) Wrote:  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)

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.

[Bit]

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

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

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.

[Nigel (UK)]

(12-23-2014 04:03 AM)Bit Wrote:  

(12-22-2014 09:42 PM)Nigel (UK) Wrote:  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)

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.

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)

[PANAMATIK]

(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

[Bit]

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

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.

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)

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.

[Bit]

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

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

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?