LaTex representation for SymbolicFunctionEvaluation

[Golam Mortuza Hossain]

Hi all,

I am trying to enhance the support for latex-formatting
of "SymbolicFunctionEvaluation" in Sage. In particular,
when their names match with Greek letters then Sage
should use formatting similar to the formatting of
"SymbolicVariable".

In Physics, we often use "psi(x)" to denote a wave-function
like
---
psi(x) = function('psi',x)
---

It will make Sage output more intuitive if they are
formatted as Greek letters.

I have already got it working after adding only few lines
of codes. However, I am facing couple of issues:

(1) While formatting integral expression, such as

integrate(phi(x)*psi(x),x)

Sage seems to bypass the _latex_ representation for
the class "SymbolicFunctionEvaluation" (of phi(x), psi(x)).

Can anyone give me some hints: where are the latex
representations for "integrate", "diff", .... are defined?
I mean in which file?

(2) In the list "common_varnames" (in sage/misc/latex.py) two
letters "Phi" and "phi" are missing. So LaTex formatting
for them doesn't work like other Greek letters (even when they
are defined as "SymbolicVariable").

Thanks,
Golam

[Jason Grout]

Golam Mortuza Hossain wrote:
> Hi all,
>
> I am trying to enhance the support for latex-formatting
> of "SymbolicFunctionEvaluation" in Sage. In particular,
> when their names match with Greek letters then Sage
> should use formatting similar to the formatting of
> "SymbolicVariable".
>
> In Physics, we often use "psi(x)" to denote a wave-function
> like
> ---
> psi(x) = function('psi',x)
> ---
>
> It will make Sage output more intuitive if they are
> formatted as Greek letters.
>
> I have already got it working after adding only few lines
> of codes. However, I am facing couple of issues:
>
> (1) While formatting integral expression, such as
>
> integrate(phi(x)*psi(x),x)
>
> Sage seems to bypass the _latex_ representation for
> the class "SymbolicFunctionEvaluation" (of phi(x), psi(x)).
>
> Can anyone give me some hints: where are the latex
> representations for "integrate", "diff", .... are defined?
> I mean in which file?
>

Can you post your patch that makes the functions typeset as greek
letters? I was trying to track this down, but the following current
behavior inhibits that.

sage: latex(function('alpha', x))
{\it alpha}\left(x\right)
sage: latex(function('phi', x))
{\it phi}\left(x\right)
sage: latex(function('psi', x))
{\it psi}\left(x\right)

As a guess, we might be calling out to maxima to latex the integral or
derivative, so that might explain where the problem lies. The code
would probably be in calculus/, maybe in calculus/calculus.py.

I believe http://trac.sagemath.org/sage_trac/ticket/4202 is relevant here.

> (2) In the list "common_varnames" (in sage/misc/latex.py) two
> letters "Phi" and "phi" are missing. So LaTex formatting
> for them doesn't work like other Greek letters (even when they
> are defined as "SymbolicVariable").
>

Yep, I ran into (2) a while back when doing spherical coordinates. Do
you already have a patch to add them?

Thanks,

Jason

[Stan Schymanski]

Hi Golam,

+1 for this enhancement! I look forward to using it and I wouldn't mind
helping if needed. Could you let me know how you got it to work? In
combination with the show() command? I can't answer your question below,
but here is what I used to do for variables that I wanted to print
nicely in latex:

var('sui')
sui._latex_ = lambda: 's_{u,i}'
show(sui)

However, if I then defined sui as a function of another variable, the
above didn't work any more:

var('t')
suit = function('sui',t)
show(suit)
show(sui)

In your example, something similar seems to happen. If you just define a
variable psi, it will plot nicely in latex:
var('psi')
show(psi)

But as soon as you define psi(x), this breaks down. This is carries over
to the integral expressions as well as differentials. Thus, I think that
the problem is not in the definition of the latex reprentations of
integral and diff, but in what happens when you define psi(x) =
function('psi',x). In my view, this is where the trouble starts.

Cheers,
Stan

[Golam Mortuza Hossain]

Hi Jason,

On Wed, Mar 25, 2009 at 11:57 AM, Jason Grout <jason...@creativetrax.com>

> Can you post your patch that makes the functions typeset as greek
> letters?

This is my first attempt to modify Sage. So please feel free
to correct me. Let me mention the changes I have made
to get the elementary support for typesetting functions
as Greek letters.

(1) In file: "sage/misc/latex.py", I have added a function after the list
"common_varnames" as follows
--------------------------------------
def is_common_varname(a):
"""
Checks whether it is a common variable name such as alpha, beta
"""
if a in common_varnames:
return True
else:
return False
----------------------------------

(2) In file: "sage/calculus/calculus.py", change the line
"from sage.misc.latex import latex, latex_variable_name"
to
"from sage.misc.latex import latex, latex_variable_name, is_common_varname"

and in _latex_(self) function for "class SymbolicFunctionEvaluation"
I have added following three lines
--------------------------------------------------------
+ n = self._f._name
+ if is_common_varname(n):
+ return "\\%s(%s)"%(n, ', '.join([x._latex_() for x in self._args]))
try:
return latex(self._maxima_())
---------------------------------------------------------

> I believe http://trac.sagemath.org/sage_trac/ticket/4202 is relevant here.

Thanks, it should definitely help.

>> (2) In the list "common_varnames" (in sage/misc/latex.py) two
>> letters "Phi" and "phi" are missing.

> Yep, I ran into (2) a while back when doing spherical coordinates.  Do

> you already have a patch to add them?

The patch that I am attaching has them added in it. However, I think
it will be better to have a separate patch for this, as this
is a stand-alone issue and should be fixed separately.

