As a newcomer to Julia this month, Sept. 2018, I am just getting used to the initially unfamiliar "#" symbol for macros and "!" symbol for functions with mutable inputs. Am I right to assume that these are merely stylistic symbols for humans to read, and that they do not really provide any information to the compiler?
I bring this up in the context of the following code that does not seem to match the style of a macro, a function, or anything else in Julia I am aware of. I am specifically asking about big"1234" below:
julia> big"1234" # big seems to be neither a macro or a function.
1234
julia> typeof(big"1234")
BigInt
julia> typeof(BigInt(1234))
BigInt
My question is: What is big in big"1234"?
Edit: I think I got my answer based on a comment at https://discourse.julialang.org/t/bigfloat-promotion-rules-and-constants-in-functions/14573/4
"Note that because decimal literals are converted to floating point numbers when parsed, BigFloat(2.1) may not yield what you expect. You may instead prefer to initialize constants from strings via parse, or using the big string literal.
julia> BigFloat(2.1)
2.100000000000000088817841970012523233890533447265625
julia> big"2.1"
2.099999999999999999999999999999999999999999999999999999999999999999999999999986"
Thus, based on the above comment, big in big"1234" is a "big string literal."
Edit 2: The above is a start at the answer, but the accepted answer below is much more complete.
These are Non-Standard String Literals. They tell the compiler that xyz"somestring" should be parsed via a macro function named #xyz_str.
The difference between BigFloat(2.1) and big"2.1" is that the former does convert the standard Float64 representation of the "numeric" literal 2.1 to BigFloat but the latter parses the string "2.1" directly (without interpreting it as a numeric literal) with the macro #big_str to compute the BigFloat representation.
You can also define your Non-Standard String Literals. LaTeXStrings.jl for example uses it to make it easier to type LaTeX equations.
Please take a look at: https://docs.julialang.org/en/v1/manual/metaprogramming/#Non-Standard-String-Literals-1
Related
The 'xor'-operator in julia is defined by the following symbol: ⊻
If I am not mistaken this is also the only symbol representing 'xor'.
How are you supposed to type this conveniently?
Am I supposed to copy or paste it into my code or remember the unicode representation by heart?
Julia's REPL has LaTeX-like tab-completion, so you can use \xor<tab>. If you paste the character in the help mode (pressing ? in the REPL) you can see how such character tab-completes:
help?> ⊻
"⊻" can be typed by \xor<tab>
help?> α
"α" can be typed by \alpha<tab>
Many editors have similar tab-completions.
I work with knitr() and I wish to transform inline Latex commands like "\label" and "\ref", depending on the output target (Latex or HTML).
In order to do that, I need to (programmatically) generate valid R strings that correctly represent the backslash: for example "\label" should become "\\label". The goal would be to replace all backslashes in a text fragment with double-backslashes.
but it seems that I cannot even read these strings, let alone process them: if I define:
okstr <- function(str) "do something"
then when I call
okstr("\label")
I directly get an error "unrecognized escape sequence"
(of course, as \l is faultly)
So my question is : does anybody know a way to read strings (in R), without using the escaping mechanism ?
Yes, I know I could do it manually, but that's the point: I need to do it programmatically.
There are many questions that are close to this one, and I have spent some time browsing, but I have found none that yields a workable solution for this.
Best regards.
Inside R code, you need to adhere to R’s syntactic conventions. And since \ in strings is used as an escape character, it needs to form a valid escape sequence (and \l isn’t a valid escape sequence in R).
There is simply no way around this.
But if you are reading the string from elsewhere, e.g. using readLines, scan or any of the other file reading functions, you are already getting the correct string, and no handling is necessary.
Alternatively, if you absolutely want to write LaTeX-like commands in literal strings inside R, just use a different character for \; for instance, +. Just make sure that your function correctly handles it everywhere, and that you keep a way of getting a literal + back. Here’s a suggestion:
okstr("+label{1 ++ 2}")
The implementation of okstr then needs to replace single + by \, and double ++ by + (making the above result in \label{1 + 2}). But consider in which order this needs to happen, and how you’d like to treat more complex cases; for instance, what should the following yield: okstr("1 +++label")?
Julia has docstrings capabilities, which are documented here https://docs.julialang.org/en/stable/manual/documentation/. I'm under the impression that it has support for LaTeX code, but I'm not sure if the intention is that the LaTeX code should look like code or like an interpretation. In the following, the LaTeX code is garbled somewhat (see rho, for instance) and not interpreted (rho does not look like ρ). Am I doing something wrong?
Is there a way to get LaTeX code look interpreted?
What I mean by interpreted is something like what they do at https://math.stackexchange.com/.
The documentation says that LaTeX code should be wrapped around double back-quotes and that Greek letters should be typed as ρ rather than \rho. But that rather defeats the point of being able to include LaTeX code, doesn't it?
Note: Version 0.5.2 run in Juno/Atom console.
"""
Module blabla
The objective function is:
``\max \mathbb{E}_0 \int_0^{\infty} e^{-\rho t} F(x_t) dt``
"""
module blabla
end
If I then execute the module and query I get this:
With triple quotes, the dollar signs disappear, but the formula is printed on a dark background:
EDIT Follow-up to David P. Sanders' suggestion to use the Documenter.jl package.
using Documenter
doc"""
Module blabla
The objective function is:
$\max \mathbb{E}_0 \int_0^{\infty} e^{-\rho t} F(x_t) dt$
"""
module blabla
end
Gives the following: the LaTeX code appears to print correctly, but it's not interpreted (ρ is displayed as \rho. I followed suggestions in: https://juliadocs.github.io/Documenter.jl/stable/man/latex.html to
Rendering LaTeX code as actual equations has to be supported by whichever software renders your docstrings. So, the short answer to why you're not seeing any rendered equations in Juno is that LaTeX rendering is currently not supported in Juno (as Matt B. pointed out, there's an open issue for that).
The doc"" string literal / string macro is there to get around another issue. Backslashes and dollar signs normally have a special meaning in string literals -- escape sequences and variable interpolation, respectively (e.g. \n gets replaced by a newline character, $(variable) inserts the value of variable into the string). This, of course, clashes with the ordinary LaTeX commands and delimiters (e.g. \frac, $...$). So, to actually have backslashes and dollar signs in a string you need to escape them all with backslashes, e.g.:
julia> "\$\\frac{x}{y}\$" |> print
$\frac{x}{y}$
Not doing that will either give an error:
julia> "$\frac{x}{y}$" |> print
ERROR: syntax: invalid interpolation syntax: "$\"
or invalid characters in the resulting strings:
julia> "``\e^x``" |> print
``^x``
Having to escape everything all the time would, of course, be annoying when writing docstrings. So, to get around this, as David pointed out out, you can use the doc string macro / non-standard string literal. In a doc literal all standard escape sequences are ignored, so an unescaped LaTeX string doesn't cause any issues:
julia> doc"$\frac{x}{y}$" |> print
$$
\frac{x}{y}
$$
Note: doc also parses the Markdown in the string and actually returns a Base.Markdown.MD object, not a string, which is why the printed string is a bit different from the input.
Finally, you can then use these doc-literals as normal docstrings, but you can then freely use LaTeX syntax without having to worry about escaping everything:
doc"""
$\frac{x}{y}$
"""
function foo end
This is also documented in Documenter's manual, although it is not actually specific to Documenter.
Double backticks vs dollar signs. The preferred way to mark LaTeX in Julia docstrings or documentation is by using double backticks or ```math blocks, as documented in the manual. Dollar signs are supported for backwards compatibility.
Note: Documenter's manual and the show methods for Markdown objects in Julia should be updated to reflect this.
You can use
doc"""
...
"""
This is a "non-standard string literal" used by the Documenter.jl package; see https://docs.julialang.org/en/stable/manual/strings/#non-standard-string-literals.
In cycript, it is possible to get a reference to a c function pointer, but I've been unable to use that syntax to retrieve a pointer to c++ functions using either their proper or mangled function names from the symbol table.
Is there a way to get there from here?
Update:
Update from Saurik's Input:
I hadn't tried function pointers from the c style symbols, but you are absolutely right that the leading underscore needs to be stripped. _DES_encrypt3 needs to be accessed with:
cy# dlsym(RTLD_DEFAULT, "DES_encrypt3")
0x14dc19
This gives me a valid pointer address.
When I look at the mangled symbol for xmpp::CapsManager::~CapsManager(), which is __ZN4xmpp11CapsManagerD2Ev_1bf718, I try
cy# dlsym(RTLD_DEFAULT, "__ZN4xmpp11CapsManagerD2Ev_1bf718")
null
cy# dlsym(RTLD_DEFAULT, "_ZN4xmpp11CapsManagerD2Ev_1bf718")
null
cy# dlsym(RTLD_DEFAULT, "ZN4xmpp11CapsManagerD2Ev_1bf718")
null
None of these variations yield a pointer.
My immediate guess is that you are trying to take the raw mangled symbol name (as you describe, getting it from the symbol table), passing it to dlsym... but dlsym requires a C-level symbol name, which means your approach would not work even for a simple C symbol: you will have an extra _ at the beginning (if you check the symbol table, you will see that C functions are also mangled, to begin with _). If you strip the leading _ you should be able to use dlsym to look up your mangled C++ symbol.
Standard common-lisp defines many reader macros such as ( and ) for grouping, ' for quote, " for string quotation, | for symbol quotation, # for dispatch macro, etc. Now I want to disable them all and use my own ones, and I have to call set-macro-character one by one to disable them all and then define my own ones.
I have found that there's one way to restore all reader macros to standard ones by calling (setf *readtable* (copy-readtable nil)), but is there a way to set them to empty(i.e., all the characters are treated as normal letters and numbers)?
I don't think there's a way. The expectation is that you're just making incremental modifications to the Lisp reader, not trying to replace it wholesale. It's not really designed to be used that way, because you can't define everything as a macro -- most of the constituent characters are associated with built-in behaviors that can't be defined as reader macros.