search

lorenzha / hdcd

0 stars 1 forks source link

'start' and 'end' in FUN #26

Closed MalteLond closed 5 years ago

MalteLond commented 6 years ago

Row 131-135.

Why do you require the loss function FUN to have (inside) arguments 'start' and 'end'? Later it will automatically be fed an x that is cut off appropriately.

Also, is there a possibility to feed FUN automatically the right parameters it asks for (i.e. n_obs, lambda, ...)?

lorenzha commented 6 years ago

The issue is that some loss functions have to be calculated completely from scratch for each segment whereas other could have "updates" which make them much faster (e.g. InitSquaredLoss). For those I use start and end which point to the global indices (indices on the whole data) whereas I use the sliced data to calculate the loss anew if I have to. If I would only use start end I would need to copy the whole dataset for each sub-segement which could blow up the memory quickly. Thats why I require every loss function to have that interface so I don't have to worry about which case is implemented in the loss function itself. Do you get what I mean?

To the second point: What do you mean with "automatically"?

MalteLond commented 6 years ago

concerning automatically: I.e. I want to allow for FUN to have parameters such as n_obs, lambda, ... . S.t. if FUN takes only lambda as an argument, then FUN(lambda = lambda) is called. If it takes lambda and n_obs as an argument, FUN(lambda = lambda, n_obs = n_obs) is called ...

concerning start, end: Why not just allow for functions to use updates (such as initsquaredloss) but not require the start, end? This would then return to the first question, where functions that use start, end can be called with those (and x in the first function call), whereas others that dont are not.