# HP Forums

Full Version: Odd HP65 OCT to DEC behaviour
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Just fiddling with my beautifully restored HP65 and found something odd. I don't think it affects any other calculators, but it might. The HP16C just simply prevents the digits 8 and 9 from being entered in octal mode so the problem never arises. The HP41CV DEC function throws a "DATA ERROR" if a non-octal digit is present in the input parameter.

But on the HP65 ...

Type 8 f-1 ->OCT and nothing happens as you'd expect since 8 is not a legal digit in octal. Same happens for 9. ( Actually, this makes perfect sense in light of the following. )

However, typing 80 f-1 ->OCT it displays 64! Convert that back to octal by typing f ->OCT and you get 100. Weird. Looks like 8 is handled like a decimal 8 for the purpose of converting from octal to decimal, so it treats it like 8 times 8^1.

Same for 800, f-1 ->OCT displays 512, which converted back to octal displays 1000. Equals 8 times 8^2.

Similarly, for 90, f-1 ->OCT displays 72, which converted back to octal displays 110. Equals 9 times 8^1. Etc ...

Dunno if I'd go as far as to call it a bug, just an interesting way to deal with non-octal digits when converting from octal to decimal. It was probably a choice of doing it this way or displaying a flashing error condition. And nobody likes an error.
Hi Steve,

The owners manual says, "As an additional feature, the “octal to decimal” conversion will accept non-octal arguments containing the digits 8 or 9. A non-octal number such as 998 will be interpreted as (9 × 8^2) + (9 × 8) + 8 = 656".
(09-06-2019 07:51 AM)Greg Wrote: [ -> ]Hi Steve,

The owners manual says, "As an additional feature, the “octal to decimal” conversion will accept non-octal arguments containing the digits 8 or 9. A non-octal number such as 998 will be interpreted as (9 × 8^2) + (9 × 8) + 8 = 656".

So, it's not a bug, it's a FEATURE! B-)

Thanks for that, I have the machine but not the owners manual ( in paper form ).
Yes, this has been discussed before in the forum. A great example of a true "bug" that became a "feature."
Sounds more like "validating your nonsensical inputs isn't worth the required space in ROM" to me.

Do D.MS+ and f-1 ->D.MS do similarly odd things if you feed in 60 or more minutes or seconds?
(09-06-2019 10:13 PM)Dave Britten Wrote: [ -> ]Sounds more like "validating your nonsensical inputs isn't worth the required space in ROM" to me.

Do D.MS+ and f-1 ->D.MS do similarly odd things if you feed in 60 or more minutes or seconds?

90 Hr + 1Hr 75min = 92Hr 15min
90.0000 ENTER 1.7500 D.MS+ 92.1500

1Hr 75min = 2Hr 15min

1.7500 F-1 D.MS-> 2.2500
2.2500 F D.MS-> 2.15

cheers

Tony
(09-07-2019 12:11 AM)teenix Wrote: [ -> ]
(09-06-2019 10:13 PM)Dave Britten Wrote: [ -> ]Sounds more like "validating your nonsensical inputs isn't worth the required space in ROM" to me.

Do D.MS+ and f-1 ->D.MS do similarly odd things if you feed in 60 or more minutes or seconds?

90 Hr + 1Hr 75min = 92Hr 15min
90.0000 ENTER 1.7500 D.MS+ 92.1500

1Hr 75min = 2Hr 15min

1.7500 F-1 D.MS-> 2.2500
2.2500 F D.MS-> 2.15

cheers

Tony

Yup, so it's the same thing then, just applied to sexagesimal instead of octal.
(09-07-2019 12:11 AM)teenix Wrote: [ -> ]
(09-06-2019 10:13 PM)Dave Britten Wrote: [ -> ]Sounds more like "validating your nonsensical inputs isn't worth the required space in ROM" to me.

Do D.MS+ and f-1 ->D.MS do similarly odd things if you feed in 60 or more minutes or seconds?

90 Hr + 1Hr 75min = 92Hr 15min
90.0000 ENTER 1.7500 D.MS+ 92.1500

1Hr 75min = 2Hr 15min

1.7500 F-1 D.MS-> 2.2500
2.2500 F D.MS-> 2.15

cheers

Tony

(09-07-2019 01:07 AM)Thomas Okken Wrote: [ -> ]
(09-07-2019 12:11 AM)teenix Wrote: [ -> ]90 Hr + 1Hr 75min = 92Hr 15min
90.0000 ENTER 1.7500 D.MS+ 92.1500

1Hr 75min = 2Hr 15min

1.7500 F-1 D.MS-> 2.2500
2.2500 F D.MS-> 2.15

cheers

Tony