How to stop LaTeX from breaking math mode lines? - math

I keep encountering an awkward problem when I type out expressions in LaTeX where the text line in the compiled document cuts an expression/equation/math object in half. Of course, I make use of $$ $$ tags to ensure this doesn't happen for particularly hefty expressions or computations, but this isn't appropriate for small expressions that appear in expository text.
Is there something I can do to make sure LaTeX never chops a mathmode expression in half in the compiled document?

you can use \mbox around your equation
\mbox{$E = mc^2$}
This will prevent a line break in the equation if it is located close to the max text width, but may lead to the equation reaching over the end of the text body.

Here is a simple solution just appending a tilde ~ to equations.
Example borrowed from here
Instead of
$x = \{x\,|\,x\in\mathbb{R_{\ge0}}\}$
you would write
$~{x = \{x\,|\,x\in\mathbb{R_{\ge0}}\}}$

Related

What can I leverage (from R) to convert expressions with nested fractions from infix-notation to LaTeX?

I'd like something to convert pretty basic math expressions, having nested parentheses and fractions, to LaTeX notation. Like mathquill, but a function (or even the building blocks of one).
There seem to be some Lua and Haskell solutions in a pandoc/Rmarkdown context, but I can't use those, because (a) I'm scared of real languages, and (b) I'm generating PNGs (via webtex) to be featured in a flextable table, outside of a rendered document.
I'm inexperienced with regular expressions, so I don't know how to leverage something like this, but I'd appreciate any pointers if that seems like a productive path.
"Write a parser" is something best left to others, at least in my case!
Example expression below. Just a few levels of nesting, no big deal. I can bound it at, say, 5 levels, if that helps. And the input is parseable as an R expression—I can guarantee matched parentheses, for example.
(y0 - (y0/((1-y0)*exp(B*dx)+y0)))*Pop
Here's what I'd want in the case above. The \cdots are sugar; I can handle those.
\left(y0-\frac{y0}{\left(1-y0\right)\cdot\exp\left(B\cdot dx\right)+y0}\right)\cdot Pop
Visually:

Why use macros in Julia?

I was reading up on the documentation of macros and ran into the following under the `Hold up: why macros' section. The reasoning given to use macros is as follows:
Macros are necessary because they execute when code is parsed,
therefore, macros allow the programmer to generate and include
fragments of customized code before the full program is run
This leads me to wonder why someone would want to use "generate and include fragments of customized code before the full program is run". Can someone provide context as to why this would be beneficial and/or other good use cases for macros?
Let me give you my view on macros.
A macro basically is a code -> code function. It takes code (a Julia expression) as input and spits out code (a different Julia expression).
Why is this useful? It has multiple purposes:
compile time copy-and-paste: You don't have to write the same piece of code multiple times but instead can define a short macro that writes it for you wherever you put it. (example)
domain specific language (DSL): You can create special syntax that after the macros code -> code transform is replaced by pure Julia constructs. This is used in many packages to define special syntax, for example here and here.
code generation: Imagine you want to write a really long piece of code which, although being long, is very simple because it has some kind of pattern that repeats itself rather trivially. Writing that code by hand can be a pain (or even practically impossible). A macro can programmatically generate the code for you. One example is for-loop unrolling (see here and here). But even the #time macro isn't doing much more than just putting a bunch of Base.time_ns() function calls around the provided Julia expression.
special string parsing: If you type the literal 3.2 in Julia it will be parsed and interpreted as a Float64. Now, imagine you want to supply a number literally that goes beyond Float64 precision but would fit into a BigFloat. Typing big(3.123124812498124812498) won't work, because the literal number is first interpreted as a Float64 and then handed to the big function. Instead you need a way to tell Julia at parse time that this should become a BigFloat. This is handled by a #big_str 3.2 macro which (for convenience) can also be written as big"3.2". The latter is just syntactic sugar.
There might be many more applications of macros, but those are the most important to me.
Let me end by referencing Steven G. Johnson's great talk at JuliaCon 2019:
Most of the time, don't do metaprogramming :)

ASCII equivalent to \eqn{\bar{x}} in Rd files

I am writing the documentation for a function of an R package I am building.
In order to have a moderately nice aspect for the help file, I need the equivalent of \bar{x} in ASCII:
\eqn{\bar{x}}{ASCII equivalent}
Not sure there's a consensus on the best way to do this, it's more a matter of taste and clarity.
Having faced this issue myself, two solutions I have used are:
y = \eqn{\bar{x}}{xbar}
y = \eqn{\bar{x}}{mean(x)}
The advantage of the latter is that when the help is displayed as ASCII, the user can copy/paste (send) the text to an R process, getting an example value for y. This assumes that \bar{x} is shorthand for the mean, as is often the case.

Multiplication in R without using the multiplication sign

I like solving my math problems(high school) using R as it is faster than writing on a piece of paper. One problem I'm having is that I have to keep writing the multiplication sign, example:
9x^2 + 24x + 16 yields = Error: unexpected symbol in "9x"
Is there any way in R to multiply 4x, without having to write 4*x but only 4x?
Would save me some time in having to write one extra character the whole time! Thanks
No. Having a number in front of a character without any space simply isn't valid syntax in R.
Take a step back and look at the syntax rules for, say, Excel, Matlab, Python, Mathematica. Every language has its rules, generally (:-) ) with good reason. For example, in R, the following are legal object names:
foo
foo.bar
foo1
foo39
But 39foo is not legal. So if you wanted any sequence [0-9][Letters] or the reverse to indicate multiplication, you'd have a conflict with naming rules.

What are the main elements in a QR code?

I didn't know before about artistic or artwork QR codes, while checking some of these codes, they are completely different from the regular standard QR code, but how is it possible to create this kind of QR code without loosing it's value (the scan result is the same) ?
These QR Codes are the most ones that amazed me:
http://www.hongkiat.com/blog/qr-code-artworks/
The only thing in common is the 3 corners, and they're different in style.
So my question is, what are the elements that we should preserve while creating such QR Codes ?
The most important things are:
Dark-on-light
Very nearly square modules
Modest light border
Substantially preserve the three-finder patterns
... and the first line of modules around them, which carries format info
... and the bottom-right alignment pattern, is helpful
The rest, the interior, can be substantially obscured and still be readable, certainly with high error correction. But messing with the elements above will tend to make it unreadable much more rapidly

Resources