🚀 go-pugleaf

Vadim Tarassov <vadim@pci.unizh.ch> writes:

> Hi, Ken
> 
> Now try your best, force yourself to concentrate your attention on
> following point.
> Ok, one ... two ... three ...
> Don't you think that routine was tested before published?

If they did test their routines rigorously I would like to see them
publish a test suite. (I know they did publish "examples" but I don't
know that they published a rigorous test suite)

Also, if you concetrate your attention as well, you might remember that there
are those things called "bugs". They kinda find their way into programs,
and users running into them report them to Pest Control to get the code
debugged. The Numerical Recipies publishes newer versions of their
library every once in a while for this reason. They say that the bugs
become resistent to the insecticides, which is why these bugs just
keep coming back.

Finally, it is important to note that numerical recipies are not free
software, so it is not appropriate to discuss them in gnu.misc.discuss,
unless you want to discuss the nature of their license terms. 
If you write a program that depends on numerical recipies routines
you can not legally redistribute these routines. This is particularly
onerous if you want your program to be free software, or if you need to
_modify_ their routines. 

In general be very cautious of books with published source code. Always 
review the copyright status of their code before using it in projects that 
you might want to share with your collegues. In almost all cases that I know 
of, such books give you no rights. The copyright terms are always stated 
behind the book's titlepage. In Numerical Recipies, you are granted
a License which is discussed in an unnumbered section in the beginning
of the book. That License is extremely restrictive however. If no permissions
or License are mentioned, this means that you are given no rights at all.
In that case, it might even be illegal to copy the source code from the book 
to your computer by hand. This is very sad because, as far as I am 
concerned it makes a big chunk of these books useless to me.

Elef.


> 
> Ken Laberteaux wrote:
> 
> > I am reading the 2nd Edition of _Numerical Recipes in C_.  I am
> > specifically looking at laguer.c.
> >
> > On p. 373 the line of code which implements Eq 9.5.7 (p. 372) is
> >
> >                h=Csub(g2,RCmul(2.0,Cdiv(f,b)));
> >
> > However Eq 9.5.7 (p. 372) makes no reference of the 2, indicating that
> > the correct version should be
> >
> >                h=Csub(g2,Cdiv(f,b));
> >
> > Can anyone shed some light into this inconsistency?
> >
> > Ken Laberteaux

Ken Laberteaux <klaberte@trc.tellabs.com> writes:

> I am reading the 2nd Edition of _Numerical Recipes in C_.  I am
> specifically looking at laguer.c.
> 
> On p. 373 the line of code which implements Eq 9.5.7 (p. 372) is 
> 
>                h=Csub(g2,RCmul(2.0,Cdiv(f,b)));
> 
> However Eq 9.5.7 (p. 372) makes no reference of the 2, indicating that
> the correct version should be
> 
>                h=Csub(g2,Cdiv(f,b));
> 
> Can anyone shed some light into this inconsistency?

Not I, but for those viewing via DejaNews, there is a second
(performance) bug in another NR code.  The arbitrary-precision
multiplication code should call fmod(), but instead uses a loop,
producing a drop in performance of at least thirty times (I measured
it).

This is just to keep all the grumbles in one place, you understand.

ObOnTopic: ... and the liccense for the NR code is too restrictive.

-- 
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+usenet

hughett@chaplin.med.upenn.edu (Paul Hughett) writes:

> Eleftherios Gkioulekas (lf@amath.washington.edu) wrote:
> [deletia]
> 
> : Finally, it is important to note that numerical recipies are not free
> : software, so it is not appropriate to discuss them in gnu.misc.discuss,
> : unless you want to discuss the nature of their license terms. 
> : If you write a program that depends on numerical recipies routines
> : you can not legally redistribute these routines. 
> 
> Not precisely true.  You are free to distribute source of your own
> program, with instructions for the users to compile and link with
> their own copy of Numerical Recipes.  You could also distribute unlinked
> binaries of your program, although I'm not sure why you should want
> to.  What you cannot do is distribute either linked binaries, or copies
> of the NR source code.

Yes, as a technical matter, you can do that. It is even better to
instruct the users to compile NR as a library and have your program
simply link it in. You can use Autoconf to check whether the user-created
library actually contains the needed routines. If your program uses GPL code, 
then you can't do any of that. Also, if you've needed to modify a NR routine, 
then you're really out of luck because:
1. I am not sure if you are allowed to do the modification in the first
   place.
2. I am sure as hell you can't redistribute it.
So if you can't redistribute it, who can? You are stuck.

