6 comments

[ 3.0 ms ] story [ 27.5 ms ] thread
Maybe this community will be more interested/helpful? I'm REALLY trying to avoid the use of things like "BigDecimal" and just stick with word-sized values (int, uint, float, etc).
i dont quite 100% understand it, but if your aiming at one/few specific size fixed-point values, why not give the literal values and be done with it?
The function otherwise supports all values of T, so I need a way of calculating the larger values at runtime. The hard-coded values I have right now are for demonstration/performance purposes only.
> all values of T

which should be...? in my understanding, youll only have limited sizes up to 64 bits, maybe 128 bits. If you want higher precision than your processor bit architecture then youll be better off using BigInts anyway. If you want a replacement for BigInt calculations then plain straight say so

Due to the nature of C# math generics, it could theoretically be any size that is supported during runtime. If I add support for 512-bit integers to the language and implement the appropriate interface, then this function should "just work". It currently doesn't only due to the fact that I'm hard-coding the constants instead of calculating them. I do indeed want a replacement for "BigDecimal" in this specific context because we don't actually need to do arbitrary arithmetic, we need to be able to generate the digits of (1 - SQRT(0.5)) and then transform them.
right, im not a maths guy but id go for the BigInteger way, or if speed was paramount id build a lookup table for the expected values of T.

That link in your question also points to the algo for sqrt(x), should be possible to optimize for 1-sqrt(1/2) but as i said im not into maths