Open vukics opened 6 years ago
Thank you! I would vote for embracing it (i.e., simplifications and generalisations using Boost preprocessor as exemplified in the above diffs)! @citibeth, @pguio, @lutorm, Julian?
I'm against changing code for its own sake, even if the new code is better. But in this case, the old code does not provide some needed functionality. So I'm open to the idea; but I would want to see it well tested before merging.
-- Elizabeth
On Mon, Jul 2, 2018 at 9:09 AM, Sylwester Arabas notifications@github.com wrote:
Thank you! I would vote for embracing it (i.e., simplifications and generalisations using Boost preprocessor as exemplified in the above diffs)! @citibeth https://github.com/citibeth, @pguio https://github.com/pguio, @lutorm https://github.com/lutorm, Julian?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/blitzpp/blitz/issues/44#issuecomment-401798723, or mute the thread https://github.com/notifications/unsubscribe-auth/AB1cd7NxI7P0x9DhyXdRJbvNKeQ9UBlcks5uChuYgaJpZM4U_Pqy .
Re: "... which [dimension] amount I define by a macro" - I wonder if this could actually offer also an option to for users to reduce compilation time - assuming most of them do not use 11 dimensions for Blitz arrays - to be tested
I’m glad you like it. I created a fork here on github, where I squashed the above diffs into a single commit.
It has been tested a lot over the last few years within my quantum-simulation framework, C++QED, which uses blitz::array
to represent state vectors and density operators of composite quantum systems.
@slayoo Dear Sylwester, do you think that the reduction of the amount of code can itself cut on the compilation time? Because otherwise the unused templates are not instantiated anyway, so it doesn’t do any harm for them to be there in the source code.
@vukics this was more of a question than statement, thanks
Without moving to C++11 (#9), a lot of repetitions in the blitz++ codebase could be omitted using preprocessor metaprogramming.
This would invoke dependence on one more boost library, but that’s no problem I guess?
I actually have to maintain a fork of blitz++ here because the maximal arity for the slicing operations is sometimes insufficient for my application. I used preprocessor metaprogramming to generate the necessary amount of slicing functions, which amount I define by a macro.
You can have a look at the solution in these relevant commits: http://sourceforge.net/p/cppqed/blitz/ci/9b49b225eaf6c9f8f8cb9e039e51d7a2cb056a27 http://sourceforge.net/p/cppqed/blitz/ci/dd01d5816e6e6f56d9d0b299c5a3c999aff676b9 http://sourceforge.net/p/cppqed/blitz/ci/b28e85ab238e1d8bcf4ec4636ec965a9106b76cd
Any chance of such solutions being pulled into the default branch?