Implementation of functions in math.h on clc-wiki
Gregory Pietsch
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.
Sincerely, Gregory Pietsch
P.J. Plauger
news:1142111865.2...@i39g2000cwa.googlegroups.com...
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.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
jacob navia
/* The <math.h> header shall provide for the following constants. The
values
are of type double and are accurate within the precision of the double
type.
*/
#define M_E (2.7182818284590452353602874713526624977572)
/* Value of e */
#define M_LOG2E (1.4426950408889634073599246810018921374266)
/* Value of log2e */
[snip]
#define M_SQRT1_2 (0.7071067811865475244008443621048490392848)
/* Value of 1/sqrt(2) */
---------------------------------------------------------------------
Where do you have that from?
It is not in the C99 standard... Maybe in some other standard?
jacob
Ben Pfaff
> Gregory Pietsch a icrit :
> #define M_E (2.7182818284590452353602874713526624977572)
> /* Value of e */
> #define M_LOG2E (1.4426950408889634073599246810018921374266)
> /* Value of log2e */
[...]
> Where do you have that from?
They're in SUSv3, at least. Not in C99 though.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jordan Abel
Which pages are infringing? the header itself, the implementation files,
or all? (Unfortunately, even if he removes it, it won't be out of the
history - who are the admins of the clc-wiki?)
Chip Eastham
Hi, jacob:
You wrote (to complete the quoted material above):
> Where do you have that from?
>
> It is not in the C99 standard... Maybe in some other standard?
I have no idea how Gregory Pietsch went about preparing his math.h
or its "portable" implementation. The #define's above are consistent
with this math.h specification, copyright 1997 by The Open Group:
http://www.opengroup.org/onlinepubs/007908799/xsh/math.h.html
By C99 most writers seem to mean ISO/IEC 9899:1999 as amended
by a couple of corrections. See for example this page at gnu.org:
http://gcc.gnu.org/c99status.html
A rationale for the new standard and a copy of the working paper that
incorporates certain corrections are linked here:
http://www.open-std.org/JTC1/SC22/WG14/www/standards
This document has more than one hundred references to math.h,
many of them in Annex F on floating-point arithmetic.
Note copyrights in standards are often held by the bodies which
produce them. This is useful in maintaining the integrity of these
published works but often surprises those who expect "information
should be free".
For this reason there is an official policy that printed copies of ISO
(International Organization for Standardization) standards should be
obtained through ones national member organization, links to lists
of which are here:
http://www.iso.org/iso/en/aboutiso/isomembers/index.html
regards, chip
Mark McIntyre
At a quick glance, I saw one mention of PJ Plauger, in reference to an
algorithm. The rest looked like a fairly standard way to implement the
functions. Perhaps it would be helpful to indicate precisely what you
believe to be infringing.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Ben Pfaff
> On Sat, 11 Mar 2006 16:41:16 -0500, in comp.lang.c , "P.J. Plauger"
> <p...@dinkumware.com> wrote:
>
>>"Gregory Pietsch" <GK...@flash.net> wrote in message
>>news:1142111865.2...@i39g2000cwa.googlegroups.com...
>>
>>> 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.
>>
>>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.
>
> At a quick glance, I saw one mention of PJ Plauger, in reference to an
> algorithm. The rest looked like a fairly standard way to implement the
> functions. Perhaps it would be helpful to indicate precisely what you
> believe to be infringing.
I compared a few files in the clc-wiki.net implementation against
those in _The Standard C Library_. The former is obviously a
derivative work of the latter, made without acknowledgments and
(now obviously) without permission.
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman
Richard Heathfield
I haven't looked, and don't plan to, so I don't know whether you're right or
not. And I think you already know that I hold you in pretty high esteem for
the huge amount you've done for the C language. But can I just put in a
plea for Gregory Pietsch?
Gregory is a longstanding contributor to comp.lang.c, and he's basically a
decent chap. If he screwed up on this occasion, I am quite sure that he
will be prepared to take down the offending material without your having to
use such - um - forthright tactics.
Ordinary, decent, law-abiding folk do make mistakes sometimes, and whilst
threatening them with legal action is undoubtedly a very effective
approach, perhaps it is best reserved for a back-up strategy, should an
initial request be rejected or ignored.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jordan Abel
Which ones did you look at? The ones I looked at looked like A) they
were probably fairly obvious implementation techniques and B) they were
simple enough to have been independently arrived at. Or were you
threatening legal action based on mere access and similarity with no
other basis? [Note: IANAL] It's possible that I didn't see the ones you
did, though, I didn't look very thoroughly through it.
CBFalconer
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.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Ben Pfaff
>On 2006-03-12, Ben Pfaff <b...@cs.stanford.edu> wrote:
>> I compared a few files in the clc-wiki.net implementation against
>> those in _The Standard C Library_. The former is obviously a
>> derivative work of the latter, made without acknowledgments and
>> (now obviously) without permission.
> [...] Or were you threatening legal action based on mere access and
> similarity with no other basis?
I'm not the one threatening legal action. Read the attributions,
fool.
--
Ben Pfaff
email: b...@cs.stanford.edu
web: http://benpfaff.org
Ben Pfaff
> On 2006-03-12, Ben Pfaff <b...@cs.stanford.edu> wrote:
>> I compared a few files in the clc-wiki.net implementation against
>> those in _The Standard C Library_. The former is obviously a
>> derivative work of the latter, made without acknowledgments and
>> (now obviously) without permission.
>
> Which ones did you look at? The ones I looked at looked like A) they
> were probably fairly obvious implementation techniques and B) they were
> simple enough to have been independently arrived at.
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.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
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)
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.
Jordan Abel
> Jordan Abel <rand...@gmail.com> writes:
>>On 2006-03-12, Ben Pfaff <b...@cs.stanford.edu> wrote:
>>> I compared a few files in the clc-wiki.net implementation against
>>> those in _The Standard C Library_. The former is obviously a
>>> derivative work of the latter, made without acknowledgments and
>>> (now obviously) without permission.
>
>> [...] Or were you threatening legal action based on mere access and
>> similarity with no other basis?
>
> I'm not the one threatening legal action. Read the attributions,
> fool.
Sorry.
P.J. Plauger
news:duvspl$sks$1...@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
Read what I said again. I'm giving him a chance, but I make no bones
about my Plan B. Ben Pfaff has kindly given a tiny sampler of code that
is clearly a direct copy; there's plenty more where that came from.
It's clear that the "author" of this stuff has to be incredibly naive
about what constitutes infringement, or incredibly brazen. In either
case, the remedy is the same. I will henceforth be monitoring this
site with extreme interest.
Jordan Abel
Keep in mind that it is a wiki, and anyone can contribute.
[for now, someone needs to delete this stuff, since it apparently is in
violation of copyright]
Jordan Abel
I would like to help with this, I have ideas on implementing stdio, and
I also think that these files should be moved into a "pseudo-namespace"
[see http://clc-wiki.net/wiki/Clc_libc/stdio]
Netocrat
>>>> I'm writing a portable implementation of the C standard library for
>>>> http://www.clc-wiki.net
P.J. Plauger wrote:
>>> 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.
And later P.J. Plauger wrote:
> I'm giving him [Gregory Pietsch] a chance, but I make no bones about my
> Plan B. Ben Pfaff has kindly given a tiny sampler of code that is
> clearly a direct copy; there's plenty more where that came from. It's
> clear that the "author" of this stuff has to be incredibly naive about
> what constitutes infringement, or incredibly brazen. In either case, the
> remedy is the same.
I've deleted all code-containing pages from the "Portable C library source
code implementation" category and its sub-categories on clc-wiki.net.
This isn't a judgement either way - I don't have a copy of "The Standard C
Library", and I haven't heard Gregory Pietsch's side of the story. It
seems like the most prudent thing to do though. The pages can currently
still be viewed and restored by admins, but I'd advocate the permanent
deletion of the content of any pages for which the copyright claim stands
unrefuted after giving Gregory Pietsch a chance to defend his methodology.
> I will henceforth be monitoring this
> site with extreme interest.
It would be a boon to the site if you were to do that.
Jordan Abel
> "Gregory Pietsch" <GK...@flash.net> wrote:
>>>>> I'm writing a portable implementation of the C standard library for
>>>>> http://www.clc-wiki.net
>
> P.J. Plauger wrote:
>>>> 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.
>
> And later P.J. Plauger wrote:
>> I'm giving him [Gregory Pietsch] a chance, but I make no bones about my
>> Plan B. Ben Pfaff has kindly given a tiny sampler of code that is
>> clearly a direct copy; there's plenty more where that came from. It's
>> clear that the "author" of this stuff has to be incredibly naive about
>> what constitutes infringement, or incredibly brazen. In either case, the
>> remedy is the same.
>
> I've deleted all code-containing pages from the "Portable C library source
> code implementation" category and its sub-categories on clc-wiki.net.
> This isn't a judgement either way - I don't have a copy of "The Standard C
> Library", and I haven't heard Gregory Pietsch's side of the story. It
> seems like the most prudent thing to do though. The pages can currently
> still be viewed and restored by admins, but I'd advocate the permanent
> deletion of the content of any pages for which the copyright claim stands
> unrefuted after giving Gregory Pietsch a chance to defend his methodology.
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.
Netocrat
[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
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
> 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
> 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.
webs...@gmail.com
> On 2006-03-11, CBFalconer <cbfal...@yahoo.com> wrote:
> > 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.
> 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?
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Jordan Abel
> Jordan Abel wrote:
>> On 2006-03-11, CBFalconer <cbfal...@yahoo.com> wrote:
>> > 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.
>> 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?
No idea.
Nick Keighley
Ben Pfaff wrote:
> Jordan Abel <rand...@gmail.com> writes:
>
> > On 2006-03-12, Ben Pfaff <b...@cs.stanford.edu> wrote:
> >> I compared a few files in the clc-wiki.net implementation against
> >> those in _The Standard C Library_. The former is obviously a
> >> derivative work of the latter, made without acknowledgments and
> >> (now obviously) without permission.
> >
> > Which ones did you look at? The ones I looked at looked like A) they
> > were probably fairly obvious implementation techniques and B) they were
> > simple enough to have been independently arrived at.
>
> 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.
--
Nick Keighley
Keith Thompson
> 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.)
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.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Richard G. Riley
> 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.)
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
I couldn't find the function definition for _Dint.
Was it out there?
--
pete
Phil Carmody
> Jordan Abel said:
>
> > On 2006-03-12, P.J. Plauger <p...@dinkumware.com> wrote:
> >> "Richard Heathfield" <inv...@invalid.invalid> wrote in message
> >> news:duvspl$sks$1...@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
> >>
> >>> P.J. Plauger said:
> >>>
> >>>> I will henceforth be monitoring this
> >> site with extreme interest.
> >
> > 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...)
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
--
What is it: is man only a blunder of God, or God only a blunder of man?
-- Friedrich Nietzsche (1844-1900), The Twilight of the Gods
Nick Keighley
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.
--
Nick Keighley
John F
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
> Richard Heathfield <inv...@invalid.invalid> writes:
>
>> Jordan Abel said:
>>
>> > On 2006-03-12, P.J. Plauger <p...@dinkumware.com> wrote:
>> >> "Richard Heathfield" <inv...@invalid.invalid> wrote in message
>> >> news:duvspl$sks$1...@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
>> >>
>> >>> P.J. Plauger said:
>> >>>
>> >>>> I will henceforth be monitoring this
>> >> site with extreme interest.
>> >
>> > 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...)
>
> 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
news:44143765$0$11610$3b21...@tunews.univie.ac.at...
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.
John F
> "John F" <sp...@127.0.0.1> wrote:
>
>> "Nick Keighley" wrote:
>>>
>>> pete wrote:
>>>> Nick Keighley wrote:
>>>> >
]>>>> > > _The Standard C Library_ has in ceil.c:
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
> 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
> On 2006-03-12, Richard Heathfield <inv...@invalid.invalid> wrote:
>> 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.)
>
> 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
> On 2006-03-12, Richard G. Riley <rgr...@gmail.com> wrote:
>> On 2006-03-12, Richard Heathfield <inv...@invalid.invalid> wrote:
>>> 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.)
>>
>> 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.
>
> Starting from the source to an open-source libc implementation, such as
> that of FreeBSD, and modifying it for portability, would be safer.
>
>>> 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.
--
Debuggers : you know it makes sense.
http://heather.cs.ucdavis.edu/~matloff/UnixAndC/CLanguage/Debug.html#tth_sEc
pete
>
> pete wrote:
> > Nick Keighley wrote:
> > >
> > > Ben Pfaff wrote:
> > > > Jordan Abel <rand...@gmail.com> writes:
> > > >
> > > > > On 2006-03-12, Ben Pfaff <b...@cs.stanford.edu> wrote:
> > > > >> I compared a few files in the clc-wiki.net
> > > > >> implementation against
> > > > >> those in _The Standard C Library_. The former is obviously a
> > > > >> The former is obviously a
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.
--
pete
P.J. Plauger
>> _Dint(&x, -1) truncates x to the nearest *even* value, a critical
>> test in function pow that's messy to write otherwise.
>
> nice hack!
I prefer to think of it as a logical completion of the original
specification, but thanks.
> .....
>> 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.
It's not as obvious as you might think. In fairness to Pietsch,
it looks like he did try to re-engineer the guts of the function
(so far he has only the float version). Still, copying the file
names, many internal implementation names, and the arbitrary
values for the return code is pushing things. In other cases,
you'll find dozens of lines of code copied almost verbatim,
including the coefficients of economized polynomials down to
the last digit. Some of those "small" modules represented days
or weeks of work, over a period of a couple of years -- they
are not the "one right way" to do things.
>> 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
> ...
Right. I have no problem with people reading my published code
and using it as inspiration for a new implementation. I've certainly
benefited over the years from reading tons of code; and I continually
garner ideas from competitors' code that I have access to. Copyright
covers the *expression* of an idea, not the idea itself. But that
expression can be hard won -- in programming it's often the difference
between working right in all the corner cases and not quite working
at oddball times. It deserves protection.
>> 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.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
P.J. Plauger
news:slrne18nrs.g...@random.yi.org...
> On 2006-03-12, P.J. Plauger <p...@dinkumware.com> wrote:
>> 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.
And in structuring the whole library so that ceil can be a one-liner.
Check out some of the ceil functions in glibc before you dismiss
this one-liner so offhandedly.
>> 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.
Here's where we part company, and where I think you're being
uncharitable at best, naive at worst. Copyright covers a broad
spectrum of expressions. It is weakest at "functional writings"
where there is little latitude for variety. Thus, I don't blink
at a <math.h> header that includes:
double sin(double);
My eyebrows would go up at:
_CRTIMP double _CDECL sin(double);
because we define those macros to work one way under gcc and
another under Windows (to build DLLs). And if I saw:
inline double _CDECL sin(double _Left)
{ // return sine
return (_Sin(_Left, 0));
}
I'd consider it a full-bore ripoff, because there's a lot of
technology behind those few lines. This is not just EVIDENCE
of a serious infringement, IMO. The point is, with each stage
there's less function and more unique expression, hence less
excuse for somebody else expressing a thing the way I did,
and hence more evidence that they're piggybacking on what's
well protected by copyright.
> 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.
Right, and I've never said otherwise. In fact, I observed in an
earlier post that the alleged perp put more work than average
into reimplementing _Dint (_Fint to be precise), though I still
consider it arguably infringing because of all the unique
expression that's still copied.
> 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.
Fine, but we don't. It became obvious only after lots of work and
rework on my part, some of it dating back over 40 years.
>> 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.
You're lucky that I chose to take a walk to Starbucks before replying
to this post. You pervert what I actually said, then use it as an
excuse to accuse *me* of being dishonest. Nary a word against the
clear-cut case of infringement that's there for anyone with a copy
of my book to verify. You're stretching the bounds of both
"uncharitable" and "naive" at this point, and bordering on arrogant
and rude. (That wasn't what I intended to say before my daily latte.)
P.J. Plauger
news:441467...@mindspring.com...
> .....
>> 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?
Nope, quite the contrary. By isolating floating-point format
peculiarities in a handful of primitives, you *ease* the task
of writing scads of portable code. Adapting the primitives to
the formats of interest then leverages quite a bit of technology.
> 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.
What you're missing is that _Dint is also provided, along with
the family of floating-point primitives I've developed over
the years. Aside from the *idea* of using those primitives,
which is arguably not protected by copyright, the implementation
of some of them involves a lot of literal copying from my work.
Christian Bau
"P.J. Plauger" <p...@dinkumware.com> wrote:
> It's not as obvious as you might think. In fairness to Pietsch,
> it looks like he did try to re-engineer the guts of the function
> (so far he has only the float version). Still, copying the file
> names, many internal implementation names, and the arbitrary
> values for the return code is pushing things. In other cases,
> you'll find dozens of lines of code copied almost verbatim,
> including the coefficients of economized polynomials down to
> the last digit.
Just a small comment: The coefficients of the polynomials can often be
chosen over a wide range; the lower coefficients are relatively strictly
determined, but there is quite a bit of leeway for the higher
coefficients. So the coefficient for x^3 in the calculation of the sine
function is quite likely the same everywhere, but if the coefficient for
x^15 matches to the last digit, then someone copied it.
P.J. Plauger
news:christian.bau-B2D...@slb-newsm1.svr.pol.co.uk...
> In article <SKSdneS9Ivvw8onZ...@giganews.com>,
> "P.J. Plauger" <p...@dinkumware.com> wrote:
>
>> It's not as obvious as you might think. In fairness to Pietsch,
>> it looks like he did try to re-engineer the guts of the function
>> (so far he has only the float version). Still, copying the file
>> names, many internal implementation names, and the arbitrary
>> values for the return code is pushing things. In other cases,
>> you'll find dozens of lines of code copied almost verbatim,
>> including the coefficients of economized polynomials down to
>> the last digit.
>
> Just a small comment: The coefficients of the polynomials can often be
> chosen over a wide range; the lower coefficients are relatively strictly
> determined, but there is quite a bit of leeway for the higher
> coefficients. So the coefficient for x^3 in the calculation of the sine
> function is quite likely the same everywhere, but if the coefficient for
> x^15 matches to the last digit, then someone copied it.
Basically true, but some of the coefficients in the library are
economized, which alters even the lowest-order terms. The latest
Dinkumware libraries use minimax techniques as well, which spread
the "creativity" even more widely over the coefficients. Aside
from the thousands of hours of computer time we've consumed over
the past several years, which arguably doesn't cost much these
days, we've also devoted the odd thousand hours of people time,
which is the realest expense we have. (It's the Ltd. part of
Dinkumware, Ltd.)
>> Some of those "small" modules represented days
>> or weeks of work, over a period of a couple of years -- they
>> are not the "one right way" to do things.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
John F
>>> test in function pow that's messy to write otherwise.
>>
>> nice hack!
>
> I prefer to think of it as a logical completion of the original
> specification, but thanks.
I did mean it the right way round :-)
>> .....
>>> 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.
>
> It's not as obvious as you might think. In fairness to Pietsch,
> it looks like he did try to re-engineer the guts of the function
> (so far he has only the float version). Still, copying the file
> names, many internal implementation names, and the arbitrary
> values for the return code is pushing things. In other cases,
> you'll find dozens of lines of code copied almost verbatim,
> including the coefficients of economized polynomials down to
> the last digit. Some of those "small" modules represented days
> or weeks of work, over a period of a couple of years -- they
> are not the "one right way" to do things.
Numerical optimisation is a though subject where propagation of errors
is one of the biggest issues which is non trivial at least...
Which optimisazions did you use? I have done three methods so far with
intermediate success (no time to use MatLab for extended
simulation...). Chebychev is one of my favourites. I'm trying to catch
up with more numerics but I just don't have enough time to.
>>> 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 ...
>
> Right. I have no problem with people reading my published code
> and using it as inspiration for a new implementation. I've certainly
> benefited over the years from reading tons of code; and I
> continually
> garner ideas from competitors' code that I have access to. Copyright
> covers the *expression* of an idea, not the idea itself. But that
> expression can be hard won -- in programming it's often the
> difference
> between working right in all the corner cases and not quite working
> at oddball times. It deserves protection.
I agree on that.
regards
John
Rod Pemberton
"P.J. Plauger" <p...@dinkumware.com> wrote in message
news:4dmdnS-TzL3...@giganews.com...
As the guys here know, I am not a strong supporter of copyrights. But,
despite what Jordan Abel says, _Dint is _NOT_ anywhere near an obvious
implementation. It is highly specialized as the four cases prove.
_Dint(double *px, int n) is especially non-obvious. Although I haven't seen
the other offending stuff, I have to strongly side with you (Plauger) that
this is proprietary.
Rod Pemberton
Jordan Abel
> news:44144c92$0$10578$3b21...@tunews.univie.ac.at...
>
>>> _Dint(&x, -1) truncates x to the nearest *even* value, a critical
>>> test in function pow that's messy to write otherwise.
>>
>> nice hack!
>
> I prefer to think of it as a logical completion of the original
> specification, but thanks.
Using it to implement pow() is clever, though.
>>> 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.
>
> It's not as obvious as you might think. In fairness to Pietsch, it
> looks like he did try to re-engineer the guts of the function (so far
> he has only the float version). Still, copying the file names, many
> internal implementation names, and the arbitrary values for the return
> code is pushing things. In other cases, you'll find dozens of lines of
> code copied almost verbatim, including the coefficients of economized
> polynomials down to the last digit.
Yeah. And those "magic numbers" probably aren't the best thing to post
on a wiki for newbies who want to know how a C library works, anyway.
For (say) a sine function, 0, 1, 0, -1, ... is a set of coefficients
that are probably more easily understood, if not necessarily leading to
as efficient or as precise an implementation.
> Some of those "small" modules represented days or weeks of work, over
> a period of a couple of years -- they are not the "one right way" to
> do things.
OK, but the ceil() implementation is, as far as I can tell, pretty much
the only way to implement ceil in terms of _Dint, for whatever that's
worth. You could flip the conditional around and make it look different,
but it's fundamentally the same.
>>> 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
>> ...
>
> Right. I have no problem with people reading my published code
> and using it as inspiration for a new implementation. I've certainly
> benefited over the years from reading tons of code; and I continually
> garner ideas from competitors' code that I have access to. Copyright
> covers the *expression* of an idea, not the idea itself. But that
> expression can be hard won -- in programming it's often the difference
> between working right in all the corner cases and not quite working
> at oddball times. It deserves protection.
Well, in any case - I know this whole episode has probably left a bad
taste in your mouth, so to speak, about the wiki and everything, but
what would your thoughts be on contributing to it? Maybe not to the c
library reimplementation, or even code at all, but it could always use
more people even just in general.
P.J. Plauger
For single-argument functions, we favor piecewise minimax fits
(ratio of polynomials) using Maplesoft. We patch around zeros
at irrational argument values with truncated Taylor series.
We use extended precision as needed, implemented as an array
of half-precision values of arbitrary length.
We've also developed special test generators that know about the
graininess of floating-point values, and the inherent sensitivity
in functions due both to high slopes and artifacts of
floating-point representation.
What could be simpler?
P.J. Plauger
news:dv1um6$33up$1...@news3.infoave.net...
>> 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.
>>
>
> As the guys here know, I am not a strong supporter of copyrights. But,
> despite what Jordan Abel says, _Dint is _NOT_ anywhere near an obvious
> implementation. It is highly specialized as the four cases prove.
> _Dint(double *px, int n) is especially non-obvious. Although I haven't
> seen
> the other offending stuff, I have to strongly side with you (Plauger) that
> this is proprietary.
Thanks, but let's tease apart a few concepts:
I am a *strong supporter* of copyrights because they protect
the actual unique expression, which at the end of the day is
what we programmers produce by way of value added.
I am *strongly opposed* to patents because they grant monopolies
on ideas, which are too easy for all of us to reinvent and which,
in software, are too close to mathematical formulas, which the
US patent system did not intend to cover.
I am neutral about keeping software proprietary. I sympathize
with the FSF goal of making all source code accessible -- indeed
I've always made my source code available to through books and
reasonable licensing terms -- but if a company wants to keep
their stuff hidden that should be their prerogative.
The problem here is that, while I assert copyright over code
in the Standard C Library book, I did not keep it proprietary.
I don't mind the copying of ideas, but I strongly oppose the
copying of expression. I make my living licensing, enhancing,
and supporting that expression.
P.J. Plauger
>> Right. I have no problem with people reading my published code
>> and using it as inspiration for a new implementation. I've certainly
>> benefited over the years from reading tons of code; and I continually
>> garner ideas from competitors' code that I have access to. Copyright
>> covers the *expression* of an idea, not the idea itself. But that
>> expression can be hard won -- in programming it's often the difference
>> between working right in all the corner cases and not quite working
>> at oddball times. It deserves protection.
>
> Well, in any case - I know this whole episode has probably left a bad
> taste in your mouth, so to speak, about the wiki and everything, but
> what would your thoughts be on contributing to it? Maybe not to the c
> library reimplementation, or even code at all, but it could always use
> more people even just in general.
I'm not agin it, and I've been know to speak up when the urge
strikes, but I do this sort of thing 60 hours a week as my
profession, not as a hobby. I'm also getting old, and looking
forward to only doing it, say, 40 hours a week. Maybe when
things slow down a bit...
Jordan Abel
sincerely sorry.
My question is this:
Do you think that, if this is infringement, that /1/ is necessarily also
infringement? How about /2/? I think that if the first is, both my
examples are as well, and that's why i'm uncomfortable with the position
that the first is.
1/return _M_d2i(&x,0) >= 0 || x <= 0 ? x : x+1;
2/
if(__dI(&x,0)<0 && x > 0)
return x+1.;
else
return x;
> double sin(double);
>
> My eyebrows would go up at:
>
> _CRTIMP double _CDECL sin(double);
>
> because we define those macros to work one way under gcc and
> another under Windows (to build DLLs).
I think mine would too, but i'd think of it as being strong evidence of
further 'lifting' rather than being copyright infringement in itself -
whatever you end up naming the macro, there's really only one way to
declare a cdecl function on gcc, and only one way to do so on msvc. /3/,
right? No idea what _CRTIMP does. dllexport? I'm certainly not
disagreeing that it should raise suspicion, just that it's copyright
infringement per se.
3/
#if defined(__GNUC__)
#define _CDECL __cdecl
#elif defined(WIN32)
#define _CDECL __attribute__((__cdecl__))
#endif
> And if I saw:
>
> inline double _CDECL sin(double _Left)
> { // return sine
> return (_Sin(_Left, 0));
> }
It's unlikely you're the first to think of bundling sine and cosine into
a single function. Again, the names very much should raise suspicion,
and I certainly didn't mean to fault you for that - but the core imple-
mentation itself would be the actual infringement. I think part of it is
that I strongly disagree that changing the names should have any effect
on whether it's copyright infringement or not, since identifiers aren't
really the expressive part of code. I'm sure you probably agree that if
someone stole your code it would be made any better if they ran it
through an obfuscator to change all the identifiers.
I think that if inline double _CDECL sin(double _Left) { return (_Sin
(_Left, 0)); } is infringement, it is implicit that inline double
__cdecl__ sin(double _M_angle) { return (_M_sin(_M_angle,0)); } must
also be. That is what makes me uncomfortable about your position.
> I'd consider it a full-bore ripoff, because there's a lot of
> technology behind those few lines.
Yes, but in my opinion you'd have to look behind them, not in them, to
find the actual ripoff.
> This is not just EVIDENCE of a serious infringement, IMO. The point
> is, with each stage there's less function and more unique expression,
> hence less excuse for somebody else expressing a thing the way I did,
> and hence more evidence that they're piggybacking on what's well
> protected by copyright.
>
>> 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.
>
> Right, and I've never said otherwise. In fact, I observed in an
> earlier post that the alleged perp put more work than average
> into reimplementing _Dint (_Fint to be precise), though I still
> consider it arguably infringing because of all the unique
> expression that's still copied.
>
>> 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.
>
> Fine, but we don't. It became obvious only after lots of work and
> rework on my part, some of it dating back over 40 years.
ceil itself did? The idea of having a _Dint() function [and the details
of its specification, etc] did? or are we talking about the implement-
ation of _Dint()? No offense intended, I'm just confused here.
>> 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.
>
> You're lucky that I chose to take a walk to Starbucks before replying
> to this post. You pervert what I actually said, then use it as an
> excuse to accuse *me* of being dishonest. Nary a word against the
> clear-cut case of infringement that's there for anyone with a copy
> of my book to verify.
Sorry - I don't have a copy of your book so I didn't feel qualified to
comment on that in either direction. I still don't believe that there's
that much variation possible in ceil() itself, and i hadn't even looked
at either the _Dint implementation on there, or, obviously, yours [since
i don't have the book]
To clarify my position: I think that the whole of what was there was
clearly infringement, just that ceil(), had it been present in isolation
with nothing else but an entirely reimplemented _Dint() wouldn't have
been. (though, the broader idea of using a function like _Dint() in the
implementation of other functions still might have been. I don't yet
have an opinion on that)
> You're stretching the bounds of both "uncharitable" and "naive" at
> this point, and bordering on arrogant and rude. (That wasn't what I
> intended to say before my daily latte.)
Again, i'm sorry.
John F
Maple is a good tool, I'll try to get back to those interesting stuff.
> We patch around zeros
> at irrational argument values with truncated Taylor series.
> We use extended precision as needed, implemented as an array
> of half-precision values of arbitrary length.
This could lead to almost infinite precision when used iteratively.
Would be interesting to see a high precision scientific library ...
maybe it will need some speed optimisazion then ... *thoughts running
through my head*
> We've also developed special test generators that know about the
> graininess of floating-point values, and the inherent sensitivity
> in functions due both to high slopes and artifacts of
> floating-point representation.
That could come in handy now and then when it comes to tweaking
control algorithms for ç— precision lab instrumentory...
> What could be simpler?
Good question ;-) If you know how to do it, nothing is complicated ...
Devil is in details and I'm as sure as I am real that you had a few
puzzles to solve on the algorithms (especially to make them
efficient...)
regards
John
Rod Pemberton
> "Rod Pemberton" <do_no...@sorry.bitbuck.cmm> wrote in message
> news:dv1um6$33up$1...@news3.infoave.net...
>
> copying of expression. I make my living licensing, enhancing,
> and supporting that expression.
So, one can use the exact same idea that you presented, as long as that
exact same idea is expressed in a completely different manner?
If everyone was held to that, it would essentially make all of mathematics,
physics, and most of computer programming, unuseable. I guess what I'm
trying to get at is: at what point does a certain author's presentation of
say, the Pythagorean Theorem, become copyrightable? How many ways can one
express this idea: "the rose is red," before it becomes uniquely
distinquishable enough to be copyrighted? Your use of _Dint was unique IMO.
But, how exactly could one use that same idea without expressing it in the
same unique manner? You seem to contradict yourself. You said you opposed
software patents, but yet it is very unlikely someone will be able to come
up with a different manner to express the ideas of _Dint without using your
exact form of expression. Essentially, you have a software patent through
copyright.
Rod Pemberton
P.J. Plauger
> First, I would like to apologize. My tone did cross a line, and I'm
> sincerely sorry.
Apology accepted. Thanks.
> .....
> My question is this:
>
> Do you think that, if this is infringement, that /1/ is necessarily also
> infringement? How about /2/? I think that if the first is, both my
> examples are as well, and that's why i'm uncomfortable with the position
> that the first is.
>
> 1/return _M_d2i(&x,0) >= 0 || x <= 0 ? x : x+1;
>
>
> 2/
> if(__dI(&x,0)<0 && x > 0)
> return x+1.;
> else
> return x;
You can fuzz the line until the cows come home. My initial
observation was that the one-liner ceil was pretty clearly
infringing in its own right because:
a) it differed only in whitespace and redundant parens from the
expression I used, down to the funny name for the internal function
_Dint, and
b) it was built around an inventive approach to ceil that I've
never seen in another implementation (down to the nuts and bolts,
even though said nuts and bolts did not appear in the one-liner)
Changing names is a step away, as is restating the algorithm.
How far is far enough? Operationally, it's probably when you've
made enough changes that you have a new debugging task on your
hands, and you're not just piggybacking on the testing and
debugging done for the prototype that inspired you. I don't
pretend it's a bright line in general. But I think it was in
the originally presented particular case for ceil.
>> double sin(double);
>>
>> My eyebrows would go up at:
>>
>> _CRTIMP double _CDECL sin(double);
>>
>> because we define those macros to work one way under gcc and
>> another under Windows (to build DLLs).
>
> I think mine would too, but i'd think of it as being strong evidence of
> further 'lifting' rather than being copyright infringement in itself -
Uh, to me that's a distinction without a difference. You still
seem to think that infringement only occurs after a certain
number of yards of code have been replicated. In literature,
you can infringe:
a book copyright by copying half a page without attribution or
permission
a screenplay by imitating the principal characters and plot outline
a poem by quoting one plangent line
It depends more on the creative freight than the length of the
train.
> whatever you end up naming the macro, there's really only one way to
> declare a cdecl function on gcc, and only one way to do so on msvc. /3/,
> right?
No, there are several. Part of my point.
> No idea what _CRTIMP does. dllexport? I'm certainly not
> disagreeing that it should raise suspicion, just that it's copyright
> infringement per se.
>
> 3/
> #if defined(__GNUC__)
> #define _CDECL __cdecl
> #elif defined(WIN32)
> #define _CDECL __attribute__((__cdecl__))
> #endif
Good guess, but off the mark. The creativity can also come in
*where* you put the _CDECL decorations, as well as what they
expand to.
>> And if I saw:
>>
>> inline double _CDECL sin(double _Left)
>> { // return sine
>> return (_Sin(_Left, 0));
>> }
>
> It's unlikely you're the first to think of bundling sine and cosine into
> a single function.
Right, but making the second argument a quadrant offset is not
widely done. Nor is the naming convention. Nor, necessarily, is
the direct call to the common internal function from a C++ inline
and a C macro. etc. etc.
> Again, the names very much should raise suspicion,
> and I certainly didn't mean to fault you for that - but the core imple-
> mentation itself would be the actual infringement. I think part of it is
> that I strongly disagree that changing the names should have any effect
> on whether it's copyright infringement or not, since identifiers aren't
> really the expressive part of code. I'm sure you probably agree that if
> someone stole your code it would be made any better if they ran it
> through an obfuscator to change all the identifiers.
Sorry, but it's both. We all know that a good set of naming
conventions can materially aid the readability of code, and
hence contribute to its worth. At the same time, it's not
the whole value added, so mechanically altering the names
and retaining the code structure doesn't cut it either.
You can't say one aspect is the arena for determining
infringment and the other is not.
> I think that if inline double _CDECL sin(double _Left) { return (_Sin
> (_Left, 0)); } is infringement, it is implicit that inline double
> __cdecl__ sin(double _M_angle) { return (_M_sin(_M_angle,0)); } must
> also be. That is what makes me uncomfortable about your position.
Well, it doesn't have to. See above.
>> I'd consider it a full-bore ripoff, because there's a lot of
>> technology behind those few lines.
>
> Yes, but in my opinion you'd have to look behind them, not in them, to
> find the actual ripoff.
Another distinction without a difference. *Both* the foreground
and the background are part of the expression.
> .....
>>> 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.
>>
>> Fine, but we don't. It became obvious only after lots of work and
>> rework on my part, some of it dating back over 40 years.
>
> ceil itself did? The idea of having a _Dint() function [and the details
> of its specification, etc] did? or are we talking about the implement-
> ation of _Dint()? No offense intended, I'm just confused here.
IIRC, _Dint first arose as a safe way to perform the common operation
of ceil and floor, safely for large and semi-numeric values. It then
became apparent that several internal functions were so similar that
they should be merged, if only to lower the cost of porting. So
ceil and _Dint evolved back and forth, not in any simply directed
fashion (as top-down advocates would have you believe).
>>> 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.
>>
>> You're lucky that I chose to take a walk to Starbucks before replying
>> to this post. You pervert what I actually said, then use it as an
>> excuse to accuse *me* of being dishonest. Nary a word against the
>> clear-cut case of infringement that's there for anyone with a copy
>> of my book to verify.
>
> Sorry - I don't have a copy of your book so I didn't feel qualified to
> comment on that in either direction. I still don't believe that there's
> that much variation possible in ceil() itself, and i hadn't even looked
> at either the _Dint implementation on there, or, obviously, yours [since
> i don't have the book]
I just grabbed three implementations of ceil from glibc. (There are
about two dozen.) They're attached below. Which one do you think looks
most like my implementation?
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
----
double
__ceil (double x)
{
if (isless (fabs (x), 9007199254740992.0)) /* 1 << DBL_MANT_DIG */
{
double tmp1, new_x;
new_x = -x;
__asm (
#ifdef _IEEE_FP_INEXACT
"cvttq/svim %2,%1\n\t"
#else
"cvttq/svm %2,%1\n\t"
#endif
"cvtqt/m %1,%0\n\t"
: "=f"(new_x), "=&f"(tmp1)
: "f"(new_x));
/* Fix up the negation we did above, as well as handling -0 properly.
*/
x = copysign(new_x, x);
}
return x;
}
----
#include <machine/asm.h>
RCSID("$NetBSD: s_ceil.S,v 1.4 1995/05/08 23:52:13 jtc Exp $")
ENTRY(__ceil)
fldl 4(%esp)
subl $8,%esp
fstcw 4(%esp) /* store fpu control word */
/* We use here %edx although only the low 1 bits are defined.
But none of the operations should care and they are faster
than the 16 bit operations. */
movl $0x0800,%edx /* round towards +oo */
orl 4(%esp),%edx
andl $0xfbff,%edx
movl %edx,(%esp)
fldcw (%esp) /* load modified control word */
frndint /* round */
fldcw 4(%esp) /* restore original control word */
addl $8,%esp
ret
----
#include "math.h"
#include "math_private.h"
#ifdef __STDC__
static const double huge = 1.0e300;
#else
static double huge = 1.0e300;
#endif
#ifdef __STDC__
double __ceil(double x)
#else
double __ceil(x)
double x;
#endif
{
int32_t i0,i1,j0;
u_int32_t i,j;
EXTRACT_WORDS(i0,i1,x);
j0 = ((i0>>20)&0x7ff)-0x3ff;
if(j0<20) {
if(j0<0) { /* raise inexact if x != 0 */
if(huge+x>0.0) {/* return 0*sign(x) if |x|<1 */
if(i0<0) {i0=0x80000000;i1=0;}
else if((i0|i1)!=0) { i0=0x3ff00000;i1=0;}
}
} else {
i = (0x000fffff)>>j0;
if(((i0&i)|i1)==0) return x; /* x is integral */
if(huge+x>0.0) { /* raise inexact flag */
if(i0>0) i0 += (0x00100000)>>j0;
i0 &= (~i); i1=0;
}
}
} else if (j0>51) {
if(j0==0x400) return x+x; /* inf or NaN */
else return x; /* x is integral */
} else {
i = ((u_int32_t)(0xffffffff))>>(j0-20);
if((i1&i)==0) return x; /* x is integral */
if(huge+x>0.0) { /* raise inexact flag */
if(i0>0) {
if(j0==20) i0+=1;
else {
j = i1 + (1<<(52-j0));
if(j<i1) i0+=1; /* got a carry */
i1 = j;
}
}
i1 &= (~i);
}
}
INSERT_WORDS(x,i0,i1);
return x;
}
Jordan Abel
On 2006-03-12, P.J. Plauger <p...@dinkumware.com> wrote:
> "Jordan Abel" <rand...@gmail.com> wrote in message
> news:slrne19666.g...@random.yi.org...
>
>>> double sin(double);
>>>
>>> My eyebrows would go up at:
>>>
>>> _CRTIMP double _CDECL sin(double);
>>>
>>> because we define those macros to work one way under gcc and
>>> another under Windows (to build DLLs).
>>
>> I think mine would too, but i'd think of it as being strong evidence of
>> further 'lifting' rather than being copyright infringement in itself -
[>...]
> It depends more on the creative freight than the length of the
> train.
I think we're still in disagreement about how much "creative freight"
a wrapper function or a declaration [regardless of how much conditional
macro baggage may be present] has. But we'll have to agree to disagree I
guess. Again, sorry for my tone before.
>> whatever you end up naming the macro, there's really only one way to
>> declare a cdecl function on gcc, and only one way to do so on msvc. /3/,
>> right?
>
> No, there are several. Part of my point.
But you have to choose one, and the choice of which one is pretty much
arbitrary, isn't it?
> The creativity can also come in *where* you put the _CDECL
> decorations, as well as what they expand to.
Normally, I'd agree, but... again, it has to go somewhere. [well,
realistically, cdecl is the default, so you _could_ leave it off if
you can guarantee that it won't be compiled with options that will
change the default calling convention] there are a limited number of
choices, and when it comes down to it, the choice is pretty much
arbitrary. personally, i'd have put it after the prototype, unless
there was a compelling reason otherwise (say, some windows compiler
doesn't allow it there. but then there's no longer a choice.)
>
>>> And if I saw:
>>>
>>> inline double _CDECL sin(double _Left)
>>> { // return sine
>>> return (_Sin(_Left, 0));
>>> }
>>
>> It's unlikely you're the first to think of bundling sine and cosine into
>> a single function.
>
> Right, but making the second argument a quadrant offset is not
> widely done.
I didn't even realize that - does that mean that one can pass 2 to it to
get -sin(x) as well?
> Nor is the naming convention.
_Word is one of a limited number of sane reserved identifier formats...
it's the one used by the new keywords in c99. I have no idea what the
significance of "left" is.
> Nor, necessarily, is the direct call to the common internal function
> from a C++ inline and a C macro. etc. etc.
That I'll buy. But inlines in headers as a general technique are common
enough.
>> Again, the names very much should raise suspicion, and I certainly
>> didn't mean to fault you for that - but the core implementation it-
>> self would be the actual infringement. I think part of it is that I
>> strongly disagree that changing the names should have any effect on
>> whether it's copyright infringement or not, since identifiers aren't
>> really the expressive part of code. I'm sure you probably agree that
>> if someone stole your code it would be made any better if they ran it
>> through an obfuscator to change all the identifiers.
>
> Sorry, but it's both. We all know that a good set of naming
> conventions can materially aid the readability of code, and hence
> contribute to its worth. At the same time, it's not the whole value
> added, so mechanically altering the names and retaining the code
> structure doesn't cut it either. You can't say one aspect is the
> arena for determining infringment and the other is not.
>
>> I think that if inline double _CDECL sin(double _Left) { return (_Sin
>> (_Left, 0)); } is infringement, it is implicit that inline double
>> __cdecl__ sin(double _M_angle) { return (_M_sin(_M_angle,0)); } must
>> also be. That is what makes me uncomfortable about your position.
>
> Well, it doesn't have to. See above.
I think we'll have to agree to disagree, and if that means that I end
up letting more things slide if I [unlikely] get famous and write a C
book, that's my loss.
> IIRC, _Dint first arose as a safe way to perform the common operation
> of ceil and floor, safely for large and semi-numeric values. It then
> became apparent that several internal functions were so similar that
> they should be merged, if only to lower the cost of porting. So
> ceil and _Dint evolved back and forth, not in any simply directed
> fashion (as top-down advocates would have you believe).
OK.
>> Sorry - I don't have a copy of your book so I didn't feel qualified to
>> comment on that in either direction. I still don't believe that there's
>> that much variation possible in ceil() itself, and i hadn't even looked
>> at either the _Dint implementation on there, or, obviously, yours [since
>> i don't have the book]
>
> I just grabbed three implementations of ceil from glibc. (There are
> about two dozen.) They're attached below. Which one do you think looks
> most like my implementation?
<snipped>
fair enough.
P.J. Plauger
> "P.J. Plauger" <p...@dinkumware.com> wrote in message
> news:bYadnfGdE9Z...@giganews.com...
>> "Rod Pemberton" <do_no...@sorry.bitbuck.cmm> wrote in message
>> news:dv1um6$33up$1...@news3.infoave.net...
>>
>> I don't mind the copying of ideas, but I strongly oppose the
>> copying of expression. I make my living licensing, enhancing,
>> and supporting that expression.
>
> So, one can use the exact same idea that you presented, as long as that
> exact same idea is expressed in a completely different manner?
Yes. That is sufficient, if not always necessary. I think you're
accusing me of saying it's always absolutely necessary. There
are degrees of acceptable difference, depending on the uniqueness
of each part of the expression.
> If everyone was held to that, it would essentially make all of
> mathematics,
> physics, and most of computer programming, unuseable.
Nonsense. Perhaps you didn't notice what I said about functional
writings. If you ask three people to draw a floor plan for a warehouse,
you're going to get three pretty similar drawings (assuming they're
all basically competent). About the only way to infringe a blueprint
is to stuff it through a copier. Most of math and physics, and
great swaths of computer programming, aren't much different from
blueprints. But those parts of computer programming that are
deserve greater protection.
> I guess what I'm
> trying to get at is: at what point does a certain author's presentation of
> say, the Pythagorean Theorem, become copyrightable?
A common touchstone is to ask, "Do you have to say it exacty
that way?" If there's only one sensible way to say something,
like x^2 + y^2 = z^2, then there's very little protection in
copyright law. But if you take the road less traveled, as it
were, you'd better not quote much more than the cliched part
of Robert Frost's great poem without getting permission.
> How many ways can one
> express this idea: "the rose is red," before it becomes uniquely
> distinquishable enough to be copyrighted?
Good question. That's what poetry magazines traffic in, for
example.
> Your use of _Dint was unique IMO.
> But, how exactly could one use that same idea without expressing it in the
> same unique manner?
Do you have to call it _Dint? There's no standard that says such
a critter exists. Does the first argument have to be a pointer
to double, and the second argument a signed integer bit offset?
Nothing like that in Fortran, IIRC. Do the return values have to
be defined in <math.h> as:
#define FP_INFINITE 2
#define FP_NAN 1
#define FP_NORMAL (-1)
#define FP_SUBNORMAL (-2)
#define FP_ZERO 0
(which was on the internet until a few hours ago, placed there
by a guy who asserted, "I'm writing a portable implementation of
the C standard library")? You might compare to this excerpt from
my <ymath.h>:
#define _DENORM (-2) /* C9X only */
#define _FINITE (-1)
#define _INFCODE 1
#define _NANCODE 2
(A little creativity there, but not much.) And so on, and so on.
None of these things *have* to be that way to implement the
clever idea of a fraction stripping function. So if you see a
ceil function that depends critically on a function spelled
the same way as yours, with the same signature as yours, with
almost identically the same return codes as yours -- with, in
fact, practically the same token sequence as yours -- is this
merely *evidence* of the possibility of infringement or is this
frigging infringement? I'd trust my fate to a dozen jurors
with no programming knowledge, just common sense, on that one.
> You seem to contradict yourself.
No, it's more that you seem to want me to. I've been
reimplementing other people's software for decades, and
I've got a keen moral sense about when I think I've done
it fairly. Moreover, I've been double checked by the
likes of AT&T and tens of thousands of critical readers.
I work *hard* to make sure I have a consistent position
on infringement, one that I can apply equally to myself
and others.
> You said you opposed
> software patents, but yet it is very unlikely someone will be able to come
> up with a different manner to express the ideas of _Dint without using
> your
> exact form of expression.
Hardly. See above.
> Essentially, you have a software patent through
> copyright.
Bullshit.
P.J. Plauger
> .....
>>> whatever you end up naming the macro, there's really only one way to
>>> declare a cdecl function on gcc, and only one way to do so on msvc. /3/,
>>> right?
>>
>> No, there are several. Part of my point.
>
> But you have to choose one, and the choice of which one is pretty much
> arbitrary, isn't it?
Yep. All the more reason to be suspicious when someone makes
all the same arbitrary decisions you did. In arbitrariness
there is creative expression.
> .....
>>>> And if I saw:
>>>>
>>>> inline double _CDECL sin(double _Left)
>>>> { // return sine
>>>> return (_Sin(_Left, 0));
>>>> }
>>>
>>> It's unlikely you're the first to think of bundling sine and cosine into
>>> a single function.
>>
>> Right, but making the second argument a quadrant offset is not
>> widely done.
>
> I didn't even realize that - does that mean that one can pass 2 to it to
> get -sin(x) as well?
Yep. In fact, a quick grep of our code shows that we use at least
four different forms for the second argument.
>> Nor is the naming convention.
>
> _Word is one of a limited number of sane reserved identifier formats...
> it's the one used by the new keywords in c99. I have no idea what the
> significance of "left" is.
True, but _Dint for a fraction stripping function, and _Left for the
left or only operand, etc.? The mere fact that the significance of
_Left doesn't leap out at you should make you wonder why some other
implementer should choose exactly the same funny name, neh?
>> Nor, necessarily, is the direct call to the common internal function
>> from a C++ inline and a C macro. etc. etc.
>
> That I'll buy. But inlines in headers as a general technique are common
> enough.
So does that mean that you dismiss all declarations, macros, and
inlines as possible sources of infringement because all the other
teens at the sock hop are doin' it too?
> .....
Jordan Abel
>> I guess what I'm trying to get at is: at what point does a certain
>> author's presentation of say, the Pythagorean Theorem, become
>> copyrightable?
>
> A common touchstone is to ask, "Do you have to say it exacty that
> way?" If there's only one sensible way to say something, like x^2 +
> y^2 = z^2, then there's very little protection in copyright law. But
> if you take the road less traveled, as it were, you'd better not quote
> much more than the cliched part of Robert Frost's great poem without
> getting permission.
If there is truly only one way to do something, we all agree (At least,
if i'm reading you correctly) that it's not copyrightable. What if there
are only two ways to do something? Are they both copyrightable? Is only
one? If there are more than two, are all but one copyrightable?
Does "well, you can say z^2-x^2=y^2", make x^2+y^2=z^2 copyrightable?
how about z=sqrt(x^2+y^2)?
[aside: given that the poem was written in 1920, it probably wasn't the
best example you might have used. But your point still stands, in
general]
[>...]
The question is whether the idea of "a function, whose first argument is
a pointer to double and whose second argument is int, returning int [0
if the double pointed at was zero, -1 if it is a normal number, -2 if it
is denormalized, 1 if it is infinite, 2 if it is not a number], and mod-
ifying the double pointed at, if normal or denormalized, such that it is
truncated to the number of bits right of the radix point specified in
the second argument" (this was intended to be an accurate and complete
description of your _Dint() function) is copyrightable. My description
of it may be, and your implementation is. But is the idea itself
copyrightable? Copyright law doesn't generally traffic in *ideas* - it's
like recipes - the set of steps themselves aren't copyrightable, only
the physical text of the recipe [the expression of those steps] is.
Jordan Abel
>>> from a C++ inline and a C macro. etc. etc.
>>
>> That I'll buy. But inlines in headers as a general technique are
>> common enough.
>
> So does that mean that you dismiss all declarations, macros, and
> inlines as possible sources of infringement because all the other
> teens at the sock hop are doin' it too?
I just meant that if everything else were shown [however unlikely] to be
something someone came up with independently, that they're both inline
on top of that doesn't bring much to the party, so to speak.
P.J. Plauger
> On 2006-03-13, P.J. Plauger <p...@dinkumware.com> wrote:
>>> I guess what I'm trying to get at is: at what point does a certain
>>> author's presentation of say, the Pythagorean Theorem, become
>>> copyrightable?
>>
>> A common touchstone is to ask, "Do you have to say it exacty that
>> way?" If there's only one sensible way to say something, like x^2 +
>> y^2 = z^2, then there's very little protection in copyright law. But
>> if you take the road less traveled, as it were, you'd better not quote
>> much more than the cliched part of Robert Frost's great poem without
>> getting permission.
>
> If there is truly only one way to do something, we all agree (At least,
> if i'm reading you correctly) that it's not copyrightable. What if there
> are only two ways to do something? Are they both copyrightable? Is only
> one? If there are more than two, are all but one copyrightable?
Looks like you're working toward a constructive definition of
copyrightability similar to Shannon's work on entropy in
information theory. The real world isn't so precise, since it's
determined by judges, lawyers, and jurors. If there's only two
ways to express something and two parties choose the same way,
the odds are 50/50 that neither party copied the other (or that
one did indeed do so). If there are twenty uncorrelated
decisions, however, and all come down the same way, the odds
are one in a million that the match is coincidental. You then
check to see which expression predated the other, then whether
the author of the later work had access to the earlier. etc. etc.
In short, copyrightable is a concept along the lines of portable;
it just ain't black and white.
> .....
> The question is whether the idea of "a function, whose first argument is
> a pointer to double and whose second argument is int, returning int [0
> if the double pointed at was zero, -1 if it is a normal number, -2 if it
> is denormalized, 1 if it is infinite, 2 if it is not a number], and mod-
> ifying the double pointed at, if normal or denormalized, such that it is
> truncated to the number of bits right of the radix point specified in
> the second argument" (this was intended to be an accurate and complete
> description of your _Dint() function) is copyrightable.
No, that isn't the question at hand. Rather, you should ask, "if
only one implementation of a library has this set of functions,
including the rather unusual _Dint function, and the author of
this later work also makes use of such a function, and that author
had access to the earlier work -- and on top of everything else
you find great swatches of code practically indistinguishable --
what are the odds that the earlier expression was infringed?
"Copyrightability" is not a boolean, any more than "portability" is.
> My description
> of it may be, and your implementation is. But is the idea itself
> copyrightable? Copyright law doesn't generally traffic in *ideas* - it's
> like recipes - the set of steps themselves aren't copyrightable, only
> the physical text of the recipe [the expression of those steps] is.
You're teaching your grandmother how to suck eggs.
Keith Thompson
[...]
>> If there is truly only one way to do something, we all agree (At least,
>> if i'm reading you correctly) that it's not copyrightable. What if there
>> are only two ways to do something? Are they both copyrightable? Is only
>> one? If there are more than two, are all but one copyrightable?
>
> Looks like you're working toward a constructive definition of
> copyrightability similar to Shannon's work on entropy in
> information theory. The real world isn't so precise, since it's
> determined by judges, lawyers, and jurors. If there's only two
> ways to express something and two parties choose the same way,
> the odds are 50/50 that neither party copied the other (or that
> one did indeed do so). If there are twenty uncorrelated
> decisions, however, and all come down the same way, the odds
> are one in a million that the match is coincidental. You then
> check to see which expression predated the other, then whether
> the author of the later work had access to the earlier. etc. etc.
> In short, copyrightable is a concept along the lines of portable;
> it just ain't black and white.
I fully agree that "it just ain't black and white", but I have to
disagree with your statement about probabilities.
If there are two equally likely ways to do something, that means that
two parties who do it independently have a 50% chance of doing it the
same way. It doesn't mean that, given that two parties have done it
the same way, there's a 50% probability that one copied the other.
That probability can only be computed given the a priori probability
that one would copy the other in the first place. For example, if the
two parties can be absolutely proven not to have had access to each
other's work, the probability that one copied the other is essentially
zero.
I'm not saying this has any real bearing on the particular case being
discussed here. I haven't commented on that because, though I own a
copy of _The Standard C Library_, I haven't taken the time to compare
it to the posted code.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jordan Abel
You just switched from infringement per se to evidence of infringement
to make that argument - some distinction without a difference that was.
I don't find it that unusual - the decimal equivalent is in IEEE
whatever-it-was, right? Decimal to binary isn't that much of a leap.
If I were implementing from scratch, I might write a function with
similar side-effects to your _Dint for normal arguments and use it in
combination with fpclassify to implement ceil.
P.J. Plauger
news:slrne19i3l.h...@random.yi.org...
Shouldn't have let this one go by earlier:
> [aside: given that the poem was written in 1920, it probably wasn't the
> best example you might have used. But your point still stands, in
> general]
I think it illustrates my overarching point beautifully -- that
the knowledge of copyright law among people who generate IP for
a living is spotty at best. You'll find that the copyrights on
Robert Frost's work are alive and earning money. Just try to
exploit his writings, even from 1920, without getting permission
from Henry Holt and Co. or Frost's estate. The law now says a
copyright extends for the life of the author plus 70 years.
P.J. Plauger
news:ln8xrfo...@nuthaus.mib.org...
Sorry, I was trying to be brief, at the risk of being imprecise. Yes,
to me one of the beauties of copyright law is that you have to show
that the alleged infringer had access to a prior work to be guilty
of copying it. That's why a clean room implementation is a priori
a defense against such accusations. Patents, regrettably, do not work
that way.
Jordan Abel
> Looks like you're working toward a constructive definition of
> copyrightability similar to Shannon's work on entropy in information
> theory. The real world isn't so precise, since it's determined by
> judges, lawyers, and jurors. If there's only two ways to express
> something and two parties choose the same way, the odds are 50/50 that
> neither party copied the other (or that one did indeed do so). If
> there are twenty uncorrelated decisions, however, and all come down
> the same way, the odds are one in a million that the match is
> coincidental. You then check to see which expression predated the
> other, then whether the author of the later work had access to the
> earlier. etc. etc. In short, copyrightable is a concept along the
> lines of portable; it just ain't black and white.
OK. Say that one party admits to copying the other. So it _is_ black and
white whether the author of the later work copied the earlier work.
There is still the question of whether this constitutes infringement.
_That_ is what I mean when I talk about copyrightability.
A work, or a part of a work, either is elegible for copyright or it is
not. There's no "grey area status" for there to be a grey area as far as
I can tell, though there might be areas that still need to be examined
in a court of law. And there have been some bizarre decisions in the
past [e.g. fonts]
P.J. Plauger
No, I switched *back* to reality. You introduced the concept of
"copyrightability" and I went along for the ride, at least for a
spell. Well guess what, "copyrightability" is the degenerate boolean
function "true". *Anybody* can fill out the proper form and send off
damn near any written expression (plus a few other things) and file
for a copyright. Even more strongly, *every* expression is born with
a copyright, which has some clout whether you register it or not.
So copyrightability doesn't mean squat. What matters is how *defensible*
a copyright is, and that's where you start talking about evidence.
(This is sounding more and more like the perennial debates about
portability that grace these electronic pages from time to time.)
And FWIW, I once got a judge to declare a copyright registration
null and void. Seems the guy just registered a whole slew of my
code claiming himself as joint author. Since I hadn't agreed to
that arrangement, his registration was fraudulent. But in a real
sense it didn't matter, because his copyright claim would have
held no water in any action he took against me or anybody else.
But for the sake of tidiness...
> I don't find it that unusual - the decimal equivalent is in IEEE
> whatever-it-was, right?
No. Just something loosely analogous. And about a quarter of a
century later, IIRC. And with quite a different name. etc. etc.
> Decimal to binary isn't that much of a leap.
You're still shucking and jiving, IMO.
> If I were implementing from scratch, I might write a function with
> similar side-effects to your _Dint for normal arguments and use it in
> combination with fpclassify to implement ceil.
You might indeed. One could then compare the two expressions to judge
the likelihood that the newer one infringes the older. But shucking
and jiving aside, most of the time infringement is pretty clear cut.
Either the copyist is just plain lazy and/or brazen, or s/he's
clueless about what constitutes infringement. It doesn't take a lot
of effort to distance a new expression from an older one enough to
avoid claims of infringement. In the case that started this thread,
you can see that effort expended in some places but not in others.
I'm still willing to bet on cluelessness in this particular matter,
at least until the author speaks for himself.
Jordan Abel
Key word - the law _now_ says that. That law does not apply to works
whose copyright term of 75 years had already expired before it was
passed in 1998.
Of course, Frost lived until 1963, so it's probable that he continued
writing and that those works from after 1923 are still under copyright.
P.J. Plauger
> On 2006-03-13, P.J. Plauger <p...@dinkumware.com> wrote:
>> Looks like you're working toward a constructive definition of
>> copyrightability similar to Shannon's work on entropy in information
>> theory. The real world isn't so precise, since it's determined by
>> judges, lawyers, and jurors. If there's only two ways to express
>> something and two parties choose the same way, the odds are 50/50 that
>> neither party copied the other (or that one did indeed do so). If
>> there are twenty uncorrelated decisions, however, and all come down
>> the same way, the odds are one in a million that the match is
>> coincidental. You then check to see which expression predated the
>> other, then whether the author of the later work had access to the
>> earlier. etc. etc. In short, copyrightable is a concept along the
>> lines of portable; it just ain't black and white.
>
> OK. Say that one party admits to copying the other. So it _is_ black and
> white whether the author of the later work copied the earlier work.
> There is still the question of whether this constitutes infringement.
> _That_ is what I mean when I talk about copyrightability.
If he admits he copied, he infringed. How much *damage* that caused
the wounded party is the stuff of litigation.
> A work, or a part of a work, either is elegible for copyright or it is
> not.
Nope, it just *is*. See my earlier post.
> There's no "grey area status" for there to be a grey area as far as
> I can tell, though there might be areas that still need to be examined
> in a court of law.
The grey areas have to do with the nature of infringement, and the
damage that it causes.
> And there have been some bizarre decisions in the
> past [e.g. fonts]
I agree that some past decisions are bizarre, and fonts are a particularly
sorry case. (You can copyright the *name* of a font, but not all the work
you put into drawing all those pretty letters.) But that's the law for
you -- a product of fallible humans wrought by contention. (Not unlike
software, and NASCAR victories.)
P.J. Plauger
It's more than probable, it's certain. Read what I said again. A
copyright extends for the *life of the author* plus 70 years. The
day Frost died in 1963 it was the life of the author plus 50 years.
Even without your keyword, his stuff is still covered.
And you once again underscore my point -- people who generate IP
for a living are way too ignorant of copyright law for their own
good (or mine, for that matter).
Jordan Abel
then where could this conversation be continued?]
http://www.copyright.gov/circs/circ1.html says:
Several categories of material are generally not eligible for
federal copyright protection. These include among others:
* Works that have not been fixed in a tangible form of expression
(for example, choreographic works that have not been notated or recor-
ded, or improvisational speeches or performances that have not been
written or recorded)
* Titles, names, short phrases, and slogans; familiar symbols or
designs; mere variations of typographic ornamentation, lettering, or
coloring; mere listings of ingredients or contents
* Ideas, procedures, methods, systems, processes, concepts,
principles, discoveries, or devices, as distinguished from a des-
cription, explanation, or illustration
* Works consisting entirely of information that is common property
and containing no original authorship (for example: standard cal-
endars, height and weight charts, tape measures and rulers, and
lists or tables taken from public documents or other common sources)
Also: Works by the U. S. Government are not eligible for U. S.
copyright protection.
>
>> There's no "grey area status" for there to be a grey area as
>> far as I can tell, though there might be areas that still need to
>> be examined in a court of law.
>
> The grey areas have to do with the nature of infringement, and the
> damage that it causes.
>
>> And there have been some bizarre
>> decisions in the past [e.g. fonts]
>
> I agree that some past decisions are bizarre, and fonts are a particularly
> sorry case. (You can copyright the *name* of a font, but not all the work
> you put into drawing all those pretty letters.)
You can trademark the name. What you can copyright is the font file, and
the data that went into it [hinting and so on]. But I'm sure that's what
you meant. I do agree that this should not be the case, and it was
the result of an unfortunate misunderstanding which, I think, would
not have been made if the decision were being made now instead of in
1976.
Jordan Abel
Was not. Copyright duration of life of the author plus 50 years was
defined in the Copyright Act of 1976, and did not apply to works
published before January 1st, 1978. Works published before January 1st,
1978 instead had their terms extended by 19 years to a total of 75.
Specifically, the length of the second term [that is, after renewal] was
extended from 28 to 47 years.
> Even without your keyword, his stuff is still covered.
Not quite.
Christian Bau
"Rod Pemberton" <do_no...@sorry.bitbuck.cmm> wrote:
> "P.J. Plauger" <p...@dinkumware.com> wrote in message
> news:bYadnfGdE9Z...@giganews.com...
> > "Rod Pemberton" <do_no...@sorry.bitbuck.cmm> wrote in message
> > news:dv1um6$33up$1...@news3.infoave.net...
> >
> > I don't mind the copying of ideas, but I strongly oppose the
> > copying of expression. I make my living licensing, enhancing,
> > and supporting that expression.
>
> So, one can use the exact same idea that you presented, as long as that
> exact same idea is expressed in a completely different manner?
Copyright is about copying.
You can write anything you like, even if it ends up looking exactly the
same, but you cannot copy, and you cannot copy + modify, even if it
looks quite different afterwards.
The only importance of "looking the same" is that if two things are
looking the same, then it is much less likely that they have been
created independently.
A. Sinan Unur
> But shucking and jiving aside, most of the time infringement is
> pretty clear cut.
FWIW, I saw the OP before seeing your response to it. Having learned an
immense amount from your book (I think I bought it in 1997), having read
through the math.h chapter quite a few times, the first thought that
occurred to me when I saw the code posted on the wiki was "I wonder if
Plauger has given permission for his code to be used".
Sinan
--
A. Sinan Unur <1u...@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
Ronald Bruck
<p...@dinkumware.com> wrote:
> "Gregory Pietsch" <GK...@flash.net> wrote in message
> news:1142111865.2...@i39g2000cwa.googlegroups.com...
>
> > 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.
>
> 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 going back to your original response for my remarks and questions.
At first I thought, "Oh, this is like SCO's suit against IBM". I
wondered what could possibly be in math.h which isn't obvious. I even
wondered whether you were THE P. J. Plauger, or whether the post was a
forgery.
I glanced at a couple of functions from the library, and the
implementations seemed straightforward. I assumed the constants came
from the Remez algorithm, which any competent graduate student could
implement and apply--or, as you note in a later post, you can use
Maple; in any case, I don't consider these to be very secret or
private. Surely they should be regarded as derivative of others' work.
There is an enormous literature on implementing mathematical functions
to the minimum number of ulps, even in extra-high precision [e.g. David
Bailey, the Gnu Multi-Precision Library]. Most of the algorithmic
stuff is open-literature (implementations may be copyrighted, or more
usually "copylefted"), and are far deeper and more extensive than
anything I see in math.h. Such a literature is one of the advantages
of an academic establishment.)
But as the dialogue progressed, e.g. with _Dint, I began to realize
that some serious infringement HAD taken place. Now I begin to worry
about the SCO lawsuit; I surely hope Linus Torvalds documented his
work.
In particular, I was impressed by your defense of copyright as opposed
to software patents (which I have always found offensive--almost as
offensive as patenting sections of the human genome). I have no
argument that a small company like Dinkumware has to protect its
sources of revenue.
But as a mathematician and USER of software, I have to wonder what's
the point of isolating possible machine dependencies so precisely.
Every compiler I've ever used has come with its own math.h, and very
often I've adopted the chip maker's version to replace the standard
libraries (ESPECIALLY implementations of BLAS and LAPACK, which are
enormously more intricate). It's easy enough to write a script to
detect what platform the program is being compiled for, and to use
highly-optimized libraries for the particular platform.
So what would be the advantage, to me, of using Dinkumware's products?
Perhaps if I were a developer trying to get my product out on 18
different processors, I could see it; but even then, I'd HAVE to use a
compiler specific to each processor, and surely these will come with
their own libraries. Of course, these often have bugs (and the
perambulations in code necessary to circumvent bugs are notorious).
So I repeat, what's the point? (Understand, I've only ever developed
on the P4, the AMD64, and the PPC, so I may not fully appreciate the
difficulties.)
--Ron Bruck
jacob navia
> jacob navia wrote:
>
>>Gregory Pietsch a écrit :
>>
>>>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.
>>>
>>>
>>
>>You write in math.h:
>>
>>/* The <math.h> header shall provide for the following constants. The
>>values
>> are of type double and are accurate within the precision of the double
>> type.
>>*/
>>
>>#define M_E (2.7182818284590452353602874713526624977572)
>> /* Value of e */
>>#define M_LOG2E (1.4426950408889634073599246810018921374266)
>> /* Value of log2e */
>>
>>[snip]
>>
>>
>>#define M_SQRT1_2 (0.7071067811865475244008443621048490392848)
>> /* Value of 1/sqrt(2) */
>>---------------------------------------------------------------------
>
>
>
> Hi, jacob:
>
> You wrote (to complete the quoted material above):
>
>
>>Where do you have that from?
>>
>>It is not in the C99 standard... Maybe in some other standard?
>
>
> I have no idea how Gregory Pietsch went about preparing his math.h
> or its "portable" implementation. The #define's above are consistent
> with this math.h specification, copyright 1997 by The Open Group:
>
> http://www.opengroup.org/onlinepubs/007908799/xsh/math.h.html
>
> By C99 most writers seem to mean ISO/IEC 9899:1999 as amended
> by a couple of corrections. See for example this page at gnu.org:
>
> http://gcc.gnu.org/c99status.html
>
> A rationale for the new standard and a copy of the working paper that
> incorporates certain corrections are linked here:
>
> http://www.open-std.org/JTC1/SC22/WG14/www/standards
>
> This document has more than one hundred references to math.h,
> many of them in Annex F on floating-point arithmetic.
>
> Note copyrights in standards are often held by the bodies which
> produce them. This is useful in maintaining the integrity of these
> published works but often surprises those who expect "information
> should be free".
>
> For this reason there is an official policy that printed copies of ISO
> (International Organization for Standardization) standards should be
> obtained through ones national member organization, links to lists
> of which are here:
>
> http://www.iso.org/iso/en/aboutiso/isomembers/index.html
>
> regards, chip
>
Thanks. I know now where they come from at least!
Rod Pemberton
> "Rod Pemberton" <do_no...@sorry.bitbuck.cmm> wrote in message
> news:dv2api$3b06$1...@news3.infoave.net...
>
> > "P.J. Plauger" <p...@dinkumware.com> wrote in message
> > news:bYadnfGdE9Z...@giganews.com...
> >> "Rod Pemberton" <do_no...@sorry.bitbuck.cmm> wrote in message
> >> news:dv1um6$33up$1...@news3.infoave.net...
> >>
> >> I don't mind the copying of ideas, but I strongly oppose the
> >> copying of expression. I make my living licensing, enhancing,
> >> and supporting that expression.
> >
> > So, one can use the exact same idea that you presented, as long as that
> > exact same idea is expressed in a completely different manner?
>
> Yes. That is sufficient, if not always necessary. I think you're
> accusing me of saying it's always absolutely necessary. There
> are degrees of acceptable difference, depending on the uniqueness
> of each part of the expression.
>
> > software patents, but yet it is very unlikely someone will be able to
come
> > up with a different manner to express the ideas of _Dint without using
> > your
> > exact form of expression.
>
As I understand it, you're attempting to secure an exclusive right to
control all forms of expression of your idea which is illegal. For you,
"degrees of acceptable difference" seems to be the key. He had a few
"degrees" of acceptable difference, but that was apparently insufficient as
you noted. So, let's say he reimplements your idea, which you claim is
perfectly acceptable, with the changes you suggested. Is that sufficient
"degrees of acceptable difference?" Or, will there be another round of
"it's still to close to my expression!" At what point does *his* expression
of *your* idea, become *his* lawful expression without granting you total
control of your idea, but only control of your expression? It's clear his
expression can't just paraphrase your expression. It's clear his expression
can't mildly obfuscate your expression. With your suggestions, it's clear
his expression needs major to extreme obfuscation in the expression of your
idea. Or, it needs a completely new method of implementation. In which
case, it's no longer your idea, but his idea and, you've gained an exclusive
right to all implementations of the idea.
> > Essentially, you have a software patent through copyright.
>
> Bullshit.
Wether you believe me or not, I believe you have a software patent through
the use of a copyright. Copyright-misuse of this sort has resulted in
fortfeiture of copyright. I suspect you've never heard of copyright-misuse:
http://en.wikipedia.org/wiki/Copyright_misuse
Rod Pemberton
P.J. Plauger
Then you don't understand it properly.
> For you,
> "degrees of acceptable difference" seems to be the key.
It's a useful guideline, yes.
> He had a few
> "degrees" of acceptable difference, but that was apparently insufficient
> as
> you noted. So, let's say he reimplements your idea, which you claim is
> perfectly acceptable, with the changes you suggested. Is that sufficient
> "degrees of acceptable difference?"
Maybe. I have to see the final version, since at this point I question
the OP's ability to distinguish infringing from non-infringing derivation.
> Or, will there be another round of
> "it's still to close to my expression!" At what point does *his*
> expression
> of *your* idea, become *his* lawful expression without granting you total
> control of your idea, but only control of your expression?
In the extreme case, when a court of law dismisses my case or finds
in his favor. Operationally, when I know I don't have a snowball's
chance in hell of prevailing in court. Practically, when I and a
couple of my friends think he's brought enough new to the party.
> It's clear his
> expression can't just paraphrase your expression. It's clear his
> expression
> can't mildly obfuscate your expression. With your suggestions, it's
> clear
> his expression needs major to extreme obfuscation in the expression of
> your
> idea.
Obfuscation is a poor tool for proving uniqueness of expression,
since it slows comprehension severely.
> Or, it needs a completely new method of implementation. In which
> case, it's no longer your idea, but his idea and, you've gained an
> exclusive
> right to all implementations of the idea.
My, you do have a twisty way of thinking, don't you? You left out about
half a dozen sane and practical steps in the middle there, in your
haste to reach the stratosphere.
>> > Essentially, you have a software patent through copyright.
>>
>> Bullshit.
>
> Wether you believe me or not, I believe you have a software patent through
> the use of a copyright. Copyright-misuse of this sort has resulted in
> fortfeiture of copyright. I suspect you've never heard of
> copyright-misuse:
> http://en.wikipedia.org/wiki/Copyright_misuse
Stop hyperventilating.
P.J. Plauger
news:130320061219545958%br...@math.usc.edu...
> In article <qeedncyY_d1...@giganews.com>, P.J. Plauger
> <p...@dinkumware.com> wrote:
>
>> "Gregory Pietsch" <GK...@flash.net> wrote in message
>> news:1142111865.2...@i39g2000cwa.googlegroups.com...
>>
>> > 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.
>>
>> 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 going back to your original response for my remarks and questions.
>
> At first I thought, "Oh, this is like SCO's suit against IBM". I
> wondered what could possibly be in math.h which isn't obvious.
Wow.
> I even
> wondered whether you were THE P. J. Plauger, or whether the post was a
> forgery.
>
> I glanced at a couple of functions from the library, and the
> implementations seemed straightforward. I assumed the constants came
> from the Remez algorithm, which any competent graduate student could
> implement and apply--or, as you note in a later post, you can use
> Maple; in any case, I don't consider these to be very secret or
> private. Surely they should be regarded as derivative of others' work.
> There is an enormous literature on implementing mathematical functions
> to the minimum number of ulps, even in extra-high precision [e.g. David
> Bailey, the Gnu Multi-Precision Library]. Most of the algorithmic
> stuff is open-literature (implementations may be copyrighted, or more
> usually "copylefted"), and are far deeper and more extensive than
> anything I see in math.h. Such a literature is one of the advantages
> of an academic establishment.)
Us greedy capitalists read the literature too, y'know.
> But as the dialogue progressed, e.g. with _Dint, I began to realize
> that some serious infringement HAD taken place.
Thanks.
> Now I begin to worry
> about the SCO lawsuit; I surely hope Linus Torvalds documented his
> work.
I think the issue is only loosely related, but what the hell, that's
his problem.
> In particular, I was impressed by your defense of copyright as opposed
> to software patents (which I have always found offensive--almost as
> offensive as patenting sections of the human genome). I have no
> argument that a small company like Dinkumware has to protect its
> sources of revenue.
Thanks again.
> But as a mathematician and USER of software, I have to wonder what's
> the point of isolating possible machine dependencies so precisely.
> Every compiler I've ever used has come with its own math.h, and very
> often I've adopted the chip maker's version to replace the standard
> libraries (ESPECIALLY implementations of BLAS and LAPACK, which are
> enormously more intricate). It's easy enough to write a script to
> detect what platform the program is being compiled for, and to use
> highly-optimized libraries for the particular platform.
If the platform has them, perhaps.
> So what would be the advantage, to me, of using Dinkumware's products?
> Perhaps if I were a developer trying to get my product out on 18
> different processors, I could see it; but even then, I'd HAVE to use a
> compiler specific to each processor, and surely these will come with
> their own libraries. Of course, these often have bugs (and the
> perambulations in code necessary to circumvent bugs are notorious).
>
> So I repeat, what's the point? (Understand, I've only ever developed
> on the P4, the AMD64, and the PPC, so I may not fully appreciate the
> difficulties.)
Evidently. You cited the most obvious -- bugs. We've developed what
I believe to be the best math testing harness in the business (and
in academia as well, from what I've seen so far). We've used it to
test all sorts of math libraries out there, and we've found all
sorts of problems. Don't get me wrong, the basic double math library
required by C89 is generally pretty good when you get it from the
likes of Microsoft, IBM, or Sun. But beyond that obvious quality
circle lies a mishmash. The evidence to date is that we test other
people's code way more than they do. That's particularly true of
open source. (It's a lot more fun to write new code and spread it
around the world with your name on it than it is to write tests
and run them.) We also use these tests to develop our own math
functions, of course, so we know they're good.
But if you don't care whether your math functions return correct
answers, it's fine to use whatever comes with your compiler.
Then there's the matter of completeness. We provide a complete
set of C99 math functions in all four IEEE precisions -- 24-bit,
53-bit, 64-bit, and 113-bit. Those compilers that pretend to
supply 24-bit float usually just wrap 53-bit double, so you get
no performance boost as you might expect. We've found a couple
of compilers that claim to support 64-bit long double, but
reliably deliver only 53-bit results. At the other extreme,
some 113-bit functions try way too hard, evidently because
their authors didn't know when to stop adding terms. We use
our tests to ensure a proper balance between accuracy and speed.
But if you're content to use just the C89 double math functions,
and you don't care about performance, you may not need anything
better.
What we offer, by contrast, is the assurance that you can use
our library on a variety of popular platforms, all the functions
you need are there, and they work right everywhere. To pull that
off we've had to be pretty inventive, over many years. You may
believe that the academic literature is a ready source of all
the information you need to knock out a decent math library,
but we know better. For one thing, it's still a big step from
most academic papers to good working code. For another, many
of the techniques we've tried from the literature over the past
several years have proved to be unstable, inaccurate, or simply
wrong.
We're just starting to build the competitive analysis part of
our web site to go with our new product launch. Soon you will
be able to see a few comparisons between our new library and
what comes with different compilers. And we'll provide a few
essays on the lesser known pitfalls of numerical computing.
Maybe then you'll see the point in licensing yet another
library when you already have one you've been using for years.
Jordan Abel
> news:dv4kqf$50m2$1...@news3.infoave.net...
>>>
>>> Bullshit.
>>
>> Wether you believe me or not, I believe you have a software patent through
>> the use of a copyright. Copyright-misuse of this sort has resulted in
>> fortfeiture of copyright. I suspect you've never heard of
>> copyright-misuse:
>> http://en.wikipedia.org/wiki/Copyright_misuse
>
> Stop hyperventilating.
You _did_ suggest that you owned the idea of using a common function
with those particular side-effects and return values to implement a
floor and ceil function. Owning "ideas" is outside of copyright law. You
can own the specific token sequences implementing each function, but you
seem to think you own the idea of having a third function that works in
a particular way to do most of the work that is shared in common between
floor() and ceil(). (Note that even without this I don't dispute that
this was still infringement, but that it easily could have not been if
he'd implemented his own ceil(), even if he had still used a _Dint()
function.)
You said "some creativity, but not much", in comparing the #define's of
FP_* in his math.h vs your own differently-named constants internal to
_Dint. However, the token sequences "# define" and "( - 1 )" (etc)
clearly lack originality and are thus not copyrightable. The idea of
using -1 to represent normal, -2 to represent denormalised values, etc,
is an idea rather than an expression of an idea, and thus also not
copyrightable. What's left there? The names. Which he didn't use. I
think the basic disconnect here is that you do not understand the fact
that there do exist categories of works that are not eligible for
copyright protection.
P.J. Plauger
> On 2006-03-13, P.J. Plauger <p...@dinkumware.com> wrote:
>> "Rod Pemberton" <do_no...@sorry.bitbuck.cmm> wrote in message
>> news:dv4kqf$50m2$1...@news3.infoave.net...
>>>> > Essentially, you have a software patent through copyright.
>>>>
>>>> Bullshit.
>>>
>>> Wether you believe me or not, I believe you have a software patent
>>> through
>>> the use of a copyright. Copyright-misuse of this sort has resulted in
>>> fortfeiture of copyright. I suspect you've never heard of
>>> copyright-misuse:
>>> http://en.wikipedia.org/wiki/Copyright_misuse
>>
>> Stop hyperventilating.
>
> You _did_ suggest that you owned the idea of using a common function
> with those particular side-effects and return values to implement a
> floor and ceil function.
Really? What I said was:
: 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.
So I claim credit for inventing it. Absent a patent (for which I
didn't file) there's no hint of ownership in that statement, IMO.
I think of all the people who claim to have invented various
concepts in the C++ Standard; none of them were accused of claiming
ownership of any keywords as a result of their invention.
Further down in that post, I also said:
: 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.
Please note the emphasis on verbatim copying, which is indeed
the stuff of copyright protection. I see no other claim beyond
that.
If I've missed a quote that can be construed as a claim of
"idea ownership" I'd appreciate having it pointed out to me.
> Owning "ideas" is outside of copyright law.
Yeah, I think I pointed that out once or twice myself. But
thanks for reminding me.
> You
> can own the specific token sequences implementing each function, but you
> seem to think you own the idea of having a third function that works in
> a particular way to do most of the work that is shared in common between
> floor() and ceil().
No, *you* seem to think I think that. What I observed, and provided
some supporting evidence for, was that writing ceil in terms of such
a utility function was a particularly unique expression, and hence
well covered by copyright law for all its brevity. And I pointed out
that the particular copying involved not just the concept of such a
function but its name, argument types, argument order, and return
codes. I invented it, first wrote it down, copyrighted it, and derive
value from it. Those are all damn good reasons for me to object even
to the copying of a single line, particularly a literal copying.
> (Note that even without this I don't dispute that
> this was still infringement, but that it easily could have not been if
> he'd implemented his own ceil(), even if he had still used a _Dint()
> function.)
I have trouble parsing that one, but I think you're saying that some
variant of ceil that uses a _Dint-like function might not infringe.
And that's quite possible, since I can't and don't claim ownership
of the *idea* of a function like _Dint.
> You said "some creativity, but not much", in comparing the #define's of
> FP_* in his math.h vs your own differently-named constants internal to
> _Dint. However, the token sequences "# define" and "( - 1 )" (etc)
> clearly lack originality and are thus not copyrightable. The idea of
> using -1 to represent normal, -2 to represent denormalised values, etc,
> is an idea rather than an expression of an idea, and thus also not
> copyrightable.
Uh, no. I've learned that you like to parse things down until you
can find some small arena -- usually somewhere off to the side --
where you can claim a partial victory of logic (and then map that
to total victory). But even by your standards this is pushing
things. Try convincing a welder and a stenographer on a jury that
that set of defines wasn't a close copy of the original. They
would know better.
> What's left there? The names. Which he didn't use. I
> think the basic disconnect here is that you do not understand the fact
> that there do exist categories of works that are not eligible for
> copyright protection.
I think I do, and I think you're straining at gnats and swallowing
camels in your zeal to be right.
Richard G. Riley
Before I plaguarise this, did you make it up or is at "an old one"?
Excellent. Adapted to target issues of course
Juuso Hukkanen
>On 2006-03-11, Gregory Pietsch <GK...@flash.net> wrote:
>> I'm writing a portable implementation of the C standard library for
>I would like to help with this, I have ideas on implementing stdio, and
Perhaps MinGW's C library package could be used as material, after all
it is distributed as a public domain.
files available from www.mingw.org
Browseable files also through mirrors e.g.:
http://geog-www.sbs.ohio-state.edu/grads/jcoleman/MinGW/include/
btw, I use the opportunity to thank you all who have been patiently &
unselfisly posting codes to public domain. The CLC-wiki - project will
certainly be a very important resource for many - Keep up with good
work!
Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
Keith Thompson
> On 12 Mar 2006 05:44:28 GMT, Jordan Abel <rand...@gmail.com> wrote:
>>On 2006-03-11, Gregory Pietsch <GK...@flash.net> wrote:
>>> I'm writing a portable implementation of the C standard library for
>
>>I would like to help with this, I have ideas on implementing stdio, and
>
> Perhaps MinGW's C library package could be used as material, after all
> it is distributed as a public domain.
>
> files available from www.mingw.org
Since many people misuse the term "public domain", I checked on this.
According to <http://www.mingw.org/licensing.shtml>, the basic MinGW
runtime code is indeed "uncopyrighted and placed in the public
domain". (This is distinct from being copyrighted and released under
an open source license such as the GPL.)
P.J. Plauger
news:tcche3-...@quark.hadron...
Just made it up. But feel free to recycle it, unattributed.
Footnotes give me hives.
Jordan Abel
I've said some things that I didn't mean, and I'll admit that it's hard
for me to know when to drop something.
Richard G. Riley
I've had a long day, and can't help but wonder if you're going to get
a reply which says
"what thread? Please read these posting guidelines ... context ..."
sorry. Just joking
Michael Mair
> We're just starting to build the competitive analysis part of
> our web site to go with our new product launch. Soon you will
> be able to see a few comparisons between our new library and
> what comes with different compilers. And we'll provide a few
> essays on the lesser known pitfalls of numerical computing.
> Maybe then you'll see the point in licensing yet another
> library when you already have one you've been using for years.
About when will that be?
At a quick glance, your "news" page is more of an "olds" page
and the tested implementations page could use an update, too
(I'd expect at least one more recent Microsoft library tested
for C++ conformance even though V6 still is in wide use). No
offense meant, I know how fast time can creep along...
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Jordan Abel
Yeah... there was a reason for
>>X-No-Context: This message is about the thread in general, not the message which appears last in the References header.
But no-one ever looks at headers.
Ben Pfaff
> Yeah... there was a reason for
>
>>>X-No-Context: This message is about the thread in general, not
>>>the message which appears last in the References header.
Context should go in the message, not in the headers.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Jordan Abel
> Jordan Abel <rand...@gmail.com> writes:
>
>> Yeah... there was a reason for
>>
>>>>X-No-Context: This message is about the thread in general, not
>>>>the message which appears last in the References header.
>
> Context should go in the message, not in the headers.
It wasn't context. It was a statement that there was no relevant context
in the message that was being replied to, so the entire quoted text was
snipped :P
P.J. Plauger
news:47moreF...@individual.net...
> P.J. Plauger schrieb:
>> We're just starting to build the competitive analysis part of
>> our web site to go with our new product launch. Soon you will
>> be able to see a few comparisons between our new library and
>> what comes with different compilers. And we'll provide a few
>> essays on the lesser known pitfalls of numerical computing.
>> Maybe then you'll see the point in licensing yet another
>> library when you already have one you've been using for years.
>
> About when will that be?
I was hoping for about another week or so, but the Berlin
C and C++ meetings are looming, so we probably won't put up
the new site until after then.
> At a quick glance, your "news" page is more of an "olds" page
Indeed.
> and the tested implementations page could use an update, too
Interestingly enough, when we put up the new competitive analysis
pages, you'll find that the other libraries have hardly changed
their degree of conformance in the past three years.
> (I'd expect at least one more recent Microsoft library tested
> for C++ conformance even though V6 still is in wide use). No
> offense meant, I know how fast time can creep along...
No offense taken. We've been working so hard and so long on
all sorts of new things that we failed to notice how much time
has gone by, at least until recently. It's amazingly easy to
let your web site stagnate just one more month...
niiru
> (It's a lot more fun to write new code and spread it
> around the world with your name on it than it is to write tests
> and run them.)
For someone who has written many mails in this thread ventilating about
the effort he has put into his work being disrespected, this is an
incredibly cheap shot
at those who freely give away the fruits of their own endeavours. You
should
hold yourself to a higher standard.
On the subject of holding yourself to higher standards, the evolution
of
http://www.dinkumware.com/conform_c.html
is an interesting exercise in removal of issues in your testing /
test harness that have been pointed out to you over time. I see no
acknowledgement of quiet removal of previous inaccuracies, nor
acknowledgement of the disputed nature of several of the claims that
remain.
Having said that, I find the apparent blatant violation of your
copyright
reprehensible, but your defence thereof went steadily downhill after
your first post.
P.J. Plauger
news:1142344009.9...@u72g2000cwu.googlegroups.com...
> P.J. Plauger wrote:
>> (It's a lot more fun to write new code and spread it
>> around the world with your name on it than it is to write tests
>> and run them.)
>
> For someone who has written many mails in this thread ventilating about
> the effort he has put into his work being disrespected,
Not quite. It was my *ownership* that I found disrespected.
Nobody has to admire the effort I put into it, except me.
> this is an
> incredibly cheap shot
> at those who freely give away the fruits of their own endeavours. You
> should
> hold yourself to a higher standard.
Excuse me, but I thought I was stating the obvious, and I certainly
meant no disrespect to the people who do give away their work. It
is simply true that it's more fun to write new code than to write
tests -- it is for me. One of the regrettable weaknesses of the
open source movement is that it never seems to produce enough tests.
And it is simply true that the major reward most contributors get
is having their name on useful software that is widely dispersed.
If you see disrespect in those observations, I'm sorry.
> On the subject of holding yourself to higher standards, the evolution
> of
>
> http://www.dinkumware.com/conform_c.html
>
> is an interesting exercise in removal of issues in your testing /
> test harness that have been pointed out to you over time. I see no
> acknowledgement of quiet removal of previous inaccuracies, nor
> acknowledgement of the disputed nature of several of the claims that
> remain.
I'm struggling a bit on this one. The only thing I can recall along
these lines was a challenge from Walter Bright (IIRC) that we
hadn't put up tests of his latest version. We didn't have time to
retest then, and I didn't think his product was worth all that
much attention, so I acceded to his wishes and simply dropped
that particular comparison. There was never any challenge to the
accuracy of what we said about the version we tested.
I've heard a few grumbles about the low scores some products
get from us, but nodoby has come forth with any evidence that
they're inaccurate or biased. Sure, we test with our own
proprietary test suite, but there are others. (We tested the
same products with Perennial's suite, to verify that our numbers
are sane, but we're not at liberty to disclose those test
results in detail.) Sadly, the open source tests don't check for
conformance, just regression against earlier behavior. And they're
*very* much tied to the nonstandard behavior of what they test.
> Having said that, I find the apparent blatant violation of your
> copyright
> reprehensible, but your defence thereof went steadily downhill after
> your first post.
Again, I'm sorry you have a lower opinion of my integrity,
but I suggest you try to tease apart your disappointment in
what I said from your belief that I was out of bounds in
saying it.
Rod Pemberton
"Keith Thompson" <ks...@mib.org> wrote in message
news:ln1wx5n...@nuthaus.mib.org...
> Juuso Hukkanen <juuso_...@tele3d.net> writes:
> > On 12 Mar 2006 05:44:28 GMT, Jordan Abel <rand...@gmail.com> wrote:
> >>On 2006-03-11, Gregory Pietsch <GK...@flash.net> wrote:
> >>> I'm writing a portable implementation of the C standard library for
> >
> >>I would like to help with this, I have ideas on implementing stdio, and
> >
> > Perhaps MinGW's C library package could be used as material, after all
> > it is distributed as a public domain.
> >
> > files available from www.mingw.org
> [...]
>
> Since many people misuse the term "public domain", I checked on this.
> According to <http://www.mingw.org/licensing.shtml>, the basic MinGW
> runtime code is indeed "uncopyrighted and placed in the public
> domain". (This is distinct from being copyrighted and released under
> an open source license such as the GPL.)
Unfortunately, I've looked at every file in the MinGW library. There are
few copyrighted code pieces in their source. But, that number is small and
all the rest seems to be PD. (This is because they mix files from the
"basic MinGW" and the "Win32 API" and the C runtime into the same
directories.)
Rod Pemberton
Old Wolf
> _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;
> }
>
An obvious case of Plaugerism.
(sorry)
Richard Heathfield
> An obvious case of Plaugerism.
> (sorry)
Go to your room.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Ronald Bruck
<p...@dinkumware.com> wrote:
> "Ronald Bruck" <br...@math.usc.edu> wrote in message
> news:130320061219545958%br...@math.usc.edu...
>
[Intermediate posts elided]
> > At first I thought, "Oh, this is like SCO's suit against IBM". I
> > wondered what could possibly be in math.h which isn't obvious.
>
> Wow.
:-) I guess you have to read this in light of my later comments.
Perhaps what I should have said is, "which isn't obvious compared to
what's in a BLAS and LAPACK implementation."
AFAIK, there is no C version of LAPACK. They just run the Fortran
through f2c. One is almost always well-advised to use the chip
manufacturer's BLAS (and LAPACK, when available). There is a program
(ATLAS) which tunes the BLAS, but the results aren't usually as good as
the chip manufacturer's optimized code. However, concerning your
further point [below], I don't know how thoroughly tested these
libraries are.
My own personal peeve: my own work uses very high-precision arithmetic
(up to 16384 bits of precision), the purpose being to recognize
specific algebraic numbers. There's little point in trying to optimize
a BLAS for this, at least until cache sizes grow enormously. And
LAPACK turns out to have many, many constants hard-wired in, based on
IEEE arithmetic. Every time I need one of the routines from LAPACK I
have to trace it all back and rewrite, often modifying the logic, which
is so specific to IEEE754. That gets old fast. (But at least I'm
unlikely to be accused of copyright violations.) And of course math.h
is useless.
>
> > I even
> > wondered whether you were THE P. J. Plauger, or whether the post was a
> > forgery.
Which ISN'T paranoid, given the way Usenet works.
> >...Such a literature is one of the advantages
> > of an academic establishment.)
>
> Us greedy capitalists read the literature too, y'know.
That's why it's there! And as I'm sure YOU know, many academics are
also involved in commercial enterprises. The A of RSA is right here at
the University of Southern California.
> > So I repeat, what's the point? (Understand, I've only ever developed
> > on the P4, the AMD64, and the PPC, so I may not fully appreciate the
> > difficulties.)
>
> Evidently. You cited the most obvious -- bugs. We've developed what
> I believe to be the best math testing harness in the business (and
> in academia as well, from what I've seen so far). We've used it to
> test all sorts of math libraries out there, and we've found all
> sorts of problems. Don't get me wrong, the basic double math library
> required by C89 is generally pretty good when you get it from the
> likes of Microsoft, IBM, or Sun.
Agreed, testing is a truely woeful situation. Not just in the Open
Source and academic community--these are AFAIK always acknowledged to
be at the user's risk. What I don't like is being used as a guinea pig
by the major COMMERCIAL players--most notoriously, Microsoft.
> >
> Then there's the matter of completeness. We provide a complete
> set of C99 math functions in all four IEEE precisions -- 24-bit,
> 53-bit, 64-bit, and 113-bit.
First I've heard of 113-bit precision. I'll check it out.
> >
> What we offer, by contrast, is the assurance that you can use
> our library on a variety of popular platforms, all the functions
> you need are there, and they work right everywhere.
I run SuSE Linux 9.3 on an AMD64 platform (FX55). (This is the fastest
system I've found at the multiprecision stuff.) I don't see this on
your list, and a $600 license for source is a bit high for my budget.
Of course the 32-bit version would work, but how much performance would
I lose?
--Ron Bruck
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
niiru
> > On the subject of holding yourself to higher standards, the evolution
> > of
> >
> > http://www.dinkumware.com/conform_c.html
> >
> > is an interesting exercise in removal of issues in your testing /
> > test harness that have been pointed out to you over time. I see no
> > acknowledgement of quiet removal of previous inaccuracies, nor
> > acknowledgement of the disputed nature of several of the claims that
> > remain.
>
> I'm struggling a bit on this one. The only thing I can recall along
> these lines was a challenge from Walter Bright (IIRC) that we
> hadn't put up tests of his latest version. We didn't have time to
> retest then, and I didn't think his product was worth all that
> much attention, so I acceded to his wishes and simply dropped
> that particular comparison. There was never any challenge to the
> accuracy of what we said about the version we tested.
Your memory seems to be slipping. Let's start with
http://sourceware.org/ml/libc-alpha/2004-07/msg00120.html
and followups. The followups contain examples of the suspect
nature of some of your tests which I should think earns them the
label "disputed".
> I've heard a few grumbles about the low scores some products
> get from us,
Perhaps because of bogus results of broken tests?
> but nodoby has come forth with any evidence that they're
> inaccurate or biased.
In fact it would seem that they have, and you yourself recognised it.
Let me add another: anyone with access to a copy
can verify for themselves that your claim of GCC 3.2 that
"(Setting the GCC command line switch to indicate that the
language is C99 does not set the macro __STDC_VERSION__
to the correct value for C99 -- it remains set to 199409L.)"
is without merit. As documented, that switch is -std=c99.
Customers might start wondering about the quality of these tests.
CBFalconer
> P.J. Plauger wrote:
>
>>> On the subject of holding yourself to higher standards, the
>>> evolution of
>>>
>>> http://www.dinkumware.com/conform_c.html
>>>
>
> Customers might start wondering about the quality of these tests.
Please do not snip attributions for material you quote. Your
message would imply that PJP wrote the portion marked ">>>" above.
He did not, you did. This is either carelessness or sneakiness.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>