Patrick Roberts

@sytabaresa thanks for bringing my attention to this, I'll see if I can implement a pull request for this. In the meantime, I don't know if you're looking for a...

@sytabaresa Hey, I've got a new version of the library in progress, but so far things look pretty promising! This order of operations bug has been fixed in the new...

Good job on the website! With your permission, I'd like to feature your educational tool as an example usage of my repository in the description. Would that be okay?

Version 5.0.0 partially implemented. Run tests with `gulp test`. Will finish code coverage in the next update or two.

I've been looking into this and we can't just unconditionally use the legacy implementation of multiply and add in `where_impl` because it doesn't handle broadcasting correctly in cases where binary_ng...

Okay so looking into this further, here's a test I'm using to verify the behavior I'm seeing: ```py def assert_where_with_pcc(torch_input_tensor, torch_input1, torch_input2, device, pcc=0.9999): def from_torch_if_tensor(x): if not isinstance(x, torch.Tensor):...

So to summarize the main three points I brought up during the meeting: - In `BinaryNgDeviceOperation`, we can encode these ops as a new binary op to pass in `input_tensor_a`...

Once we enable binary_ng without the need for an explicit `use_legacy` flag, can you check to see whether this problem still persists? Or does this op querying happen regardless of...

I've tried to reproduce both issues and I'm sure I have some parameters wrong, but I'm posting the attempts here for feedback on what's necessary to change in order to...

Thanks for the reproduction, still digging into it to understand what the intended logic should be here: