> 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**
"Lance -- so you propose to drop the .subs(old, new), and only use
this
syntax to substitute for positional arguments? -Ondrej"
Yes. My vote would be to drop the .subs(old new) syntax and have f
(...) behave the same as f.subs(...). That being said, I think this
really depends on how widely the
> Yes, and because it's the variable IMHO is the one the user should use. Also
> in the existing subs routine it works in this way, so it should work also with
> that new syntax. i.e: it would be confusing if this works
>
> In [4]: f.subs({x:3,t:9})
> Out[4]: 27
>
> and this not:
>
> In [5]: f(x=3
> ^^ why are you deleting the whitespace? I suggest to leave it as it was.
I looked at other comments and tried to make this fit the same pattern
(text starts immediately after """), but it doesn't really matter to
me how the whitespace is arranged.
> ^^^ why are you introducing the "Ignoring re
On Monday 17 November 2008 23:25:51 nnms wrote:
> > There is a problem:
> >
> > In [1]: t = Symbol("theta")
> >
> > In [2]: f = t*x
> >
> > In [3]: f(x=3,t=9)
> > Out[3]: 3⋅θ
>
> Not sure if this is a problem. Sympy knows about 'theta' but not about
>
> t. If you print f you get:
> >>> f
>
> theta
On Tue, Nov 18, 2008 at 12:25 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 18, 2008 at 12:00 AM, nnms <[EMAIL PROTECTED]> wrote:
>>
>> On Nov 17, 12:32 pm, "Brian Granger" <[EMAIL PROTECTED]> wrote:
>>> This patch implements something quite different from what we had discussed:
>>
>>
On Tue, Nov 18, 2008 at 12:00 AM, nnms <[EMAIL PROTECTED]> wrote:
>
> On Nov 17, 12:32 pm, "Brian Granger" <[EMAIL PROTECTED]> wrote:
>> This patch implements something quite different from what we had discussed:
>
> Hi Brian,
>
> The implementation I submitted was the implementation I suggested i
Also I forgot (feel free to fix it after we discuss the other things):
>> # HG changeset patch
>> # User Lance Larsen
Please add your name and email address to your .hgrc (or something
similar on windows), see the other patches's authors.
>> # Date 1226946818 25200
>> # Node ID 35c17486e4205095
On Mon, Nov 17, 2008 at 8:04 PM, Lance Larsen <[EMAIL PROTECTED]> wrote:
>
> Here is the patch for the implicit subs call syntax (i.e. f(x=1, y=2)
> vs. f.subs({x:1,y:2}) ). I changed the behavior of the __call__ method
> in the Basic class, but this did not seem to affect any test cases. If
> thi
On Nov 17, 12:32 pm, "Brian Granger" <[EMAIL PROTECTED]> wrote:
> This patch implements something quite different from what we had discussed:
Hi Brian,
The implementation I submitted was the implementation I suggested in
my original post.
> * We never discussed changing the implementation of su
> There is a problem:
>
> In [1]: t = Symbol("theta")
>
> In [2]: f = t*x
>
> In [3]: f(x=3,t=9)
> Out[3]: 3⋅θ
Not sure if this is a problem. Sympy knows about 'theta' but not about
t. If you print f you get:
>>> f
theta*x
>>> f(x=3, theta=9)
27
't' is the python variable name assigned, but 'th
Some more comments.
It would be nice to do something with the str method to get better
printing, right now I get:
In [44]: C
Out[44]: ()
Also it would be good to catch vectors and handle them, right now I'm getting
In [52]: line_integrate([x**2,y**2], C, [x,y])
Out[52]: [pi, pi]
But I believe
On Mon, Nov 17, 2008 at 10:03 PM, Andy R. Terrel <[EMAIL PROTECTED]> wrote:
>
> From cff3ce1c8551d2ecf4a79393d3ee236b0c1156f3 Mon Sep 17 00:00:00 2001
> From: Priit Laes <[EMAIL PROTECTED]>
> Date: Mon, 17 Nov 2008 22:39:23 +0200
> Subject: [PATCH] Raw implementation for line integrals.
>
> ---
>
On Monday 17 November 2008 20:04:25 Lance Larsen wrote:
> Here is the patch for the implicit subs call syntax (i.e. f(x=1, y=2)
> vs. f.subs({x:1,y:2}) ). I changed the behavior of the __call__ method
> in the Basic class, but this did not seem to affect any test cases. If
> this causes a problem,
First thing I would say is we need to add a test for each additional
feature. And adding a docstring as well.
Otherwise +1
On Nov 17, 10:03 pm, "Andy R. Terrel" <[EMAIL PROTECTED]> wrote:
> From cff3ce1c8551d2ecf4a79393d3ee236b0c1156f3 Mon Sep 17 00:00:00 2001
> From: Priit Laes <[EMAIL PROTEC
>From cff3ce1c8551d2ecf4a79393d3ee236b0c1156f3 Mon Sep 17 00:00:00 2001
From: Priit Laes <[EMAIL PROTECTED]>
Date: Mon, 17 Nov 2008 22:39:23 +0200
Subject: [PATCH] Raw implementation for line integrals.
---
sympy/geometry/__init__.py |3 ++-
sympy/geometry/curve.py | 34
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
Here is the patch for the implicit subs call syntax (i.e. f(x=1, y=2)
vs. f.subs({x:1,y:2}) ). I changed the behavior of the __call__ method
in the Basic class, but this did not seem to affect any test cases. If
this causes a problem, the __call__ can be modified to behave as
before if a *arg valu
18 matches
Mail list logo
