Just to follow up on this thread in case anyone else is interested, I found 
that the Einsum.jl package is quite close to what I need for my FEM 
application.   It is lacking a couple of features, so I added them to the 
package and have submitted a pull request.  Hopefully the author of 
Einsum.jl and I will come to a happy conclusion of a new improved Einsum.jl 
package in a week or two.  Thanks to all the posters who responded.

-- Steve


On Sunday, May 22, 2016 at 11:20:27 AM UTC-4, Jutho wrote:
>
> https://github.com/ahwillia/Einsum.jl
> or
> https://github.com/Jutho/TensorOperations.jl
> might also be of interest
>
> Op vrijdag 20 mei 2016 17:17:08 UTC+2 schreef Matt Bauman:
>>
>> I believe something just like that is already implemented in 
>> Devectorize.jl's @devec macro.  Try: `@devec y[:] = y + a .* x[ind]`.
>>
>> https://github.com/lindahua/Devectorize.jl
>>
>> On Friday, May 20, 2016 at 11:04:34 AM UTC-4, [email protected] wrote:
>>>
>>> I'm not sure that fixed-size array solves the problem.  For one thing, 
>>> the size of the small array may not be known at compile time.  For another, 
>>> I don't want the small vectors necessarily to be immutable.
>>>
>>> I decided that what would really solve this problem is indicial 
>>> notation.  This can be provided by a macro.  I have not actually written 
>>> the macro-- macro-writing sometimes gives me a headache.  But I have 
>>> already documented it!  See:
>>>
>>>     https://github.com/StephenVavasis/Indicial.jl 
>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FStephenVavasis%2FIndicial.jl&sa=D&sntz=1&usg=AFQjCNHXjC8cNNi7_jdVi1QPzKUvFFeMTQ>
>>>
>>> for documentation of my latest vaporware.  If someone out there who 
>>> enjoys macro-writing wants to take a crack at this before I do, feel free!
>>>
>>> -- Steve Vavasis
>>>
>>>
>>>
>>>
>>> On Thursday, May 19, 2016 at 9:47:12 PM UTC-4, [email protected] 
>>> wrote:
>>>>
>>>> The two functions test4 and test5 below are equivalent, but test5 is 
>>>> much faster than test4.  Apparently test4 is carrying out a heap 
>>>> allocation 
>>>> on each iteration of the j-loop.  Why?   In general, which kinds of 
>>>> assignment statements of the form <array>=<array> create temporaries, and 
>>>> which don't?  (In the example below, if the indirect addressing via array 
>>>> i 
>>>> is eliminated, then the two functions have comparable performance.)
>>>>
>>>> Thanks,
>>>> Steve Vavasis
>>>>
>>>> function test4(n)
>>>>     y = [2.0, 6.0, 3.0]
>>>>     i = [1, 2, 3]
>>>>     z = [0.0, 0.0, 0.0]
>>>>     u = 0.0
>>>>     for j = 1 : n
>>>>         z[:] = y[i]
>>>>         u += sum(z)
>>>>     end
>>>>     u
>>>> end    
>>>>
>>>> function test5(n)
>>>>     y = [2.0, 6.0, 3.0]
>>>>     i = [1, 2, 3]
>>>>     z = [0.0, 0.0, 0.0]
>>>>     u = 0.0
>>>>     for j = 1 : n
>>>>         for k = 1 : 3
>>>>             z[k] = y[i[k]]
>>>>         end
>>>>         u += sum(z)
>>>>     end
>>>>     u
>>>> end    
>>>>
>>>>
>>>> julia> @time Testmv.test4(10000000)
>>>>   1.071396 seconds (20.00 M allocations: 1.192 GB, 7.03% gc time)
>>>> 1.1e8
>>>>
>>>> julia> @time Testmv.test5(10000000)
>>>>   0.184411 seconds (4.61 k allocations: 198.072 KB)
>>>> 1.1e8
>>>>
>>>>

Reply via email to