Sure I will get to this soon.
Brian
On Thu, Mar 24, 2011 at 9:59 PM, smichr wrote:
> Can someone (Brian?) review the [ https://github.com/sympy/sympy/pull/125
> ] and [ https://github.com/sympy/sympy/pull/128 ]? These have had no
> comments in 2 weeks. I'm happy to commit them but am not the bes
ive. Otherwise, try to do better in the future. You will be
>> cursing yourself later when you go back to fix a bug and can't tell what a
>> commit did because the only description given is "Fixed stuff."
>>
>> Basically, if you are going to have a rebase-fre
On Tue, Aug 17, 2010 at 12:06 PM, Vinzent Steinberg
wrote:
> 2010/8/17 Brian Granger :
>> On Tue, Aug 17, 2010 at 9:23 AM, Christian Muise
>> wrote:
>>> One thing that was pressed on me was the desire to have every commit run
>>> clean. Regardless of what point
On Tue, Aug 17, 2010 at 11:13 AM, Aaron S. Meurer wrote:
>
> On Aug 17, 2010, at 11:07 AM, Brian Granger wrote:
>
>> On Tue, Aug 17, 2010 at 9:23 AM, Christian Muise
>> wrote:
>>> One thing that was pressed on me was the desire to have every commit run
>>
On Tue, Aug 17, 2010 at 9:23 AM, Christian Muise
wrote:
> One thing that was pressed on me was the desire to have every commit run
> clean. Regardless of what point in the commit history, all tests should
> work, or at the very least the system should install (broken imports could
> alter this).
On Wed, Aug 11, 2010 at 3:35 PM, Ondrej Certik wrote:
> On Wed, Aug 11, 2010 at 3:33 PM, Ondrej Certik wrote:
> > Hi,
> >
> > I started implementing the energies, for the hydrogen atom first:
> >
> >
> http://github.com/certik/sympy/commit/a9d53910dd2f0bfe9fe3a25614f3586faaadded0
> >
> > no test
Ondrej,
I just looked through this and it looks great. Very nice. Once the base
quantum stuff is done, we can integrate it with the hydrogen.py stuff, so
that the following would work:
>>> s = HState(n, l, m)
>>> s
|nlm>
>>> represent(s, PositionBasis())
...your functions...
Looks great thoug
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 subclasses
that define their own binary special methods (__mul__, __add__, etc._) that
are always called based on priority of the class. This could be us
Ondrej,
Thanks! This will be a huge help to us.
Cheers,
Brian
On Tue, Jul 27, 2010 at 12:10 AM, Ondrej Certik wrote:
> On Sun, Jul 25, 2010 at 12:34 PM, Brian Granger
> wrote:
> > Hi,
> > Here is the final version of my binary operator priority branch:
> > http://gi
Hi,
Here is the final version of my binary operator priority branch:
http://github.com/ellisonbg/sympy/tree/priority
To address comments I have:
* Created a decorator @call_highest_priority that is in
sympy.core.decorators to encapsulate the logic.
* Added documentation and tests.
* On my syste
Matthew,
This looks nice. One comment about the naming of the __imp__ method.
The __foo__ naming convention with leading and trailing double "_"
tends to be reserved for Python itself. Also, is there a reason you
want to have double underscores to hide this method? I would prefer
to follow the
Vinzent,
Thanks for pushing this in!
Cheers,
Brian
On Sun, Jul 11, 2010 at 5:22 PM, Vinzent Steinberg
wrote:
> 2010/4/20 Addison Cugini :
>> Vincent,
>>
>> I added a tester method in test_expr.py for the patch and added the missing
>> functions.
>>
>> I can't get the document attribute to copy
On Mon, Jul 5, 2010 at 1:28 PM, Ronan Lamy wrote:
> Le lundi 05 juillet 2010 à 19:17 +0200, Øyvind Jensen a écrit :
>> > Yep. I just got back from SciPy and I talked a lot with one of the
>> > devs of theano:
>> >
>> > http://deeplearning.net/software/theano/
>>
>> Thanks for bringing theano to m
Øyvind,
On Fri, Jul 2, 2010 at 1:46 AM, Øyvind Jensen wrote:
> to., 01.07.2010 kl. 12.28 -0500, skrev Brian Granger:
>> On Tue, Jun 29, 2010 at 5:10 PM, Øyvind Jensen
>> wrote:
>> > ti., 29.06.2010 kl. 11.26 -0700, skrev Matt Curry:
>> >> Hello,
>>
On Tue, Jun 29, 2010 at 5:10 PM, Øyvind Jensen 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 located on my github account:
>>
>> hilbert.py:
>> http://github.com/mattcurry
Hi,
I was wondering if there was a reason this patch was not applied?
http://groups.google.com/group/sympy-patches/browse_thread/thread/e75a05616e1b5732
Cheers,
Brian
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
To post to this group, se
Hi,
I have put up a branch that fixes two things in the printers:
http://github.com/ellisonbg/sympy/tree/printer
* lambdify(Piecewise) now uses iff for Python 2.4 compat.
* I added printmethod = "_pretty_" to the pretty printer class to
allow types to declare how they can
be pretty printed.
Che
Thanks!
On Thu, Mar 25, 2010 at 10:41 AM, Ondrej Certik wrote:
> On Thu, Mar 25, 2010 at 9:34 AM, Brian Granger
> wrote:
>> Ondrej,
>>
>>> I just don't like the way you resolved them. Seems like you were
>>> merging branches, which both contained some
Ondrej,
> I just don't like the way you resolved them. Seems like you were
> merging branches, which both contained some of your patches and in
> general it was a big mess. I fixed all of that and pushed things here:
Yes, I think I know what happened and I am not surprised that I made a
mess. S
Ondrej,
> The tests seem to run fine. Only I'll try to rebase it, it will make
> it easier to review. There are some conflicts, that I'll try to fix.
I am a little surprised there were conflicts. I pulled from upstream
and resolved conflicts already (just tonight). They were in piecewise
and te
OK
I have fixed all the doctests and also merged from upstream, so my
branch should merge cleanly.
Cheers,
Brian
On Tue, Mar 23, 2010 at 11:30 AM, Brian Granger wrote:
> Darn, I will look into this...
>
> Brian
>
> On Mon, Mar 22, 2010 at 2:04 PM, Aaron S. Meurer wrote:
>&
gt; True
>
> Also, it would be nice if this explained that only numerical arguments are
> accepted, instead of just raising TypeError for int(x):
>
> In [8]: bspline_basis(y, range(6), 0, x)
> ---
> Ty
OK, I have addressed all review comments. My branch should be ready to merge.
Cheers,
Brian
On Thu, Mar 18, 2010 at 4:11 PM, Brian Granger wrote:
> I am going to try to get on this soon.
>
> Cheers,
>
> Brian
>
> On Fri, Mar 12, 2010 at 10:10 AM, Aaron S. Meurer wrote
I am going to try to get on this soon.
Cheers,
Brian
On Fri, Mar 12, 2010 at 10:10 AM, Aaron S. Meurer wrote:
> Seenu comment at github.
>
> Aaron Meurer
> Sent from my iPod touch.
> On Mar 10, 2010, at 4:08 PM, Brian Granger wrote:
>
> Hi,
>
> I have impro
Ondrej,
On Thu, Mar 11, 2010 at 11:59 AM, Ondrej Certik wrote:
> On Wed, Mar 10, 2010 at 11:14 PM, Priit Laes wrote:
> > Ühel kenal päeval, K, 2010-03-10 kell 15:08, kirjutas Brian Granger:
> >> Hi,
> >>
> >> I have improved the Piecewise class and impl
On Wed, Mar 10, 2010 at 11:14 PM, Priit Laes wrote:
> Ühel kenal päeval, K, 2010-03-10 kell 15:08, kirjutas Brian Granger:
> > Hi,
> >
> > I have improved the Piecewise class and implemented B-splines. Here
> > is the branch on github:
> >
> > http://githu
Hi,
I have improved the Piecewise class and implemented B-splines. Here is the
branch on github:
http://github.com/ellisonbg/sympy/tree/bg-piecewise
There are tests for everything I have added and docstrings/doctests. I
would love comments and feedback.
Cheers,
Brian
--
You received this m
t 2:21 PM, Ondrej Certik wrote:
> >
> >> On Tue, Mar 2, 2010 at 11:20 AM, Brian Granger
> wrote:
> >>> Hi,
> >>>
> >>> Here is a branch that fixes a number of issues with Relational and
> Interval:
> >>>
> >>> * Rel
Hi,
Here is a branch that fixes a number of issues with Relational and Interval:
* Relationals of numbers now evaluate immediately to a bool (Eq(0,0) ->
True)
* Intervals and other Sets will not raise a TypeError if Set.contains
returns a non bool.
This is to prevent Set.__contains__ (which cast
> > I would prefer if this would use the new assumptions system. Or should
> > 'above_fermi' etc. be tied to symbols? The rest of the patches looks
> > fine to me, assuming all tests pass.
>
>
I agree with this.
> I agree, that we should move to the new assumption system, but that does
> require
Great.
On Sat, Feb 20, 2010 at 3:11 PM, Øyvind Jensen wrote:
> ---
> 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/s
Looks good.
Brian
On Sat, Feb 20, 2010 at 3:11 PM, Øyvind Jensen wrote:
> ---
> sympy/physics/secondquant.py | 29 -
> 1 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/sympy/physics/secondquant.py b/sympy/physics/secondquant.py
> index 93f9ca3..85
Looks good.
On Sat, Feb 20, 2010 at 3:11 PM, Øyvind Jensen wrote:
> renamed the iterator '_reverse' to 'arg_iterator' for clarity
> ---
> sympy/physics/secondquant.py | 23 ++-
> 1 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/sympy/physics/secondquant.p
Looks good.
On Sat, Feb 20, 2010 at 3:11 PM, Øyvind Jensen wrote:
> ---
> 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 1006
Looks good.
On Sat, Feb 20, 2010 at 3:11 PM, Øyvind Jensen wrote:
> ---
> 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/physic
kerDelta(_p, _q) + KroneckerDelta(_i,
> > _r)*KroneckerDelta(_p, _r)
> >
> > = tests finished: 341 passed, 1 failed in 6.34 seconds
> =
> >
> >
> > So this has to be fixed. Rebased patches are in my "wick3" branch at
> github.
Then particle/holes would still
> be low-level, but completely encapsulated in FermionicOperator. What do
> you think?
>
>
I think I would love to think about this more today but I have a big
deadline at 5 pm ;-)
I will try to get back to this F, Sat or Sun.
Cheers,
Brian
> Øyvin
Thanks for putting a github branch up.
I am crazy busy, but I did glance though things a bit...
* Can you create a base class for all exceptions in secondquant, like
class SecondQuantError(Exception):
pass
and make all other exceptions subclasses of this.
* Also, what happens if you pass bos
On Wed, Oct 7, 2009 at 4:19 PM, Ondrej Certik wrote:
>
> On Wed, Oct 7, 2009 at 3:46 PM, Brian Granger
> wrote:
> > Øyvind,
> >
> > It will take me a while to go through everything, but I just read through
> > some of it quickly. It all looks quite
> >
Øyvind,
It will take me a while to go through everything, but I just read through
some of it quickly. It all looks quite
powerful and nice. One minor thing and one question:
* In various places you use the variable "str." This is dangerous as str is
a builtin type (a string).
* It is a little
Great! I haven't had a chance to work on this for about a year, but Ondrej
and I were just talking last week how it would be nice to push this forward
more.
I have implemented a framework for working with fermionic second
> quantization operators with Sympy and I'd like to submit patches for
> in
Fabian,
> Knowing it or not, you gave me the answer to a far more important
> problem !!. The problem of extensibility with respect to user-defined
> types (as opposed to extensibility with respect to user-defined queries)
Glad me idea helps - I wasn't sure it was appropriate for the queries,
bu
> Yes, this is a bug. Does anyone have an idea how to fix it? Maybe the
> handlers_dict.update should be our own method and it should raise an
> exception if one key is updated twice? E.g. one would first have to
> remove the key, then register it. Then the user will know that two
> packages use
> yes, that's one of the main reasons behind writing the module!.
Great!
> I'll show by example how to create a new query without touching any file
> in sympy's codebase :
>
> In [1]: from sympy.query import QueryHandler, handlers_dict
>
> In [2]: class AssociativeQueryHandler(QueryHandler):
>
> If there is an infinite recursion, then it's a bug, it should work
> nice. I think the problem is that _latex_ is not designed to be called
> directly. You should call Basic.__str__(), or just Printer.doprint().
> So if the notebook is calling _latex_, then it's just a coincidence,
> and we shou
>> It look like your patches will make it much easier for users to create
>> custom Sympy types that are on equal grounds as the built in ones. Is
>> this the case? If I create a new type, will I be able to implement
>> queries for that type and will I be able to tell the Sympy core about
>> my
Fabian,
Looks like very exciting work. I have a few questions about the new system...
One thing that really bothered me about the old .is_* syntax is that
it made it very difficult for users to create their own Sympy
subclasses and have them be true equals with the built-in Sympy types.
The re
Looks good
On Tue, Dec 9, 2008 at 9:23 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
> From: Brian E. Granger <[EMAIL PROTECTED]>
>
> ---
> setupegg.py |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
> create mode 100644 setupegg.py
>
> diff --git a/setupegg.py b/setupegg.py
>
very appealing.
On Fri, Nov 21, 2008 at 8:36 AM, Brian Granger <[EMAIL PROTECTED]> wrote:
>
> Ahhh, I didn't realize this problem was there.
>
>> I don't like this behavior. And I don't like that we need to use a
>> hack to fix it.
>
> Me neither, playin
Ahhh, I didn't realize this problem was there.
> I don't like this behavior. And I don't like that we need to use a
> hack to fix it.
Me neither, playing with the frames is messy stuff
> I think it's because we are misusing the **kw arguments. The kw
> arguments are meant to specify options to f
I am off to teach lab right now, but I will look this over later
today. Looks like a complication...
Brian
On Thu, Nov 20, 2008 at 10:10 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
> On Thu, Nov 20, 2008 at 5:00 PM, Lance Larsen <[EMAIL PROTECTED]> wrote:
>>
>> I haven't used frames before,
> This patch looks good to me. Brian -- is it ok with you as well?
As much as I can tell from looking at the diff, yes, it is OK. I say
go ahead, if we want to add the bindings thing later we can, but even
this is a nice improvement.
Brian
> Ondrej
>
> >
>
--~--~-~--~~
> No worries. I appreciate you clarifying your viewpoint. You may not
> like what you get if you don't give your opinion.
Thanks.
> I am imcluding the f({x:pi,y:4}) syntax because Ondrej is right about
> the limitations of the f(x=pi,y=4) syntax, and I think that this
> method of substitution ma
Lance,
Sorry if I am being a pain in the #%%, I just want to make sure that
we get the desig of this right as someone else said "you only get to
implement __call__ once". I do appreciate you willingness to do the
implementation of this and hear me out. A few things about this most
recent patch:
Sorry I have been so slow to follow this stuff up. This week has been
crazy with personal stuff...
> Fredrik noted that the second syntax suggested by Brian is already
> supported. Should we pursue a bindings method for the convenience
> factor, or the the current Lambda notation good enough?
>
> I also thought we agree to implement the .subs(x=something, y=sasd)
> syntax. Brian -- do you think it is too confusing to put this to subs?
> I find it not general enough, e.g. .subs(x=y**2) works, but
> .subs(y**2=x) doesn't, so one has to use dictionaries as the general
> syntax .subs({x: y**
This patch implements something quite different from what we had discussed:
* We never discussed changing the implementation of subs. I think
that is a separate discussion and it outside of the scope of changing
__call__. Personally, I think the syntax for subs is fine.
* I thought we decided
...please be patient with me - I am sympy newbie...
> The general idea is that all user input should be parsed using
> sympify. Once we are inside sympy, everything is a subclass of Basic
> (you can see the sympify calls in __add__, __mul__ and similar).
> So in particular all elements of .args[:
This is something that I have begun to run into. Ideally, the
attributes like is_Integer are there to make things faster (than using
isinstance). However, you can only safely use the is_* attributes if
you are sure than you have an object (subclass of Basic) that has
those attribute. But, to fi
_ccode_
etc.
Brian
On Nov 4, 7:20 pm, Sebastian <[EMAIL PROTECTED]> wrote:
> As Brian Granger proposed in the
> threadhttp://groups.google.com/group/sympy/browse_thread/thread/2927bac0810...
> , it would be preferable if user could define printing methods for their
> own classes
60 matches
Mail list logo
