Hi,

As I have been continuing through the HP16C manual, exercising the examples with the wp34s (currently with version 843), two additional items were encountered:

1. Pages 40-41 discuss the Out-of-Range flag with respect to the arithmetic operations, and it mentions that "when a result is out-of-range, the lower bits ...of the full answer will be returned. If the operations was multiply or divide in 1's or 2's Compliment mode, the most significant bit (sign bit) returned will match the sign bit of the full answer." At the top of page 41 is an example where with 2's compliment mode and word size 16, the decimal number 32767 is entered, followed by [2] [multiply] and the result on the 16C is decimal 32766 with the out-of-range flag set. On the wp34s, the result displayed is "-2" decimal. This would represent the entire lower 16 bits of the result (65534), had the word size been large enough to hold the entire result. It would seem important to me to preserve the sign of the result, like in the 16C.

2. In this same section, there is discussion of the absolute value function (ABS). It appears, however, that ABS does not apply to integers in the 34s, both from trying it out and from reading the manual's Index of Operations. Would it be possible to extend ABS to be relevant to integers as well?

Thanks,

Jake

Hi Jake,

Thanks for testing. Again, both calculators obviously do not match. I agree on ABS should work for integers, too, unless in UNSIGN. Our software maintenance division is asleep now, however, so I ask for your patience.

Walter

Is there any reason the absolute value shouldn't work in unsigned mode as well? I should think the implementation would be quite simple.

By definition, the unsigned mode uses all bits for the mantissa and *none* for the sign. So there can't be negative numbers ...

Quote:

Our software maintenance division is asleep now, however, so I ask for your patience.

Not a problem at all. I thought I'd simply mention the findings as they are found.

As you've probably already seen: If you are using the hardware port, please update. I had to fix some nasty bugs in the last few days.

As for ABS in integer unsigned mode: If it doesn't through an error, everything is fine as ABS is a NOP here. I agree that in the signed modes, ABS should be implemented.

Quote:

By definition, the unsigned mode uses all bits for the mantissa and *none* for the sign. So there can't be negative numbers ...

Exactly. The absolute value should leave the number unchanged. It should not give an error, or the number of steps needed by Ulam's conjecture to reach one, or any other number.

I'm confused. ABS is implemented for integers and I just checked it on my 30b and it appears to work fine.

The minus sign is shown way off to the left in base ten only. The base ten only part is correct, the sign placement is silly & I'll see about a fix.

Fixing the sign problem will be more involved. The basic arithmetic operations work a bit differently to most others in the way they handle the numbers -- needed for overflow and carry computation without resorting to assembly.

- Pauli

These should be fixed in the next build.

I've probably broken other things in the process :-(

- Pauli

Hi Pauli,

Quote:

I'm confused. ABS is implemented for integers and I just checked it on my 30b and it appears to work fine.

I was working with the reflashed 30b at my work before and I am now trying it on my reflashed 20b at home. It appears to work with 1's compliment mode, but not 2's compliment mode. For instance, in 1's compliment mode with WSIZE at 16 bits and base decimal, if you enter 252 +/- ENTER, then |x| changes the sign from negative to positive. Now change it to 2's compliment mode and re-enter 252 +/- and press |x| and the sign does not change to positive.

Thanks,

Jake

Found the problem. It worked for some values but not most.

Fixed in next build.

- Pauli

Should ABS be a NOP? Shouldn't it set LASTx?

It sets last x.

It also terminates digit entry and sets stack lift.

i.e. all the usual things you'd expect of a single value single answer function.

- Pauli

I still have to learn a lot about RPN. ;-)