BTW, this patch is highly incomplete (for the intended aim) as of now.

Cheers,
Golam

[Golam Mortuza Hossain]

Thanks Stan!

On Wed, Mar 25, 2009 at 12:28 PM, Stan Schymanski <schy...@gmail.com> wrote:
> Thus, I think that
> the problem is not in the definition of the latex reprentations of
> integral and diff, but in what happens when you define psi(x) =
> function('psi',x). In my view, this is where the trouble starts.

Yes, you are right, one should start from there and I have already
got it working for the functions such as
----------

psi(x) = function('psi',x)

g(x) = exp(psi(x))
----

The next type of function names that I am considering are of
the form
----
psi1(x) = function('psi1',x)
psi2(x) = function('psi2',x)
---
Above should be easy to implement following the code
for "SymbolicVariable".

However, as I mentioned earlier, typesetting for "diff(psi(x),x) )"
is not working even though "psi(x)" is working fine.

Cheers,
Golam

[Jason Grout]

Golam Mortuza Hossain wrote:
> Hi Jason,
>
> On Wed, Mar 25, 2009 at 11:57 AM, Jason Grout <jason...@creativetrax.com>
>> Can you post your patch that makes the functions typeset as greek
>> letters?
>
> This is my first attempt to modify Sage. So please feel free
> to correct me. Let me mention the changes I have made
> to get the elementary support for typesetting functions
> as Greek letters.
>
>
> (1) In file: "sage/misc/latex.py", I have added a function after the list
> "common_varnames" as follows
> --------------------------------------
> def is_common_varname(a):
> """
> Checks whether it is a common variable name such as alpha, beta
> """
> if a in common_varnames:
> return True
> else:
> return False

Why not just:

return a in common_varnames

which I think is equivalent.

Also, I think naming the function is_latex_name or something like that
would be better. common_varnames says nothing to me about the variable
name actually being a latex command which produces a symbol (yes, I know
you're just inheriting the current behavior, so it's not your fault).

> ----------------------------------
>
> (2) In file: "sage/calculus/calculus.py", change the line
> "from sage.misc.latex import latex, latex_variable_name"
> to
> "from sage.misc.latex import latex, latex_variable_name, is_common_varname"
>
> and in _latex_(self) function for "class SymbolicFunctionEvaluation"
> I have added following three lines
> --------------------------------------------------------
> + n = self._f._name
> + if is_common_varname(n):
> + return "\\%s(%s)"%(n, ', '.join([x._latex_() for x in self._args]))
> try:
> return latex(self._maxima_())
> ---------------------------------------------------------

Do you want x._latex_() or latex(x)? I believe latex(x) tries to be
smarter than x._latex_(), in that it tries to do sensible things when
x._latex_() doesn't exist.

Good job! I'm glad you're working on this.

Jason

[Jason Grout]

