Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why is ndeps forced to be static? #42

Open
konstantin-azarov opened this issue Nov 29, 2023 · 3 comments
Open

Why is ndeps forced to be static? #42

konstantin-azarov opened this issue Nov 29, 2023 · 3 comments

Comments

@konstantin-azarov
Copy link

addcost! forces ndeps to return a static value. However I don't see why this is. It doesn't look like the fact that it is static is used anywhere. costdeps(https://github.com/ojwoodford/NLLSsolver.jl/blame/4a372d66dfa021544e9a0b441e19b9c9669c4422/src/problem.jl#L192) seems to allow dynamic values.

@ojwoodford
Copy link
Owner

Mainly because the solver doesn't currently support the ability to change the number of dependent blocks during an optimization. costdeps does support dynamic values, but the there isn't currently a mechanism to update the block structure of the hessian during optimization.

But you're right. Nothing actually depends on the output of ndeps being static. Why do you ask about this? Are you looking to have a variable number of dependent blocks? If so, please could you outline the optimization problem? I might then consider adding support.

@konstantin-azarov
Copy link
Author

Just to clarify, I'm not talking about changing the number of dependencies during runtime. My concern is that interaction between addcost! and costdeps currently requires that all cost block of a given type have the same number of dependencies.

For example for an SfM problem one may want to have a FeatureCost cost block type. Since different features are observed from several poses it may be necessary that each instance of FeatureCost have different number of dependencies, and it is impossible currently.

@ojwoodford
Copy link
Owner

I see. Makes sense. Have you tried just removing the check? It should still work, but I think performance would go down for residuals where the value isn't static; I would expect some type instability and allocations. I would consider accepting a PR if you test it out on your application and find it useful.

With the SfM application you mention, is there a reason you can't use a separate residual block per image? Are the residuals interdependent?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants