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

[Bug] Exclusive ranges might skip last element #114

Open
mattsep opened this issue Mar 7, 2022 · 4 comments
Open

[Bug] Exclusive ranges might skip last element #114

mattsep opened this issue Mar 7, 2022 · 4 comments
Labels
bug Something isn't working Silent wrong answer Highest Priority

Comments

@mattsep
Copy link
Contributor

mattsep commented Mar 7, 2022

There is a bug in the parsing of exclusive ranges that is showcased by this example:

print List(1.0 ... 1.2 : 0.15) // prints [ 1 ], but should print [ 1, 1.15 ]

This happens because the exclusive range 1.0 ... 1.2 : 0.15 is converted to 1.0 .. 1.05 : 0.15 by subtracting the step from the end, which is not the right thing to do in this situation. Since this happens at parse time, it's not possible to revert this calculation in the range_count function.

If we were to instead convert all inclusive ranges to exclusive ranges by adding the step to the end, we would find that 1.0 .. 1.2 : 0.15 would be converted to 1.0 ... 1.35 : 0.15 which would print [ 1, 1.15, 1.3 ] and this is also not correct.

What we likely need is to explicitly flag whether a given range is inclusive or exclusive range at construction so that we can compute the correct number of elements in the range_count function, at which point we can convert both ranges to one or the other.

@ConduitDan
Copy link
Collaborator

Did this get fixed? I cannot reproduce this on the main branch

@ConduitDan
Copy link
Collaborator

Updated the example

@ConduitDan ConduitDan added bug Something isn't working Silent wrong answer Highest Priority labels Apr 4, 2022
mattsep added a commit to mattsep/morpho that referenced this issue Apr 9, 2022
@softmattertheory
Copy link
Contributor

Is this now fixed?

@mattsep
Copy link
Contributor Author

mattsep commented May 8, 2022

Not yet - this issue arises due to how exclusive ranges are converted to inclusive ranges at parse time. I think inclusive and exclusive ranges need to be parsed separately, and only converted to one or the other at a later time, once we have full knowledge of the bounds and step size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Silent wrong answer Highest Priority
Projects
None yet
Development

No branches or pull requests

3 participants