You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The AbstractSamplers generate matrices where data is organized by row instead of column.
So when a user writes a parallelized objective function for example, they must iterate by row:
functionf_parallel(X)
fitness =zeros(size(X,1))
Threads.@threadsfor i in1:size(X,1)
fitness[i] =f(X[i,:])
end
fitness
end
This is atypical in Julia, as most users and external packages organize data by column. Additionally, iterating by row is discouraged, as Julia is column major and thus the row values will not be stored contiguously, causing cache misses.
Was just wondering if this was by design or if their was a good reason for this? I'm adding the option in my fork for users to initialize methods with a pre-generated population, so I need to exchange a lot of the length calls for size in _complete_population!, and would like to abide by your original design in case of eventual PR/merge.
If not, I'll move my fork to completely column major and make my changes based on that.
The text was updated successfully, but these errors were encountered:
The row major implementation in the whole package comes from its genesis without any specific reason (my fault since that), and we need to move to the typical way in Julia (column major).
The AbstractSamplers generate matrices where data is organized by row instead of column.
So when a user writes a parallelized objective function for example, they must iterate by row:
This is atypical in Julia, as most users and external packages organize data by column. Additionally, iterating by row is discouraged, as Julia is column major and thus the row values will not be stored contiguously, causing cache misses.
Was just wondering if this was by design or if their was a good reason for this? I'm adding the option in my fork for users to initialize methods with a pre-generated population, so I need to exchange a lot of the
length
calls forsize
in_complete_population!
, and would like to abide by your original design in case of eventual PR/merge.If not, I'll move my fork to completely column major and make my changes based on that.
The text was updated successfully, but these errors were encountered: