My main concern is the usage of Range for code generation. Since symbolic ranges were only just added, they haven't been used there yet. But if some of these things come up as needed there, I think we should add them. If they don't end up being needed, then we can be more strict and leave them out.
Aaron Meurer On Fri, Aug 30, 2019 at 11:42 AM Chris Smith <[email protected]> wrote: > > 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]> 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]. >> > 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. -- 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/CAKgW%3D6LRzL6dFotbUL8%2BvUq67usjJyQxP_YQqbpoVeBsgbHbqA%40mail.gmail.com.
