Support for `derivative(FastDifferenation.Node)`

[ejmeitz]

Would it be possible to add an overload for derivative(FastDifferneiation.Node,...) so you don't need to make your input an array?

[brianguenter]

made the change. As soon as CI finishes on github I'll release a new patch version.

[brianguenter]

just pushed to the Julia registry. should be live in 15-20 minutes.

[brianguenter]

closing this issue now.

[ejmeitz]

Thanks!

[ejmeitz]

I don't think this patch worked btw, I still get: BoundsError: attempt to access 1-element Vector{FastDifferentiation.PathEdge{Int64}} at index [0] if I don't put the input in [].

EDIT: Sorry, this might be something else, I am having random issues that seem stochastic. I'm running the same code but get different errors and sometimes no errors. This was just one of those. Maybe I'll open a new issue but I'm not really sure how to diagnose the issue since its a new error each time. I'm calling derivate inside of a Threads.@threads on the same symbolic object is that not safe?

Here's the top of the stack trace:

Stacktrace: [1] _deleteend! @ .\array.jl:1023 [inlined] [2] empty! @ .\array.jl:1773 [inlined] [3] get_edge_vector() @ FastDifferentiation C:\Users\ejmei.julia\packages\FastDifferentiation\mftkg\src\Factoring.jl:269 [4] old_edge_path(next_node_constraint::FastDifferentiation.PathConstraint{Int64}, dominating::Int64, is_dominator::Bool, reachable_mask::BitVector, current_edge::FastDifferentiation.PathEdge{Int64, 9, 1}) @ FastDifferentiation C:\Users\ejmei.julia\packages\FastDifferentiation\mftkg\src\Factoring.jl:299 [5] evaluate_subgraph(subgraph::FastDifferentiation.FactorableSubgraph{Int64, FastDifferentiation.DominatorSubgraph})

[brianguenter]

The differentiation code is not thread safe. I believe this is mentioned in the docs. Maybe I should make it more prominent.

There is a global cache to track expressions. The cache is a non thread safe Dict.

You could add a feature request issue if this is really important but there are several other bug fixes/features that would need to be done ahead of this so it will be a while.

As a workaround you could try using processes instead of threads. I think the package that supports this is Distributed.jl.

Each process will get its own expression cache so you won't get races. But if you have identical expressions in different processes they will be computed separately and won't have the same hash.

You might get some redundancy in expression computation if you spread expression creation across processes and then combine them.

For example, if you generated two identical expressions in two processes and then put them together into a larger expression the system will treat the two expressions as two different things. The generated code would evaluate each expression independently, doubling execution time.

On Sun, Jan 14, 2024, 6:42 AM Ethan Meitz @.***> wrote:

I don't think this patch worked btw, I still get: BoundsError: attempt to access 1-element Vector{FastDifferentiation.PathEdge{Int64}} at index [0] if I don't put the input in [].

Here's the top of the stack trace:

Stacktrace: [1] _deleteend! @ .\array.jl:1023 [inlined] [2] empty! @ .\array.jl:1773 [inlined] [3] get_edge_vector() @ FastDifferentiation C:\Users\ejmei.julia\packages\FastDifferentiation\mftkg\src\Factoring.jl:269 [4] old_edge_path(next_node_constraint::FastDifferentiation.PathConstraint{Int64}, dominating::Int64, is_dominator::Bool, reachable_mask::BitVector, current_edge::FastDifferentiation.PathEdge{Int64, 9, 1}) @ FastDifferentiation C:\Users\ejmei.julia\packages\FastDifferentiation\mftkg\src\Factoring.jl:299 [5] evaluate_subgraph(subgraph::FastDifferentiation.FactorableSubgraph{Int64, FastDifferentiation.DominatorSubgraph})

— Reply to this email directly, view it on GitHub https://github.com/brianguenter/FastDifferentiation.jl/issues/56#issuecomment-1891001116, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3WWRBN4H76SDQIB4SASP7TYOQDIJAVCNFSM6AAAAABAAJH6PGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJRGAYDCMJRGY . You are receiving this because you modified the open/close state.Message ID: @.***>

[ejmeitz]

Ah that makes sense, thanks! This makes me want to figure out a way to save the functions even more now.