http://bowmore.elyt.com/bugzilla/show_bug.cgi?id=70
--- Comment #2 from Andrew Miller <[EMAIL PROTECTED]> 2007-07-21 17:45:44 --- (In reply to comment #1) > Convolution with a shifted dirac delta is really just another way of saying > y(t-k), since that is essentially one approach to defining the dirac delta > generalised function. Also, convolution would require us to specify the > function arguments anyway. So I think convolution is not the approach we > should take. > > Changing the specification so that y becomes y(t) (i.e. a function) seems the > cleanest approach to me. > I don't see the benefits of the convolution approach either. It perhaps mathematically cleaner but there are other considerations which might affect this: 1) Consistency with existing CellML specifications - how much do we want to change the specification to support this? 2) Space requirements of the representation - will this be a major show-stopper if every variable suddenly becomes <apply><ci>y</ci><ci>t</ci></apply> instead of just <ci>y</ci>? 3) Consequences for software implementations - does this provide enough data for a simulator to use - how do we define boundary conditions, and what sorts of simulation metadata do we need to make such simulations work? How will they interact with the new representation? One option might be to introduce some sort of semantics where sometimes <ci>y</ci> is a variable meaning y, and other times it is a function, but this might cause headaches and ambiguity if we ever introduce functions as a type in CellML (although we could add attributes to the 'variables' describing their type it might be unambiguous). Also, would a variable still be called a variable in the component if it is actually a function, or do you propose that we have more than one type of element? -- Configure bugmail: http://bowmore.elyt.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the tracker item. _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
