Elementary testbed
==================

Common notes
------------
You will need
  crlibm (https://gforge.inria.fr/anonscm/git/metalibm/crlibm.git)
  VFPSupport with VFPSupport_ElementaryFunctions
  FPEmulator (any)

It's not practical to exercise all 2^64 possible inputs for each of the double precision transcendental functions, and even 2^32 inputs at single
precision would take a long time. In addition there are 2 argument transcendentals such as atan2 compounding the problem to up to 2^128 inputs.

Instead, take the view that we want to exercise the dynamic range of the float or double for normalised inputs, then check for exceptional values.
Aim for around 1M tests so the results file isn't too unwieldy.

Compare the results with other contemporary implementations. By comparing with one of the "correctly rounded" implementations we can get a figure for
the number of ulp (unit in the last place) bits of error we have.

Producing the correct answers
-----------------------------
To make some "golden" reference values, we use crlibm.
Copy the TestBed.c TestTable.c and CRVeneer.c into your crlibm directory, edit TestBed.c
as appropriate to CALL_CRLIBM and type

  gcc -o MyTests TestBed.c CRVeneer.c libcrlibm.a
  ./MyTests

this will run in "recording" mode and output a set of test result files. Copy these back to the RISC OS test system and edit TestBed.c again to select either the VFP or FPA copies to compare against.

Exceptional cases
-----------------
After the dynamic range result checker is the exception checker.
The aim of this is to ensure the right exception(s) are raised as called out in the C standard, which we use as a reference. Other exceptions may be raised but these aren't checked, only those that must be raised.

In addition a few unexceptional specific cases of pow() and atan2() are checked. This is more convenient than defining lots of ranges-of-1 results recordings when we only want to do a few spot checks. In that sense they are exceptional cases, they just don't raise exceptions.
