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
For train-test splits on pre-assembled lsq systems it is useful to have access to which rows in the design matrix correspond to individual training structures. At the moment I do this:
# copy-pasted from the assembly routine
lsqrows =Array{UnitRange}(undef, length(_data))
lsqrows[1] =1:count_observations(_data[1])
for i in2:length(_data)
lsqrows[i] = lsqrows[i -1][end] .+ (1:count_observations(_data[i]))
end
This is obviously a hack. Is it safe for now? Could something like that become part of the interface? Maybe it could be returned with the assembly routine?
The text was updated successfully, but these errors were encountered:
Yes I would very much prefer that. It just turns out this was a pretty convenient thing to have after all.
What I would really like though is something a little broader - something like a "lazy learning task" that knows the model, the dataset, will assemble things on demand - store them for re-use if allowed, etc ... Can manage many fits, parameter scanning etc...
But as a quick fix just for now, can we maybe spin out that part of the assembly routine into a separate function that I can call so I can be certain the ordering will be the same?
For train-test splits on pre-assembled lsq systems it is useful to have access to which rows in the design matrix correspond to individual training structures. At the moment I do this:
This is obviously a hack. Is it safe for now? Could something like that become part of the interface? Maybe it could be returned with the assembly routine?
The text was updated successfully, but these errors were encountered: