Yes; Base is *implicitly* imported, meaning that you can *use* any function
in Base without having to *explicitly* import it. However, in order to
*extend* the function with new methods, you do need to import it
*explicitly* (using a statement like import Base.start, Base.next, Base.done
or
Hello,
I am trying to teach gedit to understand the Julia syntax.
I am using Ubuntu 12.04, 64 bits.
I tried the code from:
https://github.com/cko/juliaLang-gnome
I copied julia.xml to /usr/share/mime and julia.lang
to /usr/share/gtksourceview-3.0/language-specs/
For updating the mime types I
Le mardi 29 juillet 2014 à 02:46 -0700, Uwe Fechner a écrit :
Hello,
I am trying to teach gedit to understand the Julia syntax.
I am using Ubuntu 12.04, 64 bits.
I tried the code from:
https://github.com/cko/juliaLang-gnome
I copied julia.xml to /usr/share/mime and julia.lang
to
Thanks, this works already nicely!
Best regards:
Uwe
On Tuesday, July 29, 2014 12:04:06 PM UTC+2, Milan Bouchet-Valat wrote:
Le mardi 29 juillet 2014 à 02:46 -0700, Uwe Fechner a écrit :
Hello,
I am trying to teach gedit to understand the Julia syntax.
I am using Ubuntu 12.04, 64
A recent post on reddit
http://badhessian.org/2014/07/six-of-one-plot-half-dozen-of-the-other/ brought
my attention to the python seaborn package:
http://web.stanford.edu/~mwaskom/software/seaborn/
Seaborn is a really cool Python visualization library based on matplotlib
and pandas, and
Hi everyone, I started using Julia since last Saturday for my PhD work. My
background in programming is mostly C++, C, and some
non-performance-oriented MATLAB. I have never used R. Despite my lack of
modern programming languages, I was able to convert some of my previous
prototype code from
[] is used to indicate that some parameters is optional, but it is not used
consistently throughout julia documentation.
See https://github.com/JuliaLang/julia/issues/4902 for some discussion.
kl. 09:42:43 UTC+2 tirsdag 29. juli 2014 skrev Roy Wang følgende:
Hi everyone, I started using Julia
1 out of 20 time my process is crashing with the following traceback, there
doesn't seem to be anything useful in it. I did find this issue (
https://github.com/JuliaLang/julia/issues/6611) which seems similar, and is
fixed as part of Julia 0.3- (we're using 0.2.1). I'm wondering if anyone
Whats the easiest way of going from an array
[1,2,3] - [1,1,2,2,3,3]
i.e. repeating all elements 2 (or more generally, n) times?
A
repeat([1, 2, 3], inner = [2])
On Jul 29, 2014, at 7:03 AM, Andrei Berceanu andreiberce...@gmail.com wrote:
Whats the easiest way of going from an array
[1,2,3] - [1,1,2,2,3,3]
i.e. repeating all elements 2 (or more generally, n) times?
A
nice, ty!
btw, the manual at
http://julia.readthedocs.org/en/latest/stdlib/linalg/#Base.repeat says
repeat(*A*, *inner = Int*, []*outer = Int*[])
shouldn't that be
repeat(*A*, *inner = Int*[], *outer = Int*[])
i.e isn't the comma in the wrong position?
On Tuesday, July 29, 2014 4:06:22
Yeah, that’s a typo. Could you fix it?
— John
On Jul 29, 2014, at 7:23 AM, Andrei Berceanu andreiberce...@gmail.com wrote:
nice, ty!
btw, the manual at
http://julia.readthedocs.org/en/latest/stdlib/linalg/#Base.repeat says
repeat(A, inner = Int, []outer = Int[])
shouldn't that be
On Sunday, July 27, 2014 8:38:37 AM UTC-4, Oliver Pewter wrote:
I have thought about YAML, JSON, serialised Julia objects in a file or
straight up Julia code.
I would tend to suggest just entering Julia code.I've been down this
path myself with custom input-file formats for simulation
That's because Sphinx identifies [] as optional arguments in the ..function
macro-thingy, and it does funny re-arrangements with it. The source is
correct; it's the output that is wrong. It's annoying, but I've not dug
into Sphinx enough to determine how we might disable it.
On Tuesday, July
Dear all,
By reading the docs, Int is an alias for either Int32 or Int64 depending on
the WORD_SIZE of the machine where Julia is running.
Why we do not have a similar Float construct for floating points? Can we
say Real is either Float32 or Float64 likewise? Is there any theoretical
See answers to the same question here:
https://groups.google.com/forum/#!searchin/julia-users/Float$20Float32$20Float$2064/julia-users/1tDvMbfCUEE/BJCu0-S7OawJ
On Tue, Jul 29, 2014 at 11:19 AM, Júlio Hoffimann julio.hoffim...@gmail.com
wrote:
Dear all,
By reading the docs, Int is an alias
Integer size is system-dependent while floating-point size is not. The 8087
https://en.wikipedia.org/wiki/Intel_8087 already had 64-bit floats and
every x86 since the i486 https://en.wikipedia.org/wiki/Intel_80486 has
too, so there's no reason to change the size of floating-point numbers on
I have defined a subclass of AbstractArray for which I do *not* want to use
the default AbstractArray printing machinery in show.jl . My assumption,
apparently incorrect, is that I simply needed to overload show.
Unfortunately, my overloaded version is never used.
Here is some sample code.
Some of the printing machinery has gotten to be quite a mess – I ran into
this myself recently, specifically for arrays. I think you need to hook
into the display function somehow, but I gave up unravelling the tangle of
method calls and just ended up adding the methods I needed make the default
I'll quote another ongoing thread
Yes; Base is *implicitly* imported, meaning that you can *use* any
function in Base without having to *explicitly* import it. However, in
order to *extend* the function with new methods, you do need to import it
*explicitly* (using a statement like import
Good morning,
I am exploring the idea of embedding Julia in our C++ medical image
reconstruction streaming framework. Each piece of a given reconstruction
workflow is basically a C++ class. Groups of classes live in dynamic
libraries that are loaded at runtime (making them essentially
That may or may not be the issue here – it's unclear to me. Even with
appropriate imports and qualifications, it is not obvious how to change the
way custom array types are shown.
On Tue, Jul 29, 2014 at 12:31 PM, g galenon...@gmail.com wrote:
I'll quote another ongoing thread
Yes; Base
On Tue, Jul 29, 2014 at 12:33 PM, Joseph Naegele joseph.naeg...@gmail.com
wrote:
Is it safe to allow code in multiple threads access the Julia runtime
using the C-API?
It is currently not safe – Julia is not reentrant. This will change when we
add threading support (already in progress), but
I saw the Roadmap for 0.3
here: https://github.com/JuliaLang/julia/issues/4853
But I cannot find the Roadmap for 0.4... Does anyone know where that is
located?
thx
Note that there's a julia.lang in the Julia repo
https://github.com/JuliaLang/julia/blob/master/contrib/julia.lang, an
earlier version of which was submitted to gtksourceview
https://bugzilla.gnome.org/show_bug.cgi?id=700410 and included in it
There is no official roadmap for 0.4 yet – just a collection of ideas in
various people's heads and spread across our mailing group and GitHub
discussions. A few major changes that come to mind off the top of my head:
- array views
- string + I/O revamp
- pkg revamp (again)
- static
Might we see the changes to the type system that are required to get
higher-order functions to specialize on input functions?
-- John
On Jul 29, 2014, at 9:49 AM, Stefan Karpinski ste...@karpinski.org wrote:
There is no official roadmap for 0.4 yet – just a collection of ideas in
various
You can also take a look at specific github issues that have been marked
0.4: https://github.com/JuliaLang/julia/milestones/0.4
It may take another trip to Boston, but I'm also pulling for the Dates
module in 0.4!
-Jacob
On Tue, Jul 29, 2014 at 12:51 PM, John Myles White
Seems like triangular dispatch may be on its way, too, which would be really
cool.
0.4: everything you want, plus the pony
--Tim
On Tuesday, July 29, 2014 12:49:04 PM Stefan Karpinski wrote:
There is no official roadmap for 0.4 yet – just a collection of ideas in
various people's heads and
I would hope/work for an improved help/documentation system, including
user-defined documentation.
On Tue, 2014-07-29 at 17:52, Jacob Quinn quinn.jac...@gmail.com wrote:
You can also take a look at specific github issues that have been marked
0.4:
That explains why the github page showed the right syntax! *head bump
A
On Tuesday, July 29, 2014 5:10:42 PM UTC+2, Matt Bauman wrote:
That's because Sphinx identifies [] as optional arguments in the
..function macro-thingy, and it does funny re-arrangements with it. The
source is
Great thanks for the clarification. I guess I should have ascertained that
it is not reentrant since the C-API obviously modifies some global state.
I will look at the current development for threading support for fun but in
the meantime, will the implementation always modify global state or
On Tue, Jul 29, 2014 at 12:51 PM, John Myles White johnmyleswh...@gmail.com
wrote:
Might we see the changes to the type system that are required to get
higher-order functions to specialize on input functions?
I believe this is one of the things that Jeff wants to do, but obviously
he's the
The array printing code writes #undef when an attempt to access an element
throws an error. Fix your array indexing code and it should work. I've
written two relatively complete and self-contained AbstractArray
derivatives in Gtk.jl if you want examples on the expected API for an
AbstractArray
On Tue, Jul 29, 2014 at 12:55 PM, Mauro mauro...@runbox.com wrote:
I would hope/work for an improved help/documentation system, including
user-defined documentation.
Yes, that's also important and we definitely need to make big progress
there.
+1
On Tuesday, July 29, 2014 01:17:59 PM Stefan Karpinski wrote:
On Tue, Jul 29, 2014 at 12:55 PM, Mauro mauro...@runbox.com wrote:
I would hope/work for an improved help/documentation system, including
user-defined documentation.
Yes, that's also important and we definitely need to make
Interesting question. I obviously didn't evaluate that as part of the blog
post, but it seems like it could be possible. The one hiccup could be that
Seaborn seems to be a wrapper around matplotlib, so that Seaborn code can
be used interchangeably with matplotlib within Python. Not knowing how
My mistake.
On Tuesday, July 29, 2014, Jameson Nash vtjn...@gmail.com wrote:
The array printing code writes #undef when an attempt to access an element
throws an error. Fix your array indexing code and it should work. I've
written two relatively complete and self-contained AbstractArray
Le mardi 29 juillet 2014 à 09:42 -0700, Waldir Pimenta a écrit :
Note that there's a julia.lang in the Julia repo, an earlier version
of which was submitted to gtksourceview and included in it (since
release 3.10 IIRC).
Ah, good to know it got included. I wasn't aware of that.
Apart from the
I've answered my own question here: the key, for now, is to overload
writemime. However, it doesn't seem that should be necessary, so I've
commented on an existing GitHub issue
https://github.com/JuliaLang/julia/issues/6117#issuecomment-50502411
about it.
The #undef issue is *not my problem.
Thanks, but in fact imports/exports are not the problem here. I'm already
importing show. It turns out that the real problem is that *show is not
being used *in the scenario above; rather, writemime is.
On Tuesday, July 29, 2014 11:31:23 AM UTC-5, g wrote:
I'll quote another ongoing
Yes, this is precisely the same issue that I had encountered (and opened an
issue about... and then forgotten that I'd opened an issue about).
On Tue, Jul 29, 2014 at 2:19 PM, Michael Grant m...@cvxr.com wrote:
Thanks, but in fact imports/exports are not the problem here. I'm already
You can check Images.jl, which defines a type Image : AbstractArray but prints
like this:
julia img = testimage(mandrill)
RGB Image with:
data: 3x512x512 Array{Uint8,3}
properties:
colorspace: RGB
colordim: 1
spatialorder: x y
limits: (0x00,0xff)
On Tuesday, July 29, 2014
Yes indeed, your solution is exactly what I need to do: overload writemime
...
On Tuesday, July 29, 2014 1:33:00 PM UTC-5, Tim Holy wrote:
You can check Images.jl, which defines a type Image : AbstractArray but
prints
like this:
julia img = testimage(mandrill)
RGB Image with:
MLBase.jl has som data repetition functionality:
http://mlbasejl.readthedocs.org/en/latest/datapre.html#data-repetition
I'd also like to be able to require a URL. At the very least it will make
for easier testing. But I think it will also simplify maintaining and using
non-public packages.
I can't believe it was that simple. Thank you so much!
On Monday, July 28, 2014 10:16:21 PM UTC-7, Ivar Nesje wrote:
It seems to me like the error is that you don't have a Julia method
results = gillespie (rr, 0)
that takes an Int as the second argument. the method you define only takes
a
I'm trying to write a small module that allows one to define a Step that
describes operations on an HDF5 file.
immutable Step
func::String
a_ins::(String...) #attribute inputs
d_ins::(String...) #dataset inputs
a_outs::(String...) #attribute outputs
d_outs::(String...)
2014-07-29 13:10 GMT-03:00 Stefan Karpinski ste...@karpinski.org:
Integer size is system-dependent while floating-point size is not. The
8087 https://en.wikipedia.org/wiki/Intel_8087 already had 64-bit floats
and every x86 since the i486 https://en.wikipedia.org/wiki/Intel_80486
has too, so
In general, you should avoid using `eval`. Is there a reason you don't want
to pass in a function and make it `func::Function` in your type?
Your `eval` inside module `Bar` is evaluating the code inside the scope of
`Bar`, which is what's causing your problem.
-- Leah
On Tue, Jul 29, 2014 at
Hi all,
I've got an algorithm that hinges critically on fast matrix multiplication.
I put up the function on this gist
https://gist.github.com/floswald/6dea493417912536688d#file-tensor-jl-L45
indicating the line (45) that takes most of the time, as you can see in the
profile output that is
There's pretty cool package Images by Tim Holy (kudos, Tim!), but it
seems to leak one standard and pretty helpful function - resizing image to
specific size. There's restrict method (probably imported from Grid.jl),
but it only reduces image size by 2 at each dimension. Are there any other
On Tuesday, July 29, 2014 02:30:55 PM Andrei Zh wrote:
There's pretty cool package Images by Tim Holy (kudos, Tim!),
...and Ron, Kevin, Lucas, etc ...
but it
seems to leak one standard and pretty helpful function - resizing image to
specific size.
There's restrict method (probably imported
On Tue, Jul 29, 2014 at 5:19 PM, Júlio Hoffimann julio.hoffim...@gmail.com
wrote:
P.S.: Why Julia users do not hang on IRC? Such trivial questions would be
addressed instantly. I guess this mailing list is being misused as an IRC
channel. (~54 emails per day).
Some do. Personally, I find IRC
I had similar problem recently, and in my case solution was to:
1. Make sure that you use OpenBLAS and not other implementation:
julia Base.blas_vendor()
:openblas
2. Use mutable versions of BLAS matrix multiplication (e.g. A_mul_B! or
more general gemm!) and thus not produce
You may have to check which is the bottleneck: getindex or matrix
multiplication.
Dahua
On Tuesday, July 29, 2014 4:22:32 PM UTC-5, Florian Oswald wrote:
Hi all,
I've got an algorithm that hinges critically on fast matrix
multiplication. I put up the function on this gist
The right-hand slice makes a copy so you might want to just do this:
v1[m*(0:(n-1)) + i] = stemp * v1[(n*(i-1)) + (1:n)]
That way only one copy is made, implicitly, by the slice operation.
On Tue, Jul 29, 2014 at 5:56 PM, Dahua Lin linda...@gmail.com wrote:
You may have to check which is
Thanks for the comments. With a bit more digging I was able to figure out
how to pass a module in which to look for the function, this finds the
correct function and avoids eval.
module Bar
bar(s::String, args...;m::Module=Main) = getfield(m,symbol(s))(args...)
export bar
end
using Bar
...and Ron, Kevin, Lucas, etc ...
Surely, I'm just referring to someone I see on the mailing list very often
:)
Yeah, it's a pretty obvious omission, but to be truthful it's never come up
for me so I've never implemented it. I will get to it eventually, but in
the
meantime if you
What would Float be an alias for?
On Jul 29, 2014, at 6:09 PM, Júlio Hoffimann julio.hoffim...@gmail.com wrote:
Some do. Personally, I find IRC to be far too much of a continual
distraction. Email I can answer when I want to. With IRC, there's also no
record of the discussion, which would
I'm following the analogy for Int:
if is(Int,Int64)
typealias Float Float64
else
typealias Float Float32
end
User code would be cleaner:
function foo(a::Float, b::Float)
end
vs.
function bar(a::Float64, b::Float64)
end
Júlio.
This makes sense? Please correct me if I'm saying nonsense.
Júlio.
Float would always be Float64.
On Jul 29, 2014, at 6:25 PM, Júlio Hoffimann julio.hoffim...@gmail.com
wrote:
I'm following the analogy for Int:
if is(Int,Int64)
typealias Float Float64
else
typealias Float Float32
end
User code would be cleaner:
function foo(a::Float,
I think the confusion is that Julio assumes Int is used for brevity, when it is
actually used for cross-platform compability.
-- John
On Jul 29, 2014, at 3:29 PM, Stefan Karpinski stefan.karpin...@gmail.com
wrote:
Float would always be Float64.
On Jul 29, 2014, at 6:25 PM, Júlio
2014-07-29 19:32 GMT-03:00 John Myles White johnmyleswh...@gmail.com:
I think the confusion is that Julio assumes Int is used for brevity, when
it is actually used for cross-platform compability.
-- John
Yes, I assumed the Int alias had these two goals: brevity + portability. I
still think
One of the things I like about the Julia community is a broad preference for
clarity over brevity. Think of it as the opposite of the Perl culture.
In this case, Float would be less, rather than more, clear because our Float
would describe a type that most languages would call Double.
-- John
From the profile output it looks like a lot of time is spent in getindex. I
suppose that is bad news? Not sure how I could avoid any of the index
lookups.
On Tuesday, 29 July 2014, Dahua Lin linda...@gmail.com
javascript:_e(%7B%7D,'cvml','linda...@gmail.com'); wrote:
You may have to check
2014-07-29 19:50 GMT-03:00 John Myles White johnmyleswh...@gmail.com:
In this case, Float would be less, rather than more, clear because our
Float would describe a type that most languages would call Double.
In my humble opinion we can call it Float without confusion and forget
about other
Yes, Float is a bad name for Float64 since anyone coming from C or Fortran
would expect Float = Float32 and Double = Float64.
If you're writing Float64 a lot I think you may be over constraining your type
signatures. Most algorithms that make sense for Float64 also make sense for
Float32 and
Hi Julia users,
There are a number of things wrong with this script that I am working on,
but for the time being, I am trying to resolve a BoundsError() triggered
while slicing an array. Code is attached.
The source of the BoundsError() appears to be this function.
function
Ignoring other languages people are likely to be used to is not really the
Julian way. People come from various language backgrounds and we'd like to make
using Julia as comfortable for as many people as possible, if the cost is not
too great. It's quite likely that many people will be working
If only Float exists in Julia, then there is no door for confusion with
Double. A user coming from a C background will soon notice that Float is
the type he is looking for. Furthermore, a simple short note on the manual
is enough to make it even clearer.
Júlio.
Thank you Stefan Karpinski.
2014-07-26 21:37 GMT-03:00 Stefan Karpinski stefan.karpin...@gmail.com:
It's technically quite difficult. Related to issue #265.
On Jul 26, 2014, at 7:55 PM, Pedro Rafael pedro.rafael.mari...@gmail.com
wrote:
What I mean by the second question is:
For what
I think you're assuming people's beliefs about programming languages are
simpler to modify than they've proven to be in our experience.
Here's an experiment you could try to see if I'm right: over the course of six
months, reply to every e-mail you see on julia-users that derives from a
Except that we already have Int != int, which becomes unfortunate when
first trying to write code for c-interop. (I don't see adding a Float alias
as particularly helpful -- and we do have Cfloat, if someone feels the need
to be pedantic/consistent in their ccall and type structs.)
On Tuesday,
You may call gemv directly.
Dahua
On Tuesday, July 29, 2014 5:56:28 PM UTC-5, Florian Oswald wrote:
From the profile output it looks like a lot of time is spent in getindex.
I suppose that is bad news? Not sure how I could avoid any of the index
lookups.
On Tuesday, 29 July 2014, Dahua
Look more carefully into the pattern of your codes.
It seems that you may be able to reshape v1 into a matrix of size (m, n)
and v0 into a matrix of size (n, m), and you may do a matrix-matrix
multiplication once without looping over multiple strided vectors.
Also, if you are using ArrayViews,
While 3D graphics packages are still in early development for Julia, I
believe that community uses 32 bit floats almost exclusively, probably
because of bandwidth constraints to the GPU (but someone with more
knowledge should correct me).
Cheers, Kevin
On Tuesday, July 29, 2014, Júlio Hoffimann
Thanks, Ivar! I will review this thread. I wish the documentation alert
readers that [, a,b,...] mean optional parameters.
There were also architectural problems related to SIMD width (I think) on
most GPU designs until fairly recently, causing operations on 64-bit
doubles to be significantly more than 2x slower than 32-bit singles. This
is not so much the case any more, but old habits die hard and if single
80 matches
Mail list logo
