Re: [julia-users] Julia Utopia: Share your tips and tricks to efficient coding in Julia

[Tamas Papp]

I use Julia with Emacs+ESS+julia-mode. I find it very efficient,
especially as I use Emacs for everything else too (LaTex, other
programming languages, e-mail, git interface).

I debug using print statements. I find @show very valuable, also see
https://github.com/timholy/DebuggingUtilities.jl . I am looking forward
to using Gallium.jl though, but at the moment I am in the middle of a
project with a deadline so I stick to the current stable version and
don't play around with 0.5.

I find @edit really useful, for looking up code for matching
methods. Also methodswith.

I find Plots.jl and Gadfly.jl very convenient for quick plots (and of
course also for production-quality plots). I have been using the latter,
and experimenting with the former now.

Favorite packages outside the core include Parameters.jl. JuliaStats
packages are really well-designed and high quality too. But of course
which packages you find useful would depend on your application domain.

Coming from Common Lisp and R, I had to wrap my head a different
workflow. In interactive languages I used previously, I kept
manipulating the image interactively, refining functions, building up
the good old "big ball of mud", then I would clean up, all without ever
restarting the process (especially in CL).

Workflow in Julia is quite different, especially because of the infamous
issue #265. I put things in modules very early, and keep reloading. I
have been experimenting with an interactive workflow using
eval(module,...) via ESS, but until #265 is fixed I put that on the
backburner.

So because I call workspace() so often, at the moment I break up things
into modules and small "scripts" which load them, load some data and
generate other data or plots, each a single well-defined step (eg
datacleaning, MCMC, simulations). I found JLD invaluable for this. To a
certain extent, this reminds me of a C/Fortan workflow, but in a nice
way :D It is certainly more disciplined then doing everything
interactively and then (occasionally) not being able to reproduce the
results.

Having used Julia for a while I am much more relaxed about optimizing code
now. I try not to do silly things (like row-major access for a
column-major structure), but in general I postpone profiling and
optimizing to much later, and sometimes don't do it at all. I find this
efficient because I spend much more time writing and rewriting code than
running it, and Julia is very efficient out of the box, so extracting
another factor of 2-5 with a lot of work is not a major concern unless I
use the code often.

On Thu, May 12 2016, David Parks wrote:

> I'm a few weeks into Julia and excited and motivated to learn and be as 
> efficient as possible. I'm sure I'm not alone. I know my way around now, 
> but am I as efficient as I can be? 
>
> What haven't I tried? What haven't I seen? What haven't I asked?
>
> For those of you who have been around longer, could you share your advice 
> on efficient day-to-day development style?
>
> For example:
>
>- What IDE do you use? Are you using Atom? A combination of Atom and the 
>REPL? Something else?
>- How do you debug complex code efficiently? How do you debug other 
>peoples code efficiently?
>- Do you have a favorite way of visualizing your work?
>- Are there must have tools? packages? utilities?
>- Any simple day-to-day efficiency/advice you could share with others 
>who didn't yet know to ask.

Re: [julia-users] Julia Utopia: Share your tips and tricks to efficient coding in Julia

[Jacob Quinn]

I'll take a stab here. For context, I've been coding in Julia since 2012,
contributed to Base and some data processing packages.

* I currently use Atom; it's come a long way since it started, both the IDE
itself and Julia support. It seems to have way more momentum in both
respects as well (vs. say, sublime). I don't use the inline evaluation very
much; not sure why, but I just haven't ever been a huge fan of that
workflow. I typically just copy paste into the terminal (iTerm2 on mac),
and enjoy using the *very* rich REPL features Julia provides (tab
completion, history search, symbols, etc.).

* For debugging code, I typically rely on good ole `println` or `@show`,
plus building things up incrementally (validating things as you build up).
I recently gave Gallium.jl a spin; for context, I've never coded in a
language with a "real debugger", so I'm not sure I'm the ideal candidate
here, but I found it somewhat difficult to navigate the right granularity
of stepping through code (should I go to the next line? next call? step
into it?). I'm 100% positive this is due to me needing to spend more time
with it and better learn "debugging" practices; note it's currently being
developed on master, so 0.5/nightlies.

* I don't do a lot of visualizing of my work, so no great advice/opinions
here.
.
* For day-to-day, here's a smattering of things I find myself reaching for
all the time:

  * modules: I rarely get very far developing new code without throwing it
in a module; this allows to develop much easier interactively and
iteratively because you can just `reload("MyModule")` and you're ensured
all the types/methods get redefined.
  * @which: One of the handiest macros in Base to help you navigate Julia's
powerful dispatch system; use to ensure that the right methods are being
called. It also comes in very handy for just taking a quick peek at
somebody else's function and where it was defined if I want to take a
closer look.
  * @time and @profile: also very handy macros when you get into