If you BUY an NR license, you are given permission by the
license of NR to distribute linked binaries that use NR routines,
under certain restrictions (basically they don't want your binary
to be a front-end entry point to calling the NR routines, they have
a weird way of requiring that). I am not sure if you have this
right if you only bought the book.

They spend an extreme amount of webspace explaining all of this
in excruciating detail. They really are very uptight about their
copyrights and licensing. They do make a few allowances if you
purchace a license separate from getting the book but these
allowances still don't make NR free software.

> 
> : This is particularly onerous if you want your program to be free
> : software, or if you need to _modify_ their routines.
> 
> Regrettably true.  I find that I am using NR less and less, for exactly
> this reason.
> 
> : In general be very cautious of books with published source code. Always 
> : review the copyright status of their code before using it in projects that 
> : you might want to share with your collegues. In almost all cases that I know 
> : of, such books give you no rights. The copyright terms are always stated 
> : behind the book's titlepage. In Numerical Recipies, you are granted
> : a License which is discussed in an unnumbered section in the beginning
> : of the book. That License is extremely restrictive however. If no permissions
> : or License are mentioned, this means that you are given no rights at all.
> : In that case, it might even be illegal to copy the source code from the book 
> : to your computer by hand. This is very sad because, as far as I am 
> : concerned it makes a big chunk of these books useless to me.
> 
> 
> Many of the routines available in Netlib have the same problem.  Either
> a restrictive license, or no stated license terms, in which case you
> cannot assume that you have any rights to the code.  You might be able
> to make the case that intentional public posting of the code implies
> certain rights to use, but I wouldn't want to try that without a
> laywer.

Agreed. I believe that the Netlib routines used in GNU Octave, like LAPACK and
FFTPACK and a few others can be considered safe, and mixable with GPLed
code. If you don't believe in the GNU Octave maintainer, then you can
certainly get a lawyer into it.

There may also be the issue that at the time when many of the Netlib stuff
was written, you didn't have a copyright if you didn't register for one.
But that would only work if these routines were never modified by anyone 
before the year that the automatic copyright was legislated 
(anyone know when that was?)

> 
> Paul Hughett

Numerical Recipies are a prime example of what RMS meant when he said
(paraphrasing) that "copyrights encourage the creation of software, but not 
the kind of software that society needs". 

Elef (IANAL but I am ANAL)
-- 
Eleftherios Gkioulekas                |  "The truth points to itself"
http://www.amath.washington.edu/~lf/  |                    --Kosh

Where did you find your version?  Perhaps it is from some freely used
source.  Please let me know.

Ken

p.s. thanks for checking.

Eric Backus wrote:
> 
> Ken Laberteaux <klaberte@trc.tellabs.com> writes:
> 
> > I am reading the 2nd Edition of _Numerical Recipes in C_.  I am
> > specifically looking at laguer.c.
> >
> > On p. 373 the line of code which implements Eq 9.5.7 (p. 372) is
> >
> >                h=Csub(g2,RCmul(2.0,Cdiv(f,b)));
> >
> > However Eq 9.5.7 (p. 372) makes no reference of the 2, indicating that
> > the correct version should be
> >
> >                h=Csub(g2,Cdiv(f,b));
> >
> > Can anyone shed some light into this inconsistency?
> 
> I agree that this appears to be inconsistant, and that your proposed
> modification looks correct.
> 
> My own code for the Laguerre method does not have the factor of two,
> and seems to work well.
> 
> --
>                         Eric Backus <eric_backus@hp.com>
>                         http://labejb.lsid.hp.com/
>                         (425) 335-2495

Ok ... ok ... ok...

Of course, NR may have bugs. Otherwise it would be bible. Besides, existence
of bugs in NR stimulates intellectual activity.
Well, it is already second time the same discussion. Can anybody here answer
me one question?  Why do you use this book !!???!!!

Ken Laberteaux <klaberte@trc.tellabs.com> writes:
> On p. 373 the line of code which implements Eq 9.5.7 (p. 372) is 
> 
>                h=Csub(g2,RCmul(2.0,Cdiv(f,b)));
> 
> However Eq 9.5.7 (p. 372) makes no reference of the 2, indicating that
> the correct version should be
> 
>                h=Csub(g2,Cdiv(f,b));
> 
> Can anyone shed some light into this inconsistency?

It's my (paranoid, perhaps) hypothesis that Numerical Recipes includes
harmless obfuscations in their code to protect their copyright, much
like Rand McNally introduces harmless small errors in their maps in
order to identify illegal copies.

