sebwrede commented on a change in pull request #1237:
URL: https://github.com/apache/systemds/pull/1237#discussion_r625867368
##########
File path:
src/main/java/org/apache/sysds/runtime/controlprogram/federated/FederatedRange.java
##########
@@ -81,6 +88,10 @@ public long getSize() {
size *= getSize(i);
return size;
}
+
+ public int getOverlapNum(){
+ return _overlapNum;
Review comment:
That would not be a good solution since it would affect all other
federated ranges as well. The solution I implemented here will only affect the
behavior of the overlapping ranges and will not change how the existing
federated ranges behave.
I did not really like this either when I added the _overlapNum, but it was a
solution that would work for the case I added without negatively affecting
anything else.
Another option would be to generate a random ID instead of setting an
overlap number, since I do not need this specific number anyway. The problem is
that I also don't need a randomly generated ID, so it would be overkill to make
the implementation when all I need is any integer.
Another solution would be to add overlap as a boolean and then check if this
boolean is true in compareTo, toString, equals, and hashCode. If it is true
then I should include the object pointer in some way in the computation. But
then the question is again if this is too much compared to just adding a unique
integer from the beginning.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
