280 lines
44 KiB
HTML
280 lines
44 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en"><head><meta charset="UTF-8"/><meta name="viewport" content="width=device-width, initial-scale=1.0"/><title>Frequently Asked Questions · The Julia Language</title><script>(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
||
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
||
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
||
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
|
||
|
||
ga('create', 'UA-28835595-6', 'auto');
|
||
ga('send', 'pageview');
|
||
</script><link href="https://cdnjs.cloudflare.com/ajax/libs/normalize/4.2.0/normalize.min.css" rel="stylesheet" type="text/css"/><link href="https://fonts.googleapis.com/css?family=Lato|Roboto+Mono" rel="stylesheet" type="text/css"/><link href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css" rel="stylesheet" type="text/css"/><script>documenterBaseURL=".."</script><script src="https://cdnjs.cloudflare.com/ajax/libs/require.js/2.2.0/require.min.js" data-main="../assets/documenter.js"></script><script src="../siteinfo.js"></script><script src="../../versions.js"></script><link href="../assets/highlightjs/default.css" rel="stylesheet" type="text/css"/><link href="../assets/documenter.css" rel="stylesheet" type="text/css"/></head><body><nav class="toc"><a href="../index.html"><img class="logo" src="../assets/logo.png" alt="The Julia Language logo"/></a><h1>The Julia Language</h1><select id="version-selector" onChange="window.location.href=this.value" style="visibility: hidden"></select><form class="search" action="../search.html"><input id="search-query" name="q" type="text" placeholder="Search docs"/></form><ul><li><a class="toctext" href="../index.html">Home</a></li><li><span class="toctext">Manual</span><ul><li><a class="toctext" href="introduction.html">Introduction</a></li><li><a class="toctext" href="getting-started.html">Getting Started</a></li><li><a class="toctext" href="variables.html">Variables</a></li><li><a class="toctext" href="integers-and-floating-point-numbers.html">Integers and Floating-Point Numbers</a></li><li><a class="toctext" href="mathematical-operations.html">Mathematical Operations and Elementary Functions</a></li><li><a class="toctext" href="complex-and-rational-numbers.html">Complex and Rational Numbers</a></li><li><a class="toctext" href="strings.html">Strings</a></li><li><a class="toctext" href="functions.html">Functions</a></li><li><a class="toctext" href="control-flow.html">Control Flow</a></li><li><a class="toctext" href="variables-and-scoping.html">Scope of Variables</a></li><li><a class="toctext" href="types.html">Types</a></li><li><a class="toctext" href="methods.html">Methods</a></li><li><a class="toctext" href="constructors.html">Constructors</a></li><li><a class="toctext" href="conversion-and-promotion.html">Conversion and Promotion</a></li><li><a class="toctext" href="interfaces.html">Interfaces</a></li><li><a class="toctext" href="modules.html">Modules</a></li><li><a class="toctext" href="documentation.html">Documentation</a></li><li><a class="toctext" href="metaprogramming.html">Metaprogramming</a></li><li><a class="toctext" href="arrays.html">Multi-dimensional Arrays</a></li><li><a class="toctext" href="linear-algebra.html">Linear algebra</a></li><li><a class="toctext" href="networking-and-streams.html">Networking and Streams</a></li><li><a class="toctext" href="parallel-computing.html">Parallel Computing</a></li><li><a class="toctext" href="dates.html">Date and DateTime</a></li><li><a class="toctext" href="interacting-with-julia.html">Interacting With Julia</a></li><li><a class="toctext" href="running-external-programs.html">Running External Programs</a></li><li><a class="toctext" href="calling-c-and-fortran-code.html">Calling C and Fortran Code</a></li><li><a class="toctext" href="handling-operating-system-variation.html">Handling Operating System Variation</a></li><li><a class="toctext" href="environment-variables.html">Environment Variables</a></li><li><a class="toctext" href="embedding.html">Embedding Julia</a></li><li><a class="toctext" href="packages.html">Packages</a></li><li><a class="toctext" href="profile.html">Profiling</a></li><li><a class="toctext" href="stacktraces.html">Stack Traces</a></li><li><a class="toctext" href="performance-tips.html">Performance Tips</a></li><li><a class="toctext" href="workflow-tips.html">Workflow Tips</a></li><li><a class="toctext" href="style-guide.html">Style Guide</a></li><li class="current"><a class="toctext" href="faq.html">Frequently Asked Questions</a><ul class="internal"><li><a class="toctext" href="#Sessions-and-the-REPL-1">Sessions and the REPL</a></li><li><a class="toctext" href="#Functions-1">Functions</a></li><li><a class="toctext" href="#Types,-type-declarations,-and-constructors-1">Types, type declarations, and constructors</a></li><li><a class="toctext" href="#Packages-and-Modules-1">Packages and Modules</a></li><li><a class="toctext" href="#Nothingness-and-missing-values-1">Nothingness and missing values</a></li><li><a class="toctext" href="#Memory-1">Memory</a></li><li><a class="toctext" href="#Asynchronous-IO-and-concurrent-synchronous-writes-1">Asynchronous IO and concurrent synchronous writes</a></li><li><a class="toctext" href="#Julia-Releases-1">Julia Releases</a></li></ul></li><li><a class="toctext" href="noteworthy-differences.html">Noteworthy Differences from other Languages</a></li><li><a class="toctext" href="unicode-input.html">Unicode Input</a></li></ul></li><li><span class="toctext">Standard Library</span><ul><li><a class="toctext" href="../stdlib/base.html">Essentials</a></li><li><a class="toctext" href="../stdlib/collections.html">Collections and Data Structures</a></li><li><a class="toctext" href="../stdlib/math.html">Mathematics</a></li><li><a class="toctext" href="../stdlib/numbers.html">Numbers</a></li><li><a class="toctext" href="../stdlib/strings.html">Strings</a></li><li><a class="toctext" href="../stdlib/arrays.html">Arrays</a></li><li><a class="toctext" href="../stdlib/parallel.html">Tasks and Parallel Computing</a></li><li><a class="toctext" href="../stdlib/linalg.html">Linear Algebra</a></li><li><a class="toctext" href="../stdlib/constants.html">Constants</a></li><li><a class="toctext" href="../stdlib/file.html">Filesystem</a></li><li><a class="toctext" href="../stdlib/io-network.html">I/O and Network</a></li><li><a class="toctext" href="../stdlib/punctuation.html">Punctuation</a></li><li><a class="toctext" href="../stdlib/sort.html">Sorting and Related Functions</a></li><li><a class="toctext" href="../stdlib/pkg.html">Package Manager Functions</a></li><li><a class="toctext" href="../stdlib/dates.html">Dates and Time</a></li><li><a class="toctext" href="../stdlib/iterators.html">Iteration utilities</a></li><li><a class="toctext" href="../stdlib/test.html">Unit Testing</a></li><li><a class="toctext" href="../stdlib/c.html">C Interface</a></li><li><a class="toctext" href="../stdlib/libc.html">C Standard Library</a></li><li><a class="toctext" href="../stdlib/libdl.html">Dynamic Linker</a></li><li><a class="toctext" href="../stdlib/profile.html">Profiling</a></li><li><a class="toctext" href="../stdlib/stacktraces.html">StackTraces</a></li><li><a class="toctext" href="../stdlib/simd-types.html">SIMD Support</a></li></ul></li><li><span class="toctext">Developer Documentation</span><ul><li><a class="toctext" href="../devdocs/reflection.html">Reflection and introspection</a></li><li><span class="toctext">Documentation of Julia's Internals</span><ul><li><a class="toctext" href="../devdocs/init.html">Initialization of the Julia runtime</a></li><li><a class="toctext" href="../devdocs/ast.html">Julia ASTs</a></li><li><a class="toctext" href="../devdocs/types.html">More about types</a></li><li><a class="toctext" href="../devdocs/object.html">Memory layout of Julia Objects</a></li><li><a class="toctext" href="../devdocs/eval.html">Eval of Julia code</a></li><li><a class="toctext" href="../devdocs/callconv.html">Calling Conventions</a></li><li><a class="toctext" href="../devdocs/compiler.html">High-level Overview of the Native-Code Generation Process</a></li><li><a class="toctext" href="../devdocs/functions.html">Julia Functions</a></li><li><a class="toctext" href="../devdocs/cartesian.html">Base.Cartesian</a></li><li><a class="toctext" href="../devdocs/meta.html">Talking to the compiler (the <code>:meta</code> mechanism)</a></li><li><a class="toctext" href="../devdocs/subarrays.html">SubArrays</a></li><li><a class="toctext" href="../devdocs/sysimg.html">System Image Building</a></li><li><a class="toctext" href="../devdocs/llvm.html">Working with LLVM</a></li><li><a class="toctext" href="../devdocs/stdio.html">printf() and stdio in the Julia runtime</a></li><li><a class="toctext" href="../devdocs/boundscheck.html">Bounds checking</a></li><li><a class="toctext" href="../devdocs/locks.html">Proper maintenance and care of multi-threading locks</a></li><li><a class="toctext" href="../devdocs/offset-arrays.html">Arrays with custom indices</a></li><li><a class="toctext" href="../devdocs/libgit2.html">Base.LibGit2</a></li><li><a class="toctext" href="../devdocs/require.html">Module loading</a></li></ul></li><li><span class="toctext">Developing/debugging Julia's C code</span><ul><li><a class="toctext" href="../devdocs/backtraces.html">Reporting and analyzing crashes (segfaults)</a></li><li><a class="toctext" href="../devdocs/debuggingtips.html">gdb debugging tips</a></li><li><a class="toctext" href="../devdocs/valgrind.html">Using Valgrind with Julia</a></li><li><a class="toctext" href="../devdocs/sanitizers.html">Sanitizer support</a></li></ul></li></ul></li></ul></nav><article id="docs"><header><nav><ul><li>Manual</li><li><a href="faq.html">Frequently Asked Questions</a></li></ul><a class="edit-page" href="https://github.com/JuliaLang/julia/tree/d386e40c17d43b79fc89d3e579fc04547241787c/doc/src/manual/faq.md"><span class="fa"></span> Edit on GitHub</a></nav><hr/><div id="topbar"><span>Frequently Asked Questions</span><a class="fa fa-bars" href="#"></a></div></header><h1><a class="nav-anchor" id="Frequently-Asked-Questions-1" href="#Frequently-Asked-Questions-1">Frequently Asked Questions</a></h1><h2><a class="nav-anchor" id="Sessions-and-the-REPL-1" href="#Sessions-and-the-REPL-1">Sessions and the REPL</a></h2><h3><a class="nav-anchor" id="How-do-I-delete-an-object-in-memory?-1" href="#How-do-I-delete-an-object-in-memory?-1">How do I delete an object in memory?</a></h3><p>Julia does not have an analog of MATLAB's <code>clear</code> function; once a name is defined in a Julia session (technically, in module <code>Main</code>), it is always present.</p><p>If memory usage is your concern, you can always replace objects with ones that consume less memory. For example, if <code>A</code> is a gigabyte-sized array that you no longer need, you can free the memory with <code>A = 0</code>. The memory will be released the next time the garbage collector runs; you can force this to happen with <a href="../stdlib/base.html#Base.gc"><code>gc()</code></a>.</p><h3><a class="nav-anchor" id="How-can-I-modify-the-declaration-of-a-type-in-my-session?-1" href="#How-can-I-modify-the-declaration-of-a-type-in-my-session?-1">How can I modify the declaration of a type in my session?</a></h3><p>Perhaps you've defined a type and then realize you need to add a new field. If you try this at the REPL, you get the error:</p><pre><code class="language-none">ERROR: invalid redefinition of constant MyType</code></pre><p>Types in module <code>Main</code> cannot be redefined.</p><p>While this can be inconvenient when you are developing new code, there's an excellent workaround. Modules can be replaced by redefining them, and so if you wrap all your new code inside a module you can redefine types and constants. You can't import the type names into <code>Main</code> and then expect to be able to redefine them there, but you can use the module name to resolve the scope. In other words, while developing you might use a workflow something like this:</p><pre><code class="language-julia">include("mynewcode.jl") # this defines a module MyModule
|
||
obj1 = MyModule.ObjConstructor(a, b)
|
||
obj2 = MyModule.somefunction(obj1)
|
||
# Got an error. Change something in "mynewcode.jl"
|
||
include("mynewcode.jl") # reload the module
|
||
obj1 = MyModule.ObjConstructor(a, b) # old objects are no longer valid, must reconstruct
|
||
obj2 = MyModule.somefunction(obj1) # this time it worked!
|
||
obj3 = MyModule.someotherfunction(obj2, c)
|
||
...</code></pre><h2><a class="nav-anchor" id="Functions-1" href="#Functions-1">Functions</a></h2><h3><a class="nav-anchor" id="I-passed-an-argument-x-to-a-function,-modified-it-inside-that-function,-but-on-the-outside,-1" href="#I-passed-an-argument-x-to-a-function,-modified-it-inside-that-function,-but-on-the-outside,-1">I passed an argument <code>x</code> to a function, modified it inside that function, but on the outside,</a></h3><p>the variable <code>x</code> is still unchanged. Why?</p><p>Suppose you call a function like this:</p><pre><code class="language-julia-repl">julia> x = 10
|
||
10
|
||
|
||
julia> function change_value!(y)
|
||
y = 17
|
||
end
|
||
change_value! (generic function with 1 method)
|
||
|
||
julia> change_value!(x)
|
||
17
|
||
|
||
julia> x # x is unchanged!
|
||
10</code></pre><p>In Julia, the binding of a variable <code>x</code> cannot be changed by passing <code>x</code> as an argument to a function. When calling <code>change_value!(x)</code> in the above example, <code>y</code> is a newly created variable, bound initially to the value of <code>x</code>, i.e. <code>10</code>; then <code>y</code> is rebound to the constant <code>17</code>, while the variable <code>x</code> of the outer scope is left untouched.</p><p>But here is a thing you should pay attention to: suppose <code>x</code> is bound to an object of type <code>Array</code> (or any other <em>mutable</em> type). From within the function, you cannot "unbind" <code>x</code> from this Array, but you can change its content. For example:</p><pre><code class="language-julia-repl">julia> x = [1,2,3]
|
||
3-element Array{Int64,1}:
|
||
1
|
||
2
|
||
3
|
||
|
||
julia> function change_array!(A)
|
||
A[1] = 5
|
||
end
|
||
change_array! (generic function with 1 method)
|
||
|
||
julia> change_array!(x)
|
||
5
|
||
|
||
julia> x
|
||
3-element Array{Int64,1}:
|
||
5
|
||
2
|
||
3</code></pre><p>Here we created a function <code>change_array!()</code>, that assigns <code>5</code> to the first element of the passed array (bound to <code>x</code> at the call site, and bound to <code>A</code> within the function). Notice that, after the function call, <code>x</code> is still bound to the same array, but the content of that array changed: the variables <code>A</code> and <code>x</code> were distinct bindings refering to the same mutable <code>Array</code> object.</p><h3><a class="nav-anchor" id="Can-I-use-using-or-import-inside-a-function?-1" href="#Can-I-use-using-or-import-inside-a-function?-1">Can I use <code>using</code> or <code>import</code> inside a function?</a></h3><p>No, you are not allowed to have a <code>using</code> or <code>import</code> statement inside a function. If you want to import a module but only use its symbols inside a specific function or set of functions, you have two options:</p><ol><li><p>Use <code>import</code>:</p><pre><code class="language-julia">import Foo
|
||
function bar(...)
|
||
# ... refer to Foo symbols via Foo.baz ...
|
||
end</code></pre><p>This loads the module <code>Foo</code> and defines a variable <code>Foo</code> that refers to the module, but does not import any of the other symbols from the module into the current namespace. You refer to the <code>Foo</code> symbols by their qualified names <code>Foo.bar</code> etc.</p></li><li><p>Wrap your function in a module:</p><pre><code class="language-julia">module Bar
|
||
export bar
|
||
using Foo
|
||
function bar(...)
|
||
# ... refer to Foo.baz as simply baz ....
|
||
end
|
||
end
|
||
using Bar</code></pre><p>This imports all the symbols from <code>Foo</code>, but only inside the module <code>Bar</code>.</p></li></ol><h3><a class="nav-anchor" id="What-does-the-...-operator-do?-1" href="#What-does-the-...-operator-do?-1">What does the <code>...</code> operator do?</a></h3><h3><a class="nav-anchor" id="The-two-uses-of-the-...-operator:-slurping-and-splatting-1" href="#The-two-uses-of-the-...-operator:-slurping-and-splatting-1">The two uses of the <code>...</code> operator: slurping and splatting</a></h3><p>Many newcomers to Julia find the use of <code>...</code> operator confusing. Part of what makes the <code>...</code> operator confusing is that it means two different things depending on context.</p><h3><a class="nav-anchor" id="...-combines-many-arguments-into-one-argument-in-function-definitions-1" href="#...-combines-many-arguments-into-one-argument-in-function-definitions-1"><code>...</code> combines many arguments into one argument in function definitions</a></h3><p>In the context of function definitions, the <code>...</code> operator is used to combine many different arguments into a single argument. This use of <code>...</code> for combining many different arguments into a single argument is called slurping:</p><pre><code class="language-julia-repl">julia> function printargs(args...)
|
||
@printf("%s\n", typeof(args))
|
||
for (i, arg) in enumerate(args)
|
||
@printf("Arg %d = %s\n", i, arg)
|
||
end
|
||
end
|
||
printargs (generic function with 1 method)
|
||
|
||
julia> printargs(1, 2, 3)
|
||
Tuple{Int64,Int64,Int64}
|
||
Arg 1 = 1
|
||
Arg 2 = 2
|
||
Arg 3 = 3</code></pre><p>If Julia were a language that made more liberal use of ASCII characters, the slurping operator might have been written as <code><-...</code> instead of <code>...</code>.</p><h3><a class="nav-anchor" id="...-splits-one-argument-into-many-different-arguments-in-function-calls-1" href="#...-splits-one-argument-into-many-different-arguments-in-function-calls-1"><code>...</code> splits one argument into many different arguments in function calls</a></h3><p>In contrast to the use of the <code>...</code> operator to denote slurping many different arguments into one argument when defining a function, the <code>...</code> operator is also used to cause a single function argument to be split apart into many different arguments when used in the context of a function call. This use of <code>...</code> is called splatting:</p><pre><code class="language-julia-repl">julia> function threeargs(a, b, c)
|
||
@printf("a = %s::%s\n", a, typeof(a))
|
||
@printf("b = %s::%s\n", b, typeof(b))
|
||
@printf("c = %s::%s\n", c, typeof(c))
|
||
end
|
||
threeargs (generic function with 1 method)
|
||
|
||
julia> vec = [1, 2, 3]
|
||
3-element Array{Int64,1}:
|
||
1
|
||
2
|
||
3
|
||
|
||
julia> threeargs(vec...)
|
||
a = 1::Int64
|
||
b = 2::Int64
|
||
c = 3::Int64</code></pre><p>If Julia were a language that made more liberal use of ASCII characters, the splatting operator might have been written as <code>...-></code> instead of <code>...</code>.</p><h2><a class="nav-anchor" id="Types,-type-declarations,-and-constructors-1" href="#Types,-type-declarations,-and-constructors-1">Types, type declarations, and constructors</a></h2><h3><a class="nav-anchor" id="man-type-stability-1" href="#man-type-stability-1">What does "type-stable" mean?</a></h3><p>It means that the type of the output is predictable from the types of the inputs. In particular, it means that the type of the output cannot vary depending on the <em>values</em> of the inputs. The following code is <em>not</em> type-stable:</p><pre><code class="language-julia-repl">julia> function unstable(flag::Bool)
|
||
if flag
|
||
return 1
|
||
else
|
||
return 1.0
|
||
end
|
||
end
|
||
unstable (generic function with 1 method)</code></pre><p>It returns either an <code>Int</code> or a <a href="../stdlib/numbers.html#Core.Float64"><code>Float64</code></a> depending on the value of its argument. Since Julia can't predict the return type of this function at compile-time, any computation that uses it will have to guard against both types possibly occurring, making generation of fast machine code difficult.</p><h3><a class="nav-anchor" id="faq-domain-errors-1" href="#faq-domain-errors-1">Why does Julia give a <code>DomainError</code> for certain seemingly-sensible operations?</a></h3><p>Certain operations make mathematical sense but result in errors:</p><pre><code class="language-julia-repl">julia> sqrt(-2.0)
|
||
ERROR: DomainError:
|
||
sqrt will only return a complex result if called with a complex argument. Try sqrt(complex(x)).
|
||
Stacktrace:
|
||
[1] sqrt(::Float64) at ./math.jl:425
|
||
|
||
julia> 2^-5
|
||
ERROR: DomainError:
|
||
Cannot raise an integer x to a negative power -n.
|
||
Make x a float by adding a zero decimal (e.g. 2.0^-n instead of 2^-n), or write 1/x^n, float(x)^-n, or (x//1)^-n.
|
||
Stacktrace:
|
||
[1] power_by_squaring(::Int64, ::Int64) at ./intfuncs.jl:173
|
||
[2] literal_pow(::Base.#^, ::Int64, ::Type{Val{-5}}) at ./intfuncs.jl:208</code></pre><p>This behavior is an inconvenient consequence of the requirement for type-stability. In the case of <a href="../stdlib/math.html#Base.sqrt"><code>sqrt()</code></a>, most users want <code>sqrt(2.0)</code> to give a real number, and would be unhappy if it produced the complex number <code>1.4142135623730951 + 0.0im</code>. One could write the <a href="../stdlib/math.html#Base.sqrt"><code>sqrt()</code></a> function to switch to a complex-valued output only when passed a negative number (which is what <a href="../stdlib/math.html#Base.sqrt"><code>sqrt()</code></a> does in some other languages), but then the result would not be <a href="faq.html#man-type-stability-1">type-stable</a> and the <a href="../stdlib/math.html#Base.sqrt"><code>sqrt()</code></a> function would have poor performance.</p><p>In these and other cases, you can get the result you want by choosing an <em>input type</em> that conveys your willingness to accept an <em>output type</em> in which the result can be represented:</p><pre><code class="language-julia-repl">julia> sqrt(-2.0+0im)
|
||
0.0 + 1.4142135623730951im
|
||
|
||
julia> 2.0^-5
|
||
0.03125</code></pre><h3><a class="nav-anchor" id="Why-does-Julia-use-native-machine-integer-arithmetic?-1" href="#Why-does-Julia-use-native-machine-integer-arithmetic?-1">Why does Julia use native machine integer arithmetic?</a></h3><p>Julia uses machine arithmetic for integer computations. This means that the range of <code>Int</code> values is bounded and wraps around at either end so that adding, subtracting and multiplying integers can overflow or underflow, leading to some results that can be unsettling at first:</p><pre><code class="language-julia-repl">julia> typemax(Int)
|
||
9223372036854775807
|
||
|
||
julia> ans+1
|
||
-9223372036854775808
|
||
|
||
julia> -ans
|
||
-9223372036854775808
|
||
|
||
julia> 2*ans
|
||
0</code></pre><p>Clearly, this is far from the way mathematical integers behave, and you might think it less than ideal for a high-level programming language to expose this to the user. For numerical work where efficiency and transparency are at a premium, however, the alternatives are worse.</p><p>One alternative to consider would be to check each integer operation for overflow and promote results to bigger integer types such as <a href="../stdlib/numbers.html#Core.Int128"><code>Int128</code></a> or <a href="../stdlib/numbers.html#Base.GMP.BigInt"><code>BigInt</code></a> in the case of overflow. Unfortunately, this introduces major overhead on every integer operation (think incrementing a loop counter) – it requires emitting code to perform run-time overflow checks after arithmetic instructions and branches to handle potential overflows. Worse still, this would cause every computation involving integers to be type-unstable. As we mentioned above, <a href="faq.html#man-type-stability-1">type-stability is crucial</a> for effective generation of efficient code. If you can't count on the results of integer operations being integers, it's impossible to generate fast, simple code the way C and Fortran compilers do.</p><p>A variation on this approach, which avoids the appearance of type instability is to merge the <code>Int</code> and <a href="../stdlib/numbers.html#Base.GMP.BigInt"><code>BigInt</code></a> types into a single hybrid integer type, that internally changes representation when a result no longer fits into the size of a machine integer. While this superficially avoids type-instability at the level of Julia code, it just sweeps the problem under the rug by foisting all of the same difficulties onto the C code implementing this hybrid integer type. This approach <em>can</em> be made to work and can even be made quite fast in many cases, but has several drawbacks. One problem is that the in-memory representation of integers and arrays of integers no longer match the natural representation used by C, Fortran and other languages with native machine integers. Thus, to interoperate with those languages, we would ultimately need to introduce native integer types anyway. Any unbounded representation of integers cannot have a fixed number of bits, and thus cannot be stored inline in an array with fixed-size slots – large integer values will always require separate heap-allocated storage. And of course, no matter how clever a hybrid integer implementation one uses, there are always performance traps – situations where performance degrades unexpectedly. Complex representation, lack of interoperability with C and Fortran, the inability to represent integer arrays without additional heap storage, and unpredictable performance characteristics make even the cleverest hybrid integer implementations a poor choice for high-performance numerical work.</p><p>An alternative to using hybrid integers or promoting to BigInts is to use saturating integer arithmetic, where adding to the largest integer value leaves it unchanged and likewise for subtracting from the smallest integer value. This is precisely what Matlab™ does:</p><pre><code class="language-none">>> int64(9223372036854775807)
|
||
|
||
ans =
|
||
|
||
9223372036854775807
|
||
|
||
>> int64(9223372036854775807) + 1
|
||
|
||
ans =
|
||
|
||
9223372036854775807
|
||
|
||
>> int64(-9223372036854775808)
|
||
|
||
ans =
|
||
|
||
-9223372036854775808
|
||
|
||
>> int64(-9223372036854775808) - 1
|
||
|
||
ans =
|
||
|
||
-9223372036854775808</code></pre><p>At first blush, this seems reasonable enough since 9223372036854775807 is much closer to 9223372036854775808 than -9223372036854775808 is and integers are still represented with a fixed size in a natural way that is compatible with C and Fortran. Saturated integer arithmetic, however, is deeply problematic. The first and most obvious issue is that this is not the way machine integer arithmetic works, so implementing saturated operations requires emitting instructions after each machine integer operation to check for underflow or overflow and replace the result with <a href="../stdlib/base.html#Base.typemin"><code>typemin(Int)</code></a> or <a href="../stdlib/base.html#Base.typemax"><code>typemax(Int)</code></a> as appropriate. This alone expands each integer operation from a single, fast instruction into half a dozen instructions, probably including branches. Ouch. But it gets worse – saturating integer arithmetic isn't associative. Consider this Matlab computation:</p><pre><code class="language-none">>> n = int64(2)^62
|
||
4611686018427387904
|
||
|
||
>> n + (n - 1)
|
||
9223372036854775807
|
||
|
||
>> (n + n) - 1
|
||
9223372036854775806</code></pre><p>This makes it hard to write many basic integer algorithms since a lot of common techniques depend on the fact that machine addition with overflow <em>is</em> associative. Consider finding the midpoint between integer values <code>lo</code> and <code>hi</code> in Julia using the expression <code>(lo + hi) >>> 1</code>:</p><pre><code class="language-julia-repl">julia> n = 2^62
|
||
4611686018427387904
|
||
|
||
julia> (n + 2n) >>> 1
|
||
6917529027641081856</code></pre><p>See? No problem. That's the correct midpoint between 2^62 and 2^63, despite the fact that <code>n + 2n</code> is -4611686018427387904. Now try it in Matlab:</p><pre><code class="language-none">>> (n + 2*n)/2
|
||
|
||
ans =
|
||
|
||
4611686018427387904</code></pre><p>Oops. Adding a <code>>>></code> operator to Matlab wouldn't help, because saturation that occurs when adding <code>n</code> and <code>2n</code> has already destroyed the information necessary to compute the correct midpoint.</p><p>Not only is lack of associativity unfortunate for programmers who cannot rely it for techniques like this, but it also defeats almost anything compilers might want to do to optimize integer arithmetic. For example, since Julia integers use normal machine integer arithmetic, LLVM is free to aggressively optimize simple little functions like <code>f(k) = 5k-1</code>. The machine code for this function is just this:</p><pre><code class="language-julia-repl">julia> code_native(f, Tuple{Int})
|
||
.text
|
||
Filename: none
|
||
pushq %rbp
|
||
movq %rsp, %rbp
|
||
Source line: 1
|
||
leaq -1(%rdi,%rdi,4), %rax
|
||
popq %rbp
|
||
retq
|
||
nopl (%rax,%rax)</code></pre><p>The actual body of the function is a single <code>leaq</code> instruction, which computes the integer multiply and add at once. This is even more beneficial when <code>f</code> gets inlined into another function:</p><pre><code class="language-julia-repl">julia> function g(k, n)
|
||
for i = 1:n
|
||
k = f(k)
|
||
end
|
||
return k
|
||
end
|
||
g (generic function with 1 methods)
|
||
|
||
julia> code_native(g, Tuple{Int,Int})
|
||
.text
|
||
Filename: none
|
||
pushq %rbp
|
||
movq %rsp, %rbp
|
||
Source line: 2
|
||
testq %rsi, %rsi
|
||
jle L26
|
||
nopl (%rax)
|
||
Source line: 3
|
||
L16:
|
||
leaq -1(%rdi,%rdi,4), %rdi
|
||
Source line: 2
|
||
decq %rsi
|
||
jne L16
|
||
Source line: 5
|
||
L26:
|
||
movq %rdi, %rax
|
||
popq %rbp
|
||
retq
|
||
nop</code></pre><p>Since the call to <code>f</code> gets inlined, the loop body ends up being just a single <code>leaq</code> instruction. Next, consider what happens if we make the number of loop iterations fixed:</p><pre><code class="language-julia-repl">julia> function g(k)
|
||
for i = 1:10
|
||
k = f(k)
|
||
end
|
||
return k
|
||
end
|
||
g (generic function with 2 methods)
|
||
|
||
julia> code_native(g,(Int,))
|
||
.text
|
||
Filename: none
|
||
pushq %rbp
|
||
movq %rsp, %rbp
|
||
Source line: 3
|
||
imulq $9765625, %rdi, %rax # imm = 0x9502F9
|
||
addq $-2441406, %rax # imm = 0xFFDABF42
|
||
Source line: 5
|
||
popq %rbp
|
||
retq
|
||
nopw %cs:(%rax,%rax)</code></pre><p>Because the compiler knows that integer addition and multiplication are associative and that multiplication distributes over addition – neither of which is true of saturating arithmetic – it can optimize the entire loop down to just a multiply and an add. Saturated arithmetic completely defeats this kind of optimization since associativity and distributivity can fail at each loop iteration, causing different outcomes depending on which iteration the failure occurs in. The compiler can unroll the loop, but it cannot algebraically reduce multiple operations into fewer equivalent operations.</p><p>The most reasonable alternative to having integer arithmetic silently overflow is to do checked arithmetic everywhere, raising errors when adds, subtracts, and multiplies overflow, producing values that are not value-correct. In this <a href="http://danluu.com/integer-overflow/">blog post</a>, Dan Luu analyzes this and finds that rather than the trivial cost that this approach should in theory have, it ends up having a substantial cost due to compilers (LLVM and GCC) not gracefully optimizing around the added overflow checks. If this improves in the future, we could consider defaulting to checked integer arithmetic in Julia, but for now, we have to live with the possibility of overflow.</p><h3><a class="nav-anchor" id="What-are-the-possible-causes-of-an-UndefVarError-during-remote-execution?-1" href="#What-are-the-possible-causes-of-an-UndefVarError-during-remote-execution?-1">What are the possible causes of an <code>UndefVarError</code> during remote execution?</a></h3><p>As the error states, an immediate cause of an <code>UndefVarError</code> on a remote node is that a binding by that name does not exist. Let us explore some of the possible causes.</p><pre><code class="language-julia-repl">julia> module Foo
|
||
foo() = remotecall_fetch(x->x, 2, "Hello")
|
||
end
|
||
|
||
julia> Foo.foo()
|
||
ERROR: On worker 2:
|
||
UndefVarError: Foo not defined
|
||
[...]</code></pre><p>The closure <code>x->x</code> carries a reference to <code>Foo</code>, and since <code>Foo</code> is unavailable on node 2, an <code>UndefVarError</code> is thrown.</p><p>Globals under modules other than <code>Main</code> are not serialized by value to the remote node. Only a reference is sent. Functions which create global bindings (except under <code>Main</code>) may cause an <code>UndefVarError</code> to be thrown later.</p><pre><code class="language-julia-repl">julia> @everywhere module Foo
|
||
function foo()
|
||
global gvar = "Hello"
|
||
remotecall_fetch(()->gvar, 2)
|
||
end
|
||
end
|
||
|
||
julia> Foo.foo()
|
||
ERROR: On worker 2:
|
||
UndefVarError: gvar not defined
|
||
[...]</code></pre><p>In the above example, <code>@everywhere module Foo</code> defined <code>Foo</code> on all nodes. However the call to <code>Foo.foo()</code> created a new global binding <code>gvar</code> on the local node, but this was not found on node 2 resulting in an <code>UndefVarError</code> error.</p><p>Note that this does not apply to globals created under module <code>Main</code>. Globals under module <code>Main</code> are serialized and new bindings created under <code>Main</code> on the remote node.</p><pre><code class="language-julia-repl">julia> gvar_self = "Node1"
|
||
"Node1"
|
||
|
||
julia> remotecall_fetch(()->gvar_self, 2)
|
||
"Node1"
|
||
|
||
julia> remotecall_fetch(whos, 2)
|
||
From worker 2: Base 41762 KB Module
|
||
From worker 2: Core 27337 KB Module
|
||
From worker 2: Foo 2477 bytes Module
|
||
From worker 2: Main 46191 KB Module
|
||
From worker 2: gvar_self 13 bytes String</code></pre><p>This does not apply to <code>function</code> or <code>type</code> declarations. However, anonymous functions bound to global variables are serialized as can be seen below.</p><pre><code class="language-julia-repl">julia> bar() = 1
|
||
bar (generic function with 1 method)
|
||
|
||
julia> remotecall_fetch(bar, 2)
|
||
ERROR: On worker 2:
|
||
UndefVarError: #bar not defined
|
||
[...]
|
||
|
||
julia> anon_bar = ()->1
|
||
(::#21) (generic function with 1 method)
|
||
|
||
julia> remotecall_fetch(anon_bar, 2)
|
||
1</code></pre><h2><a class="nav-anchor" id="Packages-and-Modules-1" href="#Packages-and-Modules-1">Packages and Modules</a></h2><h3><a class="nav-anchor" id="What-is-the-difference-between-"using"-and-"importall"?-1" href="#What-is-the-difference-between-"using"-and-"importall"?-1">What is the difference between "using" and "importall"?</a></h3><p>There is only one difference, and on the surface (syntax-wise) it may seem very minor. The difference between <code>using</code> and <code>importall</code> is that with <code>using</code> you need to say <code>function Foo.bar(..</code> to extend module Foo's function bar with a new method, but with <code>importall</code> or <code>import Foo.bar</code>, you only need to say <code>function bar(...</code> and it automatically extends module Foo's function bar.</p><p>If you use <code>importall</code>, then <code>function Foo.bar(...</code> and <code>function bar(...</code> become equivalent. If you use <code>using</code>, then they are different.</p><p>The reason this is important enough to have been given separate syntax is that you don't want to accidentally extend a function that you didn't know existed, because that could easily cause a bug. This is most likely to happen with a method that takes a common type like a string or integer, because both you and the other module could define a method to handle such a common type. If you use <code>importall</code>, then you'll replace the other module's implementation of <code>bar(s::AbstractString)</code> with your new implementation, which could easily do something completely different (and break all/many future usages of the other functions in module Foo that depend on calling bar).</p><h2><a class="nav-anchor" id="Nothingness-and-missing-values-1" href="#Nothingness-and-missing-values-1">Nothingness and missing values</a></h2><h3><a class="nav-anchor" id="How-does-"null"-or-"nothingness"-work-in-Julia?-1" href="#How-does-"null"-or-"nothingness"-work-in-Julia?-1">How does "null" or "nothingness" work in Julia?</a></h3><p>Unlike many languages (for example, C and Java), Julia does not have a "null" value. When a reference (variable, object field, or array element) is uninitialized, accessing it will immediately throw an error. This situation can be detected using the <code>isdefined</code> function.</p><p>Some functions are used only for their side effects, and do not need to return a value. In these cases, the convention is to return the value <code>nothing</code>, which is just a singleton object of type <code>Void</code>. This is an ordinary type with no fields; there is nothing special about it except for this convention, and that the REPL does not print anything for it. Some language constructs that would not otherwise have a value also yield <code>nothing</code>, for example <code>if false; end</code>.</p><p>For situations where a value exists only sometimes (for example, missing statistical data), it is best to use the <code>Nullable{T}</code> type, which allows specifying the type of a missing value.</p><p>The empty tuple (<code>()</code>) is another form of nothingness. But, it should not really be thought of as nothing but rather a tuple of zero values.</p><p>In code written for Julia prior to version 0.4 you may occasionally see <code>None</code>, which is quite different. It is the empty (or "bottom") type, a type with no values and no subtypes (except itself). This is now written as <code>Union{}</code> (an empty union type). You will generally not need to use this type.</p><h2><a class="nav-anchor" id="Memory-1" href="#Memory-1">Memory</a></h2><h3><a class="nav-anchor" id="Why-does-x-y-allocate-memory-when-x-and-y-are-arrays?-1" href="#Why-does-x-y-allocate-memory-when-x-and-y-are-arrays?-1">Why does <code>x += y</code> allocate memory when <code>x</code> and <code>y</code> are arrays?</a></h3><p>In Julia, <code>x += y</code> gets replaced during parsing by <code>x = x + y</code>. For arrays, this has the consequence that, rather than storing the result in the same location in memory as <code>x</code>, it allocates a new array to store the result.</p><p>While this behavior might surprise some, the choice is deliberate. The main reason is the presence of immutable objects within Julia, which cannot change their value once created. Indeed, a number is an immutable object; the statements <code>x = 5; x += 1</code> do not modify the meaning of <code>5</code>, they modify the value bound to <code>x</code>. For an immutable, the only way to change the value is to reassign it.</p><p>To amplify a bit further, consider the following function:</p><pre><code class="language-julia">function power_by_squaring(x, n::Int)
|
||
ispow2(n) || error("This implementation only works for powers of 2")
|
||
while n >= 2
|
||
x *= x
|
||
n >>= 1
|
||
end
|
||
x
|
||
end</code></pre><p>After a call like <code>x = 5; y = power_by_squaring(x, 4)</code>, you would get the expected result: <code>x == 5 && y == 625</code>. However, now suppose that <code>*=</code>, when used with matrices, instead mutated the left hand side. There would be two problems:</p><ul><li><p>For general square matrices, <code>A = A*B</code> cannot be implemented without temporary storage: <code>A[1,1]</code> gets computed and stored on the left hand side before you're done using it on the right hand side.</p></li><li><p>Suppose you were willing to allocate a temporary for the computation (which would eliminate most of the point of making <code>*=</code> work in-place); if you took advantage of the mutability of <code>x</code>, then this function would behave differently for mutable vs. immutable inputs. In particular, for immutable <code>x</code>, after the call you'd have (in general) <code>y != x</code>, but for mutable <code>x</code> you'd have <code>y == x</code>.</p></li></ul><p>Because supporting generic programming is deemed more important than potential performance optimizations that can be achieved by other means (e.g., using explicit loops), operators like <code>+=</code> and <code>*=</code> work by rebinding new values.</p><h2><a class="nav-anchor" id="Asynchronous-IO-and-concurrent-synchronous-writes-1" href="#Asynchronous-IO-and-concurrent-synchronous-writes-1">Asynchronous IO and concurrent synchronous writes</a></h2><h3><a class="nav-anchor" id="Why-do-concurrent-writes-to-the-same-stream-result-in-inter-mixed-output?-1" href="#Why-do-concurrent-writes-to-the-same-stream-result-in-inter-mixed-output?-1">Why do concurrent writes to the same stream result in inter-mixed output?</a></h3><p>While the streaming I/O API is synchronous, the underlying implementation is fully asynchronous.</p><p>Consider the printed output from the following:</p><pre><code class="language-julia-repl">julia> @sync for i in 1:3
|
||
@async write(STDOUT, string(i), " Foo ", " Bar ")
|
||
end
|
||
123 Foo Foo Foo Bar Bar Bar</code></pre><p>This is happening because, while the <code>write</code> call is synchronous, the writing of each argument yields to other tasks while waiting for that part of the I/O to complete.</p><p><code>print</code> and <code>println</code> "lock" the stream during a call. Consequently changing <code>write</code> to <code>println</code> in the above example results in:</p><pre><code class="language-julia-repl">julia> @sync for i in 1:3
|
||
@async println(STDOUT, string(i), " Foo ", " Bar ")
|
||
end
|
||
1 Foo Bar
|
||
2 Foo Bar
|
||
3 Foo Bar</code></pre><p>You can lock your writes with a <code>ReentrantLock</code> like this:</p><pre><code class="language-julia-repl">julia> l = ReentrantLock()
|
||
ReentrantLock(Nullable{Task}(), Condition(Any[]), 0)
|
||
|
||
julia> @sync for i in 1:3
|
||
@async begin
|
||
lock(l)
|
||
try
|
||
write(STDOUT, string(i), " Foo ", " Bar ")
|
||
finally
|
||
unlock(l)
|
||
end
|
||
end
|
||
end
|
||
1 Foo Bar 2 Foo Bar 3 Foo Bar</code></pre><h2><a class="nav-anchor" id="Julia-Releases-1" href="#Julia-Releases-1">Julia Releases</a></h2><h3><a class="nav-anchor" id="Do-I-want-to-use-a-release,-beta,-or-nightly-version-of-Julia?-1" href="#Do-I-want-to-use-a-release,-beta,-or-nightly-version-of-Julia?-1">Do I want to use a release, beta, or nightly version of Julia?</a></h3><p>You may prefer the release version of Julia if you are looking for a stable code base. Releases generally occur every 6 months, giving you a stable platform for writing code.</p><p>You may prefer the beta version of Julia if you don't mind being slightly behind the latest bugfixes and changes, but find the slightly faster rate of changes more appealing. Additionally, these binaries are tested before they are published to ensure they are fully functional.</p><p>You may prefer the nightly version of Julia if you want to take advantage of the latest updates to the language, and don't mind if the version available today occasionally doesn't actually work.</p><p>Finally, you may also consider building Julia from source for yourself. This option is mainly for those individuals who are comfortable at the command line, or interested in learning. If this describes you, you may also be interested in reading our <a href="https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md">guidelines for contributing</a>.</p><p>Links to each of these download types can be found on the download page at <a href="https://julialang.org/downloads/">https://julialang.org/downloads/</a>. Note that not all versions of Julia are available for all platforms.</p><h3><a class="nav-anchor" id="When-are-deprecated-functions-removed?-1" href="#When-are-deprecated-functions-removed?-1">When are deprecated functions removed?</a></h3><p>Deprecated functions are removed after the subsequent release. For example, functions marked as deprecated in the 0.1 release will not be available starting with the 0.2 release.</p><footer><hr/><a class="previous" href="style-guide.html"><span class="direction">Previous</span><span class="title">Style Guide</span></a><a class="next" href="noteworthy-differences.html"><span class="direction">Next</span><span class="title">Noteworthy Differences from other Languages</span></a></footer></article></body></html>
|