>> First and foremost a vector field is a differential operator over
>> scalar fields. This is how it is defined.
>
> This is again due to implicit isomorphism. See
> http://planetmath.org/encyclopedia/VectorField.html (second paragraph
> on the section on manifolds).
>
I am not sure that we speak
On Tue, May 29, 2012 at 1:19 PM, krastanov.ste...@gmail.com
wrote:
>>>
Off topic: d_dx is the unit vector along x. It needs better name. (in
latex it is \frac{\part}{\part x})
>>>
>>> I'm rather confused by your explanations. You seem to alternate between
>>> describing it as a simple ve
On Tue, May 29, 2012 at 12:57 PM, Ronan Lamy wrote:
The absence of test failures only shows that a feature that didn't exist
wasn't used. As for special cases, I already mentioned the Expr vs Basic
thing (why is this implemented only for Expr, when callability is
unrelated to t
>>
>> IIUC, this is the "dequantised" version of X P, which is a perfectly
>> well-defined quantum operator. "Obviously", (x * d_dx)(f) should
>> return x * f'(x), but I see no way to make it work in your design.
>
> I noticed this too. It wouldn't really be possible to make an
> "operator of opera
>> I know that Lambdas can be used to do a lot of these things, but
>> Lambda is inherently crippled in that if you want to mainpulate the
>> expression in the Lambda at all, you have to peel off the Lambda
>> first. With this, you don't have to do any of that. You can even use
>> Lambdas if you
>>
>>> Off topic: d_dx is the unit vector along x. It needs better name. (in
>>> latex it is \frac{\part}{\part x})
>>
>> I'm rather confused by your explanations. You seem to alternate between
>> describing it as a simple vector (but in which space?) and a differential
>> operator. These seem to b
>>> The absence of test failures only shows that a feature that didn't exist
>>> wasn't used. As for special cases, I already mentioned the Expr vs Basic
>>> thing (why is this implemented only for Expr, when callability is
>>> unrelated to the concept of Expr?), but the special handling of Symbol
On May 29, 2012, at 12:10 PM, Ronan Lamy wrote:
> 2012/5/25 krastanov.ste...@gmail.com :
An example from the (upcoming) differential geometry module:
p is a point with x=a and y=b
rect is the Cartesian coordinate system
rect.x (y) are ScalarFields taking a point and
2012/5/25 krastanov.ste...@gmail.com :
>>> An example from the (upcoming) differential geometry module:
>>>
>>> p is a point with x=a and y=b
>>>
>>> rect is the Cartesian coordinate system
>>> rect.x (y) are ScalarFields taking a point and returning the x (y)
>>> coordinate
>>> polar is the polar
Am 25.05.2012 23:41, schrieb krastanov.ste...@gmail.com:
If you do that, you won't have any simple way of recognising
ScalarFields, or things-like-rect.d_dx (what do you call them?), which
seems rather inconvenient. Worse than that, objects like (rect.x *
rect.d_dx) cannot possibly work satisfact
On May 25, 2012, at 3:41 PM, "krastanov.ste...@gmail.com"
wrote:
>>> An example from the (upcoming) differential geometry module:
>>>
>>> p is a point with x=a and y=b
>>>
>>> rect is the Cartesian coordinate system
>>> rect.x (y) are ScalarFields taking a point and returning the x (y)
>>> coord
>> An example from the (upcoming) differential geometry module:
>>
>> p is a point with x=a and y=b
>>
>> rect is the Cartesian coordinate system
>> rect.x (y) are ScalarFields taking a point and returning the x (y) coordinate
>> polar is the polar coordinate system with r and theta as basis fields
Le mercredi 23 mai 2012 à 22:24 +0200, krastanov.ste...@gmail.com a
écrit :
> > I'd really like to see what the point of this is, because, for now, I'm
> > only seeing the complications caused by all the special cases and the
> > possibilities for unexpected interactions.
> >
>
> An example from t
> I'd really like to see what the point of this is, because, for now, I'm
> only seeing the complications caused by all the special cases and the
> possibilities for unexpected interactions.
>
An example from the (upcoming) differential geometry module:
p is a point with x=a and y=b
rect is the
Le samedi 19 mai 2012 à 17:53 +0200, krastanov.ste...@gmail.com a
écrit :
> Thanks, this discussion made many of the dark corners of sympy a bit
> less frightening for me. I will try to play around with some of the
> ideas/changes that were mentioned.
>
> Getting back to the issue from the first m
Thanks, this discussion made many of the dark corners of sympy a bit
less frightening for me. I will try to play around with some of the
ideas/changes that were mentioned.
Getting back to the issue from the first message: making Expr
recursively callable. I suppose that the way to see if we need t
Le vendredi 18 mai 2012 à 22:32 +0200, krastanov.ste...@gmail.com a
écrit :
> >> >>
> >> >>>
> >> >>> * What about function arity? If f = Lambda(x, x) and
> >> >>> g = Lambda((x, y), x+y), what is 1 + f + g?
> >> >> Quite seriously I would answer "Why should we care?". It would be nice
> >> >> to h
>> >>
>> >>>
>> >>> * What about function arity? If f = Lambda(x, x) and
>> >>> g = Lambda((x, y), x+y), what is 1 + f + g?
>> >> Quite seriously I would answer "Why should we care?". It would be nice
>> >> to have partial (lazy) evaluation, but even if we do not have it, this
>> >> would be consid
Le jeudi 17 mai 2012 à 22:33 +0200, krastanov.ste...@gmail.com a écrit :
> >>> * Why is this new behaviour limited to Expr? Callability and
> >>> existence of arithmetic operations are orthogonal concepts.
> >> I did not understand the question. A possible answer if I understand
> >> would be: The
>>> * Why is this new behaviour limited to Expr? Callability and
>>> existence of arithmetic operations are orthogonal concepts.
>> I did not understand the question. A possible answer if I understand
>> would be: The idea is to have an identity between "1 + function(arg ->
>> f(arg))" and "functio
On Thu, May 17, 2012 at 1:27 PM, krastanov.ste...@gmail.com
wrote:
>> I don't think it's a good idea.
>>
>> * This logically implies 1(x) == 1, which is surprising, to say the
>> least.
> I have no comment here as I do not see exactly what the problem is.
>
>>
>> * Consequently, this gives most ob
> I don't think it's a good idea.
>
> * This logically implies 1(x) == 1, which is surprising, to say the
> least.
I have no comment here as I do not see exactly what the problem is.
>
> * Consequently, this gives most objects a dual role as themselves and
> as a constant function returning themse
Le mardi 15 mai 2012 à 23:05 +0200, krastanov.ste...@gmail.com a écrit :
> In another discussion on the mailing list Ronan mentioned that Lambda
> should not subclass Expr. Here I was proposing just the opposite: have
> Function subclass Expr in order to have callable Expr.
>
> (1+f)(x) returning
I agree that that would be a better way. I think it's just that no one
has gotten around to modifying the parser yet. It would be nice to
fix, especially given the existence of subtle bugs like
http://code.google.com/p/sympy/issues/detail?id=1612. Making isympy
-a continue to work should not be di
Here it is
https://github.com/sympy/sympy/pull/1299
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more
OK, thanks for the correction! I will just make a special check for
symbols in my code. (however if it ever comes into discussion I will
probably vote against this feature (changing the parser and making
isympy -a catch the error seems nicer to me))
--
You received this message because you are su
> May I please remove this feature if the tests do not fail?
>
I think this is needed for sympification of strings. But perhaps there
is a better way to handle this.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to
On May 15, 2012, at 4:35 PM, "krastanov.ste...@gmail.com"
wrote:
> On 15 May 2012 23:32, Aaron Meurer wrote:
>> I had this idea before. See
>> http://code.google.com/p/sympy/issues/detail?id=2006.
>>
>> I have no idea how hard it would be to implement, but my guess is that
>> it wouldn't be easy
On 15 May 2012 23:32, Aaron Meurer wrote:
> I had this idea before. See
> http://code.google.com/p/sympy/issues/detail?id=2006.
>
> I have no idea how hard it would be to implement, but my guess is that
> it wouldn't be easy. But if you have an idea how to do it go ahead and
> give it a shot. I th
I had this idea before. See
http://code.google.com/p/sympy/issues/detail?id=2006.
I have no idea how hard it would be to implement, but my guess is that
it wouldn't be easy. But if you have an idea how to do it go ahead and
give it a shot. I think it would be really cool and very useful.
Aaron Me
In another discussion on the mailing list Ronan mentioned that Lambda
should not subclass Expr. Here I was proposing just the opposite: have
Function subclass Expr in order to have callable Expr.
(1+f)(x) returning 1+f(x)
and
(1+Lambda(a, 2*a))(x) returning 1+2*a
Any thoughts? For precedent check
31 matches
Mail list logo
