conversion from unsigned and signed 8/16/32/64 integers to
FP16, FP32 and FP64 are all needed.
>>> from sfpy import Float16, Float32
>>> y = Float16(10)
(In reply to Luke Kenneth Casson Leighton from comment #1)
> >>> from sfpy import Float16, Float32
> >>> y = Float16(10)
> >>> y
that looks correct to me, docs for convenience:
"""Given an int, create a Float16 from the bitpattern represented by
that int. Otherwise, given some value, create a Float16 by rounding
*smacks-forehead* - of course. i forgot about that, was looking
for a way to do int-to-float conversion.
am going to modify sfpy (created the repo on git.libre-riscv.org
already) to expose the i32_to_f16 (etc) functions from sfpy.float.
Created attachment 18 [details]
patch to sfpy to add int-fp conversion routines
added support for larger uint down to smaller FP, this is likely
to be uint32 or uint64 down to FP16, however uint64 to FP32 would
hit the reduction point as well.
seems to be ok - currently running through 20,000 tests on each of
for testing u16/i16/f16 as inputs, it may be better to go through all cases, since there aren't that many
(In reply to Jacob Lifshay from comment #6)
> for testing u16/i16/f16 as inputs, it may be better to go through all cases,
> since there aren't that many
yeh that sounds sensible. presently i am doing only 17 bit random on uint32/64 to fp16, otherwise the probability of generating numbers that fit within range is.. well... negligeable. everything gets converted to INF.
full coverage is a good idea, and achievable.
first example usage of the new FPPipeContext "operator". it's pretty
basic: no "tidiness" class that helps actually identify it as such,
it's just straight "set op_wid=1" then:
# start doing signed decode
# start doing unsigned decode
pretty basic, and i can confirm that the ctx.op, like ctx.muxid, is
properly passed down the pipeline chain.
i might just add in a completely new class, just to see if that also works
preliminary run on signed-to-FP works, i'll do some more comprehensive
unit tests, now.
int32 and uint32 -> fp32 done - a bit of weirdness detected, however
it works. ran enough tests here to consider this one "done".