From: Alan W. I. <ir...@be...> - 2003-09-23 19:47:51
|
Hi Joao: Here are three issues I ran into with libnn and/or libcsa recently. * Name clash problems: When I built the RH7.3 rpm I discovered libnn already existed on that system for a quite different purpose: rpm -qif /usr/lib/libnn.a Name : unixODBC-devel Relocations: (not relocateable) Version : 2.2.0 Vendor: Red Hat, Inc. Release : 5 Build Date: Tue 16 Apr 2002 05:17:36 PM PDT Install date: Thu 19 Sep 2002 05:09:00 AM PDT Build Host: daffy.perf.redhat.com Group : Development/Libraries Source RPM: unixODBC-2.2.0-5.src.rpm Size : 2984533 License: LGPL Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.unixODBC.org/ Summary : Development files for programs which will use the unixODBC library. Description : The unixODBC package can be used to access databases through ODBC drivers. If you want to develop programs that will access data through ODBC, you need to install this package. I believe ODBC has nothing to do with interpolating irregularly sampled points so this libnn has nothing to do with "our" libnn. Furthermore, a google search for libnn shows lots of ODBC rpm references, and this is also apparently the name of a neural network library as well ==> double name clash. Apparently, there is also a potential name clash problem with libcsa (which is used for the name of a CDE library according to google and another library as well). The problem with nn and csa is they are just too short to be unique so the potential of name clashes is high. Joao, according to the various README documents, you got both these libraries from Pavel Sakov of CSIRO, but IIRC these are not widely distributed libraries which is why we are distributing them as part of PLplot and perhaps why we are the first group to run into the name clash problems. What do you think of putting sakov or csiro in the name (e.g., libcsiro_nn or libsakov_nn)? Another possibility is to use plplot in the name, but that depends, I think, on whether you are going to develop these libraries separately from Pavel or not (see license issue below). Another possibility for getting unique names is to spell out what they do, e.g., lib_cubic_spline_approximation and lib_natural_neighbours, but that solution would probably run into name length problems on some systems. * License issues with libcsa The README there says "The singular value decomposition code was borrowed from "Numerical Recipes in C", and sure enough I spot a version of the Numerical Recipes code, svdcmp in csa.c. The numerical recipes authors are fairly notorious for jealousy guarding their code so I don't think you can just "borrow" from them without risking some nasty consequences down the road. I just finished a large least-squares fit using SVD for my research, and because of the licensing nastiness with Numerical Recipes I chose to use the dgesdd routine from the lapack library instead. I suggest you should do the same. A complication is to find a fool-proof cross-platform way to interface from C to that fortran routine. You could use cfortran to do the heavy lifting (see http://packages.debian.org/unstable/devel/cfortran.html), but you would probably also have to use some variation on the BRAINDEAD method to make the names consistent cross-platform. (Note there is also a C version of lapack called clapack, but AFAIK it is not supported well, e.g., there is no package of that name in Debian.) * Also I noticed a lib linking style problem with libnn and libqhull which is incompatible with the hierarchical linking style that the libtool documentation recommends for best cross-platform success. There is a similar libpthreads linking style issue as well. I made the requisite Makefile.am changes, and did some minimal testing --with-pthreads for example x08c and x21c (both with -dev xwin). Everything seemed to work fine so I committed the changes. Joao, will you give these changes a test as well? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-09-24 02:01:22
|
[I forwarded this message to Pavel, the author of libnn and libcsa] On Tuesday 23 September 2003 20:47, Alan W. Irwin wrote: | Hi Joao: | | Here are three issues I ran into with libnn and/or libcsa recently. | | * Name clash problems: | | When I built the RH7.3 rpm I discovered libnn already existed on that | system for a quite different purpose: | | rpm -qif /usr/lib/libnn.a | Name : unixODBC-devel Relocations: (not relocateable) | Version : 2.2.0 Vendor: Red Hat, Inc. | Release : 5 Build Date: Tue 16 Apr 2002 | 05:17:36 PM PDT | Install date: Thu 19 Sep 2002 05:09:00 AM PDT Build Host: | daffy.perf.redhat.com | Group : Development/Libraries Source RPM: | unixODBC-2.2.0-5.src.rpm | Size : 2984533 License: LGPL | Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> | URL : http://www.unixODBC.org/ | Summary : Development files for programs which will use the unixODBC | library. | Description : | The unixODBC package can be used to access databases through ODBC | drivers. If you want to develop programs that will access data through | ODBC, you need to install this package. | | I believe ODBC has nothing to do with interpolating irregularly sampled | points so this libnn has nothing to do with "our" libnn. Furthermore, a | google search for libnn shows lots of ODBC rpm references, and this is | also apparently the name of a neural network library as well ==> double | name clash. Apparently, there is also a potential name clash problem with | libcsa (which is used for the name of a CDE library according to google and | another library as well). The problem with nn and csa is they are just too | short to be unique so the potential of name clashes is high. | | Joao, according to the various README documents, you got both these | libraries from Pavel Sakov of CSIRO, but IIRC these are not widely | distributed libraries which is why we are distributing them as part of | PLplot and perhaps why we are the first group to run into the name clash | problems. What do you think of putting sakov or csiro in the name (e.g., | libcsiro_nn or libsakov_nn)? Another possibility is to use plplot in the | name, but that depends, I think, on whether you are going to develop these | libraries separately from Pavel or not (see license issue below). Another | possibility for getting unique names is to spell out what they do, e.g., | lib_cubic_spline_approximation and lib_natural_neighbours, but that | solution would probably run into name length problems on some systems. I think that prefixing with csiro will be OK. Are we going to use domain names as java packages do to avoid name clashes :-? Pavel, what do you think about this? To refresh your memory, we at PLplot are using (with your permission) your libnn and libcsa libraries, and are distributing them as separate libraries, so users can use them alone, if they want to. The only modification I have done to libnn is to add support for libqhull, as "triangle" is non free, according to the LGLP license that we use at Plplot. | * License issues with libcsa | | The README there says "The singular value decomposition code was borrowed | from "Numerical Recipes in C", and sure enough I spot a version of the | Numerical Recipes code, svdcmp in csa.c. The numerical recipes authors | are fairly notorious for jealousy guarding their code so I don't think you | can just "borrow" from them without risking some nasty consequences down | the road. I was not aware of this. And it is certainly a problem. | I just finished a large least-squares fit using SVD for my | research, and because of the licensing nastiness with Numerical Recipes I | chose to use the dgesdd routine from the lapack library instead. This is definitively an option (shouldn't it be dgesvd?). | I suggest | you should do the same. A complication is to find a fool-proof | cross-platform way to interface from C to that fortran routine. Haven't the gsc (Gnu Scientific Library) guys converted dgesvd to C? humm, they have implemented their own SVD, based on "the Golub-Reinsch SVD algorithm", which I think is the same algorithm that NR uses (at least their names are in the NR references). But requiring the huge gsc library or a fortran compiler is an overkill... another solution must be devised. Pavel, what do you think about this? As you are using "triangle", I don't think this is a problem to you, right? | You could | use cfortran to do the heavy lifting (see | http://packages.debian.org/unstable/devel/cfortran.html), but you would | probably also have to use some variation on the BRAINDEAD method to make | the names consistent cross-platform. (Note there is also a C version of | lapack called clapack, but AFAIK it is not supported well, e.g., there is | no package of that name in Debian.) | | * Also I noticed a lib linking style problem with libnn and libqhull which | is incompatible with the hierarchical linking style that the libtool | documentation recommends for best cross-platform success. There is a | similar libpthreads linking style issue as well. I made the requisite | Makefile.am changes, and did some minimal testing --with-pthreads for | example x08c and x21c (both with -dev xwin). Everything seemed to work | fine so I committed the changes. Joao, will you give these changes | a test as well? OK, I will try ASAP. The best way to test the pthread feature is to open Octave, then: plot(sin(0:0.1:pi)); without pthreads, the plot window will not redraw/resize after the command prompt returns to Octave. This must also happens with other interpreted languages such as python. Ah! you probably can't try this with Octave, as normally it is not linked against libpthreads, so try with the equivalent Python commands (on my system python is linked with libpthreads) Joao |
From: Alan W. I. <ir...@be...> - 2003-09-24 02:51:55
|
On 2003-09-24 03:00+0100 Jo=E3o Cardoso wrote: > On Tuesday 23 September 2003 20:47, Alan W. Irwin wrote: > | I just finished a large least-squares fit using SVD for my > | research, and because of the licensing nastiness with Numerical Recipes= I > | chose to use the dgesdd routine from the lapack library instead. > > This is definitively an option (shouldn't it be dgesvd?). Both dgesvd and dgesdd compute the SVD, but the latter one has been developed more recently and uses something called the divide-and-conquor algorithm. I have no clue what that means, but since they went out of thei= r way to develop it later, I tried dgesdd first, and it worked very well. > > | I suggest > | you should do the same. A complication is to find a fool-proof > | cross-platform way to interface from C to that fortran routine. > > Haven't the gsc (Gnu Scientific Library) guys converted dgesvd to C? hum= m, > they have implemented their own SVD, based on "the Golub-Reinsch SVD > algorithm", which I think is the same algorithm that NR uses (at least th= eir > names are in the NR references). > But requiring the huge gsc library or a fortran compiler is an overkill..= =2E gsl (which I think is what you were referring to by gsc) is not appropriate for our LGPLed PLplot because gsl is licensed under GPL. On the other hand= , look up cfortran at http://packages.debian.org/unstable/devel/cfortran.html and on google. All it is is a convenient header to make life easy for calling fortran libraries from C or C libraries from fortran. No fortran compiler is involved. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2003-09-24 07:07:01
|
"Alan W. Irwin" wrote: >=20 > On 2003-09-24 03:00+0100 Jo=E3o Cardoso wrote: > > On Tuesday 23 September 2003 20:47, Alan W. Irwin wrote: > > | I just finished a large least-squares fit using SVD for my > > | research, and because of the licensing nastiness with Numerical Rec= ipes I > > | chose to use the dgesdd routine from the lapack library instead. > > > > This is definitively an option (shouldn't it be dgesvd?). >=20 > Both dgesvd and dgesdd compute the SVD, but the latter one has been > developed more recently and uses something called the divide-and-conquo= r > algorithm. I have no clue what that means, but since they went out of = their > way to develop it later, I tried dgesdd first, and it worked very well. >=20 > > > > | I suggest > > | you should do the same. A complication is to find a fool-proof > > | cross-platform way to interface from C to that fortran routine. > > > > Haven't the gsc (Gnu Scientific Library) guys converted dgesvd to C?= humm, > > they have implemented their own SVD, based on "the Golub-Reinsch SVD > > algorithm", which I think is the same algorithm that NR uses (at leas= t their > > names are in the NR references). > > But requiring the huge gsc library or a fortran compiler is an overki= ll... >=20 > gsl (which I think is what you were referring to by gsc) is not appropr= iate > for our LGPLed PLplot because gsl is licensed under GPL. On the other = hand, > look up cfortran at http://packages.debian.org/unstable/devel/cfortran.= html > and on google. All it is is a convenient header to make life easy for > calling fortran libraries from C or C libraries from fortran. No fortr= an > compiler is involved. >=20 > But there will be a Fortran compiler involved if you make PLplot from the=20 sources. (Is this cfortran by Burkhard Burow? I like that - have some=20 good experiences with it - the link above did not give me the name of the original developer). (More on the Fortran examples later, BTW) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2003-09-24 14:19:22
|
On 2003-09-24 09:06+0200 Arjen Markus wrote: > "Alan W. Irwin" wrote: > > [...] On the other hand, > > look up cfortran at http://packages.debian.org/unstable/devel/cfortran.html > > and on google. All it is is a convenient header to make life easy for > > calling fortran libraries from C or C libraries from fortran. No fortran > > compiler is involved. > > > > > > But there will be a Fortran compiler involved if you make PLplot from > the > sources. (Is this cfortran by Burkhard Burow? I like that - have some > good experiences with it - the link above did not give me the name of > the > original developer). Arjen, both you and Joao have mentioned a fortran compiler so perhaps I am missing something, but I still don't see why you would need one (except to compile the fortran interface and examples which is a different issue). It has been quite a while since I have used cfortran.h (and yes, that is the header developed by Burkhard Burow recently dual-licensed under the LGPL), but if I recall correctly, you simply include cfortran.h in your C code, and no fortran compilation is necessary to access routines in the fortran lapack library. Note, we don't compile dgesdd and the other lapack and BLAS routines that it calls, ourselves. lapack (which includes BLAS) is a completely independent package that is compiled and installed separately and which is available for all Unix/Linux platforms. We would have to put -llapack -lblas on the link line for libcsa and do the cfortran.h magic to make dgesdd accessible to C, but that is it. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2003-09-24 09:20:43
|
On 2003-09-23 19:51-0700 Alan W. Irwin wrote: > [...] All it (cfortran.h) is is a convenient header to make life easy for > calling fortran libraries from C or C libraries from fortran. No fortran > compiler is involved. I looked further, and cfortran is dual licensed with one license being LGPL. Perfect for PLplot. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2003-09-24 02:53:54
|
On 2003-09-24 03:00+0100 Jo=E3o Cardoso wrote: > The best way to test the pthread feature is to open Octave, then: > plot(sin(0:0.1:pi)); > without pthreads, the plot window will not redraw/resize after the comman= d > prompt returns to Octave. This must also happens with other interpreted > languages such as python. Ah! you probably can't try this with Octave, as > normally it is not linked against libpthreads, so try with the equivalent > Python commands (on my system python is linked with libpthreads) > I don't really understand what you have said here because I don't understan= d the limitation that the xwin driver had before which is now fixed by pthreads. Also, I don't understand what is a good test of the pthreads functionality. Does running x08c -dev xwin test it? Is that any different than ./pythondemos.py -dev xwin (which also works fine, I just discovered)? Or is there something entirely different within python I should be doing to test the pthreaded xwin driver? If so, perhaps we should make a pthreads example in C, python, etc. to ram home the point about what pthreads can do= =2E Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2003-09-24 04:15:27
|
On 2003-09-23 19:53-0700 Alan W. Irwin wrote: > On 2003-09-24 03:00+0100 Jo=E3o Cardoso wrote: > > > The best way to test the pthread feature is to open Octave, then: > > plot(sin(0:0.1:pi)); > > without pthreads, the plot window will not redraw/resize after the comm= and > > prompt returns to Octave. This must also happens with other interpreted > > languages such as python. Ah! you probably can't try this with Octave, = as > > normally it is not linked against libpthreads, so try with the equivale= nt > > Python commands (on my system python is linked with libpthreads) > > > > I don't really understand what you have said here because I don't underst= and > the limitation that the xwin driver had before which is now fixed by > pthreads. Also, I don't understand what is a good test of the pthreads > functionality. Does running x08c -dev xwin test it? Is that any differen= t > than ./pythondemos.py -dev xwin (which also works fine, I just discovered= )? > Or is there something entirely different within python I should be doing = to > test the pthreaded xwin driver? If so, perhaps we should make a pthreads > example in C, python, etc. to ram home the point about what pthreads can = do. OOPS. I just reread what you said more carefully and tried the experiment of doing the equivalent of pythondemos.py by hand from within python for plplot configure --with-pthreads. After import xw01, and return to python command-line, I can resize the (xwin) window without problems. So I think all is well. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-09-24 14:06:30
|
On Wednesday 24 September 2003 05:14, Alan W. Irwin wrote: | On 2003-09-23 19:53-0700 Alan W. Irwin wrote: | > On 2003-09-24 03:00+0100 Jo=E3o Cardoso wrote: | > > The best way to test the pthread feature is to open Octave, then: | > > plot(sin(0:0.1:pi)); | > > without pthreads, the plot window will not redraw/resize after | > > the command prompt returns to Octave. This must also happens with | > > other interpreted languages such as python. Ah! you probably | > > can't try this with Octave, as normally it is not linked against | > > libpthreads, so try with the equivalent Python commands (on my | > > system python is linked with libpthreads) | > | > I don't really understand what you have said here because I don't | > understand the limitation that the xwin driver had before which is | > now fixed by pthreads. Also, I don't understand what is a good test | > of the pthreads functionality. Does running x08c -dev xwin test it? | > Is that any different than ./pythondemos.py -dev xwin (which also | > works fine, I just discovered)? Or is there something entirely | > different within python I should be doing to test the pthreaded | > xwin driver? If so, perhaps we should make a pthreads example in | > C, python, etc. to ram home the point about what pthreads can do. | | OOPS. I just reread what you said more carefully and tried the | experiment of doing the equivalent of pythondemos.py by hand from | within python for plplot configure --with-pthreads. After import | xw01, and return to python command-line, I can resize the (xwin) | window without problems. So I think all is well. To be sure, try with plplot configured without pthreads. The problem is even more severe when one has multiple plot windows--if=20 one gets obscured by another, it will not redraw itself (unless=20 =2D-pthreads is used). This doesn't happens only under interpreted languages. As an example, if=20 you change x01c.c so that the programs makes a lengthly computation=20 after doing a plot, the same happens, i.e., while the program is doing=20 the computation the plot window will not redraw/resize itself. Joao Joao | | Alan | __________________________ | Alan W. Irwin | email: ir...@be... | phone: 250-727-2902 | | Astronomical research affiliation with Department of Physics and | Astronomy, University of Victoria (astrowww.phys.uvic.ca). | | Programming affiliations with the PLplot scientific plotting software | package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), | the Loads of Linux Links project (loll.sf.net), and the Linux | Brochure Project (lbproject.sf.net). | __________________________ | | Linux-powered Science | __________________________ |
From: <jc...@fe...> - 2003-09-24 15:55:33
|
On Wednesday 24 September 2003 08:06, Arjen Markus wrote: | "Alan W. Irwin" wrote: | > On 2003-09-24 03:00+0100 Jo=E3o Cardoso wrote: | > > On Tuesday 23 September 2003 20:47, Alan W. Irwin wrote: | > > | I just finished a large least-squares fit using SVD for my | > > | research, and because of the licensing nastiness with Numerical | > > | Recipes I chose to use the dgesdd routine from the lapack | > > | library instead. | > > | > > This is definitively an option (shouldn't it be dgesvd?). | > | > Both dgesvd and dgesdd compute the SVD, but the latter one has been | > developed more recently and uses something called the | > divide-and-conquor algorithm. I have no clue what that means, but | > since they went out of their way to develop it later, I tried | > dgesdd first, and it worked very well. | > | > > | I suggest | > > | you should do the same. A complication is to find a fool-proof | > > | cross-platform way to interface from C to that fortran routine. | > > | > > Haven't the gsc (Gnu Scientific Library) guys converted dgesvd | > > to C? humm, they have implemented their own SVD, based on "the | > > Golub-Reinsch SVD algorithm", which I think is the same algorithm | > > that NR uses (at least their names are in the NR references). | > > But requiring the huge gsc library or a fortran compiler is an | > > overkill... | > | > gsl (which I think is what you were referring to by gsc) is not | > appropriate for our LGPLed PLplot because gsl is licensed under | > GPL. On the other hand, look up cfortran at | > http://packages.debian.org/unstable/devel/cfortran.html and on | > google. All it is is a convenient header to make life easy for | > calling fortran libraries from C or C libraries from fortran. No | > fortran compiler is involved. | | But there will be a Fortran compiler involved if you make PLplot from | the | sources. Yes, that is the problem. And dgesdd or dgesvd uses other lapack=20 subrotines, and we don't want to include the full lapack library in=20 plplot. For example, dgesvd.c from clapack, with all its dependencies,=20 has about 430KB! I'm not worried with support, as these are rather old=20 and well tested subrotines, and we are not going to change them (I will=20 not!) BTW, lapack used to be distributed under SuSE, but it is not anymore... What we need is a single svd.c file. Or a self-contained fortran svd.f=20 that we could translate (once) to C using f2c or similar. James Arvo , e.g., as a (not self-contained) svd.C=20 http://www.cs.caltech.edu/~arvo/code/SVD.C that is derived from NR. http://robotics.jpl.nasa.gov/~leimgrub/scanner/svd.c is also derived=20 from NR code... I think that most people uses code from NR, as their license terms are=20 "free as long as you don't profit with it" and most researchers just=20 don't care -- this is also the problem with "triangle" and most=20 optimization code. What choices do we have other then clapack? Reading the NR text (not the=20 code!) and implement our own SVD.c? Joao | (Is this cfortran by Burkhard Burow? I like that - have some | good experiences with it - the link above did not give me the name of | the | original developer). | | (More on the Fortran examples later, BTW) | Regards, | | Arjen | | | | ------------------------------------------------------- | This sf.net email is sponsored by:ThinkGeek | Welcome to geek heaven. | http://thinkgeek.com/sf | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2003-09-24 19:27:14
|
On 2003-09-24 16:54+0100 Jo=E3o Cardoso wrote: > | But there will be a Fortran compiler involved if you make PLplot from > | the > | sources. > > Yes, that is the problem. And dgesdd or dgesvd uses other lapack > subrotines, and we don't want to include the full lapack library in > plplot. For example, dgesvd.c from clapack, with all its dependencies, > has about 430KB! I'm not worried with support, as these are rather old > and well tested subrotines, and we are not going to change them (I will > not!) You misunderstood what I said. I am not advocating incorporating the relevant part of lapack source into plplot. As you say, that is much too big, and also I would be concerned about supporting it. Instead, I am advocating simply *linking* to lapack which should be straightforward with the help of cfortran.h. > BTW, lapack used to be distributed under SuSE, but it is not anymore... Note you can get RH rpm's here (http://www.netlib.org/lapack/rpms/), and I also checked rpmfind, and there are 45 hits (!) including SuSe for lapack. Of course if none of these are suitable for some distro, or for the case of some of our Unix users where lapack may not be system-installed, the PLplot user always has the option to download and build and install lapack for themselves. I have done that a few times in the distant past, and it was completely straightforward. However, I think the vast majority of our users will not have to do that. > > What we need is a single svd.c file. Or a self-contained fortran svd.f > that we could translate (once) to C using f2c or similar. I don't like that solution at all because it is a lot of work to get that SVD coding right and tested properly. Also, it unnecessarily bulks up our source code and we have to support it. I far prefer linking to an external (and well-known) library which is already well tested, which others support= , and which most users have immediate access to as an rpm or deb. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-09-24 23:27:51
|
On Wednesday 24 September 2003 20:26, Alan W. Irwin wrote: | On 2003-09-24 16:54+0100 Jo=E3o Cardoso wrote: | > | But there will be a Fortran compiler involved if you make PLplot from | > | the | > | sources. | > | > Yes, that is the problem. And dgesdd or dgesvd uses other lapack | > subrotines, and we don't want to include the full lapack library in | > plplot. For example, dgesvd.c from clapack, with all its dependencies, | > has about 430KB! I'm not worried with support, as these are rather old | > and well tested subrotines, and we are not going to change them (I will | > not!) | | You misunderstood what I said. I am not advocating incorporating the | relevant part of lapack source into plplot. As you say, that is much too | big, and also I would be concerned about supporting it. Instead, I am | advocating simply *linking* to lapack which should be straightforward wi= th | the help of cfortran.h. Yes, that is the fast and simplest solution. But overkill; after all we are= =20 replacing a 230 lines function by a whole library! It would be much better = if=20 we could find a single file svd.c. Joao | > BTW, lapack used to be distributed under SuSE, but it is not anymore... | | Note you can get RH rpm's here (http://www.netlib.org/lapack/rpms/), and= I | also checked rpmfind, and there are 45 hits (!) including SuSe for lapac= k. | Of course if none of these are suitable for some distro, or for the case | of some of our Unix users where lapack may not be system-installed, the | PLplot user always has the option to download and build and install lapack | for themselves. I have done that a few times in the distant past, and it | was completely straightforward. However, I think the vast majority of our | users will not have to do that. | | > What we need is a single svd.c file. Or a self-contained fortran svd.f | > that we could translate (once) to C using f2c or similar. | | I don't like that solution at all because it is a lot of work to get that | SVD coding right and tested properly. Also, it unnecessarily bulks up o= ur | source code and we have to support it. I far prefer linking to an | external (and well-known) library which is already well tested, which | others support, and which most users have immediate access to as an rpm or | deb. | | Alan | __________________________ | Alan W. Irwin | email: ir...@be... | phone: 250-727-2902 | | Astronomical research affiliation with Department of Physics and | Astronomy, University of Victoria (astrowww.phys.uvic.ca). | | Programming affiliations with the PLplot scientific plotting software | package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the | Loads of Linux Links project (loll.sf.net), and the Linux Brochure Proje= ct | (lbproject.sf.net). | __________________________ | | Linux-powered Science | __________________________ | | | ------------------------------------------------------- | This sf.net email is sponsored by:ThinkGeek | Welcome to geek heaven. | http://thinkgeek.com/sf | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2003-09-25 00:45:50
|
On 2003-09-25 00:27+0100 Jo=E3o Cardoso wrote: > On Wednesday 24 September 2003 20:26, Alan W. Irwin wrote: > | You misunderstood what I said. I am not advocating incorporating the > | relevant part of lapack source into plplot. As you say, that is much t= oo > | big, and also I would be concerned about supporting it. Instead, I am > | advocating simply *linking* to lapack which should be straightforward = with > | the help of cfortran.h. > > Yes, that is the fast and simplest solution. But overkill; after all we a= re > replacing a 230 lines function by a whole library! It would be much bette= r if > we could find a single file svd.c. If you could find ~200-line SVD code written in C that does a reasonable jo= b without license restrictions, then that is good enough, and it certainly does have the advantage of being self-contained. However, I also presume that the -llapack -lblas solution will do an outstanding SVD job for us in case you cannot find a viable compact SVD code solution. And I am not worried about linking to two additional well-supported libraries like these when we already link to quite a few libraries already. So I think the best thing to do is for me to dust off my autotools and cfortran knowledge, and really see how straightforward this is going to be. In other words it is time for me to show the code. :-) If/when I commit an -llapack -lblas solution, I will try to do it in such a way that it is easy to replace if you are able to find some compact SVD C code that we can use instead without running into licensing concerns. Of course, if you find that code first, please let me know, and I will be happy to quit this extra work. :-) Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-09-25 01:28:57
|
On Thursday 25 September 2003 01:45, Alan W. Irwin wrote: | On 2003-09-25 00:27+0100 Jo=E3o Cardoso wrote: | > On Wednesday 24 September 2003 20:26, Alan W. Irwin wrote: | > | You misunderstood what I said. I am not advocating incorporating the | > | relevant part of lapack source into plplot. As you say, that is much | > | too big, and also I would be concerned about supporting it. Instead, | > | I am advocating simply *linking* to lapack which should be | > | straightforward with the help of cfortran.h. | > | > Yes, that is the fast and simplest solution. But overkill; after all we | > are replacing a 230 lines function by a whole library! It would be much | > better if we could find a single file svd.c. | | If you could find ~200-line SVD code written in C I was talking about the SVD NR code included in csa.c, it's 232 lines. I had already searched netlib and gams, but stoped at (c)lapack; however,=20 eispack has an almost self-contained svd.f: http://www.netlib.org/cgi-bin/netlibfiles.pl?filename=3D/eispack/svd.f After converting it to C with the help of f2c, it resulted in a 577 lines f= ile=20 (the original fortrans code has 358 lines of code). However I get an=20 undefined symbol when trying to link with a dummy main():=20 jcard@linux:~/Desktop/eispack> gcc test.c svd.o pythag.o -o test -lm svd.o(.text+0x363): In function `svd_': : undefined reference to `d_sign' svd.o(.text+0x784): In function `svd_': : undefined reference to `d_sign' svd.o(.text+0x16ae): In function `svd_': : undefined reference to `d_sign' collect2: ld returned 1 exit status Of course using f2c means linking with -lf2c, but perhaps that could be=20 avoided in our case, as we don't need entry/exit points. Your knowledge of= =20 fortran can be helpfull -- I don't even know how to call the subrotine :( Can you help? (The pythag.c is a 50 line subrotine used by svd.c that netlib also sent to= me=20 :) | that does a reasonable | job without license restrictions, then that is good enough, and it | certainly does have the advantage of being self-contained. However, I also | presume that the -llapack -lblas solution will do an outstanding SVD job | for us in case you cannot find a viable compact SVD code solution. And I | am not worried about linking to two additional well-supported libraries | like these when we already link to quite a few libraries already. Neither me! only if I can't keep it simple. Joao | So I think the best thing to do is for me to dust off my autotools and | cfortran knowledge, and really see how straightforward this is going to | be. In other words it is time for me to show the code. :-) If/when I comm= it | an -llapack -lblas solution, I will try to do it in such a way that it is | easy to replace if you are able to find some compact SVD C code that we c= an | use instead without running into licensing concerns. Of course, if you | find that code first, please let me know, and I will be happy to quit this | extra work. :-) | | Alan | __________________________ | Alan W. Irwin | email: ir...@be... | phone: 250-727-2902 | | Astronomical research affiliation with Department of Physics and | Astronomy, University of Victoria (astrowww.phys.uvic.ca). | | Programming affiliations with the PLplot scientific plotting software | package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the | Loads of Linux Links project (loll.sf.net), and the Linux Brochure Proje= ct | (lbproject.sf.net). | __________________________ | | Linux-powered Science | __________________________ | | | ------------------------------------------------------- | This sf.net email is sponsored by:ThinkGeek | Welcome to geek heaven. | http://thinkgeek.com/sf | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Rafael L. <lab...@ps...> - 2003-09-25 07:53:57
|
* João Cardoso <jc...@fe...> [2003-09-25 02:28]: > I had already searched netlib and gams, but stoped at (c)lapack; however, > eispack has an almost self-contained svd.f: > http://www.netlib.org/cgi-bin/netlibfiles.pl?filename=/eispack/svd.f > > After converting it to C with the help of f2c, it resulted in a 577 lines file > (the original fortrans code has 358 lines of code). However I get an > undefined symbol when trying to link with a dummy main(): > > jcard@linux:~/Desktop/eispack> gcc test.c svd.o pythag.o -o test -lm > svd.o(.text+0x363): In function `svd_': > : undefined reference to `d_sign' > svd.o(.text+0x784): In function `svd_': > : undefined reference to `d_sign' > svd.o(.text+0x16ae): In function `svd_': > : undefined reference to `d_sign' > collect2: ld returned 1 exit status This works here: $ g77 -c svd.f $ g77 -c pythag.f $ cat > test.c << EOF main () { svd_ (); } EOF $ g77 -o test svd.o pythag.o test.c I would prefer to not use f2c, and rather a straight f77 compiler if possible. Of course, if no f77 is available in the system, then the csa support must be disabled by configure, much like we are already doing with qhull. -- Rafael |
From: <jc...@fe...> - 2003-09-25 13:39:07
|
On Thursday 25 September 2003 08:53, Rafael Laboissiere wrote: | * Jo=E3o Cardoso <jc...@fe...> [2003-09-25 02:28]: | > I had already searched netlib and gams, but stoped at (c)lapack; | > however, eispack has an almost self-contained svd.f: | > http://www.netlib.org/cgi-bin/netlibfiles.pl?filename=3D/eispack/svd. | >f | > | > After converting it to C with the help of f2c, it resulted in a 577 | > lines file (the original fortrans code has 358 lines of code). | > However I get an undefined symbol when trying to link with a dummy | > main(): | > | > jcard@linux:~/Desktop/eispack> gcc test.c svd.o pythag.o -o test | > -lm | > | > svd.o(.text+0x363): In function `svd_': | > : undefined reference to `d_sign' | > | > svd.o(.text+0x784): In function `svd_': | > : undefined reference to `d_sign' | > | > svd.o(.text+0x16ae): In function `svd_': | > : undefined reference to `d_sign' | > | > collect2: ld returned 1 exit status | | This works here: | | $ g77 -c svd.f | $ g77 -c pythag.f | $ cat > test.c << EOF | main () { svd_ (); } | EOF | $ g77 -o test svd.o pythag.o test.c | | I would prefer to not use f2c, and rather a straight f77 compiler if | possible. Of course, if no f77 is available in the system, then the | csa support must be disabled by configure, much like we are already | doing with qhull. The reason why I followed the f2c track is that plplot users interested=20 only in C, or python, tcl, or whatever, but not fortran, don't need to=20 have/install a fortran compiler; instead, we use f2c for them. CVS will have svd.f, but tarballs will have svd.c Why should we have yet another software requirement if it can be=20 avoided? And the world is not only linux, plplot can be compiled with native cc=20 compilers from other unix/OS systems. (diversity is the key to=20 evolution) And g77 is not that old, f2c was the fortran "compiler" of many unix=20 systems that couldn't afford a vendor fortran compiler... I remember=20 compiling all Octave fortran libraries (fftpack, slatec, blas,=20 lapack, odepack, villad, daspk, dasrt, quadpack, dassl, minpack,=20 ranlib) with f2c! (and I'm not that old, too :) But we must run some regression tests on eispack-svd before abandoning=20 lapack. Joao |
From: Arjen M. <arj...@wl...> - 2003-09-25 06:20:33
|
"Alan W. Irwin" wrote: > > > Arjen, both you and Joao have mentioned a fortran compiler so perhaps I am > missing something, but I still don't see why you would need one (except to > compile the fortran interface and examples which is a different issue). It > has been quite a while since I have used cfortran.h (and yes, that is the > header developed by Burkhard Burow recently dual-licensed under the LGPL), > but if I recall correctly, you simply include cfortran.h in your C code, and > no fortran compilation is necessary to access routines in the fortran lapack > library. Note, we don't compile dgesdd and the other lapack and BLAS > routines that it calls, ourselves. lapack (which includes BLAS) is a > completely independent package that is compiled and installed separately and > which is available for all Unix/Linux platforms. We would have to put > -llapack -lblas on the link line for libcsa and do the cfortran.h magic to > make dgesdd accessible to C, but that is it. > In that case, the compile/link step would not need to touch any Fortran sources, so you can do without a Fortran compiler. You do need access during the link step to the Fortran runtime libraries, but I guess this is just a formality (mind you: you can get a few surprises :( ) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2003-09-25 06:35:48
|
Jo=E3o Cardoso wrote: >=20 > On Thursday 25 September 2003 01:45, Alan W. Irwin wrote: > | On 2003-09-25 00:27+0100 Jo=E3o Cardoso wrote: > | > On Wednesday 24 September 2003 20:26, Alan W. Irwin wrote: > | > | You misunderstood what I said. I am not advocating incorporatin= g the > | > | relevant part of lapack source into plplot. As you say, that is= much > | > | too big, and also I would be concerned about supporting it. Ins= tead, > | > | I am advocating simply *linking* to lapack which should be > | > | straightforward with the help of cfortran.h. > | > > | > Yes, that is the fast and simplest solution. But overkill; after a= ll we > | > are replacing a 230 lines function by a whole library! It would be= much > | > better if we could find a single file svd.c. > | > | If you could find ~200-line SVD code written in C >=20 > I was talking about the SVD NR code included in csa.c, it's 232 lines. >=20 > I had already searched netlib and gams, but stoped at (c)lapack; howeve= r, > eispack has an almost self-contained svd.f: > http://www.netlib.org/cgi-bin/netlibfiles.pl?filename=3D/eispack/svd.f >=20 > After converting it to C with the help of f2c, it resulted in a 577 lin= es file > (the original fortrans code has 358 lines of code). However I get an > undefined symbol when trying to link with a dummy main(): >=20 > jcard@linux:~/Desktop/eispack> gcc test.c svd.o pythag.o -o test -lm > svd.o(.text+0x363): In function `svd_': > : undefined reference to `d_sign' > svd.o(.text+0x784): In function `svd_': > : undefined reference to `d_sign' > svd.o(.text+0x16ae): In function `svd_': > : undefined reference to `d_sign' > collect2: ld returned 1 exit status >=20 > Of course using f2c means linking with -lf2c, but perhaps that could be > avoided in our case, as we don't need entry/exit points. Your knowledge= of > fortran can be helpfull -- I don't even know how to call the subrotine = :( > Can you help? >=20 >From the Fortran code I see that dsign() is a function. I do not know what f2c makes out of this, but this is my educated guess: double d_sign( double v, double w ) { if { w >=3D 0.0 } {=20 return abs(v) ;=20 } else { return -abs(v) ; } } (You transfer the sign of w to the first argument) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2003-09-25 08:00:39
|
On 2003-09-25 08:35+0200 Arjen Markus wrote: > >From the Fortran code I see that dsign() is a function. I do not know > what f2c makes out of this, but this is my educated guess: > > double d_sign( double v, double w ) > { > if { w >= 0.0 } { > return abs(v) ; > } else { > return -abs(v) ; > } > } > > (You transfer the sign of w to the first argument) Your educated guess is absolutely correct (see below). Does this mean Joao can avoid using -lf2c, and I can avoid learning about cfortran tomorrow? I didn't quite know what dsign was, but I knew where (info g77) all fortran calls are documented. From info g77, dsign is an archaic form of sign, and here is the documentation for that. Sign Intrinsic .............. Sign(A, B) Sign: `INTEGER' or `REAL' function, the exact type being the result of cross-promoting the types of all the arguments. A: `INTEGER' or `REAL'; scalar; INTENT(IN). B: `INTEGER' or `REAL'; scalar; INTENT(IN). Intrinsic groups: (standard FORTRAN 77). Description: Returns `ABS(A)*S', where S is +1 if `B.GE.0', -1 otherwise. *Note Abs Intrinsic::, for the function that returns the magnitude of a value. So for double precision arguments this is exactly equivalent to Arjen's C-code above. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2003-09-25 08:15:23
|
"Alan W. Irwin" wrote: > > On 2003-09-25 08:35+0200 Arjen Markus wrote: > > > >From the Fortran code I see that dsign() is a function. I do not know > > what f2c makes out of this, but this is my educated guess: > > > > double d_sign( double v, double w ) > > { > > if { w >= 0.0 } { > > return abs(v) ; > > } else { > > return -abs(v) ; > > } > > } > > > > (You transfer the sign of w to the first argument) > > Your educated guess is absolutely correct (see below). Does this mean Joao > can avoid using -lf2c, and I can avoid learning about cfortran tomorrow? > Yes, it does mean that. > I didn't quite know what dsign was, but I knew where (info g77) all fortran > calls are documented. > > >From info g77, dsign is an archaic form of sign, and here is the documentation > for that. > dsign is the specific name for the function sign. Nowadays, people hardly ever use these specific names. Well, I would say: keep cfortran.h in mind for when things get more complicated :) Regards, Arjen |