There were long discussion about the typesetting of partial derivatives in the new system, but I don't think we got to a conclusion yet. The previous thread is here:
> There were long discussion about the typesetting of partial derivatives
> in the new system, but I don't think we got to a conclusion yet. The
> previous thread is here:
> In these examples, keep in mind that we did not define what the first
> argument of the function is called, so we can't just replace D[0, 0]
> with d/dx.
> The power of this notation is seen mainly with more than one argument:
> sage: f(x+y, x-y).derivative(y)
> D[0](f)(x + y, x - y) - D[1](f)(x + y, x - y)
> Here is what MMA does:
> In[1]:= D[F[x], x]
> Out[1]= F'[x]
> In[2]:= TeXForm[%]
> Out[2]//TeXForm= F'(x)
> In[3]:= D[F[x], x, x, x, x, x]
> (5)
> Out[3]= F [x]
> In[4]:= TeXForm[%]
> Out[4]//TeXForm= F^{(5)}(x)
> In[5]:= D[F[x+2*y], x, x]
> Out[5]= F''[x + 2 y]
> In[6]:= TeXForm[%]
> Out[6]//TeXForm= F''(x+2 y)
> In[7]:= D[F[x+2*y], y, y]
> Out[7]= 4 F''[x + 2 y]
> In[8]:= TeXForm[%]
> Out[8]//TeXForm= 4 F''(x+2 y)
> In[9]:= D[F[x+y, x-y], y]
> (0,1) (1,0)
> Out[9]= -F [x + y, x - y] + F [x + y, x - y]
>> There were long discussion about the typesetting of partial >> derivatives >> in the new system, but I don't think we got to a conclusion yet. The >> previous thread is here:
>> In these examples, keep in mind that we did not define what the first >> argument of the function is called, so we can't just replace D[0, 0] >> with d/dx.
>> The power of this notation is seen mainly with more than one >> argument:
>> sage: f(x+y, x-y).derivative(y) >> D[0](f)(x + y, x - y) - D[1](f)(x + y, x - y)
>> Here is what MMA does:
>> In[1]:= D[F[x], x]
>> Out[1]= F'[x]
>> In[2]:= TeXForm[%]
>> Out[2]//TeXForm= F'(x)
>> In[3]:= D[F[x], x, x, x, x, x]
>> (5) >> Out[3]= F [x]
>> In[4]:= TeXForm[%]
>> Out[4]//TeXForm= F^{(5)}(x)
>> In[5]:= D[F[x+2*y], x, x]
>> Out[5]= F''[x + 2 y]
>> In[6]:= TeXForm[%]
>> Out[6]//TeXForm= F''(x+2 y)
>> In[7]:= D[F[x+2*y], y, y]
>> Out[7]= 4 F''[x + 2 y]
>> In[8]:= TeXForm[%]
>> Out[8]//TeXForm= 4 F''(x+2 y)
>> In[9]:= D[F[x+y, x-y], y]
>> (0,1) (1,0) >> Out[9]= -F [x + y, x - y] + F [x + y, x - y]
>> There were long discussion about the typesetting of partial derivatives >> in the new system, but I don't think we got to a conclusion yet. The >> previous thread is here:
>> In these examples, keep in mind that we did not define what the first >> argument of the function is called, so we can't just replace D[0, 0] >> with d/dx.
>> The power of this notation is seen mainly with more than one argument:
>> sage: f(x+y, x-y).derivative(y) >> D[0](f)(x + y, x - y) - D[1](f)(x + y, x - y)
>> Here is what MMA does:
>> In[1]:= D[F[x], x]
>> Out[1]= F'[x]
>> In[2]:= TeXForm[%]
>> Out[2]//TeXForm= F'(x)
>> In[3]:= D[F[x], x, x, x, x, x]
>> (5) >> Out[3]= F [x]
>> In[4]:= TeXForm[%]
>> Out[4]//TeXForm= F^{(5)}(x)
>> In[5]:= D[F[x+2*y], x, x]
>> Out[5]= F''[x + 2 y]
>> In[6]:= TeXForm[%]
>> Out[6]//TeXForm= F''(x+2 y)
>> In[7]:= D[F[x+2*y], y, y]
>> Out[7]= 4 F''[x + 2 y]
>> In[8]:= TeXForm[%]
>> Out[8]//TeXForm= 4 F''(x+2 y)
>> In[9]:= D[F[x+y, x-y], y]
>> (0,1) (1,0) >> Out[9]= -F [x + y, x - y] + F [x + y, x - y]
>>> convert(%, diff); >> / 2 \| >> | d || >> 4 |---- f(t1)|| >> | 2 || >> \dt1 /|t1 = x + 2 y
>>> diff(f(x+y, x-y), y); >> D[1](f)(x + y, x - y) - D[2](f)(x + y, x - y)
>>> convert(%, diff); >> D[1](f)(x + y, x - y) - D[2](f)(x + y, x - y)
>> I like the way MMA handles this. It's compact and consistent. So I >> suggest we change things to use the MMA convention.
> The MMA convention seems to include as a special case a prime (') for > derivatives of functions of one variable Is that right? Seems good > to me.
> John
>> Comments?
Personally, I prefer the Mathematica notation because I can actually read it. I have (serious!) trouble reading the current notation that Sage uses and I can barely read the Maple notation either. With the Mathematica notation it is totally completely obvious to me what is going on.
On Sun, Jun 14, 2009 at 4:38 PM, Burcin Erocal<bur...@erocal.org> wrote: > There were long discussion about the typesetting of partial derivatives > in the new system, but I don't think we got to a conclusion yet.
I am afraid, we might never reach a conclusion in this regard :-) It seems to be a classic case where we are trying to fit one size for all.
Given the previous arguments for/against any specific scheme for derivative typesetting and my own experience while experimenting with sage typesetting code, I am now more inclined to follow the strategy as outlined below.
(1) Let there be options such that one can use either typesetting scheme by choice in run-time.
(2) By default, we follow a rather hybrid approach:
(a) If we all agree that there is no ambiguity when the particular argument is a "symbolic variable" or "symbolic function" then we should typeset them as those found in text-books.
> Personally, I prefer the Mathematica notation because I can actually > read it. I have (serious!) trouble reading the current notation that > Sage uses and I can barely read the Maple notation either. With the > Mathematica notation it is totally completely obvious to me what is > going on.
> There were long discussion about the typesetting of partial derivatives
> in the new system, but I don't think we got to a conclusion yet. The
> previous thread is here:
> In these examples, keep in mind that we did not define what the first
> argument of the function is called, so we can't just replace D[0, 0]
> with d/dx.
> The power of this notation is seen mainly with more than one argument:
> sage: f(x+y, x-y).derivative(y)
> D[0](f)(x + y, x - y) - D[1](f)(x + y, x - y)
> Here is what MMA does:
> In[1]:= D[F[x], x]
> Out[1]= F'[x]
> In[2]:= TeXForm[%]
> Out[2]//TeXForm= F'(x)
> In[3]:= D[F[x], x, x, x, x, x]
> (5)
> Out[3]= F [x]
> In[4]:= TeXForm[%]
> Out[4]//TeXForm= F^{(5)}(x)
> In[5]:= D[F[x+2*y], x, x]
> Out[5]= F''[x + 2 y]
> In[6]:= TeXForm[%]
> Out[6]//TeXForm= F''(x+2 y)
> In[7]:= D[F[x+2*y], y, y]
> Out[7]= 4 F''[x + 2 y]
> In[8]:= TeXForm[%]
> Out[8]//TeXForm= 4 F''(x+2 y)
> In[9]:= D[F[x+y, x-y], y]
> (0,1) (1,0)
> Out[9]= -F [x + y, x - y] + F [x + y, x - y]
> / 2 \|
> | d ||
> 4 |---- f(t1)||
> | 2 ||
> \dt1 /|t1 = x + 2 y
> > diff(f(x+y, x-y), y);
> D[1](f)(x + y, x - y) - D[2](f)(x + y, x - y)
> > convert(%, diff);
> D[1](f)(x + y, x - y) - D[2](f)(x + y, x - y)
> I like the way MMA handles this. It's compact and consistent. So I
> suggest we change things to use the MMA convention.
> Comments?
> Cheers,
> Burcin
I don't like the D[1] notation at all. By the way, when we have a
function f of two variables, should we automatically assume that the
mixed partials are equal? Does this affect our choice of notation?
(Another notation I've seen: f_n is the derivative with respect to the
nth variable, so f_12 is (f_1)_2: if the variables are x and y, take
partial with respect to x, then y; in contrast, the other mixed
partial is f_21.)
> On Sun, Jun 14, 2009 at 4:38 PM, Burcin Erocal<bur...@erocal.org> wrote: >> There were long discussion about the typesetting of partial derivatives >> in the new system, but I don't think we got to a conclusion yet.
> I am afraid, we might never reach a conclusion in this regard :-)
Yes we will. It doesn't have to be unanimous, but we will reach a conclusion.
On Mon, Jun 15, 2009 at 12:30 PM, William Stein<wst...@gmail.com> wrote: > On Sun, Jun 14, 2009 at 11:03 PM, Golam Mortuza > Hossain<gmhoss...@gmail.com> wrote:
>> Hi
>> On Sun, Jun 14, 2009 at 4:38 PM, Burcin Erocal<bur...@erocal.org> wrote: >>> There were long discussion about the typesetting of partial derivatives >>> in the new system, but I don't think we got to a conclusion yet.
>> I am afraid, we might never reach a conclusion in this regard :-)
> Yes we will. It doesn't have to be unanimous, but we will reach a conclusion.
> So the conclusion is that we will go with the Mathematica style notation.
Does that also apply to Golam's earlier comment
(a) If we all agree that there is no ambiguity when the particular
argument is a "symbolic variable" or "symbolic function" then
we should typeset them as those found in text-books.
Ex:
(1) D[0,0,0] (f)(x,y) => \frac{\partial^3}{\partial x^3} f
(x,y)
(2) D[0] (f)(g(x,y), h(z)) => \frac{\partial}{\partial
g(x,y)} f(g(x,y), h(y))
so that we will no longer see nicely typeset partial derivatives even
in case (a)(1) (or even Leibniz notation at all?), or is it only in
the case (b) "when the argument is an expression"? Thanks for the
clarification.
On Tue, Jun 16, 2009 at 7:20 PM, kcrisman<kcris...@gmail.com> wrote:
>> So the conclusion is that we will go with the Mathematica style notation.
> Does that also apply to Golam's earlier comment
> (a) If we all agree that there is no ambiguity when the particular > argument is a "symbolic variable" or "symbolic function" then > we should typeset them as those found in text-books. > Ex: > (1) D[0,0,0] (f)(x,y) => \frac{\partial^3}{\partial x^3} f > (x,y) > (2) D[0] (f)(g(x,y), h(z)) => \frac{\partial}{\partial > g(x,y)} f(g(x,y), h(y))
> so that we will no longer see nicely typeset partial derivatives even > in case (a)(1) (or even Leibniz notation at all?), or is it only in > the case (b) "when the argument is an expression"? Thanks for the > clarification.
I don't know. It didn't seem to me that people voted on that more refined point.
On Tue, Jun 16, 2009 at 2:20 PM, kcrisman<kcris...@gmail.com> wrote:
>> So the conclusion is that we will go with the Mathematica style notation.
> Does that also apply to Golam's earlier comment
> (a) If we all agree that there is no ambiguity when the particular > argument is a "symbolic variable" or "symbolic function" then > we should typeset them as those found in text-books. > Ex: > (1) D[0,0,0] (f)(x,y) => \frac{\partial^3}{\partial x^3} f > (x,y) > (2) D[0] (f)(g(x,y), h(z)) => \frac{\partial}{\partial > g(x,y)} f(g(x,y), h(y))
> so that we will no longer see nicely typeset partial derivatives even > in case (a)(1) (or even Leibniz notation at all?), or is it only in > the case (b) "when the argument is an expression"? Thanks for the > clarification.
As Burcin pointed out that even MMA uses different Tex-ing scheme for some situations such as F'[x] for D[F[x],x]. So strictly speaking even MMA uses hybrid approach.
I guess, we should aim for doing better than MMA/Maple.
> Personally, I prefer the Mathematica notation because I can actually > read it. I have (serious!) trouble reading the current notation that > Sage uses and I can barely read the Maple notation either. With the > Mathematica notation it is totally completely obvious to me what is > going on.
If it wasn't obvious from my previous comments in former threads, I am of this opinion as well. I would actually be for disallowing the bare function('f') from the global namespace altogether and forcing the user to provide named, ordered dummy variables (what does it actually mean?)
> On Jun 14, 2009, at 1:19 PM, William Stein wrote:
>> Personally, I prefer the Mathematica notation because I can actually >> read it. I have (serious!) trouble reading the current notation that >> Sage uses and I can barely read the Maple notation either. With the >> Mathematica notation it is totally completely obvious to me what is >> going on.
> If it wasn't obvious from my previous comments in former threads, I > am of this opinion as well. I would actually be for disallowing the > bare function('f') from the global namespace altogether and forcing > the user to provide named, ordered dummy variables (what does it > actually mean?)
I'm not opposed to that suggestion. I have no idea what "function('f')" even means.
> On Wed, Jun 17, 2009 at 8:23 AM, Robert > Bradshaw<rober...@math.washington.edu> wrote:
> > On Jun 14, 2009, at 1:19 PM, William Stein wrote:
> >> Personally, I prefer the Mathematica notation because I can > >> actually read it. I have (serious!) trouble reading the current > >> notation that Sage uses and I can barely read the Maple notation > >> either. With the Mathematica notation it is totally completely > >> obvious to me what is going on.
> > If it wasn't obvious from my previous comments in former threads, I > > am of this opinion as well. I would actually be for disallowing the > > bare function('f') from the global namespace altogether and forcing > > the user to provide named, ordered dummy variables (what does it > > actually mean?)
> I'm not opposed to that suggestion. I have no idea what > "function('f')" even means.
I don't think forcing the user to provide dummy variables when creating the function is a good approach. I don't see where the variables would be needed, other than printing differentials. If we go with the MMA notation we won't need them even then.
It makes sense to provide a function that takes the variables as arguments, and pretty prints differentials with the df/dx notation though. We already have the code to do this, afair first written by Jason, and now Golam.
> On Tue, Jun 16, 2009 at 2:20 PM, kcrisman<kcris...@gmail.com> wrote:
> >> So the conclusion is that we will go with the Mathematica style > >> notation.
> > Does that also apply to Golam's earlier comment
> > (a) If we all agree that there is no ambiguity when the particular > > argument is a "symbolic variable" or "symbolic function" then > > we should typeset them as those found in text-books. > > Ex: > > (1) D[0,0,0] (f)(x,y) => \frac{\partial^3}{\partial > > x^3} f (x,y) > > (2) D[0] (f)(g(x,y), h(z)) => \frac{\partial}{\partial > > g(x,y)} f(g(x,y), h(y))
> > so that we will no longer see nicely typeset partial derivatives > > even in case (a)(1) (or even Leibniz notation at all?), or is it > > only in the case (b) "when the argument is an expression"? > > Thanks for the clarification.
> As Burcin pointed out that even MMA uses different Tex-ing scheme > for some situations such as F'[x] for D[F[x],x]. So strictly > speaking even MMA uses hybrid approach.
I don't think what MMA does can really be called a hybrid approach. It just represents first and second derivatives of single argument functions with F' and F'', instead of F^{(1)} and F^{(2)} respectively.
John Palmieri wrote in a different thread:
> I don't like the D[1] notation at all. By the way, when we have a > function f of two variables, should we automatically assume that the > mixed partials are equal? Does this affect our choice of notation?
> I guess, we should aim for doing better than MMA/Maple.
What would the hybrid approach be in this case? Use Maple convention, but use MMA style F^{(4, 0} instead of D[1,1,1,1]F[x+y,y] or F^{(3,1)} instead of D[1,1,1,2]F[x+y,y]?
I would like to settle this vote and get rid of the D[...] notation as soon as possible, but William's count of 4 votes for MMA notation to 2 votes for Maple notation doesn't look decisive. At least I can't believe there were so few responses. :)
Can people who care about this please comment and vote?
If there are no objections to the above definition of "hybrid approach", the options for default printing are:
1) Mathematica style 2) Maple style 3) hybrid
For all cases, we would need to provide a function that takes the names of the arguments of the given symbolic function as a parameter and typesets the expression in "textbook style"
I still vote for 1, MMA style. To state the reasons again, it's consistent, and concise.
On Tue, Jun 23, 2009 at 9:00 PM, Burcin Erocal<bur...@erocal.org> wrote: > If there are no objections to the above definition of "hybrid approach", > the options for default printing are:
> I still vote for 1, MMA style. To state the reasons again, it's > consistent, and concise.
Burcin, I am giving you my vote also, for implementing MMA style typesetting as the default one for partial derivatives. Please have those {'} and {''} and may be even {'''} notations.
So I would urge you to go ahead with the implementation.
It wouldn't be difficult to add other choices later as options to users (some of the codes are already there).
Burcin Erocal wrote: > On Tue, 16 Jun 2009 19:42:46 -0300 > Golam Mortuza Hossain <gmhoss...@gmail.com> wrote:
>> Hi,
>> On Tue, Jun 16, 2009 at 2:20 PM, kcrisman<kcris...@gmail.com> wrote: >>>> So the conclusion is that we will go with the Mathematica style >>>> notation. >>> Does that also apply to Golam's earlier comment
>>> (a) If we all agree that there is no ambiguity when the particular >>> argument is a "symbolic variable" or "symbolic function" then >>> we should typeset them as those found in text-books. >>> Ex: >>> (1) D[0,0,0] (f)(x,y) => \frac{\partial^3}{\partial >>> x^3} f (x,y) >>> (2) D[0] (f)(g(x,y), h(z)) => \frac{\partial}{\partial >>> g(x,y)} f(g(x,y), h(y))
>>> so that we will no longer see nicely typeset partial derivatives >>> even in case (a)(1) (or even Leibniz notation at all?), or is it >>> only in the case (b) "when the argument is an expression"? >>> Thanks for the clarification. >> As Burcin pointed out that even MMA uses different Tex-ing scheme >> for some situations such as F'[x] for D[F[x],x]. So strictly >> speaking even MMA uses hybrid approach.
> I don't think what MMA does can really be called a hybrid approach. It > just represents first and second derivatives of single argument > functions with F' and F'', instead of F^{(1)} and F^{(2)} respectively.
> John Palmieri wrote in a different thread: >> I don't like the D[1] notation at all. By the way, when we have a >> function f of two variables, should we automatically assume that the >> mixed partials are equal? Does this affect our choice of notation?
>> I guess, we should aim for doing better than MMA/Maple.
> What would the hybrid approach be in this case? Use Maple convention, > but use MMA style F^{(4, 0} instead of D[1,1,1,1]F[x+y,y] or F^{(3,1)} > instead of D[1,1,1,2]F[x+y,y]?
> I would like to settle this vote and get rid of the D[...] notation as > soon as possible, but William's count of 4 votes for MMA notation to 2 > votes for Maple notation doesn't look decisive. At least I can't > believe there were so few responses. :)
> Can people who care about this please comment and vote?
> If there are no objections to the above definition of "hybrid approach", > the options for default printing are:
> For all cases, we would need to provide a function that takes the names > of the arguments of the given symbolic function as a parameter and > typesets the expression in "textbook style"
> I still vote for 1, MMA style. To state the reasons again, it's > consistent, and concise.
> On Tue, Jun 23, 2009 at 9:00 PM, Burcin Erocal<bur...@erocal.org> > wrote: > > If there are no objections to the above definition of "hybrid > > approach", the options for default printing are:
> > I still vote for 1, MMA style. To state the reasons again, it's > > consistent, and concise.
> Burcin, I am giving you my vote also, for implementing MMA > style typesetting as the default one for partial derivatives. Please > have those {'} and {''} and may be even {'''} notations.
> So I would urge you to go ahead with the implementation.
:) I was hoping you'd implement it, since you did it in #5711 once.
I attached a patch to the trac ticket that contains an initial attempt at the MMA notation:
On Wed, Jun 24, 2009 at 6:54 PM, Burcin Erocal<bur...@erocal.org> wrote: > I attached a patch to the trac ticket that contains an initial attempt > at the MMA notation:
> sage: f = function('f') > sage: f(x).derivative(x,3) > f^{(3)}(x)
My suggestion would be to split out "text-mode" (repr) output for another ticket. Current text-mode output expression from Sage in this case is not a valid input expression of Sage. For example, if I do copy-n-paste output like "D[0](f)(x)" to another cell then Sage doesn't recognize it.
I guess, implementing latex output would be easier one. I did a quick-hack MMA style. It worked fine and with primes it appears to be in "textbook style".
sage: binomial(x,y).derivative(x) <boom> sage: latex(floor(x).derivative(x)) D[0]\left \lfloor x \right \rfloor sage: latex(ceil(x).derivative(x)) D[0]\left \lceil x \right \rceil
If you have an issue with the above printing, please speak now! If you like this, it'd be great if you'd chime in as well.
Burcin indicates that this is a stepping stone, not necessarily a final implementation. However, Burcin points out that we ought to settle on a suitable output soon and move on from this issue.
