Comments (4)
I agree that Direct
and DirectMA
should be merged. However, I have to own up to not fully understanding the distinction between constant and mass action jumps. The only reason for keeping things separate would be performance. Is this correct? If so, I think this boils down to whether there is a performance penalty for adding a new field to DirectJumpAggregation
. The only place I see this cropping up is in building the JumpAggregation
but that should be negligible.
It should be possible to get the function wrappers working by adding the aggregate
method in your gist to DirectJumpAggregation
that specializes on a new aggregator algorithm. The Direct
aggregator algorithm ought to be renamed, and the new aggregate
method will specialize on the DirectFunWrappers
type. All that is left is replacing the helper function for the next reaction with your implementation.
This brings up the issue of how to name these aggregator algorithms, so that a user can appreciate the difference solve(jump_prob, DirectTuples())
and solve(jump_prob, DirectFunWrappers())
.
In this way, slight variations on the basic Gillespie algorithm (e.g. FunctionWrappers, sparse/dense stoichiometric matrix representations...) can be implemented by providing (1) a new type that implements AbstractAggregatorAlgorithm
in aggregators.jl
and (2) a new aggregate
method that feeds in the correct types into a type constructor.
from jumpprocesses.jl.
The only reason for keeping things separate would be performance. Is this correct?
Yes that is correct. But it is a huge difference. For example, consider a system with 16 different A->B reactions (each having a different rate and ungrouped). Running the reaction 8000 times gives:
Direct method with tuples:
10.359 s (45989311 allocations: 1.03 GiB)
Direct method with function wrappers
2.928 s (29098591 allocations: 451.39 MiB)
Direct method with mass action rate function
146.208 ms (174991 allocations: 10.06 MiB)
As the number of reactions increases the function wrapper version gets much faster than tuples, but is still always much slower than the mass action jump version.
It should be possible to get the function wrappers working by adding the aggregate method in your gist to DirectJumpAggregation that specializes on a new aggregator algorithm.
That's what I did in the PR. Thanks for the suggestion!
This brings up the issue of how to name these aggregator algorithms
I used DirectManyJumps
. If you have a better suggestion I'm happy to change it... I admit it's not great.
from jumpprocesses.jl.
If so, I think this boils down to whether there is a performance penalty for adding a new field to DirectJumpAggregation. The only place I see this cropping up is in building the JumpAggregation but that should be negligible.
Yeah, it would be negligible.
from jumpprocesses.jl.
Closed by 22
from jumpprocesses.jl.
Related Issues (20)
- Remarks about docs [JuliaCon Proceedings review] HOT 4
- Remarks about paper [JuliaCon Proceedings review] HOT 1
- Remarks about package [JuliaCon Proceedings review] HOT 7
- Dynamical ODE and SDE solvers fail when they are combined with VariableRateJump. HOT 1
- Method ambiguities reported by Aqua HOT 2
- mutating parameter vector needs to call reset_aggregated_jumps! HOT 7
- Reenable formatter once SciMLStyle is fixed.
- Certain Continuous Callbacks does not work for JumpProcessess HOT 14
- Remarks about paper - episode 2 [JuliaCon Proceedings review] HOT 5
- Add / use cache-optimized indexed priority queue in NRM-based methods. HOT 1
- figure out why CI is now taking a ridiculous amount of time HOT 2
- Uniformization Direct Methods
- network free solvers
- Better documentation of `remake` mutating original problems
- Discrete events with repeated dosage fails for JumpSystems (fine ofr e.g. ODEs) HOT 7
- Automatic selection of solver method (e.g. `SSAStepper()`) HOT 2
- (Hierarchical) Exact Accelerated SSA HOT 1
- Seeding ensemble problems HOT 8
- `FunctionMap` not defined HOT 7
- add option to convert MassActionJumps to ConstantRateJumps HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jumpprocesses.jl.