performance tuning. Check out the Profiling section in the manual to learn
some of the ins and outs, but it becomes extremely helpful to get a feel
for where time is being spent in your code
  * @code_lowered, @code_typed, @code_llvm, @code_warntype: (there's also
@code_native if you're into the real nitty gritty). These are your best
friends! For greater context, search YouTube for Jeff Bezanson's JuliaCon
talk where he talks through the various levels of "compilation" in Julia;
it goes a long way to understanding exactly what's going with your
code. @code_warntype is particularly helpful for spotting type
instabilities which can kill performance. It's also helpful to get a feel
for the actual machinery of your code


Anyway, hopefully that sparks a few ideas.

-Jacob

On Thu, May 12, 2016 at 11:01 AM, David Parks 
wrote:

> I'm a few weeks into Julia and excited and motivated to learn and be as
> efficient as possible. I'm sure I'm not alone. I know my way around now,
> but am I as efficient as I can be?
>
> What haven't I tried? What haven't I seen? What haven't I asked?
>
> For those of you who have been around longer, could you share your advice
> on efficient day-to-day development style?
>
> For example:
>
>- What IDE do you use? Are you using Atom? A combination of Atom and
>the REPL? Something else?
>- How do you debug complex code efficiently? How do you debug other
>peoples code efficiently?
>- Do you have a favorite way of visualizing your work?
>- Are there must have tools? packages? utilities?
>- Any simple day-to-day efficiency/advice you could share with others
>who didn't yet know to ask.
>
>
>

[julia-users] Re: Julia Utopia: Share your tips and tricks to efficient coding in Julia

[Eric Forgy]

I'm also interested in this question. Having been lurking around for more 
than a year, I've seen this kind of question come up a few times and don't 
remember the answers, but remember seeing answers and they were helpful. I 
think it would be cool/helpful if Julia Computing had an "About Us 
" page with bios and answers to similar 
questions to the above for each person.


On Friday, May 13, 2016 at 1:01:04 AM UTC+8, David Parks wrote:
>
> I'm a few weeks into Julia and excited and motivated to learn and be as 
> efficient as possible. I'm sure I'm not alone. I know my way around now, 
> but am I as efficient as I can be? 
>
> What haven't I tried? What haven't I seen? What haven't I asked?
>
> For those of you who have been around longer, could you share your advice 
> on efficient day-to-day development style?
>
> For example:
>
>- What IDE do you use? Are you using Atom? A combination of Atom and 
>the REPL? Something else?
>- How do you debug complex code efficiently? How do you debug other 
>peoples code efficiently?
>- Do you have a favorite way of visualizing your work?
>- Are there must have tools? packages? utilities?
>- Any simple day-to-day efficiency/advice you could share with others 
>who didn't yet know to ask.
>
>
>

[julia-users] Symbolic mathematics language v 0.0.6

[lapeyre . math122a]

The symbolic mathematics language project that I announced last year has 
been greatly expanded.

Here is the link: https://github.com/jlapeyre/SJulia.jl

The best way to find what is new is to look at the tests 
https://github.com/jlapeyre/SJulia.jl/tree/master/sjtest

Re: [julia-users] Re: static compilation

[Jameson Nash]

We have been working on a number of simplifications on master, so some of
the best practices and extra steps aren't necessary anymore. But it should
still work on v0.4.

There are a few different goals that can be accomplished by invoking the
Julia compiler directly, so it was a bit difficult to write that blog post
talking about them all generically. Since it touches on several of the
optimization options, I structured it in part to show how these layers can
build on each other. But I decided to leave out demonstrations of how
mixing various layers and options can be used to create other products.

Since most of these steps are already configured in the Julia build system,
one of the easiest ways to augment it is to simply drop a userimg.jl file
into base/
This will then get incorporated into the usual build and become part of the
pre-defined system image.

The `-e nothing` stage is there because you have to give it something to
evaluate (a file, stdin, or `-e`, etc.), or it will pop open the REPL and
wait for the user to enter commands. This is actually also a valid way to
create an executable and can be fun to play with as a development exercise
(I still do this on occasion to test out how it is handling odd cases).

To get a ccallable declaration to show up in the binary, the only condition
is that you must declare it ccallable in the same execution step as the
final output.

-jameson


On Thu, May 12, 2016 at 10:23 AM Ján Adamčák  wrote:

> Thanks @Jameson,
>
> I am a bit confused about "you are not adding any code to the system image
> (`--eval nothing`)". According to your blog
> http://juliacomputing.com/blog/2016/02/09/static-julia.html , I think
> that this is a crucial point to obtain a small sized dll. Am I right?
>
> What is then the right way to emit "ccallable" declarations in order to
> export julia function(s)? (foo in our example from the original post in
> this thread)
>
> Is it okay to work with current version of julia 0.4.5. or I have to
> switch to another version; If yes, to which one?
>
> Thanks in advance.
>
> Dňa utorok, 10. mája 2016 22:13:57 UTC+2 Jameson napísal(-a):
>
>> The compile-all flag is only partially functional on v0.4. I think it's
>> best to just leave it off. I tested on master and fixed a bug with emitting
>> `@ccallable`, but that's unrelated. From the command line below, it looks
>> like you are not adding any code to the system image (`--eval nothing`)
>> which would also means there are no `ccallable` declarations being emitted
>> into the current compile.
>>
>> Other than that, I don't see anything wrong with that command. You
>> shouldn't see that error unless you tried to make a Task or use `@async`
>> from the compile host. It's ambiguous how that would be serialized, so it's
>> simply an error and any parallel workers should be created / started by an
>> `__init__` method.
>>
>>
>> On Tuesday, May 10, 2016 at 2:53:22 AM UTC-4, Ján Adamčák wrote:
>>>
>>> Hello guys,
>>>
>>> Thank you for your comments, though we were more optimistic...
>>>
>>>
>>> Dňa piatok, 6. mája 2016 16:27:28 UTC+2 Ján Adamčák napísal(-a):

 Sorry, my fault.

 During last week I created build_sysimg2.jl from julia 0.4.5
 build_sysimg.jl and when I run it, at line 86 (build_sysimg2.jl)

 run(`$julia -C $cpu_target --output-o sysimg_all.o --sysimage
 $sysimg_path.$(Libdl.dlext) --startup-file=no --compile=all --eval 
 nothing`)

 I got this error:

 fatal: error thrown and no exception handler available.
 ErrorException("Task cannot be serialized")
 jl_unprotect_stack at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_throw at C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll
 (unknown line)
 jl_error at C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll
 (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 jl_compress_ast at
 C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
 j

Re: [julia-users] Segmentation Faults after Julia version upgrade to 0.4.5

[Tim Holy]

You can file it as an issue at https://github.com/JuliaLang/julia/issues

Thanks!
--Tim

On Thursday, May 12, 2016 08:59:42 PM Yichao Yu wrote:
> On Thu, May 12, 2016 at 3:17 PM, Matt Anderson  wrote:
> > Hello,
> > 
> > Apologies as I am new to this kind of forum.
> > 
> > I am working on a bit of software and have encountered a segmentation
> > fault
> > after upgrading my Julia version to 0.4.5 from version 0.4.4. This issue
> > persists across multiple machines and operating systems. Under version
> > 0.4.4 the code runs without a problem.
> > 
> > The error pops up as
> > 
> > signal (11): Segmentation fault: 11
> > 
> > - at arraymath.jl:96
> > 
> > 
> > followed by a bunch of traceback.
> > 
> > 
> > So here is my real question. What is the proper way for me to document
> > this
> > so as to annoy as few people as possible?
> 
> Include as much detail as possible (especially the code to reproduce,
> you system info, julia version (where you get it from) and the error
> messages) so that people who can solve the problem can actually have
> any info at all to start debugging the problem.
> 
> > Thanks

Re: [julia-users] Segmentation Faults after Julia version upgrade to 0.4.5

[Yichao Yu]

On Thu, May 12, 2016 at 3:17 PM, Matt Anderson  wrote:
> Hello,
>
> Apologies as I am new to this kind of forum.
>
> I am working on a bit of software and have encountered a segmentation fault
> after upgrading my Julia version to 0.4.5 from version 0.4.4. This issue
> persists across multiple machines and operating systems. Under version 0.4.4
> the code runs without a problem.
>
> The error pops up as
>
> signal (11): Segmentation fault: 11
>
> - at arraymath.jl:96
>
>
> followed by a bunch of traceback.
>
>
> So here is my real question. What is the proper way for me to document this
> so as to annoy as few people as possible?

Include as much detail as possible (especially the code to reproduce,
you system info, julia version (where you get it from) and the error
messages) so that people who can solve the problem can actually have
any info at all to start debugging the problem.

>
>
> Thanks

[julia-users] Segmentation Faults after Julia version upgrade to 0.4.5

[Matt Anderson]

Hello,

Apologies as I am new to this kind of forum.

I am working on a bit of software and have encountered a segmentation fault 
after upgrading my Julia version to 0.4.5 from version 0.4.4. This issue 
persists across multiple machines and operating systems. Under version 
0.4.4 the code runs without a problem. 

The error pops up as 

signal (11): Segmentation fault: 11

- at arraymath.jl:96


followed by a bunch of traceback.


So here is my real question. What is the proper way for me to document this 
so as to annoy as few people as possible?


Thanks

[julia-users] Re: Declaration of types in function construction...

[Charles Ll]

Ok yes, thanks for your answer. it helped me tackling this problem.

Actually, the problem was residing in the bad writing of the optional 
arguments. I was passing "standard" float numbers to variables defined as 
Arrays{Float64,N}...

The proper definition of this function is:

function gaussianarea(Amplitude::Array{Float64},HWHM::Array{Float64}; 
eseAmplitude::Array{Float64} = [0.0], eseHWHM::Array{Float64} = [0.0])

Thanks again, I've been scratching my head on this problem!

Le jeudi 12 mai 2016 21:24:47 UTC+10, Gunnar Farnebäck a écrit :
>
> Your problem is probably that you try to call your function with four 
> positional arguments, although the last two should have been named. Compare
>
> julia> f(x, y; z=0) = x + y + z
> f (generic function with 1 method)
>
> julia> f(2, 3)
> 5
>
> julia> f(2, 3, 4)
> ERROR: MethodError: `f` has no method matching f(::Int64, ::Int64, ::Int64)
> Closest candidates are:
>   f(::Any, ::Any)
>
> julia> f(2, 3, z = 4)
> 9
>
> Den torsdag 12 maj 2016 kl. 12:51:13 UTC+2 skrev Charles Ll:
>>
>> Dear all,
>>
>> There is something I did not understood well in Julia regarding the type 
>> fo the variables and this creates difficulties with the functions I am 
>> writing.
>>
>> For one of the functions of Spectra.jl package, I wrote for instance: 
>>
>> function gaussianarea(Amplitude::Array{Float64},HWHM::Array{Float64}; 
>> eseAmplitude::Array{Float64} = 0, eseHWHM::Array{Float64} = 0)
>>
>> I was thinking that using the ::Array{Float64} will allow users to enter 
>> either vectors or arrays. However, when I try to enter a vectors for 
>> Amplitude or HWHM for instance, I get the following error:
>>
>> LoadError: MethodError: `gaussianarea` has no method matching 
>> gaussianarea(::Array{Float64,1}, ::Array{Float64,1}, ::Array{Float64,1}, 
>> ::Array{Float64,1})
>> Closest candidates are:
>>   gaussianarea(::Array{Float64,N}, ::Array{Float64,N})
>> while loading In[46], in expression starting on line 9
>>
>>
>> I'm quite disappointed by that and don't know how to avoid it... Because 
>> for me a vector is an Array {Float64,1}... But the above message says no?
>>
>> What did I miss here? 
>>
>

Re: [julia-users] Re: Julia large project example.

[Tim Holy]

It's been a while, but long ago I remember noticing that Debug.jl has a more 
fine-grained module structure.

Best,
--Tim

On Thursday, May 12, 2016 12:34:23 PM Ford Ox wrote:
> I did read those and it didn't make it much clearer to me. (Hell I didn't
> even know what is coupling until this Thursday morning)
> That's why am I asking for example and possibly some page on this topic in
> docs, since I have been programming in OO languages all my short
> programmers life and Julia comes with completely different approach.
> Some things from OO can be achieved by different approach, some things
> can't be achieved and shouldn't be even tried to.
> I don't want to reinvent the wheel. I don't wanna try make Julia OO. But I
> want coupling / nicely distributed code into multiple files (that's why OO
> exist in the first place right?).
> 
> And I am sure that many people joining julia (especially with v1.0) will be
> asking the same question. Therefore I would expect some official guide at
> one visible place (which this thread is no more).
> 
> Dne čtvrtek 12. května 2016 19:40:06 UTC+2 David Anthoff napsal(a):
> > Do a search for “encapsulation” in this google group and you’ll find quite
> > a number of discussions on some of the design philosophies around this
> > topic, many from the julia devs.
> > 
> > 
> > 
> > *From:* julia...@googlegroups.com  [mailto:
> > julia...@googlegroups.com ] *On Behalf Of *Ford Ox
> > *Sent:* Thursday, May 12, 2016 10:20 AM
> > *To:* julia-users >
> > *Subject:* [julia-users] Re: Julia large project example.
> > 
> > 
> > 
> > I am sorry for those words. The idea of that sentence should have been:
> > 
> > "Your approach looks like a big no no.
> > Could julia devs share their idea of how should apple encapsulation
> > achieved? Since they are the one, who invented this language, they had to
> > consider *encapsulation* many times already, so they should be the very
> > first person who gives advice on this particular topic (since nobody
> > answered this topic well one comes to conclusion that they are also the
> > only one who can answer it)."
> > 
> > Thank you for your time and patience devoting to my questions.
> > 
> > Dne čtvrtek 12. května 2016 18:52:22 UTC+2 Kristoffer Carlsson napsal(a):
> > 
> > I am pretty sure the Julia developers can speak for themselves. A more
> > humble approach would suit you well.

Re: [julia-users] Re: Julia large project example.

[Sisyphuss]

I think what is missing in the docs is something like "package design 
guideline".


On Thursday, May 12, 2016 at 10:16:53 PM UTC+2, Scott Jones wrote:
>
> Very good advice - is anything like it already in the Julia docs?  If not, 
> it should be added, up near the beginning.
>
> On Thursday, May 12, 2016 at 4:10:22 PM UTC-4, Tom Breloff wrote:
>>
>> I find the most valuable thing to do when designing julia code is to 
>> focus purely on "verbs", not "nouns".  This means focusing on the action... 
>> NOT the object that is acting.  In julia, you can do fun stuff like:
>>
>> julia> type Car end
>>
>> julia> speed(::Car) = 60
>> speed (generic function with 1 method)
>>
>> julia> type Plane end
>>
>> julia> speed(::Plane) = 500
>> speed (generic function with 2 methods)
>>
>> julia> function move(pointA, pointB, tools...)
>>speeds = map(speed, tools)
>>idx = findmax(speeds)[2]
>>println("""I don't always go fast, but when I do, I prefer a 
>> $(lowercase(string(typeof(tools[idx].
>>   I am... the most interesting coder in the world.""")
>>end
>> move (generic function with 1 method)
>>
>> julia> move(1, 2, Car(), Plane())
>> I don't always go fast, but when I do, I prefer a plane.
>> I am... the most interesting coder in the world.
>>
>> julia> type Teleporter end
>>
>> julia> speed(::Teleporter) = Inf
>> speed (generic function with 3 methods)
>>
>> julia> move(1, 2, Car(), Plane(), Teleporter())
>> I don't always go fast, but when I do, I prefer a teleporter.
>> I am... the most interesting coder in the world.
>>
>> The point with this silly example is that, in OO, you would first start 
>> thinking about all the things that your transportation tools can do, and 
>> about heirarchies of "well, a plane is kind of like a car, and, well, kind 
>> of like a bird.  I know, I'll inherit from both!"  But really you should 
>> think about the important actions and attributes, and the hierarchy and 
>> interactions between objects will follow naturally. 
>>
>>
>> On Thursday, May 12, 2016 at 3:34:23 PM UTC-4, Ford Ox wrote:
>>>
>>> I did read those and it didn't make it much clearer to me. (Hell I 
>>> didn't even know what is coupling until this Thursday morning)
>>> That's why am I asking for example and possibly some page on this topic 
>>> in docs, since I have been programming in OO languages all my short 
>>> programmers life and Julia comes with completely different approach. 
>>> Some things from OO can be achieved by different approach, some things 
>>> can't be achieved and shouldn't be even tried to. 
>>> I don't want to reinvent the wheel. I don't wanna try make Julia OO. But 
>>> I want coupling / nicely distributed code into multiple files (that's why 
>>> OO exist in the first place right?).
>>>
>>> And I am sure that many people joining julia (especially with v1.0) will 
>>> be asking the same question. Therefore I would expect some official guide 
>>> at one visible place (which this thread is no more).
>>>
>>> Dne čtvrtek 12. května 2016 19:40:06 UTC+2 David Anthoff napsal(a):

 Do a search for “encapsulation” in this google group and you’ll find 
 quite a number of discussions on some of the design philosophies around 
 this topic, many from the julia devs.

  

 *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
 Behalf Of *Ford Ox
 *Sent:* Thursday, May 12, 2016 10:20 AM
 *To:* julia-users 
 *Subject:* [julia-users] Re: Julia large project example.

  

 I am sorry for those words. The idea of that sentence should have been:

 "Your approach looks like a big no no. 
 Could julia devs share their idea of how should apple encapsulation 
 achieved? Since they are the one, who invented this language, they had to 
 consider *encapsulation* many times already, so they should be the 
 very first person who gives advice on this particular topic (since nobody 
 answered this topic well one comes to conclusion that they are also the 
 only one who can answer it)."

 Thank you for your time and patience devoting to my questions.

 Dne čtvrtek 12. května 2016 18:52:22 UTC+2 Kristoffer Carlsson 
 napsal(a):

 I am pretty sure the Julia developers can speak for themselves. A more 
 humble approach would suit you well.

Re: [julia-users] Re: Julia large project example.

[Sisyphuss]

This sure is valuable advice.

But I'm not sure whether in v1.0, it will be the same case.


On Thursday, May 12, 2016 at 10:10:22 PM UTC+2, Tom Breloff wrote:
>
> I find the most valuable thing to do when designing julia code is to focus 
> purely on "verbs", not "nouns".  This means focusing on the action... NOT 
> the object that is acting.  In julia, you can do fun stuff like:
>
> julia> type Car end
>
> julia> speed(::Car) = 60
> speed (generic function with 1 method)
>
> julia> type Plane end
>
> julia> speed(::Plane) = 500
> speed (generic function with 2 methods)
>
> julia> function move(pointA, pointB, tools...)
>speeds = map(speed, tools)
>idx = findmax(speeds)[2]
>println("""I don't always go fast, but when I do, I prefer a 
> $(lowercase(string(typeof(tools[idx].
>   I am... the most interesting coder in the world.""")
>end
> move (generic function with 1 method)
>
> julia> move(1, 2, Car(), Plane())
> I don't always go fast, but when I do, I prefer a plane.
> I am... the most interesting coder in the world.
>
> julia> type Teleporter end
>
> julia> speed(::Teleporter) = Inf
> speed (generic function with 3 methods)
>
> julia> move(1, 2, Car(), Plane(), Teleporter())
> I don't always go fast, but when I do, I prefer a teleporter.
> I am... the most interesting coder in the world.
>
> The point with this silly example is that, in OO, you would first start 
> thinking about all the things that your transportation tools can do, and 
> about heirarchies of "well, a plane is kind of like a car, and, well, kind 
> of like a bird.  I know, I'll inherit from both!"  But really you should 
> think about the important actions and attributes, and the hierarchy and 
> interactions between objects will follow naturally. 
>
>
> On Thursday, May 12, 2016 at 3:34:23 PM UTC-4, Ford Ox wrote:
>>
>> I did read those and it didn't make it much clearer to me. (Hell I didn't 
>> even know what is coupling until this Thursday morning)
>> That's why am I asking for example and possibly some page on this topic 
>> in docs, since I have been programming in OO languages all my short 
>> programmers life and Julia comes with completely different approach. 
>> Some things from OO can be achieved by different approach, some things 
>> can't be achieved and shouldn't be even tried to. 
>> I don't want to reinvent the wheel. I don't wanna try make Julia OO. But 
>> I want coupling / nicely distributed code into multiple files (that's why 
>> OO exist in the first place right?).
>>
>> And I am sure that many people joining julia (especially with v1.0) will 
>> be asking the same question. Therefore I would expect some official guide 
>> at one visible place (which this thread is no more).
>>
>> Dne čtvrtek 12. května 2016 19:40:06 UTC+2 David Anthoff napsal(a):
>>>
>>> Do a search for “encapsulation” in this google group and you’ll find 
>>> quite a number of discussions on some of the design philosophies around 
>>> this topic, many from the julia devs.
>>>
>>>  
>>>
>>> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
>>> Behalf Of *Ford Ox
>>> *Sent:* Thursday, May 12, 2016 10:20 AM
>>> *To:* julia-users 
>>> *Subject:* [julia-users] Re: Julia large project example.
>>>
>>>  
>>>
>>> I am sorry for those words. The idea of that sentence should have been:
>>>
>>> "Your approach looks like a big no no. 
>>> Could julia devs share their idea of how should apple encapsulation 
>>> achieved? Since they are the one, who invented this language, they had to 
>>> consider *encapsulation* many times already, so they should be the very 
>>> first person who gives advice on this particular topic (since nobody 
>>> answered this topic well one comes to conclusion that they are also the 
>>> only one who can answer it)."
>>>
>>> Thank you for your time and patience devoting to my questions.
>>>
>>> Dne čtvrtek 12. května 2016 18:52:22 UTC+2 Kristoffer Carlsson napsal(a):
>>>
>>> I am pretty sure the Julia developers can speak for themselves. A more 
>>> humble approach would suit you well.
>>>
>>>

[julia-users] How much memory should pmap workers use?

[Thomas Covert]

I have a function f(i) that operates on the i-th piece of a linear algebra 
heavy calculation I am doing, independently of the other pieces of the 
calculation.  If I is the set of indices I need to work on, I can 
accomplish this with something like pmap(f, I).

How much memory should each worker process maintain after pmap(f, I) is 
done?  presumably, just enough memory for holding Main and anything I 
allocated with an @everywhere, right?  However, after pmap(f, I) is done, I 
still see nprocs()-1 julia workers using lots of memory, which seems wrong 
to me.  

I've coded up a MWE example 
here: https://gist.github.com/tcovert/3b9b982ba8b13f5984bebb63887b6def

Here is what f() is supposed to do to each element i in I:
1) select a subset of a square, invertible matrix K.  each i needs a 
different subset
2) select a subset of a rectangular matrix k whose column dimension is the 
same as the column dimension of the above subset of K
3) select a subset of a vector y
4) compute k_i * (K_i \ y_i), where _i indicates the subsets above  

I realize that the subsetting and linear algebra work should allocate 
memory along the way, but I would have thought that this memory would be 
freed up after pmap() is done.

on my machine, this code leaves 4 worker processes, each using about 350 
megabytes of RAM, even after an @everywhere gc().  With a problem this 
size, RAM isn't a problem, but ideally I am using more workers, on bigger 
problems, which eventually will become memory constrained.

am I doing something wrong?  or are my expectations wrong, and this kind of 
task should indeed involve that much memory after the task is over?

-thom

[julia-users] Re: select/poll on TCPSocket in Julia?

[Andrei Zh]

Alternative questions: 

 1. Is there a way to check if TCPSocket has any incoming data? 
 2. Is it possible to set timeout for `read` operation on a socket?
 3. Can we convert TCPSocket to a file descriptor to use with `poll_fd`?

Any tips are welcome.

Maybe it's possible to convert TCPSocket to a file descriptor?

On Thursday, May 12, 2016 at 12:45:44 AM UTC+3, Andrei Zh wrote:
>
> Given several TCPSocket-s, how can I sequentially poll them and read the 
> first that becomes readable?
>
> I believe *nix's poll/select functions provide something similar for files 
> (and Julia has `poll_fd`), but what is the best way to approach this task 
> for sockets?
>

Re: [julia-users] Re: Julia large project example.

[Scott Jones]

Very good advice - is anything like it already in the Julia docs?  If not, 
it should be added, up near the beginning.

