Chris Smith | 1 Feb 08:15 2012
Picon

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.

Aaron Meurer | 1 Feb 21:18 2012
Picon

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
see any download links (I know I can pip install, but I want to play
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
(Continue reading)

Nathan Rice | 1 Feb 23:44 2012
Picon

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
> see any download links (I know I can pip install, but I want to play
> with the code too).

My bad:

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.
(Continue reading)

Aaron Meurer | 2 Feb 00:31 2012
Picon

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
>> see any download links (I know I can pip install, but I want to play
>> with the code too).
>
> My bad:
>
> 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:
>>>
(Continue reading)

Joachim Durchholz | 2 Feb 01:05 2012

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.

Nathan Rice | 2 Feb 03:32 2012
Picon

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
(Continue reading)

smichr | 2 Feb 11:14 2012
Picon

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
(Continue reading)

Alan Bromborsky | 2 Feb 17:57 2012
Picon
Picon

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.

Vladimir Perić | 2 Feb 18:21 2012
Picon

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
> http://groups.google.com/group/sympy?hl=en.
>

-- 
Vladimir Perić

--

-- 
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.

Joachim Durchholz | 2 Feb 18:22 2012

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