Hi all,
well, the only sure thing seems to be that my idea won't work :)
I agree with Peter, there's classes such as Settings that can't be duplicated in two namespaces. Oh well.
As someone said already, I guess that for now you both might go ahead and see where you get. I can put your work in two branches on my repo if you think that people might feel more encouraged to try it out.
(Also, I think that getting people to try out your code is the priority right now. I need feedback because I'm kind of between a rock and a hard place here, not wanting to hinder your progress but also having to check that nothing breaks, and that the barrier to adoption doesn't get too high---for instance, I like Peter's approach a lot, but I'm kind of scared to throw two pages of compilation errors at a user that makes a mistake...)
(On a more personal note: I also have the problem of keeping honest and checking that I'm not just putting myself in the way of change because I'd have to revise my course material and book. People, please call me out on this if I don't realize I'm slipping.)
Going back to technical stuff:
- yes, the two approaches might overlay, but if Peter's approach is in place, you lose the simplicity of Alex's approach anyway and the typedef only sets the default.
- about the wrapper class: Alexander, I was under the impression that the problems you were having could be solved just by specializing Null<AD<Real>> and giving it an appropriate conversion operator as Peter did. Did you have time to look at his code? If this work, you won't need the wrapper (which might add conversion issues, inlined or not).
- in any case, I think the two approaches can both benefit from sharing changes. The specialized Null is one case; Alex's MC engineering would be another.
Ok, enough for now, I guess...
Later,
Luigi
news, videos, case studies, tutorials and more. Take a look and join the
conversation now.