Re: [julia-users] Syntax for composite type constructors
Thanks, https://github.com/mauro3/Parameters.jl does of course what I want and more.
[julia-users] Syntax for composite type constructors
When making instances of my composite Julia types, such as
foo = Foo(1, "bartxt", 3.14)
I often have to look up the definition, because I don't remember whether,
in this case, "bar" was the first or the second field:
type Foo
bar::AbstractString
baz::Int
qux::Float64
end
"bar" was the first field, so the correct construction is
foo = Foo("bartxt", 1, 3.14)
In this case the first, incorrect code would not compile because of no
matching method.
But for
type Goo
vertical::Float64
horizontal::Float64
qux::Float64
end
it is easy to write incorrect code when the order of the fields gets mixed
up, and such bugs are potentially difficult to find.
Wouldn't it be possible to allow (optionally) for a syntax like
foo = Foo(;bar=bartxt, baz=1, qux=3.14);
goo = Goo(;horizontal=186.,vertical=0.33, qux=3.14)
where the keyword arguments are the fieldnames of the type?
Often I remember the fields of a type, but not their order.
With this syntax the argument order would be arbitrary.
The syntax would imply, that incorrect, non-existing, or missing
fields/keywords result in an error.
Thanks for your consideration.
Re: [julia-users] Re: Strange behavior using "^" (power function)
In Julia there would be also BigFloat: julia> x=parse(BigFloat, "1.0525004") 1.0525003994 julia> x^6.0-x^6 0.00
[julia-users] Re: InexactError for Arrays
Thanks, yes, but I had expected that in the second command it would give me an Int64 Array, similar as in the 1st command I get automatically an Int64 scalar. But to be fair, like this it is already much better than Matlab: >> int32(5370)*8640 ans = 2147483647 >> [int32(5370)]*8640 ans = 2147483647 /Stephan
[julia-users] InexactError for Arrays
Is there a good reason for this? _ _ _ _(_)_ | A fresh approach to technical computing (_) | (_) (_)| Documentation: http://docs.julialang.org _ _ _| |_ __ _ | Type "?help" for help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 0.4.1 (2015-11-08 10:33 UTC) _/ |\__'_|_|_|\__'_| | |__/ | x86_64-redhat-linux julia> Int32(5730)*8640 49507200 julia> Int32[5730]*8640 ERROR: InexactError() in .* at arraymath.jl:127 in * at abstractarraymath.jl:55 julia> Thanks, Stephan
[julia-users] Re: InexactError for Arrays
julia> Int32[5730]*Int32(86400)
1-element Array{Int32,1}:
495072000
should certainly give the in memory smaller Int32 Array (and InexactError
if applicable). But an Int32 Array times an Int64 scalar could well give
automatically an Int64 array, I think. Then
julia> Int32[5730]*1
and similar things could be used to promote arrays (which otherwise seems
not that easy in Julia).
/Stephan
Re: [julia-users] Re: InexactError for Arrays
Yes, certainly one can argue here back and forth:
julia> Int32[5730]*86400e3
1-element Array{Float64,1}:
4.95072e11
julia> Int32[5730]*86400f3
1-element Array{Float32,1}:
4.95072e11
i.e. promotion also here the same as for scalar*scalar. My data are from
hardware sensors or counters, which deliver 8, 16 or 32 bit, memory
consumption in the computer is normally not an issue.
What's wrong with these solutions?
> julia> Array{Int64}(Int32[5730])
> 1-element Array{Int64,1}:
> 5730
>
> julia> convert(Array{Int64}, Int32[5730])
> 1-element Array{Int64,1}:
> 5730
>
> julia> map(Int64, Int32[5730])
> 1-element Array{Int64,1}:
> 5730
Good comprehensive set of solutions, thanks. Still,
julia> Int32[5730]*1
would be shorter and nevertheless easily readable, according to my taste.
Regards,
Stephan
[julia-users] Re: cannot open files in julia on Fedora 22
By looking at ~/.julia_history with vi I found the problem: somehow I had
keyed in at the beginning of a command a character that my vi displays as
^@, but it is invisible in the REPL. This character at the beginning
obviously causes REPL do ignore the rest of the statement and just show a
new prompt "julia>". The command with the in the REPL invisible ^@ at the
beginning was stored in the command history, and when getting it form the
history for trying variations of it I only achieved the same again, REPL
ignored these statements.
When trying to hunt down the problem I upgraded to 0.4, where in the REPL
the ^@ is also invisible but causes an error message
ERROR: syntax: invalid character literal ""
Am Mittwoch, 30. September 2015 22:17:29 UTC+2 schrieb Stephan Buchert:
>
> Since today julia refuses to open files for me:
>
> [scb@stride swarm]$ julia -f
>_
>_ _ _(_)_ | A fresh approach to technical computing
> (_) | (_) (_)| Documentation: http://docs.julialang.org
>_ _ _| |_ __ _ | Type "help()" for help.
> | | | | | | |/ _` | |
> | | |_| | | | (_| | | Version 0.3.11
> _/ |\__'_|_|_|\__'_| |
> |__/ | x86_64-redhat-linux
>
> julia> versioninfo()
> Julia Version 0.3.11
> Platform Info:
> System: Linux (x86_64-redhat-linux)
> CPU: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
> WORD_SIZE: 64
> BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
> LAPACK: libopenblasp.so.0
> LIBM: libopenlibm
> LLVM: libLLVM-3.5.0
>
> julia> f=open("$(homedir())/.juliarc.jl")
>
> julia> f
> ERROR: f not defined
>
> julia> f=Base.open("$(homedir())/.juliarc.jl")
>
> julia> f
> ERROR: f not defined
>
> julia> f=open("doesnotexist")
>
> julia> f
> ERROR: f not defined
>
> julia> f=stat("$(homedir())/.juliarc.jl")
>
> julia> f
> ERROR: f not defined
>
> but
>
> julia> readdir()
> 44-element Array{Union(ASCIIString,UTF8String),1}:
> "calval"
>
>
> Erasing the Fedora julia packages and reinstalling them didn't help,
> neither does rebooting the system. Otherwise my updated Fedora 22 works
> fine. Any idea what is going on?
>
> Thanks,
> Stephan
>
[julia-users] cannot open files in julia on Fedora 22
Since today julia refuses to open files for me:
[scb@stride swarm]$ julia -f
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type "help()" for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.11
_/ |\__'_|_|_|\__'_| |
|__/ | x86_64-redhat-linux
julia> versioninfo()
Julia Version 0.3.11
Platform Info:
System: Linux (x86_64-redhat-linux)
CPU: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
WORD_SIZE: 64
BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
LAPACK: libopenblasp.so.0
LIBM: libopenlibm
LLVM: libLLVM-3.5.0
julia> f=open("$(homedir())/.juliarc.jl")
julia> f
ERROR: f not defined
julia> f=Base.open("$(homedir())/.juliarc.jl")
julia> f
ERROR: f not defined
julia> f=open("doesnotexist")
julia> f
ERROR: f not defined
julia> f=stat("$(homedir())/.juliarc.jl")
julia> f
ERROR: f not defined
but
julia> readdir()
44-element Array{Union(ASCIIString,UTF8String),1}:
"calval"
Erasing the Fedora julia packages and reinstalling them didn't help,
neither does rebooting the system. Otherwise my updated Fedora 22 works
fine. Any idea what is going on?
Thanks,
Stephan
Re: [julia-users] Inset plots with Gadfly?
Thanks for the quick reply. I think, this will work.
Am Montag, 28. September 2015 13:43:53 UTC+2 schrieb Tom Breloff:
>
> I don't think it's directly built in, but here's how you would do it:
> ("p1.o[2]" and "p2.o[2]" are the Gadfly.Plot objects that are returned
> from Gadfly.plot commands:
>
> [image: Inline image 1]
>
> On Mon, Sep 28, 2015 at 7:11 AM, Stephan Buchert <steph...@gmail.com
> > wrote:
>
>> I'm trying out the different options to plot in Julia.
>>
>> Gadfly seems to lack the option to draw a plot at a specified
>> location/size on the page, like for example as an inset in another plot?
>>
>> Would it be possible to add an interface for doing this? I have been
>> staring at the code for hstack/vstack, but this stuff is too abstract for
>> me.
>>
>> Regards,
>> Stephan
>>
>>
>>
>
[julia-users] Inset plots with Gadfly?
I'm trying out the different options to plot in Julia. Gadfly seems to lack the option to draw a plot at a specified location/size on the page, like for example as an inset in another plot? Would it be possible to add an interface for doing this? I have been staring at the code for hstack/vstack, but this stuff is too abstract for me. Regards, Stephan
[julia-users] Re: unique function Matlab-Julia
Ok, thanks. At last here is a use case.
[julia-users] unique function Matlab-Julia
In Matlab I can do, for example, with daynum fractional day numbers: idaynum = floor(daynum); [umjd, im, iu] = unique(idaynum); % = how do I get the iu in Julia? % I need an observation pms listed per day in a file. % For performance reasons the parameter is retrieved from the file only once for each of the different integer days upms = pi*umjd; % = for illustration only, instead of really retrieving the observed parameter pms = upms(iu); % Now pms matches daynum, ie. when daynum=[1.0, 1.5, 1.8, 2.0, 2.2, 3.1 ], then pms approx. [3.14, 3.14, 3.14, 6.28, 6.28, 9.42] Probably this can be done elegantly also in Julia, but, coming from Matlab, for me not easy to see how?
[julia-users] Re: unique function Matlab-Julia
The case A is a vector is relevant for this, and I need ic, for A=C(ic)
[julia-users] DataFrames in v0.4?
With the Fedora built of v0.4 (VERSION 0.4.0-dev)
julia using DataFrames
results in a long list of warnings.
More generally, will DataFrames and the new Nullable types go together?
Technically probably yes:
julia df=DataFrame(A = Array(Nullable{Float64}, 5))
should work and initialize a DataFrame with one column and 5 rows.
But the NA type seems to become obsolete? The DataFrame would still be
handy for storing data selected from SQL tables!
[julia-users] Inconvenient DateTime construction?
I have a lot of time-stamped data (from a sensor). The physical unit of the time-stamps is milliseconds from some known instant of time. The natural type for these in Julia would be DateTime. But instead of simply constructing DateTime directly from my millisecond time-stamps, e.g. julia dt=DateTime(Millisecond(timestamp)) it seems that I have to write code to get second, minute, hour, day, month, year from my timestamps? Isn't there a way to directly set the instant value (which happens to be in millisecond) of a DateTime variable?
[julia-users] Re: Should reshape be reshape!?
Thanks for the explanations.
To me this seems now reasonable, after realizing that in Julia not only
reshape etc, but already the normal assignment b=a (for a an array) opens
for the same kind of surprises as I had noticed them with reshape. Coming
from Matlab this is a surprise, but for someone being familiar with certain
other languages, I guess, it is not?
julia a=[1, 2, 3]
3-element Array{Int64,1}:
1
2
3
julia b=a;
julia b[2]=0
0
julia a
3-element Array{Int64,1}:
1
0
3
But then +- is different again:
julia b+=1;
julia a
3-element Array{Int64,1}:
1
0
3
Perhaps one could add
in http://julia.readthedocs.org/en/latest/manual/noteworthy-differences/
under Matlab near the top something like:
* Arrays are mutable. Assignments like b=a and functions b=f(a) behave in
Matlab always equivalent to b=copy(a) and b=f(copy(a)), but in Julia b
becomes conceptually a pointer or different view of the contents of a. The
values of a can be altered through b.
PS: Yes, linear indices work directly also in Julia, I had overlooked this
Am Montag, 13. Oktober 2014 10:33:26 UTC+2 schrieb Jutho:
Some more comments / answers:
I too was confused by the precise use of ! when I first started using
Julia in cases like reshape. However, it is very clear that reshape should
not have an exclamation mark.
The use of ! in Julia functions is whenever the function modifies one of
its input arguments. This can be for several reasons:
1. The function performs some operation in-place: e.g.
scale!(A,lambda) multiplies all elements of the array A with the scalar
lambda in place.
2. The operation stores the result of the computation in one
(typically the first) argument: e.g. copy!(B,A), permutedims!(B,A,perm),
scale!(B,A,lambda), Base.transpose!(B,A): do something with the data of A
and store the result in the pre-allocated but not necessarily initialised
array B
3. The function overwrites the input arguments for use as temporary
workspace, but the actual result is just a normal return value as in
typical functions: e.g. the different [eig,svd,qr]fact!(A) methods
The Base.LinAlg.BLAS methods do something in between 1. and 2.; they store
the result of the computation in a dedicated 'output' argument as in 2.,
but they can also just add the result to that output argument, in which
case it needs to be correctly initialised.
In summary, the exclamation mark means that if you need the original
values of all of the arguments after calling he function, you should better
make a copy, since calling the function allows it to destroy the original
values of its arguments (only possible with arrays or other mutable types).
Also note that most of these functions do not change the size of array
arguments, resize! is one of the notable few exceptions and only works with
one-dimensional arrays (vectors).
reshape doesn't fit in any of these categories. B=reshape(A,newsize) does
not destroy the values of a. It is however true that the output B shares
data with A, just like if you do B=slice(A,...) or B=sub(A,...). Note that
none of these functions use an exclamation mark, nor is there any other
stylistic convention to indicate that this happens. That's just a new
aspect of the language that you have to take into account when coming from
e.g. Matlab, but that is very natural when coming from e.g. C.
Finally, note that linear indexing indeed works on an array without
reshaping, but that if you want the 'vectorized' version a multidimensional
array, there is the build in function B=vec(A), which is indeed equivalent
to B=reshape(A,prod(size(A)))
Op zaterdag 11 oktober 2014 22:20:13 UTC+2 schreef Stephan Buchert:
julia a=[1 2; 3 4; 5 6]
3x2 Array{Int64,2}:
1 2
3 4
5 6
julia b=reshape(a, prod(size(a)));
julia b[3]=0
0
julia a
3x2 Array{Int64,2}:
1 2
3 4
0 6
[julia-users] Re: Should reshape be reshape!?
I have now proposed to describe reshape under the 2nd bullet together with
assignment, because like assignment also reshape returns a new reference to
a value array. My proposed text is perhaps quite wordy, for a more terse
style only the first sentence would be enough:
* Arrays are assigned by reference. After ``A=B``, assigning into ``B``
will modify ``A`` as well, the same is true after ``A=reshape(B, ...)``.
In Matlab assignment and the reshape function are equivalent to
``A=copy(B)``
and``A=reshape(copy(B), ...)``, respectively. In Julia assignment
conceptually creates another pointer to a value array, and the reshape
function a different view of it. But beware, e.g. ``A+=0``, which does
not exist in Matlab, is in Julia equivalent to A=copy(A)+0, thereafter
assigning into ``B`` does not modify ``A`` any more.
Also the third bullet, function arguments, could become clearer through
expansion, in my opinion.
Am Montag, 13. Oktober 2014 20:19:26 UTC+2 schrieb Jutho:
Maybe point 3 on the noteworthy differences list could be expanded. If
Stephan doesn't do so, I can try to give it a shot later
Op maandag 13 oktober 2014 19:53:58 UTC+2 schreef Ivar Nesje:
This behaviour is already bullet 2 and 3 on the list you suggested.
Emphasizing that Matlab implicitly inserts a copy(x), when you mutate
arrays after some boundaries might be a good idea. I also find it somewhat
hard to grasp the consequences of the current wording, but I'm not the
target audience for that part of the documentation.
As always when you want to change something in Julia, the prefered way is
to submit a pull request on Github. For documentation, you can even use the
github
web ui
https://github.com/JuliaLang/julia/edit/master/doc/manual/noteworthy-differences.rst
to
edit. If you open a pull request you should also link to this thread as
previous discussion.
Regards Ivar
kl. 16:35:52 UTC+2 mandag 13. oktober 2014 skrev Stephan Buchert følgende:
Thanks for the explanations.
To me this seems now reasonable, after realizing that in Julia not only
reshape etc, but already the normal assignment b=a (for a an array) opens
for the same kind of surprises as I had noticed them with reshape. Coming
from Matlab this is a surprise, but for someone being familiar with certain
other languages, I guess, it is not?
julia a=[1, 2, 3]
3-element Array{Int64,1}:
1
2
3
julia b=a;
julia b[2]=0
0
julia a
3-element Array{Int64,1}:
1
0
3
But then +- is different again:
julia b+=1;
julia a
3-element Array{Int64,1}:
1
0
3
Perhaps one could add in
http://julia.readthedocs.org/en/latest/manual/noteworthy-differences/
under Matlab near the top something like:
* Arrays are mutable. Assignments like b=a and functions b=f(a) behave
in Matlab always equivalent to b=copy(a) and b=f(copy(a)), but in Julia b
becomes conceptually a pointer or different view of the contents of a. The
values of a can be altered through b.
PS: Yes, linear indices work directly also in Julia, I had overlooked
this
Am Montag, 13. Oktober 2014 10:33:26 UTC+2 schrieb Jutho:
Some more comments / answers:
I too was confused by the precise use of ! when I first started using
Julia in cases like reshape. However, it is very clear that reshape should
not have an exclamation mark.
The use of ! in Julia functions is whenever the function modifies one
of its input arguments. This can be for several reasons:
1. The function performs some operation in-place: e.g.
scale!(A,lambda) multiplies all elements of the array A with the scalar
lambda in place.
2. The operation stores the result of the computation in one
(typically the first) argument: e.g. copy!(B,A),
permutedims!(B,A,perm),
scale!(B,A,lambda), Base.transpose!(B,A): do something with the data of
A
and store the result in the pre-allocated but not necessarily
initialised
array B
3. The function overwrites the input arguments for use as temporary
workspace, but the actual result is just a normal return value as in
typical functions: e.g. the different [eig,svd,qr]fact!(A) methods
The Base.LinAlg.BLAS methods do something in between 1. and 2.; they
store the result of the computation in a dedicated 'output' argument as in
2., but they can also just add the result to that output argument, in
which
case it needs to be correctly initialised.
In summary, the exclamation mark means that if you need the original
values of all of the arguments after calling he function, you should
better
make a copy, since calling the function allows it to destroy the original
values of its arguments (only possible with arrays or other mutable types).
Also note that most of these functions do not change the size of array
arguments, resize! is one of the notable few exceptions and only works
with
one-dimensional arrays (vectors).
reshape doesn't
[julia-users] Should reshape be reshape!?
julia a=[1 2; 3 4; 5 6]
3x2 Array{Int64,2}:
1 2
3 4
5 6
julia b=reshape(a, prod(size(a)));
julia b[3]=0
0
julia a
3x2 Array{Int64,2}:
1 2
3 4
0 6
[julia-users] Re: Should reshape be reshape!?
Yes, this is nice.
I had expected, that
b=reshape(a, ...)
is equivalent to
b=reshape(copy(a), ...)
i.e. changing the values in b wouldn't be visible in a. And that a function
creating only a new binding to the same values would be reshape! Compare
also with resize!
But anyway, great. Now I can get Matlab-type linear indices:
julia vector(a)=reshape(a, prod(size(a)))
vector (generic function with 1 method)
julia a=[1 2; 3 4; 5 6]
3x2 Array{Int64,2}:
1 2
3 4
5 6
julia vector(a)[3]=0
0
julia a
3x2 Array{Int64,2}:
1 2
3 4
0 6
Am Samstag, 11. Oktober 2014 22:33:30 UTC+2 schrieb Peter Simon:
It's not necessary because you can assign the result of reshape to the
same variable with virtually no overhead:
julia a = rand(1000,100,100);
julia @time a = reshape(a,prod(size(a)));
elapsed time: 1.1732e-5 seconds (336 bytes allocated)
--Peter
On Saturday, October 11, 2014 1:20:13 PM UTC-7, Stephan Buchert wrote:
julia a=[1 2; 3 4; 5 6]
3x2 Array{Int64,2}:
1 2
3 4
5 6
julia b=reshape(a, prod(size(a)));
julia b[3]=0
0
julia a
3x2 Array{Int64,2}:
1 2
3 4
0 6
[julia-users] Getting at an array of C strings in a callback function?
The C function is
int sqlite3_exec(
sqlite3*, /* An open database */
const char *sql, /* SQL to be evaluated */
int (*callback)(void*,int,char**,char**), /* Callback function */
void *,/* 1st argument to callback */
char **errmsg /* Error msg written here */
);
and the documention says:
The 3rd argument to the sqlite3_exec() callback is an array of pointers to
strings
My Julia function handed over for callback is
function printrow(::Ptr{Void}, ncol::Cint, rescolp::Ptr{Ptr{Uint8}},
colnmp::Ptr{Ptr{Uint8}})
for k=1:ncol
print($(bytestring(unsafe_load(rescolp, k))) )
end
println()
cint(0)
end
When executing a test case I get ERROR: function is not yet c-callable
function printrow(::Ptr{Void}, ncol::Cint, rescolp::Ptr{Void},
colnmp::Ptr{Void})
println(ncol = $ncol)
end
works, but I would of course like to print the strings themselves. Several
of my efforts to use the Julia pointer_to_array, etc were not successful.
[julia-users] Re: Getting at an array of C strings in a callback function?
Great, thanks, your solution with a precallback works also for me. I have
the package from
http://copr.fedoraproject.org/coprs/nalimilan/julia/
which is released Julia Version 0.3.1
Sqlite hands in some cases NULL pointers to the callback, which apparently
is no good input for bytestring. Therefore I had to do instead
precallback = function printrow(::Ptr{Void}, ncol::Cint,
rescolp::Ptr{Ptr{Uint8}}, colnmp::Ptr{Ptr{Uint8}})
for k=1:ncol
p = unsafe_load(rescolp, k)
if p!=C_NULL
print($(bytestring(p))|);
end
end
println()
convert(Cint, 0)
end
[julia-users] Re: Function Argument Passing
Thanks for the kind explanations and references that I had missed, seems
clear to me now.
As a footnote, I was looking for a way to enforce Matlab-like behaviour,
that is changing the contents of an array argument inside a function is
invisible to the caller.
Unsuccessful attempt:
function f!(x)
x=x # == does not copy x, it seems to get optimized away
x[:]=x+1 # == this is still visible to the caller
end
but
function f(x)
x=copy(x) # == copies x in function scope, for numeric arrays x=x+0 works
also
x{:]=x+1# == this is now invisible to the caller
end
[julia-users] Function Argument Passing
From the manual
Argument Passing Behavior: ...means that values are not copied when they
are passed to functions. ...Modifications to mutable values (such as
Arrays) made within a function will be visible to the caller.
I get
julia function f(x)
x=x+1
y=x+1
end
f (generic function with 1 method)
julia x=[1:5]'
1x5 Array{Int64,2}:
1 2 3 4 5
julia y=f(x)
1x5 Array{Int64,2}:
3 4 5 6 7
julia x
1x5 Array{Int64,2}:
1 2 3 4 5
Apparently Array x is copied inside the function, at least in this case,
and this is not visible to the caller (here made indirectly visible). The
manual is confusing for me. And what is the difference between my example
and the double! function from the manuals style guide, which does actually
modify the function argument?
Re: [julia-users] Matlab bench in Julia
Wow, I have now LU a little bit faster on the latest julia Fedora package than on my locally compiled julia: julia versioninfo() Julia Version 0.3.0 Platform Info: System: Linux (x86_64-redhat-linux) CPU: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz WORD_SIZE: 64 BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell) LAPACK: libopenblasp.so.0 LIBM: libopenlibm LLVM: libLLVM-3.3 julia include(code/julia/bench.jl) LU decomposition, elapsed time: 0.07222901 seconds, was 0.123 seconds with my julia FFT , elapsed time: 0.248571629 seconds Thanks for making and improving the Fedora package
[julia-users] Matlab bench in Julia
I have installed julia 0.3 from http://copr.fedoraproject.org/coprs/nalimilan/julia/ on my i7 Haswell 2.4 GHz laptop with updated Fedora 20. Then I translated the first two parts of the Matlab bench script to julia: # Transscript of the Matlab bench, # only LU and FFT # Transscript of the Matlab bench, # only LU and FFT print(LU decomposition, ); tic(); A = rand(1600, 1600); lu(A); toc(); print(FFT , ); n = 2^21; tic(); x = rand(1,n); fft(x); fft(x); toc(); The comparison is relatively disastrous for julia: julia include(code/julia/bench.jl) LU decomposition, elapsed time: 0.936670955 seconds FFT , elapsed time: 0.208915093 seconds (best out of 10 tries) Matlab r2014a LU decomposition: 0.0477 seconds FFT: 0.0682 seconds LU is 24 times slower on julia, FFT is 3 times slower. According to system-monitor Matlab bench causes 3 cores to be busy, julia only 1. This could explain the FFT result, but not the LU.
[julia-users] Re: Matlab bench in Julia
Thanks for the tips. I have now compiled julia on my laptop, and the results are: julia versioninfo() Julia Version 0.3.0+6 Commit 7681878* (2014-08-20 20:43 UTC) Platform Info: System: Linux (x86_64-redhat-linux) CPU: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz WORD_SIZE: 64 BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell) LAPACK: libopenblas LIBM: libopenlibm LLVM: libLLVM-3.3 julia include(code/julia/bench.jl) LU decomposition, elapsed time: 0.123349203 seconds FFT , elapsed time: 0.20440579 seconds Matlab r2104a, with [L,U,P] = lu(A); instead of just lu(A); LU decomposition, elapsed time: 0.0586 seconds FFT elapsed time: 0.0809 seconds So a great improvement, but julia seems still 2-3 times slower than matlab, the underlying linear algebra libraries, respectively, and for these two very limited bench marks. Perhaps Matlab found a way to speed their lin.alg. up recently? The Fedora precompiled openblas was installed already at the first test (and presumably used by julia), but, as Andreas has also pointed out, it seems to be significantly slower than an openblas library compiled now with the julia installation.
