Sorry for shouting, but "batteries-included" monolithic monsters
don't work (certainly not long-term), in case of Sage it has become
increasingly obvious in the past ~10 years.
An illusion that it is sustainable has been, ironically, kept alive by
OpenDreamKit, where a number of people were full-t
2020-08-01 08:00:32 UTC, Dima Pasechnik:
>
> Sorry for shouting, but "batteries-included" monolithic monsters
> don't work (certainly not long-term), in case of Sage it has become
> increasingly obvious in the past ~10 years.
> An illusion that it is sustainable has been, ironically, kept alive by
Le samedi 1 août 2020 10:06:47 UTC+2, Emmanuel Charpentier a écrit :
>
> Consider :
>
> sage: f=function("f")
> sage: m=var("m", domain="integer")
> sage: assume(m>0)
>
> Sage follows the Maxima convention for multiple derivation d^n/dx^n f(x)
> is diff(f(x),x,n) :
>
> sage: diff(sin(x),x,3)
> -
I forgot to mention: this is a transfert from a sage-support message by
Emmanuel:
https://groups.google.com/d/msg/sage-support/5M50BRbHy2k/5jRYMnf7AQAJ
Le samedi 1 août 2020 12:19:45 UTC+2, Eric Gourgoulhon a écrit :
>
>
>
> Le samedi 1 août 2020 10:06:47 UTC+2, Emmanuel Charpentier a écrit :
>>
This issue is difficult to solve. A similar problem was discussed in
https://trac.sagemath.org/ticket/29391#comment:4. Using `cd` instead of
`%cd` is an IPython "feature" called automagic which is not guaranteed to
always work – for example, if there is a variable named `cd` in scope. The
follo
On Sat, Aug 1, 2020 at 10:03 AM Samuel Lelievre
wrote:
>
> 2020-08-01 08:00:32 UTC, Dima Pasechnik:
> >
> > Sorry for shouting, but "batteries-included" monolithic monsters
> > don't work (certainly not long-term), in case of Sage it has become
> > increasingly obvious in the past ~10 years.
> >
On Saturday, August 1, 2020 at 1:00:32 AM UTC-7, Dima Pasechnik wrote:
>
> Besides, how about working with Homebrew formulae to offload more of
> Sage packages there.
> How about helping Conda's Sage distribution. (The latter potentially
> very helpful for Conda on Linux, too).
>
+1 on the sug
On Sat, 1 Aug 2020, 16:17 Matthias Koeppe, wrote:
> On Saturday, August 1, 2020 at 1:00:32 AM UTC-7, Dima Pasechnik wrote:
>>
>> Besides, how about working with Homebrew formulae to offload more of
>> Sage packages there.
>> How about helping Conda's Sage distribution. (The latter potentially
>>
Thanks for fowarding, Eric. I hesitated to cross-post in sage-devel,
because I was not 100% sure it wasn’t pilot error (I am now…).
Le samedi 1 août 2020 12:22:49 UTC+2, Eric Gourgoulhon a écrit :
I forgot to mention: this is a transfert from a sage-support message by
> Emmanuel:
> https://gr
Le samedi 1 août 2020 10:06:47 UTC+2, Emmanuel Charpentier a écrit :
>
> Consider :
>>
>> sage: f=function("f")
>> sage: m=var("m", domain="integer")
>> sage: assume(m>0)
>>
>> Sage follows the Maxima convention for multiple derivation d^n/dx^n f(x)
>> is diff(f(x),x,n) :
>>
>> sage: diff(sin(x),
To illustrate the need for a better notation :
sage: var("m")
m
sage: g(x,m)=x^m
Derivate by each of the variables, once each :
sage: g(x).diff(x,m)
m*x^(m - 1)*log(x) + x^(m - 1)
Ditto with Sympy
sage: import sympy
sage: sympy.sympify(g(x)).diff(x,m)
x**m*(m*log(x) + 1)/x
which is the same
I partly disagree ; see below :
Le samedi 1 août 2020 18:52:03 UTC+2, Nils Bruin a écrit :
>
>
> Le samedi 1 août 2020 10:06:47 UTC+2, Emmanuel Charpentier a écrit :
>>
>> Consider :
>>>
>>> sage: f=function("f")
>>> sage: m=var("m", domain="integer")
>>> sage: assume(m>0)
>>>
>>> Sage follows the
On Saturday, August 1, 2020 at 10:18:34 AM UTC-7, Emmanuel Charpentier
wrote:
>
> Nope : looking at the docs you point to shows that the syntax is not
> *specified*, but only *illustrated*. And there lies the rub... : the doc
> does *not* specify that unspecified (symbolic) order iterated deriva
Okay.
It seems that we agree that Sage lacks an ability routinely provided by (at
minimum) Sympy and Mathematica. I don't disagree with your assessment of
the importance of the works necessary to implement it : I have (currently)
zero knowledge of the implementation. I do not (yet) know nor und
On Saturday, August 1, 2020 at 10:43:15 AM UTC-7, Nils Bruin wrote:
> I think Maple uses the same internal representation. It's one that makes
> most sense if you're thinking about multivariate derivatives.
>
Possibly interesting detail: maple does use the same internal rep, but
complements tha
Is there an easy workaround for this on until the fix is merged? e.g. how
can I accomplish the same thing as "sage -b"? I'm on beta6 by the way.
On Saturday, July 18, 2020 at 4:27:12 AM UTC-6, Dima Pasechnik wrote:
>
> yes, this beta is a bit broken w.r.t. ./sage -b
> See https://trac.sagemath.o
Running "make build" should be a good replacement.
On Saturday, August 1, 2020 at 2:13:02 PM UTC-7, Chase Meadors wrote:
>
> Is there an easy workaround for this on until the fix is merged? e.g. how
> can I accomplish the same thing as "sage -b"? I'm on beta6 by the way.
>
> On Saturday, July 18
Thanks for posting a link to that old (5 year old) report.
The notion that you are computing in the complex domain (functions of many
complex variables??)
is really not enough. Because (as noted) there are multiple branches of
common
functions, choosing one of them (behind the scenes, on the fl
18 matches
Mail list logo
