On Saturday, August 20, 2016 at 6:13:16 AM UTC-7, Eric Gourgoulhon wrote:
>
>
>
>> I'd be hesitant to go any further. Using leibnitz notation in general
>> requires temporary variables, e.g.
>>
>> D[0,1](f)(x+y,x-y) = diff(f(t1,t2),t1,t2) |_[t1=x+y,t2=x-y]
>>
>> I don't think the RHS is more rea
On 20 August 2016 at 08:54, Bill Page wrote:
>
> If Sage supported a standard ASCII-art 2-d output format for
> expressions, then perhaps another choice would be suitable.
>
Perhaps I should have said "unicode-art" 2-d output. I noticed that in
--notebook=jupyter Sympy does thiis
import sympy
sy
Le vendredi 19 août 2016 20:24:24 UTC+2, Nils Bruin a écrit :
>
>
> Personally, I'm comfortable with the basic representation choices made in
> https://trac.sagemath.org/ticket/21286 .
>
Thanks for this ticket.
> I'd be hesitant to go any further. Using leibnitz notation in general
> require
On 19 August 2016 at 18:30, Bill Page wrote:
> ...
> Probably the only way to make a sufficient number of people happy
> enough to get a positive review on this ticket would be to implement
> several major alternative notations for derivatives and an easy way to
> switch between them. Then the onl
On 20 August 2016 at 08:14, Eric Gourgoulhon wrote:
> Le jeudi 18 août 2016 07:59:15 UTC+2, Nils Bruin a écrit :
>>
>> The situation for topological manifolds is slightly different, because
>> expressions there live in the context of a chart, where a specific
>> correspondence between variable nam
Hi,
Le jeudi 18 août 2016 07:59:15 UTC+2, Nils Bruin a écrit :
>
>
> The situation for topological manifolds is slightly different, because
> expressions there live in the context of a chart, where a specific
> correspondence between variable name and parameter position has been
> imposed. That
On 19 August 2016 at 14:24, Nils Bruin wrote:
> On Friday, August 19, 2016 at 9:45:12 AM UTC-7, Bill Page wrote:
>>
>> My main question is whether we should try to replicate what is done
>> by ExpressionNice and thereby render it obsolete or should we try
>> to reach some other compromise?
>
> Wel
On Friday, August 19, 2016 at 9:45:12 AM UTC-7, Bill Page wrote:
>
> On the contrary after reading the code for ExpressionNice carefully it
> is clear that it does not do post-processing as such
class ExpressionNice(Expression):
def _repr_(self):
d = self._pare
On the contrary after reading the code for ExpressionNice carefully it
is clear that it does not do post-processing as such and should be
quite general and robust. However that said, I am very much in favor
of using the approach you demonstrated in
https://trac.sagemath.org/ticket/21286
My main
On Thursday, August 18, 2016 at 5:32:09 AM UTC-7, Bill Page wrote:
>
> I think that there was no claim that it was unambiguous and therefore
> it implies that some ambiguity would be tolerated. But this has
> already been argued ad infinitum and apparently that has resulted in
> the current stal
ExpressionNice is a subclass of sage.symbolic.expression.Expression,
it seemed therefore that maybe I should be able to do something like:
sage: import sage.manifolds.utilities
sage: sage.symbolic.expression.Expression =
sage.manifolds.utilities.ExpressionNice
and expect all my expressions to be
On 18 August 2016 at 01:59, Nils Bruin wrote:
> On Wednesday, August 17, 2016 at 3:25:31 PM UTC-7, Bill Page wrote:
>>
>>
>> It turns out that a solution is now "hidden away" in plain sight:
>>
>> https://trac.sagemath.org/ticket/18640
>>
>> http://sagemanifolds.obspm.fr/doc/18640/reference/manifo
On Wednesday, August 17, 2016 at 3:25:31 PM UTC-7, Bill Page wrote:
>
>
> It turns out that a solution is now "hidden away" in plain sight:
>
> https://trac.sagemath.org/ticket/18640
>
> http://sagemanifolds.obspm.fr/doc/18640/reference/manifolds/sage/manifolds/utilities.html
>
>
>
And also not
13 matches
Mail list logo
