GSL extension ode-initval2-1.0 released

GSL extension ode-initval2-1.0 released

[Tuomo Keskitalo]

Hello,

FYI: I've released version 1.0 of ode-initval2 (ODE solver) extension 
library to GSL. Comments are welcome. It's available at

http://iki.fi/tuomo.keskitalo/gsl/ode-initval2/

Compared to GSL 1.13 ode-initval, ode-initval2 includes new Adams and 
BDF multistep methods (msadams and msbdf). Implicit steppers rk2imp and 
rk4imp have been modified to use Newton iteration, and implicit Euler 
method (rk1imp) has been added. Also, a new driver level has been added 
to simplify the use of the library.

The main change compared to previous version (ode-initval2-0.9) is in 
the interfaces. Now the stepper, evolve and control objects include a 
pointer to the driver object, through which they can communicate.

PS. I took down my ode-initval-additions git repository, since I have 
not updated it for a while.

Regards,
Tuomo

-- 
Tuomo.Keskitalo@iki.fi
http://iki.fi/tuomo.keskitalo

Re: [Help-gsl] GSL extension ode-initval2-1.0 released

[Forest Yang]

Hi Tuomo,

    Is there any plan to make it an official part of GSL ?


Forest.



On Sat, Jan 2, 2010 at 3:19 AM, Tuomo Keskitalo <Tuomo.Keskitalo@iki.fi> wrote:
> Hello,
>
> FYI: I've released version 1.0 of ode-initval2 (ODE solver) extension
> library to GSL. Comments are welcome. It's available at
>
> http://iki.fi/tuomo.keskitalo/gsl/ode-initval2/
>
> Compared to GSL 1.13 ode-initval, ode-initval2 includes new Adams and BDF
> multistep methods (msadams and msbdf). Implicit steppers rk2imp and rk4imp
> have been modified to use Newton iteration, and implicit Euler method
> (rk1imp) has been added. Also, a new driver level has been added to simplify
> the use of the library.
>
> The main change compared to previous version (ode-initval2-0.9) is in the
> interfaces. Now the stepper, evolve and control objects include a pointer to
> the driver object, through which they can communicate.
>
> PS. I took down my ode-initval-additions git repository, since I have not
> updated it for a while.
>
> Regards,
> Tuomo
>
> --
> Tuomo.Keskitalo@iki.fi
> http://iki.fi/tuomo.keskitalo
>
>
> _______________________________________________
> Help-gsl mailing list
> Help-gsl@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gsl
>

Re: [Help-gsl] GSL extension ode-initval2-1.0 released

[Tuomo Keskitalo]

Hello,

If we get to GSL v2 someday, I hope so.

----- Original message -----
> Hi Tuomo,
>
>        Is there any plan to make it an official part of GSL ?
>
>
> Forest.
>
>
>
> On Sat, Jan 2, 2010 at 3:19 AM, Tuomo Keskitalo <Tuomo.Keskitalo@iki.fi> wrote:
> > Hello,
> >
> > FYI: I've released version 1.0 of ode-initval2 (ODE solver) extension
> > library to GSL. Comments are welcome. It's available at
> >
> > http://iki.fi/tuomo.keskitalo/gsl/ode-initval2/
> >
> > Compared to GSL 1.13 ode-initval, ode-initval2 includes new Adams and BDF
> > multistep methods (msadams and msbdf). Implicit steppers rk2imp and rk4imp
> > have been modified to use Newton iteration, and implicit Euler method
> > (rk1imp) has been added. Also, a new driver level has been added to simplify
> > the use of the library.
> >
> > The main change compared to previous version (ode-initval2-0.9) is in the
> > interfaces. Now the stepper, evolve and control objects include a pointer to
> > the driver object, through which they can communicate.
> >
> > PS. I took down my ode-initval-additions git repository, since I have not
> > updated it for a while.
> >
> > Regards,
> > Tuomo
> >
> > --
> > Tuomo.Keskitalo@iki.fi
> > http://iki.fi/tuomo.keskitalo
> >
> >
> > _______________________________________________
> > Help-gsl mailing list
> > Help-gsl@gnu.org
> > http://lists.gnu.org/mailman/listinfo/help-gsl
> >

Re: libflame version 4.0 announced

[Gerard Jungman]

I spent a little time looking at the libflame manual. I have some
questions; maybe somebody knows the answers.

(1) The library requires FLA_Init() and FLA_Finalize(). I wonder
    what library-level data is initialized and how this interacts
    with multi-threading. It looks like it is meant to work ok
    with threads, but there is a build switch (--enable-multithreading)
    which makes me wonder what is going on. I don't like
    any kind of hidden state, and I really don't like
    hidden global state.

(2) The LAPACK-like coverage seems reasonable. But I am not a good
    judge of this. How much LAPACK functionality is covered in
    this latest release? Obviously all the banded-matrix stuff
    is out, since libflame does nothing with banded matrices.
    But how complete is it regarding core functionality?

