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.
