🚀 go-pugleaf

In article <3vp60e$o8c@solutions.solon.com>,
seebs@solutions.solon.com (Peter Seebach) wrote:
>In article <3vnqah$1ev@news.cs.tu-berlin.de>,
>Markus Freericks <mfx@cs.tu-berlin.de> wrote:
>>A function that determines the intersection between two line segments,
>>determined by four float arguments (two points) each, returning an enum
>>flag (no intersection / one point intersection / line segment intersection)
>>and four float results, of which either none, two, or all four are
>>defined.
>
>Hmm.  I guess, my advice would be to define that the "irrelevant" values
>are returned as zero.
>
>I think we're disagreeing about the use of "undefined".  The use of
>an uninitialized float is undefined behavior, right?  So, are you
>advocating undefined behavior as part of the normal functioning of the
>routine?  I can see "I don't care what value goes here", I can't see
>"I want this undefined".

The term "undefined" is relative to a specific interface.  Most of the
discussion here is in terms of Standard C, so undefined means
undefined in Standard C.  When I implement a function, I specify the
interface, which may have undefined aspects, such as what specific
values are returned in cases that the return value is logically
irrelevant.  Intersection coordinates, in the case that there is no
intersection, is a good example where an undefined return value makes
sense.

Within the implementation of the function the actual return value may
be known, but have no direct relevance to the stated function.  It is
better left as undefined in the stated interface so that
1)  the implementation can be changed without changing the interface
specification,
2)  the specification isn't cluttered with happenstance.

With regard to returning the value 0 when it is logically undefined,
how about, in the implementations that support it, return a NaN, so
that attempts to use it become really obvious?

Thad