(3) The separation of the metadata (FLA_Obj) and the data buffer is
    good. At least this means that a wrapper implementation (say C++)
    can use any allocation scheme it likes for the buffer. I'm not sure
    about FLA_Obj itself. From the code examples, it appears that
    FLA_Obj is stack friendly. But I can't be sure without looking
    at the headers. So I guess I can answer this question myself...
    but I'm tired now.

(4) According to the manual, libflame calls abort() when it encounters
    a problem. As I have discussed before, this is brain-damaged. It
    makes it hard for other library developers (us) to integrate
    their thing into an existing error-handling system. They seem
    to admit it is a problem, but it's probably a low priority
    for them. How can we integrate this?

(5) There are many configuration/build options. Is it feasible to
    build and deploy several different versions (with and without
    SuperMatrix, etc), from which a selection can be made at link
    time, requiring no source-level changes in client code?


Some random comments:

(a) I'm not sure what it would mean to "use libflame under gsl-2.0",
    as mentioned below. We need to think about ways to insulate
    ourselves from any specific project, while still allowing it
    to be used transparently.

(b) libflame does not provide BLAS functionality, it requires
    an external BLAS. This is good, since people want to use
    special optimized versions for their architectures. But
    it also means we have the same problem as with GSL:
    detecting and linking against an appropriate BLAS,
    and dealing with its possible absence. It would be
    better if we could eliminate gslcblas once and for all,
    or at least factor it out of the main release somehow.

(c) In the libflame world, it looks like scalars are themselves
    instances of 'FLA_Obj'. Ok, I can see the logical coherence
    in this, but it seems like it could be very inconvenient at
    times.

(d) There are several places where the API assumes C stdio. It looks
    like some of these uses are internal (like FLA_Print_message
    being used for error messages). This is brain-damaged, since
    it makes it harder to integrate into other environments
    (i.e. C++) where C stdio is not appropriate. It's ok to
    have such "convenience" functions in the API, but they
    should not be used internally.

(e) The autotools build looks somewhat annoying. I'm really
    tired of autotools. Obviously, the same is true of GSL.

(f) The API has both capitals and underscores, the worst choice
    of all. Seemingly trivial, but it makes me queasy. Will people
    never learn?


I'm not trying to be super-critical. But if we are seriously
considering this thing, then no stone will be left un-turned.

--
G. Jungman



-------- Original Message -------- 
Subject: 	libflame version 4.0 announced
Date: 	Sun, 14 Feb 2010 00:15:04 -0600
From: 	Rhys Ulerich <rhys.ulerich@gmail.com>
To: 	gsl-discuss@sourceware.org


Hi all,

There was some talk several months back on using libflame underneath
GSL 2.0.  libflame 4.0 was announced today, and it both includes
row-major support and eliminates their lingering Fortran/LAPACK
dependencies.  The release announcement follows...

- Rhys

Re: libflame version 4.0 announced

[Brian Gough]

At Tue, 16 Feb 2010 16:37:31 -0700,
Gerard Jungman wrote:
> (2) The LAPACK-like coverage seems reasonable. But I am not a good
>     judge of this. How much LAPACK functionality is covered in
>     this latest release? Obviously all the banded-matrix stuff
>     is out, since libflame does nothing with banded matrices.
>     But how complete is it regarding core functionality?

The main omissions currently are eigenvalues and SVD.

However, since everything in FLAME is derived automatically from a
high-level description it should be easier for them to add new
algorithms in the long run.

The problems below are all fixable I am sure.

> (4) According to the manual, libflame calls abort() when it encounters
>     a problem. As I have discussed before, this is brain-damaged. It
>     makes it hard for other library developers (us) to integrate
>     their thing into an existing error-handling system. They seem
>     to admit it is a problem, but it's probably a low priority
>     for them. How can we integrate this?
> 
> (5) There are many configuration/build options. Is it feasible to
>     build and deploy several different versions (with and without
>     SuperMatrix, etc), from which a selection can be made at link
>     time, requiring no source-level changes in client code?


> (d) There are several places where the API assumes C stdio. It looks
>     like some of these uses are internal (like FLA_Print_message
>     being used for error messages). This is brain-damaged, since
>     it makes it harder to integrate into other environments
>     (i.e. C++) where C stdio is not appropriate. It's ok to
>     have such "convenience" functions in the API, but they
>     should not be used internally.
> 
> (e) The autotools build looks somewhat annoying. I'm really
>     tired of autotools. Obviously, the same is true of GSL.

Re: libflame version 4.0 announced

[Gerard Jungman]

On Wed, 2010-02-17 at 21:04 +0000, Brian Gough wrote:
> 
> The problems below are all fixable I am sure.

