Typesetting regression in Sage-4.0
Golam Mortuza Hossain
It seems, recent switch to new symbolics has caused several
typesetting regressions in sage-4.0 (compared 3.4.*).
Here are the list of regressions which I have encountered so far.
(1) Typesetting of sec(x), csc(x), cot(x) are broken. It puts an
extra "\mbox" around them unlike for sin, cos, tan.
(2) Typesetting for "integral" no longer works
(3) symbolic "diff" now returns a rather incomprehensible output
-------
f(x) = function('f',x)
diff(f(x),x)
D[0](f)(x)
-------
What does that '0' really means? Typeset version also looks similar.
IMHO, the typeset version of any expression of Sage should look
more like those found in text-books, journals.
(4) Spurious latex code(?):
When I keep "Typeset" checkbox checked and I click on the
output then I get some spurious latex code "\newcommand{\Bold}[1]{\mathbf{#1}}"
for every output. This is not present in 3.4
-----
var('mu')
mu
\newcommand{\Bold}[1]{\mathbf{#1}}\mu
-----
(5) Same typesetting for two different variables:
------
var('xi, xi_')
latex(xi)
\xi
latex(xi_)
\xi
------
I think this bug is present even in 3.4!
Cheers,
Golam
Burcin Erocal
On Fri, 5 Jun 2009 09:37:07 -0300
Golam Mortuza Hossain <gmho...@gmail.com> wrote:
> Hi,
>
> It seems, recent switch to new symbolics has caused several
> typesetting regressions in sage-4.0 (compared 3.4.*).
Some of these are mentioned here:
http://trac.sagemath.org/sage_trac/ticket/6211
It would be great if you can post your comments on the ticket as well.
> Here are the list of regressions which I have encountered so far.
>
> (1) Typesetting of sec(x), csc(x), cot(x) are broken. It puts an
> extra "\mbox" around them unlike for sin, cos, tan.
>
>
> (2) Typesetting for "integral" no longer works
I plan to look at these over the weekend as part of an attempt to wrap
my head around how SFunction/PrimitiveFunction etc. works in the new
symbolics. It might take Mike much less time to fix them, but I guess
he's busy with release management stuff.
> (3) symbolic "diff" now returns a rather incomprehensible output
> -------
> f(x) = function('f',x)
> diff(f(x),x)
> D[0](f)(x)
> -------
> What does that '0' really means? Typeset version also looks similar.
This is also the notation used by Maple, we inherited it from GiNaC.
Here is some explanation from the Maple manual:
http://www.maplesoft.com/support/help/view.aspx?path=D
Indexes in Sage start from 0, not 1. I think this is the only
difference between Maple and Sage.
> IMHO, the typeset version of any expression of Sage should look
> more like those found in text-books, journals.
I agree that we should do better than the current situation. Any help
would be much appreciated.
I'm sorry your patch at #5711 coincided with the switch to pynac. I
still didn't get a chance to check how it fits into the new symbolics
code. I'll also try to do this in the weekend. If you can also comment
on how much of it is still relevant on the ticket, that would save a
lot of time.
> (4) Spurious latex code(?):
>
> When I keep "Typeset" checkbox checked and I click on the
> output then I get some spurious latex code
> "\newcommand{\Bold}[1]{\mathbf{#1}}" for every output. This is not
> present in 3.4 -----
> var('mu')
> mu
> \newcommand{\Bold}[1]{\mathbf{#1}}\mu
> -----
I have no idea where this came from.
>
> (5) Same typesetting for two different variables:
> ------
> var('xi, xi_')
> latex(xi)
> \xi
> latex(xi_)
> \xi
> ------
> I think this bug is present even in 3.4!
This looks like an easy fix.
Cheers,
Burcin
Rob Beezer
> > (4) Spurious latex code(?):
>
> > When I keep "Typeset" checkbox checked and I click on the
> > output then I get some spurious latex code
> > "\newcommand{\Bold}[1]{\mathbf{#1}}" for every output. This is not
> > present in 3.4 -----
> > var('mu')
> > mu
> > \newcommand{\Bold}[1]{\mathbf{#1}}\mu
> > -----
>
> I have no idea where this came from.
which is an outgrowth of the discussion at
http://groups.google.com/group/sage-devel/browse_thread/thread/68cdf05b40303286/d272dc66ad6c21b4
Robert Bradshaw
I can see how this can be more powerful, but I have to admit I'm not
a fan of this compared to the standard df/dx notation.
- Robert
Tim Lahey
I hate this notation in Maple, but it's pretty much optional. Plus,
while
I understand using 0-based indexing, the numbers have a particular
meaning
for derivatives, so 0 doesn't make sense for a first derivative. The 0th
derivative is the function.
I'd like to use the standard derivative notation.
Cheers,
Tim.
---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://www.linkedin.com/in/timlahey
John Cremona
John
Mike Hansen
> I hate this notation in Maple, but it's pretty much optional. Plus,
> while
> I understand using 0-based indexing, the numbers have a particular
> meaning
> for derivatives, so 0 doesn't make sense for a first derivative. The 0th
> derivative is the function.
This is not what the notation means. D[0](f) represented the the
derivative of f with respect to the first argument. D[0,0](f)
represents taking the derivative with respect to that argument twice.
Thus, you can have expressions like
D[0,0,1](f)(x,y)
--Mike
Tim Lahey
On Jun 5, 2009, at 3:28 PM, Mike Hansen wrote:
>
> This is not what the notation means. D[0](f) represented the the
> derivative of f with respect to the first argument. D[0,0](f)
> represents taking the derivative with respect to that argument twice.
> Thus, you can have expressions like
>
> D[0,0,1](f)(x,y)
>
Sorry, it's slightly different than the Maple notation, which I
often forget since I don't use it.
D[0](f) seems strange when there is only one argument.
I still hate the notation. It's also fairly non-standard notation. At
least in Maple, it's mostly optional. Some functions require it, but
there is a function to convert to and from that notation when necessary.
It's bad enough that Sage uses row vectors when most linear algebra
texts use columns (at least in North America). I'd prefer that Sage
stick to traditional notation.
Mike Hansen
> Sorry, it's slightly different than the Maple notation, which I
> often forget since I don't use it.
Maybe I'm missing something, but it seems that it's exactly the same
as what's here http://www.maplesoft.com/support/help/view.aspx?path=D
.
> D[0](f) seems strange when there is only one argument.
f could be a function of many variables.
> I still hate the notation. It's also fairly non-standard notation. At
> least in Maple, it's mostly optional. Some functions require it, but
> there is a function to convert to and from that notation when necessary.
I don't think it'd be a whole lot of work to make GiNaC be able to use
both notions.
--Mike
Golam Mortuza Hossain
On Fri, Jun 5, 2009 at 12:39 PM, Burcin Erocal<bur...@erocal.org> wrote:
>> (3) symbolic "diff" now returns a rather incomprehensible output
>> -------
>> f(x) = function('f',x)
>> diff(f(x),x)
>> D[0](f)(x)
>> -------
>> What does that '0' really means? Typeset version also looks similar.
>
> This is also the notation used by Maple, we inherited it from GiNaC.
> Here is some explanation from the Maple manual:
>
> http://www.maplesoft.com/support/help/view.aspx?path=D
>
> Indexes in Sage start from 0, not 1. I think this is the only
> difference between Maple and Sage.
>
>> IMHO, the typeset version of any expression of Sage should look
>> more like those found in text-books, journals.
>
> I agree that we should do better than the current situation. Any help
> would be much appreciated.
>
> I'm sorry your patch at #5711 coincided with the switch to pynac. I
> still didn't get a chance to check how it fits into the new symbolics
> code. I'll also try to do this in the weekend. If you can also comment
> on how much of it is still relevant on the ticket, that would save a
> lot of time.
I have started reading new symbolics code. Let me have some
basic understanding of how it works, then I will be able to make
some definite comments on the patch whether some of the code
can be directly copied or not. I might then try to forward-port
the patch.
Cheers,
Golam
Golam Mortuza Hossain
On Fri, Jun 5, 2009 at 4:45 PM, Mike Hansen<mha...@gmail.com> wrote:
>
>> D[0](f) seems strange when there is only one argument.
>
> f could be a function of many variables.
>
>> I still hate the notation. It's also fairly non-standard notation. At
>> least in Maple, it's mostly optional. Some functions require it, but
>> there is a function to convert to and from that notation when necessary.
>
> I don't think it'd be a whole lot of work to make GiNaC be able to use
> both notions.
IMO, it is alright if GiNaC uses this particular format for internal processing.
However, printing the output (either the raw or the typeset version) in the new
format ("D[0](f)") is at best confusing.
I guess, it would be better if new symbolics returns at least
the output in old Maxima format.
Cheers,
Golam
Mike Hansen
Hossain<gmho...@gmail.com> wrote:
>
> Hi Mike,
>
> On Fri, Jun 5, 2009 at 4:45 PM, Mike Hansen<mha...@gmail.com> wrote:
>>
>>> D[0](f) seems strange when there is only one argument.
>>
>> f could be a function of many variables.
>>
>>> I still hate the notation. It's also fairly non-standard notation. At
>>> least in Maple, it's mostly optional. Some functions require it, but
>>> there is a function to convert to and from that notation when necessary.
>>
>> I don't think it'd be a whole lot of work to make GiNaC be able to use
>> both notions.
>
> IMO, it is alright if GiNaC uses this particular format for internal processing.
> However, printing the output (either the raw or the typeset version) in the new
> format ("D[0](f)") is at best confusing.
It's not just a matter of how things are printed. For example, consider
sage: f = function('f')
sage: f(x^2).diff(x)
2*x*D[0](f)(x^2)
where GiNaC automatically applies the chain rule as opposed to something like
diff(f(x^2), x).
--Mike
Golam Mortuza Hossain
>> IMO, it is alright if GiNaC uses this particular format for internal processing.
>> However, printing the output (either the raw or the typeset version) in the new
>> format ("D[0](f)") is at best confusing.
>
> It's not just a matter of how things are printed. For example, consider
>
> sage: f = function('f')
> sage: f(x^2).diff(x)
> 2*x*D[0](f)(x^2)
>
> where GiNaC automatically applies the chain rule as opposed to something like
>
> diff(f(x^2), x).
OK, got it.
I guess, it shouldn't be difficult to typeset the expression as earlier
even with the new format. We just need to parse it differently.
Could you please give some clue on how exactly the typesetting with new
symbolics are supposed to work? Is there a _latex_ class method for
symbolic expression somewhere in the new symbolics?
(Earlier there was a "_latex_" method for the class SymbolicFunctionEvaluation.
From there I could call a function such as
"misc.latex.latex_symbolic_function(self)" )
If yes, then I should be able to salvage most of the code from an old
patch.
Thanks,
Golam
Now let me ask,
Mike Hansen
Hossain<gmho...@gmail.com> wrote:
> I guess, it shouldn't be difficult to typeset the expression as earlier
> even with the new format. We just need to parse it differently.
>
> Could you please give some clue on how exactly the typesetting with new
> symbolics are supposed to work? Is there a _latex_ class method for
> symbolic expression somewhere in the new symbolics?
> (Earlier there was a "_latex_" method for the class SymbolicFunctionEvaluation.
> From there I could call a function such as
> "misc.latex.latex_symbolic_function(self)" )
> If yes, then I should be able to salvage most of the code from an old
> patch.
The _latex_ from Expressions calls GiNaC which as code for assembling
latex code from the expression tree. The thing that corresponds to
SymbolicFunctionEvaluation is roughly sage.symbolic.function.SFunction
and PrimitiveFunction. The things of interest are print_latex_func
and _print_latex_.
Sorry for the rushed explanation. I can take a look at this too later
this evening when I have some more time.
--Mike
Golam Mortuza Hossain
On Fri, Jun 5, 2009 at 7:09 PM, Mike Hansen<mha...@gmail.com> wrote:
> The _latex_ from Expressions calls GiNaC which as code for assembling
> latex code from the expression tree. The thing that corresponds to
> SymbolicFunctionEvaluation is roughly sage.symbolic.function.SFunction
> and PrimitiveFunction. The things of interest are print_latex_func
> and _print_latex_.
Thanks Mike, it was very helpful. I have now mostly ported the old
patch (#5711) to new symbolics. Consequently, typesetting for "integrate",
"diff", "limit", "laplace", "inverse_laplace", symbolic functions (Greek
letters) are working great in sage-4.0.1.
However, there are couple of issues that I need to sort out.
(1) In "py_latex_function_pystring" function (sage.symbolics.pynac),
what does the argument "fname_paren" signify? Why does typesetting
depend on it?
(2) keyword "latex_name": If I understand correctly, the new
"SFunction" class can be given keyboard argument
"latex_name=LaTeX". Somehow, it doesn't seem to work
from notebook. It would be really cool if we could define a
symbolic function as
----
riemann(x) = function('riemann', x, latex_name="\\mathcal{R}")
----
(3) Is there an equivalent class for "SymbolicVariable" in new symbolics?
If yes, then certain customization can be done. For example, f(x) can
be typeset as "f(x)" whereas f(x^2) can be typeset as "f\left(x^2\right)".
(4) Should we switch to old maxima format for "diff"?
Cheers,
Golam
Nick Alexander
> "SFunction" class can be given keyboard argument
> "latex_name=LaTeX". Somehow, it doesn't seem to work
> from notebook. It would be really cool if we could define a
> symbolic function as
> ----
> riemann(x) = function('riemann', x, latex_name="\\mathcal{R}")
That's the function I want.
> (4) Should we switch to old maxima format for "diff"?
Please no -- the new thing takes time to get used to but is better in
the long run.
Nick
Tim Lahey
On Jun 9, 2009, at 8:01 PM, Golam Mortuza Hossain wrote:
>
> (4) Should we switch to old maxima format for "diff"?
>
Yes. At least make it the default and the other an option.
Cheers,
Jason Grout
>
> (4) Should we switch to old maxima format for "diff"?
Can you clarify with an example what you mean? In other words, can you
give an example of the "new" way and the "old" way?
Thanks,
Jason
Golam Mortuza Hossain
On Tue, Jun 9, 2009 at 9:45 PM, Jason Grout<jason...@creativetrax.com> wrote:
>> (4) Should we switch to old maxima format for "diff"?
>
> Can you clarify with an example what you mean? In other words, can you
> give an example of the "new" way and the "old" way?
In new symbolics, "df(x)/dx" is
(a) represented as: D[0] f(x)
(b) typeset as: D[0] f(x)
In old symbolics, the same was
(a) represented as: diff( f(x), x)
(b) typeset as: \frac{d f(x)}{d x}
Cheers,
Golam
Nick Alexander
>> you
>> give an example of the "new" way and the "old" way?
And the examples with multiple variables?
Nick
Tim Lahey
The problem I have with the "new" way is that it isn't standard so
it doesn't make sense for typesetting. You'd have to explain it in
every paper that used it.
Also, in Maple, it's only an option, not a default. If you use diff,
you get the standard notation. If D is used, then that notation is
used.
Cheers,
Robert Bradshaw
> On Jun 9, 2009, at 11:09 PM, Nick Alexander wrote:
>
>>
>>>> Can you clarify with an example what you mean? In other words, can
>>>> you
>>>> give an example of the "new" way and the "old" way?
>>
>> And the examples with multiple variables?
>>
>> Nick
>
> The problem I have with the "new" way is that it isn't standard so
> it doesn't make sense for typesetting. You'd have to explain it in
> every paper that used it.
On top of that, explaining the notation to an (average) freshman
calculus student is infinitely worse than having to explain it in a
paper. Also, functions in Sage do have variable names bound to their
dummy variables, so it's not entirely ambiguous. We could make it a
printing option on latex objects though.
- Robert
Carl Witty
Is it even possible to use the old typesetting format with the new
symbolic representation? For example, "df(sin(x)*cos(x))/dx" is
represented as -(sin(x)^2 - cos(x)^2)*D[0](f)(sin(x)*cos(x)); it seems
likely to be difficult to invert that to produce
{{{\it \partial}}\over{{\it \partial}\,x}}\,f\left(\cos x\,\sin x \right)
(which is what the old symbolics produced). And what should
"D[0](f)(sin(x)*cos(x))" be typeset as?
Carl
Golam Mortuza Hossain
On Wed, Jun 10, 2009 at 4:49 PM, Carl Witty<carl....@gmail.com> wrote:
> Is it even possible to use the old typesetting format with the new
> symbolic representation? For example, "df(sin(x)*cos(x))/dx" is
> represented as -(sin(x)^2 - cos(x)^2)*D[0](f)(sin(x)*cos(x)); it seems
> likely to be difficult to invert that to produce
>
> {{{\it \partial}}\over{{\it \partial}\,x}}\,f\left(\cos x\,\sin x \right)
>
> (which is what the old symbolics produced). And what should
> "D[0](f)(sin(x)*cos(x))" be typeset as?
Agree, this is really a mess. If I follow the simple algorithm,
I get "\frac{d f\left(\sin\left(x\right) \cos\left(x\right)\right)}
{d \sin\left(x\right) \cos\left(x\right)}".
Other suggestion (with known pitfalls) could be
"\frac{d f(z)}{d z}_{|z=\sin(x)\cos(x)}" where the argument itself
is an expression.
While using the new representation, I happened to hit a major
drawback. For example: "diff( f(x), x, 20)" is now represented
as
"D[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0](f)(x)"
In seems there are no ways to shorten it.
Also, if I do a copy-n-paste of above expression in a new cell. Sage
doesn't recognize "D" function.
Cheers,
Golam
Jason Grout
How about:
-(sin(x)^2-cos(x)^2)*\frac{df}{dx}(sin(x)*cos(x))
That's how I'd write it in class if I was illustrating the chain rule.
I agree with Robert---functions have ordered, named parameters (thanks
to your patch that deprecated not specifying the order of variables!),
so we should be able to convert back and forth between D[i](f) and
\frac{df}{d<parameter>} or \frac{\partial f}{\partial<parameter>}
unambiguously.
Jason
Mike Hansen
> That's how I'd write it in class if I was illustrating the chain rule.
>
> I agree with Robert---functions have ordered, named parameters (thanks
> to your patch that deprecated not specifying the order of variables!),
> so we should be able to convert back and forth between D[i](f) and
> \frac{df}{d<parameter>} or \frac{\partial f}{\partial<parameter>}
> unambiguously.
No, it's not that easy. These really are two different things.
Converting from the D[] notation to the diff() notation requires the
introduction of a dummy variable and an evaluation. Functions don't
have ordered, named parameters associated to them. Consider the
following:
sage: x, y = var('x,y')
sage: f = function('f')
sage: f(x*y).diff(x)
y*D[0](f)(x*y)
Note that "f = function('f', x)" is the same as "f = function('f')(x)".
The correct solution is to make GiNaC know about both types of expressions.
--Mike
Robert Bradshaw
>
> On Wed, Jun 10, 2009 at 3:16 PM, Jason Grout<jason-
> sa...@creativetrax.com> wrote:
>> That's how I'd write it in class if I was illustrating the chain
>> rule.
>>
>> I agree with Robert---functions have ordered, named parameters
>> (thanks
>> to your patch that deprecated not specifying the order of
>> variables!),
>> so we should be able to convert back and forth between D[i](f) and
>> \frac{df}{d<parameter>} or \frac{\partial f}{\partial<parameter>}
>> unambiguously.
>
> No, it's not that easy. These really are two different things.
> Converting from the D[] notation to the diff() notation requires the
> introduction of a dummy variable and an evaluation. Functions don't
> have ordered, named parameters associated to them. Consider the
> following:
>
> sage: x, y = var('x,y')
> sage: f = function('f')
> sage: f(x*y).diff(x)
> y*D[0](f)(x*y)
>
> Note that "f = function('f', x)" is the same as "f = function('f')
> (x)".
I misspoke. Raw functions are weird beasts, which don't even know how
many parameters they take. E.g.
sage: f = function('f', x, 2, y); f
f(x, 2, y)
sage: f(10)
f(10, 2, y)
I'm not sure what to make of this, but I'd rather have them behave
more like functions defined with the f(x) = ... notation.
> The correct solution is to make GiNaC know about both types of
> expressions.
Yep.
- Robert
Golam Mortuza Hossain
On Wed, Jun 10, 2009 at 7:23 PM, Mike Hansen<mha...@gmail.com> wrote:
> On Wed, Jun 10, 2009 at 3:16 PM, Jason Grout<jason...@creativetrax.com> wrote:
>> I agree with Robert---functions have ordered, named parameters (thanks
>> to your patch that deprecated not specifying the order of variables!),
>> so we should be able to convert back and forth between D[i](f) and
>> \frac{df}{d<parameter>} or \frac{\partial f}{\partial<parameter>}
>> unambiguously.
>
> No, it's not that easy. These really are two different things.
> Converting from the D[] notation to the diff() notation requires the
> introduction of a dummy variable and an evaluation.
I have re-based (to 4.0.1) an old patch for the ticket
http://trac.sagemath.org/sage_trac/ticket/5711
This patch will allow typesetting of derivatives in both formats.
By default it will typeset "D[0]f(x)" as df/dx (diff format).
One can switch between two typesetting formats as follows
-----------
psi(x) = function('psi',x)
g = diff(psi(x),x)
latex(g)
\frac{d \psi\left(x\right)}{d x}
# Switch to D format
sage.symbolic.pynac.typeset_d_as_diff=False
latex(g)
D[0]\psi\left(x\right)
----------
I would appreciate if someone could review it.
Thanks,
Golam