* GSL extension ode-initval2-1.0 released
@ 2010-01-02 8:19 Tuomo Keskitalo
2010-01-22 9:16 ` [Help-gsl] " Forest Yang
2010-02-16 23:36 ` libflame version 4.0 announced Gerard Jungman
0 siblings, 2 replies; 11+ messages in thread
From: Tuomo Keskitalo @ 2010-01-02 8:19 UTC (permalink / raw)
To: GSL Discuss Mailing List, Help-gsl, Info-gsl
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Help-gsl] GSL extension ode-initval2-1.0 released
2010-01-02 8:19 GSL extension ode-initval2-1.0 released Tuomo Keskitalo
@ 2010-01-22 9:16 ` Forest Yang
2010-01-23 11:15 ` Tuomo Keskitalo
2010-02-16 23:36 ` libflame version 4.0 announced Gerard Jungman
1 sibling, 1 reply; 11+ messages in thread
From: Forest Yang @ 2010-01-22 9:16 UTC (permalink / raw)
To: Tuomo Keskitalo; +Cc: GSL Discuss Mailing List, Help-gsl, Info-gsl
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Help-gsl] GSL extension ode-initval2-1.0 released
2010-01-22 9:16 ` [Help-gsl] " Forest Yang
@ 2010-01-23 11:15 ` Tuomo Keskitalo
0 siblings, 0 replies; 11+ messages in thread
From: Tuomo Keskitalo @ 2010-01-23 11:15 UTC (permalink / raw)
To: Forest Yang; +Cc: GSL Discuss Mailing List
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
> >
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libflame version 4.0 announced
2010-01-02 8:19 GSL extension ode-initval2-1.0 released Tuomo Keskitalo
2010-01-22 9:16 ` [Help-gsl] " Forest Yang
@ 2010-02-16 23:36 ` Gerard Jungman
2010-02-17 21:20 ` Brian Gough
1 sibling, 1 reply; 11+ messages in thread
From: Gerard Jungman @ 2010-02-16 23:36 UTC (permalink / raw)
To: GSL Discuss Mailing List
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libflame version 4.0 announced
2010-02-16 23:36 ` libflame version 4.0 announced Gerard Jungman
@ 2010-02-17 21:20 ` Brian Gough
2010-02-17 22:49 ` Gerard Jungman
2010-02-17 22:51 ` James Amundson
0 siblings, 2 replies; 11+ messages in thread
From: Brian Gough @ 2010-02-17 21:20 UTC (permalink / raw)
To: Gerard Jungman; +Cc: GSL Discuss Mailing List
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libflame version 4.0 announced
2010-02-17 21:20 ` Brian Gough
@ 2010-02-17 22:49 ` Gerard Jungman
2010-02-17 23:10 ` Rhys Ulerich
2010-02-19 18:19 ` Brian Gough
2010-02-17 22:51 ` James Amundson
1 sibling, 2 replies; 11+ messages in thread
From: Gerard Jungman @ 2010-02-17 22:49 UTC (permalink / raw)
To: GSL Discuss Mailing List
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libflame version 4.0 announced
2010-02-17 21:20 ` Brian Gough
2010-02-17 22:49 ` Gerard Jungman
@ 2010-02-17 22:51 ` James Amundson
1 sibling, 0 replies; 11+ messages in thread
From: James Amundson @ 2010-02-17 22:51 UTC (permalink / raw)
To: Brian Gough; +Cc: Gerard Jungman, GSL Discuss Mailing List
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libflame version 4.0 announced
2010-02-17 22:49 ` Gerard Jungman
@ 2010-02-17 23:10 ` Rhys Ulerich
2010-02-19 18:19 ` Brian Gough
1 sibling, 0 replies; 11+ messages in thread
From: Rhys Ulerich @ 2010-02-17 23:10 UTC (permalink / raw)
To: GSL Discuss Mailing List
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libflame version 4.0 announced
2010-02-17 22:49 ` Gerard Jungman
2010-02-17 23:10 ` Rhys Ulerich
@ 2010-02-19 18:19 ` Brian Gough
1 sibling, 0 replies; 11+ messages in thread
From: Brian Gough @ 2010-02-19 18:19 UTC (permalink / raw)
To: GSL Discuss Mailing List
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libflame version 4.0 announced
2010-02-14 6:15 Rhys Ulerich
@ 2010-02-17 21:20 ` Brian Gough
0 siblings, 0 replies; 11+ messages in thread
From: Brian Gough @ 2010-02-17 21:20 UTC (permalink / raw)
To: Rhys Ulerich; +Cc: gsl-discuss
At Sun, 14 Feb 2010 00:15:04 -0600,
Rhys Ulerich wrote:
> 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...
Hooray.
^ permalink raw reply [flat|nested] 11+ messages in thread
* libflame version 4.0 announced
@ 2010-02-14 6:15 Rhys Ulerich
2010-02-17 21:20 ` Brian Gough
0 siblings, 1 reply; 11+ messages in thread
From: Rhys Ulerich @ 2010-02-14 6:15 UTC (permalink / raw)
To: gsl-discuss
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
---------- Forwarded message ----------
From: Robert van de Geijn <rvdg@cs.utexas.edu>
Date: Sat, Feb 13, 2010 at 8:26 PM
Subject: libflame version 4.0
Folks,
in time for SIAM PP10 Field has released the next libflame milestone
release (version 4.0).
So see what changes have been incorporated, see
http://z.cs.utexas.edu/wiki/flame.wiki/libflame/
The world can now say goodbye to column major order (both row and
column major order are now supported) and Fortran.
Congratulations Field! (with help from Ernie.)
Robert van de Geijn
Professor of Computer Sciences
The University of Texas at Austin
rvdg@cs.utexas.edu
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-02-19 18:19 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-02 8:19 GSL extension ode-initval2-1.0 released Tuomo Keskitalo
2010-01-22 9:16 ` [Help-gsl] " Forest Yang
2010-01-23 11:15 ` Tuomo Keskitalo
2010-02-16 23:36 ` libflame version 4.0 announced Gerard Jungman
2010-02-17 21:20 ` Brian Gough
2010-02-17 22:49 ` Gerard Jungman
2010-02-17 23:10 ` Rhys Ulerich
2010-02-19 18:19 ` Brian Gough
2010-02-17 22:51 ` James Amundson
2010-02-14 6:15 Rhys Ulerich
2010-02-17 21:20 ` Brian Gough
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).