It's a floating point with 128 bits of precision, a 16bit exponent (and a sign, obviously); aimed at accuracy rather than speed, and currently implemented in C# with a couple of AMD64-asm subroutines for things that C# is epically bad at (that's right, assembly in C# - I use VirtualAlloc and write the binary to executable mem, then use Marshal.GetDelegateForFunctionPointer).
There are no NaNs or Infinities, but there's no particular reason they couldn't be added (I'm just lazy)

What I have so far:

add
subtract
multiply
divide
relationals (< > <= >= == !=)
ceil
floor
truncate
modulo (using floor)
fast approximate 1/x (accurate to nothing, it just negates the exponent and complements the mantissa)
square root (assumed accurate to about 4ULP) CORDIC version and Babylonian
arctan (assumed accurate to about 4ULP - but very slow)
log (Taylor)
exp (Taylor)
pow (using log and exp)
sine (Taylor)
cosine (using sine)
tan (using sin and cos)
arcsine (using arctan)
arccos (using arctan)

What I'm planning:

sqrt (using log and exp) - nope
Print (I only have a base16 printing function now, useful for debugging but that's about it)

Any requests?

It would be interesting if you could port or wrap a math library like GMP for C#. Then you could take advantage of its support for arbitrary precision with assembly optimizations from C# programs.

GMP already has C# bindings

Oh my fail then, nice work on your library though.

Log(x) (base e) now works, but it takes 130 iterations in some cases (when many bits in x are set). An iteration does two multiplications and two divisions, so it's not exactly fast.

I normalize x to between 1 and 2, then I use the Taylor series for ln(1+x). The proper way - I sum negative and positive terms separately and "smallest first", then later add them together with the "exponent * ln(2)" term.
The problem is that x near 2 gives an x near 1 in the Taylor series, which therefore converges very slowly.
Does anyone know any better ways?

Edit: I just found a slow way to approximate about 120 bits of Log(x), but the lowest couple of bits are just nonsense. Also, it is slow.

Accuracy example:
sin(1)^ln(10) =
0.ac0aed97a80a79dfb02f7bb899a18284(my float lib)
0.ac0aed97a80a79dfb02f7bb899a18282 (wolfram alpha)
0.ac0aed97a62d03 (TI 84+)

Considering the big error-amplification there, the result is not bad IMO.

edit: accidentally used my fail-version of Log - fixed now

And the fail version was still only divergent in the last three digits instead of the last one; not bad at all! I'll be pedantic as I was on IRC and claim that this is actually a 156-bit number library, as the total size of sign, exponent, and mantissa is usually counted, not just the size of the mantissa.

Lol sure, but I called it "float with 128bit mantissa" here

156??
128+16 = 144

Even with another byte for the sign(s), I'd imagine it'd be only 152 bits, which is an even(?) 19 bytes.

Err, I meant 152. And he stated on IRC that he was not bothering with any sort of bitmasking, such that the sign was a full 8-bit byte. I in turn suggested he use some of those extra bits to represent NaN and Inf, since he said he currently doesn't have support for any special bit patterns to indicate those values.

Here's some sauce: nope.
And it's true, it won't compile, because SharpAsm is missing, but it could still be useful

Wow, C# looks a lot like Java! I had no idea. And very nice, I'll probably take a few more scans through that code.