$$\begin{align*}a_1=\alpha _1+\alpha _2+\cdots+\alpha _n,a_2=\alpha _1\alpha _2+\alpha _1\alpha _3+\cdots+\alpha _{n-1}\alpha _n,\cdots a_1 \end{align*}$$
Delete a_1 in the above, then that could be shown well.
$$\begin{align*}a_1=\alpha _1+\alpha _2+\cdots+\alpha _n,a_2=\alpha _1\alpha _2+\alpha _1\alpha _3+\cdots+\alpha _{n-1}\alpha _n,\cdots \end{align*}$$
http://hypergroups.pancakeapps.com/Test/test.txt
Of course they can show well in Math.SE
$$\begin{align*}a_1=\alpha _1+\alpha _2+\cdots+\alpha _n,a_2=\alpha _1\alpha _2+\alpha _1\alpha _3+\cdots+\alpha _{n-1}\alpha _n,\cdots a_1 \end{align*}$$
$$\begin{align*}a_1=\alpha _1+\alpha _2+\cdots+\alpha _n,a_2=\alpha _1\alpha _2+\alpha _1\alpha _3+\cdots+\alpha _{n-1}\alpha _n,\cdots \end{align*}$$
The MathJax here and Pancake are not the same?
If you look into the HTML source, you'll notice <em> tags within the equation I'm guessing from a Markdown conversion. MathJax's TeX parser stops at HTML tags (and skips incomplete equations).
You need to prevent the Markdown parser from messing up the TeX code. That's not trivial but there are many solutions out there; see for example this answer from MathJax's lead developer.
Related
I'm using beautiful soup to parse email invoices and I'm running into consistent problem involving special characters.
The text I am trying to parse is shown in the image.
But what I get from beautiful soup after finding the element and calling elem.text is this:
'Hi Mike, It=E2=80=\r\n=99s probably not a big drama if you are having problems separating product=\r\ns from classes. It is not uncommon to receive an order for pole classes and=\r\n a bottle of Dry Hands.\r\nAlso, remember that we will have just straight up product orders that your =\r\nsystem will not be able to place into a class list, hence having the extra =\r\nsheet for any =E2=80=9Cerroneous=E2=80=9D orders will be handy.'
As you can see the apostrophe is now represented by "=E2=80=99", double quotes are "=E2=80=9C" and "=E2=80=9D" and there are seemingly random newlines in the text, for example "product=\r\ns".
The newlines don't seem to appear in the image.
Apparently "E2 80 99" is the unicode hex representation of ' , but I don't understand why I can still see it in this form after having done email.decode('utf-8') before sending it to beautiful soup.
This is the element
<td border:="" class='3D"td"' left="" middle="" padding:="" solid="" style='3D"color:' text-align:="" v="ertical-align:">Hi Mike, It=E2=80=
=99s probably not a big drama if you are having problems separating product=
s from classes. It is not uncommon to receive an order for pole classes and=
a bottle of Dry Hands.
Also, remember that we will have just straight up product orders that your =
system will not be able to place into a class list, hence having the extra =
sheet for any =E2=80=9Cerroneous=E2=80=9D orders will be handy.</td>
I can post my code if required but I figure I must be making a simple mistake.
I checked out the answer to this question
Decode Hex String in Python 3
but i think that expects the entire string to be hex rather than just having random hex parts.
but I'm honestly not even sure how to search for "decode partial hex strings"
My final questions are
Q1 How do I convert
'Hi Mike, It=E2=80=\r\n=99s probably not a big drama if you are having problems separating product=\r\ns from classes. It is not uncommon to receive an order for pole classes and=\r\n a bottle of Dry Hands.\r\nAlso, remember that we will have just straight up product orders that your =\r\nsystem will not be able to place into a class list, hence having the extra =\r\nsheet for any =E2=80=9Cerroneous=E2=80=9D orders will be handy.'
into
'Hi Mike, It's probably not a big drama if you are having problems separating products from classes. It is not uncommon to receive an order for pole classes and=\r\n a bottle of Dry Hands.Also, remember that we will have just straight up product orders that your system will not be able to place into a class list, hence having the extra sheet for any "erroneous" orders will be handy.'
using python 3, without manually fixing each string and writing a replace method for each possible character.
Q2 Why does this "=\r\n" appear everywhere in my string but not in the rendered html?
#JosefZ's comment lead me to the answer.
Q1 has an answer.
>>> import quopri
>>> print(quopri.decodestring(mystring).decode('utf-8'))
Hi Mike, It’s probably not a big drama if you are having problems separating products from classes. It is not uncommon to receive an order for pole classes and a bottle of Dry Hands.
Also, remember that we will have just straight up product orders that your system will not be able to place into a class list, hence having the extra sheet for any “erroneous” orders will be handy.
Q2 Thanks to #snakecharmerb I now know that the seemingly random unrepresented line endings are to enforce a line length of 80 characters.
#snakecharmerb wrote a much better answer than this one to someone with the same problem as me here.
https://stackoverflow.com/a/55295640/992644
In Haddock, the "inline code"¹ markup, #...#, is the same as the "code block" markup,
#
...
#
How can I write a single-line Haddock comment that consists only of an inline code span, without it being misinterpreted as a block? A comment like
-- |#/code/ span#
renders as the block
code span
instead of the desired inline
code span
The context, in case more examples help, is that I'm writing a data type that represents a BNF grammar, and so I have a number of types that look like the following:
-- |#/term/ ::=#
data Term = Var Name -- ^#/name/#
| Plus Term Term -- ^#/term/ + /term/#
| Print Term -- ^#print /term/#
This example corresponds to the grammar
term ::= name
| term + term
| print term
and so the grammar is embedded in the Haddock comments. But since Haddock parses those #...# comments as blocks, the output is unnecessarily tall, and is inconsistent when some lines have extra comment text (e.g., -- ^#double /term/# – syntax sugar).
¹ A.k.a. "monospaced" or "typewriter".
Here is a suggested dirty hack. Your problem is that your lines only have code, and not text, correct? Well, just add, after the code, a bit of meaningless text. You can use the &#xH; format to insert hexcodes of unicode characters, for example zero-width or nonbreaking spaces. I would imagine that this would let you convince haddock that you are in an inline rather than block context.
Experimenting with Mathjax on my site, I face a problem when I type in
$1<x<2$
The outcome will be as follows
This, for example, has no issues.
$x<1\text{ or }x>2$
How do I make the first one display normally?
I have attached the issue at http://teach.sg/mathematics/additional-mathematics/mathjax/.
Since < is used to start a tag in HTML, the browser considers 1<x to be a 1 followed by a tag beginning <x, and everything up to the next > becomes part of that tag. This happens long before MathJax has a chance to look for mathematics on the page, so MathJax is not able to process this math as you intended it.
You have already identified one solution (using \lt and \gt) You can also just use spaces in most cases: $1 < x < 2$.
Instead of using $1<x<2$, use $1\lt x \lt 2$.
I'd like to use latex notation for equations in my source code.
For example, I would write the following comment in some haskell source file Equations.hs:
-- | $v = \frac{dx}{dt}$
In the doc directory, this gets rendered by haddock in Equations.tex as:
{\char '44}v = frac{\char '173}dx{\char '175}{\char '173}dt{\char '175}{\char '44}
I found this function in the source for Haddock's latex backend that replaces many characters that are used in latex formatting:
latexMunge :: Char -> String -> String
...
latexMunge '$' s = "{\\char '44}" ++ s
Is there any existing functionality that allows me to bypass this and insert latex equations in comments?
No. The main reason why this (and similar features) don't exist is that it's unclear what to do with the markup in the other backends, be it HTML one, Hoogle one or whatever else someone might be using. This is fairly commonly requested but there is no common agreement and more importantly, no patches.
Technically we don't support the LaTeX backend, it's kept around compiling so that the Haskell Report can be produced. If you or someone else wants to give it some new life (and features) then we'll happily accept patches.
tl;dr: no can do. I know people simply pre-render LaTeX and insert the resulting images in with the image syntax.
I have a LaTeX document where I'd like the numbering of floats (tables and figures) to be in one numeric sequence from 1 to x rather than two sequences according to their type. I'm not using lists of figures or tables either and do not need to.
My documentclass is report and typically my floats have captions like this:
\caption{Breakdown of visualisations created.}
\label{tab:Visualisation_By_Types}
A quick way to do it is to put \addtocounter{table}{1} after each figure, and \addtocounter{figure}{1} after each table.
It's not pretty, and on a longer document you'd probably want to either include that in your style sheet or template, or go with cristobalito's solution of linking the counters.
The differences between the figure and table environments are very minor -- little more than them using different counters, and being maintained in separate sequences.
That is, there's nothing stopping you putting your {tabular} environments in a {figure}, or your graphics in a {table}, which would mean that they'd end up in the same sequence. The problem with this case (as Joseph Wright notes) is that you'd have to adjust the \caption, so that doesn't work perfectly.
Try the following, in the preamble:
\makeatletter
\newcounter{unisequence}
\def\ucaption{%
\ifx\#captype\#undefined
\#latex#error{\noexpand\ucaption outside float}\#ehd
\expandafter\#gobble
\else
\refstepcounter{unisequence}% <-- the only change from default \caption
\expandafter\#firstofone
\fi
{\#dblarg{\#caption\#captype}}%
}
\def\thetable{\#arabic\c#unisequence}
\def\thefigure{\#arabic\c#unisequence}
\makeatother
Then use \ucaption in your tables and figures, instead of \caption (change the name ad lib). If you want to use this same sequence in other environments (say, listings?), then define \the<foo> the same way.
My earlier attempt at this is in fact completely broken, as the OP spotted: the getting-the-lof-wrong is, instead of being trivial and only fiddly to fix, absolutely fundamental (ho, hum).
(For the afficionados, it comes about because \advance commands are processed in TeX's gut, but the content of the .lof, .lot, and .aux files is fixed in TeX's mouth, at expansion time, thus what was written to the files was whatever random value \#tempcnta had at the point \caption was called, ignoring the \advance calculations, which were then dutifully written to the file, and then ignored. Doh: how long have I know this but never internalised it!?)
Dutiful retention of earlier attempt (on the grounds that it may be instructively wrong):
No problem: try putting the following in the preamble:
\makeatletter
\def\tableandfigurenum{\#tempcnta=0
\advance\#tempcnta\c#figure
\advance\#tempcnta\c#table
\#arabic\#tempcnta}
\let\thetable\tableandfigurenum
\let\thefigure\tableandfigurenum
\makeatother
...and then use the {table} and {figure} environments as normal. The captions will have the correct 'Table/Figure' text, but they'll share a single numbering sequence.
Note that this example gets the numbers wrong in the listoffigures/listoftables, but (a) you say you don't care about that, (b) it's fixable, though probably mildly fiddly, and (c) life is hard!
I can't remember the syntax, but you're essentially looking for counters. Have a look here, under the custom floats section. Assign the counters for both tables and figures to the same thing and it should work.
I'd just use one type of float (let's say 'figure'), then use the caption package to remove the automatically added "Figure" text from the caption and deal with it by hand.