I don't know about this particular routine, but based on prior
experience with NR, my bet would be that if you follow the logic of
the code, the routine is correct -- but in a way that you may not have
ever written it had you started from scratch.

-- 
- Sean Eddy
- Dept. of Genetics, Washington University in St. Louis
- http://www.genetics.wustl.edu/eddy/

Listen Jerk, Numerical Recipes have come out with several bug fixes for
their routines.  Further, they state openly that their response to bug
reports is very slow, and frequently never directly to the person making
the report.  Thus I asked the newsgroups since others may remember
discussion on this before (yes I did check dejanews first).

Further, if you had a clue, you'd know that the potential bug I mention
does not affect convergence, only speed of convergence.  Casual testing
may not catch it.

Not often I see such a stupid response on this newsgroup. 
Congratulation!

Ken


Vadim Tarassov wrote:
> 
> Hi, Ken
> 
> Now try your best, force yourself to concentrate your attention on
> following point.
> Ok, one ... two ... three ...
> 
> Don't you think that routine was tested before published?
>

Eleftherios Gkioulekas (lf@amath.washington.edu) wrote:
[deletia]

: Finally, it is important to note that numerical recipies are not free
: software, so it is not appropriate to discuss them in gnu.misc.discuss,
: unless you want to discuss the nature of their license terms. 
: If you write a program that depends on numerical recipies routines
: you can not legally redistribute these routines. 

Not precisely true.  You are free to distribute source of your own
program, with instructions for the users to compile and link with
their own copy of Numerical Recipes.  You could also distribute unlinked
binaries of your program, although I'm not sure why you should want
to.  What you cannot do is distribute either linked binaries, or copies
of the NR source code.

: This is particularly onerous if you want your program to be free
: software, or if you need to _modify_ their routines.

Regrettably true.  I find that I am using NR less and less, for exactly
this reason.

: In general be very cautious of books with published source code. Always 
: review the copyright status of their code before using it in projects that 
: you might want to share with your collegues. In almost all cases that I know 
: of, such books give you no rights. The copyright terms are always stated 
: behind the book's titlepage. In Numerical Recipies, you are granted
: a License which is discussed in an unnumbered section in the beginning
: of the book. That License is extremely restrictive however. If no permissions
: or License are mentioned, this means that you are given no rights at all.
: In that case, it might even be illegal to copy the source code from the book 
: to your computer by hand. This is very sad because, as far as I am 
: concerned it makes a big chunk of these books useless to me.


Many of the routines available in Netlib have the same problem.  Either
a restrictive license, or no stated license terms, in which case you
cannot assume that you have any rights to the code.  You might be able
to make the case that intentional public posting of the code implies
certain rights to use, but I wouldn't want to try that without a
laywer.

Paul Hughett

Ken Laberteaux <klaberte@trc.tellabs.com> writes:

> I am reading the 2nd Edition of _Numerical Recipes in C_.  I am
> specifically looking at laguer.c.
> 
> On p. 373 the line of code which implements Eq 9.5.7 (p. 372) is 
> 
>                h=Csub(g2,RCmul(2.0,Cdiv(f,b)));
> 
> However Eq 9.5.7 (p. 372) makes no reference of the 2, indicating that
> the correct version should be
> 
>                h=Csub(g2,Cdiv(f,b));
> 
> Can anyone shed some light into this inconsistency?

I agree that this appears to be inconsistant, and that your proposed
modification looks correct.

My own code for the Laguerre method does not have the factor of two,
and seems to work well.

-- 
			Eric Backus <eric_backus@hp.com>
			http://labejb.lsid.hp.com/
			(425) 335-2495

Hi, Ken

Now try your best, force yourself to concentrate your attention on
following point.
Ok, one ... two ... three ...

Don't you think that routine was tested before published?

Ken Laberteaux wrote:

> I am reading the 2nd Edition of _Numerical Recipes in C_.  I am
> specifically looking at laguer.c.
>
> On p. 373 the line of code which implements Eq 9.5.7 (p. 372) is
>
>                h=Csub(g2,RCmul(2.0,Cdiv(f,b)));
>
> However Eq 9.5.7 (p. 372) makes no reference of the 2, indicating that
> the correct version should be
>
>                h=Csub(g2,Cdiv(f,b));
>
> Can anyone shed some light into this inconsistency?
>
> Ken Laberteaux

In article <3653DFB0.876D5A72@pci.unizh.ch>,
Vadim Tarassov  <vadim@pci.unizh.ch> wrote:

|> Now try your best, force yourself to concentrate your attention on
|> following point.
|> Ok, one ... two ... three ...
|> 
|> Don't you think that routine was tested before published?

