Re: Issue 1823 in sympy: integral.atoms(Symbol) should introspect

Do we even need bound_symbols? I think it can be useful for checking what can be done with an expression, for example if it is desired to manipulate an expression like this: n*Sum(x**n, (n, 0, oo)) = n*Sum(x**m, (m, 0, oo)) = Sum(n*x**m, (m, 0, oo)) If a symbol is present in both free and

Re: Issue 1823 in sympy: integral.atoms(Symbol) should introspect

Do we even need bound_symbols? I think it can be useful for checking what can be done with an expression, for example if it is desired to manipulate an expression like this: n*Sum(x**n, (n, 0, oo)) = n*Sum(x**m, (m, 0, oo)) = Sum(n*x**m, (m, 0, oo)) If a symbol is present in both free and

Re: please review Øyvind GSoC code

I am really happy to see the fruit of my gsoc landing in the master branch. Thanks to all who have been involved! Ondrej, could you rebuild the documentation in http://certik.github.com/sympy ? Øyvind on., 29.09.2010 kl. 11.19 -0700, skrev Ondrej Certik: Thanks Andy! Ondrej On Wed,

Re: var and symbols

ti., 17.08.2010 kl. 01.14 -0600, skrev Aaron S. Meurer: Well, here's the problem with the spaceless option: var('ab cd ef') (ab, cd, ef) var('ab cd') (ab, cd) var('ab') (a, b) This one has bitten me many times. It would be great to make it more consistent. Øyvind So definitely

Re: C code generator and much improved contraction logic

/second_review_round Øyvind On 28 Jul, 23:52, Øyvind Jensen jensen.oyv...@gmail.com wrote: On 27 Jul, 19:07, Brian Granger elliso...@gmail.com wrote: Oyvind, I don't know if you saw the new operator priority stuff that I did this weekend.  This will make it possible to more reliably have Expr

Re: C code generator and much improved contraction logic

Thanks for your comments everybody! When you are finished reviewing, please remember to push the button in smartbear so that we move on to the next phase. Øyvind On 28 Jul, 08:19, Ondrej Certik ond...@certik.cz wrote: On Tue, Jul 27, 2010 at 9:11 AM, Andy Ray Terrel andy.ter...@gmail.com

Re: C code generator and much improved contraction logic

just create an issue and do it later when things have stabilized. Øyvind Cheers, Brian On Mon, Jul 26, 2010 at 1:36 PM, Øyvind Jensen jensen.oyv...@gmail.comwrote: I have uploaded my work on the C code printer, C code generator and the tensor module to smartbear for review: http

C code generator and much improved contraction logic

I have uploaded my work on the C code printer, C code generator and the tensor module to smartbear for review: http://hosted.smartbear.com/sympy/go?page=ReviewDisplayreviewid=6 The ability to create code that loops over array arguments is much improved, mainly because the contraction logic is

Re: codegen stuff

Thanks, I'll fix it very soon. Øyvind On 9 Jul, 23:51, certik1 cert...@llnl.gov wrote: Hi, the new patches about codegen are awesome, as well as Tuple and so on. Great job! Ondrej P.S. I tried to compile on my rhel5 box and got some easy to fix things for python2.4.

Re: fortran code generator reviewing

Hi Toon, Thanks for your patches/suggestions and for looking over my work! lø., 10.07.2010 kl. 09.09 +0200, skrev Toon Verstraelen: Hi, I've been looking into the fcode and codegen implementation. Sorry for the delay. First of all: I'm really happy with the work being done. I wish I

Re: Lambdify namespace order bugfix

ma., 05.07.2010 kl. 10.08 -0700, skrev Ondrej Certik: On Mon, Jul 5, 2010 at 5:16 AM, Øyvind Jensen jensen.oyv...@gmail.com wrote: On 4 Jul, 19:54, Ondrej Certik ond...@certik.cz wrote: On Sun, Jul 4, 2010 at 10:45 AM, Aaron S. Meurer asmeu...@gmail.com wrote: Oops, you are right

Re: Hilbert Space Review

to., 01.07.2010 kl. 12.28 -0500, skrev Brian Granger: On Tue, Jun 29, 2010 at 5:10 PM, Øyvind Jensen jensen.oyv...@gmail.com wrote: ti., 29.06.2010 kl. 11.26 -0700, skrev Matt Curry: Hello, I've been working on implementing Hilbert spaces in SymPy. I have created/improved two files

Re: Hilbert Space Review

