New WP34S unit

[Nigel (UK)]

(11-04-2023 08:22 PM)ebs Wrote:  Nigel, 3918 works as you described.

But the loss of the most significant digits when WSIZE is surpassed could be a bit confusing, specially in LZOFF mode in binary, if a one followed by zeros is lost all that zeros suddenly disappear. Would be better if possible when the limit of WSIZE is reached, trigger a "Too long error"?

On the calculator as it was previously, nothing special happens when WSIZE is passed. With an 8-bit word size I could enter "12345678" in hex mode; it only changes to "78" when the command line is processed (ENTER or another operation). I agree that the issue you have identified is more of a problem.

Initially I did intend to count up digits and flash up a warning when too many are entered. The problem is that the number of digits varies with the base. In bases 2, 4, 8, 16 it's easy to work out; in other bases the number of digits allowed depends on the exact digits that are entered. If I could think of a quick way to spot when overflow occurs I'd implement it, but so far I haven't managed this. That doesn't mean it can't be done or even that it's hard; any ideas are welcome! Any method has to be light on RAM (not too many extra variables) and ideally really short. The calculator's flash space is filling up - the code so far has used up a few hundred bytes, which isn't too bad, but how much more is justified?

I actually think it's rather fun to type in a long base 9 number and watch the digits go crazy when too many have been entered! But that's just me, perhaps.

I'm about to upload r3919, which contains a couple of bugfixes. I'll continue to think about the problem - as I've said, it's easy to do it in the most commonly used bases, and perhaps that's enough.

Thank you so much for your feedback!

Nigel (UK)