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

Agree and streamline treatment of context in tensor #28

Open
kaifox opened this issue Sep 25, 2017 · 3 comments
Open

Agree and streamline treatment of context in tensor #28

kaifox opened this issue Sep 25, 2017 · 3 comments

Comments

@kaifox
Copy link
Member

kaifox commented Sep 25, 2017

Currently, the context can give problems in the following cases:

  • in the equals method: Currently, it is taken into account, but should it? What could be alternatives? E.g. having an additional method, like isIdentical(), which takes into account the context and remove it from the default equals method?
  • E.g. when extracting a tensor, and then using it in a calculation, where broadcasting is required (with the same dimension): One solution could be that the context determination should become a method in the broadcasting strategy ... probably it is?? To be evaluated...
@agorzawski
Copy link
Member

for the first bullet, yes it it shouldn't be taken (i.e. two chroma measurements at different time (the time is in the context).... isIdentical() seems to be the most obvious .

second bullet, I vaguely remember that it was implemented. To be confirmed...

@michi42
Copy link
Member

michi42 commented Sep 27, 2017

  • I think I agree on the first point - two tensors can be equal even with different contexts. So it should not be considered for equals(). Adding an identical() method or similar sounds fine. We only need to take care that this is reflected for hashCode() as well to not break the contract.
  • For the broadcasting, I would not consider the context for the default broadcasting strategy. In particular not when we define the equals() without context. Otherwise, we could produce 'interesting' results like A==B but A+C != B+C if A and B have different contexts.
    In general, one could ask how much sense it makes to propagate forward the context through calculations ... what should be the context of A+B if A and B have different contexts?
    The current (default) LeftContextPreservedStrategy feels somewhat arbitrary - and, strictly speaking, breaks the commutativity of operations (in particular as long as we consider the context for equals()).
    Perhaps propagating no context at all through calculation would be a better default? Or at least don't propagate contexts in a way that breaks when constructing the result tensor.

@kaifox
Copy link
Member Author

kaifox commented Oct 1, 2017

Ok, ... I think here we converge more or less in our opinions....

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

3 participants