thethirdone / jsoftfloat Goto Github PK

Division, SquareRoot and Logarithm are more difficult than addition and multiplication because they can result in infinite digits. The simple algorithm for long division gives a simple way to find the answer up to x digits though. Squareroot can also be found exactly up to x digits by using the bisection method (works particularly well for binary floats). But logarithm is slightly harder to get the precise answer up to ``x` digits because there isn't an exact exponential function either. This means that in order to get the correct rounding, more sophisticated error bounding is needed.

Typically this is done with Newton-Raphson iteration and precomputed tables, and continuing until the error is between floating-point values. I would like to keep the code simpler than anything more complex than what I can understand directly from reading the code though. One of the goals of this project is to have a readable, correct floating-point implementation; using more complex algorithms runs counter to that goal.

I'm not sure how to proceed. I will probably just work on other things until I get an idea (it worked for sqrt).

I'm trying to install RARS assembler to an offline machine. I get jsoftload package does not exist when I run build-jar.sh. So I extracted jsoftload source to my machine bu I still get this error.

small should round to 0 or Float32(1) depending on rounding mode, but it always goes to 0.

        ExactFloat small = new Float32(1).toExactFloat();
        small = small.divide(new ExactFloat(BigInteger.valueOf(4)),4);

I also believe, when divided by 2, this doesn't trigger underflow.

This code produces actual zero when computes 1*1+0 by fmadd.d fa0, ft1, ft2, ft0:

	li		t1 1
	fcvt.d.w	ft2, t1
	fcvt.d.w	ft1, t1
	fcvt.d.w	ft0, zero
	fmadd.d		fa0, ft2, ft1, ft0

The result is 0 in fa0 instead of 1

The problem is here. Perhaps, here must be not ||, but &&?

The simplest case I could create which shows this is F32(0x43c0a000) + F32(0x0000476e) which should equal F32(0x006B7E4A), but instead equals F32(0x00EB7E4A).

The key seems to be the lowest exponent bit is set erroneously. The extra details in both numbers seem to be important, but its not clear yet how.

There are several issues related to addition near the the subnormal boundary, the answer correctly given is clearly wrong and there has to be an off by one or something in the exact conversion (has to be an a weird issue as it has been completely tested for to exact and back) or addition code (not as well tested) .

For example, F32(0x00F00000) + F32(0x00100000) should equal F32(0x01000000), but instead equals F32(0x00F80000)

This shouldn't be a super hard bug to track down, but I'm not going to be able to fix it immediately.