Assume correct extents in binary ops to avoid floating point errors #91
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Floating point math can lead to situations in which combined
GridExtent
s fail a requirement that checks correspondence betweenCellSize
+Extent
on the one hand and pixel cols/rows on the other.This is likely desirable behavior if it happens only when bad data has been passed into MAML. It is very undesirable if it occurs in certain edge cases that are able to compute results properly, as happens whenever the
Extent
/CellSize
ratio becomes too large and floating point arithmetic's approximations fail us.The upshot of this is that we get slightly less guarded execution but avoid false positive errors