Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Don wrote: Lars T. Kyllingstad wrote: Sean Kelly wrote: Walter Bright wrote: Andrei Alexandrescu wrote: Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. The license is, from my copy of the 1987 edition: Although this book and its programs are copyrighted, we specifically authorize you, the reader of this book, to make one machine-readable copy of each program for your own use. [...] Distribution of machine-readable programs (either as copied by you or as purchased) to any other person is not authorized. I'll have to dig my copy out and see if it's any better. Really, if the code can't even legally be used internally for an application developed by a team of programmers then the book is nearly worthless. I wouldn't go so far as to call it worthless. It may not be a repository of freely usable algorithms, but it is a nice textbook that covers a wide range of topics and methods. A lot of the algorithms in NR are just their versions of classic (and public domain) algorithms found freely available on NETLIB. Yes, they basically grabbed algorithms from NETLIB and added their own bugs to them. So really, the licence should say: Although this book and the bugs in its programs are copyrighted, we specifically authorize you, the reader of this book, to make one machine-readable copy of each bug for your own use. [...] :) -Lars
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
On 2009-05-17 12:02:31 +0200, Lars T. Kyllingstad pub...@kyllingen.nospamnet said: Don wrote: Lars T. Kyllingstad wrote: Sean Kelly wrote: Walter Bright wrote: Andrei Alexandrescu wrote: Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. The license is, from my copy of the 1987 edition: Although this book and its programs are copyrighted, we specifically authorize you, the reader of this book, to make one machine-readable copy of each program for your own use. [...] Distribution of machine-readable programs (either as copied by you or as purchased) to any other person is not authorized. I'll have to dig my copy out and see if it's any better. Really, if the code can't even legally be used internally for an application developed by a team of programmers then the book is nearly worthless. I wouldn't go so far as to call it worthless. It may not be a repository of freely usable algorithms, but it is a nice textbook that covers a wide range of topics and methods. A lot of the algorithms in NR are just their versions of classic (and public domain) algorithms found freely available on NETLIB. Yes, they basically grabbed algorithms from NETLIB and added their own bugs to them. So really, the licence should say: Although this book and the bugs in its programs are copyrighted, we specifically authorize you, the reader of this book, to make one machine-readable copy of each bug for your own use. [...] :) -Lars The extremely restrictive license of numerical recipes means that one should *always* try to avoid using their version. The book does a reasonable job at explaining some good algorithms (but often not the best/newest) but normally one can find good alternatives, or take original NETLIB algorithms. The unresonable license of NR was one of the main reasons for GSL (which has its own set of problems). Fawzi
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Andrei Alexandrescu wrote: Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. Not counting the criticism about its algorithms being plain wrong... (I'm not able to judge myself). http://www.uwyo.edu/buerkle/misc/wnotnr.html http://amath.colorado.edu/computing/Fortran/numrec.html Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Andrei Alexandrescu wrote: Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. The license is, from my copy of the 1987 edition: Although this book and its programs are copyrighted, we specifically authorize you, the reader of this book, to make one machine-readable copy of each program for your own use. [...] Distribution of machine-readable programs (either as copied by you or as purchased) to any other person is not authorized.
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Walter Bright wrote: Andrei Alexandrescu wrote: Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. The license is, from my copy of the 1987 edition: Although this book and its programs are copyrighted, we specifically authorize you, the reader of this book, to make one machine-readable copy of each program for your own use. [...] Distribution of machine-readable programs (either as copied by you or as purchased) to any other person is not authorized. (Fumbling below the desk, in search of the shotgun...) Has anyone found a 20 years newer copyright on this?
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Walter Bright wrote: Andrei Alexandrescu wrote: Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. The license is, from my copy of the 1987 edition: Although this book and its programs are copyrighted, we specifically authorize you, the reader of this book, to make one machine-readable copy of each program for your own use. [...] Distribution of machine-readable programs (either as copied by you or as purchased) to any other person is not authorized. I'll have to dig my copy out and see if it's any better. Really, if the code can't even legally be used internally for an application developed by a team of programmers then the book is nearly worthless.
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Sean Kelly wrote: Walter Bright wrote: Andrei Alexandrescu wrote: Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. The license is, from my copy of the 1987 edition: Although this book and its programs are copyrighted, we specifically authorize you, the reader of this book, to make one machine-readable copy of each program for your own use. [...] Distribution of machine-readable programs (either as copied by you or as purchased) to any other person is not authorized. I'll have to dig my copy out and see if it's any better. Really, if the code can't even legally be used internally for an application developed by a team of programmers then the book is nearly worthless. I wouldn't go so far as to call it worthless. It may not be a repository of freely usable algorithms, but it is a nice textbook that covers a wide range of topics and methods. A lot of the algorithms in NR are just their versions of classic (and public domain) algorithms found freely available on NETLIB. So even if one cannot write them directly from the book, there are other ways to get at them. What one can't always get from NETLIB are explanations of how the routines work, and why they're designed the way they are, and that's where NR comes in handy. -Lars
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Lars T. Kyllingstad wrote: 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) If you're talking about any one of the books that come up when entering Numerical Recipes in the Amazon search box, I'd say that those recipes are freely usable. That's why they're in the books. Checking, of course may be good, but if anyone publishes recipes in a book and then sues people for actually using them, I'd sue *them* for entrapment.
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
On Fri, May 15, 2009 at 12:22 PM, Georg Wrede georg.wr...@iki.fi wrote: Lars T. Kyllingstad wrote: 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) If you're talking about any one of the books that come up when entering Numerical Recipes in the Amazon search box, I'd say that those recipes are freely usable. That's why they're in the books. Checking, of course may be good, but if anyone publishes recipes in a book and then sues people for actually using them, I'd sue *them* for entrapment. Well you'd better call your lawyer then. :-) The usage terms on the classic Numerical Recipes are terrible. Basically you're only allowed to use their code if you purchased a copy of the book. Which basically means if you use their code, then you are not allowed to share the NR portion of your code with anyone who does not own the book. Their code is not so pretty anyway, so much better to just read the ideas and implement it yourself, thus avoiding any potential legal hassle. SciPy has recently done a sweep through their code purging anything that looks like it was derived from NR code for this reason. They also went through and made it clear in all comments which refer to NR for explanations of algorithms that they did NOT use NR code as a basis for the code in SciPy. --bb
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Georg Wrede wrote: Lars T. Kyllingstad wrote: 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) If you're talking about any one of the books that come up when entering Numerical Recipes in the Amazon search box, I'd say that those recipes are freely usable. That's why they're in the books. Checking, of course may be good, but if anyone publishes recipes in a book and then sues people for actually using them, I'd sue *them* for entrapment. Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. Andrei
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Andrei Alexandrescu wrote: Georg Wrede wrote: Lars T. Kyllingstad wrote: 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) If you're talking about any one of the books that come up when entering Numerical Recipes in the Amazon search box, I'd say that those recipes are freely usable. That's why they're in the books. Checking, of course may be good, but if anyone publishes recipes in a book and then sues people for actually using them, I'd sue *them* for entrapment. Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. Exactly. So, what's the point? Here's a bone, widely available on the sidewalk!!! But my god, just try to chew on it, and I'll sue your [butt]. And that's one more reason to lose respect for a certain judicial system. The mere hint of such practices, really should make the law makers take a serious look at themselves. (But then again, to even become a law maker in such a system, you'd have gone throug such a chewing that the last bit of decency, sense of right, fairness, and a few other characteristics, simply have to have been erased from your mind. Heck, lawyers in even honest countries aren't respected for righteousness, fairness, integrity, or respect.) I've seen software houses in America publish their library code. And that code contained passages like this is the unpublished source code [...] copyright witheld [...] all rights reserved. Publishing freaking Unpublished can only happen in the New World.
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Bill Baxter wrote: On Fri, May 15, 2009 at 12:22 PM, Georg Wrede georg.wr...@iki.fi wrote: Lars T. Kyllingstad wrote: 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) If you're talking about any one of the books that come up when entering Numerical Recipes in the Amazon search box, I'd say that those recipes are freely usable. That's why they're in the books. Checking, of course may be good, but if anyone publishes recipes in a book and then sues people for actually using them, I'd sue *them* for entrapment. Well you'd better call your lawyer then. :-) The usage terms on the classic Numerical Recipes are terrible. Basically you're only allowed to use their code if you purchased a copy of the book. Which basically means if you use their code, then you are not allowed to share the NR portion of your code with anyone who does not own the book. Damn. It's a shame that I currently don't have a company of, say, 20 coders. Then I'd have enough slack in my turnover to take on issues like this. Here in Europe, some of those things aren't all too favorably looked upon. Just last week I read that Intel had got a fine of millions of dollars, just because they had twisted the arm of some wholeseller so that they entirely excluded AMD. Their code is not so pretty anyway, so much better to just read the ideas and implement it yourself, thus avoiding any potential legal hassle. Yes, if the algorithm is published in a book, then it's a lot easier for us to implement it, instead of translating /their/ C[++] implementation. SciPy has recently done a sweep through their code purging anything that looks like it was derived from NR code for this reason. They also went through and made it clear in all comments which refer to NR for explanations of algorithms that they did NOT use NR code as a basis for the code in SciPy. The *first* half of this century belongs to the RIAA, and their friends. And similarily, like the Soviet Union thought socialism /everywhere/ is the answer, seems like some other countries think free market /everywhere/, unhindered, is the answer. For example, TV was originally thought of as a superior medium to educate the masses, to bring equality to citizens by enabling everyone access to the same education. Today, one watches Oprah, Dr Phil, etc. and sees 3 minutes of programming, 6 minutes of commercials, and the same all over again. Watching those shows overseas, makes one cry of compassion. Here we see the shows at least a half hour at a time, interspersed (sometimes) with brief flashes, saying put commercial here. And we have jingles between programming and commercials. During the *second* half of this century, most countries and continents have adopted a more pragmatical way. (Just as in programming languages, full OOP sucks, full Purely Functional sucks, etc.) The entities will have adopted a pragmatic mix of state controlled, free market, branch cooperated, and third sector, economic systems. For example, deciding what should be showed to kids before 9am, is not a choice left to who makes programming that the average 2-second channel hopper sticks to, or who is audacious enough to have 95% of an hour commercials and only 5% programming because the audience seems to cope. That decision has to be with the FCC, or some other authority, not guided by quartal revenue. Just yesterday I watched a documentary from China. Seems like the Central Government (or whatever they're called) have adopted a way of thinking about economical issues, that kind-of strides the socialist and the market economy. Most things are according to market economy, but some things are tightly controlled. (Yes, I know, they censor the Internet heavily, but the commentators and the interviewees (some of which were economics students at regular Chinese, Shanhai, or Hong Kong universities) seemed to think that some censorship is a small price to pay for economic stability, long-term predictability, and reason in administration. Which they (according to them) couldn't have with a revolution or a shift of power.) We don't need to copy NR. All we need is to glipse at their algorithms. And anyway, D is so much more powerful that those algorithms would be, implemented in another way, anyhow.
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
On Fri, May 15, 2009 at 5:15 PM, Georg Wrede georg.wr...@iki.fi wrote: We don't need to copy NR. All we need is to glipse at their algorithms. And anyway, D is so much more powerful that those algorithms would be, implemented in another way, anyhow. THe NR in C code is basically a translated version of the NR in Fortran code. Right down to using 1-based indexing. THe NR in C++ code is the C code with a few token classes thrown in for vectors. Still using 1-based indexing. It's not something you'd really want to emulate, especially not in D. Unless you just happen to love Fortran-style code. :-) --bb
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
THe NR in C++ code is the C code with a few token classes thrown in for vectors. Still using 1-based indexing. You must be talking about NR 2 C++ code. NR 3 code uses 0-based indexing (and it allows you to use STL vectors). It's also a lot more object oriented than NR 2 and it uses templates instead of function pointer parameters. Still, it's not very usable as a library and it's not even meant to be one. It's basically a set of algorithms, so free functions would be better than classes, IMHO.
SciD (Was: Real Close to the Machine: Floating Point in D )
== Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article In my numerics library (which I've, in all modesty, named SciD) I'm converging on a package structure I'm fairly pleased with: scid.core: Internal modules, such as scid.core.traits, scid.core.tests, scid.core.exception, etc. scid.ports: Here I put ports of various packages from NETLIB and other sources. Examples of subpackages are scid.minpack, scid.quadpack, etc. These have, for the most part, rather nasty APIs, and should normally not be used directly. scid: In the root package I've placed the most ubiquitous modules, i.e. scid.vector, scid.transformation, etc. scid.calculus scid.calculus.differentiation scid.calculus.integration ... scid.linalg ... scid.nonlinear ... Specific problem areas get their own subpackages. At the moment these mostly just contain nicer interfaces to the routines in scid.ports -- drivers, if you will. Wait a minute, you have a numerics library for D that does all this stuff? I'd like to hear more about this. If/when it's in a usable state, please put it up on dsource and post it to http://prowiki.org/wiki4d/wiki.cgi?ScientificLibraries.
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
dsimcha wrote: == Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article In my numerics library (which I've, in all modesty, named SciD) I'm converging on a package structure I'm fairly pleased with: scid.core: Internal modules, such as scid.core.traits, scid.core.tests, scid.core.exception, etc. scid.ports: Here I put ports of various packages from NETLIB and other sources. Examples of subpackages are scid.minpack, scid.quadpack, etc. These have, for the most part, rather nasty APIs, and should normally not be used directly. scid: In the root package I've placed the most ubiquitous modules, i.e. scid.vector, scid.transformation, etc. scid.calculus scid.calculus.differentiation scid.calculus.integration ... scid.linalg ... scid.nonlinear ... Specific problem areas get their own subpackages. At the moment these mostly just contain nicer interfaces to the routines in scid.ports -- drivers, if you will. Wait a minute, you have a numerics library for D that does all this stuff? I'd like to hear more about this. If/when it's in a usable state, please put it up on dsource and post it to http://prowiki.org/wiki4d/wiki.cgi?ScientificLibraries. It's in a usable, but very incomplete state. I fully intend to publish it on dsource at some point, but there are a couple of reasons why I haven't done it yet: 1. I don't want to burden dsource with yet another dead project with some half-baked modules in it. I haven't got a lot of time to work on it, and mostly I just add things as I need them in my work. 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) 3. The API is still very much in a state of flux, and I need to decide how I want it. Here, I feel I'm making some progress now. After a long period of doing analytical calculations by hand, I'm now back on the numerics bandwagon and have started actually using my library again. The best way to judge whether an API is usable is to actually use it. ;) If you're interested, this is what I have: Integration: - Five of the QUADPACK routines (qk, qng, qag, qags, qagi) - Mori's Double Exponential algorithm Differentiation: - Forward/backward/symmetric difference - Ridder's extrapolation method - A home-brewed templated function for doing higher-order derivatives by symmetric difference - Jacobian matrix by forward difference (from MINPACK) Nonlinear equation solvers: - bisection, secant, false position, and Ridders' method Nonlinear system solvers: - MINPACK's variant of the Powell Hybrid algorithm - The Newton-Raphson algorithm I'm hoping someone will create a linear algebra library for D2 soon. I know very little about that stuff. At the very least, I think Phobos should have some basic vector/matrix functionality. I've looked at Don's BLADE library; it looks pretty awesome. Here's to hoping he finds the time and inspiration to continue work on it again. :) -Lars
