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

[Bill Zorn]

Yes, I suppose if you have some (HW or otherwise) implementation if IEEE
754, and you want to make sure it does exactly the same thing as softfloat
3, then you would want softfloat 3's actual integer conversion routines.
That is a strong argument for me to add that functionality to the
interface, even if it's not on the "usual" path that someone would use to
construct a float with the value of some Python integer they happened to
have.The worst the Python wrappings should be able to do for those
functions is tell you that your integer doesn't fit in an int32, if you
somehow manage to screw that up.

Out of curiosity, will you also eventually want the 80-bit or 128-bit
types? Or can I go to sleep without having to worry about how I would try
to get their values into and out of strings?


On Wed, Jul 17, 2019 at 4:00 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Wed, Jul 17, 2019 at 11:37 AM Bill Zorn <bill.zorn at gmail.com> wrote:
> >
> > I'm glad you're having success with the library, and I'm glad you
> figured this out.
>
> aww i really wanted to find a youtube clip of B.O.B from Monsters v
> Aliens, saying "i may not have a brain, gentleman..."   ah ha!
>  https://getyarn.io/yarn-clip/da358bd0-d32b-479d-ab7b-c409ce6fe1cd
>
> :)
>
> > 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 :)
>
> we're not so concerned about posit (luckily)
>
> > Out of curiosity - what do you need int to float conversion for,
> specifically?
>
> basically what we're doing is developing a hardware IEEE754 unit (and
> using sfpy to confirm that it's correct).  therefore, anything that a
> hardware IEEE754 FPU is expected to have, *we* have to have, and
> therefore need to test it.
>
> > 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.
>
>  it doesn't matter: it's the accurate (convenient) access to the
> softfloat-3 functionality that we need, rather than any particular
> "pythonic" behaviour.
>
> > 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).
>
>  doesn't matter, because we expect the integer values to be verbatim
> untouched as they pass through softfloat.
>
>  what we're testing is that our hardware IEEE754 FPU throws the
> *exact* same exceptions, has the *exact* same Inf and NaN values, and
> so on, as softfloat.
>
>
> > 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:
> >
> > Float16(float(a))
>
>  yeh.  this would lose the corner-cases, through the python conversion
> getting in the way.  we *really* need the absolute direct unaltered
> access to softfloat-3.  if there's *any* interference by actual
> "python", modifying or not providing the binary representations (or a
> direct equivalent of them), we have a problem.
>
>  so this is why passing in a python int (and having it be converted
> behind the scenes to an int16, uint32 or whatever) is ok, but having
> *python* perform the conversion from int to float is absolutely out of
> the question.
>
>
> > 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.
>
>  my brain thoroughly melted a few hours ago.  i've been using that
> exact functionality for months: inputting the binary representation of
> floats, performing sfpy add/mul/div, getting the result back (as a
> binary representation) then comparing it against the equivalent
> IEEE754 hardware simulation.
>
>
> > That said, if there is a particular functionality you need, I'd be happy
> to add it to the library.
>
>  that'd be fantastic.  one thing that we will need, some time in the
> next few months, is the option to build the "tininess" selection, when
> building softfloat-3 for RISC-V interoperability.
>
>      #
> /*----------------------------------------------------------------------------
>      # | Software floating-point underflow tininess-detection mode.
>      #
> *----------------------------------------------------------------------------*/
> -    # extern uint_fast8_t softfloat_detectTininess; # THREAD_LOCAL
> -    # cdef enum:
> -    #     softfloat_tininess_beforeRounding = 0
> -    #     softfloat_tininess_afterRounding  = 1
> +    extern uint_fast8_t softfloat_detectTininess; # THREAD_LOCAL
> +    cdef enum:
> +        softfloat_tininess_beforeRounding = 0
> +        softfloat_tininess_afterRounding  = 1
>
> many thanks, bill.
>
> l.
>