I would use a separate class from Interval. For instance, * already means cartesian product on Interval. You can use Interval internally if it takes care of some calculations for you.

I would do it. But I think it end up being the same class Interval with little different name and different meaning for the arithmetic operators. I think it will be little confusing for us to have things like that. Do you have any workarounds?

Maybe what you really want is a separate class on top of Interval. What you are building isn't really an interval, but rather an arbitrary element of an interval. [1, 2] + [2, 4) doesn't make sense mathematically, but (arbitrary element of [1, 2]) + (arbitrary element of [2, 4)) does.

Anyway, we should definitely keep them separate. Interval is a set, not an expression (in the Expr sense). We often use abuse of notation to treat intervals as such, but abuses of notation only serve to create confusing type systems (which isn't to say we shouldn't allow nice syntactic sugar; that's a separate point).

Maybe what you really want is a separate class on top of Interval. What you are building isn't really an interval, but rather an arbitrary element of an interval. [1, 2] + [2, 4) doesn't make sense mathematically, but (arbitrary element of [1, 2]) + (arbitrary element of [2, 4)) does.

Anyway, we should definitely keep them separate. Interval is a set, not an expression (in the Expr sense). We often use abuse of notation to treat intervals as such, but abuses of notation only serve to create confusing type systems (which isn't to say we shouldn't allow nice syntactic sugar; that's a separate point).

Thanks, I got it now. I have created a separate class IV for the purpose. By the way should I put it in a file other than sets.py.

For some reasons the test for division of intervals are failing on my local machine, but it working fine on IPython. Can you help me with this?

================================================================ test process starts =================================================================
executable:         /usr/bin/python  (2.7.3-final-0) [CPython]
architecture:       64-bit
cache:              yes
ground types:       gmpy 1.17
random seed:        51926891
hash randomization: on (PYTHONHASHSEED=3725838702)

sympy/core/tests/test_sets.py[35] ..................................E                                                                           [FAIL]

______________________________________________________________________________________________________________________________________________________
_______________________________________________________ sympy/core/tests/test_sets.py:test_IV ________________________________________________________
  File "/home/hargup/Harsh-sympy/sympy/core/tests/test_sets.py", line 569, in test_IV
    assert IV(1, 2)/2 == IV(Rational(1, 2), 1)
TypeError: unsupported operand type(s) for /: 'IV' and 'int'

============================================== tests finished: 34 passed, 1 exceptions, in 0.28 seconds ==============================================
DO *NOT* COMMIT!

In [1]: from sympy import *

In [2]: IV(1, 2)/IV(2, 3)
Out[2]: [1/3, 1]

In [3]: IV(1, 2)/2
Out[3]: [1/2, 1]

By the way should I put it in a file other than sets.py.

in numbers.py, m.b.?

Can you help me with this?

Yes, the problem is here:

TypeError: unsupported operand type(s) for /: 'IV' and 'int'

Please, take look on the python documentation & other classes (e.g. numbers) on how to handle this. Or you can change 2 -> Integer(2).

Yes, the problem is here:

TypeError: unsupported operand type(s) for /: 'IV' and 'int'

Please, take look on the python documentation & other classes (e.g. numbers) on how to handle this. Or you can change 2 -> Integer(2).

Thanks, I had defined __div__ and __rdiv__ but not __truediv__ and __rtruediv__. That's why I was getting error when running the tests but not when I was doing the same thing with in IPython console.

Yes, there are three combinations to test, Python 2, Python 2 with from __future__ import division, and Python 3. The first one is not important, because every file should be importing division. The last two should be almost the same, but I think there may be some differences regarding __truediv__.

On Sun, Dec 22, 2013 at 03:19:09PM -0800, Aaron Meurer wrote:

Yes, there are three combinations to test, Python 2, Python 2 with from
future import division, and Python 3. The first one is not important,
because every file should be importing division. The last two should be
almost the same, but I think there may be some differences regarding
truediv.

Why not add just:
truediv = div
(like other numbers.py's classes)?

@skirpichev: I created a new file instead of adding IV class in the numbers.py file. I did this because in numbers.py file I was not able to import Interval from sets.py probably because it was in in turn importing a lot of classes from numbers.py.

@asmeurer, @skirpichev : You can start the review. I hope this time you won't have to write comments like "space after comma".

I did this because in numbers.py file I was not able to import Interval from sets.py probably because it was in in turn importing a lot of classes from numbers.py.

I don't think it's a good idea to introduce a new file. Logically, IV belongs to numbers.py or just to sets.py.

And for @asmeurer.

Maybe what you really want is a separate class on top of Interval. What you are building isn't really an interval, > but rather an arbitrary element of an interval.

No, it is. All we do - define some new fancy binary ops: Interval x Interval -> Interval.

Anyway, we should definitely keep them separate. Interval is a set, not an expression (in the Expr sense). We > often use abuse of notation to treat intervals as such, but abuses of notation only serve to create confusing
type systems (which isn't to say we shouldn't allow nice syntactic sugar; that's a separate point).

And maybe the current Set class is wrong. Probably, it should be like builtin set, and not to overload add as union, for example. See this:
http://docs.python.org/3.4/library/stdtypes.html#set-types-set-frozenset

Interval - is just a very good name to keep it. If we keep clean separate interfaces (set-like and number-like) - nothing is wrong if we will have an entity that we can treat as a set and as an expression.

It doesn't seem to belong to numbers.py to me.

And maybe the current Set class is wrong. Probably, it should be like builtin set, and not to overload add as ?> union, for example. See this:
http://docs.python.org/3.4/library/stdtypes.html#set-types-set-frozenset

I removed the __add__, __sub__ and __mul__ procedure from the Set class and ran the test suit to see what breaks. Apart from the obvious failure in test for sets module a few other module uses the overloaded __add__ as union and __mul__ as cartesian product on Interval. Here are the test results.

https://gist.github.com/hargup/8161971
So, changing the current behavior of Interval might not turn to be an easy task, even if we want to do it.

On Sat, Dec 28, 2013 at 09:58:53AM -0800, Harsh Gupta wrote:

So, changing the current behavior of Interval might not turn to be an easy
task, even if we want to do it.

It was just a suggestion (and maybe it has been already
discussed), I'm not sure we want to do it.

And anyhow, unless you're a mathematician, I think it's pretty hard to remember that | is union (I always have to stop for a second and think, "OK, union, that's 'or', so |").

It's all about python compatibility. If Set is a set of sympy's objects - maybe the same (as for builtin set container) interface makes sense.

I have move the IV class back to sets.py

If we keep separate IV and Interval - you should choose a good name for the first.

If we keep separate IV and Interval - you should choose a good name for the first.

Can you suggest any?

Can you suggest any?

Sorry :(

I agree we should keep the same interface, but we should also keep + for union.

Classes like this really show the need for a good dispatching system. One should be able to write this without touching any other file.

Sorry I'm late to the discussion. I think that this class should inherit from Expr and contain-but-not-inherit-from Interval. I would suggest that it does not inherit from both simultaneously.

Also, I think it should contain a Set, not an Interval How much of this logic is generalizable? Consider the following example

X = SetExpr(FiniteSet(1, 2))
Y = SetExpr(FiniteSet(2, 3))

# Evaluates to true?
X + Y == SetExpr(FiniteSet(3, 4, 5))

How far can we generalize the notion of an expression that carries around a set?

SymPy.stats does this to some extent. Each symbol carries around both a set and a probability distribution on that set. Expressions containing multiple random symbols are projections onto cartesian products of sets. This Set-Expr issue should be a much easier problem. It may be that Intervals are easier to work with and deserve special attention. Some sort of simplification scheme might be helpful here.

+1 to Matthew's comments.

I should also note that I'm totally in favor of work in this direction. I think that an Expr frontend to sets and particularly to intervals would be a fantastic contribution!

For scalar functions on sets I think that the natural thing to do is to rely on ImageSet. In general something like the following should work for many interactions

f(SetExpr(a_set)) -> SetExpr(imageset(f, a_set))

In this way we rely on a general computational piece of sets to do much of the work for us. I expect this to expose errors in ImageSet. That's good.

This doesn't handle set-set interactions though.

I set up a draft of my set expression idea in #2721

I should also note that I'm totally in favor of work in this direction. I think that an Expr frontend to sets and particularly to intervals would be a fantastic contribution!

Thanks a lot your words are encouraging.

Also, I think it should contain a Set, not an Interval.

That will be definitely better. The need to implement operations on Interval arose to handle cases like sin(x) --> oo and tan(x) --> oo in limits and other expressions [1]. But using only Intervals won't be sufficient. For example limit(sec(x), x, oo) should return (-oo, -1]U[1, oo) it won't be possible to get it by using only Intervals, we will have to use Set as Expressions.

For scalar functions on sets I think that the natural thing to do is to rely on ImageSet

I was not of aware of ImageSet, thanks for pointing out. I went through its source and what I understood is to check if something is in ImageSet solves the given function minus the parameter and check if it is in the base set. In a sense ImageSet doesn't really know what its content are. Hence, it doesn't play well when Intervals are given as base_set.

In [14]: sqrs = ImageSet(Lambda(x, x**2), Interval(0, 2))

In [15]: Interval(-10, 10).intersect(sqrs)
Out[15]: Intersection([-10, 10], ImageSet(Lambda(x, x**2), [0, 2])) 

I think ImageSet should return the resulting Set when it can do so.
At least for some cases where we can solve the derivative of the function we can compute the resulting ImageSet for an Interval by finding out the local Maximas and Minimas of the function in the base Interval. And for FiniteSet we can simply compute and store the resulting value for each member.

Sorry, I should have suggested that you use imageset rather than ImageSet.

imageset relies on _eval_imageset implemented in various Set classes. That is where much of the actual logic exists.

In [13]: ImageSet(Lambda(x, x**2), Interval(0, 2))
Out[13]: 
⎧ 2             ⎫
⎨x  | x ∊ [0, 2]⎬
⎩               ⎭

In [14]: imageset(Lambda(x, x**2), Interval(0, 2))
Out[14]: [0, 4]

imageset is also not doing the right thing. As of now it works fine only if the given function is monotonic on both positive reals and negative reals. For example it fails here:

imageset(Lambda(x, (x-2)**2), Interval(1, 3))
Out[14]: {1}

Good catch. Looks like Interval._eval_imageset could use some work.

I have implemented an initial fix for Interval._eval_imageset in #2723

I think this PR is no longer needed when Matthew is working on SetExpr and I'm working on imagesets

While I do think that SetExpr is the way to go it's not yet at the level of maturity of this pull request. In particular we should probably do automatic evaluation somewhere as the IV class does rather than rely on setexpr.simplify

On Wed, Jan 01, 2014 at 08:07:43AM -0800, Harsh Gupta wrote:

That will be definitely better. The need to implement operations on
Interval arose to handle cases like sin(x) --> oo and tan(x) --> oo in
limits and other expressions [[1]1]. But using only Intervals won't be
sufficient. For example limit(sec(x), x, oo) should return (-oo, -1]U[1,
oo) it won't be possible to get it by only using Intervals, we will have
to use Set as Expressions.

@hargup, please take look on
https://github.com/sympy/sympy/wiki/Infinities-and-Singularities