nomenclature constancy

[JeffreySarnoff]

David Sanders and I have given some attention to interval field naming in an attempt to find a seat of general agreement. Taking the best of both your contribution (parameterizing AbstractInterval) and our easy-peasy field naming, for directed intervals with two bounds (possibly equal), we have:

abstract type AbstractInterval{T} end

struct ConcreteInterval{T} <: AbstractInterval{T}
lo::T
hi::T

# inner constructor, if any

end

If you are amenable to the field name change, @dpsanders may be moved to parameterized abstraction. Each would be another step toward first-class intervals that just work and will do so intra-packagly.

[timholy]

I'm fine with field renaming. FYI for our applications it's important to be able to encode an empty interval with lo > hi. lo == hi is not empty, it has a single point in it.

[JeffreySarnoff]

Yours and some of mine -- I lean on half-open intervals: 'instantons' are ephemeral and moments accrete.

[JeffreySarnoff]

What do you do with these?

…

On Thu, Mar 23, 2017 at 7:11 PM, Tim Holy ***@***.***> wrote: I'm fine with field renaming. FYI for our applications it's important to be able to encode an empty interval with lo > hi. lo == hi is not empty, it has a single point in it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABmqxvqjL82-KX106BrbHyDjaWlrjC_pks5rovwvgaJpZM4MnQ48> .

[timholy]

They are ranges without the implied step. For UnitRange, 1:0 is an empty range.

Example application: you want to find out whether two intervals intersect. The natural approach is to intersect them and then ask whether the returned interval is empty. If you can't define a value that means empty, then this straightforward approach doesn't work.