On second thought, the function just takes a string and returns whether
that string is actually a latex command (i.e., can be prepended by "\").
I'd probably just call it is_latex_command or is_latex_symbol.

Eventually, this function will need to have a doctest or two
illustrating its use.

Jason

[Golam Mortuza Hossain]

Hi,

On Wed, Mar 25, 2009 at 4:09 PM, Jason Grout
<jason...@creativetrax.com> wrote:
> Also, I think naming the function is_latex_name or something like that
> would be better.  common_varnames says nothing to me about the variable
> name

Thanks Jason for your suggestions. I have renamed the
function. Also, I have made some changes to accommodate
typesetting for more functions. In _latex_() function
for "class SymbolicFunctionEvaluation", the new codes are
---------------------------------------------------------------------------
name = latex_function_name(self._f._name)
if name:
return "%s\\left(%s\\right)"%(name, ', '.join([latex(x) for x
in self._args]))
--------------------------------------------------------------------------

"latex_function_name" (In file: "sage/misc/latex.py") is now
defined as:

-------------------------------------------------------------
def latex_function_name(x):
"""
If possible return common function names such as alpha, beta,
psi1 as latex symbols otherwise return False
"""
return ... latex-ified(x) if possible #All latex construction goes here

return False
-------------------------------------------------------------

I have followed the typesetting of "SymbolicVariable" closely.
I am listing sample situations:

-----------------------------------------
(1) function('psi',x) => psi\left(x\right)

(2) function('psi1',x) => \psi_{1}\left(x\right)

(3) function('psi_00',x) => \psi_{00}\left(x\right)

(4) function('psi_mu',x) => \psi_{\mu}\left(x\right)

(5) function('psi_xyz',x) => \psi_{xyz}\left(x\right)

(6) function('myfunc_nu',x) => ???

(7) function('alpha_abcd_xyz',x) => ???
------------------------------------------

(1) to (5) have been implemented but I am not sure
what to do for (6) and (7). I guess, for them its better
to return False so that default typesetting are used.
Please let me know if I have missed something.

Cheers,
Golam

[Jason Grout]

Golam Mortuza Hossain wrote:
> Hi,
>
> On Wed, Mar 25, 2009 at 4:09 PM, Jason Grout
> <jason...@creativetrax.com> wrote:
>> Also, I think naming the function is_latex_name or something like that
>> would be better. common_varnames says nothing to me about the variable
>> name
>
> Thanks Jason for your suggestions. I have renamed the
> function. Also, I have made some changes to accommodate
> typesetting for more functions. In _latex_() function
> for "class SymbolicFunctionEvaluation", the new codes are
> ---------------------------------------------------------------------------
> name = latex_function_name(self._f._name)
> if name:
> return "%s\\left(%s\\right)"%(name, ', '.join([latex(x) for x
> in self._args]))
> --------------------------------------------------------------------------
>

Hmmm...I might be being pedantic here, but I'd probably test "name" a
little more explicitly:

if name is not False:
blah...

> "latex_function_name" (In file: "sage/misc/latex.py") is now
> defined as:
>
> -------------------------------------------------------------
> def latex_function_name(x):
> """
> If possible return common function names such as alpha, beta,
> psi1 as latex symbols otherwise return False
> """
> return ... latex-ified(x) if possible #All latex construction goes here
>
> return False
> -------------------------------------------------------------
>
> I have followed the typesetting of "SymbolicVariable" closely.
> I am listing sample situations:
>
> -----------------------------------------
> (1) function('psi',x) => psi\left(x\right)
>
> (2) function('psi1',x) => \psi_{1}\left(x\right)
>
> (3) function('psi_00',x) => \psi_{00}\left(x\right)
>
> (4) function('psi_mu',x) => \psi_{\mu}\left(x\right)
>
> (5) function('psi_xyz',x) => \psi_{xyz}\left(x\right)
>
> (6) function('myfunc_nu',x) => ???
>
> (7) function('alpha_abcd_xyz',x) => ???
> ------------------------------------------
>
> (1) to (5) have been implemented but I am not sure
> what to do for (6) and (7). I guess, for them its better
> to return False so that default typesetting are used.
> Please let me know if I have missed something.
>

This seems great. I think you're right: just return False and let the
normal Sage process happen.

I think at this point, it'd be good to post a patch so that we can all
see the full change. Do you know how to make a patch with mercurial?
Have you been using version control to save your changes?

Jason

[Stan Schymanski]

Hi Golam,

It seems that you and Jason are getting a firm grip on this, which is
great. Just out of curiosity and my ignorance of the underlying code: Is
your aim to hard-code certain functions, or is your aim to provide the
users with the possibility of defining the latex representation of their
functions? I assume it is the latter, as there is an indefinite number
of possible function names. Could you confirm?

Cheers and good luck,

Stan

Golam Mortuza Hossain wrote:

[Golam Mortuza Hossain]

Hi Jason,

On Thu, Mar 26, 2009 at 12:49 AM, Jason Grout <jason...@creativetrax.com>

>
> I think at this point, it'd be good to post a patch so that we can all
> see the full change.  Do you know how to make a patch with mercurial?
> Have you been using version control to save your changes?

Frankly, I am trying to learn mercurial now! OK, here is a patch
that adds two missing Greek letters "phi" and "Phi"
to the list "common_varnames".

Could you please open a ticket for this patch? It is created
on top of sage-3.4 version.

I am sending the patch for type-setting of functions as Greek
letters in my next mail.

Thanks,
Golam

[Jason Grout]

Actually, if you want to see the development process from end to end, do
you want to request a trac account? All you have to do is follow the
instructions on the trac home page: http://trac.sagemath.org/sage_trac/wiki

(i.e., email Michael Abshoff and read the trac guidelines)

Then you can create the ticket.

Thanks again for your contribution!

Jason

[Golam Mortuza Hossain]

Hi Stan,

On Thu, Mar 26, 2009 at 5:59 AM, Stan Schymanski <schy...@gmail.com>

> It seems that you and Jason are getting a firm grip on this, which is
> great. Just out of curiosity and my ignorance of the underlying code: Is
> your aim to hard-code certain functions, or is your aim to provide the
> users with the possibility of defining the latex representation of their
> functions? I assume it is the latter, as there is an indefinite number
> of possible function names. Could you confirm?

My current aim was to deal with the function names which are
named after Greek letters, and possibly with suffixes. For example:
function names such as "psi", "tau0", "alpha_mn" "Psi_alpha" etc.

Could you please give some examples for the later case? May be
I am missing your point.

Jason: I am attaching the patch for enhancing typesetting of
functions. I need to add doc-tests though. In the patch, I have
implemented all the situations that I planned to do.

Apart from the situations I mentioned earlier, it now also
supports following types of function name (single letters with
suffixes)
---------------
(6) function('f1',x) => f_{1}\left(x\right)

(7) function('T_sigma',x) => T_{\sigma}\left(x\right)

(8) function('R_ab',x) => R_{ab}\left(x\right)
----------------

Currently, the major problem is to figure out: whats going
wrong in typesetting "diff( psi(x), x)" even
though "exp(psi(x))" works beautifully. Similar issue
arises for "integrate", "conjugate"...

Cheers,
Golam

[Burcin Erocal]

Hi,

On Thu, 26 Mar 2009 17:11:39 -0300
Golam Mortuza Hossain <gmho...@gmail.com> wrote:

<snip>

> Jason: I am attaching the patch for enhancing typesetting of
> functions. I need to add doc-tests though. In the patch, I have
> implemented all the situations that I planned to do.
>
> Apart from the situations I mentioned earlier, it now also
> supports following types of function name (single letters with
> suffixes)
> ---------------
> (6) function('f1',x) => f_{1}\left(x\right)
>
> (7) function('T_sigma',x) => T_{\sigma}\left(x\right)
>
> (8) function('R_ab',x) => R_{ab}\left(x\right)
> ----------------

Can you outline what are the differences between your new
latex_function_name() and the already existing latex_variable_name() in
sage.misc.latex?

The doc string of latex_variable_name() explains what it does clearly:

1. If the variable is a single letter, that is the latex version.

2. If the variable name is suffixed by a number, we put the number
in the subscript.

3. If the variable name contains an '_' we start the subscript at
the underscore. Note that #3 trumps rule #2.

4. If a component of the variable is a greek letter, escape it
properly.

5. Recurse nicely with subscripts.

How is your function different, apart from the fact that you don't
process suffixes recursively?

Thanks.

Burcin

[Golam Mortuza Hossain]

Hi Burcin,

On Thu, Mar 26, 2009 at 5:46 PM, Burcin Erocal <bur...@erocal.org> wrote:
>    5. Recurse nicely with subscripts.
>
> How is your function different, apart from the fact that you don't
> process suffixes recursively?

In one sentence: the new function returns False for un-told situations
whereas the existing function always returns latex expressions for
ALL names.

This behaviour is bad for function-names as it breaks
function-specific typesetting scheme.

Example: for the function "diff" latex_variable_name will
return \mbox{diff}. This breaks current type-setting
of "diff(f(x),x)" as "{{{\it \partial}}\over{{\it
\partial}\,x}}\,f\left(x\right)"