I get some failing tests: __ /home/oy/git_workingdir/sympy/sympy/physics/tests/ test_hilbert.py ___ File /home/oy/git_workingdir/sympy/sympy/physics/tests/ test_hilbert.py, line 1, in module from

Re: Hilbert Space Review

  File /home/oy/git_workingdir/sympy/sympy/physics/hilbert.py, line 267     obj = Expr.__new__(cls, *args, commutative=False)                                              ^ SyntaxError: invalid syntax The syntax error is because I have python 2.5 installed. The following line is compatible

Re: Hilbert Space Review

on., 30.06.2010 kl. 12.05 -0700, skrev Matt Curry: Okay, I've fixed up a few more things you've mentioned and pushed it to github. Cool. I just finished commenting on github http://github.com/mattcurry/sympy/commit/8e63d9d62bca475bcd6e6ee711e166cb6fbe In general it looks very good: It's

Re: Hilbert Space Review

ti., 29.06.2010 kl. 11.26 -0700, skrev Matt Curry: Hello, I've been working on implementing Hilbert spaces in SymPy. I have created/improved two files located on my github account: hilbert.py: http://github.com/mattcurry/sympy/blob/hilbert/sympy/physics/hilbert.py test_hilbert.py:

Re: [PATCH 2/4] Implemented optional free-form source format for Fortran code printer

ti., 15.06.2010 kl. 00.04 +0200, skrev Vinzent Steinberg: What about updating the docstring? It is updated: @@ -309,6 +346,8 @@ def fcode(expr, **settings): some parameter statements for the number symbols. If False, the same information is

Re: Created codegenerator FCodeGen for generating compilable fortran code

On 9 Jun, 23:03, Andy Ray Terrel andy.ter...@gmail.com wrote: Instead of creating new branches every time you update your repo I suggest using stgit [0].  You should be careful though because you can mess up and overwrite things, but as long as you are the person pulling and pushing to your

Re: Fix issue 1920: SymTuple doesn't rebuild itself

I think I could make good use of SymTuples for code generation with array arguments, and I believe we did reach a conclusion above, so I rebased the patch to current master and created another patch moving SymTuple into the core. They are both in the branch

[PATCH 1/4] move function wrap_fortran() to FCodePrinter._wrap_fortran()

This will let the line wrapping function respect settings of the fortran printer. --- sympy/printing/fcode.py| 107 ++-- sympy/printing/tests/test_fcode.py |5 +- 2 files changed, 56 insertions(+), 56 deletions(-) diff --git

[PATCH 4/4] Created codegenerator FCodeGen for generating compilable fortran code

Implemented tests of the generated strings, and a script in test_external/ to test resulting binaries. The existing CCodeGen and related tests was used as templates for the new functionality. --- sympy/test_external/test_codegen_f95_ifort.py | 240 sympy/utilities/codegen.py

[PATCH 2/4] Implemented optional free-form source format for Fortran code printer

fcode takes a new keyword: source_format='fixed'|'free' --- sympy/printing/fcode.py| 71 sympy/printing/tests/test_fcode.py |6 ++-- 2 files changed, 58 insertions(+), 19 deletions(-) diff --git a/sympy/printing/fcode.py

Re: review request

ti., 11.05.2010 kl. 02.36 -0700, skrev smichr: As I already said, it would be much easier if you could create another branch for review (1766-for-review) which contains only stable changes. This would help to get it in faster. The commits before 1766-- are stable. I

Re: [PATCH] Fix missing brackets in latex output of (-1)**x

I pushed it to the branch fix_latex ti., 04.05.2010 kl. 15.09 -0700, skrev Ondrej Certik: +1, is it in your branch somewhere? Ondrej OnMon, May 3, 2010 at 3:32 AM, Øyvind Jensen jensen.oyv...@gmail.com wrote: Before: -1^{x} Now: \left(-1\right)^{x} Added a test

Re: [PATCH] Fix missing brackets in latex output of (-1)**x

Well, Jeger means hunter and it is more of a joke, really... From the good old days ;-) on., 05.05.2010 kl. 13.02 -0700, skrev Ondrej Certik: On Wed, May 5, 2010 at 12:40 PM, Øyvind Jensen jensen.oyv...@gmail.com wrote: I cannot figure out how to fork that repo. Thought there should

[PATCH] Fix missing brackets in latex output of (-1)**x

Before: -1^{x} Now: \left(-1\right)^{x} Added a test --- sympy/printing/latex.py|3 ++- sympy/printing/tests/test_latex.py |3 +++ 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/sympy/printing/latex.py b/sympy/printing/latex.py index

