wp34s / 16C Compatibility Items #2 and #3



#14

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


#15

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


#16

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


#17

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


#18

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.

#19

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.


#20

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.


#21

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


#22

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


#23

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

#24

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


#25

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


#26

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

Fixed in next build.


- Pauli

#27

These should be fixed in the next build.
I've probably broken other things in the process :-(

- Pauli


Possibly Related Threads...
Thread Author Replies Views Last Post
  Bought a 16C to compensate a little Eelco Rouw 23 3,786 12-07-2013, 01:26 PM
Last Post: Eelco Rouw
  9014B Sony Part Number Compatibility aj04062 0 476 11-08-2013, 05:59 AM
Last Post: aj04062
  Shiny new 16C! Keith Midson 7 1,300 10-27-2013, 02:22 AM
Last Post: Keith Midson
  Compatibility of new HP PRIME Cable Harold A Climer 8 1,458 10-13-2013, 01:14 PM
Last Post: Eric Smith
  HP10C series battery door compatibility? Bruce Larrabee 6 1,163 08-11-2013, 05:42 AM
Last Post: Bruce Larrabee
  Some random wish list items for the 43s Marcel Samek 18 2,379 07-11-2013, 05:35 PM
Last Post: Paul Dale
  HP-16C simulator fhub 12 1,767 06-30-2013, 10:14 PM
Last Post: Robert Prosperi
  Program for HP-16c... Leonid 9 1,392 06-07-2013, 08:51 PM
Last Post: David Hayden
  HP-17bII+ Solve Compatibility Issues Robert Prosperi 7 1,386 04-22-2013, 10:11 PM
Last Post: Gerson W. Barbosa
  [Clonix/NOV] NoV-64 backwards compatibility Doug (NYC) 0 480 01-20-2013, 11:21 AM
Last Post: Doug (NYC)

Forum Jump: