1 Feb 2012 08:15

### Re: SymPy with generic Symbol proxies; python expression algebra

This is exciting news, I think. Those that know better how these
things should work will no doubt be responding. Thanks for contacting
SymPy!

--

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.


1 Feb 2012 21:18

### Re: SymPy with generic Symbol proxies; python expression algebra

Hi.

On Tue, Jan 31, 2012 at 4:38 PM, Nathan Rice
<nathan.alexander.rice@...> wrote:
> I am the author of elementwise (http://packages.python.org/
> elementwise/) and constraints (http://packages.python.org/
> constraintslib/).  These tools are similar to SymPy in their use of
> symbolic proxy objects to represent values that may be provided later
> (and to some degree in their target audience).

This is cool.  Where can I get the code for these projects? I didn't
with the code too).

>
> I'm getting in touch because:
>
> 1.) I'd like to get people on board with the idea of a standard symbol
> proxy.  The general case is basically doing anything with a symbol
> returns another symbol representing the resulting expression.  While
> you do this to some degree now, the way in which you've gone about it
> only allows you to use functions that return a wrapper object (Add,
> Pow, etc).  Anyone that wants to interact SymPy has to take and return
> these objects.  A much better scenario is to have and symbolic
> expressions that can be realized down to normal python code (and which
> can be generated in a general manner from ASTs).    This gives you
> full interoperability with regular Python code.

So I'm trying to understand exactly what you are suggesting here?  You
want to do the sort of thing that SymPy does where you can build up


1 Feb 2012 23:44

### Re: SymPy with generic Symbol proxies; python expression algebra

> On Tue, Jan 31, 2012 at 4:38 PM, Nathan Rice
> <nathan.alexander.rice@...> wrote:
>> I am the author of elementwise (http://packages.python.org/
>> elementwise/) and constraints (http://packages.python.org/
>> constraintslib/).  These tools are similar to SymPy in their use of
>> symbolic proxy objects to represent values that may be provided later
>> (and to some degree in their target audience).
>
> This is cool.  Where can I get the code for these projects? I didn't
> with the code too).

https://github.com/nathan-rice/Constraints
https://github.com/nathan-rice/Elementwise

>>
>> I'm getting in touch because:
>>
>> 1.) I'd like to get people on board with the idea of a standard symbol
>> proxy.  The general case is basically doing anything with a symbol
>> returns another symbol representing the resulting expression.  While
>> you do this to some degree now, the way in which you've gone about it
>> only allows you to use functions that return a wrapper object (Add,
>> Pow, etc).  Anyone that wants to interact SymPy has to take and return
>> these objects.  A much better scenario is to have and symbolic
>> expressions that can be realized down to normal python code (and which
>> can be generated in a general manner from ASTs).    This gives you
>> full interoperability with regular Python code.


2 Feb 2012 00:31

### Re: SymPy with generic Symbol proxies; python expression algebra

On Wed, Feb 1, 2012 at 3:44 PM, Nathan Rice
<nathan.alexander.rice@...> wrote:
>> On Tue, Jan 31, 2012 at 4:38 PM, Nathan Rice
>> <nathan.alexander.rice@...> wrote:
>>> I am the author of elementwise (http://packages.python.org/
>>> elementwise/) and constraints (http://packages.python.org/
>>> constraintslib/).  These tools are similar to SymPy in their use of
>>> symbolic proxy objects to represent values that may be provided later
>>> (and to some degree in their target audience).
>>
>> This is cool.  Where can I get the code for these projects? I didn't
>> with the code too).
>
>
> https://github.com/nathan-rice/Constraints
> https://github.com/nathan-rice/Elementwise

Cool.  So you are basically letting Python do the work by putting
everything in lambdas (or is it nested lambdas?).  SymPy builds things
up in it's own proxy objects, which has advantages (e.g., we can
easily print the object as it was built). I'm sure there are
advantages to just using Python closures, though I can't think of them
now (perhaps more space efficient, and simpler code?).

>
>>>
>>> I'm getting in touch because:
>>>


2 Feb 2012 01:05

### Re: SymPy with generic Symbol proxies; python expression algebra

Am 02.02.2012 00:31, schrieb Aaron Meurer:
> Cool.  So you are basically letting Python do the work by putting
> everything in lambdas (or is it nested lambdas?).  SymPy builds things
> up in it's own proxy objects, which has advantages (e.g., we can
> easily print the object as it was built).

I may be displaying my Pythonic ignorance showing here, but wouldn't it
be possible to change the print function for these lambdas?
Alternatively, the proxies could be made into Callables by attaching the
proper function stuff.

As far as I understand Python, both variants should work equally well
from the interpreter's point of view, so we'd be free to choose either
route.

I have to admit I don't have a good idea about the gap between Nathan's
propsal and current SymPy code, so YMMV.
Just my 2 cents

--

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.


2 Feb 2012 03:32

### Re: SymPy with generic Symbol proxies; python expression algebra

> Cool.  So you are basically letting Python do the work by putting
> everything in lambdas (or is it nested lambdas?).  SymPy builds things
> up in it's own proxy objects, which has advantages (e.g., we can
> easily print the object as it was built). I'm sure there are
> advantages to just using Python closures, though I can't think of them
> now (perhaps more space efficient, and simpler code?).

Depends on whether you're talking about elementwise or constraints.
Constraints basically converts everything to a one argument callable,
so that you can evaluate each expression in the context of an input
value.  Elementwise uses lambdas to put off dereferencing variables
until the last possible moment, and to get around the fact that
standard generators are one shot items.

Also, note that  <at> chainable does some magic :)  Every operation returns
a new proxy, so I can store whatever I need.  Currently I only store
the "state" (via closure) and a parent reference, but rather than
building state, I could just store (operation, [arguments]).  There
are a few downsides to that from my perspective:

1.) All arguments are evaluated immediately
2.) You lose the nice ability to "swap" variables in the closure.
3.) You are going to have to generate the "compiled" python expression
eventually anyhow

The main advantage of the (function, [arguments]) tuple is that it
lets you defer "compiling" the expression into python, so if you want
to go back and replace all __add__ calls with __wackyadd__ later on,
you can do that easily.  You could achieve the same behavior with the
benefits of closures by having a "func" variable in the closure that


2 Feb 2012 11:14

### should Float allow high precision output from a low precision input?

In some discussion regarding changes to Float that are part of pull #
998 ( https://github.com/sympy/sympy/pull/998 ), the question of
whether to allow a high precision Float to be made from a low
precision float has arisen.

e.g. in my branch, Float(.3, 20) is disallowed since at face value one
might expect this to produce 0.30000000000000000000, but it doesn't.
It produced (in master) the 20 decimal digits that represent the
floating point approximation of 3/10: 0.29999999999999998890. So, like
Decimal (see below), I would prefer to disallow creation of high-
precision floats from low-precision input. In this case, an error
would be raised in my branch:

>>> Float(.3,20)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "sympy\core\numbers.py", line 529, in __new__
raise ValueError('float has insufficient precision; send as
Float("%s", %s)?
' % (num, dps))
ValueError: float has insufficient precision; send as Float("0.3",
20)?

In order to obtain that high precision value of the *floating point
representation* of 0.3, evalf would have to be used:  Float(.
3).evalf(20). To obtain a high-precision value of 0.3 one would send
(as suggested by the error message) the 0.3 in a string: Float("0.3",
20) will give a 0.3 followed by 19 zeros.

In practice, here are 3 different ways one might try to get 21 digits


2 Feb 2012 17:57

### Test modules

How do I run the tests for just one module (in my case the tests for
geometric algebra)?

--

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.


2 Feb 2012 18:21

### Re: Test modules

You can use bin/test <somestring> and it'll match <somestring> to
filenames and run only those tests. So, in your case, "bin/test
galgebra" will do fine.

On Thu, Feb 2, 2012 at 5:57 PM, Alan Bromborsky <abrombo@...> wrote:
> How do I run the tests for just one module (in my case the tests for
> geometric algebra)?
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@...
> To unsubscribe from this group, send email to
> sympy+unsubscribe@...
> For more options, visit this group at
>

--

--

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.


2 Feb 2012 18:22

### Re: Test modules

Am 02.02.2012 17:57, schrieb Alan Bromborsky:
> How do I run the tests for just one module (in my case the tests for
> geometric algebra)?

bin/test name-of-module

Any part of the filename will do, the tester will run any files with a
matching name.
At worst, you'll run more tests than you intended, but the full names of
the tests are printed so you can be more precise on the next run.

--

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.



Gmane