Similar issue arises for "integrate", "exp", etc.

In fact, I tried to use latex_variable_name for functions and
then ran into trouble!

Cheers,
Golam

[Stan Schymanski]

I was thinking of custom defined latex representations of different
variables or functions, similar to the example I showed in my first
email in this thread. Basically, I would like to be able to give
working names to variables (e.g. sui), but display them as I would in
a paper if I use the show command (e.g. $s_{u,i}$). I can define this
by

var('sui')
sui._latex_ = lambda: 's_{u,i}'

but as soon as define the variable as a function, e.g.

var('t')
sui(t) = function('sui',t)

show(sui) does not display correctly any more. So I think that the
problem with the latex representation of functions is not limited to
greek letters, but to any more complicated variable names, and it
would be nice if the user could define the latex representation of his
variables and functions himself. This is for example helpful if one
uses Sage to find analytical solutions of equation that can be put
into e.g. Fortran code, but at the same time one would like to
document the solution path in a nicely typeset way ready to go into a
paper.

I hope this makes sense to you.

Cheers
Stan

On Mar 26, 9:11 pm, Golam Mortuza Hossain <gmhoss...@gmail.com> wrote:
> Hi Stan,
>

> On Thu, Mar 26, 2009 at 5:59 AM, Stan Schymanski <schym...@gmail.com>

>  typeset-symbolic-functions.patch
> 3KViewDownload

[Golam Mortuza Hossain]

Hi Stan,

On Fri, Mar 27, 2009 at 5:58 AM, Stan Schymanski <schy...@gmail.com> wrote:
>
> I was thinking of custom defined latex representations of different
> variables or functions, similar to the example I showed in my first
> email in this thread. Basically, I would like to be able to give
> working names to variables (e.g. sui), but display them as I would in
> a paper if I use the show command (e.g. $s_{u,i}$). I can define this
> by
>
> var('sui')
> sui._latex_ = lambda: 's_{u,i}'
>
> but as soon as define the variable as a function, e.g.
>
> var('t')
> sui(t) = function('sui',t)
>
> show(sui) does not display correctly any more. So I think that the
> problem with the latex representation of functions is not limited to
> greek letters

Thanks, I got it! I agree, it would simply be a great feature.

While playing with your examples, I noticed that Sage can
in fact display them as you want but only partially. For example,

----------------------------
riemann_abcd(x) = function('riemann_abcd',x)
riemann_abcd._latex_ = lambda: '{\\mathcal R}_{abcd}'
view(riemann_abcd)
----------------------------

works! but

------------
view(riemann_abcd(x))
------------

doesn't work. So surely, there are issues. However I guess,
it shouldn't be difficult to fix given it already works partially.

Cheers
Golam

[Stan Schymanski]

Hi Golam,

Thanks a lot for looking into this. It would be great if you could fix
this along the way when you solve your original problem.

Cheers,

Stan

Golam Mortuza Hossain wrote:

[Golam Mortuza Hossain]

Hi,

On Wed, Mar 25, 2009 at 11:57 AM, Jason Grout

<jason...@creativetrax.com> wrote:
> As a guess, we might be calling out to maxima to latex the integral or
> derivative, so that might explain where the problem lies.

Yes, you are quite right. Now I have been able to locate the code where
Sage is calling maxima for Tex-ing symbolic expressions. In
"sage/interfaces/maxima.py" the following line does the job.
s = P._eval_line('tex(%s);'%self.name(), reformat=False)

However, Sage does it only when it fails to do so by its own _latex_
method. This also means that current typesetting of Sage can become
highly inconsistent for symbolics. For example, consider
--------------
var('alpha_nu');
f(x) = function('f',x)
g(x) = integrate(alpha_nu*exp(-alpha_nu*x)*f(x),x)
latex(g(x))
---
{\alpha_{\nu} \int {e^ {- {\it alpha\_nu}\,x }\,f\left(x\right)}{\;dx}}
---------------

The variable "alpha_nu" is being typeset as two different objects
in the same expression which is a disaster!!!

It seems to me that one can take three approaches to fix the
problem of typesetting functions as Greek letters.

(1) Enhance tex-ing of symbolic functions in Maxima.

(2) Edit the tex-ed expressions returned by maxima on-the-fly.
(I tried this and it works but it is also error-prone!)

(3) Implement _latex_ method for "diff", "integrate", ....
within Sage itself. Assuming, pynac-based symbolics in Sage
is in near-horizon, one would need these methods anyway.

At this point, I think, it would be better to hear from those
who are involved with pynac. In particular, whether some
of these _latex_ methods are already being implemented!

Thanks,
Golam

[Burcin Erocal]

Hi,

On Sat, 28 Mar 2009 09:52:18 -0300

Golam Mortuza Hossain <gmho...@gmail.com> wrote:

> (3) Implement _latex_ method for "diff", "integrate", ....
> within Sage itself. Assuming, pynac-based symbolics in Sage
> is in near-horizon, one would need these methods anyway.
>
> At this point, I think, it would be better to hear from those
> who are involved with pynac. In particular, whether some
> of these _latex_ methods are already being implemented!

