In Python 3, I would
print_me = "Look at this significant figure formatted number: {:.2f}!".format(floating_point_number)
print(print_me)
or
print_me = f"Look at this significant figure formatted number: {floating_point_number:.2f}!"
print(print_me)
In Julia
print_me = "Look at this significant figure formatted number: $floating_point_number"
print(print_me)
but this would yield say
Look at this significant figure formatted number: 61.61616161616161
How do I get Julia to restrict the number of decimal places it displays? Note that the necessary storage of the string to be printed, to my knowledge, rules out using the #printf macro.
This works, but does not seem stylistically correct.
floating_point_number = round(floating_point_number,2)
print_me = "Look at this significant figure formatted number: $floating_point_number"
print(print_me)
You can use #sprintf macro from the standard library package Printf. This returns a string rather than just printing it as #printf.
using Printf
x = 1.77715
print("I'm long: $x, but I'm alright: $(#sprintf("%.2f", x))")
Output:
I'm long: 1.77715, but I'm alright: 1.78
In addition to #niczky12's answer you can also use the Formatting package designed precisely for this type of thing!
Pkg.add("Formatting")
using Formatting: printfmt
x = 1.77715
printfmt("I'm long: $x, but I'm alright: {:.2f}", x)
Output:
I'm long: 1.77715, but I'm alright: 1.78
While it is still a work in progress (I need to add a bunch of unit tests, and I want to add a Python 3.6 style mode), you could also use my StringUtils.jl package, which adds C and Python like formatting, Swift style interpolation, Emoji, LaTex, and Html and Unicode named characters to string literals.
Pkg.clone("https://github.com/ScottPJones/StringUtils.jl")
Pkg.checkout("StringUtils")
using StringUtils
x = 1.77715
print(u"I'm long: \(x), but I'm alright: \%.2f(x)")
Output:
I'm long: 1.77715, but I'm alright: 1.78
Related
If we type in letters we get all lowercase letters from english alphabet. However, there are many more possible characters like ä, é and so on. And there are symbols like $ or (, too. I found this table of unicode characters which is exactly what I need. Of course I do not want to copy and paste hundreds of possible unicode characters in one vector.
What I've tried so far: The table gives the decimals for (some of) the unicode characters. For example, see the following small table:
Glyph Decimal Unicode Usage in R
! 33 U+0021 "\U0021"
So if type "\U0021" we get a !. Further, paste0("U", format(as.hexmode(33), width= 4, flag="0")) returns "U0021" which is quite close to what I need but adding \ results in an error:
paste0("\U", format(as.hexmode(33), width= 4, flag="0"))
Error: '\U' used without hex digits in character string starting ""\U"
I am stuck. And I am afraid even if I figure out how to transform numbers to characters usings as.hexmode() there is still the problem that there are not Decimals for all unicode characters (see table, Decimals end with 591).
Any idea how to generate a vector with all the unicode characters listed in the table linked?
(The question started with a real world problem but now I am mostly simply eager to know how to do this.)
There may be easier ways to do this, but here goes. The Unicode package contains everything you need.
First we can get a list of unicode scripts and the block ranges:
library(Unicode)
uranges <- u_scripts()
Check what we've got:
head(uranges, 3)
$Adlam
[1] U+1E900..U+1E943 U+1E944..U+1E94A U+1E94B U+1E950..U+1E959 U+1E95E..U+1E95F
$Ahom
[1] U+11700..U+1171A U+1171D..U+1171F U+11720..U+11721 U+11722..U+11725 U+11726 U+11727..U+1172B U+11730..U+11739 U+1173A..U+1173B U+1173C..U+1173E U+1173F
[11] U+11740..U+11746
$Anatolian_Hieroglyphs
[1] U+14400..U+14646
Next we can convert the ranges into their sequences.
expand_uranges <- lapply(uranges, as.u_char_seq)
To get a single vector of all characters we can unlist it. This won't be easy to work with so really it would be better to keep them as a list:
all_unicode_chars <- unlist(expand_uranges)
# The Wikipedia page linked states there are 144,697 characters
length(all_unicode_chars)
[1] 144762
So seems to be all of them and the page needs updating. They are stored as integers so to print them (assuming the glyph is supported) we can do, for example, printing Japanese katakana:
intToUtf8(expand_uranges$Katakana[[1]])
[1] "ァアィイゥウェエォオカガキギクグケゲコゴサザシジスズセゼソゾタダチヂッツヅテデトドナニヌネノハバパヒビピフブプヘベペホボポマミムメモャヤュユョヨラリルレロヮワヰヱヲンヴヵヶヷヸヹヺ"
I am replacing values in Yaml files, and need to choose which values will be quoted.
I don't understand the current behaviour of write.yaml
library(yaml)
test <- list("a"=list("b"="123", "c"="rabbitmq"))
as.yaml(test)
write_yaml(test, "test.yaml")
In test.yaml, "123" is quoted while rabbitmq is not. How can I deliberately choose what will be quoted ?
It is actually possible to generate characters that are quoted very straightforwardly without any esoteric workaround.
So from the help to yaml::as.yaml we have:
"Character vectors that have an attribute of ‘quoted’ will be wrapped in double quotes (see below for example)."
Now, here is the test:
veck1 <- c("a")
veck2 <- veck1
attr(veck2, which = "quoted") <- TRUE # actually any attribute value works here
test_list <- list(unquoted_char = veck1, quoted_char = veck2)
write_yaml(test_list, "./test.yaml")
gives me the yaml file:
unquoted_char: a
quoted_char: "a"
which is exactly what was asked for #gaut.
Maybe the R/package version need an update, here are my settings.
R version:
major 4
minor 2.1
year 2022
month 06
day 23
svn rev 82513
language R
version.string R version 4.2.1 (2022-06-23)
nickname Funny-Looking Kid
package version yaml: ‘2.3.5’
workaround
Although this might be difficult for more complex YAML file outputs, there is a workaround to the apparent inability of the yaml package to force quotations, as explored below. We can use regex to match, in this example, any non-quoted continuous group of letters or numbers and force quotations around it.
library(stringr)
test <- list("a"=list("b"=123L, "c"="rabbitmq", d = "Yes"))
test_yaml <- as.yaml(test)
test_yaml
#> [1] "a:\n b: 123\n c: rabbitmq\n d: 'Yes'\n"
We can see here that we might want to quote 123 and rabbitmq (Yes is already in quotes).
test_yaml <- str_replace_all(test_yaml, "(?<=:\\s)([a-zA-Z0-9]*?)(?=\n)", "'\\1'")
test_yaml
#> [1] "a:\n b: '123'\n c: 'rabbitmq'\n d: 'Yes'\n"
And then write this to your YAML file.
write_yaml(test_yaml, "/Users/caldwellst/Desktop/test.yaml")
We then get your, I'm assuming, desired output.
a:
b: '123'
c: 'rabbitmq'
d: 'Yes'
yaml package
write_yaml is using strings to force a quote, because otherwise 123 would be interpreted as numeric. You don't need quotes for rabbitmq because it will automatically be interpreted as a string. If you actually want 123 to be interpreted as numeric, just pass it as such.
test <- list("a"=list("b"=123, "c"="rabbitmq"))
as.yaml(test)
write_yaml(test, "test.yaml")
Then you get:
a:
b: 123.0 # pass b as 123L to force integer output
c: rabbitmq
Per the documentation of write_yaml:
Character vectors that have a class of ‘verbatim’ will not be quoted in the output YAML document except when the YAML specification requires it
Although that is a way to force certain values to be output without quotes, there appears to be no easy way to force quoting of values. I've tried with passing unicode = T and explicit quotes in the string, but they are removed. As well, I tried to trick the system by passing in various handlers to manipulate class (and remove verbatim if it was there. However, none seem to work. As the source code is in C, not able to get something working with the write_yaml function.
There's a detailed answer about the YAML syntax and quoting in general in this great SO post.
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
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.
I work with R and I would like to use the Unicode symbol "dot above" as thousands separator for data contained in a dataframe (not for plotting), for example: 1˙000˙000 instead of 1,000,000
The character code of "dot above" is 02D9 (taken from Microsoft Word); when I type the command:
"\u02D9"
the result is the symbol "dot above":
"˙"
I changed the option "scipen":
options(scipen = 10)
and then I tried three different solutions:
1.
format(1000000, big.mark = "\u02D9")
2.
format(1000000, big.mark = intToUtf8("0x02D9"))
3.
library(Unicode)
format(1000000, big.mark = intToUtf8(as.u_char("02D9")))
but the result is always:
"1™Ë000™Ë000"
Maybe it's about the encoding system (I live in Italy and I use Microsoft Windows 7 on my computer) or maybe the solution is simpler than the ones I tried but I don't know how to deal with it.
Does anybody know how to do it?
Thanks in advance for any suggestion.
As #Roland mentions gsub and sub used by prettyNum mangle the encoding. Unfortunately you cannot simply reset it afterwards to recover your data since the mangling converts it to two characters, and prettyNum reverses their order:
`Encoding<-`(format(1000, big.mark = "\u02D9"),"UTF-8")
[1] "1\u0099\xcb000"
The best way to work around is to format with a safe character and swap and change encoding afterwards:
`Encoding<-`(gsub(",","\u02d9",format(1e6,big.mark=",")),"UTF-8")
[1] "1˙000˙000"