Re:Backpropagation is a leaky abstraction
by im3w1l on Tuesday December 20, 2016 @07:12AM
(#13219156)
Those properties should ideally be part of the documentation so that the abstraction stops leaking.
One could argue that if these details are necessary for correct/performant operation, then it is a leaky abstraction.
Re:Backpropagation is a leaky abstraction
by im3w1l on Tuesday December 20, 2016 @09:27AM
(#13220029)
To me a leaky abstraction is an abstraction that does not expose all the relevant details. So if those details are written on the spec sheet of the black box then there is no leak.
If the box is only labelled with O(nlog n) without specifying constants then there is a leak.
Re:Backpropagation is a leaky abstraction
by ezanmoto on Tuesday December 20, 2016 @09:26AM
(#13220018)
I feel that if you care that much about the internals of the abstraction then you don't necessarily want an abstraction anymore, but rather the concrete thing that is being abstracted over. I think abstraction is an admirable quality that has numerous advantages, but if you need guarantees on the properties of what's under the abstraction then an abstraction is probably not what's needed at that point.
There are a lot of details to get right: how are elements compared? Is the sort stable? Is it efficient for small N? Is it efficient for nearly-sorted arrays? Is it efficient when almost all the elements compare equal? Is it guaranteed O(n log n) or average? If average, is there an input that reliably triggers n^2 behavior making it a DDoS vector?
Anything is a leaky abstraction when you care enough.