Replacement for snprintf

[H. S. Teoh]

On Wed, Oct 30, 2019 at 07:28:44PM +0000, berni44 via Digitalmars-d wrote:
> On Wednesday, 30 October 2019 at 18:16:56 UTC, Rumbu wrote:
> > That means that snprintf must use the current rounding mode that can
> > be read using FloatingPointControl.rounding from std.math.
> 
> Is it really a "must"? We are not completely bound by the IEEE
> standard and, if good reasons are available, might reject it. For
> example, comparing two floats with <= produces either "false" or
> "true" in D. According to IEEE there should be a third result
> possible, namly "not comparable".

For non-comparable floats x and y (i.e., at least one is a NaN), D has
the semantics:

	x < y		false
	x <= y		false
	x >= y		false
	x > y		false
	x == y		false
	x != y		true

D used to have other comparison operators that handle various
NaN-related subtleties (the so-called "spaceship operators" because of
their alien appearance), but they were deprecated because nobody
understood them so nobody used them.

Having said that, though, I think we should try to conform to IEEE as
much as possible, and there better be very good reasons when we don't.


> Having said this, it would be possible to implement it the way you
> claim, but probably at some cost (=slower, more and less easy readable
> lines of code). I'll think about it.

As I have said, floating-point formatting is far from the trivial affair
that it appears to be on the surface.  It's not something to be
undertaken lightly, because it's full of complicated corner cases that
must be handled correctly.


T

-- 
Never wrestle a pig. You both get covered in mud, and the pig likes it.