Comments (16)
Interesting. Yes, that's a good way to solve it. We might want to have as_array
make use of BlockBandedMatrices.jl here.
https://github.com/JuliaMatrices/BlockBandedMatrices.jl
That will make the as_array
kick out a pretty efficient result type when necessary. I think another thing @jlperla is interested in is multidimensional operators. To build the linear operator on vec(u)
in 2D space we need to utilize the Kronecker product. With the as_array
setup a user can just as_array
L1
and L2
and do the product there, but it may be useful to see if we can have a lazy Kronecker?
from diffeqoperators.jl.
From Slack
- In almost all cases for matrix multiplication we want it contiguous, so caches as
Vector
will do well for a very long time (but yes, having a choice is always nice) - The split... I would like to be able to write code which is able to use operators without requiring all of the operator instances of DiffEqOperators.jl. I did that incorrectly in the first attempt though. But I think that if
AbstractDiffEqOperator
is in DiffEqBase with the definition ofas_array
that might be all that's needed? - I like that choice for how to handle the scalars.
- axpy! is probably better and should have generic fallbacks
- Is it necessary to have affine be a different operator? Or could the normal one just have a spot for the affine term and then have an
is_linear(A)
which just uses the type parameter? - For
*
I wouldn't use anyA_mul_B!
. That lack of mutation would be useful for static arrays. - That operator composition is sick!
Let's go forward with this.
from diffeqoperators.jl.
Moved the notebook from my personal repo to my DiffEqOperators.jl fork.
Added another type of operator composition: block concatenation (see this section and simple test. The need for block concatenations arise for problems such as #59, as well as systems of PDEs (e.g. multivariate diffusion equations that @jlperla and I have been working on). Typically the combined operator can be expressed as a block diagonal matrix, which I have implemented in the notebook. General block concatenations using the [A B; C D]
notation (i.e. hvcat
) can also be written in a similar fashion, though probably a bit complicated.
from diffeqoperators.jl.
A lazy kronecker is a good idea. A frequent case would be to have the drift a function of the underlying state, but then the brownian term have the same variance. In that case, a lazy kronecker would be a nice way to compose the variance term.
from diffeqoperators.jl.
Actually, wouldn't a lazy kronecker just be implemented by one of these block concentrations? That means it can be done via a new binary op ⊗
(\otimes
) that does this?
from diffeqoperators.jl.
Going through old issues and found this: #43 Implement collect.
Seems the collect
referenced there is basically my as_array
. However is this the intended behavior of collect
in base Julia? From the latest documentation it seems collect
always return a full Array
:
https://docs.julialang.org/en/latest/base/collections/#Base.collect-Tuple{Any}
Not sure if the behavior is changed in v0.7 and documentation hasn't followed up. In v0.6.2 collect
does behave like full
:
>>> collect(speye(10))
10×10 Array{Float64,2}:
1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0
from diffeqoperators.jl.
collect
and full
are very similar, in fact I think full
may be deprecated in v0.7. Its definition is it collects over the iterator, so it would produce something dense. @dlfivefifty has been working on a more refined idea of specialized array types JuliaLang/julia#25558 I'm not sure if that PR introduces something like as_array
for how it has to handle views.
from diffeqoperators.jl.
@ChrisRackauckas Not sure you wanted me to pipe in, but I'm not sure what as_array
is from this conversation.
from diffeqoperators.jl.
as_array
is a method that creates the "best" structured array from the lazy operator. So if it knows it's banded then it returns a BandedMatrix
, but if it doesn't have good structure but is sparse it returns SprarseMatrixCSC
. Does such a function exist?
from diffeqoperators.jl.
Updates about lazy Kronecker products and sums here and test here.
I only wrote the two dimension case. It's possible to do an N-dimension case (it should look a lot like DiffEqCompositeOperator
) but the multi-indexing part is a bit messy (for example, how can I express something like "loop over the multidimensional array and multiply L
with each 1D slice in the j
th dimension"?)
Relevant discussion: #21 Taking operators on dimensional models seriously.
Still not sure if this is the right approach though. Also would the concept of tensor/Kronecker products be a bit hard to grasp for regular users?
from diffeqoperators.jl.
Well the tensor/Kronecker products are how they'd be implemented, but we can probably find a better higher level interface to expose to users.
from diffeqoperators.jl.
For sure. I think the syntactic sugar here is very important to get right (or at least have a plan). But if you can write the math as a cartesian product of the domains, then the kronecker symbol may be defensible.
@MSeeker1340 I am hoping that this library is the mindblowing combination of blackboard-math and generic but efficient code that we can use to show people the power of Julia, so I don't mind taking the time necessary to ensure the right high-level interface is possible. How much of that is in the https://github.com/JuliaDiffEq/ModelingToolkit.jl vs. this library, I am not entirely sure.
Chris, since many of the discrete state in economics would be named discrete states in a markov chain, it might be worth thinking about how this might interact with the definition of finite domains.
from diffeqoperators.jl.
I'm not sure if that PR introduces something like as_array for how it has to handle views
No, that's just for dispatch of mul!
. But it would be useful for overriding mul!
for lazy arrays. (Without that PR requires many, many ambiguity cases to override mul!
.)
What about overriding AbstractSparseMatrix(A)
to construct the "best" sparse matrix?
from diffeqoperators.jl.
Seems odd to me to give an abstract type a fake "constructor". Is that done anywhere else?
from diffeqoperators.jl.
How is it fake? Yes it's standard practice:
julia> Integer(3.0)
3
from diffeqoperators.jl.
How is it fake?
Well you cannot construct an abstract type, so in some sense it's not really a constructor. But okay, I didn't know that it's a standard thing (I never knew you could use Integer
as a function). AbstractSparseMatrix
makes sense then.
from diffeqoperators.jl.
Related Issues (20)
- Performance issues with nonlinear_diffusion! HOT 4
- Fix symbolic arrays test to allow MTK v5.21.0 HOT 7
- UndefVarError: dereference not defined when precompiling DiffEqOperators (Win10, julia 1.6.1-2) HOT 7
- Version Compatibility? HOT 1
- Error defining second-order differential HOT 8
- The latest versions of LoopVectorization (0.12.80-81) are not compatible and cause errors HOT 1
- Noob Help: Simple, Linear, Inhomogenous PDE HOT 3
- concretization of High Dimension PDE HOT 2
- LoopVectorization break HOT 5
- Unexpected concretization of Laplace operator HOT 3
- v4.35.0 failed to release HOT 2
- Feature request: Support Summation-By-Parts operators HOT 4
- Support Unitful HOT 6
- Incorrect boundary padded vector with composed PeriodicBC on 2d data HOT 6
- Implementing Drift-Diffusion model in higher dimensions HOT 3
- Uninitialized field `opnorm` in JacVecOperator HOT 4
- SplitODEProblem broken for MatrixFreeOperator HOT 3
- ERROR: LoadError: Some tests did not pass: 30 passed, 0 failed, 4 errored, 4 broken. HOT 18
- Warning related to "LoopVectorization.check_args"
- Lots of precompilation errors and noise HOT 7
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 diffeqoperators.jl.