public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gerard Jungman <jungman@lanl.gov>
To: gsl-discuss@sourceware.org
Subject: Re: simplicity vs. efficiency of algorithms in GSL
Date: Thu, 25 Sep 2008 00:07:00 -0000	[thread overview]
Message-ID: <1222301240.30638.146.camel@bellerophon.lanl.gov> (raw)
In-Reply-To: <m3hc85xn1t.wl%bjg@network-theory.co.uk>


On Wed, 2008-09-24 at 22:15 +0100, Brian Gough wrote:
> I mentally gave up on LAPACK as an option a long time ago.

Sounds reasonable. I'm tired of waiting for them to produce
something attractive. But what do we do?


> The FLAME
> library has more potential, it is LGPL'ed and faster than LAPACK, but
> it does not have all the functionality [1].

Interesting. Are we waiting for them to do something practical,
like generate a feature-complete LAPACK replacement? I hope they do...

More than that, I hope they produce an interface that makes sense.
Enough sense that people are motivated to code to it.


> Realistically I see the role of GSL as an alternative to Numerical
> Recipes and other similar non-free libraries.  None of these have any
> super features but they are still widely used.  As such, I would see
> simplicity, ease of use and good documentation as priorities.

I don't know about this "alternative to NR" philosophy. Those words have
been used before; they make some sense, as far as they go. But that's
really aiming pretty low. GSL is far from perfect, but, in my opinion,
it is clearly better than NR in every way.

As far as the range of functionality to encompass, I agree with
Robert Brown; we should have everything. That doesn't mean we have
to implement everything, we just have to know how it would fit in.
I think figuring out how components fit together is most of the battle.

For the same reason, simplicity vs efficiency is not the right argument.
Experts should produce the the most efficient code, in some rational
and usable form, and we should use it. The only thing that prevents us
from doing this tomorrow is that, as far as I can tell, no expert has
managed to produce what we need in a rational and usable form. For me,
rational and usable means that it solves all those tedious problems
that plague the fortran-to-anything-else interface. At least that
would be a start.

Of course, I like things to be neat and tidy; that's just me. Maybe
other people don't mind having to cobble things together, but I have
a very low threshold for that. There's no work I do that is so
compelling that I don't care how painful it is to get the answer.
And I always want better tools.

I think we surpassed the "alternative to NR" goal some years ago.
Now we should try to make the best possible thing. Period. And my
reasons are very mercenary; if there were such a thing, then
I would be able to use it.

--
G. Jungman


  reply	other threads:[~2008-09-25  0:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200809221621.54890.emanuele.passera@treuropa.com>
     [not found] ` <20080922162507.GA29877@hippogriff.homeunix.org>
2008-09-22 18:32   ` Tuomo Keskitalo
2008-09-22 19:48     ` Patrick Alken
2008-09-22 21:01       ` Robert G. Brown
2008-09-23 21:52         ` Gerard Jungman
2008-09-24 21:19           ` Brian Gough
2008-09-25  0:07             ` Gerard Jungman [this message]
2008-09-25  3:07               ` Andrew W. Steiner
2008-09-25  3:50               ` Z F
2008-09-26 21:48               ` Brian Gough
2008-09-27  6:12                 ` Jochen Küpper
2008-09-29 13:35                   ` Brian Gough
2008-10-07 21:14                   ` Gerard Jungman
2008-10-09 18:38                     ` Tuomo Keskitalo
2008-10-09 18:57                       ` Frank Reininghaus
2008-10-09 21:17                         ` Gerard Jungman
2008-10-10  0:05                       ` Gerard Jungman
2008-10-10 15:50                         ` Robert G. Brown
2008-10-10 18:47                           ` James Amundson
2008-10-11  2:48                         ` Brian Gough
2008-10-14 21:33                           ` Gerard Jungman
2008-10-14 22:41                             ` Daniel Franke
2008-10-16 22:20                               ` Gerard Jungman
2008-10-17 13:27                             ` Brian Gough

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1222301240.30638.146.camel@bellerophon.lanl.gov \
    --to=jungman@lanl.gov \
    --cc=gsl-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).