Improper Usage of @pure about grassmann.jl HOT 8 CLOSED

Thank you for your detailed report regarding the issue with @pure.

I am aware that there are certain issues associated with it; however, I do not intend on cutting back on the usage of it very much in this repository.

However, I would like to investigate my usage of it more and try to make it more stable and correct in its usage, because many things in this repository have rapidly changed.

This issue will be closed now, since I don't intend to cut back overall, but the discussion can remain open here for further comments since I do intend to resolve any critical issues of this type.

from grassmann.jl.

Presumably its for performance reasons. I did some microbenchmarks against my fork where I removed all the @pures and various multivector multiplications seem to be about a factor of 10x faster (~100ns -> ~1μs). Surely there are better ways to eke out this extra speed than violating all the rules the compiler holds dear though.

from grassmann.jl.

I see. For what it's worth, I forked the repo and removed all uses of @pure and that seems to have solved #7.

from grassmann.jl.

I am aware that there are certain issues associated with it; however, I do not intend on cutting back on the usage of it very much in this repository.

So it causes problems, but you want to keep doing it anyway? Why?

For an internal error as in #7 we could do something in the compiler to avoid the error, but it still indicates that there is a potentially invalid use of @pure.

from grassmann.jl.

If this package continues to misuse @pure it is very unlikely to ever work reliably. It's also unclear why you feel the need to use @pure annotations so heavily. Why do you feel that you need them?

from grassmann.jl.

The reason why I use it and made this project is because it's fun to try out and experiment with.

In fortran programming I had used pure methods also, and I see that in Julia it can lead to big performance boosts, but the rest of the design must assume extra constraints.

In this particular package, the entire design constraint is centered around passing around parametric type data ahead of compile time in order to make the generated code more efficient, yet also remain fully flexible for both numerical and symbolic computation with many different dimensional spin algebras.

That is why if you naively remove all usage of @pure you will have drastic performance costs.. in the JuliaLang discourse I have already explained why I used it, but without @pure you are not going to be able to get efficient code on many instances into the function ahead of compile time.

Yes, there is indeed very likely a bug or mistake with my usage, which I need to hunt down. I did not actually have time to double check my usage on every line yet.

At the beginning I was a lot more precise and careful with my usage, but as I had to redesign a lot of things in the package I may have introduced some bugs with the @pure usage.

from grassmann.jl.

In this particular package, the entire design constraint is centered around passing around parametric type data ahead of compile time in order to make the generated code more efficient, yet also remain fully flexible for both numerical and symbolic computation with many different dimensional spin algebras.

The complaint is that the way you do achieve relies on invalid assumptions that can at any point come up and bite a user in the ass unexpectedly. There are tried and true ways to perform operations at compile time which don't involve abusing @pure.

from grassmann.jl.

As discussed in #7 it was not the @pure macro that was really the issue in this repository. There were some other bugs which have been worked out, but overall the usage of it is relevant here.

from grassmann.jl.