You're right, these methods are needed.

These have been in the todo list [1] since Nick Alexander pointed them
out to me on IRC. I fixed the latexing of variables then, the functions
and derivatives need more work.

[1] http://wiki.sagemath.org/symbolics/pynac_todo

For the variables, I just needed to call latex_variable_name from
sage.misc.latex. If the python implementations for the other cases
are already there, it will just be as simple as adding the python calls
in the proper places in pynac.

I can only encourage you to go ahead and implement how you think
latex'ing of symbolic functions, derivatives, etc. should work. I will
then try to use your implementation from pynac.

Thanks.

Burcin

[Golam Mortuza Hossain]

Hi,

On Fri, Mar 27, 2009 at 5:58 AM, Stan Schymanski <schy...@gmail.com> wrote:

> I was thinking of custom defined latex representations of different
> variables or functions, similar to the example I showed in my first
> email in this thread. Basically, I would like to be able to give
> working names to variables (e.g. sui), but display them as I would in
> a paper if I use the show command (e.g. $s_{u,i}$). I can define this
> by
>
> var('sui')
> sui._latex_ = lambda: 's_{u,i}'
>
> but as soon as define the variable as a function, e.g.
>
> var('t')
> sui(t) = function('sui',t)
>
> show(sui) does not display correctly any more. So I think that the
> problem with the latex representation of functions is not limited to
> greek letters,

After playing with the issue, I feel that using existing _latex_ method
to define a custom-latex-expression for symbolic functions is bit tricky.

However, I could easily write a new method which works as follows
-----------------------------------------
sui(x) = function('sui',x)
sui(x).set_latex('s_{u,i}')
latex(sui(x))
----
s_{u,i}\left(x\right)
-----------------------------------------
It seems to work well. set_latex method is defined as

-----
def set_latex(self, expr=None):
"""
Set custom LaTeX representation for a symbolic function
"""
from sage.misc.latex import user_defined_latex_dict as ldict
key = self._f._name
if expr is not None:
ldict[key] = expr
elif key in ldict:
del ldict[key]
return None
-----
To construct latex symbols for symbolic functions,
new "latex_function_name" now checks whether
"user_defined_latex_dict" has any key for the given function.

Feel free to post if you have further suggestions.

Cheers,
Golam

[Stan Schymanski]

Hi Golam,

This looks good. Would the following work as well?

-----------------------------------------
sui.set_latex('s_{u,i}')

sui(x) = function('sui',x)

latex(sui(x))
----
s_{u,i}\left(x\right)
-----------------------------------------

Or would the function assignment sui(x) = function('sui',x) overwrite
the previous set_latex command? In other words, my question is whether
the latex definition for sui would automatically be applied to sui(x) or
whether I would have to explicitly give a latex definition for sui(x).
In the latter case, would I have to define the function first and then
its latex representation as you did, or could it also be done the other
way round?

I like the user_defined_latex_dict idea. Good work!

Cheers,

Stan

Golam Mortuza Hossain wrote:

[Golam Mortuza Hossain]

Hi,

On Thu, Mar 26, 2009 at 4:14 PM, Jason Grout
<jason...@creativetrax.com> wrote:
>>here is a patch that adds two missing Greek
>>letters "phi" and "Phi" to the list "common_varnames".
>>
>> Could you please open a ticket for this patch? It is created
>> on top of sage-3.4 version.
>

> Actually, if you want to see the development process from end to end, do
> you want to request a trac account?  All you have to do is follow the
> instructions on the trac home page: http://trac.sagemath.org/sage_trac/wiki
>
> (i.e., email Michael Abshoff and read the trac guidelines)
>
> Then you can create the ticket.

It took bit long to get a trac account!

Jason: I was wondering whether you have opened any
ticket on this issue? If not, then I will try it myself.

Meanwhile, I have implemented typesetting support for
some of the functions like "conjugate", "integrate" of
symbolic functions. My original problem is now solved
for these functions as Maxima is no longer being called for their
latex-ing.

Should I submit patches for each of these functions
separately?

Thanks,
Golam

[Jason Grout]

Golam Mortuza Hossain wrote:
> Hi,
>
> On Thu, Mar 26, 2009 at 4:14 PM, Jason Grout
> <jason...@creativetrax.com> wrote:
>>> here is a patch that adds two missing Greek
>>> letters "phi" and "Phi" to the list "common_varnames".
>>>
>>> Could you please open a ticket for this patch? It is created
>>> on top of sage-3.4 version.
>> Actually, if you want to see the development process from end to end, do
>> you want to request a trac account? All you have to do is follow the
>> instructions on the trac home page: http://trac.sagemath.org/sage_trac/wiki
>>
>> (i.e., email Michael Abshoff and read the trac guidelines)
>>
>> Then you can create the ticket.
>
> It took bit long to get a trac account!
>
> Jason: I was wondering whether you have opened any
> ticket on this issue? If not, then I will try it myself.

I don't think I opened any tickets on this.

>
> Meanwhile, I have implemented typesetting support for
> some of the functions like "conjugate", "integrate" of
> symbolic functions. My original problem is now solved
> for these functions as Maxima is no longer being called for their
> latex-ing.
>
> Should I submit patches for each of these functions
> separately?

I think one patch covering all of the functions would be fine. It's one
logical issue.

Jason

[Golam Mortuza Hossain]

Hi Stan,

