The link to the NR licence that you give is to the license for use of the book in paper or electronic form for programming, not for the license to use one or another piece their code as part of your own code. Their stated licens in the book is that you *may* use their code as part of your own program and make it available to others, with restrictions. The restrictions explicitly exclude "mix and match" algorithms, which would be a re-presentation of the work in the book and code. This seems to be reasonably compatible with what we would want to do.
"...You may also, under this license, transfer pre-compiled, executable programs incorporating our routines to other, unlicensed, screens or computers, providing that (i) your application is noncommercial (i.e., does not involve the selling o fyour program for a fee), ..." Without reading the U. Colorado link in detail, I will say that most of the NR algorithms for floating point are for single-precision functions and are not extensible to double precision; later editions say just exactly that. The criticisms on ODE and PDE integration algorithms may be related to that presumption that single precision is good enough, or the reliance of the authors on free or inexpensive student coding efforts; I don't know because I don't rely on cookbooks for that type of algorithm. So far as I know they have never added a double precision library. But, most of their algorithms, for linear algebra and other such, aren't really affected by this. But, yes, I don't use their algorithms for single-precision floating point functions, I use Abramowitz & Stegun or other reference for an algorithm or simply do my own. In any case, this is cookbook software, and is not subject to the support and bug fixes of the horrendously expensive IMSL library that the U. Colorado page touts as superior; IMSL is superior but inflexible, in my limited experiences with it many years ago. I can't comment on the NAG packages because I haven't used them. Their multiple precision stuff is only in the last editions for FORTRAN and C, and the Fortran 90 extension written by Metcalf and Reed which is actually Volume 2 of the Second edition (1996) and consists only of Fortran 90 re-codes of the algorithms in Volume 1, often with improvements, some of them major, either from the expertise of Metcalf and Reed and their associates or from advantages offered by Fortran 90. They consist of eight-bit stackable arithmetic, which is the core of my mantissa arithmetic, with separate sections on computation of pi to arbitrary precision and multiplication using a string of eight-bit segments out of an integer of arbitrary length. They use their of a single-precision FFT from another section and parsing the call and return from this FFT is non-trivial, so I just used that code, unchanged. A simple alternative would be to do my own eight-bit stackable arithmetic and multiplication algorithm. If I really needed to distance myself form the NR license I would do that. It's not rocket science and it's not that hard. But, it's long, and I haven't needed to do that. James K Beard -----Original Message----- From: K. Frank [mailto:[email protected]] Sent: Sunday, April 10, 2011 9:32 AM To: mingw64 Subject: Re: [Mingw-w64-public] mingw-w64 Decimal Floating Point math Hello James and Jon! On Sat, Apr 9, 2011 at 10:58 PM, James K Beard <[email protected]> wrote: > JonY - well, mine is in Fortran 95 structured format, with layers of classes > and derived data types. An experienced programmer could port it to C++ > fairly quickly, giving you a a C++ class with overloaded arithmetic and > casting/data conversion operations. But I'm not a C++ programmer and don't > want to become one; I'm not in software or computer science and have other > plans for my time than gaining expertise in C++. But I would be happy to > support other people to do the conversion to C++. > > The Numerical Recopies core utilities are extended-precision fixed-point > arithmetic without extensions (I do the extensions myself), an algorithm to > compute pi to arbitrary precision, and an algorithm to do multiplication > using an FFT to convolve polynomials of integers that are the extended > precision mantissas broken up into bytes. The multiplication and division > algorithms are non-trivial and the computer science in them is very much key > to acceptable speeds in multiplication. If you guys are at all serious > about this I will approach the NR people about how to proceed. My tentative > thinking has been to put out what I have under the GPL, MIT, BSD or whatever > license and note the NR modules needed to complete the package and leave it > at that. For something to become a package in another language, I need a > release into the MIT or BSD license. That's not at all very different from > what they offer in the books and CD, so I think that it might be > forthcoming, particularly if a plug for NR is included, but at this late > date even that might not be required. > ... About Numerical Recipes -- they use a pretty restrictive license. See, for example, their web site: http://www.nr.com/com/how-we-license.html I can't speak for them as to whether they would release some part of their code (e.g., the extended-precision module) under a more open license that would work for mingw-w64, but I expect that getting their license relaxed would be an uphill battle. One more comment about Numerical Recipes: I've never used their extended-precision code, and James has battle-tested it, so it's probably quite good, but in general, there are a lot pitfalls in the Numerical Recipes algorithms and code. In fact, it's rather notorious in the numerical-analysis community. One summary of community concerns can be found here, under the title "Numerical Recipes -- not so good": http://amath.colorado.edu/computing/Fortran/numrec.html Just a heads-up... Best. K. Frank > ... > James K Beard > > -----Original Message----- > From: Jon [mailto:[email protected]] On Behalf Of JonY > Sent: Saturday, April 09, 2011 9:07 PM > ... > I've talked with Kai sometime ago about licensing, GPL and LGPL aren't > practical for mingw-w64, if it were, I would have taken libdecnumber and > libquadmath from gcc directly. > > He opted for a MIT or BSD type license so mingw-w64 could still be used to > develop proprietary software. > ... ---------------------------------------------------------------------------- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
