#5711: [with patch, needs work] Enhanced Typesetting of Symbolic Functions
-------------------------+--------------------------------------------------
Reporter: gmhossain | Owner: cwitty
Type: enhancement | Status: new
Priority: major | Milestone: sage-4.0.2
Component: symbolics | Keywords: Enhance Typesetting, LaTeX, Symbolic
Functions
Reviewer: | Author:
Merged: |
-------------------------+--------------------------------------------------
Comment(by gmhossain):
Thanks Burcin for your detailed review. See below for my responses. I
would be happy to
hear you back before I start making some of the changes, you have
suggested.
> > (2) Functions such as "diff", "integrate", "limit", "conjugate",
> > "laplace", "inverse_laplace" are now typeset within Sage itself.
> These should be handled using the custom printing facilities of
`sage.symbolic.function.SFunction`.
I fully agree! However, does new symbolics has such framework ready for
the mentioned functions?
> I see that there is already a `_limit` function defined in
`sage/calculus/calculus.py`.
> I think the best solution for the short term would be to put these
printing functions
> there, and give them as an argument to the `SFunction` constructor.
Could you please give an short example for such construction (my current
understanding
of new symbolics is limited)?
What is your "long-term" solution?
Why is it better to put these functions in calculus/calculus.py
even as a "short term" solution? (I gather from William's note
http://480.sagenb.org/home/pub/45/ that
"calculus" direcotory is to be deleted. This conflicts with your
suggestion.)
> {{{
> sage: latex(x.conjugate())
> \bar{x}
> }}}
>
> Why is `\overline` better?
"\bar" is ok for variable but is insufficient for symbolic functions.
Please try the
followings in the notebook:
{{{
jsmath('\\bar{\\psi\\left(x, y\\right)}')
jsmath('\\overline{\\psi\\left(x, y\\right)}')
}}}
then you will see the reason yourself.
> > (6) '''[New in the rebased patch]''' New symbolics uses "D" format
> I believe this issue needs more debate,
> I suggest we split this to a different ticket.
Sure, I will open a new ticket for this.
>
> > (1) Symbolics functions with name in Greek letters (with possible
> > suffixes), are typeset nicely in LaTeX.
> >
> > Ex: psi(x) => \psi(x)
> > f0(x) => f_0(x)
>
> Can't this be handled by a call to the new `latex_function_name()` from
`sage.symbolic.pynac.py_latex_function_pystring()`?
Provided all other symbolic "functions" ("integrate",...) have been
typeset
somewhere else which is not the case at present.
> > (3) Default (fall-back) typesetting for unknown functions (as
> > in Maxima).
> >
> > Ex: myfn(x) => {\it myfn}(x)
>
> We have the GiNaC convention of falling back to `\mbox` at the moment.
Frankly, it is disappointing to see another inconsistent typesetting.
Why should a function named "sin" should be typseset as "\sin" (=>"\rm
sin")
where as another function named "mysin" is typeset as "\mbox{mysin}"?
Please compare
them side-by-side to see the contrast.
> Previously, maxima didn't do anything for function names with one
variable, and added an `\it`:
So as in this patch! Though, I wanted to use "\rm" as {\rm myfunc} but
decided to
stick to maxima usage.
> As you mention in the docstring for `latex_function_name()`, there is
> considerable code duplication between this function and
`latex_variable_name()`.
I agree that we should avoid duplication of code.
> Is there a reason why the further recursions performed by
`latex_variable_name()`
> are not relevant for function names?
In physics, we often use functions such as "f_{\alpha\beta}". In sage, if
I use
current latex_variable_name() to typeset "f_alpha_beta" then it would
typeset
as f_{{\alpha}_{\beta}} which is completely different.
However I guees, thats my own preference and I shouldn't argue anymore on
this.
I guess #6290 will solve my problem altogether.
I will remove latex_function_name() and use latex_variable_name() instead.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5711#comment:12>
Sage <http://sagemath.org/>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