On Wed, Apr 1, 2009 at 4:42 AM, Stan Schymanski <schy...@gmail.com> wrote:
> -----------------------------------------
> sui.set_latex('s_{u,i}')
> sui(x) = function('sui',x)
> latex(sui(x))
> ----
> s_{u,i}\left(x\right)
> -----------------------------------------
>
> Or would the function assignment sui(x) = function('sui',x) overwrite
> the previous set_latex command? In other words, my question is whether
> the latex definition for sui would automatically be applied to sui(x) or
> whether I would have to explicitly give a latex definition for sui(x).
> In the latter case, would I have to define the function first and then
> its latex representation as you did, or could it also be done the other
> way round?

It seems that view/show/latex methods are called only after an
expression has been evaluated. So during typesetting one has
access to "sui(x)" and not to "sui". Consequently, custom latex string
needs to be assigned to "sui(x)". Admittedly, my current understanding
of Sage is limited so there may be different ways of doing the same.

New "set_latex()" method is defined for evaluated symbolic
functions. So one needs to define "sui(x)" first and then call
sui(x).set_latex('s_{u,i}'). Doing it in reverse order will raise
error.

> I like the user_defined_latex_dict idea. Good work!

Thanks!

Cheers,
Golam

[Stan Schymanski]

Hi Golam,

Thanks for letting me know. Not a problem at all, I was just curious. I
look forward to seeing it in action.

Cheers

Stan

Golam Mortuza Hossain wrote:

[Golam Mortuza Hossain]

Hi,

On Wed, Apr 1, 2009 at 10:11 PM, Jason Grout
<jason...@creativetrax.com> wrote:
>> Jason: I was wondering whether you have opened any
>> ticket on this issue? If not, then I will try it myself.
>
> I don't think I opened any tickets on this.

OK, I will do it.

>> Should I submit patches for each of these functions
>> separately?
>
> I think one patch covering all of the functions would be fine.  It's one
> logical issue.

Thanks! I have now implemented four functions "diff", "integrate",
"conjugate" and "limit". They seem to cover most of the situations
where maxima is being called for typesetting.

Now I am having an issue on choosing conventions for integral. Which
one is preferred for "integrate(f(x), x)" ?

(1) \int dx f(x)
(2) \int f(x) dx

The first one looks better for nested integrals. Screenshot
of both cases are attached.

Here is a link to another screenshot showing all new typesetting
for symbolic functions in action.

http://www.math.unb.ca/~ghossain/latex-for-symbolics.jpg

Cheers,
Golam

[Nick Alexander]

>
> (1) \int dx f(x)
> (2) \int f(x) dx

I prefer (2).

Nick

[rjf]

At the risk of stating the obvious for some people, the TeX
processing, including defining new forms,
is directly available in Maxima, without the overhead of Sage.

For example,
texput( riemann, "{\\mathcal R}")$
followed by tex( .... expression with riemann...) --> tex stuff.

While I have not followed the latest releases of Sage, Maxima has the
following attributes which I think may not be shared with Sage.

1. You can download a windows installer for Maxima from sourceforge.
2. The default version of Maxima runs in GCL, which tends to be
substantially faster than other versions (like the one used by Sage?)
3. You can load the very latest version of Maxima.
4. There is a rather nice front end, wxmaxima, which includes
typesetting, plotting, etc.

There are relatively modest facilities for number theory, and group
theory in Maxima.

On the downside of this tex-generator stuff, I would like to point out
(as the author of the original version in Macsyma) that the exact
form of the generated TeX depends on the ordering of terms by the
automatic simplification programs. For all but the very simplest
expressions it is likely that a human would wish to see the result
tweaked somewhat to be "publication quality".

If this has not occurred to you, consider the display for expressions
m*x+c, x+c*m, e=c^2*m, f=a*m ...

RJF

[Robert Bradshaw]

I've actually never seen (1) used; (2) seems much more natural. The
"\int dx \int dy f" is strange as the "dx dy" is often best viewed as
single differential.

- Robert

[Golam Mortuza Hossain]

Hi,

Thanks Nick, Robert! OK, then we settle on (2) for integral.

The remaining issue is now to settle the conventions for derivative.
Currently, maxima uses "\\partial" symbol even for functions
of single variable. I think it would be better if we follow the
arguments of
http://trac.sagemath.org/sage_trac/ticket/4202
for derivative of function with single variable. So here are the situations

(1) diff( f(x), x) =>
--------------------
(a) Current scheme via Maxima:

{{{\it \partial}}\over{{\it \partial}\,x}}\,f\left(x\right)

(b) Proposed:
\frac{d f\left(x\right)}{d x}

(2) diff( f(x, y), x) =>
--------------------
(a) Current scheme via Maxima:
{{{\it \partial}}\over{{\it \partial}\,x}}\,f\left(x, y\right)

(b) Proposed:
\frac{\partial f\left(x, y\right)}{\partial x}

We follow similar scheme for higher derivatives.

Once this convention is settled, I will be ready to submit
the final patch including doc-tests.

Cheers,
Golam

[Tim Lahey]

My recommendation is:

\frac{\mathrm{d} f(x)}{\mathrm{d} x}

This ensures an upright d. It's what I use for all derivatives based
upon
"A Guide to LaTeX". Also, I'm not sure you really need to use \left and
\right for a single term. I think it's overkill. If you have multiple
terms
of varying heights, it makes sense, but not for a single letter or
number.

Cheers,

Tim.

---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://www.linkedin.com/in/timlahey

[rjf]

On Apr 5, 9:06 am, Golam Mortuza Hossain <gmhoss...@gmail.com> wrote:
> Hi,
>
> On Sat, Apr 4, 2009 at 4:06 PM, Robert Bradshaw
>

