I'm in the process of working on a coding project in a pluto notebook. It's early days but I'm curious why the value of 1000 doesn't show beside quadorder in the screenshot above. It seems to output for everything else!
It is the ; in your code that triggers that. However, I don't think it is supposed to be expected behavior. It is supposed to be a comment, but the parser probably sees the ; and thinks that it is part of the code.
If you put it between quoting marks then this doesn't happen.
I.e. this should work as expected:
quadorder = 1000 # like python Julia doesn't require ';'
Otherwise, it would usually also work if you just don't put it at the end of the line.
The Julia REPL evaluates the semicolon wrongly and it is a know issue github.com/JuliaLang/julia/issues/28743.
You can actually trick it into some weird behavior that suppresses output. For example this returns no output:
julia> ";#"
julia> a = ["; #", "hi", 3]
julia> a = "223" #;
The reason is that the REPL parser looks for the last semicolon in the line and if there is any # or if it is at the end of the line (whitespaces don't matter), then it suppresses any output.
Related
I am new to using Julia and the atom IDE, and I was wondering if it was possible to somehow just press enter and have the computer run 1 line of code spread over multiple lines, and still have it recognize that it is still the same 1 line of code, just like in Rstudio? (I want this for readability purposes only)
what I mean is something like:
println("Hello
world")
and be able to highlight and run this script without receiving an error message.
Yes. The method differs based on what the line of code contains, or specifically, where you want to break the line.
For a string like you've posted in the question, you have to precede the newline with a \ character, to inform Julia that you're using this newline only for readability, and don't want it to be included in the actual string. (Note: I'll be illustrating these with the command-line REPL that has the julia> prompt, but the same principles apply in the Atom/VS Code based IDE setups too).
julia> println("Hello \
world")
Hello world
Outside of strings, if the current line isn't complete, Julia automatically looks for the continuation in the next line. This means that to break a line into multiple ones, you have to leave all but the final line incomplete:
julia> 1 +
2 +
3 *
4
15
julia> DEPOT_PATH |>
first |>
readdir
16-element Vector{String}:
"artifacts"
"bin"
⋮
julia> 1,
2,
3
(1, 2, 3)
In some cases when you don't have a convenient binary operator to leave hanging like the above, you may have to start your line with an opening parenthesis, so that Julia will know that it's a continuous statement until the closing parenthesis is encountered.
You also have multi-line Strings denoted by """:
julia> println("""This
is
a multi-line \
text""")
This
is
a multi-line text
I've written a prime-generating function generatePrimes (full code here) that takes input bound::Int64 and returns a Vector{Int64} of all primes up to bound. After the function definition, I have the following code:
println("Generating primes...")
println("Last prime: ", generatePrimes(10^7)[end])
println("Primes generated.")
which prints, unexpectedly,
Generating primes...
9999991
Primes generated.
This output misses the "Last prime: " segment of the second print statement. The output does work as expected for smaller inputs; any input at least up to 10^6, but somehow fails for 10^7. I've tried several workarounds for this (e.g. assigning the returned value or converting it to a string before calling it in a print statement, combining the print statements, et cetera) and discovered some other weird behaviour: if the "Last prime", is removed from the second print statement, for input 10^7, the last prime doesn't print at all and all I get is a blank line between the first and third print statements. These issues are probably related, and I can't seem to find anything online about why some print statements wouldn't work in Julia.
Thanks so much for any clarification!
Edit: Per DNF's suggestion, following are some reductions to this issue:
Removing the first and last print statements doesn't change anything -- a blank line is always printed in the case I outlined and each of the cases below.
println(generatePrimes(10^7)[end]) # output: empty line
Calling the function and storing the last index in a variable before calling println doesn't change anything either; the cases below work exactly the same either way.
lastPrime::Int = generatePrimes(10^7)[end]
println(lastPrime) # output: empty line
If I call the function in whatever form immediately before a println, an empty line is printed regardless of what's inside the println.
lastPrime::Int = generatePrimes(10^7)[end]
println("This doesn't print") # output: empty line
println("This does print") # output: This does print
If I call the function (or print the pre-generated-and-stored function result) inside a println, anything before the function call (that's also inside the println) isn't printed. The 9999991 and anything else there may be after the function call is printed only if there is something else inside the println before the function call.
# Example 1
println(generatePrimes(10^7)[end]) # output: empty line
# Example 2
println("This first part doesn't print", generatePrimes(10^7)[end]) # output: 9999991
# Example 3
println("This first part doesn't print", generatePrimes(10^7)[end], " prints") # output: 9999991 prints
# Example 4
println(generatePrimes(10^7)[end], "prime doesn't print") # output: prime doesn't print
I could probably list twenty different variations of this same thing, but that probably wouldn't make things any clearer. In every single case version of this issue I've seen so far, the issue only manifests if there's that function call somewhere; println prints large integers just fine. That said, please let me know if anyone feels like they need more info. Thanks so much!
Most likely you are running this code from Atom Juno which recently has some issues with buffering standard output (already reported by others and I also sometimes have this problem).
One thing you can try to do is to flush your standard output
flush(stdout)
Like with any unstable bug restarting Atom Juno also seems to help.
I had the same issue. For me, changing the terminal renderer (File -> Settings -> Packages -> julia-client -> Terminal Options) from webgl to canvas (see pic below) seems to solve the issue.
change terminal renderer
I've also encountered this problem many times. (First time, it was triggered after using the debugger. It is probably unrelated but I have been using Julia+Juno for 2 weeks prior to this issue.)
In my case, the code before the println statement needed to have multiple dictionary assignation (with new keys) in order to trigger the behavior.
I also confirmed that the same code ran in Command Prompt (with same Julia interpreter) prints fine. Any hints about how to further investigate this will be appreciated.
I temporarily solve this issue by printing to stderr, thinking that this stream has more stringent flush mechanism: println(stderr, "hello!")
I try to export a file in SAS but I get "Open code statement recursion detected." error. Since I export more than one files depending on date I define as a macro variable based on the prompt date, I want to name my file to be exported with this variable but it does not work. I would really appreciate if anyone helps me.
rep_date = 30APR2015:00:00:00
Outfile = work.A042015.sas7
%let var = CATS("A",MONTH(DATEPART(&rep_date)),YEAR(DATEPART(&rep_date)));
data WORK.&var(compress=yes);
set WORK.have;
run;
Macro variables are just strings. So if you want to execute functions in macro code you need to wrap the function inside of the %SYSFUNC() macro function.
%let rep_date='01JAN2015:01:23'dt ;
%let dsname = A%sysfunc(datepart(&rep_date),monyy6);
data &dsname(compress=yes);
set have;
run;
As a more broad issue, OPEN STATEMENT RECURSION DETECTED refers to cases where you assign a macro variable to itself.
%let &mvar = &mvar;
Of course, this wouldn't normally happen on purpose (one would think). When it does happen, usually it's a sign of one of two classes of mistake.
You're missing a semicolon, end parenthesis, end quote, or something else that causes SAS to not "see" the semicolon at the end of the %let statement. Then your next statement uses the macro variable in a macro context, and SAS sees that as part of the %let statement, which causes this error message.
Something went wrong somewhere else, and you have an issue where that something-else propagates errors further down that don't make any sense. Having an unmatched quotation is a classic example of this, as is a macro that doesn't properly %mend.
1 can happen in cases as simple as this:
%let mvar=mydataset
%put &mvar;
Oops. If it's that simple, then just pop the semicolon on and you're good. It could, however, be caused by something more significant - such as an unmatched parenthesis or quotation - which might require restarting your SAS session. (Sometimes submitting a magic string, which are variations on %*;*;*';*";%*%mend;*);, will fix things, sometimes not. Restarting SAS is a reliable way to fix that).
That's also true with 2 above - if a magic string doesn't fix it, then you may simply need to restart your SAS session. Of course, you still need to find that unmatched quote/parenthesis/etc., but you first need to start SAS over so you can figure it out.
I am streaming strings and parsing them into floats/ints from a .dat. Everything is going well until I work with the last item in the string, which returns an error.
Example Data:
x = "15505052|B|Other|2.22|250022|2776|09/2019|01/2004|"
y = split(x, "|") # <-- one inner loop of the loop
if isblank(y[9]) == false
floater = parse(Float64, y[9])
end
This is the error I receive:
ArgumentError("float64(String): invalid number format")
while loading In[42], in expression starting on line 56
in float64 at string.jl:1613
in parse at /Users/laptop/.julia/v0.3/Compat/src/Compat.jl:217
in loan_aqsn at In[42]:36
I have visually inspected the last column in the above data strings and determined that the data should be parseable into a Float64, and indeed every other column works just fine.
What I have found is that I can individually parse lines from the .dat just fine (for testing purposes), but when I move to streaming the file Julia throws the error. The only thing I can figure out about this error is that it has to due with working with the final record in the string y[9], which makes no sense to me.
Any help with this frustrating problem is much appreciated.
You're testing whether y is blank, when it is in fact an empty string:
x = "15505052|B|Other|2.22|250022|2776|09/2019|01/2004|"
y = split(x)
y[9] # ""
isblank(y[9]) # false, since we have an empty string
float(y[9]) # ERROR: ArgumentError("float64(String): invalid number format")
You should modify your code to use isempty() instead
using Compat # for parse(Float, String)
if !isempty(y[9])
floater = parse(Float64, y[9])
end
# do stuff
Relevant manual section (for v0.3)
Which julia version are you using? Mine doesn't recognize parse(fmt,str) as a valid command (v 0.3.10).
Try really parsing the numbers, not just converting them. That way the divisions are properly executed (like 01/2004 in the second x).
strs = ["12", "12.1", "12/3"]
for i in strs
a::Float64 = eval(parse(i))
println(a)
end
this works fine in my julia REPL, returning 12.0,12.1 and 4.0.
Note that I am "executing" those numbers, opening a security concern if I use this code for other thing than a quick script.
Consider the following code:
File C.jl
module C
export printLength
printLength = function(arr)
println(lentgh(arr))
end
end #module
File Main.jl
using C
main = function()
arr = Array(Int64, 4)
printLength(arr)
end
main()
Let's try to execute it.
$ julia Main.jl
ERROR: lentgh not defined
in include at /usr/bin/../lib64/julia/sys.so
in process_options at /usr/bin/../lib64/julia/sys.so
in _start at /usr/bin/../lib64/julia/sys.so
while loading /home/grzes/julia_sucks/Main.jl, in expression starting on line 8
Obviously, it doesn't compile, because lentgh is misspelled. The problem is the message I received. expression starting on line 8 is simply main(). Julia hopelessly fails to point the invalid code fragment -- it just points to the invocation of main, but the erroneous line is not even in that file! Now imagine a real project where an error hides really deep in the call stack. Julia still wouldn't tell anything more than that the problem started on the entry point of the execution. It is impossible to work like that...
Is there a way to force Julia to give a little more precise messages?
In this case it's almost certainly a consequence of inlining: your printLength function is so short, it's almost certainly inlined into the call site, which is why you get the line number 8.
Eventually, it is expected that inlining won't cause problems for backtraces. At the moment, your best bet---if you're running julia's pre-release 0.4 version---is to start julia as julia --inline=no and run your tests again.