[PATCH] Fix issue 1920: SymTuple doesn't rebuild itself

SymTuple did not fulfill foo.func(*foo.args) == foo. This patch fixes that by storing the wrapped tuple as .args[0] instead of directly as .args Updated all SymTuple methods, added a test and fixed some whitespace. --- sympy/physics/secondquant.py| 35

[PATCH] Fix for Issue 1920: Now SymTuple.func(*SymTuple.args) work as expected.

Added a test and fixed some related whitespace errors. --- sympy/physics/secondquant.py| 20 +--- sympy/physics/tests/test_secondquant.py |9 + 2 files changed, 10 insertions(+), 19 deletions(-) diff --git a/sympy/physics/secondquant.py

Re: [PATCH 2/2] Added method Dummy.as_nondummy()

., 05.04.2010 kl. 00.06 +0200, skrev Vinzent Steinberg: 2010/3/31 Øyvind Jensen jensen.oyv...@gmail.com: In situations where it is natural to generate dummy symbols with Symbol.as_dummy(), the reverse process may also be useful. Uncommented two tests for this. --- sympy/core/symbol.py

[PATCH 2/2] Added method Dummy.as_nondummy()

In situations where it is natural to generate dummy symbols with Symbol.as_dummy(), the reverse process may also be useful. Uncommented two tests for this. --- sympy/core/symbol.py| 11 +++ sympy/core/tests/test_symbol.py |4 ++-- 2 files changed, 13 insertions(+), 2

Re: [PATCH] Fix Basic.__lt__() and friends for noncommutative symbols (issue 1878)

I think he meant to put commutative=False, not noncommutative=True. Exactly, I put up another branch fix__lt__2, where this is fixed. It's weird that Symbol will let you create nonexistent assumptions on it: But that can be quite useful: In [4]: r = Symbol('r',something=True) In [5]:

[PATCH] Fix Basic.__lt__() and friends for noncommutative symbols (issue 1878)

All comparisons of for non-commutative symbols used to return False. Now an Inequality or StrictInequality is returned instead. Added a test. --- sympy/core/basic.py| 12 +--- sympy/core/tests/test_basic.py |8 2 files changed, 13 insertions(+), 7 deletions(-)

Re: [PATCH] refine: Let refine_Pow work harder to simplify powers of (-1)

Great suggestions! I'll create a new patch. Øyvind ma., 22.02.2010 kl. 14.13 -0700, skrev Aaron S. Meurer: On Feb 22, 2010, at 12:43 PM, Øyvind Jensen wrote: Before, 'refine_Pow' would simplify (-1)**exp only if 'exp' as a whole couold be determined as even or odd. A doctest like

[PATCH] refine: Let refine_Pow work harder to simplify powers of (-1)

Before, 'refine_Pow' would simplify (-1)**exp only if 'exp' as a whole could be determined as even or odd. A doctest like, refine_Pow((-1)**(x+y), Assume(x, Q.even)) (-1)**y would fail. This patch fixes that by treating powers of S.NegativeOne as a special case. Every term in

[PATCH] Fix resolutor consistency check in ask()

An exception could be raised as a false positive. We should only demand consistency between two resolutors if they have both reached a conclusion. Before this patch, an exception would be raised in the event of an inconclusive resolutor following a conclusive. Added a test for the issue ---

Re: [PATCH] Fix resolutor consistency check in ask()

Sorry, I sent the wrong patch. Please consider the next email instead. Øyvind ti., 23.02.2010 kl. 20.23 +0100, skrev Øyvind Jensen: An exception could be raised as a false positive. We should only demand consistency between two resolutors if they have both reached a conclusion. Before

[PATCH] Fix resolutor consistency check in ask()

An exception could be raised as a false positive. We should only demand consistency between two resolutors if they have both reached a conclusion. Before this patch, an exception would be raised in the event of an inconclusive resolutor following a conclusive. Added a test for the issue ---

[PATCH] refine: Let refine_Pow work harder to simplify powers of (-1)

Before, 'refine_Pow' would simplify (-1)**exp only if 'exp' as a whole couold be determined as even or odd. A doctest like, refine_Pow((-1)**(x+y), Assume(x, Q.even)) (-1)**y would fail. This patch fixes that by treating powers of S.NegativeOne as a special case. Every term

Re: [PATCH 6/6] Make substitute_dummies() more flexible and controllable w.r.t. output

