Richard D. Moores wrote:
On Wed, Dec 16, 2009 at 20:23, Dave Angel <[email protected]> wrote:
Richard D. Moores wrote:
There are conceivably better ways to get at the mantissa of the fp number,
but you can simply parse the hex digits as I did manually, and add one and
subtract one from the given mantissa (the part between the decimal point
and the 'p'). Then it just remains to figure out which two of those three
values actually span the desired value.
Using the numbers and strings you supply, the three values would be:
0x1.bd70a3d70a3d6p-2
0x1.bd70a3d70a3d7p-2
0x1.bd70a3d70a3d8p-2
and the second one is somewhat less than .435, while the 3rd is more.
Now, while this is good enough to do by hand, you have to realize there are
some places it may not work, and another where it won't.
Dave,
I was hoping to find a way to NOT do it by hand, for the simple cases
such as 0x1.bd70a3d70a3d7p-2 . I'm weak on hex arithmetic. For these
simple cases, is there a general way to "add" something to the last
digit of a hex value to bump it up and down by 1? After I can do that,
I'll try to deal with the cases you mention below.
Dick
I'm not sure whether trailing zeroes are always provided in the hex()
method. So you may have to pad it out before adjusting the last digit. I'm
also not positive how it normalizes the hex value printed out. As the
example in the help indicates, there are more than one hex string that can
be converted to the same float - if you denormalize, it'll still convert it.
I just don't know if hex() ever produces a non-normalized value.
More drastically, if you're trying to be complete, is the infinities, the
NAN values, and the numbers, *very* close to zero, where gradual underflow
takes effect. The notion here is that when the exponent gets as negative as
it can safely store, the standard requires that the number be stored
denormalized, rather than going immediately to zero. I don't know how those
values are represented by the hex() method, but they have fewer significant
digits, so the adjustment you would need would be in a different column.
If I had to write a function to do what you ask, and if I couldn't get
better specs as to what Python is actually doing with the hex() method, I'd
work out an algorithm where tweak what seems to be the bottom digit, then
see if the float has a new value. If it does not, I'm working on the wrong
column.
DaveA
Try the following in Python 3.1:
def increment(floatval, incr=1):
#Given a float of "reasonable" size, increment it by smallest amount
# and if incr is -1, then decrement
stringval = floatval.hex()
mantissa, exponent = stringval.split("p")
mantissa = mantissa.replace(".", "") #ignore the period
mantissa = hex(int(mantissa, 16) + incr)
newstringval = mantissa[:3] + "." + mantissa[3:] + "p" + exponent
newfloatval = float.fromhex(newstringval)
#print(floatval, newstringval, newfloatval)
return newfloatval
You can specify an increment of +1 or -1, but larger values also work
just as well. From limited testing, this works for any positive values
that aren't in the gradual underflow range.
The parsing and reassembly of the mantissa and exponent are pretty
sloppy, but maybe they are even correct, for the output of the hex() method.
DaveA
_______________________________________________
Tutor maillist - [email protected]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
