Hi Andrew, I think the advantages offered by this transition outweigh the lack of backwards compatibility and have no objections to your proposal, just a few clarifications below...
> I am planning on completely updating the CCGS to make use of CeVAS, > MaLaES, and CUSES. Due to the large scale of the changes, I am taking > this opportunity to fix some design issues which currently limit what > CCGS can do. This inevitably means breaking the existing interface, and > any code that uses it (I could have tried to make the interfaces look > the same, but the code generated would still be different, due to the > changes discussed below). > > Major changes proposed: > * The concept of variables and rates in CCGS is being replaced by a > concept of a computation target. A computation target is anything which > can be computed by CCGS, and includes variables and rates (possibly > multiple times). I'm not sure I follow how variable's are linked to a ComputationTarget. You say that a given variable may be associated with multiple computable's - does this mean there are possibly multiple methods to compute the same variable or will all the ComputationTarget's for a given variable resolve to the same computational steps? > * There will no longer be separate blocks of code which explicitly > compute rates and blocks which explicitly compute variables. Instead, > computation targets are computed, and as a side effect of this, any > other algebraic or rate variable may be computed as a pre-requisite. One > positive result of this is that it will be possible to use derivatives > like any other variable, so the same derivative can appear more than > once, and derivatives can even be solved by Newton-Raphson steps if > required. It means that it is possible to efficient code which evolves > the model without computing unnecessary variables until they are needed > for presentation purposes. This completely changes the structure of the > strings produced, causing backward-incompatibility. Could you clarify what you mean by "presentation purposes"? > * The idea that a rate is a constant is contemplated, allowing for more > efficient computation. Is this looking at the math defining a rate and checking if it would remain constant after all the other math has been processed? Thanks, Andre. _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
