[Tutor] Need a better name for this function

[Dave Angel]

Richard D. Moores wrote:
> On Wed, Dec 16, 2009 at 20:23, Dave Angel <davea at ieee.org> 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