Are you sure it was?  I've heard claims the NR routines are often
_untested_ -- especially the C routines, about which there was a big
thread 2-3 months ago talking about some really glaring errors.  Look it
up on Deja News if interested.

cu,
Bruce

-- 
"That's the old ecological tale that explains humans' inability to fully
appreciate global warming.  To wit: if you drop a frog in a pan of hot
water, it jumps out.  If you drop it in a pan of cold water, then turn
the heat up slowly, you can roast it to death."  -- Clive Thompson

On Wed, 18 Nov 1998 16:08:27 -0500, Ken Laberteaux <klaberte@trc.tellabs.com> wrote:
>I am reading the 2nd Edition of _Numerical Recipes in C_.  I am
>specifically looking at laguer.c.
>
>On p. 373 the line of code which implements Eq 9.5.7 (p. 372) is 
>
>               h=Csub(g2,RCmul(2.0,Cdiv(f,b)));
>
>However Eq 9.5.7 (p. 372) makes no reference of the 2, indicating that
>the correct version should be
>
>               h=Csub(g2,Cdiv(f,b));
>
>Can anyone shed some light into this inconsistency?

There is no inconsistency.  The recurrence relation used to calculate
f in the loop is:

  /* a[i] defines the i-th coefficient of an m degree polynomial */
  /* let p(m) = a[m] * x^m + ... + a[0] */
  f[m] = 0;
  d[m] = 0;
  b[m] = a[m];
  for (j = m-1; j >= 0; j--) {
    f[j] = x * f[j+1] + d[j+1];
    d[j] = x * d[j+1] + b[j+1];
    b[j] = x * b[j+1] + a[j];
  }

You can prove the following loop invariant by induction:

For k = 1 ... m;

  d[m-k](x) = b[m-k](x)'
  f[m-k](x) = (1/2) * b[m-k](x)''

Proof:

  For k = 1;
    b[m-1](x) = x * b[m](x) + a[m-1]
              = a[m] * x + a[m-1];
    
    but,
    d[m-1](x) = x * d[m](x) + b[m](x)
              = a[m]
	      = b[m](x)'
    
    and,
    f[m-1](x) = x * f[m](x) + d[m]
              = 0
	      = (1/2) * b[m-1](x)''

  Therefore, there exists some n > 1 such that hypothesis is true for
  all numbers greater than or equal to 1 but less than n. We will no
  show the hypothesis is true for k = n,

  For k = n;
    b[m-n](x) = x * b[m-(n-1)](x) + a[m-n]

    Thus,
    b[m-n](x)' = x * b[m-(n-1)](x)' + b[m-(n-1)](x)
    
    and
    b[m-n](x)'' = x * b[m-(n-1)](x)'' + 2 * b[m-(n-1)](x)'
    
    But,
    d[m-n](x) = x * d[m-(n-1)](x) + b[m-(n-1)](x)
              = x * b[m-(n-1)](x)' + b[m-(n-1)](x)
   
    which follows from the induction hypothesis.  Thus,
    
    d[m-n](x) = b[m-n](x)'
    
    Also,
    f[m-n](x) = x * f[m-(n-1)] + d[m-(n-1)](x)
              = x * (1/2) * b[m-(n-1)](x)'' + b[m-(n-1)](x)'
	      
    which follows from the induction hypothesis.  Thus,
    
    f[m-n](x) = (1/2) * b[m-n](x)''

  Thus, the hypothesis is true for all n >= 1.

-- 
James C. Hu <jxh@cs.wustl.edu>       Computer Science Doctoral Candidate
http://www.cs.wustl.edu/~jxh/        Washington University in Saint Louis
>>>>>>>>>>>>> I use *SpamBeGone* <URL:http://www.internz.com/SpamBeGone/>

[gnu.misc.discuss dropped in followups]

On Thu, 19 Nov 1998 09:37:07 -0500, 
Ken Laberteaux <klaberte@trc.tellabs.com> wrote:
>Listen Jerk, Numerical Recipes have come out with several bug fixes for
>their routines.  Further, they state openly that their response to bug
>reports is very slow, and frequently never directly to the person making
>the report.  Thus I asked the newsgroups since others may remember
>discussion on this before (yes I did check dejanews first).
>
[Snip]

You really should drop gnu.misc.discuss from this kind of post.  It
isn't only the `jerk' that finds this annoying. 

-- 
Kenneth P. Turvey <kturvey@SprocketShop.com> 

Those who would give up essential Liberty, to purchase a little
temporary safety, deserve neither Liberty or safety.
	-- Benjamin Franklin