Forums

I did misread for earlier post. I presume you don't read the mathematica back to SBML once you generated the mathematica code, because of this you won't get the issue I have.

The particular problem I have is I believe solvable by moving to global variables, so I'm ok about it. Don't know though about Nicolas' issues however.

H

-----Original Message-----
From: Bruce E Shapiro, PhD [mailto:bshapiro@caltech.edu]
Sent: Thursday, July 28, 2005 9:47 PM
To: SBML Discussion List
Subject: Re: [sbml-discuss] Global vs. local parameters

You misunderstand me or perhaps I misspoke.

I gave an example with globals.

MathSBML has local parameters implemented as well as global. It was not difficult to do.

This is why I am confused.

Bruce

On Jul 28, 2005, at 10:10 PM, Herbert Sauro wrote:

>
> Bruce, you admitted yourself that you use only global variables, but
> this thread is about local scope which you've not implemented, modify
> MathSBML to use local parameters and see how you get on.
>
> Hrebert
>
> -----Original Message-----
> From: Nicolas Le Novere [mailto:lenov@ebi.ac.uk]
> Sent: Thursday, July 28, 2005 12:31 AM
> To: SBML Discussion List
> Subject: Re: [sbml-discuss] Global vs. local parameters
>
> On Wed, 27 Jul 2005, Bruce E Shapiro, PhD wrote:
>
>
>> What I still don't get is why its such a problem to keep variables in
>> different scopes. Are we trying to fix SBML for developers who
>> **assumed** incorrectly that #3 was true before they wrote their
>> code? Or is there truly either a conceptual or programming
>> difficulty here?
>>
>
> One of the basic problem is that you have one namespace for:
>
> compartments
> species
> global parameter
>
> So there cannot be clashes between ids of such elements. Then you
> have local parameters, each reaction having its own namespace.
> Because of that, such local parameters can not only overide global
> parameters, but also compartments and species. In addition, because
> global and local are all "<parameter>", their automatic treatment
> is very complicated. You have to invent all kinds of treatments to
> get the right value in the kinetic laws.
>
> This is significant programming work. And this work is done and
> redone byt all the soft developpers. Later, you give an actual
> example of overiding. And I'm sure there are some others. However,
> I may be wrong, but I in all the models we curated for BioModels
> Database (around 50 so far), I don't think we encountered the case
> even once. I just honestly don't think it's worth it. And I don't
> think the backward compatibility would be a huge problem. We could
> provide a tool (e.g. an XSL) to convert the problematic models.
>
>
>> I believe we should think really hard before making changes that
>> [...]
>> violate the spirit of modular programming.
>>
>
> But the *current* situation violate that very much. Hou would you
> consider Perl if a local scalar could overide a global scalar, or a
> global array, or a global hash table? Beside, I'd like SBML to go
> even further down the modular route in the future, with reactions
> as real classes, that could be stored in an individual module. And
> I think the proposed move actually paves the way.
>
>
>> I can think of one example why I would be opposed to the adoption of
>> (3). Suppose I have a large model with several thousand cells that
>> have basically the same set of reactions in each cell as well as some
>> transport reactions. For a particular reaction I'd like to have the
>> same rate constant k for every occurrence of reaction r *except* in a
>> few cells, where I overwrite the value. I'd rather not write the
>> value
>> out several thousand times, just the one global time and in the few
>> reactions where it needs to be changed.
>>
>
> This is the kind of speech I did years ago. You're missing the
> point. SBML is not a configuration format for your simulator. There
> is no reason for it to be parcimonious. Your soft can write k a
> thousand times without any problem. And you can still change only
> the one you want. Besides, the right way to deal with your problem
> is probably to have two SBML files, defining your two cells, and
> within your software to have arrays of cells defined by one or the
> other (<heresy>you could consider NeuroML for such kind of problem</
> heresy>).
>
>
>> Admittedly, there is an easy workaround - just write out the
>> parameter
>> in every reaction
>>
>
> yes.
>
>
>> -- but my point is that we need to think hard about whether there
>> are
>> situations where global variables should have the same name as
>> locals.
>>
>
> Each time I found one, it is merely a human issue, not a computing
> one.
>
> <disclaimer>I am *not* saying we have to get rid of the global
> parameters.</disclaimer>
>
> --
> 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 AIM screen name:
> nlenovere
>
>
>