There is no way to check it once the returned value is separated from the Range. `Range(x,y,z)[0] -> x` and `x` has no correlation to restrictions of Range. Another layer of complexity is that `Range(x,y,z).inf` is not `x` if `z` is negative. And `Range(x,y,z)[-1]` is worse, because even if you assume integers, you have to calculate the ending value that is a multiple of z.
Being explicit is a safe way to start. Range has tried to give as much leeway for representation while sticking to a safe behavior when symbols are present (i.e. requiring assumptions). Time will tell if this is useful enough. /c On Friday, August 30, 2019 at 11:12:05 AM UTC-5, Aaron Meurer wrote: > > I think it's safe to assume that x is an integer, unless it's > explicitly not. It's pretty standard to not require assumptions, and > anyway, noninteger arguments give an exception, so I think it's > reasonable to assume that any argument must be an integer. It's the > same as Interval(x, y) assuming x and y are real. > > Aaron Meurer > > On Fri, Aug 30, 2019 at 5:28 AM Chris Smith <[email protected] > <javascript:>> wrote: > > > > Even `Range(x, x + 10)[0]` cannot be evaluated unless we known that x is > an integer. > > > > Support for Range and methods which return a known value has been > committed, e.g. `Range(i + 1, i + 10)[0] -> i + 1` if `i` is an integer. > > > > /c > > > > On Thursday, August 29, 2019 at 1:26:22 PM UTC-5, Aaron Meurer wrote: > >> > >> On Thu, Aug 29, 2019 at 6:02 AM Chris Smith <[email protected]> wrote: > >> > > >> > Currently it returns NotImplemented. Were you thinking EmptySet > returns (oo, -oo) for (inf, sup)? > >> > >> Yes, I noticed that it gives NotImplementedError, but the > >> mathematically correct result for it is oo for inf and -oo for sup. > >> See for instance https://en.wikipedia.org/wiki/Lattice_(order) (search > >> for "emtpy set"). In a lattice, join is the supremum and meet is the > >> infimum. The lattice in this case would be the real numbers union -oo > >> and oo, which is a complete lattice. > >> > >> > > >> > In any case, it is not only inf and sup that are problems for a > symbolic range. The problem of how to represent a slice or indexed element > of the range is also present, e.g. `Range(x,y,z)[0]` is not `x` unless the > range is not empty...and if it is empty then accessing `[0]` would generate > an error. > >> > >> I'm not sure here. If we don't make any assumptions, then slicing > >> cannot be allowed in any range with symbolic parameters, except in > >> certain cases like Range(x, x + 10). Which means it wouldn't be very > >> useful. But I'm not really sure if it's something that you'd want to > >> use. > >> > >> Aaron Meurer > >> > >> > > >> > On Tuesday, August 27, 2019 at 10:56:21 AM UTC-5, Aaron Meurer wrote: > >> >> > >> >> I think it's reasonable to return the result. I noticed that > >> >> Interval.inf just returns the lower limit, even though Interval can > >> >> also technically return an empty set. Actually, the infimum of the > >> >> empty set is infinity, not nan, so if that's the concern, we can > >> >> include that in the Piecewise result. > >> >> > >> >> Aaron Meurer > >> >> > >> >> On Mon, Aug 26, 2019 at 6:29 PM Chris Smith <[email protected]> > wrote: > >> >> > > >> >> > Ok, that is a detail that can be changed. But the bigger question > is whether we want such an expression to be returned or if we just want to > forbid it and raise an error if a non-Piecewise result cannot be returned. > >> >> > > >> >> > On Monday, August 26, 2019 at 4:22:13 PM UTC-5, Aaron Meurer > wrote: > >> >> >> > >> >> >> I would structure the Piecewise so that there is no True > (otherwise) > >> >> >> condition, and the empty set cases fall under that. I think > Piecewise > >> >> >> already gives nan in such cases. > >> >> >> > >> >> >> This is also somewhat related to > https://github.com/sympy/sympy/issues/16362. > >> >> >> > >> >> >> Aaron Meurer > >> >> >> > >> >> >> On Mon, Aug 26, 2019 at 1:57 PM Chris Smith <[email protected]> > wrote: > >> >> >> > > >> >> >> > In this PR `Range` has been modified to accept symbolic start, > stop and step values, e.g. `Range(x, y, z)`. One of the decisions that > needs to be made is whether such Ranges should return the symbolic logical > statement corresponding to a given attribute or not. > >> >> >> > > >> >> >> > e.g. the piecewise-folded version of `Range(x, y, z).inf` is > >> >> >> > > >> >> >> > Piecewise( > >> >> >> > (nan, ceiling((-x + y)/z) <= 0), > >> >> >> > (x, z > 0), > >> >> >> > (x + z*ceiling((-x + y)/z) - z, Ne(x, x + 1)), > >> >> >> > (y - z, True)) > >> >> >> > > >> >> >> > The problem is that the nan result is really not the inf...it > is used to indicate that inf is not defined under conditions that would > lead to an EmptySet, e.g. x=z=1,y=0. Is this of any value or should Range > with symbols just raise a ValueError if a property cannot be given as a > simple expression? > >> >> >> > > >> >> >> > /c > >> >> >> > > >> >> >> > -- > >> >> >> > You received this message because you are subscribed to the > Google Groups "sympy" group. > >> >> >> > To unsubscribe from this group and stop receiving emails from > it, send an email to [email protected]. > >> >> >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/6dc89b8f-cf15-4d9e-861c-1ad267df7955%40googlegroups.com. > > > >> >> > > >> >> > -- > >> >> > You received this message because you are subscribed to the Google > Groups "sympy" group. > >> >> > To unsubscribe from this group and stop receiving emails from it, > send an email to [email protected]. > >> >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/95f2dab1-446c-4196-9363-b51de7ed44e1%40googlegroups.com. > > > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > Groups "sympy" group. > >> > To unsubscribe from this group and stop receiving emails from it, > send an email to [email protected]. > >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/dc79e5a0-a782-42f2-8220-e110191e2b5f%40googlegroups.com. > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "sympy" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] <javascript:>. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/53fd30ac-04e5-4f07-83dc-a42f67eef1a8%40googlegroups.com. > > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/28c4f33e-d098-43b5-800d-e59ea7d1ee83%40googlegroups.com.
