ComponentArrays.jl
FunctionalCollections.jl
Our great sponsors
ComponentArrays.jl | FunctionalCollections.jl | |
---|---|---|
1 | 1 | |
276 | 121 | |
- | 0.0% | |
7.0 | 0.0 | |
5 days ago | about 1 year ago | |
Julia | Julia | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ComponentArrays.jl
-
Recursion absolutely necessary for distributed computing?
But for these to be as fast as say an Array when being used as the object in a differential equation solve or as the underlying construct of a nonlinear optimization, you would need the compiler to elide the struct construction which it doesn't always do. This is why the tools evolved to be around things like https://github.com/jonniedie/ComponentArrays.jl instead, where it's an Array-backed object with a higher level. Such immutable objects are used in these array-like contexts when the problems are small enough (FieldVectors or SLVector LabelledArrays.jl in DiffEq), and such applications work well in Haskell as well, but I haven't seen a compiler do well with say a 1,000 ODE model written in this style. And it's not quite an extreme case if it's what people are doing daily.
FunctionalCollections.jl
-
Recursion absolutely necessary for distributed computing?
I think that's the issue, but it's more of a context issue. For a lot of the groups using Julia, the cases excluded from this are 99% of what people are doing daily for scientific computing. For reference for those who don't know, a nice Julia library for these kinds of tools is https://github.com/JuliaCollections/FunctionalCollections.jl, and it is used in places where functional styles and pure functions are more widely used like in the symbolic computing libraries.
What are some alternatives?
DiffEqBase.jl - The lightweight Base library for shared types and functionality for defining differential equation and scientific machine learning (SciML) problems
julia - The Julia Programming Language
JuMP.jl - Modeling language for Mathematical Optimization (linear, mixed-integer, conic, semidefinite, nonlinear)
RayTracer.jl - Differentiable RayTracing in Julia
ModelingToolkit.jl - An acausal modeling framework for automatically parallelized scientific machine learning (SciML) in Julia. A computer algebra system for integrated symbolics for physics-informed machine learning and automated transformations of differential equations
ControlSystems.jl - A Control Systems Toolbox for Julia
DSGE.jl - Solve and estimate Dynamic Stochastic General Equilibrium models (including the New York Fed DSGE)
GeoStats.jl - An extensible framework for geospatial data science and geostatistical modeling fully written in Julia
ScottishTaxBenefitModel.jl - A tax-benefit model for Scotland
DiscretePIDs.jl - Discrete-time PID controllers in Julia
DifferentialEquations.jl - Multi-language suite for high-performance solvers of differential equations and scientific machine learning (SciML) components. Ordinary differential equations (ODEs), stochastic differential equations (SDEs), delay differential equations (DDEs), differential-algebraic equations (DAEs), and more in Julia.