I'd also like to point out that "adding" two intervals doesn't necessarily result in a new interval, e.g. add([1,4], [9,12]). At least, I wouldn't expect you to return [1,12] for that, because 10 obviously falls in neither of the two.

As far as the $arg1->add($arg2) notation is concerned, this is pretty much standard for a lot of Math related modules. See Math::BigInt for example.

Number::Interval and Set::Window seem to be concerned with intervals on a number line. Neither module has defined the basic arithmetic operators (+, -, · and ÷) or mathematical functions. I need these along with comparison functions to test the 18 (eep!) relations between two intervals.

For my application an interval represents a value with a known amount of error. The interval [4, 6] means that the real answer is somewhere between 4 and 6, but we don't know exactly where. Because floating point calculations aren't exact, the results of interval calculations are rounded out by rounding the lower bound down and the upper bound up to the next representable numbers. The end result gives you a lower and upper bound that contain the real answer.

The basic operators for intervals are defined as:

x op y = [ min{ lower(x) op lower(y), lower(x) op upper(y),
                upper(x) op lower(y), upper(x) op upper(y) },
           max{ lower(x) op lower(y), lower(x) op upper(y),
                upper(x) op lower(y), upper(x) op upper(y) } ]
[download]

With a few proofs we can eliminate some of the operations. So, to add two intervals you would add the lower bounds together and the upper bounds together. For example, x + y = [lower(x) + lower(y), upper(x) + upper(y)]. So your example of add([1, 4], [9, 12]) would return [10, 16], which does contain 10.

Thank you for your reply.

Owl looked at him, and wondered whether to push him off the tree; but, feeling that he could always do it afterwards, he tried once more to find out what they were talking about.

Thanks for making the difference with more conventional ideas about intervals clearer. I based my answer on the naive interpretation of the notion, and you're right, that's not what you're dealing with.

Now that I realise that Interval Computation is a whole field of mathematics, I'm more inclined to suggest that your module name should somehow express that. Since interval and computation are both generic and already have broad CS usage, I'd lean toward something like Interval::Analysis. Maybe put it in the Math namespace as well, although Math::Interval::Analysis is pretty long. It does seem like The right thing to do though...

Fixed. Thank you for bringing that to my attention.

Owl looked at him, and wondered whether to push him off the tree; but, feeling that he could always do it afterwards, he tried once more to find out what they were talking about.

Perhaps splitting the difference is a good solution. Math::Interval could contain the basic class with validation, type conversion and the comparison operations. Then Math::Interval::Arithmetic could define the basic arithmetic operators, Math::Interval::Trigonometric could define the trigonometric functions and so on.

Owl looked at him, and wondered whether to push him off the tree; but, feeling that he could always do it afterwards, he tried once more to find out what they were talking about.

You might take a look at Number::Tolerant

Number::Tolerant is closer to what I need but is still missing the arithmetic operations.

Owl looked at him, and wondered whether to push him off the tree; but, feeling that he could always do it afterwards, he tried once more to find out what they were talking about.

use overload (  '+' => \&add );
# now $arg1 + $arg2 will be handled as $arg1->add($arg2) behind the sc
+enes.
[download]

That's a good idea. I will look at overload to add operator overloading.

Owl looked at him, and wondered whether to push him off the tree; but, feeling that he could always do it afterwards, he tried once more to find out what they were talking about.

But that's so long to type! ;)

Owl looked at him, and wondered whether to push him off the tree; but, feeling that he could always do it afterwards, he tried once more to find out what they were talking about.

You could use the technique described in Re: use, require, and constructors to create a short name alias for your package

package Math::Interval::Computations;
...

*{MIC::} = *{Math::Interval::Computations::};
1;
[download]

And then your users can do

use Math::Interval::Computations;
my $icObj = MIC->new(...);
...
[download]

Maybe Intvl->new(..) would be a better short name?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Yeah ... you could probably get away with just Math::Interval. If the module's description specifies that it performs "interval computations" (as I'm sure it will) then anyone looking for a module to perform interval computations should find it - and should recognise immediately that it does what they want.

The thing I like about "Math::IntervalComputations" is that the name tells you what it does. "Math::Interval" tells you nothing. If it were up to me I'd still go with "Math::IntervalComputations" .... but it's not up to me .... and that's possibly a good thing :-)

Cheers,
Rob