If you want to use prepared statements (for safely inserting strings) you will
get a huge speedup if you wrap the insert queries in a transaction.
Open Terminal
Type
rm ~/.julia_history
No,
array size for Array{T, N} where N 1 is immutable.
I think I have read somewhere that this is to make it easier to have automatic
bounds check hoisting in loop, but I don't think we have that yet.
That was lots of questions. I'll answer one.
I know to get the best speed, 0.4 is needed. Still, (for the above) what are
the problems for 0.3? Have most of the fixed speed issues been backported? Is
Compat.jl needed (or have anything to do with speed?) I think slicing and
threads stuff (and
Julia will not track memory allocations in c programs, but there is a keyword
argument
http://docs.julialang.org/en/release-0.3/manual/profile/#options-for-controlling-the-display-of-profile-results
to Profile.print that you might try:
Profile.print(C=true)
Ivar
onsdag 25. mars 2015
Good question!
In 0.4 the printing for @test has been improved quite significantly to
display the values of variables.
julia a,b = 1,2
julia @test a==b
ERROR: test failed: (1 == 2)
in expression: a == b
in error at error.jl:19
in default_handler at test.jl:27
in do_test at test.jl:50
If you store millions of them, you can use only 1/8 of the space, and get
better memory efficiency.
onsdag 25. mars 2015 21.11.05 UTC+1 skrev Boris Kheyfets følgende:
The question says it all. I wonder if on would get any benefits of keeping
small things in small containers: Uint8 instead of
]) # throws error
Best Wishes.
On Sunday, February 1, 2015 at 1:49:50 PM UTC-5, Ivar Nesje wrote:
And more generally, for all types that makes sense to convert between,
you can use the convert function
convert(String, :blah)
(or maybe better, to avoid type instability issues)
convert
If you have a signature
function commonprefix(str_arr::Array{AbstractString,1})
It means that it should only work on Arrays with element type
AbstractString. If you call it with Array{UTF8String,1}, you can't push! a
reference to a ASCIIString onto the array (without conversion), so the
That depends on what you want to understand. Unsigned types is usually used as
a generic collection of bits, and it is much easier to see bit patterns when it
is shown as hex. It is also nice to make them visually distinguished.
Just for further reference when people find this thread through search:
#10506 https://github.com/JuliaLang/julia/issues/10506
(sorry for bumping the thread for everyone who will read this)
fredag 13. mars 2015 00.29.23 UTC+1 skrev Julia User følgende:
hi!
Is there an ready or prefered way
So, what you would want to do is `Array{String,1}()`.
That ought to construct a array of strings with dimension 1 but doesn't.
But in 0.4 you can use Array{String,1}(0) to create a 1d array with 0
elements. Note that you have to provide the size of the array, and 0 is not
default (, but
Python learned that lesson in moving from python 2 to python 3, so Julia
creates lazy ranges by default. With the focus Julia has on performance,
this would probably an obvious choice anyway.
For the ideom you present, we actually don't even create a range (because
of inlining), but generate
There seems to be a limit on 524,288 bytes. (See
https://github.com/JuliaLang/julia/pull/8241)
Naturally we use a little bit more memory for long variable names when parsing,
but I highly doubt that it is measurable.
At runtime the length of variable name does not affect the speed.
The is true, and that is also what I wanted to do. When using @elapsed,
should I then be worried about garbage collection affecting my times?
When making benchmarks you should worry about everything!, and make efforts
to ensure that your synthetic results actually extrapolates to the code
*julia **big(pi)*
*3.141592653589793238462643383279502884197169399375105820974944592307816406286198e+00
with 256 bits of precision*
lørdag 7. mars 2015 18.59.47 UTC+1 skrev Alan Edelman følgende:
With about a week left, I'd love to find out how many digits of π we can
get only from
We're looking forward to merge your pull request on github when you have time.
Even the small fixes needs to be done, and the more people that feels
comfortable with the contribution process, the fewer bugs we'll have.
Anyway's great to get feedback early so that annoying issues like that,
I don't think the backspace character will be interpreted as you want it by
a web browser. It doesn't really make sense in a stored format like HTML.
fredag 6. mars 2015 19.46.28 UTC+1 skrev DP følgende:
I am using juliabox (v0.3.6)
On Saturday, March 7, 2015 at 12:10:16 AM UTC+5:30, Ivar
It works for me in the standard OSX terminal with a recent 0.4 version.
What kind of system (and julia version) are you on? (versioninfo() tells us
everything we need).
fredag 6. mars 2015 19.27.48 UTC+1 skrev DP følgende:
print(123,char(0x08),567)
println()
print(123,char(0x09),567)
Benchmarks like this is kind of useless because you're doing a meaningless
task, that one of the systems optimize away, but the other faithfully does
in the inefficient manner you prescribed.
This is because Octave (and Matlab) uses copy on write (COW) semantics and
has spent huge efforts to
1. Make sure that your code is correct for the inputs you allow. There
is no need to accept BigFloat (nor Float16) if you end up converting to
Float64 for the calculation anyway (the user of your code can do that
himself). If you don't care enough about different precisions to
I'd also like a REPL command which prints out a list of all of the
objects currently in memory space (like 'whos' in Octave)
I'd recommend you try the obscurely named whos() in Julia :)
torsdag 5. mars 2015 14.38.05 UTC+1 skrev David Higgins følgende:
Oh, and an IDE is the other
Casting is called reinterpret in Julia.
don't
think keyword arguments alone explain this. But it looks like there is some
type instability inside repeat because it creates arrays where the number
of dimensions can't be inferred.
Simon
On Monday, March 2, 2015 at 5:35:15 AM UTC-5, Ivar Nesje wrote:
The speed difference
The speed difference is because Julia doesn't specialize for specific types
for keyword arguments, and type unstable code creates really slow loops in
Julia.
Thanks for reporting, I'll work on a fix.
mandag 2. mars 2015 09.09.04 UTC+1 skrev antony schutz følgende:
Hi Steven,
Thanks for
If you find evidence that there is anything wrong with the first N random
numbers in the standard Random Number Generator (RNG) in Julia, we would
consider that a bug, fix it, and release a new point release faster than a
Lenovo CTO is able to arrange a meeting with someone who understands the
Thanks for reporting
The error seems to be coming from /src/gc.c#L482
https://github.com/JuliaLang/julia/blob/32aee08d0b833233cd22b7b1de01ae769395b3b8/src/gc.c#L482,
which was added in #8699 https://github.com/JuliaLang/julia/pull/8699 which
was merged 24 Ja
No, pointer doesn't keep a reference to the original array. See
http://docs.julialang.org/en/latest/stdlib/c/?highlight=pointer#Base.pointer
The second call can be written safely as
ccall((:fun, :lib), Void, (Ptr{Int64},), [1,2])
No, that is not possible with pmap.
I think something like @everywhere srand(seed) would partially work, but you'd
still suffer from non determinism in the scheduler that might run different
portions of the array in different processes depending on the current load on
your computer.
We have seen quite a few instances where Base functions were extended with
methods without restriction to non-Base types, and it caused problems when
Julia was updated.
Is randomly breaking in new versions of Julia your style?
Strange that GitHub excludes merge commits on their site, but not in their
API.
mandag 23. februar 2015 19.57.19 UTC+1 skrev Jiahao Chen følgende:
Fair enough, but that would mean actually parsing the commit history :)
Thanks,
Jiahao Chen
Staff Research Scientist
MIT Computer Science and
Also log will throw a DomainErrror in Julia if you give it a negative
argument. That is another check and might prevent some optimizations.
onsdag 18. februar 2015 21.36.12 UTC+1 skrev Stefan Karpinski følgende:
What system are you on? And what libm are you using?
On Wed, Feb 18, 2015 at
Git stores committer time with timezone, and we ask git for a UNIX timestamp
and compare to the current system unix timestamp on startup, so I'm pretty sure
we do things correctly.
If the system clock is wrong, there is not much we can do.
Nothing seems to have changed with regards to pcre the last 9 months, and I
just tried to download it and it worked.
It might have been some intermittent error with the server, so delete the
file and try again.
onsdag 18. februar 2015 12.04.26 UTC+1 skrev Patrick Sanan følgende:
I'm getting
Definitely possible. The code is at
https://github.com/JuliaLang/julia/blob/master/base/version.jl#L210
Nice, I'm glad my code didn't crash when given unexpected input.
Maybe we should check the system clock against a online time server when you
run make test. We just use the timestamp git adds when committing, so other
than that, there doesn't seem like there is much new can do.
Array{Int}(A)
Should probably also work soon.
I definitely agree that the info message has some confusing aspects. Please
open an issue (or a PR) with Lint.jl so that the info reads something like.
INFO: In 0.4, replace int() with Int(), or some of the other explicit rounding
functions. (round, trunc, etc...)
Thanks for bringing up this important issue. There was some previous discussion
in https://github.com/dcjones/Gadfly.jl/issues/21 that might interest you.
Please don't tell him to use +1 and -1 to manipulate UTF8String indexes. Use
nextind and prevind.
Pair is defined as
immutable Pair{A,B}
first::A
second::B
end
, so it is type specialized with two parameters A and B.
Pair has its own syntax key = value and is used extensively with dicts.
Ivar
onsdag 4. februar 2015 19.58.42 UTC+1 skrev Seth følgende:
I stumbled across Pair by
I would imagine that symbol(try) and @eval does make this possible, but as
the syntax for using the type will also use the same thrick, you will get
pretty incomprehensible code.
And more generally, for all types that makes sense to convert between, you
can use the convert function
convert(String, :blah)
(or maybe better, to avoid type instability issues)
convert(ASCIIString, :blah)
convert(UTF8String, :blah)
In 0.4 the default constructor for all types will fallback
This issue will fix itself when `a[r]` returns a subarray with 0.4 (this
hasn't landed in master yet, and reminds me that the pending change will
require a huge documentation effort that change affect APIs).
The improved garbage collection that was merged in master recently will
likely greatly
As you probably realized vcat makes a copy of the vector, so it is
inefficient when you use it repeatedly. Julia provides the push! and append!
functions
so that you can efficiently add elements to the end of a vector. There is
also a sizehint! function if you know how many elements there will
Yes, if you are on windows, the nightly installer is the easiest way. Be sure
to keep the old downloads, and remember what versions you use so that you can
revert if a new change causes trouble with your setup. (How careful you must
be, depends on how acceptable it is for you to have a broken
any() is short-circuiting if the length of array is more than 16. That
seems like dubious semantics to me.
Ivar
fredag 30. januar 2015 09.39.28 UTC+1 skrev Mike Innes følgende:
Ok, I now see that `all` isn't short-circuiting, which is kind of
surprising/annoying. Anyone know why that is?
This behaviour is intended and as I understand it a relic from Matlab
(where you can't have arrays of arrays). It is the basis for a convenient
array construction from a range (eg, [1:5] gives [1,2,3,4,5] instead of an
array with a Range object), so there are more to it than you might think.
You need to use
()([true,true], [true,false],[false,true])
I think this is because is used as a special character in ccall. I have
seen this raised a few times, but I don't know what to search for to find
the previous discussions.
Regards Ivar
mandag 26. januar 2015 15.33.06 UTC+1 skrev
Did you time your function twice? The first time you call a function it needs
to be compiled, and for very small tests, that process will dominate.
Currently we bundle loads of binary dependencies in order to include batteries
for common cases. There will always be some tension about what to include, so
creating different distributions seems to be the way to please everyone.
See also https://github.com/JuliaLang/julia/issues/5155
There is
http://docs.julialang.org/en/latest/stdlib/file/?highlight=file#Base.@__FILE__,
but the others are not yet implemented.
No, using eval inside a macro is (almost) never what you want.
A macro is a function that transform one expression to another expression. You
should return an expression that print the string version of the input, not
print directly in the macro.
See also
@test(1, 2, 3, 4)
Originally posted at https://github.com/JuliaLang/julia/issues/9863
The problem here is a parsing ambiguity, because tuples support indexing. I
believe there is an issue on github for this, but I can't figure out what to
search for.
It might be more obvious that (Float64, Int)[2] is ambiguous.
but this is uggly
And it will change in 0.4 (I think)
Pretty much anything. Compiler bugs are certainly possible, but also bugs in
the standard library. Generally pure Julia code shouldn't segfault, unless
you're using ccall or the unsafe_ family.
If you can post a link to a reasonably short segfaulting example here, there is
a good chance that
And why isn't this most frequently asked question covered in our FAQ?
http://docs.julialang.org/en/latest/manual/faq/
I think there might have been a package that defined something like this once.
Do you get this error from a package?
Currently *OverflowError* doesn't have a message field, so to do this, you
have to either let showerror
https://github.com/JuliaLang/julia/blob/69a68305743a6b9a9409e7db69d955909e7006d0/base/replutil.jl#L114
check the backtrace to look for *factoria*l or add a text field, so that
factorial can
I can see two solutions. Either you define an outer constructor for
MyOtherType,
MyOtherType(i::Int) = MyOtherType(MyType(i))
or you can consider MyType equivalent to an Int, so that you define convert
convert(::Type{MyType}, i::Int) = MyType(i)
Ivar
tirsdag 13. januar 2015 07.24.25 UTC+1
Octave uses Float64 numbers by default, so factorial(20) in octave is
equivalent to factorial(20.0) in Julia.
New method definitions will replace the previous definition.
If you put the function in a module and bring them into you scope with
using/importall, you'll run into
https://github.com/JuliaLang/julia/issues/4345, which can be considered either
a bug or a missing feature.
Also, it's faster as multiple dispatch allows to call the function directly,
instead of determining which code to execute via if/else.
It is only faster to use a type (and dispatch), if the type can be inferred at
compile time.
Note that there might be a security issue, because whoever inputs data to your
program also get the ability to run arbitrary code on the computer. In a local
setting where everyone who input data, also have access to changing the code,
this isn't an issue, but be careful if you plan to take
Yes, but he is looking at the 0.4 documentation, so naturally he won't find it
there. Try the 0.3 documentation.
Compat.jl doesn't have doc, but there is a package that is reported to do this
for 0.3. I think it was Doctile.jl, but I might remember wrong.
See
https://github.com/JuliaLang/julia/commit/be0f0dafa798c26279f4ece2f70afa9fc078772c
Unfortunately yes, this is (currently) expected.
The problem is that B is a global variable and currently we can't analyze the
code in the comprehension to ensure that it doesn't change the type of B.
Various suggestions has come up about how to fix this, but currently your
options is to make
Forgot to say Base.== returns bool, so this now makes == type unstable.
Type stable (in the context of Julia) means that the return type can be
statically inferred from the argument types. This means that + is type
stable, even though it returns a Float64 if the arguments are Float64 and
May I ask why $ is needed before symbol()?
The same reason why you need $ in front of x. The function expression needs
a symbol as its name, and you want to dynamically generate that symbol at
macro evaluation time, in order to have access to the x variable.
I can't see any argument for why it would be wrong to add the requested
method. Please open an issue (or better yet a Pull request) on github, so
that we can have more opinions on the matter.
The implementation could be as simple as
*convert{T:AbstractString}(::Type{T}, c::Char) = convert(T,
The problem is where we should stop adding methods to allow symbols to work as
strings.
* might be fine though, so please submit your code as a pull request, so we can
get more opinions on the matter. (Be sure to link to this discussion and to
post a link to the PR here)
I wander why 0.2 (meaning not 0.3.4)?
Probably because this is a really old thread.
The implementation will naturally also use string intermediaries, so you won't
get much better performance.
I like $(symbol(gen_$x)) better than $(:gen_ * x), and others might agree.
There is also an issue about implementing too much of the string API for
symbols, because they have different performance characteristics.
Yes, this is the current situation. Don't call functions in this way in a hot
inner loop where you care about performance (yet). There are lots of things
that can be done to improve this situation, but it hasn't reached the top of
anyone's todo list yet.
The best current workaround is to use a
Have you seen https://github.com/JuliaLang/julia/pull/8987?
Not directly related to your question, but dump takes a optional parameter to
change the output limitation.
Eg:
dump(ex, 100)
prints a deeper version of the AST than
dump(ex)
*Collections.heapify!(x)*
kl. 11:22:24 UTC+1 lørdag 3. januar 2015 skrev Rodolfo Santana følgende:
Let's say I have an array x=rand(10) . How do I use the heapify! function
to heapify x?
Thanks!
-Rodolfo
The issue tracker is off for Github forks. If the package has moved and is
maintained at @jiahao's fork, he should break the fork relation.
kl. 19:11:19 UTC+1 lørdag 3. januar 2015 skrev Jiahao Chen følgende:
Thanks for the report and the fix.
I've updated the code and strengthened the test;
See https://github.com/JuliaLang/julia/issues/4869
kl. 19:19:26 UTC+1 lørdag 3. januar 2015 skrev René Donner følgende:
Hi,
I wanted to append the tuple (3,4) to the tuple (1,2), expecting (1,2,3,4)
as output:
julia a = (1,2,(3,4)...)
(1,2,(3,4)...)
It turns out I have to use
Usually, they get merged within days, and often backported to the 0.3 version
of the manual as well.
It's an oversight if documentation improvements doesn't get backported (if it
is not documenting new features in 0.4-dev). Please bump the relevant pull
requests so that we can fix that.
Yes, Git allows for many different models for development. As Julia is a
pretty small project (compared to the linux kernel), we have a much simpler
structure. Julia is also in a early phase so we are exploring different
options, and we need a branch to distribute and try out new ideas. We
If you also want to look at the implementation of a function, the @less and
@edit macros is very time saving alternatives to @which.
kl. 15:34:56 UTC+1 tirsdag 30. desember 2014 skrev Steven G. Johnson
følgende:
Note that the PriorityQueue type in Base may do what you want.
This is great!
transifex looks good, and I wish you the best of luck. I'm no use in
Spanish or German, but if I see a great (updated) manual in a few languages
in 6 month time, I might look into translating to Norwegian.
I just want to give a word of warning that the Julia documentation isn't
No, the release-0.3 branch (that we tag 0.3.x releases from) only receives
bug fixes that (hopefully) doesn't break backward compatibility. Everything
is captured in the Numerous bugfixes bullet.
You can look at the list of commits
I think this have to be fixed in Compat, so that's probably the right place
to open an issue (or preferably a PR).
You also don't need @compat, because (currently) Compat just generically
defines
the new functions
If it can't be fixed in Compat, we might consider it a bug in Julia 0.3 and
fix it in a new 0.3.5 point release.
Ivar
kl. 23:03:51 UTC+1 fredag 26. desember 2014 skrev Ivar Nesje følgende:
I think this have to be fixed in Compat, so that's probably the right
place to open an issue
:
On Mon, Dec 22, 2014 at 8:34 PM, Ivar Nesje iva...@gmail.com
javascript: wrote:
3 days old version: This looks really weird, and I can't really see how
this
can happen. The first I would check is that you are actually running
the
julia you just built, rather than a a 3 days old
This is two separate issues, so I'll try to answer them separately.
3 days old version: This looks really weird, and I can't really see how
this can happen. The first I would check is that you are actually running
the julia you just built, rather than a a 3 days old julia from another
kl. 13:01:36 UTC+1 fredag 19. desember 2014 skrev Bas Dirks følgende:
Where do I send my technical (front-end) suggestions?
For simple changes a Pull Request at
https://github.com/JuliaLang/julialang.github.com would be great. For more
drastic changes it's probably a good idea to open an
Please don't double post your questions without linking between them. It's
really annoying to answer a question, just to find out that it was answered 1
hour ago another place.
https://github.com/lindahua/NumericExtensions.jl/issues/49
Yes, everything is fine now. I noticed only 5 people were following
NumericExtensions.jl, so it's probably better to ask here.
The error seems really strange. Do you load some code from a file, or do you
paste everything directly in the REPL? Have you defined the type multiple times
in the
Will be exciting to see how fast Julia 0.3 dies down when we start
recommending 0.4 by default.
kl. 15:27:45 UTC+1 torsdag 18. desember 2014 skrev Stefan Karpinski
følgende:
Compatibility is tough and we've really just barely started to deal with
it, but I think so far it's going pretty
Can you post the exact code you use? There are many ways to print numbers in
Julia, and they give different representations.
Great!
When you feel confident about the new package, you should register this
with METADATA.jl https://github.com/JuliaLang/METADATA.jl so that others
will be able to start using it with Pkg.add(IPNets).
kl. 18:02:05 UTC+1 tirsdag 16. desember 2014 skrev Seth følgende:
Hi all,
I'm pleased
Hi,
Hello.
Looks like exciting doc changes are afoot with Julia! I'd like to get some
more understanding of what's coming. Had a look at some of the github issues
tagged doc, but I'm still missing some basics (note, I'm still quite new to
Julia). Questions:
* Is code from Docile.jl,
1 - 100 of 545 matches
Mail list logo
