Trying to motivate the case for method chaining for the "underscore" operations.
I noticed there are a whole set of operations that end with underscore. I think I have seen this in PyTorch, where convention means the object instance will get modified (a mutating func in swift term).
Consider this:
benchmark(title: "run 1") {
let v123 = v1 - v2 - v3
}
benchmark(title: "run 2") {
v1.sub_(v2); v1.sub_(v3)
}
where v1, v2, and v3 are very large. It took 41.405 ms for 1st and 16.365 ms the 2nd. The diff is due to .new(...) being called twice. So depending on the computational context where you don't care about original v1 getting clobbered. You prefer the 2nd way. I found this is often the case if you need to customize or during post-processing of neural network (intermediate input/output) in Apple CoreML. This motivates writing this:
in one single line and sub_ should return self to allow this method chaining. Please let me know what you think, and if this makes sense. I will try this out locally, but just want to hear if you know any bad surprise.
Trying to motivate the case for method chaining for the "underscore" operations.
I noticed there are a whole set of operations that end with underscore. I think I have seen this in PyTorch, where convention means the object instance will get modified (a mutating func in swift term).
Consider this:
where v1, v2, and v3 are very large. It took 41.405 ms for 1st and 16.365 ms the 2nd. The diff is due to .new(...) being called twice. So depending on the computational context where you don't care about original v1 getting clobbered. You prefer the 2nd way. I found this is often the case if you need to customize or during post-processing of neural network (intermediate input/output) in Apple CoreML. This motivates writing this:
in one single line and sub_ should return self to allow this method chaining. Please let me know what you think, and if this makes sense. I will try this out locally, but just want to hear if you know any bad surprise.