|
> Local parameters seem wonderful until you find that you must refer to them
> from outside their scope. Optimization is a case in point.
>
> Optimization requires a vector of unique parameter names/ids, and so to
> fit
> an entire model to data requires that global parameters be passed to the
> optimizer. I have to agree that it's very convenient to be able to use Km
> again and again locally, but as soon as you begin a parameter optimization
> procedure I believe you are going to have to give your parameters global
> names, or at least global ids, anyway. So, like Herbert, I have a strong
> preference for global parameters.
> Furthermore, any attempt to legislate one or the other out of existence is
> doomed to fail on logical grounds. No software tool can afford to treat
> the
> global/local distinction lightly because there are important use cases
> where
> global parameters become local and others where local parameters become
> global.
Your comments are absolutely right of course. But again, they are
tool-related problem. Over the last year or so, it seems that one tends to
forget that SBML is meant to exchange models between tools, not to be a
sort of configuration files for simulators. So for instance, a tool can
always read an SBML files with local parameters and rewrite them as global
parameters (and play with that, like merging param with same value etc.)
--
Nicolas LE NOVÈRE, Computational Neurobiology,
EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Tel: +44(0)1223 494 521, Fax: +44(0)1223 494 468, Mob: +33(0)689218676
http://www.ebi.ac.uk/~lenov
|