If you’ve bothered to get past the Subject of this post, you’re my guy.

I have to convert hex values to decimal values and it is not as easy as doing a hex(string) to accomplish this.

Apparently Hex 45C97800 converts to 6447 (according to ) and I’m tending to agree on the answer but my head is exploding on figuring out how to do this in Panorama. Certainly to someone out there, you can do this while patting your head, circling your stomach, and chewing bubble gum. Me? Not tonight.

Any friendly assist?

You would start with hex(string) just to make a number out of it. It wouldn’t be the right number, but it will be easier to parse than text.

theNumber = hex(string)

Next, you want to determine if it is positive or negative. Since this is “classic” Panorama “theNumber” will already have the right sign, but Panorama X would consider an 8 digit hex value to be positive regardless. To make it continue to work when it is ported to Pan X, you could use

theSign = ?(theNumber and hex("80000000"),-1,1)

Next, you want to isolate the exponent, and adjust for the offset.

theExponent = (theNumber and hex("7F800000"))\8388608 - 150

Then, you isolate the significand, including the hidden bit.

theMantissa = (theNumber and hex("7FFFFF")) or hex("800000")

and then you put them all together, with zero as a special case.

theNumber = ?(theNumber = 0, 0, theSign*theMantissa*2.00000^theExponent)

theNumber should now be a floating point number, which you can convert to decimal text in the usual ways, using str( or pattern(.

This doesn’t deal with some of the more exotic floats, like denormalized floats, or infinity or NaN, but I expect it will work with all the cases you need to deal with.

I make it 1,170,831,360. So 6.447 is nowhere near correct.

My Number Cruncher procedure (available from the Database Exchange) calculated it instantly.

As the title of this topic indicates, this is about a hexadecimal dump of a number in floating point format, not integer. This screen shot is from the web page Robert’s link points to.

I’m confused. What does Hex 45C97800 actually mean other than a number in radix 16? The decimal number 6447 is 192F in hex notation. How does that relate to Robert’s original number?

Each hex digit represents 4 binary bits. Hexadecimal is often used as a shorthand for binary, when you want to dump the contents of memory. This is a dump of the way 32 bit floating point numbers are stored. (Panorama’s floats are 64 bit.) The Wikipedia article gives a pretty detailed description of the various floating point formats.

For this particular format, the leading bit (bit 31) is the sign bit. The next 8 bits (bits 30 - 23) are the exponent, and the last 23 (bits 22 - 0) are the significand. There is also understood to be a one bit before the significand.

The value of a number depends on how it is encoded. Even an integer could be encoded in different formats, for example little endian vs. big endian. Or even the bit order could be reversed. In this case, the value is encoded as a floating point number using the format described on the page Robert originally provided the link for (kudos to Dave for the clever solution, btw, and I guess I’ll take a bow for the fact that Panorama can do this without resorting to an external programming language.)

Kudos all around. Dave is a brilliant fellow that is amazingly generous. James Cook knew the answer but just doesn’t type as fast as Dave. Jim Rea gave us the gift of Panorama.

I’ll be doing a lot of conversions. Question: Will creating a custom function be more efficient for Panorama to do the conversions, or will it just take less typing within a procedure to do the multistep calcs?
(I’ve never created a custom function.)

It wouldn’t be any more efficient for Panorama. As you say, it would take less typing, if you are doing it in more than one place. Less typing means fewer opportunities to commit a typo.

The wink and laugh is missing.

Realize this is straying a bit, but can Dave (or someone) explain Dave’s use of “and” in his solution, above? My understanding is that in Panorama the result of an “and” operation is either -1 (true) or 0 (false), but Dave’s procedure suggests “and” is doing a bit level combination of the two operands, or something else more complicated?

Yes, the and operator is a bit level operation, and always has been.

The result of comparison operators like =, >, <, etc. is -1 (true) or 0 (false). Since -1 is a value with all bits set to 1, the and operator works just fine for boolean logic. But as in this example, it can be used for bit level and operations (and the same goes for or and xor).

The same also goes for the not operator, which I believe is the main reason why comparison operations return -1 to mean true. Any non-zero value is considered true, but if you apply the not operator to a mixture of ones and zeros, you just get a different mixture of zeros and ones. In order for not true() to be 0 (false), true() has to be -1. 1 and 1 is 1, so letting true be 1 would work with the and operator, but not 1 would be -2, and that would not work.

Cool! Thanks both of you! That one doesn’t get the sense of bit level manipulation in the help file entry for ‘and’ leads one to suspect this is an under-the-hood aspect of the Panorama logical operators is not actually documented?