iitis / symmetrictensors.jl Goto Github PK

Following changes to symmetric tensors access functions should be made:

1. getindex(st::SymmetricTensor, mulind...) should return tensor element in the same as an Array would.
2. accesnotord(st::SymmetricTensor, mulind::Tuple) rename to getblock(st::SymmetricTensor, mulind::Tuple).
3. add getblock(st::SymmetricTensor, mulind...).

We have to decide weter setindex(st::SymmetricTensor, mulind...) should change all symmetric tensor elements?

I am sorry I did not understand your code without reading the associated paper. May I ask if we can create fourth-order tensors in this package, especially the symmetric ones?

review and rewrite docs

The motivation for the block size is not clear, maybe you should add, that it is only performance relevant, has no effects on the result and that in your test cases the best value was 2?
See also:
iitis/Cumulants.jl#16

New version of julia is out. We should support it ASAP. Should we keep compatibility with julia 0.5.x? How much effort this requires? @kdomino @pgawron

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

The tag name "0.2.0" is not of the appropriate SemVer form (vX.Y.Z).
cc: @lpawela

I made the mistake to use it in a performance critical part of the code, and noticed that pyramideindices re-eval its body at every execution, making it very inefficient:

julia> @time pyramidindices(3, 3) ;
  0.012201 seconds (23.48 k allocations: 1.190 MiB, 88.89% compilation time)

julia> @time pyramidindices(3, 3) ;
  0.012611 seconds (23.48 k allocations: 1.190 MiB, 86.13% compilation time)  # Compilation again

I am not quite sure how to solve the issue in general.

For my case I just cache the result with Memoization.jl and it is fine (I call it with the same arguments over and over, so I don't need to be very fancy).