NUMERICAL RECIPES

Discussion in 'C Programming' started by robin, Jan 2, 2011.

  1. robin

    robin Guest

    "Ron Shepard" <> wrote in message
    news:...

    | I think the
    | Numerical Recipes books are excellent introductions to many
    | computational problems, including linear algebra. I do agree that
    | the code itself that is given in the book is sometimes not the most
    | robust, but on the other hand, something like LAPACK code is robust
    | but too complicated for a beginner to understand easily.

    Numerical Recipes is an authoritative source of information
    about a vast number of numerical procedures.

    Therefore I endorse Ron Shepherd's remark that it is an
    "excellent introductions to many computational problems, including linear algebra".

    At more than 1200 pages, and more than 400 propgrams/procedures,
    there is something there for everybody.

    Three editions have been published.
    ________________

    New in the Third Edition (2007):

    * A new chapter on classification and inference,
    including such topics as Gaussian mixture models,
    hidden Markov modeling, hierarchical clustering
    (phylogenetic trees), and support vector machines.
    * A new chapter on computational geometry, including
    topics like KD trees, quad- and octrees, Delaunay
    triangulation and applications, and many useful
    algorithms for lines, polygons, triangles, spheres, and
    so on.
    * Many new statistical distributions, with pdf's, cdf's,
    and inverse cdf's
    * An expanded treatment of ODEs, emphasizing recent
    advances, and with completely new routines
    * Much-expanded sections on uniform random
    deviates. and on deviates from many other statistical
    distributions
    * An introduction to spectral and pseudospectral
    methods for PDEs
    * Interior point methods for linear programming
    * More on sparse matrices
    * Interpolation on scattered data in multidimensions
    * Curve interpolation in multidimensions
    * Quadrature by variable transformation, and adaptive
    quadrature
    * More on Gaussian quadratures and orthogonal
    polynomials
    * More on accelerating the convergence of series
    * Improved incomplete gamma and beta functions,
    and new inverse functions
    * Improved spherical harmonics and fast spherical
    harmonic transforms
    * Generalized Fermi-Dirac integrals
    * Multivariate Gaussian deviates
    * Algorithms and implementations for hash memory
    functions
    * Incremental quantile estimation
    * Chi-square with small numbers of counts
    * Dynamic programming
    * Hard and soft error correction, and Viterbi decoding
    * Eigensystem routines for real, nonsymmetric matrices
    * Multitaper methods for power spectral estimation
    * Wavelets on the interval
    * Information-theoretic properties of distributions
    * Markov chain Monte Carlo
    * Gaussian process regression and Kriging
    * Stochastic simulation of chemical reaction networks
    * Code for plotting simple graphs from within programs
     
    robin, Jan 2, 2011
    #1
    1. Advertising

  2. robin

    bert Guest

    On Jan 2, 9:03 am, "robin" <> wrote:
    > Numerical Recipes is an authoritative source of information
    > about a vast number of numerical procedures.


    Maybe so, but the version "Numerical Recipes in C"
    was a travesty. Practically all of the C code had
    been transliterated quite mindlessly from Fortran,
    making hardly any use of C idioms which would
    have made the code cleaner and neater. In
    particular, there was scarcely any use of pointers.
    So authoritative about procedures, maybe, but as
    for authoritative about C, absolutely not.
    --
     
    bert, Jan 2, 2011
    #2
    1. Advertising

  3. robin

    robin Guest

    "bert" <> wrote in message
    news:...
    On Jan 2, 9:03 am, "robin" <> wrote:

    > Numerical Recipes is an authoritative source of information
    > about a vast number of numerical procedures.


    >Maybe so, but the version "Numerical Recipes in C"
    >was a travesty.


    Wasn't that published in about 1992?

    I clearly stated that I was referring the information and the procedures,
    and in particular to the 2007 edition.

    > Practically all of the C code had
    >been transliterated quite mindlessly from Fortran,
    >making hardly any use of C idioms which would
    >have made the code cleaner and neater. In
    >particular, there was scarcely any use of pointers.


    Pointers are probably best avoided.

    >So authoritative about procedures, maybe, but as
    >for authoritative about C, absolutely not.


    It doesn't pretend to be.
    The authors clearly state that NR is "NOT [emphasis added]
    a textbook on programming, or on best programming practices, or on C++, ..."
     
    robin, Jan 2, 2011
    #3
  4. On Jan 2, 3:29 pm, bert <> wrote:
    >
    > Maybe so, but the version "Numerical Recipes in C"
    > was a travesty.  Practically all of the C code had
    > been transliterated quite mindlessly from Fortran,
    >

    I've spent many a day rewriting Numerical Recipes code so that it
    actually fits with the rest of my C program.
     
    Malcolm McLean, Jan 2, 2011
    #4
  5. robin

    aruzinsky Guest

    The same thing happened with Collected Algorithms from ACM. Volumes
    I, ii and III were nice with many good general purpose algorithms,
    although written mostly in algol (see http://en.wikipedia.org/wiki/ALGOL)
    and some Fortran. These volumes are a good competitor to Numerical
    Recipes. The volumes that followed were too specialized and the
    algorithms were on microfiche.

    On Jan 2, 8:23 am, Giorgio Pastore <> wrote:
    > On 1/2/11 2:29 PM, bert wrote:
    >
    > > On Jan 2, 9:03 am, "robin"<>  wrote:
    > >> Numerical Recipes is an authoritative source of information
    > >> about a vast number of numerical procedures.

    >
    > ...
    > > So authoritative about procedures, maybe, but as
    > > for authoritative about C, absolutely not.
    > > --

    >
    > Actually, I think that Numerical Recipes is a book which progressively
    > becomes worse at each new edition.
    >
    >  From the side of algorithms, the first edition  was doing a pretty good
    > job concentrating on a few of them. That way, it was a not-deep but
    > modern, honest and readable book on numerical algorithms. A good
    > starting point for further readings. The examples in Fortran 77 were not
    > enough modular to be included in other codes without some rewriting,
    > but, as examples of implementation were reasonably well written.
    >
    > The last edition has become a huge book which tries to cover almost
    > everything. It is true that the original intent was to provide a sort of
    > cookbook. But the first edition was a good starting point for everybody
    >   wanted to get a feeling  how to become a chef able to prepare a full
    > meal. The last one covers too much for a general overview and not so in
    > depth to provide a definite guide for each specific topic.
    >
    > Finally, the authors explicit admission of missing their bets on the
    > language evolution is mirrored by codes which progressively tend to use
    > less expressively  the underlying languages.
    >
    > I hope that this trend could be reversed in the future.
    >
    > Giorgio
     
    aruzinsky, Jan 2, 2011
    #5
  6. robin

    Guest

    In article <ifqj7c$ne2$-september.org>,
    Peter Flass <> wrote:
    >
    >I found there was a lot of work translating the algorithms into PL/I
    >too, for the same reason. You can't just translate the code
    >one-for-one, but have to translate the intent instead.


    If that were all :-( As pointed out several times, you often have
    to fix the code as well.

    >That being said, I've found the first edition quite useful.


    Which included the worst random number generators that I had seen
    in 25 years of refereeing on that topic - MUCH worse than RANDU.
    They started to give wrong answers in trivial, realistic tests
    with only 200 numbers.



    Regards,
    Nick Maclaren.
     
    , Jan 2, 2011
    #6
  7. robin

    Peter Flass Guest

    On 1/2/2011 8:29 AM, bert wrote:
    > On Jan 2, 9:03 am, "robin"<> wrote:
    >> Numerical Recipes is an authoritative source of information
    >> about a vast number of numerical procedures.

    >
    > Maybe so, but the version "Numerical Recipes in C"
    > was a travesty. Practically all of the C code had
    > been transliterated quite mindlessly from Fortran,
    > making hardly any use of C idioms which would
    > have made the code cleaner and neater. In
    > particular, there was scarcely any use of pointers.
    > So authoritative about procedures, maybe, but as
    > for authoritative about C, absolutely not.
    > --


    I found there was a lot of work translating the algorithms into PL/I
    too, for the same reason. You can't just translate the code
    one-for-one, but have to translate the intent instead.

    That being said, I've found the first edition quite useful.
     
    Peter Flass, Jan 2, 2011
    #7
  8. In comp.lang.fortran bert <> wrote:
    > On Jan 2, 9:03 am, "robin" <> wrote:
    >> Numerical Recipes is an authoritative source of information
    >> about a vast number of numerical procedures.


    > Maybe so, but the version "Numerical Recipes in C"
    > was a travesty. Practically all of the C code had
    > been transliterated quite mindlessly from Fortran,
    > making hardly any use of C idioms which would
    > have made the code cleaner and neater.


    (snip)

    This one I agree with, though if you go through the routine
    and fix up those problems, in the end you learn more about
    how it works. It did that at least once, and it took a while
    to get right. (Especially all the loops indexing arrays
    from zero instead of one.)

    -- glen
     
    glen herrmannsfeldt, Jan 2, 2011
    #8
  9. robin

    Seebs Guest

    On 2011-01-02, robin <> wrote:
    > "bert" <> wrote in message
    > news:...
    >> Practically all of the C code had
    >>been transliterated quite mindlessly from Fortran,
    >>making hardly any use of C idioms which would
    >>have made the code cleaner and neater. In
    >>particular, there was scarcely any use of pointers.


    > Pointers are probably best avoided.


    Not in a book that's supposed to be useful to C programmers.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Jan 3, 2011
    #9
  10. robin

    robin Guest

    <> wrote in message news:ifqhas$10h$...
    | In article <ifqj7c$ne2$-september.org>,
    | Peter Flass <> wrote:
    | >
    | >I found there was a lot of work translating the algorithms into PL/I
    | >too, for the same reason. You can't just translate the code
    | >one-for-one, but have to translate the intent instead.
    |
    | If that were all :-( As pointed out several times, you often have
    | to fix the code as well.

    Your comments and information are out-of-date.

    | >That being said, I've found the first edition quite useful.
    |
    | Which included the worst random number generators that I had seen
    | in 25 years of refereeing on that topic - MUCH worse than RANDU.
    | They started to give wrong answers in trivial, realistic tests
    | with only 200 numbers.

    Again, you are referring to the 1988 (first) edition.
    That's 23 years ago. Not particularly relevant.

    The current (third) edition provides a range of RNGs
    (but, of course, not the latest of George Marsaglia's of 2010).
     
    robin, Jan 3, 2011
    #10
  11. On Jan 3, 3:39 am, glen herrmannsfeldt <> wrote:
    > ... fix up those problems, in the end you learn more about
    > how it works.  It did that at least once, and it took a while
    > to get right.  (Especially all the loops indexing arrays
    > from zero instead of one.)


    I also went through the NR routines I needed and rewrote them
    to index from zero; am glad to discover now I wasn't the only
    one so perverse. :) But, no ... I didn't learn how Jacobi's
    pivots work while I was at it, just being in "copy faithfully"
    mode.

    Doing this rewrite, I felt somewhat anal-retentive, since the
    N.R. routines could be treated as a black box, and the funny
    indexing disguised via macros. It was my obsessive-compulsive
    behavior, I think, that made me "fix" the indexing ...
    but at least I don't wash my hands 10 hours per day like
    some OCD sufferers. :)

    James Dow Allen
     
    James Dow Allen, Jan 3, 2011
    #11
  12. Phil Hobbs <> wrote:

    > ...once you put them [NR codes] in a shared library, it
    > becomes a useful prototyping tool and doesn't contaminate your code with
    > copylefts and suchlike.


    Have you read the license conditions on the NR code? Regardless of what
    one might think about copylefts, the copyright on the NR code is more
    restrictive than any copyleft. Copylefts place conditions on
    redistributing the code or programs built from it. The NR copyright
    places an even stronger condition - namely that you cannot do it at all.

    Quoting exactly from my copy of NR in Fortran 90

    "Immediate License....You are not allowed to transfer or distribute
    machine-readable copies to any other person, or to use the routines
    on more than one machine, or to distribute executable programs
    containing our routines. This is the only free license."

    As the last sentence quoted above implies, there are other license
    options, but you have to pay for all of them (paying for the book
    doesn't count).

    --
    Richard Maine | Good judgment comes from experience;
    email: last name at domain . net | experience comes from bad judgment.
    domain: summertriangle | -- Mark Twain
     
    Richard Maine, Jan 5, 2011
    #12
  13. robin

    Uno Guest

    On 1/7/2011 5:09 AM, rosario wrote:
    > "rosario"<> ha scritto nel messaggio
    > news:4d25757b$0$10583$...
    >>
    >> "rosario"<> ha scritto nel messaggio
    >> news:4d2571d4$0$10573$...
    >>>
    >>> "rosario"<> ha scritto nel messaggio
    >>> news:4d249126$0$10574$...
    >>>>
    >>>> "robin"<> ha scritto nel messaggio
    >>>> news:4d2055cd$0$99356$...
    >>>>> "Ron Shepard"<> wrote in message
    >>>>> news:...
    >>>>>
    >>>>> | I think the
    >>>>> | Numerical Recipes books are excellent introductions to many
    >>>>> | computational problems, including linear algebra. I do agree that
    >>>>> | the code itself that is given in the book is sometimes not the most
    >>>>> | robust, but on the other hand, something like LAPACK code is robust
    >>>>> | but too complicated for a beginner to understand easily.
    >>>>>
    >>>>> Numerical Recipes is an authoritative source of information
    >>>>> about a vast number of numerical procedures.
    >>>>
    >>>> better write code in one macro asm that allow multi instruction for line
    >>>> and indentation
    >>>>
    >>>> all compiler science == 0 for me, and it go to the wrong way
    >>>> [the way the human lost what the machine do]
    >>>
    >>> excuse me possibily, i'm one extremis don't believe all the people say
    >>> i believe what i see

    >>
    >> and i see something like this:
    >>
    >> ; a inizializzaRNDFile(u32* RNDvar, u8* fname)
    >> ; Questa funzione inizializza i vettori delle basi e dei seed per la variabile
    >> random RNDvar
    >> ; prendendo i dati per l'inizializzazione da un file esterno.
    >> ; RNDvar: variabile random ritornata da rtnRNDmem() o inizializzata da
    >> iniRNDmem
    >> [in/out]
    >> ; fname: stringa che contiene il nome del file i cui dati servono a
    >> inizializzare RNDvar [in]
    >> ; ritorna: [0 ed CF==1 per errore; 1 ed CF==0 tutto ok]
    >> ; uso tipico:
    >> ; rtnRNDmem(6, 31415821, 1234) |jc .e|j=a
    >> ; inizializzaRNDFile(j, "filedati")|jc .e
    >> ; 0j,4i,8Ra, 12P_RNDvar, 16P_fname + 5120
    >> ; 5132 5136
    >> align 4
    >> inizializzaRNDFile:
    >> <i,j
    >> s-=5120
    >> << RNDvar=5132, fname=5136, KeyHandle=16
    >> i=^fname|j=^RNDvar
    >> i==0#.e |j==0 #.e|D*j==0#.e ; la basea non puo' essere zero
    >> D*j+ini== -1 #.e ; l'array di basi non puo' essere inizializzato
    >> D*j+nbs>100000#.e ; il numero delle basi non puo' essere> 100000
    >> #.1
    >> .e1: a=^KeyHandle|CloseHandle(a)
    >> .e: a^=a|stc|#.z ; errore: ritorna 0
    >> .1: CreateFileA(i,&GENERIC_READ, 0, 0,&OPEN_EXISTING,
    >> &FILE_ATTRIBUTE_NORMAL,0)
    >> a==&INVALID_HANDLE_VALUE#.e|^KeyHandle=a
    >> r=&*s+24|c=s|ReadFile(a, r, 4064, c, 0)
    >> a==0#.e1|a=D*s|a<4?#.e1 ; se ha elementi in numero<4 esci errore
    >> a=^KeyHandle|CloseHandle(a)|a==0#.e
    >> ; prepara la variabile random definendo l'array di
    >> basi e seed
    >> ; con i dati provenienti dal file
    >> r=&*s+24|a=^0|PreparaRND(j, r, a)|jc .e
    >> a=1|clc
    >> .z:
    >>>> RNDvar, fname, KeyHandle

    >> s=&*s+5120
    >>> i,j

    >> ret 8

    >
    > so i'm just one troll?
    >
    >


    I would say more like a scribbler. That's alright, if you're five.
    --
    Uno
     
    Uno, Jan 9, 2011
    #13
  14. robin

    Uno Guest

    On 1/5/2011 2:11 PM, Richard Maine wrote:
    > Phil Hobbs<> wrote:
    >
    >> ...once you put them [NR codes] in a shared library, it
    >> becomes a useful prototyping tool and doesn't contaminate your code with
    >> copylefts and suchlike.

    >
    > Have you read the license conditions on the NR code? Regardless of what
    > one might think about copylefts, the copyright on the NR code is more
    > restrictive than any copyleft. Copylefts place conditions on
    > redistributing the code or programs built from it. The NR copyright
    > places an even stronger condition - namely that you cannot do it at all.
    >
    > Quoting exactly from my copy of NR in Fortran 90
    >
    > "Immediate License....You are not allowed to transfer or distribute
    > machine-readable copies to any other person, or to use the routines
    > on more than one machine, or to distribute executable programs
    > containing our routines. This is the only free license."
    >
    > As the last sentence quoted above implies, there are other license
    > options, but you have to pay for all of them (paying for the book
    > doesn't count).
    >


    My problem with the treatment was the large, proprietary module that
    needed to be included in order to make the smallest of examples work.

    I'm not saying that would be a problem for others, presumably people
    with deeper pockets than me, which is a lot of people.

    They sure are amazing, quick, and robust, tho.
    --
    Uno
     
    Uno, Jan 9, 2011
    #14
  15. robin

    Uno Guest

    On 1/2/2011 7:34 PM, Seebs wrote:
    > On 2011-01-02, robin<> wrote:
    >> "bert"<> wrote in message
    >> news:...
    >>> Practically all of the C code had
    >>> been transliterated quite mindlessly from Fortran,
    >>> making hardly any use of C idioms which would
    >>> have made the code cleaner and neater. In
    >>> particular, there was scarcely any use of pointers.

    >
    >> Pointers are probably best avoided.

    >
    > Not in a book that's supposed to be useful to C programmers.


    By what process do you get that? Programs without pointers aren't useful?

    Usually, when the rest of us talk about "avoiding pointers," we mean the
    unnecessary ones that obfuscate.

    Of course, I'll never stand between Seebs and his calling to make C a
    useless abstraction.
    --
    Uno
     
    Uno, Jan 9, 2011
    #15
  16. robin

    Guest

    In article <>, Uno <> wrote:
    >On 1/2/2011 7:34 PM, Seebs wrote:
    >> On 2011-01-02, robin<> wrote:
    >>
    >>> Pointers are probably best avoided.

    >>
    >> Not in a book that's supposed to be useful to C programmers.

    >
    >By what process do you get that? Programs without pointers aren't useful?


    In C, that is true. All of strings, arrays and (when used as objects)
    functions are actually pointers, and it is important to know and use
    that when passing them as function arguments.

    It is not true in Fortran.


    Regards,
    Nick Maclaren.
     
    , Jan 9, 2011
    #16
  17. robin

    aruzinsky Guest

    Proper implementation of C pointers increases program speed but the
    source code is relatively unreadable. C and, more so, C++ can be
    written to be either very readable or very unreadable. I much rather
    read C source code written to resemble pseudo-code. Afterwards, it is
    easy enough for me to implement pointers (which later I have
    difficulty reading).

    On Jan 8, 9:42 pm, Uno <> wrote:
    > On 1/2/2011 7:34 PM, Seebs wrote:
    >
    > > On 2011-01-02, robin<>  wrote:
    > >> "bert"<>  wrote in message
    > >>news:....
    > >>> Practically all of the C code had
    > >>> been transliterated quite mindlessly from Fortran,
    > >>> making hardly any use of C idioms which would
    > >>> have made the code cleaner and neater.  In
    > >>> particular, there was scarcely any use of pointers.

    >
    > >> Pointers are probably best avoided.

    >
    > > Not in a book that's supposed to be useful to C programmers.

    >
    > By what process do you get that?  Programs without pointers aren't useful?
    >
    > Usually, when the rest of us talk about "avoiding pointers," we mean the
    > unnecessary ones that obfuscate.
    >
    > Of course, I'll never stand between Seebs and his calling to make C a
    > useless abstraction.
    > --
    > Uno
     
    aruzinsky, Jan 9, 2011
    #17
  18. robin

    Seebs Guest

    On 2011-01-09, aruzinsky <> wrote:
    > Proper implementation of C pointers increases program speed but the
    > source code is relatively unreadable.


    No, it isn't.

    > I much rather
    > read C source code written to resemble pseudo-code. Afterwards, it is
    > easy enough for me to implement pointers (which later I have
    > difficulty reading).


    There are tons of algorithms which are elegant and clear using pointers,
    and hard to write clearly at all without them. Perhaps you should just
    practice more until pointers are more comfortable for you.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Jan 9, 2011
    #18
  19. robin

    Beliavsky Guest

    On Jan 8, 10:33 pm, Uno <> wrote:
    > On 1/5/2011 2:11 PM, Richard Maine wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > Phil Hobbs<>  wrote:

    >
    > >> ...once you put them [NR codes] in a shared library, it
    > >> becomes a useful prototyping tool and doesn't contaminate your code with
    > >> copylefts and suchlike.

    >
    > > Have you read the license conditions on the NR code? Regardless of what
    > > one might think about copylefts, the copyright on the NR code is more
    > > restrictive than any copyleft. Copylefts place conditions on
    > > redistributing the code or programs built from it. The NR copyright
    > > places an even stronger condition - namely that you cannot do it at all..

    >
    > > Quoting exactly from my copy of NR in Fortran 90

    >
    > >    "Immediate License....You are not allowed to transfer or distribute
    > >     machine-readable copies to any other person, or to use the routines
    > >     on more than one machine, or to distribute executable programs
    > >     containing our routines. This is the only free license."

    >
    > > As the last sentence quoted above implies, there are other license
    > > options, but you have to pay for all of them (paying for the book
    > > doesn't count).

    >
    > My problem with the treatment was the large, proprietary module that
    > needed to be included in order to make the smallest of examples work.


    I think that part of the Numerical Recipes is in the public domain .
    See http://www.nr.com/public-domain.html .
     
    Beliavsky, Jan 9, 2011
    #19
  20. writes:
    > In article <>, Uno <> wrote:
    >>On 1/2/2011 7:34 PM, Seebs wrote:
    >>> On 2011-01-02, robin<> wrote:
    >>>
    >>>> Pointers are probably best avoided.
    >>>
    >>> Not in a book that's supposed to be useful to C programmers.

    >>
    >>By what process do you get that? Programs without pointers aren't useful?

    >
    > In C, that is true. All of strings, arrays and (when used as objects)
    > functions are actually pointers, and it is important to know and use
    > that when passing them as function arguments.
    >
    > It is not true in Fortran.


    It's not true in C either.

    Strings are not pointers. Arrays are not pointers. Functions are not
    pointers.

    All three are typically managed using pointers, and a declaration that
    looks like a parameter of array or function type is really a pointer
    parameter.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 9, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Al Murphy

    Java numerical recipes online...

    Al Murphy, Feb 5, 2004, in forum: Java
    Replies:
    1
    Views:
    5,653
    Steve W. Jackson
    Feb 5, 2004
  2. Rouben Rostamian

    Re: numerical recipes book

    Rouben Rostamian, Jul 30, 2003, in forum: C Programming
    Replies:
    0
    Views:
    386
    Rouben Rostamian
    Jul 30, 2003
  3. E. Robert Tisdale

    Re: numerical recipes book

    E. Robert Tisdale, Jul 31, 2003, in forum: C Programming
    Replies:
    0
    Views:
    399
    E. Robert Tisdale
    Jul 31, 2003
  4. mma
    Replies:
    5
    Views:
    583
    Aleksander Nabaglo
    Dec 9, 2003
  5. Lew
    Replies:
    1
    Views:
    1,347
    Frank Cisco
    Feb 21, 2009
Loading...

Share This Page