On Thursday, May 12, 2016 at 4:10:22 PM UTC-4, Tom Breloff wrote:
>
> I find the most valuable thing to do when designing julia code is to focus 
> purely on "verbs", not "nouns".  This means focusing on the action... NOT 
> the object that is acting.  In julia, you can do fun stuff like:
>
> julia> type Car end
>
> julia> speed(::Car) = 60
> speed (generic function with 1 method)
>
> julia> type Plane end
>
> julia> speed(::Plane) = 500
> speed (generic function with 2 methods)
>
> julia> function move(pointA, pointB, tools...)
>speeds = map(speed, tools)
>idx = findmax(speeds)[2]
>println("""I don't always go fast, but when I do, I prefer a 
> $(lowercase(string(typeof(tools[idx].
>   I am... the most interesting coder in the world.""")
>end
> move (generic function with 1 method)
>
> julia> move(1, 2, Car(), Plane())
> I don't always go fast, but when I do, I prefer a plane.
> I am... the most interesting coder in the world.
>
> julia> type Teleporter end
>
> julia> speed(::Teleporter) = Inf
> speed (generic function with 3 methods)
>
> julia> move(1, 2, Car(), Plane(), Teleporter())
> I don't always go fast, but when I do, I prefer a teleporter.
> I am... the most interesting coder in the world.
>
> The point with this silly example is that, in OO, you would first start 
> thinking about all the things that your transportation tools can do, and 
> about heirarchies of "well, a plane is kind of like a car, and, well, kind 
> of like a bird.  I know, I'll inherit from both!"  But really you should 
> think about the important actions and attributes, and the hierarchy and 
> interactions between objects will follow naturally. 
>
>
> On Thursday, May 12, 2016 at 3:34:23 PM UTC-4, Ford Ox wrote:
>>
>> I did read those and it didn't make it much clearer to me. (Hell I didn't 
>> even know what is coupling until this Thursday morning)
>> That's why am I asking for example and possibly some page on this topic 
>> in docs, since I have been programming in OO languages all my short 
>> programmers life and Julia comes with completely different approach. 
>> Some things from OO can be achieved by different approach, some things 
>> can't be achieved and shouldn't be even tried to. 
>> I don't want to reinvent the wheel. I don't wanna try make Julia OO. But 
>> I want coupling / nicely distributed code into multiple files (that's why 
>> OO exist in the first place right?).
>>
>> And I am sure that many people joining julia (especially with v1.0) will 
>> be asking the same question. Therefore I would expect some official guide 
>> at one visible place (which this thread is no more).
>>
>> Dne čtvrtek 12. května 2016 19:40:06 UTC+2 David Anthoff napsal(a):
>>>
>>> Do a search for “encapsulation” in this google group and you’ll find 
>>> quite a number of discussions on some of the design philosophies around 
>>> this topic, many from the julia devs.
>>>
>>>  
>>>
>>> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
>>> Behalf Of *Ford Ox
>>> *Sent:* Thursday, May 12, 2016 10:20 AM
>>> *To:* julia-users 
>>> *Subject:* [julia-users] Re: Julia large project example.
>>>
>>>  
>>>
>>> I am sorry for those words. The idea of that sentence should have been:
>>>
>>> "Your approach looks like a big no no. 
>>> Could julia devs share their idea of how should apple encapsulation 
>>> achieved? Since they are the one, who invented this language, they had to 
>>> consider *encapsulation* many times already, so they should be the very 
>>> first person who gives advice on this particular topic (since nobody 
>>> answered this topic well one comes to conclusion that they are also the 
>>> only one who can answer it)."
>>>
>>> Thank you for your time and patience devoting to my questions.
>>>
>>> Dne čtvrtek 12. května 2016 18:52:22 UTC+2 Kristoffer Carlsson napsal(a):
>>>
>>> I am pretty sure the Julia developers can speak for themselves. A more 
>>> humble approach would suit you well.
>>>
>>>

Re: [julia-users] Re: Julia large project example.

[Tom Breloff]

I find the most valuable thing to do when designing julia code is to focus 
purely on "verbs", not "nouns".  This means focusing on the action... NOT 
the object that is acting.  In julia, you can do fun stuff like:

julia> type Car end

julia> speed(::Car) = 60
speed (generic function with 1 method)

julia> type Plane end

julia> speed(::Plane) = 500
speed (generic function with 2 methods)

julia> function move(pointA, pointB, tools...)
   speeds = map(speed, tools)
   idx = findmax(speeds)[2]
   println("""I don't always go fast, but when I do, I prefer a 
$(lowercase(string(typeof(tools[idx].
  I am... the most interesting coder in the world.""")
   end
move (generic function with 1 method)

julia> move(1, 2, Car(), Plane())
I don't always go fast, but when I do, I prefer a plane.
I am... the most interesting coder in the world.

julia> type Teleporter end

julia> speed(::Teleporter) = Inf
speed (generic function with 3 methods)

julia> move(1, 2, Car(), Plane(), Teleporter())
I don't always go fast, but when I do, I prefer a teleporter.
I am... the most interesting coder in the world.

The point with this silly example is that, in OO, you would first start 
thinking about all the things that your transportation tools can do, and 
about heirarchies of "well, a plane is kind of like a car, and, well, kind 
of like a bird.  I know, I'll inherit from both!"  But really you should 
think about the important actions and attributes, and the hierarchy and 
interactions between objects will follow naturally. 


On Thursday, May 12, 2016 at 3:34:23 PM UTC-4, Ford Ox wrote:
>
> I did read those and it didn't make it much clearer to me. (Hell I didn't 
> even know what is coupling until this Thursday morning)
> That's why am I asking for example and possibly some page on this topic in 
> docs, since I have been programming in OO languages all my short 
> programmers life and Julia comes with completely different approach. 
> Some things from OO can be achieved by different approach, some things 
> can't be achieved and shouldn't be even tried to. 
> I don't want to reinvent the wheel. I don't wanna try make Julia OO. But I 
> want coupling / nicely distributed code into multiple files (that's why OO 
> exist in the first place right?).
>
> And I am sure that many people joining julia (especially with v1.0) will 
> be asking the same question. Therefore I would expect some official guide 
> at one visible place (which this thread is no more).
>
> Dne čtvrtek 12. května 2016 19:40:06 UTC+2 David Anthoff napsal(a):
>>
>> Do a search for “encapsulation” in this google group and you’ll find 
>> quite a number of discussions on some of the design philosophies around 
>> this topic, many from the julia devs.
>>
>>  
>>
>> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
>> Behalf Of *Ford Ox
>> *Sent:* Thursday, May 12, 2016 10:20 AM
>> *To:* julia-users 
>> *Subject:* [julia-users] Re: Julia large project example.
>>
>>  
>>
>> I am sorry for those words. The idea of that sentence should have been:
>>
>> "Your approach looks like a big no no. 
>> Could julia devs share their idea of how should apple encapsulation 
>> achieved? Since they are the one, who invented this language, they had to 
>> consider *encapsulation* many times already, so they should be the very 
>> first person who gives advice on this particular topic (since nobody 
>> answered this topic well one comes to conclusion that they are also the 
>> only one who can answer it)."
>>
>> Thank you for your time and patience devoting to my questions.
>>
>> Dne čtvrtek 12. května 2016 18:52:22 UTC+2 Kristoffer Carlsson napsal(a):
>>
>> I am pretty sure the Julia developers can speak for themselves. A more 
>> humble approach would suit you well.
>>
>>

[julia-users] old objects and new code

[Boylan, Ross]

A file has code surrounded by a module declaration.  It includes definitions of 
some types and some functions.
In the REPL (ESS) I include the file and execute a function that returns me an 
object x of type MyModule.Foo.
Then I change some of the code and include the module again.  The type Foo is 
unchanged.

It seems to me that when I execute one of the module functions on x the 
original version of the function, not the revised version, gets called.

If I recreate x then I get the current function definitions aka what I wanted.

First, is my understanding of what's going on correct? 

Second, any recommendations for dealing with this?  In this case regenerating x 
was not a big deal, but I can imagine situations that weren't so trivial.  If 
there were lots of objects involved, one could keep a script that creates them 
and rerun it.

Thanks
Ross Boylan

Re: [julia-users] Re: Julia large project example.

[Ford Ox]

I did read those and it didn't make it much clearer to me. (Hell I didn't 
even know what is coupling until this Thursday morning)
That's why am I asking for example and possibly some page on this topic in 
docs, since I have been programming in OO languages all my short 
programmers life and Julia comes with completely different approach. 
Some things from OO can be achieved by different approach, some things 
can't be achieved and shouldn't be even tried to. 
I don't want to reinvent the wheel. I don't wanna try make Julia OO. But I 
want coupling / nicely distributed code into multiple files (that's why OO 
exist in the first place right?).

And I am sure that many people joining julia (especially with v1.0) will be 
asking the same question. Therefore I would expect some official guide at 
one visible place (which this thread is no more).

Dne čtvrtek 12. května 2016 19:40:06 UTC+2 David Anthoff napsal(a):
>
> Do a search for “encapsulation” in this google group and you’ll find quite 
> a number of discussions on some of the design philosophies around this 
> topic, many from the julia devs.
>
>  
>
> *From:* julia...@googlegroups.com  [mailto:
> julia...@googlegroups.com ] *On Behalf Of *Ford Ox
> *Sent:* Thursday, May 12, 2016 10:20 AM
> *To:* julia-users >
> *Subject:* [julia-users] Re: Julia large project example.
>
>  
>
> I am sorry for those words. The idea of that sentence should have been:
>
> "Your approach looks like a big no no. 
> Could julia devs share their idea of how should apple encapsulation 
> achieved? Since they are the one, who invented this language, they had to 
> consider *encapsulation* many times already, so they should be the very 
> first person who gives advice on this particular topic (since nobody 
> answered this topic well one comes to conclusion that they are also the 
> only one who can answer it)."
>
> Thank you for your time and patience devoting to my questions.
>
> Dne čtvrtek 12. května 2016 18:52:22 UTC+2 Kristoffer Carlsson napsal(a):
>
> I am pretty sure the Julia developers can speak for themselves. A more 
> humble approach would suit you well.
>
>

Re: [julia-users] Re: how long until vectorized code runs fast?

[Tim Holy]

On Thursday, May 12, 2016 06:44:16 AM Anonymous wrote:
>  Also like I said before, I'm most curious about the current status of
> operations of the form:
> 
> [1 2; 3 4] .* [1 2]
> 
> is such an operation covered by BLAS?

No, among other reasons because BLAS only handles floating-point numbers. That 
specific operation is handled by broadcasting.

Best,
--Tim

> 
> On Thursday, May 12, 2016 at 5:58:22 AM UTC-7, Tim Holy wrote:
> > Did you run it twice? Remember that memory is allocated during JIT
> > compilation, so the amount of memory on the first call is completely
> > meaningless.
> > 
> > --Tim
> > 
> > On Wednesday, May 11, 2016 11:03:38 PM Anonymous wrote:
> > > In response to both Kristoffer and Keno's timely responses,
> > > 
> > > Originally I just did a simple @time test of the form
> > > Matrix .* horizontal vector
> > > 
> > > and then tested the same thing with for loops, and the for loops were
> > 
> > way
> > 
> > > faster (and used way less memory)
> > > 
> > > However I just devectorized one of my algorithms and ran an @time
> > > comparison and the vectorized version was actually twice as fast as the
> > > devectorized version, however the vectorized version used way more
> > 
> > memory.
> > 
> > >  Clearly I don't really understand the specifics of what makes code
> > 
> > slow,
> > 
> > > and in particular how vectorized code compares to devectorized code.
> > > 
> > >  Vectorized code does seem to use a lot more memory, but clearly for my
> > > 
> > > algorithm it nevertheless runs faster than the devectorized version.  Is
> > > there a reference I could look at that explains this to someone with a
> > > background in math but not much knowledge of computer architecture?
> > > 
> > > On Wednesday, May 11, 2016 at 10:41:55 PM UTC-7, Keno Fischer wrote:
> > > > There seems to be a myth going around that vectorized code in Julia is
> > > > slow. That's not really the case. Often times it's just that
> > > > devectorized code is faster because one can manually perform
> > > > operations such as loop fusion, which the compiler cannot currently
> > > > reason about (and most C compilers can't either). In some other
> > > > languages those benefits get drowned out by language overhead, but in
> > > > julia those kinds of constructs are generally fast. The cases where
> > > > julia can be slower is when there is excessive memory allocation in a
> > > > tight inner loop, but those cases can usually be rewritten fairly
> > > > easily without losing the vectorized look of the code.
> > > > 
> > > > On Thu, May 12, 2016 at 1:35 AM, Kristoffer Carlsson
> > > > 
> > > > > wrote:
> > > > > It is always easier to discuss if there is a piece of code to look
> > 
> > at.
> > 
> > > > Could
> > > > 
> > > > > you perhaps post a few code examples that does not run as fast as
> > 
> > you
> > 
> > > > want?
> > > > 
> > > > > Also, make sure to look at :
> > > > > https://github.com/IntelLabs/ParallelAccelerator.jl. They have a
> > 
> > quite
> > 
> > > > > sophisticated compiler that does loop fusions and parallelization
> > 
> > and
> > 
> > > > other
> > > > 
> > > > > cool stuff.
> > > > > 
> > > > > On Thursday, May 12, 2016 at 7:22:24 AM UTC+2, Anonymous wrote:
> > > > >> This remains one of the main drawbacks of Julia, and the
> > 
> > devectorize
> > 
> > > > >> package is basically useless as it doesn't support some really
> > 
> > crucial
> > 
> > > > >> vectorized operations.  I'd really prefer not to rewrite all my
> > > > 
> > > > vectorized
> > > > 
> > > > >> code into nested loops if at all possible, but I really need more
> > > > 
> > > > speed, can
> > > > 
> > > > >> anyone tell me the timeline and future plans for making vectorized
> > 
> > code
> > 
> > > > run
> > > > 
> > > > >> at C speed?

RE: [julia-users] Re: Julia large project example.

[David Anthoff]

Do a search for “encapsulation” in this google group and you’ll find quite a 
number of discussions on some of the design philosophies around this topic, 
many from the julia devs.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Ford Ox
Sent: Thursday, May 12, 2016 10:20 AM
To: julia-users 
Subject: [julia-users] Re: Julia large project example.

 

I am sorry for those words. The idea of that sentence should have been:

"Your approach looks like a big no no. 
Could julia devs share their idea of how should apple encapsulation achieved? 
Since they are the one, who invented this language, they had to consider 
encapsulation many times already, so they should be the very first person who 
gives advice on this particular topic (since nobody answered this topic well 
one comes to conclusion that they are also the only one who can answer it)."

Thank you for your time and patience devoting to my questions.

Dne čtvrtek 12. května 2016 18:52:22 UTC+2 Kristoffer Carlsson napsal(a):

I am pretty sure the Julia developers can speak for themselves. A more humble 
approach would suit you well.

[julia-users] Re: Julia large project example.

[Ford Ox]

I am sorry for those words. The idea of that sentence should have been:

"Your approach looks like a big no no. 
Could julia devs share their idea of how should apple encapsulation 
achieved? Since they are the one, who invented this language, they had to 
consider *encapsulation* many times already, so they should be the very 
first person who gives advice on this particular topic (since nobody 
answered this topic well one comes to conclusion that they are also the 
only one who can answer it)."

Thank you for your time and patience devoting to my questions.

Dne čtvrtek 12. května 2016 18:52:22 UTC+2 Kristoffer Carlsson napsal(a):
>
> I am pretty sure the Julia developers can speak for themselves. A more 
> humble approach would suit you well.

Re: [julia-users] Re: how long until vectorized code runs fast?

[Stefan Karpinski]

I also have to ask... you're not working with global variables, right?

On Thu, May 12, 2016 at 4:05 PM, Ford Ox  wrote:

> Why dont you just post your code here?
>
> Dne čtvrtek 12. května 2016 15:53:35 UTC+2 Anonymous napsal(a):
>
>> Yes the algorithm I'm testing this on is fairly polished at this point,
>> all variables are within a type and they all have strict type
>> declarations.  The memory allocations are very low compared to the
>> vectorized code, so memory-wise the loops are doing their job, but this
>> doesn't translate into speed-ups.
>>
>> On Thursday, May 12, 2016 at 6:46:32 AM UTC-7, Steven G. Johnson wrote:
>>>
>>>
>>>
>>> On Thursday, May 12, 2016 at 8:51:44 AM UTC-4, Miguel Bazdresch wrote:

 honestly I've been testing out different devectorizations of my
> algorithms and I keep getting slower results, not faster, so either I
> really suck at writing for loops or Julia is doing a good job with my
> vectorized code.
>

>>> Make sure your loops are in a function — don't benchmark in global scope
>>> (see the performance tips sections of the manual).  Try running your
>>> function through @code_warntype myfunction(args...) and see if it warns
>>> marks any variables as type "ANY" (which indicates a type instability in
>>> your code, see the performance tips),
>>>
>>> Also, if you do "@time myfunc(args...)" and it indicates that you did a
>>> huge number of allocations, you could either have a type instability or be
>>> allocating new arrays in your inner loops (it is always better to allocate
>>> arrays once outside your inner loops and then update them in-place as
>>> needed).
>>>
>>

[julia-users] Julia Utopia: Share your tips and tricks to efficient coding in Julia

[David Parks]

I'm a few weeks into Julia and excited and motivated to learn and be as 
efficient as possible. I'm sure I'm not alone. I know my way around now, 
but am I as efficient as I can be? 

What haven't I tried? What haven't I seen? What haven't I asked?

For those of you who have been around longer, could you share your advice 
on efficient day-to-day development style?

For example:

   - What IDE do you use? Are you using Atom? A combination of Atom and the 
   REPL? Something else?
   - How do you debug complex code efficiently? How do you debug other 
   peoples code efficiently?
   - Do you have a favorite way of visualizing your work?
   - Are there must have tools? packages? utilities?
   - Any simple day-to-day efficiency/advice you could share with others 
   who didn't yet know to ask.

Re: [julia-users] Re: Julia large project example.

[Tom Breloff]

That's quite the understatement Kristoffer...

On Thu, May 12, 2016 at 12:52 PM, Kristoffer Carlsson  wrote:

> I am pretty sure the Julia developers can speak for themselves. A more
> humble approach would suit you well.

[julia-users] Re: Julia large project example.

[Kristoffer Carlsson]

I am pretty sure the Julia developers can speak for themselves. A more humble 
approach would suit you well.

[julia-users] Re: Julia large project example.

[Ford Ox]

That was exactly what I didn't want to see. This approach is so dirty that 
I feel like earth worm just by looking at this.
I am pretty sure that julia devs share my disgust :)

