Le 06/05/2015 21:15, Mauro a écrit :
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
Thank you, I didn't knew I can use vectors of vectors !
S.
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.
