Add Decimal64 basics #5
Conversation
…cimal-basic-setup-and-parsing
…umberToFloatingPointBits.cs copy
…sing Ieee decimal basic setup and parsing
Organize and Cleanup
|
This commit: 7cbca98 is the only real "new" thing compared to the Decimal32 PR. I grouped all logic updates in this one commit to make reviewing easier. |
| IMinMaxValue<Decimal64> | ||
| { | ||
|
|
||
| private const NumberStyles DefaultParseStyle = NumberStyles.Float | NumberStyles.AllowThousands; // TODO is this correct? |
| // c. Trailing significand. Can be used to encode a payload, to distinguish different NaNs. | ||
| // Note: Canonical NaN has G6-G12 as 0 and the encoding of the payload also canonical. | ||
|
|
||
| private const ulong QNanBits = 0x7C00_0000_0000_0000; // TODO I used a "positive" NaN here, should it be negative? |
There was a problem hiding this comment.
I'd probably keep it as positive for the "bit mask"
But we should probably return -QNaN for the "canonincal" version, so it matches what happens for the binary QNaN
There was a problem hiding this comment.
Sounds good, although I'm curious how we arrived at that decision. I think the intel library has positive QNaN as their "canonical" NaN, for example, this early return in bid64_add:
Despite this, is it still reasonable to return -QNaN for cases like this?
There was a problem hiding this comment.
Because x86 hardware returns -QNaN for binary floats in hardware, so it's been the historical "norm" that people see
|
@tannergooding I updated most of the |
|
I was planning on doing the same strategy for |
This PR should include everything from #4 but with additions for Decimal64. I'll be pivoting to Decimal64 development from here forward.