> <rober...@math.washington.edu> wrote:
>
> > On Apr 3, 2009, at 7:16 PM, Nick Alexander wrote:
>
> >>> (1)   \int dx f(x)
> >>> (2)   \int f(x) dx
>
> >> I prefer (2).
>
> > I've actually never seen (1) used; (2) seems much more natural. The
> > "\int dx \int dy f" is strange as the "dx dy" is often best viewed as
> > single differential.
>
> Thanks Nick, Robert! OK, then we settle on (2) for integral.

The only people I know who use the other ordering are physicists with
14-deep integrals, where associating the variable and the limits is
MUCH easier with version 1. There may be other people, too.

>
> The remaining issue is now to settle the conventions for derivative.
> Currently, maxima uses "\\partial"  symbol even for functions
> of single variable.

This does not seem to be true.

I just ran Maxima on 'diff(f(x),x) and I got this:

{d}\over{d\,x}}\,f\left(x\right)



So if it uses \partial, it is because Sage is messing it up.

> I think it would be better if we follow the

> arguments ofhttp://trac.sagemath.org/sage_trac/ticket/4202

> for derivative of function with single variable.  So here are the situations
>
> (1)  diff( f(x), x)   =>
> --------------------
>  (a)  Current scheme via Maxima:
>        {{{\it \partial}}\over{{\it \partial}\,x}}\,f\left(x\right)
>
>  (b) Proposed:
>        \frac{d f\left(x\right)}{d x}
>
> (2)  diff( f(x, y), x)   =>
> --------------------
>  (a)  Current scheme via Maxima:
>        {{{\it \partial}}\over{{\it \partial}\,x}}\,f\left(x, y\right)

>
>  (b) Proposed:
>        \frac{\partial f\left(x, y\right)}{\partial x}

I don't know what problem is being solved by this change, but the
notation for derivatives that you are proposing is inadequate for the
breadth of expressions possible. This has been well known in the CAS
community for decades.

For example, consider diff(f(x^2,y(x)^2), x), which could be
expanded to 2*x*f^(1)(f(x^2,y(x)^2)+ 2*y^(1)*y(x)*f^(2)(x^2,y(x)^2)
or some such. So you need a notation for the derivative of f or y
with respect to its first [positional] argument.
etc.
see
Differentiation of unknown functions in MACSYMA

Source ACM SIGSAM Bulletin archive
Volume 19 , Issue 2 (May 1985) table of contents
Pages: 19 - 24
Year of Publication: 1985
ISSN:0163-5824
Author
Jeffrey P. Golden

[William Stein]

On Sun, Apr 5, 2009 at 11:58 AM, rjf <fat...@gmail.com> wrote:
>
>
>
> On Apr 5, 9:06 am, Golam Mortuza Hossain <gmhoss...@gmail.com> wrote:
>> Hi,
>>
>> On Sat, Apr 4, 2009 at 4:06 PM, Robert Bradshaw
>>
>> <rober...@math.washington.edu> wrote:
>>
>> > On Apr 3, 2009, at 7:16 PM, Nick Alexander wrote:
>>
>> >>> (1)   \int dx f(x)
>> >>> (2)   \int f(x) dx
>>
>> >> I prefer (2).
>>
>> > I've actually never seen (1) used; (2) seems much more natural. The
>> > "\int dx \int dy f" is strange as the "dx dy" is often best viewed as
>> > single differential.
>>
>> Thanks Nick, Robert! OK, then we settle on (2) for integral.
>
> The only people I know who use the other ordering are physicists with
> 14-deep integrals, where associating the variable and the limits is
> MUCH easier with version 1. There may be other people, too.
>
>>
>> The remaining issue is now to settle the conventions for derivative.
>> Currently, maxima uses "\\partial"  symbol even for functions
>> of single variable.
>
> This does not seem to be true.
>
> I just ran Maxima on  'diff(f(x),x)  and I got this:
>
> {d}\over{d\,x}}\,f\left(x\right)
>
>
>
> So if it uses \partial, it is because Sage is messing it up.

You're right, it does not use partial for a single variable, even through Sage.

sage: m = maxima('integrate(sin(x^3),x)')
sage: m
'integrate(sin(x^3),x)
sage: m._latex_()
'\\int {\\sin x^3}{\\;dx}'
sage: latex(integrate(sin(x^3),x))
\int {\sin x^3}{\;dx}

William

[Golam Mortuza Hossain]

On Sun, Apr 5, 2009 at 4:05 PM, William Stein <wst...@gmail.com> wrote:
>
> On Sun, Apr 5, 2009 at 11:58 AM, rjf <fat...@gmail.com> wrote:
>
>> On Apr 5, 9:06 am, Golam Mortuza Hossain <gmhoss...@gmail.com> wrote:
>>> Hi,
>>>
>>> On Sat, Apr 4, 2009 at 4:06 PM, Robert Bradshaw

>> This does not seem to be true.
>>
>> I just ran Maxima on  'diff(f(x),x)  and I got this:
>>
>> {d}\over{d\,x}}\,f\left(x\right)
>>
>>
>> So if it uses \partial, it is because Sage is messing it up.
>
> You're right, it does not use partial for a single variable, even through Sage.
>
> sage: m = maxima('integrate(sin(x^3),x)')
> sage: m
> 'integrate(sin(x^3),x)
> sage: m._latex_()
> '\\int {\\sin x^3}{\\;dx}'
> sage: latex(integrate(sin(x^3),x))
> \int {\sin x^3}{\;dx}

May be I am missing something. Does typesetting of "diff" somehow
depend on typesetting of "integrate"?

If I try following in Sage (v3.4) I get "\partial" for function
with single variable. So it could be due to maxima-interface of Sage,
unless my sage installation is messed up.
-------------------------------------------

f(x) = function('f',x)

latex(diff(f(x),x))
---

{{{\it \partial}}\over{{\it \partial}\,x}}\,f\left(x\right)

