ordinal range implementation, fixes #5585 #6326
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| $fn(r::Range ) = Range($fn(r.start), $fn(r.step), r.len) | ||
| $fn(r::Range1) = Range1($fn(r.start), r.len) | ||
| $fn(r::StepRange) = $fn(r.start):$fn(r.step):$fn(last(r)) | ||
| $fn(r::Range1) = $fn(r.start):$fn(last(r)) |
|
Glad this is coming along. This branch could stand a rebase or something to get rid of all the merges. |
| if D<:FloatingPoint || S<:FloatingPoint | ||
| error("StepRange should not be used with floating point") | ||
| end | ||
| step == 0 && error("step cannot be zero") |
There was a problem hiding this comment.
Finally got around to trying these out with Dates. The one hiccup I ran into for getting Date/Period ranges to automatically work was the step == 0, step>0 lines in the constructor, and the step(r) == 0 in the show method for Range. I changed them to step == zero(S) and step>zero(S), along with step(r) == zero(typeof(step(r0))) in the show method and everything works like a charm!
The reason is Date/Real and Period/Real comparisons aren't allowed in the Dates code.
I'll pull out the old range tests I use to have for DateTimes and Periods and play with this some more.
still not clear what to do with floating point in StepRange
It turns out there are many cases that are drastically easier this way. Tests not passing yet, but getting there.
rename Range1 to UnitRange allow constructing a larger class of ranges, leaving overflow to length()
export UnitRange NEWS for range changes remove random test for BigInt ranges, since they now have BigInt lengths, for which we can't yet generate random numbers.
this is likely to cause too much breakage; e.g. arrays of UnitRange{Int}
are common.
it expressed a degree of freedom that was not really there, since it really depended on the first two parameters.
JeffBezanson
added a commit
that referenced
this pull request
Apr 1, 2014
ordinal range implementation, fixes #5585
|
|
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Adds
OrdinalRange,StepRange,UnitRange, andrange.length, and aside from that large ranges work, except for iterating overtypemin(Int):typemax(Int).The requirements on an ordinal type
TareD=T-T,T+D,T<T,D%D, anddiv(D,D)(Dis the type of the difference between elements).