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.
Sincerely, Gregory Pietsch 110  8449 
"Gregory Pietsch" <GK**@flash.net> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.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.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
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.
Sincerely, Gregory Pietsch
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) */
---------------------------------------------------------------------
Where do you have that from?
It is not in the C99 standard... Maybe in some other standard?
jacob
jacob navia <ja***@jacob.remcomp.fr> writes: 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
On 2006-03-11, P.J. Plauger <pj*@dinkumware.com> wrote: "Gregory Pietsch" <GK**@flash.net> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.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.
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?)
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.
Sincerely, Gregory Pietsch
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/...sh/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/i...ers/index.html
regards, chip
On Sat, 11 Mar 2006 16:41:16 -0500, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote: "Gregory Pietsch" <GK**@flash.net> wrote in message
news:11**********************@i39g2000cwa.googleg roups.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.
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 =----
Mark McIntyre <ma**********@spamcop.net> writes: On Sat, 11 Mar 2006 16:41:16 -0500, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
"Gregory Pietsch" <GK**@flash.net> wrote in message
news:11**********************@i39g2000cwa.google groups.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
P.J. Plauger said: "Gregory Pietsch" <GK**@flash.net> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.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 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)
On 2006-03-12, Ben Pfaff <bl*@cs.stanford.edu> wrote: Mark McIntyre <ma**********@spamcop.net> writes:
On Sat, 11 Mar 2006 16:41:16 -0500, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
"Gregory Pietsch" <GK**@flash.net> wrote in message
news:11**********************@i39g2000cwa.googl egroups.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.
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.
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.
--
"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/>
Jordan Abel <ra*******@gmail.com> writes: On 2006-03-12, Ben Pfaff <bl*@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: bl*@cs.stanford.edu
web: http://benpfaff.org
Jordan Abel <ra*******@gmail.com> writes: On 2006-03-12, Ben Pfaff <bl*@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[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\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;}
On 2006-03-11, CBFalconer <cb********@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)
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.
On 2006-03-12, Ben Pfaff <bl*@cs.stanford.edu> wrote: Jordan Abel <ra*******@gmail.com> writes:On 2006-03-12, Ben Pfaff <bl*@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.
"Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:du**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com... P.J. Plauger said:
"Gregory Pietsch" <GK**@flash.net> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.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 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.
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.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
On 2006-03-12, P.J. Plauger <pj*@dinkumware.com> wrote: "Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:du**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
P.J. Plauger said:
"Gregory Pietsch" <GK**@flash.net> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.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 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.
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.
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]
On 2006-03-11, Gregory Pietsch <GK**@flash.net> 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.
Sincerely, Gregory Pietsch
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]
"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.
I will henceforth be monitoring this
site with extreme interest.
It would be a boon to the site if you were to do that.
-- http://members.dodo.com.au/~netocrat
On 2006-03-12, Netocrat <ne******@dodo.com.au> wrote: "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.
I will henceforth be monitoring this
site with extreme interest.
It would be a boon to the site if you were to do that.
On Sun, 12 Mar 2006 07:13:47 +0000, Jordan Abel wrote:
[re pages deleted from clc-wiki.net due to copyright infringement claims;
sci.math dropped from headers] Deleting my stdio.h, which was created after this controversy [and given
that I don't even have a copy of TSCL], seems a bit overzealous.
Yes, a little trigger-happy. I've restored it.
-- http://members.dodo.com.au/~netocrat
Jordan Abel said: On 2006-03-12, P.J. Plauger <pj*@dinkumware.com> wrote: "Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:du**********@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...)
--
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)
P.J. Plauger said: Read what I said again.
Sure. Here we go...
"At a quick glance, I'd say you're violating my copyright in the most
blatant and irresponsible manner. If the infringing stuff isn't off the
internet in short order, I will be taking legal action."
I'm giving him a chance, but I make no bones
about my Plan B.
Okay. But, given that Gregory is no stranger to the group and is known not
to be an antisocial git, I'd have tried to word plan A a little more
gently, that's all.
I will henceforth be monitoring this site with extreme interest.
That can only be good for all concerned.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Netocrat said: I've deleted all code-containing pages from the "Portable C library source
code implementation" category and its sub-categories on clc-wiki.net.
Good move. Perhaps it would be a good idea to start again, and ban anyone
from participating if they have access to a copy of TSCL. (In a curious
omission, I never actually got around to buying a copy myself, so I'd be
game for that.)
This morning, I took the opportunity to drop in on the C wiki, and I have to
say it does look like it's becoming a useful site, current debacle
notwithstanding. I am delighted, and encouraged. I may start dropping by a
little more often.
--
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 wrote: On 2006-03-11, CBFalconer <cb********@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/
On 2006-03-12, we******@gmail.com <we******@gmail.com> wrote: Jordan Abel wrote: On 2006-03-11, CBFalconer <cb********@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.
Ben Pfaff wrote: Jordan Abel <ra*******@gmail.com> writes:
On 2006-03-12, Ben Pfaff <bl*@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
Richard Heathfield <in*****@invalid.invalid> writes: 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.
On 2006-03-12, Richard Heathfield <in*****@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.
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.
Nick Keighley wrote:
Ben Pfaff wrote: Jordan Abel <ra*******@gmail.com> writes:
On 2006-03-12, Ben Pfaff <bl*@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.
I couldn't find the function definition for _Dint.
Was it out there?
--
pete
Richard Heathfield <in*****@invalid.invalid> writes: Jordan Abel said:
On 2006-03-12, P.J. Plauger <pj*@dinkumware.com> wrote: "Richard Heathfield" <in*****@invalid.invalid> wrote in message
news:du**********@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
pete wrote: Nick Keighley wrote:
Ben Pfaff wrote: Jordan Abel <ra*******@gmail.com> writes:
> On 2006-03-12, Ben Pfaff <bl*@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.
I couldn't find the function definition for _Dint.
Was it out there?
I think you misunderstand. _Dint() is *not* part of the standard (the
initial underscore is a strong hint) it is part of the particular
implementation. If such internals match then the chances are
vanishingly
small that one is not a derived version of the other. They could also
be derived from a common source.
--
Nick Keighley
"Nick Keighley" wrote:
pete wrote: Nick Keighley wrote: >
> Ben Pfaff wrote:
> > Jordan Abel <ra*******@gmail.com> writes:
> >
> > > On 2006-03-12, Ben Pfaff <bl*@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.
I couldn't find the function definition for _Dint.
Was it out there?
I think you misunderstand. _Dint() is *not* part of the standard
(the
initial underscore is a strong hint) it is part of the particular
implementation. If such internals match then the chances are
vanishingly
small that one is not a derived version of the other. They could
also
be derived from a common source.
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
Phil Carmody said: Richard Heathfield <in*****@invalid.invalid> writes:
Jordan Abel said:
> On 2006-03-12, P.J. Plauger <pj*@dinkumware.com> wrote:
>> "Richard Heathfield" <in*****@invalid.invalid> wrote in message
>> news:du**********@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.
--
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)
"John F" <sp**@127.0.0.1> wrote in message
news:44***********************@tunews.univie.ac.at ... "Nick Keighley" wrote:
pete wrote: Nick Keighley wrote:
>
> Ben Pfaff wrote:
> > Jordan Abel <ra*******@gmail.com> writes:
> >
> > > On 2006-03-12, Ben Pfaff <bl*@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.
I couldn't find the function definition for _Dint.
Was it out there?
I think you misunderstand. _Dint() is *not* part of the standard (the
initial underscore is a strong hint) it is part of the particular
implementation. If such internals match then the chances are
vanishingly
small that one is not a derived version of the other. They could also
be derived from a common source.
I was of the opinion that the name was derived or borrowed from Fortrans
DINT (truncate towards zero).
It performs an eqal operation in the implementations above so that seems
reasonable.
For all its brevity, this is a remarkably telling example of the
distinct worth of a particular implementation. _Dint is indeed my
own invention, evolved over several decades of writing portable
and efficient math functions. It is *not* simply a C implementation
of an old Fortran function, despite the similarity of names. Note
that it takes a second argument. Instead:
_Dint(double *px, int n) clears all but the first n bits to the right
of the (true) binary point in the floating-point value *px, then
returns a code describing the nature of the *discarded* value.
_Dint(&x, -1) truncates x to the nearest *even* value, a critical
test in function pow that's messy to write otherwise.
_Dint(&x, 0) truncates x to an integer and returns zero only
if x was already an integer. It returns other codes if x was a
NaN, an infinity, or a denormal. A good way to kick off all
sorts of math functions.
_Dint(&x, 1) truncates x to the nearest multiple of 1/2, and
tells you whether the result was an exact multiple of 1/2.
Round to nearest, anyone?
_Dint(&x, 2) truncates x to the nearest multiple of 1/4, very
handy for determining a quadrant.
_Dint(&x, (FBITS - 1) / 2) helps split a value into pieces so
you can perform arbitrary-precision using normal floating-point
operations.
At a quick count, we use _Dint in four dozen places in the
Dinkumware C library. It's the binary analog to the most
important (IMO) innovation in the evolving IEEE-754R decimal
floating-point package -- the ability to round to a given
number of decimal digits. But you will notice that _Dint is
*not* specified by the C Standard, and it is *not* present in
other implementations of the Standard C library. (Nor is the
decimal analog in IEEE-754R so clearly delineated.)
I consider _Dint one of the more valuable components of the
Standard C library that I originally wrote and that is now
being licensed by my company, Dinkumware, Ltd. (my
principal source of income for the past decade or so). I
don't take lightly the notion that it can be copied and
used verbatim in ways that took me quite some time to
work out. That's why something as seemingly lightweight as:
return _Dint (&x, 0) < 0 && 0.0 < x ? x + 1.0 : x;
is IMO a serious infringement. It takes more than removing
two parens and adding a space to bring something new to the
party.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
"P.J. Plauger" wrote: "John F" <sp**@127.0.0.1> wrote:
"Nick Keighley" wrote:
pete wrote:
Nick Keighley wrote:
>
[SNIP
]>>>> > > _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.
I couldn't find the function definition for _Dint.
Was it out there?
I think you misunderstand. _Dint() is *not* part of the standard
(the
initial underscore is a strong hint) it is part of the particular
implementation. If such internals match then the chances are
vanishingly
small that one is not a derived version of the other. They could
also
be derived from a common source.
I was of the opinion that the name was derived or borrowed from
Fortrans DINT (truncate towards zero).
It performs an eqal operation in the implementations above so that
seems reasonable.
For all its brevity, this is a remarkably telling example of the
distinct worth of a particular implementation. _Dint is indeed my
own invention, evolved over several decades of writing portable
and efficient math functions. It is *not* simply a C implementation
of an old Fortran function, despite the similarity of names. Note
that it takes a second argument. Instead:
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
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
On 2006-03-12, P.J. Plauger <pj*@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.
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.
On 2006-03-12, Richard G. Riley <rg****@gmail.com> wrote: On 2006-03-12, Richard Heathfield <in*****@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. 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.
On 2006-03-12, Jordan Abel <ra*******@gmail.com> wrote: On 2006-03-12, Richard G. Riley <rg****@gmail.com> wrote: On 2006-03-12, Richard Heathfield <in*****@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/~matlo...g.html#tth_sEc
Nick Keighley wrote:
pete wrote: Nick Keighley wrote:
Ben Pfaff wrote:
> Jordan Abel <ra*******@gmail.com> writes:
>
> > On 2006-03-12, Ben Pfaff <bl*@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
> >> derivative work of the latter, The former is obviously a
> >> 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.
I couldn't find the function definition for _Dint.
Was it out there?
I think you misunderstand. _Dint() is *not* part of the standard (the
initial underscore is a strong hint) it is part of the particular
implementation. If such internals match then the chances are
vanishingly
small that one is not a derived version of the other. They could also
be derived from a common source.
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
"John F" <sp**@127.0.0.1> wrote in message
news:44***********************@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.
..... 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
"Jordan Abel" <ra*******@gmail.com> wrote in message
news:sl**********************@random.yi.org... On 2006-03-12, P.J. Plauger <pj*@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
Dinkumware, Ltd. http://www.dinkumware.com
"pete" <pf*****@mindspring.com> wrote in message
news:44***********@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.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
In article <SK******************************@giganews.com>,
"P.J. Plauger" <pj*@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.
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.
"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk... In article <SK******************************@giganews.com>,
"P.J. Plauger" <pj*@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
"P.J. Plauger" wrote: "John F" <sp**@127.0.0.1> wrote:
_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 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
"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:4d********************@giganews.com...
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.
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
On 2006-03-12, P.J. Plauger <pj*@dinkumware.com> wrote: "John F" <sp**@127.0.0.1> wrote in message
news:44***********************@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.
"John F" <sp**@127.0.0.1> wrote in message
news:44***********************@tunews.univie.ac.at ... "P.J. Plauger" wrote: "John F" <sp**@127.0.0.1> wrote:
_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 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.
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
Dinkumware, Ltd. http://www.dinkumware.com
"Rod Pemberton" <do*********@sorry.bitbuck.cmm> wrote in message
news:dv***********@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
Dinkumware, Ltd. http://www.dinkumware.com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Robert Mark Bram |
last post by:
Howdy All!
I am trying to write a very brief comparison of the Date and Math objects in
terms of instance v static objects. What I have below is my best so far. Any
criticisms or suggestions are...
|
by: Anon Email |
last post by:
Hi people,
I'm learning about header files in C++. The following is code from
Bartosz Milewski:
// Code
const int maxStack = 16;
class IStack
|
by: cwdjrxyz |
last post by:
Javascript has a very small math function list. However there is no
reason that this list can not be extended greatly. Speed is not an
issue, unless you nest complicated calculations several levels...
|
by: sathyashrayan |
last post by:
Following are the selected thread from the date:30-jan-2005 to
31-jan-2005. I did not use any name because of the subject is important.
You can get the original thread by typing the subject...
|
by: Thomas Lumley |
last post by:
What does the standard guarantee about the accuracy of eg the
trigonometric functions? There is obviously an implementation-dependent
upper bound on the accuracy, since the answer is stored in a...
|
by: Sensei |
last post by:
I have a quick question about the math library included in the standard
C90 (and 99).
The gcc, xlc and possibly other compilers/linkers on some unix
platforms cannot use any math functions in...
|
by: Ark |
last post by:
Hi everyone,
Does anyone know if Direct3D overloads System.Math
functions?
Also is it possible to access the base functions of the
overloaded function (in other words restore original of
the...
|
by: silellak |
last post by:
I have found an odd error when using an XSL stylesheet transform. We
have a Notes/Domino application with the following line of code in one
of the stylesheets:
<xsl:value-of...
|
by: Francine.Neary |
last post by:
I'm finding it really hard to keep some of these things straight...
For example, fputs is to puts as fprintf is to printf, except that
fputs has the file handle at the end and fprintf at the...
|
by: Jason Doucette |
last post by:
I am converting a C-style unit into a C++ class. I have an
implementation function that was defined in the .cpp file (so it was
hidden from the interface that exists in the .h file). It uses a...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
