zeda / z80float Goto Github PK

There should be conversion routines for the 24-bit floats (f24). I think maybe:

• f24 <== string
• f24 ==> single ("single" being this lbrary's bastardized format)
• f24 <==> binary32
• f24 <==> binary16
• f24 <==> u8
• f24 <==> u16
• f24 <==> i8
• f24 <==> i16

f24/f24cos.z80 says cos(0)==0 in the comments. But cos(0)=1

xsqrt returns the wrong value for sqrt(2^32-1) for example. The expected significand is
0xFFFFFFFF80000000. The calculated significand is 0xFFFF7FFF5FFFAFFF.

I'm not up for debugging this right now, but I suspect that it is an issue with sqrt32.

The way geometric mean (sqrt(x*y)) and arithmetic mean (a+b)/2 is implemented in this library will erroneously cause overflow with some range of inputs. Neither geometric mean nor arithmetic mean (geomean and amean in this library) should overflow except when one or more arguments is +inf or -inf.

Because these are used to compute the Borchardt-Gauss mean, which is used for natural logarithm and inverse trig and inverse hyperbolics and other routines, all of these will erroneously result in overflow for some range of inputs.

As such, this is an important set of bugs to fix.

Ideas:

For amean, if the exponent of either input is close to the maximum, subtract 1 from both exponents, then add the inputs. Otherwise, add the inputs, then subtract 1 from the result exponent. Note: If we go with the first method for all inputs, then we will have erroneous underflow issues.

For geometric mean, it is a bit more complicated. You could compute it as sqrt(x)*sqrt(y), but that erroneously returns NaN if both inputs are negative. It also costs an extra square root.

I think the easiest method is to wrap the existing geomean code in a routine that calculates the output exponent, then sets input exponents to either 0 or 1 as needed.
Basically, if e1 and e2 are the respective exponents, then first do (e1+e2)>>1 → etemp. Set e1 to the carry from computing etemp (so 0 or 1) and e2 to 0. Now compute the product, then the square root, then add etemp to the exponent.

Another method that I contemplated a few years ago here might be useful for the lower-precision floats, but that'll require some investigation.

$ ./single.py -inf +inf 3.4028236e+38 3.4028235e+38 3.4028237e+38 NaN
.db $FF,$FF,$FF,$00  ;-inf /* Ooops!!! */
.db $FF,$FF,$7F,$00  ;+inf /* Ooops!!! */
.db $00,$00,$00,$00  ;3.4028236e+38 /* Ooops!!! */
.db $FF,$FF,$7F,$FF  ;3.4028235e+38
.db $FF,$FF,$7F,$00  ;3.4028237e+38 /* Ooops!!! */
Traceback (most recent call last):
  File "./single.py", line 59, in <module>
    print(dbify(tofloat(i))+"  ;"+i)
  File "./single.py", line 37, in tofloat
    a=int(x)
ValueError: cannot convert float NaN to integer

From manual:

The mantissa requires the top three bits to contain specific values:

    +0 is represented as 0x00
    -0 is represented as 0x80
    +inf is represented as 0x40
    -inf is represented as 0xC0
    NaN is represented as 0x20

;Power of 10 is stored in B, need to put in A first
xor a
sub b
ld de,pow10table+120
jp p,+_

doesn't work with numbers like 1e-2.
This works for me ("calc" in NedoOS):

;Power of 10 is stored in BC, need to put in A first
xor a
or b
ld de,pow10table+120
jp p,+_

Higher priority

• f32toa - Convert an f32 float to a string to be displayed.
  • Currently this is emulated by converting the f32 to a "single" and then using singletostr to convert to a string. This means that the f32 library requires mulSingle and the single constants instead of using the already available f32mul and f32 constants.
• atof32 - convert a string to an f32 float.

Integer conversions

• f32toi8
• i8tof32
• f32toi16
• i16tof32
• f32tou8
• u8tof32
• f32tou16
• u16tof32

Conversions between floats

• f32tosingle
• singletof32
• f32tof24
• f24tof32
• f32tof16
• f16tof32
• f32tox
• xtof32
• f32tof64
• f64tof32
• f32toTIFloat
• TIFloattof32