[libre-riscv-dev] bug in sfpy on FP16 integer initialisation

Bill Zorn bill.zorn at gmail.com
Wed Jul 17 11:37:07 BST 2019

I'm glad you're having success with the library, and I'm glad you figured
this out. I guess I'll have to be very careful not to break anything in the
softfloat bindings when I update to the latest softposit library, which I
should do soon :)

Out of curiosity - what do you need int to float conversion for,
specifically? I left the softfloat 'C-style' int to float conversion
functions out of the bindings deliberately, because they don't really make
a lot of sense in Python. an int32 is a terrible datatype for holding the
value of a float32, since it only covers a tiny portion of the dynamic
range (i.e. most large magnitude floats, which are actually integers,
aren't int32s because they would overflow).

Since this is all in Python, where integers can be really big, and the
supported softfloat datatypes are all no larger than doubles, it made the
most sense to me to do any int to float conversions at the Python level
rather than in C. So if you have a Python integer (call it a) that you want
to convert to a Float16 by value, I would just have written:


where the float(a) call in Python will actually convert the (potentially
really big) Python integer to a Python double under the hood. Of course,
this might have problems with double rounding, but then again so does
everything, because sfpy's constructors always convert to a double first
and then make a second cast down to the smaller types. A proper conversion
from arbitrary numbers or number-like representations to correctly rounded
floating-point values is very difficult to build and a bit beyond the scope
of the library.

As you found out the hard way, sfpy is designed to be fast and convenient
for dealing with the binary representations of floats, not so much with
their real values. That said, if there is a particular functionality you
need, I'd be happy to add it to the library.

On Wed, Jul 17, 2019 at 1:19 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>

> all good.

More information about the libre-riscv-dev mailing list