Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement suggestion: method chaining for add_, sub_, etc. #10

Open
kechan opened this issue Jan 22, 2019 · 0 comments
Open

Enhancement suggestion: method chaining for add_, sub_, etc. #10

kechan opened this issue Jan 22, 2019 · 0 comments

Comments

@kechan
Copy link

kechan commented Jan 22, 2019

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:

 v1.sub_(v2).sub_(v3) 

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.

@kechan kechan changed the title Enhancement suggestion: chaining for add_, sub_, etc. Enhancement suggestion: method chaining for add_, sub_, etc. Jan 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant