* Re: GSL-0.9 -> Standard interface to functions/pakages
2001-12-19 13:20 ` GSL-0.9 -> Standard interface to functions/pakages Nicolai Hanssing
2001-12-19 13:20 ` Brian Gough
@ 2001-12-19 13:20 ` Brian Gough
1 sibling, 0 replies; 5+ messages in thread
From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw)
To: Nicolai Hanssing; +Cc: gsl-discuss
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* GSL-0.9 -> Standard interface to functions/pakages
2001-12-19 13:20 gsl-0.9 and SunProCC 5.0 - compile problems Eric Rose
2001-12-19 13:20 ` Brian Gough
@ 2001-12-19 13:20 ` Nicolai Hanssing
2001-12-19 13:20 ` Brian Gough
2001-12-19 13:20 ` Brian Gough
1 sibling, 2 replies; 5+ messages in thread
From: Nicolai Hanssing @ 2001-12-19 13:20 UTC (permalink / raw)
To: egcs; +Cc: gsl-discuss
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* gsl-0.9 and SunProCC 5.0 - compile problems
@ 2001-12-19 13:20 Eric Rose
2001-12-19 13:20 ` Brian Gough
2001-12-19 13:20 ` GSL-0.9 -> Standard interface to functions/pakages Nicolai Hanssing
0 siblings, 2 replies; 5+ messages in thread
From: Eric Rose @ 2001-12-19 13:20 UTC (permalink / raw)
To: gsl-discuss
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
===================================================================
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gsl-0.9 and SunProCC 5.0 - compile problems
2001-12-19 13:20 gsl-0.9 and SunProCC 5.0 - compile problems Eric Rose
@ 2001-12-19 13:20 ` Brian Gough
2001-12-19 13:20 ` GSL-0.9 -> Standard interface to functions/pakages Nicolai Hanssing
1 sibling, 0 replies; 5+ messages in thread
From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw)
To: Eric Rose; +Cc: gsl-discuss
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GSL-0.9 -> Standard interface to functions/pakages
2001-12-19 13:20 ` GSL-0.9 -> Standard interface to functions/pakages Nicolai Hanssing
@ 2001-12-19 13:20 ` Brian Gough
2001-12-19 13:20 ` Brian Gough
1 sibling, 0 replies; 5+ messages in thread
From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw)
To: Nicolai Hanssing; +Cc: gsl-discuss
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-12-19 13:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-12-19 13:20 gsl-0.9 and SunProCC 5.0 - compile problems Eric Rose
2001-12-19 13:20 ` Brian Gough
2001-12-19 13:20 ` GSL-0.9 -> Standard interface to functions/pakages Nicolai Hanssing
2001-12-19 13:20 ` Brian Gough
2001-12-19 13: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).