* 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ 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; 9+ 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] 9+ messages in thread
end of thread, other threads:[~2010-02-19 18:19 UTC | newest] Thread overview: 9+ 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
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).