On Wed, 2015-05-06 at 18:25, Stéphane Mottelet <[email protected]>
wrote:
> As I already answered to Steven, these matrices are not just "data"
> because their elements change at each iteration of an optimization
> process. So i need "code" to update the matrices.
Anything you can achieve with metaprogramming you can also achieve in
any Turning complete language. But don't run from Julia and port your
program to Brainfuck now ;-)
For instance your first nzval update could be:
locs = Vector{Int}[[-1, 18, 63, 103],
[1, 63],
[1, 18],
...
]
function update_nzval!(nzval, v, locs)
for i =1:length(locs)
nzval[i] = 0
for j=2:length(locs[i])
nzval[i] += v[locs[i][j]]
end
nzval[i] *= locs[i][1]
end
end
> S.
>
> Le 06/05/2015 16:47, Stefan Karpinski a écrit :
>> Yes, this seems like a severe abuse of the compiler. It makes much
>> more sense for this to be input as data rather than code.
>>
>> On Wed, May 6, 2015 at 8:42 AM, Steven G. Johnson
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> It doesn't make sense to me to use code generation to spit out a
>> literal expression for inputting a large sparse matrix on each
>> iteration of optimization. In no conceivable compiler will this be
>> faster than just using a loop to generate the sparse matrix data
>> structure, rather than using a loop to generate the code to
>> generate the sparse matrix and then compiling the generated code.
>> It should be O(n) work in either case, but the constant factor
>> will inevitably be worse for a compiler.
>>
>>
