16C - CHS not changing "0" to "-0" when in 1's complement mode.

[meltdown03]

JRPN 16C or 15C? 16C

Describe the bug You should be able to change the sign of a 0 when in 1's complement mode, but currently it does nothing.

To Reproduce Tell me a bit about how to reproduce the problem. This is especially important if you don't have a debug log! DEC F > 1's 0 > CHS BIN shows 0 b

Expected behavior The 0 should change to a negative (-0) after hitting CHS when in 1's mode, and the BIN value should be all 1's

Platform: Linux and Android, build from master branch repo source

Additional context A small thing that's probably a huge pain to fix!

[zathras]

First of all, hats off to you for actually using 1's complement! I remember it being pretty obscure back when the 16C came out, and it's hardly become more popular since then. I have to ask: What prompted you to notice this?

Next, are you sure the real 16C did this? I bet it did, and even if it didn't I'd be happy to implement it. But I like to keep track of any divergences from the real 16C, and I don't have one; if you do, a quick check would be appreciated.

I don't think it will be hard to fix - at most, a couple of lines of code special-casing this bit of 1's complement weirdness. Dealing with this sort of obscure stuff is one of the fun parts of doing a calculator simulator! It might be as much as a few weeks before I really take a look, though... At the moment, I'm experiencing the joy of being an executor, so my life is filled with medallion signature guarantees and the like.

[meltdown03]

I was looking at the CHS bug that afflicts some of the HP calculators. https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv016.cgi?read=107829 I didn't realize that it really only happens in FLOAT mode, so I was trying all the modes on my real device and all the emulators. So basically, dumb luck!

On Thu, Mar 14, 2024, 7:36 AM Bill Foote @.***> wrote:

First of all, hats off to you for actually using 1's complement! I remember it being pretty obscure back when the 16C came out, and it's hardly become more popular since then. I have to ask: What prompted you to notice this?

Next, are you sure the real 16C did this? I bet it did, and even if it didn't I'd be happy to implement it. But I like to keep track of any divergences from the real 16C, and I don't have one; if you do, a quick check would be appreciated.

I don't think it will be hard to fix - at most, a couple of lines of code special-casing this bit of 1's complement weirdness. Dealing with this sort of obscure stuff is one of the fun parts of doing a calculator simulator! It might be as much as a few weeks before I really take a look, though... At the moment, I'm experiencing the joy of being an executor, so my life is filled with medallion signature guarantees and the like.

— Reply to this email directly, view it on GitHub https://github.com/zathras/jrpn/issues/85#issuecomment-1997357236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPBQCDB3M7NRDQAEHPMODTYYGKVTAVCNFSM6AAAAABEVKC6DOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXGM2TOMRTGY . You are receiving this because you authored the thread.Message ID: @.***>

[whuyse]

Permit me to reply ;-) I have verified on a 15CE turned to 16C mode (with HEX bug corrected btw), which should be the same, and it is exactly as meltdown described.

[zathras]

It was just a matter of deleting a test to special-case 0 - see the putback just above. From the comment, it looks like I had investigated this behavior, probably by testing the behavior of another simulator (since I don't have a real 16C), and I intentionally special-cased +0 to stick at +0. I guess that other simulator had the (undesirable?) behavior where +0 CHS stuck at +0.

I just re-read the relevant section of the user's guide, and it does say (on page 30) that CHS "complements all bits," and it doesn't mention a special case for 0, so that agrees with this fix.

[zathras]

Published in 2.1.12