latex symbols in fmtmathjax
31 views
Skip to first unread message
Ralf Hemmecke
May 1, 2021, 8:29:19 AM5/1/21
to fricas-devel
There are obviously already people using jfricas.
I was asked for a feature to allow greek letters and other stuff.
While it is easily possible to do this with UTF-8 encoding like
delta := "𝛿"::Symbol
and show nicely in jfricas with FormatMathJax enabled.
However, right-clicking on the output and exporting the expression as
TeX, gives back a UTF-8 symbol. If you want to include that expression
in a LaTeX document, then one must enable the right encoding. In my
experience you need something like lualatex or xelatex to work reliably
with 8bit characters.
So it makes sense to support LaTeX symbols in the MathJax output for
jFriCAS. Currently the backslash is translated into {\backslash} and
thus shows as a literal backslash in the output.
After this patch a symbol name that starts with \ is directly handed to
the output unaltered so that it can be interpreted by MathJax.
Of course, that feature can be switched on and off, see below.
(2) -> setFormat!(FormatMathJax)$JFriCASSupport;
(3) -> delta := "\delta"::Symbol; NN := "\mathcal{N}"::Symbol;
(4) -> sin(delta+NN)
--FORMAT:BEG:FormatMathJax
\[
\sin\left({\backslash}mathcal\{N\}+{\backslash}delta\right)
\]
--FORMAT:END:FormatMathJax
(5) -> setPrettySymbols!(true)$FormatMathJax;
(6) -> sin(delta+NN)
--FORMAT:BEG:FormatMathJax
\[
\sin\left(\mathcal{N}+\delta\right)
\]
--FORMAT:END:FormatMathJax
Comments are welcome.
If I do not hear something, I will commit it next Tuesday.
https://github.com/hemmecke/fricas/commit/a584d857a623be6be35bd5641cc1a584b22adcad
Ralf
I was asked for a feature to allow greek letters and other stuff.
While it is easily possible to do this with UTF-8 encoding like
delta := "𝛿"::Symbol
and show nicely in jfricas with FormatMathJax enabled.
However, right-clicking on the output and exporting the expression as
TeX, gives back a UTF-8 symbol. If you want to include that expression
in a LaTeX document, then one must enable the right encoding. In my
experience you need something like lualatex or xelatex to work reliably
with 8bit characters.
So it makes sense to support LaTeX symbols in the MathJax output for
jFriCAS. Currently the backslash is translated into {\backslash} and
thus shows as a literal backslash in the output.
After this patch a symbol name that starts with \ is directly handed to
the output unaltered so that it can be interpreted by MathJax.
Of course, that feature can be switched on and off, see below.
(2) -> setFormat!(FormatMathJax)$JFriCASSupport;
(3) -> delta := "\delta"::Symbol; NN := "\mathcal{N}"::Symbol;
(4) -> sin(delta+NN)
--FORMAT:BEG:FormatMathJax
\[
\sin\left({\backslash}mathcal\{N\}+{\backslash}delta\right)
\]
--FORMAT:END:FormatMathJax
(5) -> setPrettySymbols!(true)$FormatMathJax;
(6) -> sin(delta+NN)
--FORMAT:BEG:FormatMathJax
\[
\sin\left(\mathcal{N}+\delta\right)
\]
--FORMAT:END:FormatMathJax
Comments are welcome.
If I do not hear something, I will commit it next Tuesday.
https://github.com/hemmecke/fricas/commit/a584d857a623be6be35bd5641cc1a584b22adcad
Ralf
Bill Page
May 1, 2021, 9:53:31 AM5/1/21
to fricas...@googlegroups.com
On Sat, May 1, 2021 at 8:29 AM Ralf Hemmecke <ra...@hemmecke.org> wrote:
...
After this patch a symbol name that starts with \ is directly handed to
the output unaltered so that it can be interpreted by MathJax.
+1
Andrey G. Grozin
May 1, 2021, 10:21:00 AM5/1/21
to fricas-devel
On Sat, 1 May 2021, Ralf Hemmecke wrote:
> While it is easily possible to do this with UTF-8 encoding like
>
> delta := "𝛿"::Symbol
>
> and show nicely in jfricas with FormatMathJax enabled.
> However, right-clicking on the output and exporting the expression as
> TeX, gives back a UTF-8 symbol. If you want to include that expression
> in a LaTeX document, then one must enable the right encoding. In my
> experience you need something like lualatex or xelatex to work reliably
> with 8bit characters.
Why? Normal pdflatex (and, I think, latex) work fine with UTF-8, if you
> While it is easily possible to do this with UTF-8 encoding like
>
> delta := "𝛿"::Symbol
>
> and show nicely in jfricas with FormatMathJax enabled.
> However, right-clicking on the output and exporting the expression as
> TeX, gives back a UTF-8 symbol. If you want to include that expression
> in a LaTeX document, then one must enable the right encoding. In my
> experience you need something like lualatex or xelatex to work reliably
> with 8bit characters.
include
\usepackage[utf8]{inputenc}
in the preamble. I always use this line when writing LaTeX files in
Russian. So, I think, UTF-8 symbols are fine for including in LaTeX.
Andrey
Waldek Hebisch
May 1, 2021, 10:22:35 PM5/1/21
to fricas...@googlegroups.com
On Sat, May 01, 2021 at 02:29:17PM +0200, Ralf Hemmecke wrote:
> There are obviously already people using jfricas.
> I was asked for a feature to allow greek letters and other stuff.
> While it is easily possible to do this with UTF-8 encoding like
>
> delta := "????"::Symbol
> There are obviously already people using jfricas.
> I was asked for a feature to allow greek letters and other stuff.
> While it is easily possible to do this with UTF-8 encoding like
>
>
> and show nicely in jfricas with FormatMathJax enabled.
> However, right-clicking on the output and exporting the expression as
> TeX, gives back a UTF-8 symbol. If you want to include that expression
> in a LaTeX document, then one must enable the right encoding. In my
> experience you need something like lualatex or xelatex to work reliably
> with 8bit characters.
>
> So it makes sense to support LaTeX symbols in the MathJax output for
> jFriCAS. Currently the backslash is translated into {\backslash} and
> thus shows as a literal backslash in the output.
>
> After this patch a symbol name that starts with \ is directly handed to
> the output unaltered so that it can be interpreted by MathJax.
That breaks normal rules: OutputForm is supposed to give equivalent
> and show nicely in jfricas with FormatMathJax enabled.
> However, right-clicking on the output and exporting the expression as
> TeX, gives back a UTF-8 symbol. If you want to include that expression
> in a LaTeX document, then one must enable the right encoding. In my
> experience you need something like lualatex or xelatex to work reliably
> with 8bit characters.
>
> So it makes sense to support LaTeX symbols in the MathJax output for
> jFriCAS. Currently the backslash is translated into {\backslash} and
> thus shows as a literal backslash in the output.
>
> After this patch a symbol name that starts with \ is directly handed to
> the output unaltered so that it can be interpreted by MathJax.
output for all formatters. This proposal would create "LaTeX only"
OutputForm, which is quite undesirable.
Ideally, we would have single set of rules working for everywone.
ATM it seems that we need some compromises to provide desired
features. However, this "direct LaTeX" way seem much less clean
than say recoding Greek letters as LaTeX escapes. To say the
truth, in longer run teaching LaTeX to correctly handle Greek
letters seem more desirable. In my case the following seem
to work:
\usepackage[utf8x]{inputenc}
\def\textalpha{\alpha}
After that unicode alpha in formula correctly appears in the
output. Of course, that would have to be done for all
Greek math symbols. I would expect some ready-made package
to handle this, but the above is easier than searching trough
tons of packages...
--
Waldek Hebisch
Ralf Hemmecke
May 2, 2021, 10:00:13 AM5/2/21
to fricas...@googlegroups.com
Waldek,
Your message was not clear whether or not you want me to commit this to
FriCAS.
On 02.05.21 04:22, Waldek Hebisch wrote:
> That breaks normal rules:
Sorry, I haven't seen any documented rules about this.
> OutputForm is supposed to give equivalent
> output for all formatters.
You've just made this up, right? What is the definition of "equivalent"?
Is 𝛿 and \delta equivalent?
> This proposal would create "LaTeX only"
> OutputForm, which is quite undesirable.
Wrong. It never touches anything in OutputForm, only in FormatMathJax.
And most importantly it doesn't break anything since a user must switch
this feature on to work.
> Ideally, we would have single set of rules working for everywone.
Ideally Unicode was invented 100 years ago and OutputForm would not have
been primarily written to deal with the output of 2D-ASCII math.
> ATM it seems that we need some compromises to provide desired
> features.
Yes, that is why I wrote this extension.
> However, this "direct LaTeX" way seem much less clean
> than say recoding Greek letters as LaTeX escapes. To say the
> truth, in longer run teaching LaTeX to correctly handle Greek
> letters seem more desirable. In my case the following seem
> to work:
>
> \usepackage[utf8x]{inputenc}
> \def\textalpha{\alpha}
Of course, the usual "works for me" is not convincing.
I took some characters from
https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode
Works fine in FriCAS
(1) -> delta := "𝛿"::Symbol; NN := "𝓝"::Symbol; DD:="𝔻"::Symbol;Symbol;
Type: Symbol
(2) -> sin(DD+delta+NN)
(2) sin(𝛿 + 𝔻 + 𝓝)
Type: Expression(Integer)
and works perfectly in jFriCAS.
When I copy the output form the Jupyter notebook, it gives me
\sin\left(𝛿+𝔻+𝓝\right)
which is fine for lualatex, but not for pdflatex neither with utf8 nor
utf8x. See attached LaTeX file.
pdflatex -interaction=nonstopmode foo.tex
The utf8x package builds on the ucs package and a quick search reveals
that this is incompatible with biblatex.
Search ucs in the documentation of https://www.ctan.org/pkg/biblatex .)
I wouldn't want to sacrifice biblatex just for having a delta in FriCAS
output.
As you can see in the attachement your
\def\textdelta{\delta}
only helps partially.
I don't know why it would be such a bad idea to make the life of our
users easy.
Furthermore, I am happy to remove that stuff from FormatMathJax, if we
enter an ideal world and everyone is using a unicode-aware LaTeX.
Ralf
Your message was not clear whether or not you want me to commit this to
FriCAS.
On 02.05.21 04:22, Waldek Hebisch wrote:
> That breaks normal rules:
Sorry, I haven't seen any documented rules about this.
> OutputForm is supposed to give equivalent
> output for all formatters.
Is 𝛿 and \delta equivalent?
> This proposal would create "LaTeX only"
> OutputForm, which is quite undesirable.
And most importantly it doesn't break anything since a user must switch
this feature on to work.
> Ideally, we would have single set of rules working for everywone.
been primarily written to deal with the output of 2D-ASCII math.
> ATM it seems that we need some compromises to provide desired
> features.
> However, this "direct LaTeX" way seem much less clean
> than say recoding Greek letters as LaTeX escapes. To say the
> truth, in longer run teaching LaTeX to correctly handle Greek
> letters seem more desirable. In my case the following seem
> to work:
>
> \usepackage[utf8x]{inputenc}
> \def\textalpha{\alpha}
I took some characters from
https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode
Works fine in FriCAS
(1) -> delta := "𝛿"::Symbol; NN := "𝓝"::Symbol; DD:="𝔻"::Symbol;Symbol;
Type: Symbol
(2) -> sin(DD+delta+NN)
(2) sin(𝛿 + 𝔻 + 𝓝)
Type: Expression(Integer)
and works perfectly in jFriCAS.
When I copy the output form the Jupyter notebook, it gives me
\sin\left(𝛿+𝔻+𝓝\right)
which is fine for lualatex, but not for pdflatex neither with utf8 nor
utf8x. See attached LaTeX file.
pdflatex -interaction=nonstopmode foo.tex
The utf8x package builds on the ucs package and a quick search reveals
that this is incompatible with biblatex.
Search ucs in the documentation of https://www.ctan.org/pkg/biblatex .)
I wouldn't want to sacrifice biblatex just for having a delta in FriCAS
output.
As you can see in the attachement your
\def\textdelta{\delta}
only helps partially.
I don't know why it would be such a bad idea to make the life of our
users easy.
Furthermore, I am happy to remove that stuff from FormatMathJax, if we
enter an ideal world and everyone is using a unicode-aware LaTeX.
Ralf
Bill Page
May 2, 2021, 11:29:57 AM5/2/21
to fricas...@googlegroups.com
Ralf's proposed patch for FormatMathJax allows much more than just support of Unicode-like symbols. There are many cases when one might want to use a small but otherwise arbitrary LaTeX fragment as a more sophisticated way to represent some symbol.
--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/daeb853d-5874-03e2-d2b7-17e5c1e9418b%40hemmecke.org.
Kurt Pagani
May 2, 2021, 2:41:57 PM5/2/21
to fricas...@googlegroups.com
On 02.05.2021 17:29, Bill Page wrote:
> Ralf's proposed patch for FormatMathJax allows much more than just support of
> Unicode-like symbols. There are many cases when one might want to use a small
> but otherwise arbitrary LaTeX fragment as a more sophisticated way to represent
> some symbol.
++1
> Ralf's proposed patch for FormatMathJax allows much more than just support of
> Unicode-like symbols. There are many cases when one might want to use a small
> but otherwise arbitrary LaTeX fragment as a more sophisticated way to represent
> some symbol.
In my view it's simpy great. For example, one can (deliberately!) write
a:="\alpha"::Symbol or hb := "\hbar"::Symbol::EXPR INT, then 'a', 'hb' will be
rendered as 𝛼,ℏ as soon as we set
setPrettySymbols! true
It does no harm to OutputForm at all; moreover, one is not urged to use special
identifiers (like alpha, %alpha, ...) and, last but not least, it works for
BasicOperator as well :)
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/daeb853d-5874-03e2-d2b7-17e5c1e9418b%40hemmecke.org
> <https://groups.google.com/d/msgid/fricas-devel/daeb853d-5874-03e2-d2b7-17e5c1e9418b%40hemmecke.org>.
> https://groups.google.com/d/msgid/fricas-devel/daeb853d-5874-03e2-d2b7-17e5c1e9418b%40hemmecke.org
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to fricas-devel...@googlegroups.com
> <mailto:fricas-devel...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to fricas-devel...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/CAC6x94QpFrbjC%3DGfSrZvPEwg1Awi2%2BnA0awktz9wSqAAUeT-PA%40mail.gmail.com
> <https://groups.google.com/d/msgid/fricas-devel/CAC6x94QpFrbjC%3DGfSrZvPEwg1Awi2%2BnA0awktz9wSqAAUeT-PA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Waldek Hebisch
May 2, 2021, 3:02:13 PM5/2/21
to fricas...@googlegroups.com
On Sun, May 02, 2021 at 11:29:44AM -0400, Bill Page wrote:
> Ralf's proposed patch for FormatMathJax allows much more than just support
> of Unicode-like symbols. There are many cases when one might want to use a
> small but otherwise arbitrary LaTeX fragment as a more sophisticated way to
> represent some symbol.
That part of reason why I view it as problematic: it is not something
> Ralf's proposed patch for FormatMathJax allows much more than just support
> of Unicode-like symbols. There are many cases when one might want to use a
> small but otherwise arbitrary LaTeX fragment as a more sophisticated way to
> represent some symbol.
localized but in principle has very wide scope.
--
Waldek Hebisch
Ralf Hemmecke
May 2, 2021, 3:56:54 PM5/2/21
to fricas...@googlegroups.com
How is that detrimental to FriCAS itself?
Ralf
Bill Page
May 3, 2021, 12:10:01 PM5/3/21
to fricas...@googlegroups.com
If it is necessary to consider alternatives, then I think one other approach would be to export a function that sets a "presentation" property on a Symbol and then make use of that property (if it exists) and if the flag is set in FormatMathJax. The benefit then might be that a formatter would have a choice as to whether to use the presentation property string or not.
--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210502190206.GA32321%40math.uni.wroc.pl.
Kurt Pagani
May 3, 2021, 1:19:43 PM5/3/21
to fricas...@googlegroups.com
On 03.05.2021 18:09, Bill Page wrote:
> If it is necessary to consider alternatives, then I think one other approach
> would be to export a function that sets a "presentation" property on a Symbol
> and then make use of that property (if it exists) and if the flag is set in
> FormatMathJax. The benefit then might be that a formatter would have a choice as
> to whether to use the presentation property string or not.
Do you think of something like setProperty/display in BOP?
> If it is necessary to consider alternatives, then I think one other approach
> would be to export a function that sets a "presentation" property on a Symbol
> and then make use of that property (if it exists) and if the flag is set in
> FormatMathJax. The benefit then might be that a formatter would have a choice as
> to whether to use the presentation property string or not.
https://fricas.github.io/api/BasicOperator.html
Or have I completely misread your suggestion?
I've been using the those methods for some time, e.g.
f:=operator 'f
display(f,o+->F)
f [x,y,z] -> F
properties f -> table(%display = NONE)
in order to suppress the arguments (enhancing readibility of large formulas),
however, it's not exatly brilliant :( - you'll notice that as soon as you need
derivatives.
@Waldek
> it is not something
> localized but in principle has very wide scope.
Admitted, however, what's wrong with this? It concerns MathJax only, and a
> localized but in principle has very wide scope.
sin(a) remains as is unless you define another representation for "a" - strictly
speaking, it's more like a substitution.
>
> On Sun, May 2, 2021 at 3:02 PM Waldek Hebisch <heb...@math.uni.wroc.pl
> <mailto:heb...@math.uni.wroc.pl>> wrote:
>
> On Sun, May 02, 2021 at 11:29:44AM -0400, Bill Page wrote:
> > Ralf's proposed patch for FormatMathJax allows much more than just support
> > of Unicode-like symbols. There are many cases when one might want to use a
> > small but otherwise arbitrary LaTeX fragment as a more sophisticated way to
> > represent some symbol.
>
> That part of reason why I view it as problematic: it is not something
> localized but in principle has very wide scope.
> --
> Waldek Hebisch
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fricas-devel...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/20210502190206.GA32321%40math.uni.wroc.pl
> <https://groups.google.com/d/msgid/fricas-devel/20210502190206.GA32321%40math.uni.wroc.pl>.
> https://groups.google.com/d/msgid/fricas-devel/20210502190206.GA32321%40math.uni.wroc.pl
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to fricas-devel...@googlegroups.com
> <mailto:fricas-devel...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to fricas-devel...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/CAC6x94TT56jftJRj-9Tc0Cn_tut9LYyTVUYiektzTxv8nQnJTA%40mail.gmail.com
> <https://groups.google.com/d/msgid/fricas-devel/CAC6x94TT56jftJRj-9Tc0Cn_tut9LYyTVUYiektzTxv8nQnJTA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Waldek Hebisch
May 3, 2021, 1:33:36 PM5/3/21
to fricas...@googlegroups.com
On Mon, May 03, 2021 at 12:09:49PM -0400, Bill Page wrote:
> If it is necessary to consider alternatives, then I think one other
> approach would be to export a function that sets a "presentation" property
> on a Symbol and then make use of that property (if it exists) and if the
> flag is set in FormatMathJax. The benefit then might be that a formatter
> would have a choice as to whether to use the presentation property string
> or not.
Yes, that is direction that I have in mind. Such property is
> If it is necessary to consider alternatives, then I think one other
> approach would be to export a function that sets a "presentation" property
> on a Symbol and then make use of that property (if it exists) and if the
> flag is set in FormatMathJax. The benefit then might be that a formatter
> would have a choice as to whether to use the presentation property string
> or not.
formatter specific, so should be settable per formatter (possibly
as hash table in formatter).
--
Waldek Hebisch
Bill Page
May 3, 2021, 1:35:23 PM5/3/21
to fricas...@googlegroups.com
On Mon, May 3, 2021 at 1:19 PM Kurt Pagani <nil...@gmail.com> wrote:
>
> On 03.05.2021 18:09, Bill Page wrote:
> > If it is necessary to consider alternatives, then I think one other approach
> > would be to export a function that sets a "presentation" property on a Symbol
> > and then make use of that property (if it exists) and if the flag is set in
> > FormatMathJax. The benefit then might be that a formatter would have a choice as
> > to whether to use the presentation property string or not.
>
> Do you think of something like setProperty/display in BOP?
> https://fricas.github.io/api/BasicOperator.html
Yes, but probably a new property just to specify an alternate
>
> On 03.05.2021 18:09, Bill Page wrote:
> > If it is necessary to consider alternatives, then I think one other approach
> > would be to export a function that sets a "presentation" property on a Symbol
> > and then make use of that property (if it exists) and if the flag is set in
> > FormatMathJax. The benefit then might be that a formatter would have a choice as
> > to whether to use the presentation property string or not.
>
> Do you think of something like setProperty/display in BOP?
> https://fricas.github.io/api/BasicOperator.html
presentation for a particular symbol. Perhaps there could be several
such alternatives of interest to different formatters. But if no
relevant property exists or if for some reason it might be undesirable
in a certain context then the fall back would be to just treat it the
way it is done now.
Of course more sophisticated things are possible. For example it might
be nice to have some way to pass (sub/super/...)-scripts to the
frontend formatter for substitution into a LaTeX snippet, i.e. like
arguments to a macro.
> Or have I completely misread your suggestion?
>
> I've been using the those methods for some time, e.g.
> f:=operator 'f
> display(f,o+->F)
> f [x,y,z] -> F
> properties f -> table(%display = NONE)
>
> in order to suppress the arguments (enhancing readibility of large formulas),
> however, it's not exatly brilliant :( - you'll notice that as soon as you need
> derivatives.
>
little and included in FriCAS.
> @Waldek
> > it is not something
> > localized but in principle has very wide scope.
>
> Admitted, however, what's wrong with this? It concerns MathJax only, and a
> sin(a) remains as is unless you define another representation for "a" - strictly
> speaking, it's more like a substitution.
>
worksheet is to be presented in another format, e.g. a worksheet
prepared in jfricas but later you want to use it in TeXmacs.
Ralf Hemmecke
May 3, 2021, 4:21:56 PM5/3/21
to fricas...@googlegroups.com
> Of course more sophisticated things are possible. For example it might
> be nice to have some way to pass (sub/super/...)-scripts to the
> frontend formatter for substitution into a LaTeX snippet, i.e. like
> arguments to a macro.
Do you mean something like FormatLaTeX implements?
> be nice to have some way to pass (sub/super/...)-scripts to the
> frontend formatter for substitution into a LaTeX snippet, i.e. like
> arguments to a macro.
setFormats!([FormatLaTeX, FormatMathJax])$JFriCASSupport
(4) -> a[3]^b
b
(4) a
3
--FORMAT:BEG:FormatLaTeX
\begin{fricasmath}{4}
\SUPER{\PAREN{\SUB{\SYMBOL{a}}{3}}}{\SYMBOL{b}}
\end{fricasmath}
--FORMAT:END:FormatLaTeX
--FORMAT:BEG:FormatMathJax
\[
{\left({a}_{3}\right)}^{b}
\]
--FORMAT:END:FormatMathJax
Define \SUB and \SUPER in any way you like. The stuff in fricasmath.sty
is just a default setting.
Ralf
Ralf Hemmecke
May 3, 2021, 4:32:32 PM5/3/21
to fricas...@googlegroups.com
> I can see that the current proposal might be undesirable if the same
> worksheet is to be presented in another format, e.g. a worksheet
> prepared in jfricas but later you want to use it in TeXmacs.
OK, I as a user prepare some cool stuff in jfricas and then I have some
> worksheet is to be presented in another format, e.g. a worksheet
> prepared in jfricas but later you want to use it in TeXmacs.
work to make it look nice in Texmacs. Why is that a problem that FriCAS
should deal with?
If you aim at using a worksheet in both jfricas and texmacs, then use
unicode. If, however, you solely use the jfricas interface and want the
computed result for easy inclusion in a slide or other LaTeX document,
then use my proposal.
Up to now nobody has given one single good reason that would speak
against inclusion in FriCAS.
Anyway, if my proposal is not included then I would like to postpone the
release until a proper substitute is ready. Otherwise you needlessly
prevent people from doing cool stuff with FriCAS.
Ralf
Waldek Hebisch
May 3, 2021, 6:00:33 PM5/3/21
to fricas...@googlegroups.com
On Mon, May 03, 2021 at 10:32:31PM +0200, Ralf Hemmecke wrote:
> > I can see that the current proposal might be undesirable if the same
> > worksheet is to be presented in another format, e.g. a worksheet
> > prepared in jfricas but later you want to use it in TeXmacs.
>
> OK, I as a user prepare some cool stuff in jfricas and then I have some
> work to make it look nice in Texmacs. Why is that a problem that FriCAS
> should deal with?
>
> If you aim at using a worksheet in both jfricas and texmacs, then use
> unicode. If, however, you solely use the jfricas interface and want the
> computed result for easy inclusion in a slide or other LaTeX document,
> then use my proposal.
If nobody uses your code, then problem is greatly limited, but
> > I can see that the current proposal might be undesirable if the same
> > worksheet is to be presented in another format, e.g. a worksheet
> > prepared in jfricas but later you want to use it in TeXmacs.
>
> OK, I as a user prepare some cool stuff in jfricas and then I have some
> work to make it look nice in Texmacs. Why is that a problem that FriCAS
> should deal with?
>
> If you aim at using a worksheet in both jfricas and texmacs, then use
> unicode. If, however, you solely use the jfricas interface and want the
> computed result for easy inclusion in a slide or other LaTeX document,
> then use my proposal.
not gone. But to use your code people have to embed LaTeX
construct into things that should be pure math. You create
completely unnecessary fragmentation: to get what that want
in your proposal users have to create LaTeX-specific code,
which will fail with other formatters, or ignore your
feature. I could understand it if it was impossible to do
better. But there are _clearly_ better alternatives.
First, formatter may replace Unicode characters by appropriate
control sequences. AFAIK Unicode characters works fine in MathML
and there is support in Texmacs (I am unable to test it, but
is right way to go). Currently Unicode characters works also
on most terminals, so in text modes. So natural thing is to
make sure that they work with LaTeX. You say that there
are troubles on LaTeX side. In such case it is reasonable
to do substitution in the formatter: for supported characters
replace Unicode by appropriate LaTeX control sequences.
You write about "cool stuff", however need to mess with
LaTeX control sequences is very un-cool and rather
make impression of immature system that can not do
things properly.
There is also question of documentation: without documentation
such feature is much less useful. If it is documented, then
there will be confusion if we remove it (obsolete info tends
to have long life on the web).
Another things is that code that we offer should be a good
example. Unfortunatly, beginers frequently fall into trap
of "getting something to work" and follow bad examples.
In your proposal users are encouraged to follow bad
coding pattern and this patten is visible (as opposed
to something encapsulated in it own ghetto).
More generaly, FriCAS strength is its principled design.
In short term, by breaking principles one can frequently
make gains, this is called technical debt. But like
real debt, we either have to pay it back (clean up
things) or face insolvence. Technical debt means that
there will be increased cost of further developement
and IMO in most cases is wrong choice.
--
Waldek Hebisch
Reply all
Reply to author
Forward
0 new messages