-----------------------------------------

Cheers,
Golam

[William Stein]

Very good point! I just had a look and for some mysterious reason line 550 in

devel/sage/sage/interfaces/maxima.py

is

self._sendline(r":lisp (defun tex-derivative (x l r) (tex (if
$derivabbrev (tex-dabbrev x) (tex-d x '\\partial)) l r lop rop ))")

which means "change to use that partial when starting up any maxima interface".
I don't know why that is there or who wanted it.

william

[Golam Mortuza Hossain]

On Sun, Apr 5, 2009 at 3:58 PM, rjf <fat...@gmail.com> wrote:
>> So here are the situations
>>
>> (1)  diff( f(x), x)   =>
>> --------------------
>>  (a)  Current scheme via Maxima:
>>        {{{\it \partial}}\over{{\it \partial}\,x}}\,f\left(x\right)
>>
>>  (b) Proposed:
>>        \frac{d f\left(x\right)}{d x}
>>
>> (2)  diff( f(x, y), x)   =>
>> --------------------
>>  (a)  Current scheme via Maxima:
>>        {{{\it \partial}}\over{{\it \partial}\,x}}\,f\left(x, y\right)
>
>>
>>  (b) Proposed:
>>        \frac{\partial f\left(x, y\right)}{\partial x}
>
> I don't know what problem is being solved by this change, but the
> notation for derivatives that you are proposing is inadequate for the
> breadth of expressions possible. This has been well known in the CAS
> community for decades.
>
> For example, consider diff(f(x^2,y(x)^2), x),   which could be
> expanded to 2*x*f^(1)(f(x^2,y(x)^2)+ 2*y^(1)*y(x)*f^(2)(x^2,y(x)^2)
> or some such.  So you need a notation for the derivative of f or y
> with respect to its first [positional] argument.
> etc.

I certainly agree that the form I wrote, will not be adequate for
many situations.

I am trying to see here which latex representation is preferred for
an already evaluated/simplified/expanded expression that contains
"diff( f(x,y), x)".

Cheers,
Golam

[Golam Mortuza Hossain]

On Sun, Apr 5, 2009 at 1:15 PM, Tim Lahey <tim....@gmail.com> wrote:
> My recommendation is:
>
> \frac{\mathrm{d} f(x)}{\mathrm{d} x}
>
> This ensures an upright d. It's what I use for all derivatives based
> upon
> "A Guide to LaTeX". Also, I'm not sure you really need to use \left and
> \right for a single term. I think it's overkill. If you have multiple
> terms of varying heights, it makes sense, but not for a single letter or
> number.

I agree that using \left(, \right) for single term is overkilling
but this usage seems to be widespread. The reason is
during typesetting f(y), one calls latex() function recursively as
"y" itself could be a symbolic function like y(x) and so on.

Nevertheless, one can improve this by checking
whether the argument is an instance of symbolic variable.

Cheers,
Golam

[Jason Grout]

Interesting. Some time ago, I posted code at #4202 to do intelligent
things with partial derivatives. Golam's patch is probably better, though.

#3717 is also a related ticket.

Jason

[Golam Mortuza Hossain]

Hi,

... So here goes the patch to enhance the typesetting capability
of symbolic functions within sage. It includes several doc-tests
for each functions.

Main features are:

(1) Symbolics functions with name in Greek letters (with possible
suffixes), are typeset nicely in LaTeX.

Ex: psi(x) => \psi(x)

(2) Functions such as "diff", "integrate", "limit", "conjugate",
"laplace", "inverse_lapse" are now typeset within Sage itself.

Ex: psi(x).conjugate() => {\psi}^*(x)

(3) Default (fall-back) typesetting for unknown functions (as
in Maxima).

Ex: myfn(x) => {\it myfn}(x)

(4) Allows users to define their own/custom LaTeX expression
for any symbolic functions via a new method "set_latex()" for
the class SymbolicFunctionEvaluation.

Ex: var('t');
hubble(t) = function('hubble',t)
hubble(t).set_latex('\\mathcal{H}')

#To reset custom LaTeX expression
hubble(t).set_latex()

(5) If the arguments of a symbolic function are all symbolic
variables then typesetting will avoid using \left(, \right).

Ex: Phi(x,y) => \Phi(x, y) (if x,y are symbolic vars)

Note: You need to apply a small patch

http://trac.sagemath.org/sage_trac/ticket/5678

before you apply the attached patch. This patch is
created using sage-3.4.

I will be happy to hear any issues that you may find
in it, before I open a ticket for this enhancement.

Cheers,
Golam

[Robert Bradshaw]

On Apr 7, 2009, at 8:48 AM, Golam Mortuza Hossain wrote:

> Hi,
>
>

> I will be happy to hear any issues that you may find
> in it, before I open a ticket for this enhancement.

I've only been marginally following this issue (thanks for all your
work on it BTW) but typically it's better to create tickets sooner
rather than later. (In fact, the policy is to create tickets when you
start working on something, to avoid duplication of effort).

- Robert

[Golam Mortuza Hossain]

On Tue, Apr 7, 2009 at 3:14 PM, Robert Bradshaw
<robe...@math.washington.edu> wrote:
>> Hi,
>>
>>
>> I will be happy to hear any issues that you may find
>> in it, before I open a ticket for this enhancement.
>
> I've only been marginally following this issue (thanks for all your
> work on it BTW) but typically it's better to create tickets sooner
> rather than later. (In fact, the policy is to create tickets when you
> start working on something, to avoid duplication of effort).

Thanks, so here is the ticket

http://trac.sagemath.org/sage_trac/ticket/5711

I will be happy to address any comments/concern from
the reviewer.

Cheers,
Golam