Introduce types, e.g. DivDiffData, to get around complicated broadcast machinery #142
Introduce types, e.g. DivDiffData, to get around complicated broadcast machinery #142DanielVandH wants to merge 3 commits intomasterfrom
DivDiffData, to get around complicated broadcast machinery #142Conversation
|
What's the difference between a We definitely do not want to cache every single operation |
|
I think the issue was with type inference for nested BroadcastVectors (or maybe just for caches of them) gives an eltype of Union{}. Maybe if instead of using a cache for all the individual broadcasts I just build up all the BroadcastVectors and cache those |
|
No the issue has nothing to do with type inference. It' that if you broadcast cached vectors then call to The proposal was to do a single type to wrap and cache the entire vector, not to introduce more generic lazy arrays that are composed. |
|
I think this is closer to what you want? I still need to figure out why e.g. (taken directly from the tests) t = 2
P = SemiclassicalJacobi(t, -0.5, -0.5, -0.5)
Q = SemiclassicalJacobi(t, 0.5, 0.5, 0.5, P)
x = axes(P,1)
D = Derivative(x)
D = Q \ (D*P)tries to indefinitely resize the cache though. |
CachedBroadcastVector to get around broadcast machineryDivDiffData, to get around complicated broadcast machinery
@dlfivefifty Is this roughly what you had in mind for trying to get around some of the broadcast machinery? I'm simply caching the broadcast results in a
CachedBroadcastVectorwithcache_filldata!implemented asIt's currently only implemented in
divdiffto get an idea of what it looks like:which is a bit annoying as it requires a bunch of individual
CBVcalls. I did initially start with aCachedFusedBroadcastVectorbut it's somewhat unreadable as I need to manually build theTupleof functions and vectors. I also tried specific structs for each type of operation, e.g.RangeTimesAccumulate, but getting this type of struct correct seems nicer.There's an issue with this implementation though that I'm not sure I understand. It keeps trying to indefinitely resize the vector in some cases. For example, putting a
@show inds, K.datasizeinsideLazyArrays.cache_filldata!(K::CachedBroadcastVector{T, F, A, B}, inds) where {T, F, A, B}and differentiating a weighted basis,Any idea what's going on with this implementation that it keeps wanting to resize? I thought
_vec_resizedata!(B::AbstractVector, n)should get around this automatically. Note that the indexing does work sometimes though, e.g.works and uses
CachedBroadcastVector.