Dne čtvrtek 12. května 2016 17:29:01 UTC+2 Sisyphuss napsal(a):
>
> I have tried to use Julia module as static class. According to my 
> experience, it is doable. You cannot have two modules of the same names 
> though. When it comes to your example, it means you can't have two apples 
> (this apple and that apple). 
>
> I am afraid you should use immutable Apple type.
> immutable Apple
>   s::float64
>   t::float64
>   Apple(a,b) = s > 0 ? new(a,b) : error("size should be positive")
> end
>
> Apple()= Apple(rand(),rand())
> size(x::Apple) = x.s
> taste(x::Apple) = x.t
>
> a = Apple()
> size(a)
> taste(a)
>
>
>
> On Thursday, May 12, 2016 at 4:26:50 PM UTC+2, Ford Ox wrote:
>>
>> I have checked julia git, but some questions still remain.
>>
>> Should I use module as class substitution? (Every global variable in 
>> module is encapsulated. Same for function unless one uses export). 
>> In that case where is my constructor?
>>
>> In OO languages you know exactly what methods every object has (in IDE 
>> you can use CTRL+Space). How can I do that, or should I need to do that in 
>> julia?
>>
>> Let's say I create a module called Apple, with methods taste() and 
>> size(), and somebody wants to use that module. Methods taste() and size() 
>> are obviously just getters for variables that are somehow stored in Apple 
>> module. The user should be never able to change size and taste of apple by 
>> himself, those values will be randomly set when constructor is called.
>> How do I encapsulate those two variables? Where do I store those two 
>> variables (If I store them in type, user must be able to pass that type 
>> into Apple methods, thus he can just do AppleType.size  = 6). How do I call 
>> constructor if variables are not stored in type?
>> Note: I don't want to have immutable AppleType!
>>
>

[julia-users] Re: Julia large project example.

[David P. Sanders]

In this example you can easily create another, distinct, object of the same 
type with a2=Apple(). 

[julia-users] Re: Julia large project example.

[Sisyphuss]

I have tried to use Julia module as static class. According to my 
experience, it is doable. You cannot have two modules of the same names 
though. When it comes to your example, it means you can't have two apples 
(this apple and that apple). 

I am afraid you should use immutable Apple type.
immutable Apple
  s::float64
  t::float64
  Apple(a,b) = s > 0 ? new(a,b) : error("size should be positive")
end

Apple()= Apple(rand(),rand())
size(x::Apple) = x.s
taste(x::Apple) = x.t

a = Apple()
size(a)
taste(a)



On Thursday, May 12, 2016 at 4:26:50 PM UTC+2, Ford Ox wrote:
>
> I have checked julia git, but some questions still remain.
>
> Should I use module as class substitution? (Every global variable in 
> module is encapsulated. Same for function unless one uses export). 
> In that case where is my constructor?
>
> In OO languages you know exactly what methods every object has (in IDE you 
> can use CTRL+Space). How can I do that, or should I need to do that in 
> julia?
>
> Let's say I create a module called Apple, with methods taste() and size(), 
> and somebody wants to use that module. Methods taste() and size() are 
> obviously just getters for variables that are somehow stored in Apple 
> module. The user should be never able to change size and taste of apple by 
> himself, those values will be randomly set when constructor is called.
> How do I encapsulate those two variables? Where do I store those two 
> variables (If I store them in type, user must be able to pass that type 
> into Apple methods, thus he can just do AppleType.size  = 6). How do I call 
> constructor if variables are not stored in type?
> Note: I don't want to have immutable AppleType!
>

[julia-users] meeting problem when installing GadFly

[SHORE SHEN]

Ima using win 10, here's the error msg

failed process: Process(`git clone -q --mirror 
git://github.com/JuliaLang/Iterators.jl.git 
'C:\Users\shoren\.julia\v0.4\.cache\Iterators'`, ProcessExited(128)) [128]

 in pipeline_error at process.jl:555

 in sync_end at task.jl:413

 [inlined code] from task.jl:422

 in add at pkg/entry.jl:64

 in add at pkg/entry.jl:73

 in anonymous at pkg/dir.jl:31

 in cd at file.jl:32

 in cd at pkg/dir.jl:31

 in add at pkg.jl:23

 in include_string at C:\Users\shoren\.julia\v0.4\CodeTools\src\eval.jl:28

 in include_string at C:\Users\shoren\.julia\v0.4\CodeTools\src\eval.jl:32

 [inlined code] from C:\Users\shoren\.julia\v0.4\Atom\src\eval.jl:39

 in anonymous at C:\Users\shoren\.julia\v0.4\Atom\src\eval.jl:62

 in withpath at C:\Users\shoren\.julia\v0.4\Requires\src\require.jl:37

 in withpath at C:\Users\shoren\.julia\v0.4\Atom\src\eval.jl:53

 [inlined code] from C:\Users\shoren\.julia\v0.4\Atom\src\eval.jl:61

 in anonymous at task.jl:58

[julia-users] Re: Julia large project example.

[Ford Ox]

I would expect that those questions will be answered in documentation in 
bold even if the answer is: No, you can't do that!

[julia-users] Re: Julia large project example.

[Ford Ox]

I have checked julia git, but some questions still remain.

Should I use module as class substitution? (Every global variable in module 
is encapsulated. Same for function unless one uses export). 
In that case where is my constructor?

In OO languages you know exactly what methods every object has (in IDE you 
can use CTRL+Space). How can I do that, or should I need to do that in 
julia?

Let's say I create a module called Apple, with methods taste() and size(), 
and somebody wants to use that module. Methods taste() and size() are 
obviously just getters for variables that are somehow stored in Apple 
module. The user should be never able to change size and taste of apple by 
himself, those values will be randomly set when constructor is called.
How do I encapsulate those two variables? Where do I store those two 
variables (If I store them in type, user must be able to pass that type 
into Apple methods, thus he can just do AppleType.size  = 6). How do I call 
constructor if variables are not stored in type?
Note: I don't want to have immutable AppleType!

Re: [julia-users] Re: static compilation

[Ján Adamčák]

Thanks @Jameson,

I am a bit confused about "you are not adding any code to the system image 
(`--eval nothing`)". According to your blog 
http://juliacomputing.com/blog/2016/02/09/static-julia.html , I think that 
this is a crucial point to obtain a small sized dll. Am I right?

What is then the right way to emit "ccallable" declarations in order to 
export julia function(s)? (foo in our example from the original post in 
this thread)

Is it okay to work with current version of julia 0.4.5. or I have to switch 
to another version; If yes, to which one?

Thanks in advance.

