Am Fri, 14 Oct 2016 23:29:50 +0000 schrieb Bernd Paysan:
> Am Fri, 14 Oct 2016 18:05:30 +0100 schrieb Gerry Jackson:
>
>> On 13/10/2016 01:26, Bernd Paysan wrote:
>> gforth-0.7.9_20161006.exe fails 8 tests in SUBSTITUTE tests in file
>> stringtests.fth under Windows 10. IIRC they used to run on a previous
>> version Gforth 0.7.9_20160113
>>
>> Use the latest version of the tests:
>>
https://github.com/gerryjackson/forth2012-test-suite
>
> Yes, I really need to get around embedding all your new tests into the
> test suite Gforth runs automatically after build.
I started with your FP test, and I ran into problems pretty soon. First
of all, older glibcs fail on a few of the precise number conversions.
Second, the x87 coprocessor fails on the rounding tests, it is slightly
off.
I've identified these problems:
old glibc:
INCORRECT RESULT hex_t{ r8 2L@ -> 42c00000 00000002 }t
Actual result[0]=1
INCORRECT RESULT hex_t{ r8 2L@ -> 3fe00000 00000002 }t
Actual result[0]=1
INCORRECT RESULT hex_t{ r8 2L@ -> 404f44ab d5aa7ca4 }t
Actual result[0]=D5AA7CA3
INCORRECT RESULT hex_t{ r8 2L@ -> 3ff00000 00000001 }t
Actual result[0]=0
The "Actual result[i]=value" is a modification of ttester.fs I made to
make sure I can see what's going on right in the output, without having
to check interactively; sometimes that's impossible, e.g. on the Travis
setup.
And this is x86 (the "spoil financial calculation" defect only with old
glibc, so that is a number conversion problem):
Page: 6
Checking rounding on multiply, divide and add/subtract.
! F* is neither chopped nor correctly rounded.
! F/ is neither chopped nor correctly rounded.
! Addition/Subtraction neither rounds nor chops.
! Sticky bit used incorrectly or not at all.
! FLAW lack(s) of guard digits or failure(s) to correctly round or chop
(noted above) count as one flaw in the final tally below.
...
Test for sqrt monotonicity.
sqrt has passed a test for Monotonicity.
Testing whether sqrt is rounded or chopped.
! Square root is neither chopped nor correctly rounded.
! Observed errors run from -5.0000E-1 to 5.0000E-1 ulps.
Diagnosis resumes after milestone Number 90
...
This computed value is O.K.
Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.3891E0 as X -> 1.
! DEFECT Calculated 7.3891E0 for
! (1 + (-1.1102E-16 ) ^ (-1.8014E16 );
! differs from correct value by -3.4413E-9
! This much error may spoil financial
! calculations involving tiny interest rates.
Testing powers Z^Q at four nearly extreme values.
... no discrepancies found.
...
! DEFECTs discovered = 1
! FLAWs discovered = 1
! The arithmetic diagnosed may be Acceptable
! despite inconvenient Defects.
I modified the code so that flaws merely emit warnings, and won't cause a
fail, but the defects still flag it as failed, and I don't feel like
turning defects into a warning ;-).
On the other hand, running those tests already revealed two bugs in Gforth
(one in the dynamic code generator, and one in our ecvt_r replacement,
which couldn't handle denormals with sufficient accuracy).