Sure, they're fixable, but the question is by whom.
I'm trying to chart a specific course for integration.

I assume we don't want to touch (fork) their code
base; that's to be avoided at almost all costs.

I just want to link against it, presumably through
some GSL-owned insulation layer, which can be
configured to point to any conforming implementation.
Similar to the BLAS wrapper layer.

But this requires some kind of interface design. With
BLAS we were lucky that a standard C interface existed
already. But it's not so clear what a "standard" LAPACK
interface would look like. It's very nice that they have
gifted us with their implementation and their interfaces
for a model. But it doesn't leave us entirely off the hook.

The other big problem is what to do with their data
structures. Obviously we need an insulation layer to
protect clients from changes in FLA_Obj and friends.


Here are some problems to be solved:

(1) Explicitly specify the data layout for buffers of underlying
    types. There is presumably only one reasonable way to do this,
    but we should be sure not to paint ourselves into a corner
    in some initially unforeseen way. Understand how it fits
    into a larger scheme involving multiarrays, etc. Make sure
    that it makes sense _across_ language barriers. This includes
    things like the complex types. What is our philosophy about
    packing complex types and can we make it language-neutral?
    Is this a solved problem yet?

(2) Decide how to map (semantically and syntactically) the
    FLAME picture of metadata to/from anything else we might
    want to expose. Do we compose our metadata objects from
    theirs (bad insulation?)? Do we transform representations
    on the fly (performance penalties?)? Is metadata hidden
    behind functional interfaces (performance again?)? Or
    is it exposed (as documented struct elements for example)?

    I am perfectly happy to accept their definitions for the
    abstract metadata. It's good to have a document (FLAME manual)
    that lays it all out explicitly. But there is still stuff to do.

(3) Design an access scheme that makes sense, i.e. no awful
    element-wise '_get' and '_set' functions. Make sure that
    GSL clients have full and free access to the data buffer,
    so that it can be manipulated directly, passed to external
    functions for element-wise processing, etc. Make sure that
    other GSL components that expect globs of data are friendly
    to these buffers and to the metadata that may be needed to
    guide access to these buffers. Also make sure no
    heap-centric-isms creep in.


These are only some things to think about. Of course, I have
some (very preliminary) opinions, but that's for later discussions.

--
G. Jungman

Re: libflame version 4.0 announced

[Rhys Ulerich]

> But this requires some kind of interface design. With
> BLAS we were lucky that a standard C interface existed
> already. But it's not so clear what a "standard" LAPACK
> interface would look like.

FWIW, there's an attempt at a "standard" LAPACK interface over at the
Intel Software Forums [1] aiming to be a CBLAS-for-LAPACK.  It has
been silent for awhile though.

- Rhys

[1] http://software.intel.com/en-us/forums/showthread.php?t=61234

Re: libflame version 4.0 announced

[Brian Gough]

At Wed, 17 Feb 2010 15:47:49 -0700,
Gerard Jungman wrote:
> I just want to link against it, presumably through
> some GSL-owned insulation layer, which can be
> configured to point to any conforming implementation.
> Similar to the BLAS wrapper layer.
> 
> But this requires some kind of interface design. With
> BLAS we were lucky that a standard C interface existed
> already. But it's not so clear what a "standard" LAPACK
> interface would look like. It's very nice that they have
> gifted us with their implementation and their interfaces
> for a model. But it doesn't leave us entirely off the hook.
> 
> The other big problem is what to do with their data
> structures. Obviously we need an insulation layer to
> protect clients from changes in FLA_Obj and friends.

I envisioned two simple things to add FLAME support in GSL:

- a set of wrapper functions to call the high-level flame routines
  (Cholesky, LU, QR etc) with gsl_vector/matrix arguments (via the
  simple create+attach_buffer method, as in the FLAME/C examples in
  the manual).

  This would be a direct alternative to the gsl_linalg routines.

  e.g. gsl_linalg_LU_decomp (gsl_matrix * A, gsl_permutation * p, int *signum)
  => gsl_flame_LU_decomp (gsl_matrix * A, gsl_permutation * p)

- a few (trivial) utility functions to convert from gsl_vector/matrix
  to FLA_Obj.

-- 
Brian Gough

Re: libflame version 4.0 announced

[James Amundson]

On 02/17/2010 03:04 PM, Brian Gough wrote:
> At Tue, 16 Feb 2010 16:37:31 -0700,
> Gerard Jungman wrote:
>    
>> (2) The LAPACK-like coverage seems reasonable. But I am not a good
>>      judge of this. How much LAPACK functionality is covered in
>>      this latest release? Obviously all the banded-matrix stuff
>>      is out, since libflame does nothing with banded matrices.
>>      But how complete is it regarding core functionality?
>>      
> The main omissions currently are eigenvalues and SVD.
>    
Uh... Those are pretty big omissions.

--Jim