Implementation of functions in math.h on clc-wiki

[Netocrat]

On Sun, 12 Mar 2006 07:13:47 +0000, Jordan Abel wrote:
[re pages deleted from clc-wiki.net due to copyright infringement claims;
sci.math dropped from headers]

Deleting my stdio.h, which was created after this controversy [and given
that I don't even have a copy of TSCL], seems a bit overzealous.

Yes, a little trigger-happy. I've restored it.

 

[Richard Heathfield]

Jordan Abel said:

Keep in mind that it is a wiki, and anyone can contribute.

Even P J Plauger. And since he's now closely monitoring it, he might just
start doing that.

(It's an ill wind...)

 

[Richard Heathfield]

P.J. Plauger said:

Read what I said again.

Sure. Here we go...

"At a quick glance, I'd say you're violating my copyright in the most
blatant and irresponsible manner. If the infringing stuff isn't off the
internet in short order, I will be taking legal action."

I'm giving him a chance, but I make no bones
about my Plan B.

Okay. But, given that Gregory is no stranger to the group and is known not
to be an antisocial git, I'd have tried to word plan A a little more
gently, that's all.

I will henceforth be monitoring this site with extreme interest.

That can only be good for all concerned.

 

[Richard Heathfield]

Netocrat said:

I've deleted all code-containing pages from the "Portable C library source
code implementation" category and its sub-categories on clc-wiki.net.

Good move. Perhaps it would be a good idea to start again, and ban anyone
from participating if they have access to a copy of TSCL. (In a curious
omission, I never actually got around to buying a copy myself, so I'd be
game for that.)

This morning, I took the opportunity to drop in on the C wiki, and I have to
say it does look like it's becoming a useful site, current debacle
notwithstanding. I am delighted, and encouraged. I may start dropping by a
little more often.

 

[websnarf]

Caution. Many of the standard library routines are intrinsically
not implementable with portable code. I suggest an enumeration of
these would be worthwhile, together with the sort of assumptions
needed for an implementation. We can start with malloc, realloc,
and free, which require assumptions about alignment and pointer
convertability.

A _lot_ can be done with only a very tiny section of non-portable code,
though. malloc/realloc/free need only two things - a way to get a
[moderately large] block of memory from the OS, and a way to figure out
pointer alignments. (Once a pointer _is_ aligned 'for any data type', it
can be converted to a pointer to any data type)

On many (and certainly most modern) platforms, a heap implementation
that is not thread safe (via true critical sections) is kind of
useless.

much of stdio can be implemented on a bare-bones subset of the UNIX api:
open, close, read, write; limit open flags to only O_{RDONLY RDWR WRONLY
CREAT TRUNC APPEND}; the other three functions are already dead-simple.

Hmm ... how about things like clock, time, remove, getenv? And if you
are including headers, what's the plan for implementing offsetof,
va_start, va_arg, etc portably?

 

[Jordan Abel]

Gregory Pietsch wrote:
I'm writing a portable implementation of the C standard library
for http://www.clc-wiki.net and I was wondering if someone could
check the functions in math.h for sanity/portability/whatever.
I'm almost halfway through writing the over 200 functions needed
to implement C99's version of math.h, and I would like to have
some feedback and/or expert advice on my implementations.

Caution. Many of the standard library routines are intrinsically
not implementable with portable code. I suggest an enumeration of
these would be worthwhile, together with the sort of assumptions
needed for an implementation. We can start with malloc, realloc,
and free, which require assumptions about alignment and pointer
convertability.

A _lot_ can be done with only a very tiny section of non-portable code,
though. malloc/realloc/free need only two things - a way to get a
[moderately large] block of memory from the OS, and a way to figure out
pointer alignments. (Once a pointer _is_ aligned 'for any data type', it
can be converted to a pointer to any data type)

On many (and certainly most modern) platforms, a heap implementation
that is not thread safe (via true critical sections) is kind of
useless.

Locking can be abstracted with macros, to some extent.

Hmm ... how about things like clock, time, remove, getenv? And if you
are including headers, what's the plan for implementing offsetof,
va_start, va_arg, etc portably?

No idea.

 

[Nick Keighley]

Here is just one example. It's a very simple one because it's
less to type.

_The Standard C Library_ has in ceil.c:

#include "xmath.h"

double (ceil)(double x)
{ /* compute ceil(x) */
return (_Dint(&x, 0) < 0 && 0.0 < x ? x + 1.0 : x);
}

On clc-wiki.net:

#include "xmath.h"

double
(ceil) (double x)
{
return _Dint (&x, 0) < 0 && 0.0 < x ? x + 1.0 : x;
}

Also, all the file names are the same.

seems pretty blatent. Things like _Dint() are like a giant neon sign.
If I were
to try and implement math.h (I doubt I would) _Dint() doesn't seem like
an
obvious name to pick.

 

[Keith Thompson]

Netocrat said:


Good move. Perhaps it would be a good idea to start again, and ban anyone
from participating if they have access to a copy of TSCL. (In a curious
omission, I never actually got around to buying a copy myself, so I'd be
game for that.)

I don't know that it's necessary to be quite that strict. I own a
copy of P.J. Plauger's _The Standard C Library_, but presumably I
could (given time and inclination) write code without referring to it.

 

[Richard G. Riley]

Netocrat said:


Good move. Perhaps it would be a good idea to start again, and ban anyone
from participating if they have access to a copy of TSCL. (In a curious
omission, I never actually got around to buying a copy myself, so I'd be
game for that.)

Why would you ban anyone with access to that? Surely you would want
them to in order to guide? Not everything must be built from
scratch. So long as its not a rip off, the ideas contained therein can
be used to fuse a new thoughtline for the new libraries.

 

[pete]

seems pretty blatent. Things like _Dint() are like a giant neon sign.
If I were
to try and implement math.h
(I doubt I would) _Dint() doesn't seem like
an
obvious name to pick.

I couldn't find the function definition for _Dint.
Was it out there?

 

[Phil Carmody]

Jordan Abel said:


Even P J Plauger. And since he's now closely monitoring it, he might just
start doing that.

(It's an ill wind...)

PJP has /already/ been wronged, and /already/ provides, through his
own choice of medium the information that you wish to see provided.
Why do you ask more from him?

Phil

 

[Nick Keighley]

I couldn't find the function definition for _Dint.
Was it out there?

I think you misunderstand. _Dint() is *not* part of the standard (the
initial underscore is a strong hint) it is part of the particular
implementation. If such internals match then the chances are
vanishingly
small that one is not a derived version of the other. They could also
be derived from a common source.

 

[John F]

I think you misunderstand. _Dint() is *not* part of the standard
(the
initial underscore is a strong hint) it is part of the particular
implementation. If such internals match then the chances are
vanishingly
small that one is not a derived version of the other. They could
also
be derived from a common source.

I was of the opinion that the name was derived or borrowed from
Fortrans DINT (truncate towards zero).
It performs an eqal operation in the implementations above so that
seems reasonable.

regards
John

 

[Richard Heathfield]

Phil Carmody said:

PJP has /already/ been wronged, and /already/ provides, through his
own choice of medium the information that you wish to see provided.

You misunderstand me. I do understand why he's concerned about copyright, of
course I do. But "the information I wish to see provided" is what,
precisely? I couldn't give a monkey's whether the C wiki provides a
standard library source. I already have a compiler and libc, thank you. I
was talking about more general contributions to the wiki.

Why do you ask more from him?

I'm not asking anything from him. But if he does monitor the wiki closely,
he might *just* feel like contributing - just as he contributes to Usenet
without anyone asking him to. And if he does so, that'll be great. But if
he doesn't, no big deal. I think you've got the wrong end of the stick for
a change, Phil.

 

[P.J. Plauger]

I was of the opinion that the name was derived or borrowed from Fortrans
DINT (truncate towards zero).
It performs an eqal operation in the implementations above so that seems
reasonable.

For all its brevity, this is a remarkably telling example of the
distinct worth of a particular implementation. _Dint is indeed my
own invention, evolved over several decades of writing portable
and efficient math functions. It is *not* simply a C implementation
of an old Fortran function, despite the similarity of names. Note
that it takes a second argument. Instead:

_Dint(double *px, int n) clears all but the first n bits to the right
of the (true) binary point in the floating-point value *px, then
returns a code describing the nature of the *discarded* value.

_Dint(&x, -1) truncates x to the nearest *even* value, a critical
test in function pow that's messy to write otherwise.

_Dint(&x, 0) truncates x to an integer and returns zero only
if x was already an integer. It returns other codes if x was a
NaN, an infinity, or a denormal. A good way to kick off all
sorts of math functions.

_Dint(&x, 1) truncates x to the nearest multiple of 1/2, and
tells you whether the result was an exact multiple of 1/2.
Round to nearest, anyone?

_Dint(&x, 2) truncates x to the nearest multiple of 1/4, very
handy for determining a quadrant.

_Dint(&x, (FBITS - 1) / 2) helps split a value into pieces so
you can perform arbitrary-precision using normal floating-point
operations.

At a quick count, we use _Dint in four dozen places in the
Dinkumware C library. It's the binary analog to the most
important (IMO) innovation in the evolving IEEE-754R decimal
floating-point package -- the ability to round to a given
number of decimal digits. But you will notice that _Dint is
*not* specified by the C Standard, and it is *not* present in
other implementations of the Standard C library. (Nor is the
decimal analog in IEEE-754R so clearly delineated.)

I consider _Dint one of the more valuable components of the
Standard C library that I originally wrote and that is now
being licensed by my company, Dinkumware, Ltd. (my
principal source of income for the past decade or so). I
don't take lightly the notion that it can be copied and
used verbatim in ways that took me quite some time to
work out. That's why something as seemingly lightweight as:

return _Dint (&x, 0) < 0 && 0.0 < x ? x + 1.0 : x;

is IMO a serious infringement. It takes more than removing
two parens and adding a space to bring something new to the
party.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[John F]

[SNIP
]>>>> > > _The Standard C Library_ has in ceil.c:

For all its brevity, this is a remarkably telling example of the
distinct worth of a particular implementation. _Dint is indeed my
own invention, evolved over several decades of writing portable
and efficient math functions. It is *not* simply a C implementation
of an old Fortran function, despite the similarity of names. Note
that it takes a second argument. Instead:

I was referring to the name. And "eqal" was meant in a weak sense.

_Dint(double *px, int n) clears all but the first n bits to the
right
of the (true) binary point in the floating-point value *px, then
returns a code describing the nature of the *discarded* value.

_Dint(&x, -1) truncates x to the nearest *even* value, a critical
test in function pow that's messy to write otherwise.

nice hack!

_Dint(&x, 0) truncates x to an integer and returns zero only
if x was already an integer. It returns other codes if x was a
NaN, an infinity, or a denormal. A good way to kick off all
sorts of math functions.

_Dint(&x, 1) truncates x to the nearest multiple of 1/2, and
tells you whether the result was an exact multiple of 1/2.
Round to nearest, anyone?

_Dint(&x, 2) truncates x to the nearest multiple of 1/4, very
handy for determining a quadrant.

_Dint(&x, (FBITS - 1) / 2) helps split a value into pieces so
you can perform arbitrary-precision using normal floating-point
operations.

D'oh! You turned it into a numerical swiss-knife!
In Fortran there are several functions to implement this. Great work!

At a quick count, we use _Dint in four dozen places in the
Dinkumware C library. It's the binary analog to the most
important (IMO) innovation in the evolving IEEE-754R decimal
floating-point package -- the ability to round to a given
number of decimal digits. But you will notice that _Dint is
*not* specified by the C Standard, and it is *not* present in
other implementations of the Standard C library. (Nor is the
decimal analog in IEEE-754R so clearly delineated.)

It is mentioned that it should be able to do it IIRC.

I consider _Dint one of the more valuable components of the
Standard C library that I originally wrote and that is now
being licensed by my company, Dinkumware, Ltd. (my
principal source of income for the past decade or so).

It is, indeed! I hav not had a look at the implementation of _Dint in
the current case. But it looks quite obvious.

I
don't take lightly the notion that it can be copied and
used verbatim in ways that took me quite some time to
work out.

That's what I would sign for immediatelly.

I guess that if he had asked you for assistance, you would have helped
to solve some issues. Just copy and paste without asking is not the
fine kind ...

That's why something as seemingly lightweight as:

return _Dint (&x, 0) < 0 && 0.0 < x ? x + 1.0 : x;

is IMO a serious infringement. It takes more than removing
two parens and adding a space to bring something new to the
party.

FULL ACK.

regards
John

 

[Jordan Abel]

I consider _Dint one of the more valuable components of the Standard C
library that I originally wrote and that is now being licensed by my
company, Dinkumware, Ltd. (my principal source of income for the past
decade or so). I don't take lightly the notion that it can be copied
and used verbatim in ways that took me quite some time to work out.
That's why something as seemingly lightweight as:

Seemingly? It _is_ lightweight. The heavy lifting takes place in _Dint
itself.

return _Dint (&x, 0) < 0 && 0.0 < x ? x + 1.0 : x;

is IMO a serious infringement.

It may be EVIDENCE of a serious infringement, but the real much more
serious infringement would be copying of the implementation of _Dint
itself. Unless you have either a trademark on the name or a patent on
the idea of the function, someone could just as well implement their
own.

Given the specification of "_Dint", this looks like a perfectly obvious
way of implementing ceil. If we lived in some bizarre parallel universe
where _Dint is in the standard C library and ceil is not, that's how _I_
would implement ceil.

It takes more than removing two parens and adding a space to bring
something new to the party.

I'm not saying you're wrong, but equating the copying of a small and
possibly uncopyrightable mathematical formula that _uses_ _Dint, with
copying of the implementation of _Dint itself, seems dishonest.

 

[Jordan Abel]

Why would you ban anyone with access to that? Surely you would want
them to in order to guide? Not everything must be built from scratch.
So long as its not a rip off, the ideas contained therein can be used
to fuse a new thoughtline for the new libraries.

There is a certain danger of both unconsciously copying things, and of
design elements, though not themselves copyrightable, leading in some
cases to very similar code that is very open to liability. While the
idea of _Dint itself [as opposed to its source code] is not, in my
opinion (IANAL) copyrightable, it does lead to some obvious implement-
ations of some other functions [ceil (as shown), floor, round], which,
even if _not_ deliberately copied could end up the same. It's still
possible that is what happened. It leads to a can of worms.

Starting from the source to an open-source libc implementation, such as
that of FreeBSD, and modifying it for portability, would be safer.

 

[Richard G. Riley]

Why would you ban anyone with access to that? Surely you would want
them to in order to guide? Not everything must be built from scratch.
So long as its not a rip off, the ideas contained therein can be used
to fuse a new thoughtline for the new libraries.

There is a certain danger of both unconsciously copying things, and of
design elements, though not themselves copyrightable, leading in some
cases to very similar code that is very open to liability. While the
idea of _Dint itself [as opposed to its source code] is not, in my
opinion (IANAL) copyrightable, it does lead to some obvious implement-
ations of some other functions [ceil (as shown), floor, round], which,
even if _not_ deliberately copied could end up the same. It's still
possible that is what happened. It leads to a can of worms.

It certainly does : we ran a project once for 5 C programmers to write
a routine which copied a string and then removd all the non leading
vowels. We" wr lkng fr spd and rdblty".

4 of the 5 were almost identical in every way. Admittedly the 5 had
been working on a common code base and so shared certain styles : but
often there really is only one way to skin a horse.

Its also one of the big issues when designing redundancy into systems
: often the redundant monitors fail at the same unlikely condition
because the engineers who engineered them made the same booboos.

 

[pete]

I think you misunderstand. _Dint() is *not* part of the standard (the
initial underscore is a strong hint) it is part of the particular
implementation. If such internals match then the chances are
vanishingly
small that one is not a derived version of the other. They could also
be derived from a common source.

Don't function calls like _Dint(), render the code non portable?

I don't understand the point of the posted clc-wiki.net library.
What was one supposed to have been able to do with it?
Was it supposed to have been instructional or of practical use,
or even compilable?

I don't think this is very instructional:
"You just call _Dint (&x, 0),
and now you know how ceil can be implemented."
and I don't undestand
what I was supposed to have been able to do with that code.