symbolic Range

72 views
Skip to first unread message

Chris Smith

unread,
Aug 26, 2019, 3:57:47 PM8/26/19
to sympy
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

Aaron Meurer

unread,
Aug 26, 2019, 5:22:13 PM8/26/19
to sympy
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
> --
> 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 sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/6dc89b8f-cf15-4d9e-861c-1ad267df7955%40googlegroups.com.

Chris Smith

unread,
Aug 26, 2019, 8:29:35 PM8/26/19
to sympy
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 <smi...@gmail.com> 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 sy...@googlegroups.com.

David Bailey

unread,
Aug 27, 2019, 6:07:36 AM8/27/19
to sy...@googlegroups.com

I have sympy running under Windows 10-64.

Recently I discovered that the standard installation includes all the sources, and I wonder how easy it would be to recompile one source with - say - a print statement included. I added a print statement, and vaguely hoped that merely altering the source would trigger a recompile of that source file.

I didn't get my printout - either because I had not placed it in the right place, or because it wasn't compiled. Can anyone help?

David

Kalevi Suominen

unread,
Aug 27, 2019, 6:32:37 AM8/27/19
to sympy
Did you add the print statement to a source file in a standard installation? The compiled files are also part of the standard installation and can usually be modified only by the super user. Running as an ordinary user will not compile the sources. Instead, you should install a copy of the library in a directory where you have all access rights. The sources can be downloaded from https://www.sympy.org/en/download.html.

Kalevi Suominen

David Bailey

unread,
Aug 27, 2019, 6:54:22 AM8/27/19
to sy...@googlegroups.com
On 27/08/2019 11:32, Kalevi Suominen wrote:
Did you add the print statement to a source file in a standard installation? The compiled files are also part of the standard installation and can usually be modified only by the super user. Running as an ordinary user will not compile the sources. Instead, you should install a copy of the library in a directory where you have all access rights. The sources can be downloaded from https://www.sympy.org/en/download.html.

Thanks for your reply.

Sorry, I should probably have added a bit more information.

In fact I installed python and sympy in a read-write location on my machine: c:\PythonSystem. I also have a copy, so if I were to corrupt the library, I could just copy the whole thing back again to reset it. I noticed that if I generate an exception, the system references those source files, for example:

 File "C:\PythonSystem\lib\site-packages\sympy\combinatorics\partitions.py", line 233, in RGS
    partition = self.partition

Etc etc

Given that, what else do I need to do to compile my modified source?

David

Aaron Meurer

unread,
Aug 27, 2019, 11:50:13 AM8/27/19
to sympy
You don't have to do anything. Python compiles .py files automatically.

If you are doing this, however, I would recommend getting the git
source code, and modifying that. The reason is that git makes it much
easier to reset your changes. If you run Python from the directory of
the git checkout, it will import SymPy from there instead of from the
installed version.

Aaron Meurer
> --
> 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 sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/bdb6b08a-fed7-1237-0eb2-066a82df0c90%40dbailey.co.uk.

Aaron Meurer

unread,
Aug 27, 2019, 11:56:21 AM8/27/19
to sympy
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
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/95f2dab1-446c-4196-9363-b51de7ed44e1%40googlegroups.com.

David Bailey

unread,
Aug 27, 2019, 12:47:08 PM8/27/19
to sy...@googlegroups.com
On 27/08/2019 16:49, Aaron Meurer wrote:
You don't have to do anything. Python compiles .py files automatically.

This is what I originally suspected, and I have now confirmed it by putting a deliberate error in the source file and observing it stumble over that.

Strangely adding a line

print("Testing\n")

(suitably indented)

didn't work - but possibly there are reasons why print doesn't output from within sympy.

Thanks for your help,

David

Chris Smith

unread,
Aug 29, 2019, 8:02:06 AM8/29/19
to sympy
Currently it returns NotImplemented. Were you thinking EmptySet returns (oo, -oo) for (inf, sup)?

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.

Aaron Meurer

unread,
Aug 29, 2019, 2:26:22 PM8/29/19
to sympy
On Thu, Aug 29, 2019 at 6:02 AM Chris Smith <smi...@gmail.com> 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
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/dc79e5a0-a782-42f2-8220-e110191e2b5f%40googlegroups.com.

Chris Smith

unread,
Aug 30, 2019, 7:28:31 AM8/30/19
to sympy
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

Aaron Meurer

unread,
Aug 30, 2019, 12:12:05 PM8/30/19
to sympy
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
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/53fd30ac-04e5-4f07-83dc-a42f67eef1a8%40googlegroups.com.

Chris Smith

unread,
Aug 30, 2019, 1:42:25 PM8/30/19
to sympy
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

Aaron Meurer

unread,
Aug 30, 2019, 1:54:24 PM8/30/19
to sympy
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
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/28c4f33e-d098-43b5-800d-e59ea7d1ee83%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages