gsl-0.9 and SunProCC 5.0 - compile problems

gsl-0.9 and SunProCC 5.0 - compile problems

[Eric Rose]

Has anyone reported any problems compiling GSL with the
native Sun compiler? (SunPro CC/cc 5.0)

  Configure with CC=cc and CFLAGS=-fast     (Sun's version of -O2)

I get a problem with the 'templates' :-)

Looks like the SunCC has problems assigning the struct that is
the _internal_representation

/bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -I..
-I..    -fast -c reim.c
rm -f .libs/reim.lo
cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -fast -c reim.c  -KPIC -DPIC
-o reim.o
"./reim_source.c", line 35: left operand must be modifiable lvalue: op
"="
"./reim_source.c", line 53: left operand must be modifiable lvalue: op
"="
"./reim_source.c", line 35: left operand must be modifiable lvalue: op
"="
"./reim_source.c", line 53: left operand must be modifiable lvalue: op
"="
"./reim_source.c", line 35: left operand must be modifiable lvalue: op
"="
"./reim_source.c", line 53: left operand must be modifiable lvalue: op
"="
cc: acomp failed for reim.c
make: *** [reim.lo] Error 1


-- 
===================================================================
Eric Rose                        Software Engineer / Project Leader
E-mail eric.rose@stratec.com       ==> http://www.medivision.ch <==
Secr.  +41-31-632-8792                 Medivision / STRATEC Medical
Mobile +41-79-649-1309                Eimattstr. 3, 4436 - Oberdorf
FAX    +41-31-398-3071                                  Switzerland
===================================================================

Re: gsl-0.9 and SunProCC 5.0 - compile problems

[Brian Gough]

Eric Rose writes:
 > "="
 > "./reim_source.c", line 53: left operand must be modifiable lvalue: op
 > "="
 > cc: acomp failed for reim.c
 > make: *** [reim.lo] Error 1

I've checked in a new version based on the cast you suggested if you
want to try it out. Thanks.

GSL-0.9 -> Standard interface to functions/pakages

[Nicolai Hanssing]

Hi List,

After working with gsl_min,gsl_multifit etc., I find the lack of standard
interface as a great weakness when using gsl.

First of, it should be suffcient for the solvers, and minimizers with one
interface to usersupplied functions and derivatives:

f(R^1) -> R^1
f(R^1) -> R^m
f(R^n) -> R^1
f(R^n) -> R^m

Which can all be handled by an interface as:

gsl_(???)_function_f: 
int (* f) (const gsl_vector * X, void * PARAMS, gsl_vector* F)
gsl_(???)_function_df:
int (* df) (const gsl_vector * X, void * PARAMS, gsl_matrix * J)
gsl_(???)_function_fdf:
int (* fdf) (const gsl_vector * X, void * PARAMS, gsl_vector * F,gsl_matrix * J)

Currently each optimizing-pakage has it own similar definition, when the
interface above clearly should be sufficient.

-------

Next up, using the above definition GSL should be able to provide the
users with a simplified interface to both solvers, minimizers and
maximizers. I.e. use of the interface should only be 3-4 steps:

1. Initialise (alloc) pakage, using usersupplied values or default.
2. Do optimization.
(3.) User-controlled iteration.
4. Terminate (free) pakage.

Most of the pakage would ofcourse just be a wrapper for the existing
solvers in GSL.

My point is that little enhancements, and the ability to try functions
implemented in gsl, without the need of a big program to setup *all*
options, and allocations would greatly improve upon
development-time, allthough the pakage might give a performancehit. It can
be seen as a higherlevel interface to lowerlevel functions. If users want
more direct control, they can offcourse use the lower-level pakages
directly.

Actually something as simple as a usefull numberingscheme for the number 
of independent variables in a function and number of returned values would
be of great use (n,p are currently used inconsistently):

nx = dimension of x - now n, p, m.
nf = dimension of function returnvalue, now normally p.

What the pakage should be called I don't know - gsl_optim might be a
little too close to Matlab ;o)

I wouldn't mind doing the framework, when I've finished the "direct
search, SIMPLEX", currently underway.

Re: GSL-0.9 -> Standard interface to functions/pakages

[Brian Gough]

Nicolai Hanssing writes:
 > of independent variables in a function and number of returned values would
 > be of great use (n,p are currently used inconsistently):

Can you show me where.. if so I will correct it. 

Re: GSL-0.9 -> Standard interface to functions/pakages

[Brian Gough]

Nicolai Hanssing writes:
 > First of, it should be suffcient for the solvers, and minimizers with one
 > interface to usersupplied functions and derivatives:
 > .....
 > gsl_(???)_function_f: 
 > int (* f) (const gsl_vector * X, void * PARAMS, gsl_vector* F)
 > gsl_(???)_function_df:
 > int (* df) (const gsl_vector * X, void * PARAMS, gsl_matrix * J)
 > gsl_(???)_function_fdf:
 > int (* fdf) (const gsl_vector * X, void * PARAMS, gsl_vector * F,gsl_matrix * J)
 > 
 > Currently each optimizing-pakage has it own similar definition, when the
 > interface above clearly should be sufficient.
 >
 > Next up, using the above definition GSL should be able to provide the
 > users with a simplified interface to both solvers, minimizers and
 > maximizers. I.e. use of the interface should only be 3-4 steps:
 >
 > My point is that little enhancements, and the ability to try functions
 > implemented in gsl, without the need of a big program to setup *all*
 > options, and allocations would greatly improve upon
 > development-time, allthough the pakage might give a performancehit. It can
 > be seen as a higherlevel interface to lowerlevel functions. If users want
 > more direct control, they can offcourse use the lower-level pakages
 > directly.

The library is oriented towards interfacing to scripting languages, so
the routines are low-level and broken down into fundamental
components.  The structs for gsl_multifit_.., gsl_multiroots_.., etc
should be regarded as part of the interface, as a way to pass in a
collection of arguments, rather than a mathematical object. The
functions correspond to a library, rather than an 'environment'. So
from this point of view its natural that the multiroots, multifit and
multimin modules use different structs.  If you'd like to make a
separate higher-level interface for C/C++ programming feel free to do
that.