Dňa utorok, 10. mája 2016 22:13:57 UTC+2 Jameson napísal(-a):
>
> The compile-all flag is only partially functional on v0.4. I think it's 
> best to just leave it off. I tested on master and fixed a bug with emitting 
> `@ccallable`, but that's unrelated. From the command line below, it looks 
> like you are not adding any code to the system image (`--eval nothing`) 
> which would also means there are no `ccallable` declarations being emitted 
> into the current compile.
>
> Other than that, I don't see anything wrong with that command. You 
> shouldn't see that error unless you tried to make a Task or use `@async` 
> from the compile host. It's ambiguous how that would be serialized, so it's 
> simply an error and any parallel workers should be created / started by an 
> `__init__` method.
>
>
> On Tuesday, May 10, 2016 at 2:53:22 AM UTC-4, Ján Adamčák wrote:
>>
>> Hello guys, 
>>
>> Thank you for your comments, though we were more optimistic...
>>
>>
>> Dňa piatok, 6. mája 2016 16:27:28 UTC+2 Ján Adamčák napísal(-a):
>>>
>>> Sorry, my fault. 
>>>
>>> During last week I created build_sysimg2.jl from julia 0.4.5 
>>> build_sysimg.jl and when I run it, at line 86 (build_sysimg2.jl)
>>>
>>> run(`$julia -C $cpu_target --output-o sysimg_all.o --sysimage 
>>> $sysimg_path.$(Libdl.dlext) --startup-file=no --compile=all --eval nothing`)
>>>
>>> I got this error:
>>>
>>> fatal: error thrown and no exception handler available.
>>> ErrorException("Task cannot be serialized")
>>> jl_unprotect_stack at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_throw at C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll 
>>> (unknown line)
>>> jl_error at C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll 
>>> (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Adam\AppData\Local\Julia-0.4.5\bin\libjulia.dll (unknown line)
>>> jl_compress_ast at 
>>> C:\Users\Ad

Re: [julia-users] Re: how long until vectorized code runs fast?

[Ford Ox]

Why dont you just post your code here? 

Dne čtvrtek 12. května 2016 15:53:35 UTC+2 Anonymous napsal(a):
>
> Yes the algorithm I'm testing this on is fairly polished at this point, 
> all variables are within a type and they all have strict type declarations. 
>  The memory allocations are very low compared to the vectorized code, so 
> memory-wise the loops are doing their job, but this doesn't translate into 
> speed-ups.
>
> On Thursday, May 12, 2016 at 6:46:32 AM UTC-7, Steven G. Johnson wrote:
>>
>>
>>
>> On Thursday, May 12, 2016 at 8:51:44 AM UTC-4, Miguel Bazdresch wrote:
>>>
>>> honestly I've been testing out different devectorizations of my 
 algorithms and I keep getting slower results, not faster, so either I 
 really suck at writing for loops or Julia is doing a good job with my 
 vectorized code.

>>>
>> Make sure your loops are in a function — don't benchmark in global scope 
>> (see the performance tips sections of the manual).  Try running your 
>> function through @code_warntype myfunction(args...) and see if it warns 
>> marks any variables as type "ANY" (which indicates a type instability in 
>> your code, see the performance tips),
>>
>> Also, if you do "@time myfunc(args...)" and it indicates that you did a 
>> huge number of allocations, you could either have a type instability or be 
>> allocating new arrays in your inner loops (it is always better to allocate 
>> arrays once outside your inner loops and then update them in-place as 
>> needed).
>>
>

Re: [julia-users] Re: how long until vectorized code runs fast?

[Anonymous]

Yes the algorithm I'm testing this on is fairly polished at this point, all 
variables are within a type and they all have strict type declarations. 
 The memory allocations are very low compared to the vectorized code, so 
memory-wise the loops are doing their job, but this doesn't translate into 
speed-ups.

On Thursday, May 12, 2016 at 6:46:32 AM UTC-7, Steven G. Johnson wrote:
>
>
>
> On Thursday, May 12, 2016 at 8:51:44 AM UTC-4, Miguel Bazdresch wrote:
>>
>> honestly I've been testing out different devectorizations of my 
>>> algorithms and I keep getting slower results, not faster, so either I 
>>> really suck at writing for loops or Julia is doing a good job with my 
>>> vectorized code.
>>>
>>
> Make sure your loops are in a function — don't benchmark in global scope 
> (see the performance tips sections of the manual).  Try running your 
> function through @code_warntype myfunction(args...) and see if it warns 
> marks any variables as type "ANY" (which indicates a type instability in 
> your code, see the performance tips),
>
> Also, if you do "@time myfunc(args...)" and it indicates that you did a 
> huge number of allocations, you could either have a type instability or be 
> allocating new arrays in your inner loops (it is always better to allocate 
> arrays once outside your inner loops and then update them in-place as 
> needed).
>

Re: [julia-users] Re: how long until vectorized code runs fast?

[Tom Breloff]

Also it's possible that your vectorized versions are being passed to
multithreaded routines? The setup might require more memory but the
execution would run in parallel.

On Thu, May 12, 2016 at 9:46 AM, Steven G. Johnson 
wrote:

>
>
> On Thursday, May 12, 2016 at 8:51:44 AM UTC-4, Miguel Bazdresch wrote:
>>
>> honestly I've been testing out different devectorizations of my
>>> algorithms and I keep getting slower results, not faster, so either I
>>> really suck at writing for loops or Julia is doing a good job with my
>>> vectorized code.
>>>
>>
> Make sure your loops are in a function — don't benchmark in global scope
> (see the performance tips sections of the manual).  Try running your
> function through @code_warntype myfunction(args...) and see if it warns
> marks any variables as type "ANY" (which indicates a type instability in
> your code, see the performance tips),
>
> Also, if you do "@time myfunc(args...)" and it indicates that you did a
> huge number of allocations, you could either have a type instability or be
> allocating new arrays in your inner loops (it is always better to allocate
> arrays once outside your inner loops and then update them in-place as
> needed).
>

Re: [julia-users] Re: how long until vectorized code runs fast?

[Steven G. Johnson]

On Thursday, May 12, 2016 at 8:51:44 AM UTC-4, Miguel Bazdresch wrote:
>
> honestly I've been testing out different devectorizations of my algorithms 
>> and I keep getting slower results, not faster, so either I really suck at 
>> writing for loops or Julia is doing a good job with my vectorized code.
>>
>
Make sure your loops are in a function — don't benchmark in global scope 
(see the performance tips sections of the manual).  Try running your 
function through @code_warntype myfunction(args...) and see if it warns 
marks any variables as type "ANY" (which indicates a type instability in 
your code, see the performance tips),

Also, if you do "@time myfunc(args...)" and it indicates that you did a 
huge number of allocations, you could either have a type instability or be 
allocating new arrays in your inner loops (it is always better to allocate 
arrays once outside your inner loops and then update them in-place as 
needed).

Re: [julia-users] Re: how long until vectorized code runs fast?

[Anonymous]

I did run it multiple times yes.  I've tried a couple different 
devectorizations on my algorithms and none result in speed ups, and most 
result in slightly slower run-times.  I guess I find it a bit strange 
because the memory allocations and garbage collection is *far less *when I 
devectorize, but that doesn't translate into performance improvements. 
 Also like I said before, I'm most curious about the current status of 
operations of the form:

[1 2; 3 4] .* [1 2]

is such an operation covered by BLAS?

On Thursday, May 12, 2016 at 5:58:22 AM UTC-7, Tim Holy wrote:
>
> Did you run it twice? Remember that memory is allocated during JIT 
> compilation, so the amount of memory on the first call is completely 
> meaningless. 
>
> --Tim 
>
> On Wednesday, May 11, 2016 11:03:38 PM Anonymous wrote: 
> > In response to both Kristoffer and Keno's timely responses, 
> > 
> > Originally I just did a simple @time test of the form 
> > Matrix .* horizontal vector 
> > 
> > and then tested the same thing with for loops, and the for loops were 
> way 
> > faster (and used way less memory) 
> > 
> > However I just devectorized one of my algorithms and ran an @time 
> > comparison and the vectorized version was actually twice as fast as the 
> > devectorized version, however the vectorized version used way more 
> memory. 
> >  Clearly I don't really understand the specifics of what makes code 
> slow, 
> > and in particular how vectorized code compares to devectorized code. 
> >  Vectorized code does seem to use a lot more memory, but clearly for my 
> > algorithm it nevertheless runs faster than the devectorized version.  Is 
> > there a reference I could look at that explains this to someone with a 
> > background in math but not much knowledge of computer architecture? 
> > 
> > On Wednesday, May 11, 2016 at 10:41:55 PM UTC-7, Keno Fischer wrote: 
> > > There seems to be a myth going around that vectorized code in Julia is 
> > > slow. That's not really the case. Often times it's just that 
> > > devectorized code is faster because one can manually perform 
> > > operations such as loop fusion, which the compiler cannot currently 
> > > reason about (and most C compilers can't either). In some other 
> > > languages those benefits get drowned out by language overhead, but in 
> > > julia those kinds of constructs are generally fast. The cases where 
> > > julia can be slower is when there is excessive memory allocation in a 
> > > tight inner loop, but those cases can usually be rewritten fairly 
> > > easily without losing the vectorized look of the code. 
> > > 
> > > On Thu, May 12, 2016 at 1:35 AM, Kristoffer Carlsson 
> > > 
> > > > wrote: 
> > > > It is always easier to discuss if there is a piece of code to look 
> at. 
> > > 
> > > Could 
> > > 
> > > > you perhaps post a few code examples that does not run as fast as 
> you 
> > > 
> > > want? 
> > > 
> > > > Also, make sure to look at : 
> > > > https://github.com/IntelLabs/ParallelAccelerator.jl. They have a 
> quite 
> > > > sophisticated compiler that does loop fusions and parallelization 
> and 
> > > 
> > > other 
> > > 
> > > > cool stuff. 
> > > > 
> > > > On Thursday, May 12, 2016 at 7:22:24 AM UTC+2, Anonymous wrote: 
> > > >> This remains one of the main drawbacks of Julia, and the 
> devectorize 
> > > >> package is basically useless as it doesn't support some really 
> crucial 
> > > >> vectorized operations.  I'd really prefer not to rewrite all my 
> > > 
> > > vectorized 
> > > 
> > > >> code into nested loops if at all possible, but I really need more 
> > > 
> > > speed, can 
> > > 
> > > >> anyone tell me the timeline and future plans for making vectorized 
> code 
> > > 
> > > run 
> > > 
> > > >> at C speed? 
>
>

[julia-users] Re: Julia large project example.

[Ford Ox]

I hope that chapter about healthy coding will be added into documentation.

Are plain .jl files with source code stored in julia home directory on my 
computer?

Re: [julia-users] Re: convert array elements

[Kristoffer Carlsson]

Try it in a function. Array comprehensions are a bit annoying that the 
results depend on the ability of type inference to figure out the result 
type. There is an issue tracking 
this: https://github.com/JuliaLang/julia/issues/7258

On Thursday, May 12, 2016 at 3:36:06 PM UTC+2, Michael Borregaard wrote:
>
> Awesome, thank you! I love the Julia 0.5 implementation. 
> PS. On my system ["$x" for x in ID] gives an Array{Any}, this seems to be 
> a general issue with array comprehensions.
>
> On Thu, May 12, 2016 at 12:38 PM, Steven G. Johnson  > wrote:
>
>>
>>
>> On Thursday, May 12, 2016 at 6:34:30 AM UTC-4, Michael Borregaard wrote:y 
>> - the 'easiest' way of doing this is 
>>>
>>> ID = [UTF8String("$x") for x in ID]
>>>
>>>
>> map(string, ID) converts all elements of ID to strings.   You could also 
>> use ["$x" for x in ID].   In Julia 0.5 you can do string.(ID)
>>
>
>

Re: [julia-users] Re: convert array elements

[Michael Krabbe Borregaard]

Awesome, thank you! I love the Julia 0.5 implementation.
PS. On my system ["$x" for x in ID] gives an Array{Any}, this seems to be a
general issue with array comprehensions.

On Thu, May 12, 2016 at 12:38 PM, Steven G. Johnson 
wrote:

>
>
> On Thursday, May 12, 2016 at 6:34:30 AM UTC-4, Michael Borregaard wrote:y
> - the 'easiest' way of doing this is
>>
>> ID = [UTF8String("$x") for x in ID]
>>
>>
> map(string, ID) converts all elements of ID to strings.   You could also
> use ["$x" for x in ID].   In Julia 0.5 you can do string.(ID)
>

Re: [julia-users] Re: documentation reversed order for multiple methods

[Igor Cerovsky]

Thanks Michael, the behavior you mentioned in 0.5 is what I've expected:
adding to docstrings using one double quotes pair shall add docstring after
previous method for given function, which is inside three double quotes
pair.

On 12 May 2016 at 13:42, Michael Hatherly  wrote:

> The ordering of docstrings in Julia 0.4 is based on the method
> signatures, which can sometimes not be all that obvious. They
> are not printed in a random order though. It’s best just to not
> rely on a specific order in 0.4.
>
> In 0.5 this order has been changed,
> https://github.com/JuliaLang/julia/pull/15266,
> to the definition order of the docstrings, which should be much
> less surprising.
>
> — Mike
> On Thursday, 12 May 2016 10:23:16 UTC+2, Igor Cerovsky wrote:
>>
>> Hello,
>>
>> Trying to write documentation according to Julia manual I've found
>> following reversed order of methods for given function; is that a bug?:
>> """
>> foo()
>>
>> I'm major foo...
>> """
>> function foo()
>> end
>>
>> "
>> foo(x)
>>
>> Here comes additional doc...
>> "
>> function foo(x)
>> end
>>
>> resulting documentation looks like:
>> help?> foo
>>   foo(x)
>>
>>   Here comes additional doc...
>>
>>   foo()
>>
>>   I'm major foo...
>>
>>
>>
>>

Re: [julia-users] Re: how long until vectorized code runs fast?

[Tim Holy]

Did you run it twice? Remember that memory is allocated during JIT 
compilation, so the amount of memory on the first call is completely 
meaningless.

--Tim

On Wednesday, May 11, 2016 11:03:38 PM Anonymous wrote:
> In response to both Kristoffer and Keno's timely responses,
> 
> Originally I just did a simple @time test of the form
> Matrix .* horizontal vector
> 
> and then tested the same thing with for loops, and the for loops were way
> faster (and used way less memory)
> 
> However I just devectorized one of my algorithms and ran an @time
> comparison and the vectorized version was actually twice as fast as the
> devectorized version, however the vectorized version used way more memory.
>  Clearly I don't really understand the specifics of what makes code slow,
> and in particular how vectorized code compares to devectorized code.
>  Vectorized code does seem to use a lot more memory, but clearly for my
> algorithm it nevertheless runs faster than the devectorized version.  Is
> there a reference I could look at that explains this to someone with a
> background in math but not much knowledge of computer architecture?
> 
> On Wednesday, May 11, 2016 at 10:41:55 PM UTC-7, Keno Fischer wrote:
> > There seems to be a myth going around that vectorized code in Julia is
> > slow. That's not really the case. Often times it's just that
> > devectorized code is faster because one can manually perform
> > operations such as loop fusion, which the compiler cannot currently
> > reason about (and most C compilers can't either). In some other
> > languages those benefits get drowned out by language overhead, but in
> > julia those kinds of constructs are generally fast. The cases where
> > julia can be slower is when there is excessive memory allocation in a
> > tight inner loop, but those cases can usually be rewritten fairly
> > easily without losing the vectorized look of the code.
> > 
> > On Thu, May 12, 2016 at 1:35 AM, Kristoffer Carlsson
> > 
> > > wrote:
> > > It is always easier to discuss if there is a piece of code to look at.
> > 
> > Could
> > 
> > > you perhaps post a few code examples that does not run as fast as you
> > 
> > want?
> > 
> > > Also, make sure to look at :
> > > https://github.com/IntelLabs/ParallelAccelerator.jl. They have a quite
> > > sophisticated compiler that does loop fusions and parallelization and
> > 
> > other
> > 
> > > cool stuff.
> > > 
> > > On Thursday, May 12, 2016 at 7:22:24 AM UTC+2, Anonymous wrote:
> > >> This remains one of the main drawbacks of Julia, and the devectorize
> > >> package is basically useless as it doesn't support some really crucial
> > >> vectorized operations.  I'd really prefer not to rewrite all my
> > 
> > vectorized
> > 
> > >> code into nested loops if at all possible, but I really need more
> > 
> > speed, can
> > 
> > >> anyone tell me the timeline and future plans for making vectorized code
> > 
> > run
> > 
> > >> at C speed?

Re: [julia-users] Re: how long until vectorized code runs fast?

[Miguel Bazdresch]

The easiest way to write slow for loops is to make them row-major instead
of column-major.

-- mb

On Thu, May 12, 2016 at 8:46 AM, Anonymous  wrote:

> So I guess the consensus is not that Julia's devectorized code is so much
> faster than its vectorized code (in fact I keep getting slow downs when I
> test out different devectorizations of my algorithms), but that R's
> devectorized code just sucks, either that or I really suck at writing for
> loops.
>
> honestly I've been testing out different devectorizations of my algorithms
> and I keep getting slower results, not faster, so either I really suck at
> writing for loops or Julia is doing a good job with my vectorized code.
>
> On Thursday, May 12, 2016 at 4:49:42 AM UTC-7, Stefan Karpinski wrote:
>>
>> On Thu, May 12, 2016 at 7:41 AM, Keno Fischer <
>> kfis...@college.harvard.edu> wrote:
>>
>>> There seems to be a myth going around that vectorized code in Julia is
>>> slow. That's not really the case. Often times it's just that
>>> devectorized code is faster because one can manually perform
>>> operations such as loop fusion, which the compiler cannot currently
>>> reason about (and most C compilers can't either). In some other
>>> languages those benefits get drowned out by language overhead, but in
>>> julia those kinds of constructs are generally fast. The cases where
>>> julia can be slower is when there is excessive memory allocation in a
>>> tight inner loop, but those cases can usually be rewritten fairly
>>> easily without losing the vectorized look of the code.
>>
>>
>> This. JMW's blog post on the subject is as relevant as when he wrote it:
>>
>>
>> http://www.johnmyleswhite.com/notebook/2013/12/22/the-relationship-between-vectorized-and-devectorized-code/
>>
>> Conclusion:
>>
>>- *Julia’s vectorized code is 2x faster than R’s vectorized code*
>>- Julia’s devectorized code is 140x faster than R’s vectorized code
>>- Julia’s devectorized code is 1350x faster than R’s devectorized code
>>
>> Julia's vectorized code is not slow – it's faster than other languages.
>> It's just that Julia allows you to write even faster code when it matters.
>>
>

Re: [julia-users] Re: how long until vectorized code runs fast?

[Anonymous]

So the consensus is not that Julia's devectorized code is so much faster 
than its vectorized code (in fact I keep getting slow-downs when I test out 
various devectorizations of my algorithms), but that R's devectorized code 
just sucks.

On Thursday, May 12, 2016 at 4:49:42 AM UTC-7, Stefan Karpinski wrote:
>
> On Thu, May 12, 2016 at 7:41 AM, Keno Fischer  > wrote:
>
>> There seems to be a myth going around that vectorized code in Julia is
>> slow. That's not really the case. Often times it's just that
>> devectorized code is faster because one can manually perform
>> operations such as loop fusion, which the compiler cannot currently
>> reason about (and most C compilers can't either). In some other
>> languages those benefits get drowned out by language overhead, but in
>> julia those kinds of constructs are generally fast. The cases where
>> julia can be slower is when there is excessive memory allocation in a
>> tight inner loop, but those cases can usually be rewritten fairly
>> easily without losing the vectorized look of the code.
>
>
> This. JMW's blog post on the subject is as relevant as when he wrote it:
>
>
> http://www.johnmyleswhite.com/notebook/2013/12/22/the-relationship-between-vectorized-and-devectorized-code/
>
> Conclusion:
>
>- *Julia’s vectorized code is 2x faster than R’s vectorized code*
>- Julia’s devectorized code is 140x faster than R’s vectorized code
>- Julia’s devectorized code is 1350x faster than R’s devectorized code
>
> Julia's vectorized code is not slow – it's faster than other languages. 
> It's just that Julia allows you to write even faster code when it matters.
>

Re: [julia-users] Re: how long until vectorized code runs fast?

[Anonymous]

So I guess the consensus is not that Julia's devectorized code is so much 
faster than its vectorized code (in fact I keep getting slow downs when I 
test out different devectorizations of my algorithms), but that R's 
devectorized code just sucks, either that or I really suck at writing for 
loops.

honestly I've been testing out different devectorizations of my algorithms 
and I keep getting slower results, not faster, so either I really suck at 
writing for loops or Julia is doing a good job with my vectorized code.

On Thursday, May 12, 2016 at 4:49:42 AM UTC-7, Stefan Karpinski wrote:
>
> On Thu, May 12, 2016 at 7:41 AM, Keno Fischer  > wrote:
>
>> There seems to be a myth going around that vectorized code in Julia is
>> slow. That's not really the case. Often times it's just that
>> devectorized code is faster because one can manually perform
>> operations such as loop fusion, which the compiler cannot currently
>> reason about (and most C compilers can't either). In some other
>> languages those benefits get drowned out by language overhead, but in
>> julia those kinds of constructs are generally fast. The cases where
>> julia can be slower is when there is excessive memory allocation in a
>> tight inner loop, but those cases can usually be rewritten fairly
>> easily without losing the vectorized look of the code.
>
>
> This. JMW's blog post on the subject is as relevant as when he wrote it:
>
>
> http://www.johnmyleswhite.com/notebook/2013/12/22/the-relationship-between-vectorized-and-devectorized-code/
>
> Conclusion:
>
>- *Julia’s vectorized code is 2x faster than R’s vectorized code*
>- Julia’s devectorized code is 140x faster than R’s vectorized code
>- Julia’s devectorized code is 1350x faster than R’s devectorized code
>
> Julia's vectorized code is not slow – it's faster than other languages. 
> It's just that Julia allows you to write even faster code when it matters.
>

[julia-users] Re: Julia large project example.

[Steven G. Johnson]

The largest Julia project is currently Julia itself, which is mostly 
written in Julia.

Re: [julia-users] loop-else

[Ford Ox]

Java ( C, C++, etc) approach has another bonus. You can check both whether 
loop :


   1. *finished*
   2. *did not finish*
   3. *did not run at all*


Dne čtvrtek 12. května 2016 13:46:20 UTC+2 Ford Ox napsal(a):
>
> Go for loop-nobreak then :)
>
> In java you can create nobreak statement like this:
> int i;
> for(i=0; i < 100; i++) {if(...) break;}
> if(i == 100) System.out.println("The loop finished without breaking")
>
> Which has no more side effects but bringing "i" into outer scope ( julia 
> does this anyway ). I am not so sure about goto side effects tho!
>
>
> Dne čtvrtek 12. května 2016 13:27:57 UTC+2 Stefan Karpinski napsal(a):
>>
>> IIRC, the issue with this was that the Python meaning is pretty 
>> unintuitive (but sometimes useful) and having this syntax but having it 
>> mean something else (more intuitive) seems like causing unnecessary 
>> confusion for people coming from Python, hence the lack of movement. 
>> Arguably, the Python meaning is less confusing to express with gotos and 
>> labels.
>>
>> On Wed, May 11, 2016 at 3:49 PM, Isaiah Norton  
>> wrote:
>>
>>> That issue is marked as a 1.0 milestone, which should be interpreted as 
>>> "decision before 1.0" in this case. But clearly a low priority.
>>>
>>> On Wed, May 11, 2016 at 5:26 AM, Ford Ox  wrote:
>>>
 Will loop-else python like syntax be implemented in future? I have read 
 this  topic, but no 
 statement has been made.

>>>
>>>
>>

Re: [julia-users] Re: Getting into macros nightmare!

[Didier Verna]

Stefan Karpinski wrote:

> Didier, since you definitely have a better handle on what macro
> hygiene means to someone coming from Lisp, would you consider editing
> that text to clarify that point?

  OK (I think I had another request for an update in the manual
  somewhere else as well).

-- 
ELS'16, May 9-10, Krakow, Poland: http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Cannot readandwrite from same process

[f . griese12345]

I've tried the following Example 

julia> (so,si,pr)=readandwrite(`cat`)
(Pipe(closed => open, 0 bytes waiting),Pipe(open => open, 0 bytes 
waiting),Process(`cat`, ProcessRunning))

julia> write(si,"hallo")
5

julia> so
Pipe(closed => open, 0 bytes waiting)

julia> si
Pipe(open => open, 0 bytes waiting)

julia> pr
Process(`cat`, ProcessRunning)

from http://blog.leahhanson.us/post/julia/julia-commands.html

but I would expect

julia> so
Pipe(closed => open, 5 bytes waiting)

What am I doing wrong?

In this Example one has to close the inStream "si", is there a way to read 
and write from "so" and "si" while keeping them open?

Re: [julia-users] Re: how long until vectorized code runs fast?

[Stefan Karpinski]

On Thu, May 12, 2016 at 7:41 AM, Keno Fischer 
wrote:

> There seems to be a myth going around that vectorized code in Julia is
> slow. That's not really the case. Often times it's just that
> devectorized code is faster because one can manually perform
> operations such as loop fusion, which the compiler cannot currently
> reason about (and most C compilers can't either). In some other
> languages those benefits get drowned out by language overhead, but in
> julia those kinds of constructs are generally fast. The cases where
> julia can be slower is when there is excessive memory allocation in a
> tight inner loop, but those cases can usually be rewritten fairly
> easily without losing the vectorized look of the code.


This. JMW's blog post on the subject is as relevant as when he wrote it:

http://www.johnmyleswhite.com/notebook/2013/12/22/the-relationship-between-vectorized-and-devectorized-code/

Conclusion:

   - *Julia’s vectorized code is 2x faster than R’s vectorized code*
   - Julia’s devectorized code is 140x faster than R’s vectorized code
   - Julia’s devectorized code is 1350x faster than R’s devectorized code

Julia's vectorized code is not slow – it's faster than other languages.
It's just that Julia allows you to write even faster code when it matters.

Re: [julia-users] loop-else

[Ford Ox]

Go for loop-nobreak then :)

In java you can create nobreak statement like this:
int i;
for(i=0; i < 100; i++) {if(...) break;}
if(i == 100) System.out.println("The loop finished without breaking")

Which has no more side effects but bringing "i" into outer scope ( julia 
does this anyway ). I am not so sure about goto side effects tho!


Dne čtvrtek 12. května 2016 13:27:57 UTC+2 Stefan Karpinski napsal(a):
>
> IIRC, the issue with this was that the Python meaning is pretty 
> unintuitive (but sometimes useful) and having this syntax but having it 
> mean something else (more intuitive) seems like causing unnecessary 
> confusion for people coming from Python, hence the lack of movement. 
> Arguably, the Python meaning is less confusing to express with gotos and 
> labels.
>
> On Wed, May 11, 2016 at 3:49 PM, Isaiah Norton  > wrote:
>
>> That issue is marked as a 1.0 milestone, which should be interpreted as 
>> "decision before 1.0" in this case. But clearly a low priority.
>>
>> On Wed, May 11, 2016 at 5:26 AM, Ford Ox 
>> > wrote:
>>
>>> Will loop-else python like syntax be implemented in future? I have read 
>>> this  topic, but no 
>>> statement has been made.
>>>
>>
>>
>

Re: [julia-users] following down the chain of dispatch

[Stefan Karpinski]

I cannot emphasize enough how nice this is.

On Wed, May 11, 2016 at 11:21 PM, Kristoffer Carlsson  wrote:

> If you get Gallium https://github.com/Keno/Gallium.jl working you can
> simply step through the functions.

Re: [julia-users] Error while loading packages

[hililielala16]

Yes, in ...\etc\julia on file juliarc.jl by doing ENV["JULIA_PKGDIR"] = 
joinpath(JULIA_HOME,"..",".julia")

Thank you very much Tony Kelman, I think now it is fine! 

H

Le jeudi 12 mai 2016 12:42:47 UTC+2, Tony Kelman a écrit :
>
> Did you set the JULIA_PKGDIR environment variable? If so, where? There's a 
> separate julia variable used for the cache path, you may need to 
> unshift!(Base.LOAD_CACHE_PATH, 
> Pkg.dir("..","lib","v$(VERSION.major).$(VERSION.minor)"))

Re: [julia-users] Re: Getting into macros nightmare!

[Stefan Karpinski]

Didier, since you definitely have a better handle on what macro hygiene
means to someone coming from Lisp, would you consider editing that text to
clarify that point?

On Thu, May 12, 2016 at 12:04 PM, Didier Verna 
wrote:

> Ford Ox  wrote:
>
> > I have kinda skipped the hygiene chapter in docs :)
>
>   The docs can unfortunately also be a source of confusion. In that
>   particular case, contrary to what it says, the macros in Julia are
>   only half-hygienic, and esc is a means to restore hygiene, not
>   "violate" it.
>
> --
> ELS'16, May 9-10, Krakow, Poland: http://www.european-lisp-symposium.org
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info
>

[julia-users] Re: documentation reversed order for multiple methods

[Michael Hatherly]

The ordering of docstrings in Julia 0.4 is based on the method
signatures, which can sometimes not be all that obvious. They
are not printed in a random order though. It’s best just to not
rely on a specific order in 0.4.

In 0.5 this order has been changed, 
https://github.com/JuliaLang/julia/pull/15266,
to the definition order of the docstrings, which should be much
less surprising.

— Mike
On Thursday, 12 May 2016 10:23:16 UTC+2, Igor Cerovsky wrote:
>
> Hello,
>
> Trying to write documentation according to Julia manual I've found 
> following reversed order of methods for given function; is that a bug?:
> """
> foo()
> 
> I'm major foo...
> """
> function foo()
> end
>
> "
> foo(x)
> 
> Here comes additional doc...
> "
> function foo(x)
> end
>
> resulting documentation looks like:
> help?> foo
>   foo(x)
>
>   Here comes additional doc...
>
>   foo()
>
>   I'm major foo...
>
>
>
>

[julia-users] Re: Package Documentation Tools

[Michael Hatherly]

Yes, that’s how things currently work. LaTeX output and HTML
without using MkDocs will be added at some point, not in the
initial 0.1 release, but probably 0.2.

If anyone runs into any problems feel free to open an issue in
the repo — I don’t check the mailing list all that often.
​

— Mike
​
On Wednesday, 11 May 2016 19:05:19 UTC+2, Chris Rackauckas wrote:
>
> Oh okay. So you just make docstrings (which can have LaTeX and support 
> REPL help) and then Documenter.jl can convert them into Markdown files 
> which mkdocs can convert into HTML documentation (with which I can choose a 
> different theme)? I think I got this now.
>
> On Wednesday, May 11, 2016 at 9:33:57 AM UTC-7, Tommy Hofmann wrote:
>>
>> Do you also want to support the repl help system? By this I mean, do you 
>> want to do the following also for your custom functions/types?
>>
>> help?> BigInt
>> search: BigInt disable_sigint reenable_sigint set_bigfloat_precision
>>
>>   BigInt(x)
>>
>>   Create an arbitrary precision integer. x may be an Int (or anything 
>> that can
>>   be converted to an Int). The usual mathematical operators are defined 
>> for
>>   this type, and results are promoted to a BigInt.
>>
>>   Instances can be constructed from strings via parse, or using the big 
>> string
>>   literal.
>>
>> help?> gcd
>> search: gcd gcdx gc_disable significand
>>
>>   gcd(x,y)
>>
>>   Greatest common (positive) divisor (or zero if x and y are both zero).
>>
>> These are coming from the docstrings attached to the types/function (see 
>> http://docs.julialang.org/en/release-0.4/manual/documentation/). As far 
>> as I know they have to be written in Markdown. I do not know how well 
>> Sphinx and Markdown work together (Sphinx usually uses files in 
>> reStructuredText (rst) format).
>>
>> On Wednesday, May 11, 2016 at 6:10:06 PM UTC+2, Chris Rackauckas wrote:
>>>
>>> Thanks for the link. I'll look into using Documenter.jl + mkdocs. Is 
>>> there anyway that the format can match something like Sphinx/MakeTheDocs (I 
>>> don't really know what that is)? I like that look much better; the font 
>>> from the Documenter.jl examples is wonky and hard to read.
>>>
>>> On Wednesday, May 11, 2016 at 9:01:48 AM UTC-7, Tommy Hofmann wrote:

 What about this post?

 https://groups.google.com/forum/#!searchin/julia-users/documentation/julia-users/q7rwopVQHV4/o-mDXpqhAwAJ
 Note that instead of Lexicon.jl one should use Documenter.jl but the 
 workflow is similar.

 Documenter.jl provides an easy way to combine docstrings and manually 
 written Markdown files. At the end of the day one gets mkdocs 
 documentations, which can be deployed to readthedocs, but you can also 
 produce a pdf using https://github.com/jgrassler/mkdocs-pandoc.

 Documenter.jl itself has nothing to do with LaTeX or not. No one 
 prevents you from using LaTeX in your dostrings or Markdown files.


 On Wednesday, May 11, 2016 at 5:20:36 PM UTC+2, Chris Rackauckas wrote:
>
> Forgot to mentioned that LaTeX is a requirement. I don't see any LaTeX 
> in Documenter.jl
>
> On Wednesday, May 11, 2016 at 7:42:34 AM UTC-7, Kristoffer Carlsson 
> wrote:
>>
>> https://github.com/MichaelHatherly/Documenter.jl with its 
>> documentation http://michaelhatherly.github.io/Documenter.jl/latest/ 
>> is good imo.
>>
>> You can look at packages that are using Documenter here: 
>> http://michaelhatherly.github.io/Documenter.jl/latest/man/examples/
>>
>> On Wednesday, May 11, 2016 at 4:04:58 PM UTC+2, Chris Rackauckas 
>> wrote:
>>>
>>> Hi,
>>>   I was wondering if there's any documentation/tutorials for 
>>> generating documentation for Julia packages. I would like to make one 
>>> of 
>>> those Read the Docs things but I don't know where to start (or if 
>>> that's 
>>> still the preferred method) and a quick Google / Julia-users search 
>>> didn't 
>>> hit a result.
>>>
>>

Re: [julia-users] Re: Documentation generators for Julia?

[Stefan Karpinski]

It seems like it will be a Julia flavor of Markdown.

On Thu, May 12, 2016 at 1:35 PM, kleinsplash 
wrote:

> Hi,
>
> Any chance there is a consensus on which document generation platform will
> be the standard? So that if I start writing and comments then later
> compiling will allow document generation:
>
> http://www.stack.nl/~dimitri/doxygen/
> http://www.sphinx-doc.org/en/stable/contents.html
> https://www.statistik.lmu.de/~leisch/Sweave/
> https://github.com/mpastell/Weave.jl
>
> I am trying to find a simple across protocal language, working with ROS
> there tends to be python, c, c++, julia and lua possibly R. So is there
> something that works regardless?
>
> -Thx
>
>
> On Monday, 6 May 2013 15:57:04 UTC+2, Amuthan A. Ramabathiran wrote:
>
>> Hello,
>>
>> I'm looking for documentation generators that can extract documentation
>> from a Julia code (similar to Doxygen). I tried using sphinx, but have not
>> been able to do the comment extraction part (its pretty cool otherwise).
>> Any pointers on this?
>>
>> (I tried jocco too, but haven't been so successful with it.)
>>
>> Thanks,
>> Amuthan.
>>
>

[julia-users] Re: Documentation generators for Julia?

[kleinsplash]

Hi,

Any chance there is a consensus on which document generation platform will 
be the standard? So that if I start writing and comments then later 
compiling will allow document generation: 

http://www.stack.nl/~dimitri/doxygen/
http://www.sphinx-doc.org/en/stable/contents.html
https://www.statistik.lmu.de/~leisch/Sweave/
https://github.com/mpastell/Weave.jl

I am trying to find a simple across protocal language, working with ROS 
there tends to be python, c, c++, julia and lua possibly R. So is there 
something that works regardless? 

-Thx


On Monday, 6 May 2013 15:57:04 UTC+2, Amuthan A. Ramabathiran wrote:
>
> Hello,
>
> I'm looking for documentation generators that can extract documentation 
> from a Julia code (similar to Doxygen). I tried using sphinx, but have not 
> been able to do the comment extraction part (its pretty cool otherwise). 
> Any pointers on this?
>
> (I tried jocco too, but haven't been so successful with it.)
>
> Thanks,
> Amuthan.
>

Re: [julia-users] loop-else

[Stefan Karpinski]

IIRC, the issue with this was that the Python meaning is pretty unintuitive
(but sometimes useful) and having this syntax but having it mean something
else (more intuitive) seems like causing unnecessary confusion for people
coming from Python, hence the lack of movement. Arguably, the Python
meaning is less confusing to express with gotos and labels.

On Wed, May 11, 2016 at 3:49 PM, Isaiah Norton 
wrote:

> That issue is marked as a 1.0 milestone, which should be interpreted as
> "decision before 1.0" in this case. But clearly a low priority.
>
> On Wed, May 11, 2016 at 5:26 AM, Ford Ox  wrote:
>
>> Will loop-else python like syntax be implemented in future? I have read
>> this  topic, but no
>> statement has been made.
>>
>
>

[julia-users] Re: Declaration of types in function construction...

[Gunnar Farnebäck]

Your problem is probably that you try to call your function with four 
positional arguments, although the last two should have been named. Compare

julia> f(x, y; z=0) = x + y + z
f (generic function with 1 method)

julia> f(2, 3)
5

julia> f(2, 3, 4)
ERROR: MethodError: `f` has no method matching f(::Int64, ::Int64, ::Int64)
Closest candidates are:
  f(::Any, ::Any)

julia> f(2, 3, z = 4)
9

Den torsdag 12 maj 2016 kl. 12:51:13 UTC+2 skrev Charles Ll:
>
> Dear all,
>
> There is something I did not understood well in Julia regarding the type 
> fo the variables and this creates difficulties with the functions I am 
> writing.
>
> For one of the functions of Spectra.jl package, I wrote for instance: 
>
> function gaussianarea(Amplitude::Array{Float64},HWHM::Array{Float64}; 
> eseAmplitude::Array{Float64} = 0, eseHWHM::Array{Float64} = 0)
>
> I was thinking that using the ::Array{Float64} will allow users to enter 
> either vectors or arrays. However, when I try to enter a vectors for 
> Amplitude or HWHM for instance, I get the following error:
>
> LoadError: MethodError: `gaussianarea` has no method matching 
> gaussianarea(::Array{Float64,1}, ::Array{Float64,1}, ::Array{Float64,1}, 
> ::Array{Float64,1})
> Closest candidates are:
>   gaussianarea(::Array{Float64,N}, ::Array{Float64,N})
> while loading In[46], in expression starting on line 9
>
>
> I'm quite disappointed by that and don't know how to avoid it... Because 
> for me a vector is an Array {Float64,1}... But the above message says no?
>
> What did I miss here? 
>

Re: [julia-users] Anonymous Function Behavior

[Stefan Karpinski]

This compilation cost is proportional to the amount of code you type into
the REPL or editor, which is modest and very limited (unless you're
generating code). I understand why it might be of interest and worth
noting, but is there an actual problem? 50 milliseconds is well below the
threshold of what is considered perceptually instantaneous.

On Wed, May 11, 2016 at 2:00 PM, Yichao Yu  wrote:

> On Wed, May 11, 2016 at 5:13 AM, Andras Niedermayer
>  wrote:
> > BTW, it does work if you put it into a function rather than running it in
> > global scope:
> > julia> test(y) = map(x->10^x, y)
> > test (generic function with 1 method)
> >
> > julia> @time test(a);
> >   0.003387 seconds (4.34 k allocations: 97.662 KB)
> >
> > julia> @time test(a);
> >   0.000440 seconds (4.01 k allocations: 78.422 KB)
> >
> > This is related to
> >
> http://docs.julialang.org/en/release-0.4/manual/performance-tips/#avoid-global-variables
>
> No it's not.
> The use of global variable only affect top level code (i.e. the call
> of `map`) which basically takes no time at all.
> It works for this case for the same reason I mentioned above. The
> lambda used in both cases are the same one so no recompilation is
> needed.
>
> >
> >
> >
> > On Tuesday, May 10, 2016 at 9:03:26 PM UTC+2, Yichao Yu wrote:
> >>
> >> On Tue, May 10, 2016 at 2:22 PM,   wrote:
> >> > Watch this.
> >> >
> >> > We define an array:
> >> > a = collect(-1:0.001:1)
> >> >
> >> > Then map something over the aforementioned array for the first time:
> >> > @time map(x->10^x, a)
> >> > # 0.049258 seconds
> >> >
> >> > Do it again so that we don't capture JIT compilation time:
> >>
> >> This doesn't work
> >>
> >> > @time map(x->10^x, a)
> >>
> >> Since this is a different anonymous function.
> >>
> >> > # 0.048793 seconds -- didn't change much
> >> >
> >> > Now we assign the anonymous function to a variable:
> >> > f = x->10^x
> >> >
> >> > Then we map the variable over the array:
> >> > @time map(f, a)
> >> > # 0.047853 seconds
> >> >
> >> > Again so that we avoid JIT:
> >>
> >> It works this time
> >>
> >> > @time map(f, a)
> >>
> >> Since this is the same anonymous function
> >>
> >> > # 0.000386 seconds -- wow
> >> >
> >> > What is happening here?
> >> > Why does assigning an anonymous function to a variable makes the
> >> > function
> >> > execution so much faster?
> >> >
> >> >
> >> > Yousef
>

[julia-users] Re: ANN: julia-spectral group created for discussions/questions related to spectral methods and ApproxFun in Julia

[Paulo Jabardo]

Link: https://groups.google.com/forum/?fromgroups=#!forum/julia-spectral


On Wednesday, May 11, 2016 at 9:54:08 PM UTC-3, Sheehan Olver wrote:
>
>
> I've created a Google group julia-spectral for any discussions/questions 
> related to spectral methods.  In particular, this can serve as a place to 
> ask questions related to ApproxFun (to avoid spamming the julia-users 
> group).
>
> Sheehan
>

[julia-users] Declaration of types in function construction...

[Charles Ll]

Dear all,

There is something I did not understood well in Julia regarding the type fo 
the variables and this creates difficulties with the functions I am writing.

For one of the functions of Spectra.jl package, I wrote for instance: 

function gaussianarea(Amplitude::Array{Float64},HWHM::Array{Float64}; 
eseAmplitude::Array{Float64} = 0, eseHWHM::Array{Float64} = 0)

I was thinking that using the ::Array{Float64} will allow users to enter 
either vectors or arrays. However, when I try to enter a vectors for 
Amplitude or HWHM for instance, I get the following error:

LoadError: MethodError: `gaussianarea` has no method matching 
gaussianarea(::Array{Float64,1}, ::Array{Float64,1}, ::Array{Float64,1}, 
::Array{Float64,1})
Closest candidates are:
  gaussianarea(::Array{Float64,N}, ::Array{Float64,N})
while loading In[46], in expression starting on line 9


I'm quite disappointed by that and don't know how to avoid it... Because 
for me a vector is an Array {Float64,1}... But the above message says no?

What did I miss here? 

Re: [julia-users] Error while loading packages

[Tony Kelman]

Did you set the JULIA_PKGDIR environment variable? If so, where? There's a 
separate julia variable used for the cache path, you may need to 
unshift!(Base.LOAD_CACHE_PATH, 
Pkg.dir("..","lib","v$(VERSION.major).$(VERSION.minor)"))

[julia-users] Re: convert array elements

[Steven G. Johnson]

On Thursday, May 12, 2016 at 6:34:30 AM UTC-4, Michael Borregaard wrote:y - 
the 'easiest' way of doing this is 
>
> ID = [UTF8String("$x") for x in ID]
>
>
map(string, ID) converts all elements of ID to strings.   You could also 
use ["$x" for x in ID].   In Julia 0.5 you can do string.(ID)

[julia-users] convert array elements

[Michael Borregaard]

I am trying to convert from R to Julia, as i really like Julia and the nice 
development going on here. But there are certain operations that are a lot 
more complicated to do in Julia, even though they are mainstay (I will do 
the several times every day). But I am in doubt if I just don't know hwo to 
do them properly in Julia. 
One of them is converting array elements - say for example I have sample 
plot names - often they are listed in data files as ASCIIString or 
UTF8String (depending on the nationality of collaborators), and often they 
are just integers. In R I would treat them all as string:
ID <- as.character(ID)

and get on with my life. In Julia this does not sound so easy - the 
'easiest' way of doing this is 
ID = [UTF8String("$x") for x in ID]

Are there ideomatic ways of converting array elements? I would believe so, 
as this is so often used by people who work with data.

Thanks!

[julia-users] Re: Julia large project example.

[Ford Ox]

Well,  the minesweeper was indeed a bad decision.  I am looking for project 
with at least 5 modules. 

Re: [julia-users] Re: Getting into macros nightmare!

[Didier Verna]

Ford Ox  wrote:

> I have kinda skipped the hygiene chapter in docs :)

  The docs can unfortunately also be a source of confusion. In that
  particular case, contrary to what it says, the macros in Julia are
  only half-hygienic, and esc is a means to restore hygiene, not
  "violate" it.

-- 
ELS'16, May 9-10, Krakow, Poland: http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] switch superior

[Páll Haraldsson]

On Monday, May 9, 2016 at 6:10:40 AM UTC, Tamas Papp wrote:
>
> Was there more recent discussion about switch? I think I missed it, last 
> thing I am aware of is #5410. And of course see Switch.jl.
>

I took a look, and it implements C-style switch with its pros/features 
(mainly if you are translating C-code line-by-line) and cons. While I find 
it great that implementing switch (and match) with macros in Julia is 
possible, I also see at:

https://github.com/JuliaLang/julia/issues/5410

that Go's switch fixed C's "software engineering"-mistakes (still OO 
polymorphism and Julia's multiple dispatch is also the alternative), with 
"fallback"-keywords still allowing "Duff's device" (fast code).

Something like:

https://github.com/kmsquire/Match.jl

should be emphasized over switch.

-- 
Palli.


> In any case, I find the proposed syntax a bit obscure and 
> complicated. I would prefer using the result of 
>
> findfirst(x->input % x == 0,[2,3,5,7]) 
>
> or if that does not help, then explicit currying, 
>
> input = 119 
> let d(x) = input % x == 0 
> if d(2) 
> # code 
> elseif d(3) 
> # code 
> elseif d(5) 
> # code 
> elseif d(7) 
> # code 
> end 
> end 
>
> Best, 
>
> Tamas 
>
>
>
> On Mon, May 09 2016, Ford Ox wrote: 
>
> > I have a little suggestion: If julia is going to have switch, could we 
> make it a bit better? 
> > 
> > Basically the switch would take two parameters : function and variable. 
> On each case it would would 
> > call the function with those two params, and if the functions would 
> return true, it would evaluate the case 
> > block. 
> > 
> > Note: the function has to return boolean. 
> > 
> > Example 
> > 
> > function divides(a, b) 
> >   return a % b == 0 
> > end 
> > 
> > input = 119 
> > switch(divides, input) 
> >   case 2 # this can be translated as ~ if(divides(input, 2)) 
> >   case 3 # 3 divides input without remainder 
> >   case 5 # 5 divides input without remainder 
> >   case 7 # 7 divides input without remainder 
> > end 
> > 
> > Of course you could achieve the default switch behavior like this: 
> > switch(==, input) 
> > ... 
> > 
> > What do you think about it? 
>

[julia-users] Re: Julia large project example.

[Páll Haraldsson]

On Thursday, May 12, 2016 at 8:45:47 AM UTC, Ford Ox wrote:
>
> I have searched docs but didn't find any info on this.
>
> *How should one structure larger project (say minesweeper) with data 
> encapsulation on mind?*
>

Funny you should mention Minesweeper and "larger" in the same sentence, as 
the 80-line Minesweeper in my favorite example of concise Julia code to 
show:

http://escher-jl.org/ *

https://github.com/shashi/Escher.jl

This includes all the code (excluding this generic library, and 
dependencies), and doesn't need JavaScript, HTML, CSS..


In general, similar to Python, you can access data members of your types 
(classes in Python), and there is no "private" as in C++ (or "protected", 
that wouldn't apply here), but it's bad practice to do that.

There are very large Julia projects, so this is not a hindrance. See also:

https://en.wikipedia.org/wiki/Composition_over_inheritance


* Very strangely, the website comes up, then turns blank, at least in 
Firefox. I believed I had screwed up, something in the browser, with some 
add-on, but in fact, I happened to get a new machine, and now have a clean 
profile. This used to work..

 

>
>
> Do you have link to any existing project, or could you provide an 
> interface or graph, showing, how would you implement ^?
>
>
> All projects I have written so far, feel like a mess (* pretty much like 
> android app developing* :P ).
>

Re: [julia-users] Error while loading packages

[hililielala16]

Hello Yichao Yu,

The system is a Windows 7 enterprise, 64bits
No, I did not touch it. Here is what i see when I show the directories in 
.julia


Le mercredi 11 mai 2016 14:26:36 UTC+2, Yichao Yu a écrit :
>
> On Wed, May 11, 2016 at 4:52 AM,  > 
> wrote: 
> > Hello, 
> > 
> > I had instaled Julia and it was working perfectly last week. However, 
> since 
> > 10 days it is working perfectly each 2 days. The days it is not perfect 
> I 
> > can not use any package. When I try to load anyone I have the following 
> > message: 
> > 
> > using DataFrames 
> > INFO: Precompiling module DataFrames... 
> > Error: SystemError: mkdir: No such file or directory in mkdir at 
> file.jl:42 
> > 
> > using JuMP 
> > INFO: Precompiling module JuMP... 
> > Error: SystemError: mkdir: No such file or directory in mkdir at 
> file.jl:42 
> > 
> > And this happens for all the packages I try to load!!! 
> > 
> > Thank you if someone can help. 
>
> What's your system? 
> What's in your `~/.julia` (or corresponding package/cache dir on other 
> systems), have you done anything to it? 
>
> > 
> > 
>

[julia-users] Re: documentation reversed order for multiple methods

[Ford Ox]

You have two methods for function foo, so you will get two docs out of 
help. Since you don't specify what method are you looking for, don't be 
surprised julia doesn't care either and prints out their docs in reverse 
(possibly even random) order...


Dne čtvrtek 12. května 2016 10:23:16 UTC+2 Igor Cerovsky napsal(a):
>
> Hello,
>
> Trying to write documentation according to Julia manual I've found 
> following reversed order of methods for given function; is that a bug?:
> """
> foo()
> 
> I'm major foo...
> """
> function foo()
> end
>
> "
> foo(x)
> 
> Here comes additional doc...
> "
> function foo(x)
> end
>
> resulting documentation looks like:
> help?> foo
>   foo(x)
>
>   Here comes additional doc...
>
>   foo()
>
>   I'm major foo...
>
>
>
>

[julia-users] Julia large project example.

[Ford Ox]

I have searched docs but didn't find any info on this.

*How should one structure larger project (say minesweeper) with data 
encapsulation on mind?*

Do you have link to any existing project, or could you provide an interface 
or graph, showing, how would you implement ^?


All projects I have written so far, feel like a mess (* pretty much like 
android app developing* :P ).

[julia-users] documentation reversed order for multiple methods

[Igor Cerovsky]

Hello,

Trying to write documentation according to Julia manual I've found 
following reversed order of methods for given function; is that a bug?:
"""
foo()

I'm major foo...
"""
function foo()
end

"
foo(x)

Here comes additional doc...
"
function foo(x)
end

resulting documentation looks like:
help?> foo
  foo(x)

  Here comes additional doc...

  foo()

  I'm major foo...

Re: [julia-users] Optimization

[Ford Ox]

Would it be possible (and worth) to parse julia into lambda calculus, 
similar to morte 

?

Dne středa 11. května 2016 14:43:37 UTC+2 Tim Holy napsal(a):
>
> You don't really need to read LLVM to get the gist; just count the "mul"s 
> and 
> note that there are no calls to a general "pow" function. ("ret" means 
> return, 
> "i64" means Int64, %n refers to variable n) 
>
> Optimization is a hard problem in general (google "sufficiently smart 
> compiler"). But more can be done, and certainly we'd love your help making 
> julia's compiler better. 
>
> https://github.com/JuliaLang/julia/issues/3440 is a good issue for 
> getting 
> oriented. It's not guaranteed to be up to date; I see a couple of places 
> where 
> I think the box could be checked. 
>
> Best, 
> --Tim 
>
>
> On Wednesday, May 11, 2016 05:28:08 AM Ford Ox wrote: 
> > Sadly I don't understand llvm language. 
> > Is that problem of optimization in general or is it just specific for 
> llvm? 
> > It would be not so hard to write special code optimizer in julia itself 
> I 
> > guess (I have made one (quite simple - tho it was capable of optimizing 
> > both examples and much more) in python and it was not even hard). 
> > 
> > Dne středa 11. května 2016 13:48:11 UTC+2 Tim Holy napsal(a): 
> > > You might find this to be a fun example of how simple-seeming 
> > > optimizations can 
> > > be much more trouble than you might expect. 
> > > 
> > > For _years_, in Matlab (and perhaps other languages), x^2 was much, 
> much 
> > > slower than x*x. You might think it's surprising that a company with 
> > > Mathworks' resources couldn't fix this for so long. In Julia we 
> optimize 
> > > it: 
> > > 
> > > julia> foo1(x) = x*x 
> > > foo1 (generic function with 1 method) 
> > > 
> > > julia> foo2(x) = x^2 
> > > foo2 (generic function with 1 method) 
> > > 
> > > julia> foo3(x) = x^3 
> > > foo3 (generic function with 1 method) 
> > > 
> > > julia> @code_llvm foo1(5) 
> > > 
> > > define i64 @julia_foo1_21463(i64) { 
> > > 
> > > top: 
> > >   %1 = mul i64 %0, %0 
> > >   ret i64 %1 
> > > 
> > > } 
> > > 
> > > julia> @code_llvm foo2(5) 
> > > 
> > > define i64 @julia_foo2_21471(i64) { 
> > > 
> > > top: 
> > >   %1 = mul i64 %0, %0 
> > >   ret i64 %1 
> > > 
> > > } 
> > > 
> > > julia> @code_llvm foo3(5) 
> > > 
> > > define i64 @julia_foo3_21472(i64) { 
> > > 
> > > top: 
> > >   %1 = mul i64 %0, %0 
> > >   %2 = mul i64 %1, %0 
> > >   ret i64 %2 
> > > 
> > > } 
> > > 
> > > ("mul" means multiply, which means it's expanding x^3 as (x*x)*x.) 
> > > 
> > > BUT, this seemingly-trivial optimization proved to be a lot of hassle: 
> see 
> > > https://github.com/JuliaLang/julia/issues/6506 
> > > and the discussions that preceded it. 
> > > 
> > > Best, 
> > > --Tim 
> > > 
> > > On Wednesday, May 11, 2016 02:34:56 AM Ford Ox wrote: 
> > > > From docs: 
> > > > 
> > > > macro r_str(p) 
> > > > 
> > > > > Regex(p) 
> > > > > end 
> > > > > 
> > > > > 
> > > > > That’s all. This macro says that the literal contents of the 
> string 
> > > > > literal r"^\s*(?:#|$)" should be passed to the 
> > > > > @r_str macro and the result of that expansion should be placed in 
> the 
> > > > > syntax tree where the string literal occurs. In 
> > > > > other words, the expression r"^\s*(?:#|$)" is equivalent to 
> placing 
> > > 
> > > the 
> > > 
> > > > > following object directly into the syntax 
> > > > > tree: 
> > > > > Regex("^\\s*(?:#|\$)") 
> > > > > 
> > > > > 
> > > > > Not only is the string literal form shorter and far more 
> convenient, 
> > > 
> > > but 
> > > 
> > > > > it is also more efficient: since the regular 
> > > > > expression is compiled and the Regex object is actually created 
> when 
> > > 
> > > the 
> > > 
> > > > > code is compiled, the compilation occurs 
> > > > > only once, rather than every time the code is executed. Consider 
> if 
> > > 
> > > the 
> > > 
> > > > > regular expression occurs in a loop: 
> > > > > for line = lines 
> > > > > m = match(r"^\s*(?:#|$)", line) 
> > > > > if m == nothing 
> > > > > # non-comment 
> > > > > else 
> > > > > # comment 
> > > > > end 
> > > > > end 
> > > > > 
> > > > > Shouldn't the compiler optimize this code *on its own* like this ? 
> > > > 
> > > > re = Regex("^\\s*(?:#|\$)") 
> > > > for line = lines 
> > > > m = match(re, line) 
> > > > if m == nothing 
> > > > # non-comment 
> > > > else 
> > > > # comment 
> > > > end 
> > > > end 
> > > > 
> > > > This is kind of optimization which is really easy to detect and and 
> > > 
> > > execute. 
> > > 
> > > > How is that so that julia is not able to do that? 
>
>

Re: [julia-users] Re: how long until vectorized code runs fast?

[Anonymous]

are operators such as

[1 2; 3 4] .* [1 2]

or

[1,2] .^ [1,2]

part of BLAS?

The latter is covered by devectorize.jl, however my understanding is that 
the former falls between the cracks, neither covered by devectorize.jl nor 
by BLAS.

On Thursday, May 12, 2016 at 12:06:45 AM UTC-7, Milan Bouchet-Valat wrote:
>
> Le mercredi 11 mai 2016 à 23:03 -0700, Anonymous a écrit : 
> > In response to both Kristoffer and Keno's timely responses, 
> > 
> > Originally I just did a simple @time test of the form 
> > Matrix .* horizontal vector 
> > 
> > and then tested the same thing with for loops, and the for loops were 
> > way faster (and used way less memory) 
> > 
> > However I just devectorized one of my algorithms and ran an @time 
> > comparison and the vectorized version was actually twice as fast as 
> > the devectorized version, however the vectorized version used way 
> > more memory.  Clearly I don't really understand the specifics of what 
> > makes code slow, and in particular how vectorized code compares to 
> > devectorized code.  Vectorized code does seem to use a lot more 
> > memory, but clearly for my algorithm it nevertheless runs faster than 
> > the devectorized version.  Is there a reference I could look at that 
> > explains this to someone with a background in math but not much 
> > knowledge of computer architecture? 
> I don't know about a reference, but I suspect this is due to BLAS. 
> Vectorized versions of linear algebra operations like matrix 
> multiplication are highly optimized, and run several threads in 
> parallel. OTC, your devectorized code isn't carefully tuned for a 
> specific processor model, and uses a single CPU core (soon Julia will 
> support using several threads, and see [1]). 
>
> So depending on the particular operations you're running, the 
> vectorized form can be faster even though it allocates more memory. In 
> general, it will likely be faster to use BLAS for expensive operations 
> on large matrices. OTOH, it's better to devectorize code if you 
> successively perform several simple operations on an array, because 
> each operation currently allocates a copy of the array (this may well 
> change with [2]). 
>
>
> Regards 
>
>
> 1: http://julialang.org/blog/2016/03/parallelaccelerator 
> 2: https://github.com/JuliaLang/julia/issues/16285 
>
> > > There seems to be a myth going around that vectorized code in Julia 
> > > is  
> > > slow. That's not really the case. Often times it's just that  
> > > devectorized code is faster because one can manually perform  
> > > operations such as loop fusion, which the compiler cannot 
> > > currently  
> > > reason about (and most C compilers can't either). In some other  
> > > languages those benefits get drowned out by language overhead, but 
> > > in  
> > > julia those kinds of constructs are generally fast. The cases 
> > > where  
> > > julia can be slower is when there is excessive memory allocation in 
> > > a  
> > > tight inner loop, but those cases can usually be rewritten fairly  
> > > easily without losing the vectorized look of the code.  
> > > 
> > > On Thu, May 12, 2016 at 1:35 AM, Kristoffer Carlsson  
> > >  wrote:  
> > > > It is always easier to discuss if there is a piece of code to 
> > > look at. Could  
> > > > you perhaps post a few code examples that does not run as fast as 
> > > you want?  
> > > >  
> > > > Also, make sure to look at :  
> > > > https://github.com/IntelLabs/ParallelAccelerator.jl. They have a 
> > > quite  
> > > > sophisticated compiler that does loop fusions and parallelization 
> > > and other  
> > > > cool stuff.  
> > > >  
> > > >  
> > > >  
> > > > On Thursday, May 12, 2016 at 7:22:24 AM UTC+2, Anonymous wrote:  
> > > >>  
> > > >> This remains one of the main drawbacks of Julia, and the 
> > > devectorize  
> > > >> package is basically useless as it doesn't support some really 
> > > crucial  
> > > >> vectorized operations.  I'd really prefer not to rewrite all my 
> > > vectorized  
> > > >> code into nested loops if at all possible, but I really need 
> > > more speed, can  
> > > >> anyone tell me the timeline and future plans for making 
> > > vectorized code run  
> > > >> at C speed?  
>

Re: [julia-users] Re: how long until vectorized code runs fast?

[Milan Bouchet-Valat]

Le mercredi 11 mai 2016 à 23:03 -0700, Anonymous a écrit :
> In response to both Kristoffer and Keno's timely responses,
> 
> Originally I just did a simple @time test of the form
> Matrix .* horizontal vector
> 
> and then tested the same thing with for loops, and the for loops were
> way faster (and used way less memory)
> 
> However I just devectorized one of my algorithms and ran an @time
> comparison and the vectorized version was actually twice as fast as
> the devectorized version, however the vectorized version used way
> more memory.  Clearly I don't really understand the specifics of what
> makes code slow, and in particular how vectorized code compares to
> devectorized code.  Vectorized code does seem to use a lot more
> memory, but clearly for my algorithm it nevertheless runs faster than
> the devectorized version.  Is there a reference I could look at that
> explains this to someone with a background in math but not much
> knowledge of computer architecture?
I don't know about a reference, but I suspect this is due to BLAS.
Vectorized versions of linear algebra operations like matrix
multiplication are highly optimized, and run several threads in
parallel. OTC, your devectorized code isn't carefully tuned for a
specific processor model, and uses a single CPU core (soon Julia will
support using several threads, and see [1]).

So depending on the particular operations you're running, the
vectorized form can be faster even though it allocates more memory. In
general, it will likely be faster to use BLAS for expensive operations
on large matrices. OTOH, it's better to devectorize code if you
successively perform several simple operations on an array, because
each operation currently allocates a copy of the array (this may well
change with [2]).


Regards


1: http://julialang.org/blog/2016/03/parallelaccelerator
2: https://github.com/JuliaLang/julia/issues/16285

> > There seems to be a myth going around that vectorized code in Julia
> > is 
> > slow. That's not really the case. Often times it's just that 
> > devectorized code is faster because one can manually perform 
> > operations such as loop fusion, which the compiler cannot
> > currently 
> > reason about (and most C compilers can't either). In some other 
> > languages those benefits get drowned out by language overhead, but
> > in 
> > julia those kinds of constructs are generally fast. The cases
> > where 
> > julia can be slower is when there is excessive memory allocation in
> > a 
> > tight inner loop, but those cases can usually be rewritten fairly 
> > easily without losing the vectorized look of the code. 
> > 
> > On Thu, May 12, 2016 at 1:35 AM, Kristoffer Carlsson 
> >  wrote: 
> > > It is always easier to discuss if there is a piece of code to
> > look at. Could 
> > > you perhaps post a few code examples that does not run as fast as
> > you want? 
> > > 
> > > Also, make sure to look at : 
> > > https://github.com/IntelLabs/ParallelAccelerator.jl. They have a
> > quite 
> > > sophisticated compiler that does loop fusions and parallelization
> > and other 
> > > cool stuff. 
> > > 
> > > 
> > > 
> > > On Thursday, May 12, 2016 at 7:22:24 AM UTC+2, Anonymous wrote: 
> > >> 
> > >> This remains one of the main drawbacks of Julia, and the
> > devectorize 
> > >> package is basically useless as it doesn't support some really
> > crucial 
> > >> vectorized operations.  I'd really prefer not to rewrite all my
> > vectorized 
> > >> code into nested loops if at all possible, but I really need
> > more speed, can 
> > >> anyone tell me the timeline and future plans for making
> > vectorized code run 
> > >> at C speed?