-
Notifications
You must be signed in to change notification settings - Fork 351
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
Equivalence operator fails to handle vector string differences #1981
Comments
This is an interesting observation, @kwokcb, but I wonder if this is actually by design? After all, we don't want our document comparison logic to convert from value strings to precision-limited floats and vectors before performing comparisons, as this would destroy information that was present in the original value strings. Is there another approach that you had in mind, that might improve upon our current literal string comparisons, but without destroying information that was present in the original strings? |
I guess if it is indeed doing a string compare then it should do a numeric value compare instead for |
As noted above, it's my sense that converting strings to precision-limited floats and vectors for document comparisons would be a step backwards, as it would hide meaningful differences (e.g. 0.9 and 0.899999976 would be considered identical), and would remove the ability to compare documents containing invalid value strings. I'm definitely open to other ideas on how to improve our document comparisons, though, if you have thoughts on strategies that might provide the best of both worlds. |
Feels to me like maybe there are different use-cases for comparison, and perhaps the best approach is to think about supporting different types of comparison. I can see the value in a true value comparison, as well as the current string comparison. |
Here's another possibility: keep it as a string compare, but preprocess each string first to 1) remove all whitespace, and 2) remove all ".0[0*]" (e.g. a decimal followed by one or more zeroes). That way, "1,1" and "1, 1" and "1.0,1.0" would all be "equal". This wouldn't cover all possible cases, but I bet it'd cover the most important differences with no destruction of actual information in the original string representation of the numeric values, and no floating-point precision concerns. |
That's a really cool idea, @dbsmythe. Taking this one step further, what if we added a new This would allow @kwokcb to achieve the result he's after by testing the following:
An additional advantage of this separation is that |
I like this idea, but maybe |
Good point, and perhaps We do have some precedent for the usage of MaterialX/source/MaterialXFormat/File.cpp Line 136 in 153a803
|
This all sounds very promising.
Thus this could be run on a document / nodegraph, node, input or just a string, to normalize as needed. This also does not require any class interface modifications. |
That sounds reasonable to me, @kwokcb, and I might suggest the following for consistency with similar methods in MaterialX:
|
I will put up something for this. Note that the per Element scope is useful as I've had to write different equivalence code to work around the strict ordering check which I logged an issue for. |
Let's fold this issue into the more recent proposal for a functional equivalence operator in #1987. |
Issue
The
operator==
operator seems to detect that a element differs when the format of the string used to representvectors differs.
This seems very strange as the values are identical and would assume in memory that the comparison does not take into consideration the string formatting.
I cannot currently compare documents such as these.
Example
Test file 1:
Test file 2:
The differences are:
.0
vs not using.0
. e.g.0
vs `0.0The text was updated successfully, but these errors were encountered: