interval diameter (length, width, measure, range, or size) about portion HOT 8 CLOSED

This has already been proposed but (temporarily) rejected, see #42 #60 #61.

from portion.

Yes, intervals are immutable so any property can be computed and cached at creation time.

from portion.

Just to weigh in, interval length is mathematically well-defined for any type of interval. The length of a real interval is usually defined as b - a, for both closed and open intervals since endpoints have no size. The question is which value to assign to unbounded intervals. It could be +inf or undefined depending on the domain. In any case, I don't see a loss of generality by implementing such a property.

I am aware that portion does not support discrete intervals explicitly. But for discrete intervals, the size of an interval is its set order. If the interval is open, the open endpoint is not part of the set of course.

Interval size plays an important role in integration theory and real analysis. However, my use case scenario is scheduling applications.

Thank you,

from portion.

What would be the length of the empty interval, without loss of generality about the objects being used as bounds?

Notice that if you really need to compute the length of (numerical) intervals, you can already define your own function that accepts an interval and returns its length, or you can subclass the Interval class to add such a property. See the (not-yet-released) recent changes we made https://github.com/AlexandreDecan/portion#specialize--customize-intervals (in particular, the create_api function that makes it easy to keep the existing API while subclassing intervals).

from portion.

Just like unbounded intervals, the length of an empty interval could be 0 or undefined, depending on the domain. A possible solution to keep the generality would be to define a default value for these special cases, but let the user change it.

In any case, thanks for the suggestion. I'm subclassing Interval but the final notation is still a bit cumbersome since I use the function closedopen to create the intervals I work with.

I did it like this:

def set_size(self):
    size = 0
    for i in self:
        if isinstance(i.upper, int) and isinstance(i.lower, int):
            size += i.upper - i.lower

    self.size = size

Many thanks

from portion.

I only need bounded and non-empty closedopen intervals, so I ended up doing this. Everything seems to be working as expected for my use case. This way I do not need to import portion to use the function closedopen, just this module. Please let me know if this can break something else though. It is not a suggestion in any way, just a solution I found to my scenario.

import portion as P

class Interval(P.Interval):
    def __init__(self, *intervals):
        if len(intervals) == 2 and all(isinstance(x, int) for x in intervals):
            super().__init__(P.closedopen(*intervals))
        else:
            super().__init__(*intervals)

        self.set_size()


    def set_size(self):
        size = 0
        for i in self:
            if isinstance(i.upper, int) and isinstance(i.lower, int):
                size += i.upper - i.lower

        self.size = size

from portion.

Hi. I think that's ok w.r.t. breaking changes. However, I don't think it's a good idea to create atomic intervals using the constructor of the Interval class. Is the sole purpose to accept integers is to avoid to write a call to P.closedopen, then why not create an alias for this function? (e.g., c = partial(P.closedopen, klass=Interval))

from portion.

That's probably better, thank you.
Would it be possible to define size when the interval is created?
I would like to avoid calculating it at every size call.

from portion.