sø., 21.02.2010 kl. 13.25 +0100, skrev Vinzent Steinberg: 2010/2/21 Øyvind Jensen jensen.oyv...@gmail.com: The keyword pretty_indices used to be boolean, but is now a dict of lists containing letters to label the new dummy indices. This allows the user much better control over

[PATCH 1/6] Improved documentation for evaluate_deltas

--- sympy/physics/secondquant.py | 25 + 1 files changed, 13 insertions(+), 12 deletions(-) diff --git a/sympy/physics/secondquant.py b/sympy/physics/secondquant.py index edc9987..687bf9d 100644 --- a/sympy/physics/secondquant.py +++ b/sympy/physics/secondquant.py @@

[PATCH 2/6] Improved documentation of _sort_anticommuting_fermions() in secondquant.py

--- sympy/physics/secondquant.py |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sympy/physics/secondquant.py b/sympy/physics/secondquant.py index 687bf9d..b7ae493 100644 --- a/sympy/physics/secondquant.py +++ b/sympy/physics/secondquant.py @@ -2269,8 +2269,8 @@ def

[PATCH 5/6] substitute_dummies should also accept single term expressions.

--- sympy/physics/secondquant.py |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/sympy/physics/secondquant.py b/sympy/physics/secondquant.py index 858c222..6a5fa60 100644 --- a/sympy/physics/secondquant.py +++ b/sympy/physics/secondquant.py @@ -2666,8 +2666,10 @@ def

[PATCH 6/6] Make substitute_dummies() more flexible and controllable w.r.t. output

The keyword pretty_indices used to be boolean, but is now a dict of lists containing letters to label the new dummy indices. This allows the user much better control over the resulting expression. Docstring and doctests updated accordingly. --- sympy/physics/secondquant.py | 104

Re: Fix for doc formatting

Good, thanks. Øyvind sø., 06.12.2009 kl. 14.38 +0100, skrev Vinzent Steinberg: 2009/12/5 Øyvind Jensen jensen.oyv...@gmail.com: Another fix to .jacobian() docstring. Improved the layout a bit. No change in wording. Øyvind I felt free to change your patch a bit and to push

Re: Fix for doc formatting

Another fix to .jacobian() docstring. Improved the layout a bit. No change in wording. Øyvind -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patc...@googlegroups.com. To unsubscribe from this group,

Re: Second quantization with fermionic operators

, Øyvind Jensen jensen.oyv...@gmail.com wrote: The failed assertion XYZ should simply be removed. It fails because of the platform-dependent hash, and is not relevant any more. It used to be relevant when I tried to use the relation [[A,B],C] + [[C,A],B] + [[B,C],A] = 0

Re: Second quantization with fermionic operators

The failed assertion XYZ should simply be removed. It fails because of the platform-dependent hash, and is not relevant any more. It used to be relevant when I tried to use the relation [[A,B],C] + [[C,A],B] + [[B,C],A] = 0 to enforce a canonical nesting of commutators. I couldn't

Re: Second quantization with fermionic operators

to github, please pull. Ondrej, I fixed the 'str' variable as well. Øyvind On 15 Okt, 18:54, Brian Granger ellisonbg@gmail.com wrote: On Thu, Oct 15, 2009 at 2:26 AM, Øyvind Jensen jensen.oyv...@gmail.comwrote: Brian, thanks for your input! I will make

Re: Second quantization with fermionic operators

Brian, thanks for your input! I will make that Exception baseclass, and raise those NotImplementedErrors. I'll do it the coming weekend. I really like your idea of implementing the particle/hole stuff on a higher level, and creating algorithms independent of boson/fermi formalism. That is a

Re: Second quantization with fermionic operators

Nice! Here are patches for the quick and easy stuff. They can be applied to the branch you posted. I also noticed some other small issues, and they are corrected in the patches. 4) please use explicit imports in the example. Then it would be clear that the import: from

Re: Second quantization with fermionic operators

Yes, I am aware of that. Thanks for your patches, I'll try it and see where the bottleneck is. Btw in your first patch, you seem to have a bogus line (with kwargs), which is not used anywhere, unless I am missing something. Ondrej That was indeed an error. It is fixed in this new patch.

Re: Second quantization with fermionic operators

Thanks for your swift responses, I've got some comments: * In various places you use the variable str. This is dangerous as str is a builtin type (a string). Absolutely, It should be substituted immediately. * It is a little awkward to have the occupation #'s stored differently for bosons