Re: [julia-users] Documentation in the source code

[Viral Shah]

Given that Docile.jl is almost compatible with the 0.4 stuff, we could even 
add it as a dependency to Compat.jl, so that package authors can start 
adding documentation that will work for 0.3, and will work on 0.4.

Streamlining of package documentation will go a long way towards making 
stuff like JuliaBox and Juno a lot more user friendly.

-viral

On Saturday, December 6, 2014 2:18:07 AM UTC+5:30, Mike Innes wrote:
>
> I'll add some meta-documentation to the manual for this soon.
>
> On 5 December 2014 at 19:58, John Myles White  
> wrote:
>
>> Documentation is undergoing a shift as 0.4 will be the first release with 
>> built-in documentation tools. Check the GitHub issues for details about the 
>> upcoming @doc macro.
>>
>>   -- John
>>
>> On Dec 5, 2014, at 10:40 AM, Petr Krysl  wrote:
>>
>> > Hello,
>> >
>> > Does anyone know how the document functions and types (and modules) in 
>> the "Julia style"?
>> >
>> > I looked at the source code for some of the Base functions and I 
>> couldn't really find any documentation attached to those functions.
>> >
>> > Thanks,
>> >
>> > Petr
>>
>>
>

Re: [julia-users] Avoiding allocation when writing to arrays of immutables

[John Myles White]

I think this might be a problem with Julia 0.3. I see it on Julia 0.3, but not 
on the development branch for Julia 0.4.

 — John

On Dec 5, 2014, at 6:27 PM, Will Dobbie  wrote:

> Hi,
> 
> I have a program which copies elements between two arrays of immutables in a 
> tight loop. The sizes of the arrays never change. I've been struggling to get 
> it to avoid spending a large chunk of its time in the garbage collector. I 
> have an example of what I mean below.
> 
> With arrays of Int64 I get:
> elapsed time: 0.164429425 seconds (0 bytes allocated)
> 
> With arrays of an immutable the same size as Int64 I get:
> elapsed time: 1.421834146 seconds (32000 bytes allocated, 15.97% gc time)
> 
> My understanding was arrays of immutables should behave like arrays of 
> structs in C and not require heap allocation. Is there a way I can achieve 
> that? I'm using Julia 0.3.3.
> 
> Thanks,
> Will
> 
> 
> 
> module immtest
> 
> immutable Vec2
>   x::Float32
>   y::Float32
> end
> 
> # typealias element_type Vec2 # Results in allocation in the loop 
> below
> typealias element_type Int64  # Does not cause allocation
> 
> function runtest(reps)
>   dst = resize!(element_type[], 100_000)
>   src = resize!(element_type[], 10)
> 
>   @time begin
>   for i=1:reps
>   copy!(dst, 1000, src, 1, length(src))
>   # dst[1000:1009] = src  # same performance as 
> above
>   end
>   end
> end
> 
> runtest(10_000_000)
> 
> end
> 

[julia-users] Avoiding allocation when writing to arrays of immutables

[Will Dobbie]

Hi,

I have a program which copies elements between two arrays of immutables in 
a tight loop. The sizes of the arrays never change. I've been struggling to 
get it to avoid spending a large chunk of its time in the garbage 
collector. I have an example of what I mean below.

With arrays of Int64 I get:
elapsed time: 0.164429425 seconds (0 bytes allocated)

With arrays of an immutable the same size as Int64 I get:
elapsed time: 1.421834146 seconds (32000 bytes allocated, 15.97% gc 
time)

My understanding was arrays of immutables should behave like arrays of 
structs in C and not require heap allocation. Is there a way I can achieve 
that? I'm using Julia 0.3.3.

Thanks,
Will



module immtest

immutable Vec2
x::Float32
y::Float32
end

# typealias element_type Vec2 # Results in allocation in the loop below
typealias element_type Int64 # Does not cause allocation

function runtest(reps)
dst = resize!(element_type[], 100_000)
src = resize!(element_type[], 10)

@time begin
for i=1:reps
copy!(dst, 1000, src, 1, length(src))
# dst[1000:1009] = src # same performance as above
end
end
end

runtest(10_000_000)

end

[julia-users] Re: How can I sort Dict efficiently?

[Steven G. Johnson]

On Friday, December 5, 2014 9:57:28 AM UTC-5, Michiaki Ariga wrote:
>
> I found there are no method such as sort_by() after v0.3.
> But I want to count word frequency with Dict() and sort by its value to 
> find frequent word.
> So, how can I sort Dict efficiently?
>

 You may want to use a different data structure.  For example, you can 
store word frequencies in a PriorityQueue and then pull out the most 
frequent word with peek or dequeue.  See:

http://julia.readthedocs.org/en/latest/stdlib/collections/

(A PriorityQueue lets you quickly fetch the smallest value, whereas you 
want the largest frequency, but you can work around this by just storing 
frequency * -1.)

If you need all of the values in order, you can instead use an OrderedDict 
from https://github.com/JuliaLang/DataStructures.jl

[julia-users] Re: Redefinition of type problem in IJulia an REPL

[elextr]

Putting words in the major developers mouths :)

The "Julian" way is to have lots of small functions.  Automatically 
exporting all those helper functions pollutes the namespace and increases 
the chance of name clashes with other packages.  So "exportall" would also 
need an "unexport" or "local" as well to hide these functions.  Having 
spent considerable time in the past adding "static" to C function 
declarations, I can say with authority that the "local" will be forgotten 
regularly since it is innocuous until a clash occurs.

Cheers
Lex

On Saturday, December 6, 2014 11:36:44 AM UTC+10, Greg Trzeciak wrote:
>
> Hah, thanks for actually bothering to reply with such a simple mistake (in 
> my proper code I exported with a typo and assumed export doesn't work in 
> repl)
>
> Is there any paritcular reason why there is no "exportall"?
>
> On Saturday, December 6, 2014 12:17:51 AM UTC+1, ele...@gmail.com wrote:
>>
>> You didn't export Foo from the module.
>>
>> Cheers
>> Lex
>>
>> On Saturday, December 6, 2014 3:23:26 AM UTC+10, Greg Trzeciak wrote:
>>>
>>> While developing in IJulia notebook (and REPL) if I need to redefine a 
>>> type I am informed of "invalid redefinition of constant". According to 
>>> http://julia.readthedocs.org/en/latest/manual/faq/ the types in module 
>>> Main cannot be redefined and as a workaround it suggests wrapping the code 
>>> inside the module. But if I do:
>>> In[1]:
>>> module Mod1
>>>
>>> type Foo
>>> name::String
>>> end
>>> a = Foo("bar")
>>> println(a.name)
>>> end
>>>
>>> How can I get access to Types defined in In[1]
>>>
>>> eg. In[2]:
>>> using Mod1
>>> b = Foo("bar")
>>> println(b.name)
>>>
>>> ERROR: Foo not defined
>>>
>>> I tried using, export, import, importall to no avail and placing the 
>>> code in the .jl file and using include("something.jl") is not an "an 
>>> excellent workaround" because it defies the purpose of using notebook.
>>>
>>> I know I can restart the kernel but it is not too practical to do too 
>>> often.
>>>
>>>
>>>
>>>
>>>
>>>

Re: [julia-users] Re: What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Matt Gushee]

On Fri, Dec 5, 2014 at 5:22 PM, ivo welch  wrote:
>
> On Fri, Dec 5, 2014 at 6:47 PM, Páll Haraldsson 
> wrote:
>>
>> what is it you want? Why is web-programming special? And wouldn't Julia be
>> as least as good a fit (for server side) as any other language?
>
> I do not want to hijack the julia list, so I will be short.

I don't either, so I'll be even shorter.
>
> imho, a web language should allow you to pretend that you are programming
> the GUI on a single desktop.

That's kind of the idea behind Node.js, isn't it? Sounds like the
mother of all leaky abstractions to me.

--
Matt Gushee

Re: [julia-users] undo hash (dehash, unhash, etc)

[David Koslicki]

Thanks for the suggestions:

On Friday, December 5, 2014 5:40:57 PM UTC-8, Jason Merrill wrote:
>
> This is the best you can do if
>
> 1. Every input in your space of possibilities is equally likely, and
> 2. You need to remember every input that you've seen
> 3. You need to know the order you saw them in
>
> If you just need to know "have I seen this input before," and you can 
> accept some false positives, then bloom filters are a good choice, as you 
> suggest, and John has an implementation of these in Julia: 
> https://github.com/johnmyleswhite/BloomFilters.jl
>
> I've tried using this, but it isn't quite "prime time ready" 
(https://github.com/johnmyleswhite/BloomFilters.jl/issues/7)
 

> If you just need to know "how many different inputs have I seen," then the 
> HyperLogLog is another semi-miraculous data structure for doing that, and 
> John also has an implementation of these in Julia: 
> https://github.com/johnmyleswhite/HyperLogLog.jl
>
> I hadn't hear of this before! But I will certainly look into it!
 

> As you can see, John's been busy :-)
>
> But probably there are other things you want to query about your data. 
> There might be good answers to some of those questions too if you ask them. 
> In general, you might want to read up on Streaming Algorithms: 
> http://en.wikipedia.org/wiki/Streaming_algorithm
>
> See also the BioJulia organization. Looks like they already have an 
> implementation of the 2-bits per base pair idea: 
> https://github.com/BioJulia/BioSeq.jl
>
This is currently the approach I'm taking (with my own implementation). 

>
> On Friday, December 5, 2014 5:25:04 PM UTC-8, David Koslicki wrote:
>>
>> Good suggestion, but I've tried that already, and besides the fact that 
>> the HDF5 package (https://github.com/timholy/HDF5.jl) doesn't yet 
>> support Int128, this would result in file sizes upwards of 750Gb (too large 
>> for my purposes).
>>
>> On Friday, December 5, 2014 5:19:00 PM UTC-8, Jason Merrill wrote:
>>>
>>> Here's one possibility:
>>>
>>> Interpret A, C, T, G as two bit integers, i.e. A=00, C=01, T=10, G=11. A 
>>> string of up to 50 of these has 2*50=100 bits, so you could store any such 
>>> string as a unique Int128.
>>>
>>

Re: [julia-users] undo hash (dehash, unhash, etc)

[Jameson Nash]

Being able to suggest an appropriate compression algorithm would require
knowing both how you intend to use the data (so that you don’t kill
performance by packing the data wrong) and what the data looks like (where
the “entropy” http://en.wikipedia.org/wiki/Entropy_%28information_theory%29
exists in the data).

For example, if you just want a smaller storage format, gzip would probably
do quite well. However, gzip is a stream compressor, and cannot do random
seeks. If there’s a lot of redundancy, then you could store them in a
Dictionary object (Dict{ASCIIString, Int} of string=>count mappings). If
there is a lot of common prefixes, then a common prefix tree (similar to
the Dictionary, but where branch stores a count and a pointer to the next
object:

type Node
  count::Int
  A::Node
  C::Node
  T::Node
  G::Node
  Node() = new(1)
end

)

On Fri Dec 05 2014 at 8:28:05 PM David Koslicki 
wrote:

Duly noted, though I did get my answer (no) pretty quickly! ;)
> Of course, the main problem is still an issue. But then again, it's kind
> of an "open problem" in bioinformatics (so I don't think this would be the
> correct forum to ask it in).
>
> I appreciate your help!
>
>
> On Friday, December 5, 2014 5:23:56 PM UTC-8, Jason Merrill wrote:
>>
>> As a meta point, beware the XY problem: http://meta.stackexchange.com/
>> a/66378
>>
>> In other words, you'll typically get better answers faster if you start
>> with the broad context, like
>>
>> On Friday, December 5, 2014 5:13:49 PM UTC-8, David Koslicki wrote:

 I have strings (on the alphabet {A,C,T,G}) of length 30 to 50. I am
 trying to hash them to save on space (as I have a few million to billion of
 them).

>>>
>> And then suggest ideas for how to solve it that you've thought of that
>> don't quite work yet, like
>>
>>
>>> I know I should be using a bloom filter (http://en.wikipedia.org/wiki/
 Bloom_filter) or some other such space-saving data structure, but I'm
 too lazy/busy/inexperienced to do it by hand.

>>>  or
>>
>>> > Is there a built in function that will undo hash()?

>>>
>>
>>
> ​

Re: [julia-users] undo hash (dehash, unhash, etc)

[Jason Merrill]

This is the best you can do if

1. Every input in your space of possibilities is equally likely, and
2. You need to remember every input that you've seen
3. You need to know the order you saw them in

If you just need to know "have I seen this input before," and you can 
accept some false positives, then bloom filters are a good choice, as you 
suggest, and John has an implementation of these in 
Julia: https://github.com/johnmyleswhite/BloomFilters.jl

If you just need to know "how many different inputs have I seen," then the 
HyperLogLog is another semi-miraculous data structure for doing that, and 
John also has an implementation of these in 
Julia: https://github.com/johnmyleswhite/HyperLogLog.jl

As you can see, John's been busy :-)

But probably there are other things you want to query about your data. 
There might be good answers to some of those questions too if you ask them. 
In general, you might want to read up on Streaming 
Algorithms: http://en.wikipedia.org/wiki/Streaming_algorithm

See also the BioJulia organization. Looks like they already have an 
implementation of the 2-bits per base pair 
idea: https://github.com/BioJulia/BioSeq.jl

On Friday, December 5, 2014 5:25:04 PM UTC-8, David Koslicki wrote:
>
> Good suggestion, but I've tried that already, and besides the fact that 
> the HDF5 package (https://github.com/timholy/HDF5.jl) doesn't yet support 
> Int128, this would result in file sizes upwards of 750Gb (too large for my 
> purposes).
>
> On Friday, December 5, 2014 5:19:00 PM UTC-8, Jason Merrill wrote:
>>
>> Here's one possibility:
>>
>> Interpret A, C, T, G as two bit integers, i.e. A=00, C=01, T=10, G=11. A 
>> string of up to 50 of these has 2*50=100 bits, so you could store any such 
>> string as a unique Int128.
>>
>

[julia-users] Re: Redefinition of type problem in IJulia an REPL

[Greg Trzeciak]

Hah, thanks for actually bothering to reply with such a simple mistake (in 
my proper code I exported with a typo and assumed export doesn't work in 
repl)

Is there any paritcular reason why there is no "exportall"?

On Saturday, December 6, 2014 12:17:51 AM UTC+1, ele...@gmail.com wrote:
>
> You didn't export Foo from the module.
>
> Cheers
> Lex
>
> On Saturday, December 6, 2014 3:23:26 AM UTC+10, Greg Trzeciak wrote:
>>
>> While developing in IJulia notebook (and REPL) if I need to redefine a 
>> type I am informed of "invalid redefinition of constant". According to 
>> http://julia.readthedocs.org/en/latest/manual/faq/ the types in module 
>> Main cannot be redefined and as a workaround it suggests wrapping the code 
>> inside the module. But if I do:
>> In[1]:
>> module Mod1
>>
>> type Foo
>> name::String
>> end
>> a = Foo("bar")
>> println(a.name)
>> end
>>
>> How can I get access to Types defined in In[1]
>>
>> eg. In[2]:
>> using Mod1
>> b = Foo("bar")
>> println(b.name)
>>
>> ERROR: Foo not defined
>>
>> I tried using, export, import, importall to no avail and placing the code 
>> in the .jl file and using include("something.jl") is not an "an excellent 
>> workaround" because it defies the purpose of using notebook.
>>
>> I know I can restart the kernel but it is not too practical to do too 
>> often.
>>
>>
>>
>>
>>
>>

Re: [julia-users] undo hash (dehash, unhash, etc)

[David Koslicki]

Duly noted, though I did get my answer (no) pretty quickly! ;)
Of course, the main problem is still an issue. But then again, it's kind of 
an "open problem" in bioinformatics (so I don't think this would be the 
correct forum to ask it in).

I appreciate your help!

On Friday, December 5, 2014 5:23:56 PM UTC-8, Jason Merrill wrote:
>
> As a meta point, beware the XY problem: 
> http://meta.stackexchange.com/a/66378
>
> In other words, you'll typically get better answers faster if you start 
> with the broad context, like
>
> On Friday, December 5, 2014 5:13:49 PM UTC-8, David Koslicki wrote:
>>>
>>> I have strings (on the alphabet {A,C,T,G}) of length 30 to 50. I am 
>>> trying to hash them to save on space (as I have a few million to billion of 
>>> them). 
>>>
>>
> And then suggest ideas for how to solve it that you've thought of that 
> don't quite work yet, like
>  
>
>> I know I should be using a bloom filter (
>>> http://en.wikipedia.org/wiki/Bloom_filter) or some other such 
>>> space-saving data structure, but I'm too lazy/busy/inexperienced to do it 
>>> by hand.
>>>
>>  or  
>
>> > Is there a built in function that will undo hash()? 
>>>
>>
>  
>

Re: [julia-users] undo hash (dehash, unhash, etc)

[David Koslicki]

Good suggestion, but I've tried that already, and besides the fact that the 
HDF5 package (https://github.com/timholy/HDF5.jl) doesn't yet support 
Int128, this would result in file sizes upwards of 750Gb (too large for my 
purposes).

On Friday, December 5, 2014 5:19:00 PM UTC-8, Jason Merrill wrote:
>
> Here's one possibility:
>
> Interpret A, C, T, G as two bit integers, i.e. A=00, C=01, T=10, G=11. A 
> string of up to 50 of these has 2*50=100 bits, so you could store any such 
> string as a unique Int128.
>
> On Friday, December 5, 2014 5:13:49 PM UTC-8, David Koslicki wrote:
>>
>> I have strings (on the alphabet {A,C,T,G}) of length 30 to 50. I am 
>> trying to hash them to save on space (as I have a few million to billion of 
>> them). I know I should be using a bloom filter (
>> http://en.wikipedia.org/wiki/Bloom_filter) or some other such 
>> space-saving data structure, but I'm too lazy/busy/inexperienced to do it 
>> by hand.
>>
>> On Friday, December 5, 2014 5:10:54 PM UTC-8, Jason Merrill wrote:
>>>
>>> There might be a good solution to the particular problem you're trying 
>>> to solve, though. What are you trying to do?
>>>
>>> On Friday, December 5, 2014 5:08:08 PM UTC-8, John Myles White wrote:

 For specialized cases it is possible to achieve 1-1-ness: 
 http://en.wikipedia.org/wiki/Perfect_hash_function

 But this is not something that most people aspire to do for most types 
 since 1-1-ness isn't essential in most applications and is costly to 
 achieve.

  -- John

 On Dec 5, 2014, at 5:03 PM, David Koslicki  wrote:

 Ah, of course! I was hoping that on certain data types it was 1-1, but 
 I guess that was a long shot. Thanks for clarifying.

 On Friday, December 5, 2014 4:57:41 PM UTC-8, Jason Merrill wrote:
>
> If the space of possible hashes is smaller than the space of possible 
> inputs (e.g. the hash is represented with fewer bits than the input data 
> is), which is typically the case, then you can use the Pigeonhole 
> Principle 
> to prove what John wrote:
>
> https://en.wikipedia.org/wiki/Pigeonhole_principle
>
> On Friday, December 5, 2014 4:35:18 PM UTC-8, John Myles White wrote:
>>
>> This function is impossible to write in generality since hash 
>> functions aren't one-to-one. 
>>
>>  -- John 
>>
>> On Dec 5, 2014, at 4:32 PM, David Koslicki  
>> wrote: 
>>
>> > Hello, 
>> > 
>> > Is there a built in function that will undo hash()? 
>> > 
>> > i.e. I am looking for a function "dehash()" such that 
>> > dehash(hash("ACTG")) == "ACTG" 
>> > 
>> > I can't seem to find this anywhere (documentation, google, this 
>> user group, etc). 
>> > 
>> > Thanks, 
>> > 
>> > ~David 
>>
>>

Re: [julia-users] undo hash (dehash, unhash, etc)

[Jason Merrill]

As a meta point, beware the XY problem: 
http://meta.stackexchange.com/a/66378

In other words, you'll typically get better answers faster if you start 
with the broad context, like

On Friday, December 5, 2014 5:13:49 PM UTC-8, David Koslicki wrote:
>>
>> I have strings (on the alphabet {A,C,T,G}) of length 30 to 50. I am 
>> trying to hash them to save on space (as I have a few million to billion of 
>> them). 
>>
>
And then suggest ideas for how to solve it that you've thought of that 
don't quite work yet, like
 

> I know I should be using a bloom filter (
>> http://en.wikipedia.org/wiki/Bloom_filter) or some other such 
>> space-saving data structure, but I'm too lazy/busy/inexperienced to do it 
>> by hand.
>>
>  or  

> > Is there a built in function that will undo hash()? 
>>
>
 

Re: [julia-users] undo hash (dehash, unhash, etc)

[Jason Merrill]

Here's one possibility:

Interpret A, C, T, G as two bit integers, i.e. A=00, C=01, T=10, G=11. A 
string of up to 50 of these has 2*50=100 bits, so you could store any such 
string as a unique Int128.

On Friday, December 5, 2014 5:13:49 PM UTC-8, David Koslicki wrote:
>
> I have strings (on the alphabet {A,C,T,G}) of length 30 to 50. I am trying 
> to hash them to save on space (as I have a few million to billion of them). 
> I know I should be using a bloom filter (
> http://en.wikipedia.org/wiki/Bloom_filter) or some other such 
> space-saving data structure, but I'm too lazy/busy/inexperienced to do it 
> by hand.
>
> On Friday, December 5, 2014 5:10:54 PM UTC-8, Jason Merrill wrote:
>>
>> There might be a good solution to the particular problem you're trying to 
>> solve, though. What are you trying to do?
>>
>> On Friday, December 5, 2014 5:08:08 PM UTC-8, John Myles White wrote:
>>>
>>> For specialized cases it is possible to achieve 1-1-ness: 
>>> http://en.wikipedia.org/wiki/Perfect_hash_function
>>>
>>> But this is not something that most people aspire to do for most types 
>>> since 1-1-ness isn't essential in most applications and is costly to 
>>> achieve.
>>>
>>>  -- John
>>>
>>> On Dec 5, 2014, at 5:03 PM, David Koslicki  wrote:
>>>
>>> Ah, of course! I was hoping that on certain data types it was 1-1, but I 
>>> guess that was a long shot. Thanks for clarifying.
>>>
>>> On Friday, December 5, 2014 4:57:41 PM UTC-8, Jason Merrill wrote:

 If the space of possible hashes is smaller than the space of possible 
 inputs (e.g. the hash is represented with fewer bits than the input data 
 is), which is typically the case, then you can use the Pigeonhole 
 Principle 
 to prove what John wrote:

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

 On Friday, December 5, 2014 4:35:18 PM UTC-8, John Myles White wrote:
>
> This function is impossible to write in generality since hash 
> functions aren't one-to-one. 
>
>  -- John 
>
> On Dec 5, 2014, at 4:32 PM, David Koslicki  
> wrote: 
>
> > Hello, 
> > 
> > Is there a built in function that will undo hash()? 
> > 
> > i.e. I am looking for a function "dehash()" such that 
> > dehash(hash("ACTG")) == "ACTG" 
> > 
> > I can't seem to find this anywhere (documentation, google, this user 
> group, etc). 
> > 
> > Thanks, 
> > 
> > ~David 
>
>
>>>

Re: [julia-users] undo hash (dehash, unhash, etc)

[David Koslicki]

I have strings (on the alphabet {A,C,T,G}) of length 30 to 50. I am trying 
to hash them to save on space (as I have a few million to billion of them). 
I know I should be using a bloom filter 
(http://en.wikipedia.org/wiki/Bloom_filter) or some other such space-saving 
data structure, but I'm too lazy/busy/inexperienced to do it by hand.

On Friday, December 5, 2014 5:10:54 PM UTC-8, Jason Merrill wrote:
>
> There might be a good solution to the particular problem you're trying to 
> solve, though. What are you trying to do?
>
> On Friday, December 5, 2014 5:08:08 PM UTC-8, John Myles White wrote:
>>
>> For specialized cases it is possible to achieve 1-1-ness: 
>> http://en.wikipedia.org/wiki/Perfect_hash_function
>>
>> But this is not something that most people aspire to do for most types 
>> since 1-1-ness isn't essential in most applications and is costly to 
>> achieve.
>>
>>  -- John
>>
>> On Dec 5, 2014, at 5:03 PM, David Koslicki  wrote:
>>
>> Ah, of course! I was hoping that on certain data types it was 1-1, but I 
>> guess that was a long shot. Thanks for clarifying.
>>
>> On Friday, December 5, 2014 4:57:41 PM UTC-8, Jason Merrill wrote:
>>>
>>> If the space of possible hashes is smaller than the space of possible 
>>> inputs (e.g. the hash is represented with fewer bits than the input data 
>>> is), which is typically the case, then you can use the Pigeonhole Principle 
>>> to prove what John wrote:
>>>
>>> https://en.wikipedia.org/wiki/Pigeonhole_principle
>>>
>>> On Friday, December 5, 2014 4:35:18 PM UTC-8, John Myles White wrote:

 This function is impossible to write in generality since hash functions 
 aren't one-to-one. 

  -- John 

 On Dec 5, 2014, at 4:32 PM, David Koslicki  wrote: 

 > Hello, 
 > 
 > Is there a built in function that will undo hash()? 
 > 
 > i.e. I am looking for a function "dehash()" such that 
 > dehash(hash("ACTG")) == "ACTG" 
 > 
 > I can't seem to find this anywhere (documentation, google, this user 
 group, etc). 
 > 
 > Thanks, 
 > 
 > ~David 


>>

Re: [julia-users] undo hash (dehash, unhash, etc)

[David Koslicki]

So a better question to ask would have been: "Is the built-in julia 
function for hashing strings a perfect hash function". I assume the answer 
is no...

On Friday, December 5, 2014 5:08:08 PM UTC-8, John Myles White wrote:
>
> For specialized cases it is possible to achieve 1-1-ness: 
> http://en.wikipedia.org/wiki/Perfect_hash_function
>
> But this is not something that most people aspire to do for most types 
> since 1-1-ness isn't essential in most applications and is costly to 
> achieve.
>
>  -- John
>
> On Dec 5, 2014, at 5:03 PM, David Koslicki  > wrote:
>
> Ah, of course! I was hoping that on certain data types it was 1-1, but I 
> guess that was a long shot. Thanks for clarifying.
>
> On Friday, December 5, 2014 4:57:41 PM UTC-8, Jason Merrill wrote:
>>
>> If the space of possible hashes is smaller than the space of possible 
>> inputs (e.g. the hash is represented with fewer bits than the input data 
>> is), which is typically the case, then you can use the Pigeonhole Principle 
>> to prove what John wrote:
>>
>> https://en.wikipedia.org/wiki/Pigeonhole_principle
>>
>> On Friday, December 5, 2014 4:35:18 PM UTC-8, John Myles White wrote:
>>>
>>> This function is impossible to write in generality since hash functions 
>>> aren't one-to-one. 
>>>
>>>  -- John 
>>>
>>> On Dec 5, 2014, at 4:32 PM, David Koslicki  wrote: 
>>>
>>> > Hello, 
>>> > 
>>> > Is there a built in function that will undo hash()? 
>>> > 
>>> > i.e. I am looking for a function "dehash()" such that 
>>> > dehash(hash("ACTG")) == "ACTG" 
>>> > 
>>> > I can't seem to find this anywhere (documentation, google, this user 
>>> group, etc). 
>>> > 
>>> > Thanks, 
>>> > 
>>> > ~David 
>>>
>>>
>

Re: [julia-users] undo hash (dehash, unhash, etc)

[Jason Merrill]

There might be a good solution to the particular problem you're trying to 
solve, though. What are you trying to do?

On Friday, December 5, 2014 5:08:08 PM UTC-8, John Myles White wrote:
>
> For specialized cases it is possible to achieve 1-1-ness: 
> http://en.wikipedia.org/wiki/Perfect_hash_function
>
> But this is not something that most people aspire to do for most types 
> since 1-1-ness isn't essential in most applications and is costly to 
> achieve.
>
>  -- John
>
> On Dec 5, 2014, at 5:03 PM, David Koslicki  > wrote:
>
> Ah, of course! I was hoping that on certain data types it was 1-1, but I 
> guess that was a long shot. Thanks for clarifying.
>
> On Friday, December 5, 2014 4:57:41 PM UTC-8, Jason Merrill wrote:
>>
>> If the space of possible hashes is smaller than the space of possible 
>> inputs (e.g. the hash is represented with fewer bits than the input data 
>> is), which is typically the case, then you can use the Pigeonhole Principle 
>> to prove what John wrote:
>>
>> https://en.wikipedia.org/wiki/Pigeonhole_principle
>>
>> On Friday, December 5, 2014 4:35:18 PM UTC-8, John Myles White wrote:
>>>
>>> This function is impossible to write in generality since hash functions 
>>> aren't one-to-one. 
>>>
>>>  -- John 
>>>
>>> On Dec 5, 2014, at 4:32 PM, David Koslicki  wrote: 
>>>
>>> > Hello, 
>>> > 
>>> > Is there a built in function that will undo hash()? 
>>> > 
>>> > i.e. I am looking for a function "dehash()" such that 
>>> > dehash(hash("ACTG")) == "ACTG" 
>>> > 
>>> > I can't seem to find this anywhere (documentation, google, this user 
>>> group, etc). 
>>> > 
>>> > Thanks, 
>>> > 
>>> > ~David 
>>>
>>>
>

Re: [julia-users] undo hash (dehash, unhash, etc)

[John Myles White]

For specialized cases it is possible to achieve 1-1-ness: 
http://en.wikipedia.org/wiki/Perfect_hash_function

But this is not something that most people aspire to do for most types since 
1-1-ness isn't essential in most applications and is costly to achieve.

 -- John

On Dec 5, 2014, at 5:03 PM, David Koslicki  wrote:

> Ah, of course! I was hoping that on certain data types it was 1-1, but I 
> guess that was a long shot. Thanks for clarifying.
> 
> On Friday, December 5, 2014 4:57:41 PM UTC-8, Jason Merrill wrote:
> If the space of possible hashes is smaller than the space of possible inputs 
> (e.g. the hash is represented with fewer bits than the input data is), which 
> is typically the case, then you can use the Pigeonhole Principle to prove 
> what John wrote:
> 
> https://en.wikipedia.org/wiki/Pigeonhole_principle
> 
> On Friday, December 5, 2014 4:35:18 PM UTC-8, John Myles White wrote:
> This function is impossible to write in generality since hash functions 
> aren't one-to-one. 
> 
>  -- John 
> 
> On Dec 5, 2014, at 4:32 PM, David Koslicki  wrote: 
> 
> > Hello, 
> > 
> > Is there a built in function that will undo hash()? 
> > 
> > i.e. I am looking for a function "dehash()" such that 
> > dehash(hash("ACTG")) == "ACTG" 
> > 
> > I can't seem to find this anywhere (documentation, google, this user group, 
> > etc). 
> > 
> > Thanks, 
> > 
> > ~David 
> 

Re: [julia-users] Struggling with generic functions.

[John Myles White]

StatsBase is meant to occupy that sort of role, but there's enough disagreement 
that we haven't moved as far foward as I'd like. Have you read through the 
StatsBase codebase?

 -- John

On Dec 2, 2014, at 8:19 PM, Rob J. Goedman  wrote:

> Thanks John, I’d come to a similar conclusion about there not being a 
> straightforward solution. Nice to get that confirmed from your side. Cutting 
> back on exporting names whenever possible also makes a lot of sense. 
> 
> Is StatsBase intended to play a similar role for types? Or is that more the 
> domain of PGM.jl?
> 
> As an example,  Model is used in several packages (MCMC, Mamba). This makes 
> using both packages simultaneously harder as the end user needs to figure out 
> which names to qualify. Other packages have taken a different approach. 
> MixedModels uses MixedModel and LinearMixedModel, GLM uses LmMod and GlmMod, 
> Stan and Jags use Stanmodel and Jagsmodel (I could rename them to StanModel 
> and JagsModel). Is it reasonable to make Model an abstract type?
> 
> Rob
> 
> 
>> On Dec 2, 2014, at 4:37 PM, John Myles White  
>> wrote:
>> 
>> There's no clean solution to this. In general, I'd argue that we should stop 
>> exporting so many names and encourage people to use qualified names much 
>> more often than we do right now.
>> 
>> But for important abstractions, we can put them into StatsBase, which all 
>> stats packages should be derived from.
>> 
>> -- John
>> 
>> On Dec 2, 2014, at 4:34 PM, Rob J. Goedman  wrote:
>> 
>>> I’ll try to give an example of my problem based on how I’ve seen it occur 
>>> in Stan.jl and Jags.jl.
>>> 
>>> Both DataFrames.jl and Mamba.jl export describe(). Stan.jl relies on Mamba, 
>>> but neither Stan or Mamba need DataFrames. So DataFrames is not imported by 
>>> default.
>>> 
>>> Recently someone used Stan and wanted to read in a .csv file and added 
>>> DataFrames to the using clause in the script, i.e.
>>> 
>>> ```
>>> using Gadfly, Stan, Mamba, DataFrames
>>> ```
>>> 
>>> After running a simulation, Mamba’s describe(::Mamba.Chains) could no 
>>> longer be found.
>>> 
>>> I wonder if someone can point me in the right direction how best to solve 
>>> these kind of problems (for end users):
>>> 
>>> 1. One way around it is to always qualify describe(), e.g. Mamba.describe().
>>> 2. Use isdefined(Main, :DataFrames) to upfront test for such a collision.
>>> 3. Suggest to end users to import DataFrames and qualify e.g. 
>>> DataFrames.readtable().
>>> 4. ?
>>> 
>>> Thanks and regards,
>>> Rob J. Goedman
>>> goed...@mac.com
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 

Re: [julia-users] undo hash (dehash, unhash, etc)

[David Koslicki]

Ah, of course! I was hoping that on certain data types it was 1-1, but I 
guess that was a long shot. Thanks for clarifying.

On Friday, December 5, 2014 4:57:41 PM UTC-8, Jason Merrill wrote:
>
> If the space of possible hashes is smaller than the space of possible 
> inputs (e.g. the hash is represented with fewer bits than the input data 
> is), which is typically the case, then you can use the Pigeonhole Principle 
> to prove what John wrote:
>
> https://en.wikipedia.org/wiki/Pigeonhole_principle
>
> On Friday, December 5, 2014 4:35:18 PM UTC-8, John Myles White wrote:
>>
>> This function is impossible to write in generality since hash functions 
>> aren't one-to-one. 
>>
>>  -- John 
>>
>> On Dec 5, 2014, at 4:32 PM, David Koslicki  wrote: 
>>
>> > Hello, 
>> > 
>> > Is there a built in function that will undo hash()? 
>> > 
>> > i.e. I am looking for a function "dehash()" such that 
>> > dehash(hash("ACTG")) == "ACTG" 
>> > 
>> > I can't seem to find this anywhere (documentation, google, this user 
>> group, etc). 
>> > 
>> > Thanks, 
>> > 
>> > ~David 
>>
>>

Re: [julia-users] undo hash (dehash, unhash, etc)

[Jason Merrill]

If the space of possible hashes is smaller than the space of possible 
inputs (e.g. the hash is represented with fewer bits than the input data 
is), which is typically the case, then you can use the Pigeonhole Principle 
to prove what John wrote:

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

On Friday, December 5, 2014 4:35:18 PM UTC-8, John Myles White wrote:
>
> This function is impossible to write in generality since hash functions 
> aren't one-to-one. 
>
>  -- John 
>
> On Dec 5, 2014, at 4:32 PM, David Koslicki  > wrote: 
>
> > Hello, 
> > 
> > Is there a built in function that will undo hash()? 
> > 
> > i.e. I am looking for a function "dehash()" such that 
> > dehash(hash("ACTG")) == "ACTG" 
> > 
> > I can't seem to find this anywhere (documentation, google, this user 
> group, etc). 
> > 
> > Thanks, 
> > 
> > ~David 
>
>

Re: [julia-users] undo hash (dehash, unhash, etc)

[John Myles White]

This function is impossible to write in generality since hash functions aren't 
one-to-one.

 -- John

On Dec 5, 2014, at 4:32 PM, David Koslicki  wrote:

> Hello,
> 
> Is there a built in function that will undo hash()?
> 
> i.e. I am looking for a function "dehash()" such that
> dehash(hash("ACTG")) == "ACTG"
> 
> I can't seem to find this anywhere (documentation, google, this user group, 
> etc).
> 
> Thanks,
> 
> ~David

[julia-users] undo hash (dehash, unhash, etc)

[David Koslicki]

Hello,

Is there a built in function that will undo hash()?

i.e. I am looking for a function "dehash()" such that
dehash(hash("ACTG")) == "ACTG"

I can't seem to find this anywhere (documentation, google, this user group, 
etc).

Thanks,

~David

Re: [julia-users] Re: What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[ivo welch]

On Fri, Dec 5, 2014 at 6:47 PM, Páll Haraldsson 
wrote:

> All joking aside, you got me intrigued. If there is no good language, then
> what is it you want? Why is web-programming special? And wouldn't Julia be
> as least as good a fit (for server side) as any other language?
>

​I do not want to hijack the julia list, so I will be short.

imho, a web language should allow you to pretend that you are programming
the GUI on a single desktop.  the web is special: the app is not running on
one computer, but on one client and one server, and they are glued together
by many protocols, not just one [like X].  the (compiled) language output
should be transparent and generate all the html5/javascript/ajax/cgi/etc.
necessary to implement the tasks.think "intelligent Tk" that can work
server/client on the web, if you wish.  a GUI designer could itself then be
integrated to make it even better.

one should not have to write both server-side cgi programs and client-side
javascript for one application.  one should not even have to learn
javascript...


Ivo Welch (ivo.we...@gmail.com)
http://www.ivo-welch.info/

Re: [julia-users] Reviewing a Julia programming book for Packt

[elextr]

Have had the same problem with other open source projects I participate in, 
they spam anybody prominent on the ML or github.

The resulting books seem to contain large parts consisting of the projects 
manuals, often verbatim.

Cheers
Lex

On Saturday, December 6, 2014 3:45:19 AM UTC+10, Stefan Karpinski wrote:
>
> Yes, as the contact has been so relentlessly spammy, I've started to treat 
> it as spam.
>
> On Fri, Dec 5, 2014 at 12:23 PM, Iain Dunning  > wrote:
>
>> I also refused to review for them, both in this new wave of spam and the 
>> previous one, on the basis that I don't think such a book should exist 
>> (yet). I also felt that by being a reviewer, I'm authorizing the use of my 
>> name for a product I have no control over (they can just ignore what you 
>> say). They seem like a bunch of crooks to be honest.
>
>
>

[julia-users] Re: Redefinition of type problem in IJulia an REPL

[elextr]

You didn't export Foo from the module.

Cheers
Lex

On Saturday, December 6, 2014 3:23:26 AM UTC+10, Greg Trzeciak wrote:
>
> While developing in IJulia notebook (and REPL) if I need to redefine a 
> type I am informed of "invalid redefinition of constant". According to 
> http://julia.readthedocs.org/en/latest/manual/faq/ the types in module 
> Main cannot be redefined and as a workaround it suggests wrapping the code 
> inside the module. But if I do:
> In[1]:
> module Mod1
>
> type Foo
> name::String
> end
> a = Foo("bar")
> println(a.name)
> end
>
> How can I get access to Types defined in In[1]
>
> eg. In[2]:
> using Mod1
> b = Foo("bar")
> println(b.name)
>
> ERROR: Foo not defined
>
> I tried using, export, import, importall to no avail and placing the code 
> in the .jl file and using include("something.jl") is not an "an excellent 
> workaround" because it defies the purpose of using notebook.
>
> I know I can restart the kernel but it is not too practical to do too 
> often.
>
>
>
>
>
>

Re: [julia-users] Selecting all items in array larger than a given number

[ggggg]

>
> *julia> **testarray2=testarray[testarray.>0.1]*
>
> *2-element Array{Float64,1}:*
>
> * 0.2*
>
> * 0.3*
>

Note the .> which is the broadcasting version of > 

Re: [julia-users] Selecting all items in array larger than a given number

[Tracy Wadleigh]

r/find/filter/

On Fri, Dec 5, 2014 at 5:32 PM,  wrote:

> Hi,
>
> Quick question.
>
> Say I have an array
>
> testarray = [0.1,0.2,0.3]
>
>
> Now, using an array comprehension, how could I create an array featuring
> all members of testarray > 0.1?
>
> I tried
>
> testarray2 = [testarray[i] > 0.1 for i=1:length(testarray)]
>
> and
>
> testarray2 = find(x -> x > 0.1,testarray)
>
> but neither of those worked to create
>
> testarray2 = [0.2,0.3]
>
>
> Thanks.
>

[julia-users] Selecting all items in array larger than a given number

[yaoismyhero]

Hi,

Quick question.

Say I have an array

testarray = [0.1,0.2,0.3]


Now, using an array comprehension, how could I create an array featuring 
all members of testarray > 0.1?

I tried 

testarray2 = [testarray[i] > 0.1 for i=1:length(testarray)]

and 

testarray2 = find(x -> x > 0.1,testarray)

but neither of those worked to create

testarray2 = [0.2,0.3] 


Thanks. 

[julia-users] Initializing a SharedArray Memory Error

[benFranklin]

Hi all, I'm trying to figure out how to best initialize a SharedArray, 
using a C function to fill it up that computes a huge matrix in parts, and 
all comments are appreciated. To summarise: Is A, making an empty shared 
array, computing the matrix in parallel using pmap and then filling it up 
serially, better than using B, computing in parallel and storing in one 
step by using an init function in the SharedArray declaration?


The difference tends to be that B uses a lot more memory, each process 
using the exact same amount of memory. However it is much faster than A, as 
the copy step takes longer than the computation, but in A most of the 
memory usage is in one process, using less memory overall.

Any tips on how to do this better? Also, this pmap is how I'm handling more 
complex paralellizations in Julia. Any comments on that approach?

Thanks a lot!

Best,
Ben


CODE A:

Is this, making an empty shared array, computing the matrix in parallel and 
then filling it up serially:

function findZeroDividends(model::ModelPrivate)

nW = length(model.vW)
nZ = length(model.vZ)
nK = length(model.vK)
nQ = length(model.vQ)
 zeroMatrix = SharedArray(Float64,(nW,nZ,nK,nQ,nQ,nQ),pids=workers())

input = [stateFindZeroK(w,z,k,model) for w in 1:nW, z in 1:nZ,  k in 1:nK];
results = pmap(findZeroInC,input);

for w in 1:nW
for z in 1:nZ
for k in 1:nK

zeroMatrix[w,z,k,:,:,:] = results[w + nW*((z-1) + nZ*(k-1))]
 end
end
end

return zeroMatrix
end

___

CODE B:

Better than these two:

function 
start(x::SharedArray,nW::Int64,nZ::Int64,nK::Int64,model::ModelPrivate)

for j in myid()-1:nworkers():(nW*nZ*nK)
inds = ind2sub((nW,nZ,nK),j)
x[inds[1],inds[2],inds[3],:,:,:] 
=findZeroInC(stateFindZeroK(inds[1],inds[2],inds[3],model))
end

x

end

function findZeroDividendsSmart(model::ModelPrivate)

nW = length(model.vW)
nZ = length(model.vZ)
nK = length(model.vK)
nQ = length(model.vQ)

#input = [stateFindZeroK(w,z,k,model) for w in 1:nW, z in 1:nZ,  k in 1:nK];
#results = pmap(findZeroInC,input);

zeroMatrix = SharedArray(Float64,(nW,nZ,nK,nQ,nQ,nQ),pids=workers(), init = 
x->start(x,nW,nZ,nK,model) )

return zeroMatrix
end



The C function being called is inside this wrapper and returns the pointer 
to  double *capitalChoices = (double *)malloc(sizeof(double)*nQ*nQ*nQ);

function findZeroInC(state::stateFindZeroK)

w = state.wealth
z = state.z
k = state.k
model = state.model

#findZeroInC(double wealth, int z,int k,  double theta, double delta, 
 double* vK,
# int nK, double* vQ, int nQ, double* transition, double betaGov)

nQ = length(model.vQ)

t = ccall((:findZeroInC,"findP.so"), 
Ptr{Float64},(Float64,Int64,Int64,Float64,Float64,Ptr{Float64},Int64,Ptr{Float64},Int64,Ptr{Float64},Float64),
model.vW[w],z-1,k-1,model.theta,model.delta,model.vK,length(model.vK),model.vQ,nQ,model.transition,model.betaGov)
if t == C_NULL
error("NULL")
end

return pointer_to_array(t,(nQ,nQ,nQ),true)

end

Re: [julia-users] Re: What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Jeff Waller]

On Friday, December 5, 2014 12:43:20 PM UTC-5, Steven G. Johnson wrote:
>
> On Friday, December 5, 2014 9:57:42 AM UTC-5, Sebastian Nowozin wrote:
>>
>> I find Julia great, but for the technical computing goal, my biggest 
>> grime with Julia (0.3.3 and 0.4.0-dev) at the moment is the lack of simple 
>> OpenMP-style parallelism.
>>
>
> See the discussion at:
>   https://github.com/JuliaLang/julia/issues/1790
> and the considerable work in progress on multithreading in Julia:
>   https://github.com/JuliaLang/julia/tree/threads
>
> There is DArray and pmap, but they have large communication overheads for 
>> shared-memory parallelism,
>>
>
> This is a somewhat orthogonal issue.  You can have multiple processes and 
> still use a shared address space for data structures.  See:
>
>
> http://julia.readthedocs.org/en/latest/manual/parallel-computing/#shared-arrays-experimental
>  
>
> The real difference is the programming model, not so much the 
> communications cost.
>

I think you're right that the interesting thing for a language is the 
model, but at the same time
for problems that are too big to reside on 1 machine, you can't ignore the 
communications.

I feel the grail here is to do map-reduce with the bare minimum of language 
elements and hosts
as first-class is too much.  

If I can draw an analogy for a 2-levels removed analogy, what language 
elements guarantee 
@simd will vectorize anything that could possibly be vectorized and what 
will it take to make
@simd completely unnecessary.  In the same way what will it take to make a 
problem
automatically decomposable across hosts in a reasonable way.  Assuming 
everything can
fit on 1 machine is too limiting, but it's so convenient.  

I seems like Julia as a language among other things is predicated on LLVM 
being able to figure
out how to vectorize, and introducing the minimum elements for LLVM to do 
its thing; in this
case typing and immutability and JIT, and from Jacob's graph, looks like 
that was a pretty good
idea.

How about multi-host parallelism?

Re: [julia-users] Re: How should one think about cost of multiple dispatch?

[Tim Holy]

No cheating!

--Tim

On Friday, December 05, 2014 08:50:36 PM Mike Innes wrote:
> I can close that issue for a case of beer, although I can't promise to
> actually fix it.
> 
> On 5 December 2014 at 20:49, Tim Holy  wrote:
> > Sounds like a bargain...count me in for a bottle.
> > 
> > --Tim
> > 
> > On Friday, December 05, 2014 03:22:18 PM Stefan Karpinski wrote:
> > > Make it a bottle of bourbon and we're talking.
> > > 
> > > On Fri, Dec 5, 2014 at 3:21 PM, Jameson Nash  wrote:
> > > > I'll buy you a case of beer if you can close that issue
> > > > 
> > > > On Fri, Dec 5, 2014 at 2:58 PM Stefan Karpinski 
> > > > 
> > > > wrote:
> > > >> https://github.com/JuliaLang/julia/issues/265 – I'd really like to
> > 
> > fix
> > 
> > > >> this.
> > > >> 
> > > >> On Fri, Dec 5, 2014 at 2:09 PM, Páll Haraldsson <
> > > >> 
> > > >> pall.haralds...@gmail.com> wrote:
> > > >>> On Friday, December 5, 2014 5:25:18 PM UTC, Steven G. Johnson wrote:
> > >  There is no runtime overhead in cases where the types are known at
> > >  compile time.
> > > >>> 
> > > >>> Be aware of one thing, say you define:
> > > >>> 
> > > >>> f(x, y) = 1 + 2p(x)y; p(x) = 2x^2 + 1;
> > > >>> 
> > > >>> You will get the same code even as if you defined p first. UNLESS
> > > >>> you
> > > >>> try to run f first by accident (or intentionally as I did). Then at
> > > >>> compile time you get complicated assembly code (and an error).
> > > >>> 
> > > >>> Then if you define p then f is already defined and now works and
> > > >>> will
> > > >>> not get reoptimized. This gives slower result in interactive.
> > > >>> 
> > > >>> Best regards,
> > > >>> Palli.

Re: [julia-users] Re: How should one think about cost of multiple dispatch?

[Mike Innes]

I can close that issue for a case of beer, although I can't promise to
actually fix it.

On 5 December 2014 at 20:49, Tim Holy  wrote:

> Sounds like a bargain...count me in for a bottle.
>
> --Tim
>
> On Friday, December 05, 2014 03:22:18 PM Stefan Karpinski wrote:
> > Make it a bottle of bourbon and we're talking.
> >
> > On Fri, Dec 5, 2014 at 3:21 PM, Jameson Nash  wrote:
> > > I'll buy you a case of beer if you can close that issue
> > >
> > > On Fri, Dec 5, 2014 at 2:58 PM Stefan Karpinski 
> > >
> > > wrote:
> > >> https://github.com/JuliaLang/julia/issues/265 – I'd really like to
> fix
> > >> this.
> > >>
> > >> On Fri, Dec 5, 2014 at 2:09 PM, Páll Haraldsson <
> > >>
> > >> pall.haralds...@gmail.com> wrote:
> > >>> On Friday, December 5, 2014 5:25:18 PM UTC, Steven G. Johnson wrote:
> >  There is no runtime overhead in cases where the types are known at
> >  compile time.
> > >>>
> > >>> Be aware of one thing, say you define:
> > >>>
> > >>> f(x, y) = 1 + 2p(x)y; p(x) = 2x^2 + 1;
> > >>>
> > >>> You will get the same code even as if you defined p first. UNLESS you
> > >>> try to run f first by accident (or intentionally as I did). Then at
> > >>> compile time you get complicated assembly code (and an error).
> > >>>
> > >>> Then if you define p then f is already defined and now works and will
> > >>> not get reoptimized. This gives slower result in interactive.
> > >>>
> > >>> Best regards,
> > >>> Palli.
>
>

Re: [julia-users] Re: How should one think about cost of multiple dispatch?

[Tim Holy]

Sounds like a bargain...count me in for a bottle.

--Tim

On Friday, December 05, 2014 03:22:18 PM Stefan Karpinski wrote:
> Make it a bottle of bourbon and we're talking.
> 
> On Fri, Dec 5, 2014 at 3:21 PM, Jameson Nash  wrote:
> > I'll buy you a case of beer if you can close that issue
> > 
> > On Fri, Dec 5, 2014 at 2:58 PM Stefan Karpinski 
> > 
> > wrote:
> >> https://github.com/JuliaLang/julia/issues/265 – I'd really like to fix
> >> this.
> >> 
> >> On Fri, Dec 5, 2014 at 2:09 PM, Páll Haraldsson <
> >> 
> >> pall.haralds...@gmail.com> wrote:
> >>> On Friday, December 5, 2014 5:25:18 PM UTC, Steven G. Johnson wrote:
>  There is no runtime overhead in cases where the types are known at
>  compile time.
> >>> 
> >>> Be aware of one thing, say you define:
> >>> 
> >>> f(x, y) = 1 + 2p(x)y; p(x) = 2x^2 + 1;
> >>> 
> >>> You will get the same code even as if you defined p first. UNLESS you
> >>> try to run f first by accident (or intentionally as I did). Then at
> >>> compile time you get complicated assembly code (and an error).
> >>> 
> >>> Then if you define p then f is already defined and now works and will
> >>> not get reoptimized. This gives slower result in interactive.
> >>> 
> >>> Best regards,
> >>> Palli.

Re: [julia-users] Documentation in the source code

[Mike Innes]

I'll add some meta-documentation to the manual for this soon.

On 5 December 2014 at 19:58, John Myles White 
wrote:

> Documentation is undergoing a shift as 0.4 will be the first release with
> built-in documentation tools. Check the GitHub issues for details about the
> upcoming @doc macro.
>
>   -- John
>
> On Dec 5, 2014, at 10:40 AM, Petr Krysl  wrote:
>
> > Hello,
> >
> > Does anyone know how the document functions and types (and modules) in
> the "Julia style"?
> >
> > I looked at the source code for some of the Base functions and I
> couldn't really find any documentation attached to those functions.
> >
> > Thanks,
> >
> > Petr
>
>

Re: [julia-users] Re: How should one think about cost of multiple dispatch?

[cdm]

looking forward to reflecting on Julia's youth ...

"remember back in '15, when Karpinski killed the infamous
Bezanson Bourbon Bounty Bug ? ... those were the days."


go well, mate.

cdm


On Friday, December 5, 2014 12:23:00 PM UTC-8, Stefan Karpinski wrote:
>
> Make it a bottle of bourbon and we're talking.
>

Re: [julia-users] Re: How should one think about cost of multiple dispatch?

[Stefan Karpinski]

Make it a bottle of bourbon and we're talking.

On Fri, Dec 5, 2014 at 3:21 PM, Jameson Nash  wrote:

> I'll buy you a case of beer if you can close that issue
>
> On Fri, Dec 5, 2014 at 2:58 PM Stefan Karpinski 
> wrote:
>
>> https://github.com/JuliaLang/julia/issues/265 – I'd really like to fix
>> this.
>>
>> On Fri, Dec 5, 2014 at 2:09 PM, Páll Haraldsson <
>> pall.haralds...@gmail.com> wrote:
>>
>>>
>>>
>>> On Friday, December 5, 2014 5:25:18 PM UTC, Steven G. Johnson wrote:

 There is no runtime overhead in cases where the types are known at
 compile time.

>>>
>>> Be aware of one thing, say you define:
>>>
>>> f(x, y) = 1 + 2p(x)y; p(x) = 2x^2 + 1;
>>>
>>> You will get the same code even as if you defined p first. UNLESS you try 
>>> to run f first by accident (or intentionally as I did). Then at compile 
>>> time you get complicated assembly code (and an error).
>>>
>>> Then if you define p then f is already defined and now works and will not 
>>> get reoptimized. This gives slower result in interactive.
>>>
>>> Best regards,
>>> Palli.
>>>
>>>
>>

Re: [julia-users] Re: How should one think about cost of multiple dispatch?

[Jameson Nash]

I'll buy you a case of beer if you can close that issue
On Fri, Dec 5, 2014 at 2:58 PM Stefan Karpinski 
wrote:

> https://github.com/JuliaLang/julia/issues/265 – I'd really like to fix
> this.
>
> On Fri, Dec 5, 2014 at 2:09 PM, Páll Haraldsson  > wrote:
>
>>
>>
>> On Friday, December 5, 2014 5:25:18 PM UTC, Steven G. Johnson wrote:
>>>
>>> There is no runtime overhead in cases where the types are known at
>>> compile time.
>>>
>>
>> Be aware of one thing, say you define:
>>
>> f(x, y) = 1 + 2p(x)y; p(x) = 2x^2 + 1;
>>
>> You will get the same code even as if you defined p first. UNLESS you try to 
>> run f first by accident (or intentionally as I did). Then at compile time 
>> you get complicated assembly code (and an error).
>>
>> Then if you define p then f is already defined and now works and will not 
>> get reoptimized. This gives slower result in interactive.
>>
>> Best regards,
>> Palli.
>>
>>
>

Re: [julia-users] Documentation in the source code

[John Myles White]

Documentation is undergoing a shift as 0.4 will be the first release with 
built-in documentation tools. Check the GitHub issues for details about the 
upcoming @doc macro.

  -- John

On Dec 5, 2014, at 10:40 AM, Petr Krysl  wrote:

> Hello,
> 
> Does anyone know how the document functions and types (and modules) in the 
> "Julia style"?
> 
> I looked at the source code for some of the Base functions and I couldn't 
> really find any documentation attached to those functions.
> 
> Thanks,
> 
> Petr

Re: [julia-users] Re: How should one think about cost of multiple dispatch?

[Stefan Karpinski]

https://github.com/JuliaLang/julia/issues/265 – I'd really like to fix this.

On Fri, Dec 5, 2014 at 2:09 PM, Páll Haraldsson 
wrote:

>
>
> On Friday, December 5, 2014 5:25:18 PM UTC, Steven G. Johnson wrote:
>>
>> There is no runtime overhead in cases where the types are known at
>> compile time.
>>
>
> Be aware of one thing, say you define:
>
> f(x, y) = 1 + 2p(x)y; p(x) = 2x^2 + 1;
>
> You will get the same code even as if you defined p first. UNLESS you try to 
> run f first by accident (or intentionally as I did). Then at compile time you 
> get complicated assembly code (and an error).
>
> Then if you define p then f is already defined and now works and will not get 
> reoptimized. This gives slower result in interactive.
>
> Best regards,
> Palli.
>
>

[julia-users] Re: How should one think about cost of multiple dispatch?

[Páll Haraldsson]

On Friday, December 5, 2014 5:25:18 PM UTC, Steven G. Johnson wrote:
>
> There is no runtime overhead in cases where the types are known at compile 
> time.
>

Be aware of one thing, say you define:

f(x, y) = 1 + 2p(x)y; p(x) = 2x^2 + 1;

You will get the same code even as if you defined p first. UNLESS you try to 
run f first by accident (or intentionally as I did). Then at compile time you 
get complicated assembly code (and an error).

Then if you define p then f is already defined and now works and will not get 
reoptimized. This gives slower result in interactive.

Best regards,
Palli.

[julia-users] Documentation in the source code

[Petr Krysl]

Hello,

Does anyone know how the document functions and types (and modules) in the 
"Julia style"?

I looked at the source code for some of the Base functions and I couldn't 
really find any documentation attached to those functions.

Thanks,

Petr

Re: [julia-users] Re: How should one think about cost of multiple dispatch?

[Stefan Karpinski]

If you do end up in a situation where type inference can't figure out what
method to call, dispatch can get kind of slow, but it's still comparable to
method calls in Python or Ruby. It turns out that by expressing polymorphic
behaviors with multiple dispatch, the programmer somewhat unwittingly
provides a lot of great type information to the compiler. Typed data
structures like typed arrays and structs with typed fields, also gives a
lot of good type information. Between these two sources, type inference can
generally figure out the types of things pretty well. When Jeff did some
experiments he found that about 60% of expressions end up concretely typed
(for some completely arbitrary but non-trivial code). There's also a
positive correlation between how performance-critical code is and how
"well-typed" it is: high-level code that's pulling data from external
sources and using loosely typed data structures tends not to be performance
critical; tight inner loops tend to involve fairly simple operations on
values with predictable types. This is basically the classic division of
using a high-level dynamic language for "business logic" and a low-level
static language for performance-sensitive code, but instead of using two
languages, you can use one and the difference is just a matter of coding
style.

On Fri, Dec 5, 2014 at 12:25 PM, Steven G. Johnson 
wrote:

> There is no runtime overhead in cases where the types are known at compile
> time.   In terms of performance, the key thing to understand about Julia is:
>
> * The first time you call a function f(x,y) with a given set of argument
> types, Julia compiles a new version of f that is specialized (partially
> evaluated) for those argument types (which are propagated as far as
> possible by type inference).   Functions called within f with known types
> (via type inference) are compiled recursively as needed, and possibly
> inlined.
>
> * This compiled version is cached and re-used for subsequent calls with
> the same argument types.
>
> So, for example, consider f(x, y) = x + y, where we know that + is
> extremely overloaded.   If you call f(3,4), it compiles a specialized
> version of f(x,y) specifically for Int arguments.  The dispatch for + is
> determined at compile time, and in fact is inlined.   The resulting machine
> code is essentially equivalent to what would be produced by a C compiler
> from int64 f(int64 x, int64 y) { return x+y; }, as can be verified by
> running code_native(f, (Int,Int)), which produces:
>
> pushRBP
> movRBP, RSP
> addRDI, RSI
> movRAX, RDI
> popRBP
> ret
>
> The next time you call f with integer arguments, e.g. f(7,12), this
> compiled code is re-used.   If you call f with a different set of argument
> types, e.g. f(3.5, 2.7), then it compiles a different version of f
> specialized for those argument types.  At this point, Julia has both the
> (Int,Int) and the (Float64,Float64) compiled versions cached.
>
> Similarly, if you define another function g(x,y) = x + f(x,y) and then
> call g(3,4), the compiled version of g will call the precompiled f(Int,Int)
> code [or actually it will probably inline it], with no runtime dispatch.
>
> --SGJ
>

Re: [julia-users] julia literals for bittypes

[Stefan Karpinski]

Hex literals are unsigned and take their size from the number of digits.

On Fri, Dec 5, 2014 at 10:24 AM, John Myles White 
wrote:

> 0x03
>
>  — John
>
> On Dec 5, 2014, at 3:17 AM, Francesco  wrote:
>
> > When I write:
> >
> > julia> x = 3
> >
> > I assign to x a Int64 by default.
> >
> > julia> typeof(x)
> > Int64
> >
> > Let say that 3 should be Uint8, then I write:
> > julia> x = convert(Uint8, 3)
> >
> > Is there a more idiomatic way of doing it?
> > Maybe with literals?
>
>

Re: [julia-users] why are variables not local by default?

[Stefan Karpinski]

What would you expect an assignment at global scope to do? If it created a
local variable, what scope would it be local to?

On Fri, Dec 5, 2014 at 8:41 AM, John Drummond  wrote:

> Thanks. I missed a couple of those links, though I did try seaching.
> Yes I'd read the last performance tips, but what I hadn't found was why it
> wasn't harder to have global variables or in what cases they'd be essential.
>
>
> On Friday, December 5, 2014 1:06:19 PM UTC, Isaiah wrote:
>>
>> See the discussions in
>> http://julia.readthedocs.org/en/release-0.3/manual/performance-tips/
>> https://github.com/JuliaLang/julia/issues/524
>> https://github.com/JuliaLang/julia/issues/8870
>> (and elsewhere)
>>
>>
>> On Fri, Dec 5, 2014 at 7:13 AM, John Drummond  wrote:
>>
>>> I suspect I'm missing something here.
>>>
>>> I had a simple script to strip out nuls from a text file.
>>> placing a let at the beginning and end at the end resulted in a 70 times
>>> speed up.
>>>
>>> I'm wondering what the reason is that there isn't the equivalent of a
>>> let end wrapped around everything, and where global variables have to be
>>> used they have to be specifically declared as such?
>>>
>>>
>>>
>>>
>>

Re: [julia-users] Reviewing a Julia programming book for Packt

[Stefan Karpinski]

Yes, as the contact has been so relentlessly spammy, I've started to treat
it as spam.

On Fri, Dec 5, 2014 at 12:23 PM, Iain Dunning  wrote:

> I also refused to review for them, both in this new wave of spam and the
> previous one, on the basis that I don't think such a book should exist
> (yet). I also felt that by being a reviewer, I'm authorizing the use of my
> name for a product I have no control over (they can just ignore what you
> say). They seem like a bunch of crooks to be honest.

Re: [julia-users] Re: What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Steven G. Johnson]

On Friday, December 5, 2014 9:57:42 AM UTC-5, Sebastian Nowozin wrote:
>
> I find Julia great, but for the technical computing goal, my biggest grime 
> with Julia (0.3.3 and 0.4.0-dev) at the moment is the lack of simple 
> OpenMP-style parallelism.
>

See the discussion at:
  https://github.com/JuliaLang/julia/issues/1790
and the considerable work in progress on multithreading in Julia:
  https://github.com/JuliaLang/julia/tree/threads

There is DArray and pmap, but they have large communication overheads for 
> shared-memory parallelism,
>

This is a somewhat orthogonal issue.  You can have multiple processes and 
still use a shared address space for data structures.  See:

   
http://julia.readthedocs.org/en/latest/manual/parallel-computing/#shared-arrays-experimental
 


The real difference is the programming model, not so much the 
communications cost.

Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Páll Haraldsson]

On Friday, December 5, 2014 4:58:44 PM UTC, Mike Innes wrote:
>
> I suspect Tim's idea was to help out by closing issues, not by opening 
> them.
>

I guess :)

I took a look and there were pages of issues (including the PhD one.. :) 
You seem to have succeeded in making an awesome language. I'm mainly 
interested in the less math-heavy issues to enable Julia use for mere 
mortals/non-typical uses. See my post in julia-dev.

Best regards,
Palli.

[julia-users] Re: How should one think about cost of multiple dispatch?

[Steven G. Johnson]

There is no runtime overhead in cases where the types are known at compile 
time.   In terms of performance, the key thing to understand about Julia is:

* The first time you call a function f(x,y) with a given set of argument 
types, Julia compiles a new version of f that is specialized (partially 
evaluated) for those argument types (which are propagated as far as 
possible by type inference).   Functions called within f with known types 
(via type inference) are compiled recursively as needed, and possibly 
inlined.

* This compiled version is cached and re-used for subsequent calls with the 
same argument types.

So, for example, consider f(x, y) = x + y, where we know that + is 
extremely overloaded.   If you call f(3,4), it compiles a specialized 
version of f(x,y) specifically for Int arguments.  The dispatch for + is 
determined at compile time, and in fact is inlined.   The resulting machine 
code is essentially equivalent to what would be produced by a C compiler 
from int64 f(int64 x, int64 y) { return x+y; }, as can be verified by 
running code_native(f, (Int,Int)), which produces:

pushRBP
movRBP, RSP
addRDI, RSI
movRAX, RDI
popRBP
ret

The next time you call f with integer arguments, e.g. f(7,12), this 
compiled code is re-used.   If you call f with a different set of argument 
types, e.g. f(3.5, 2.7), then it compiles a different version of f 
specialized for those argument types.  At this point, Julia has both the 
(Int,Int) and the (Float64,Float64) compiled versions cached.

Similarly, if you define another function g(x,y) = x + f(x,y) and then call 
g(3,4), the compiled version of g will call the precompiled f(Int,Int) code 
[or actually it will probably inline it], with no runtime dispatch.

--SGJ

[julia-users] Redefinition of type problem in IJulia an REPL

[Greg Trzeciak]

While developing in IJulia notebook (and REPL) if I need to redefine a type 
I am informed of "invalid redefinition of constant". According 
to http://julia.readthedocs.org/en/latest/manual/faq/ the types in module 
Main cannot be redefined and as a workaround it suggests wrapping the code 
inside the module. But if I do:
In[1]:
module Mod1

type Foo
name::String
end
a = Foo("bar")
println(a.name)
end

How can I get access to Types defined in In[1]

eg. In[2]:
using Mod1
b = Foo("bar")
println(b.name)

ERROR: Foo not defined

I tried using, export, import, importall to no avail and placing the code 
in the .jl file and using include("something.jl") is not an "an excellent 
workaround" because it defies the purpose of using notebook.

I know I can restart the kernel but it is not too practical to do too often.

Re: [julia-users] Reviewing a Julia programming book for Packt

[Iain Dunning]

I also refused to review for them, both in this new wave of spam and the 
previous one, on the basis that I don't think such a book should exist (yet). I 
also felt that by being a reviewer, I'm authorizing the use of my name for a 
product I have no control over (they can just ignore what you say). They seem 
like a bunch of crooks to be honest.

Re: [julia-users] Re: What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Jeff Waller]

On Friday, December 5, 2014 5:47:15 AM UTC-5, Páll Haraldsson wrote:
>
>
>
> On Friday, December 5, 2014 1:11:12 AM UTC, ivo welch wrote:
>>
>>
>> there are no good web development language environments (server, browser) 
>> IMHO, and julia will not fit this bill, either.
>>
>
> You are forgetting PHP :)
>
> All joking aside, you got me intrigued. If there is no good language, then 
> what is it you want? Why is web-programming special? And wouldn't Julia be 
> as least as good a fit (for server side) as any other language?
>
> For client side, I was thinking of writing a separate post on that. Julia 
> could work..
>
> Is it a problem that you have separate languages on either side? Then 
> Julia or any language wouldn't be perfect (until Julia works client side, I 
> don't think JavaScript is better for server-side (than Julia) or best for 
> non-web..).
>
> As for server side I had this crazy idea that Julia and PHP could be 
> combined.. I'm not sure what the best way is to get people to stop using 
> PHP and rewriting from scratch isn't good..
>

Nah, man, Javascript!  But of course I'm going to say that.

The main problems with PHP

It's not cool.
It's perceived as slow.

The language elements or lack of language elements can be argued, but those 
things eventually get fixed so long as people remain interested.  I think 
there is value in having the same language on both sides not for technical 
reasons, but because mostly it promotes freedom and free flow of ideas, but 
at the same time, only Sauron was able to fashion the One to Rule Them All, 
and he was a villain. It's not all just a popularity contest either, but 
that's part of it.  It's no good to have a perfect but unpopular language. 
 And anyway who wants just one language for everything? too dull!

Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Mike Innes]

I suspect Tim's idea was to help out by closing issues, not by opening them.

On 5 December 2014 at 15:36, Páll Haraldsson 
wrote:

>
>
> On Friday, December 5, 2014 2:39:11 PM UTC, Tim Holy wrote:
>>
>> I'm glad you're enthusiastic about Julia. If you're looking to pitch in,
>> one
>> good place to look is the list of open issues:
>> https://github.com/JuliaLang/julia/issues
>> If you're most interested in "features," filtering on the "up for grabs"
>> label
>> might be a good start.
>>
>
> I did.. The "issue" was closed and I was pointed to the groups. Anyway I
> noted the Prolog answer in this thread. I have my forth issue comming but
> think I'll post in julia-dev for discussion first as not really a "bug"..
>
>
>> Best,
>> --Tim
>>
>> On Friday, December 05, 2014 06:00:31 AM Páll Haraldsson wrote:
>> > On Friday, December 5, 2014 11:34:46 AM UTC, Tamas Papp wrote:
>> > > On Fri, Dec 05 2014, Páll Haraldsson > >
>> > >
>> > > wrote:
>> > > > On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote:
>> > > >> I find your aversion to femtolisp difficult to understand,
>> probably
>> > > >> because I tend to think of Julia as a Lisp with the following key
>> > > >
>> > > >> features:
>> > > > I don't really have an aversion to femtolisp. I understand it's an
>> > >
>> > > awesome
>> > >
>> > > > implementation of Scheme.
>> > > >
>> > > > If you "think of Julia as a Lisp" (including Scheme, right?) then
>> when
>> > > > would you prefer Lisp (or Scheme) for new things after Julia came
>> along?
>> > >
>> > > Sorry, but did you read my e-mail? As I said, Julia is much more
>> > > optimizable
>> > >
>> > >
>> > >
>> > > with its richer type system, which is a great advantage for
>> > > me. Common Lisp is remarkably nice, but
>> >
>> > Yes I did read it. Note, I meant would you still recommend (Common)
>> Lisp
>> > for anything, you seem to argue well for Julia (and against
>> > "Lisp"/S-expressions while you're at it?). Note also, I said "would you
>> > prefer Lisp (or Scheme)". I know Scheme is a dialect of Lisp and Racket
>> of
>> > Scheme, but am not expert on the differences. I may be grouping all the
>> > Lisps together unfairly. Your objections to Common Lisp may not
>> generalize
>> > to them all.
>> >
>> > Personally, I like S-expressions too, but many people prefer
>> >
>> > > M-expressions, especially for math (they are indeed more compact).
>> >
>> > Is there a good way to call any (or all) of the S-expressions languages
>> > from Julia? I'm not even sure it's important too, there could be lots
>> of
>> > useful preexisting code.
>> >
>> > > >> I am not so
>> > > >> sure that current technology allows a single language to be good
>> at
>> > > >> everything, languages like C seem to be difficult to replace with
>> > > >> dynamic languages in some situations.
>> > >
>> > > These are very abstract points, and I am not sure that discussing
>> them
>> > > as such is very productive. As many have remarked in this thread,
>> > > languages are tools, designed for a given prupose. Is a hammer better
>> > > than a screwdriver? Etc.
>> >
>> > Libraries are also "tools", I'm just not at all convinced we need many
>> > languages (for different "purposes", maybe with very few limited
>> > exceptions) rather than just new libraries. That seems to be a failure
>> of
>> > computer science.
>> >
>> > > > Why? For C, Julia seems already better for almost all users. If
>> > >
>> > > "languages
>> > >
>> > > > like C" means C++, I could see all new code in Julia and C++ as
>> legacy.
>> > > > What other "like C" do you mean?
>> > >
>> > > Again, I am wondering if you actually read the replies to your
>> > > questions. Many have remarked on these issues in their replies to
>> you,
>> > > eg dynamic vs manual memory allocation, etc. C, C++, and Fortran are
>> > > fundamentally different from Julia at the moment.
>> >
>> > I read all the replies (might have missed some). I already mentioned
>> > dynamic memory allocation in my first post as a temporary limitation
>> > (currently would be a problem for very few users/uses). Never
>> programmed in
>> > Fortran but think it also uses manual memory allocation. While Julia
>> uses
>> > those languages in part I think manual is not the reason for their (or
>> > Julia's) speed; in general that they are fundamentally different in a
>> > better way or others. Garbage collection can be hard real-time and fast
>> > (and Julia - the core language wouldn't need changes that break
>> > compatibility).
>> >
>> > or by
>> >
>> > > helping to discover where it could be improved.
>> > >
>> > > Partly why I'm writing this. I want to know what needs improving or
>> if
>> >
>> > something can't be improved, unless breaking things in a minor way or
>> > fundamentally that Julia can't work.
>> >
>> > > Frankly, I don't understand your decision problem -- are you trying
>> to
>> > > decide whether to invest learning in Julia vs some other language?
>> Even
>> > > though that question does 

Re: [julia-users] Re: Julia as a matlab mex function (and the struggle for independence from cygwin)

[Tim Holy]

Sounds good. It would be for interop in both ways, then.

--Tim

On Friday, December 05, 2014 08:40:39 AM Tracy Wadleigh wrote:
> Rather than doing my own package, I think it makes more sense to try to add
> this functionality to the existing MATLAB.jl package, where, for instance,
> they already have mxArray marshaling.

Re: [julia-users] How should one think about cost of multiple dispatch?

[Isaiah Norton]

Jeff talked about some of the implementation details in his JuliaCon
presentation (see around :22 and :29 at least):
https://www.youtube.com/watch?v=osdeT-tWjzk

At a slightly higher level, Stefan's notebook is very informative:
http://nbviewer.ipython.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22

(for some reason InfoQ still hasn't unlocked the associated talk video)

On Fri, Dec 5, 2014 at 11:45 AM, John Myles White 
wrote:

> I think you'll want an answer from Stefan, Jeff, Keno, Jameson or Viral to
> get a better review, but my sense is that multiple dispatch is primarily
> costly at compile time and pays close to zero cost at run-time. Within a
> function body, if the types of variables don't change, then the choice of
> which methods for "+" to call are already perfectly determined by the time
> the function body is being exeuted.
>
>  -- John
>
> On Dec 5, 2014, at 8:41 AM, Ronald L. Rivest  wrote:
>
> > Multiple dispatch is a unique and interesting feature of Julia...
> >
> > How is it implemented?
> >
> > What is the overhead incurred by multiple dispatch?  (Esp. if there are
> a large
> > number of methods, as for "+" ?).
> >
> > Cheers,
> > Ron
>
>

[julia-users] How should one think about cost of multiple dispatch?

[Ronald L. Rivest]

Multiple dispatch is a unique and interesting feature of Julia...

How is it implemented? 

What is the overhead incurred by multiple dispatch?  (Esp. if there are a 
large
number of methods, as for "+" ?).

Cheers,
Ron

Re: [julia-users] How should one think about cost of multiple dispatch?

[John Myles White]

I think you'll want an answer from Stefan, Jeff, Keno, Jameson or Viral to get 
a better review, but my sense is that multiple dispatch is primarily costly at 
compile time and pays close to zero cost at run-time. Within a function body, 
if the types of variables don't change, then the choice of which methods for 
"+" to call are already perfectly determined by the time the function body is 
being exeuted.

 -- John

On Dec 5, 2014, at 8:41 AM, Ronald L. Rivest  wrote:

> Multiple dispatch is a unique and interesting feature of Julia...
> 
> How is it implemented? 
> 
> What is the overhead incurred by multiple dispatch?  (Esp. if there are a 
> large
> number of methods, as for "+" ?).
> 
> Cheers,
> Ron

Re: [julia-users] Re: Julia as a matlab mex function (and the struggle for independence from cygwin)

[Tracy Wadleigh]

Rather than doing my own package, I think it makes more sense to try to add 
this functionality to the existing MATLAB.jl package, where, for instance, 
they already have mxArray marshaling.

Re: [julia-users] Reviewing a Julia programming book for Packt

[Jacob Quinn]

Sorry to hear that Evan. I'll look out for that.

-Jacob

On Fri, Dec 5, 2014 at 10:47 AM, cdm  wrote:

>
> gratis or libre ... ?
>
> On Thursday, December 4, 2014 5:35:52 PM UTC-8, John Myles White wrote:
>>
>> I hate to say it, but Packt's handling of its Julia publications is
>> rather troubling. I received a request to review this book and told them I
>> wasn't free, but the truth is that I would prefer that they not pubilsh
>> this kind of book at all right now. The blurb refers to several things that
>> may not even exist in JuliaStats, including lists, factors and ANOVA's. I
>> think the whole thing is premature.
>>
>>  -- John
>>
>

Re: [julia-users] type conversion in array comprehension

[Kevin Squire]

It might just be that you're working in global scope, where the compiler
isn't able to verify that the type of k won't change.  What happens when
you wrap that code in a function?

Hopefully this behavior will change eventually (see
https://github.com/JuliaLang/julia/issues/8870), since it's asked about on
this list frequently.  In the mean time, a gander through the performance
tips section of the manual might be worthwhile.

Cheers!
   Kevin

On Fri, Dec 5, 2014 at 1:06 AM, Andrew Ellis  wrote:

>
>
> I'm trying to construct an array of Dicts (Dict{Symbol,Any}, to be used as
> initial values for MCMC chains by the Mamba package). The following problem
> doesn't appear to have anything to do with Mamba, though.
>
>
> julia> using Distributions
>
> The following works, i.e. autoamatic conversion works: rand(Binomial(50,
> 0.75)) will returns an Int64 and 34.3 is a Float64
>
> julia> inits = [[:k => rand(Binomial(50, 0.75)), :j => 34.3] for i in 1:2]
> 2-element Array{Dict{Symbol,Any},1}:
>  [:j=>34.3,:k=>39]
>  [:j=>34.3,:k=>42]
>
>
> This also works:
>
> julia> k= rand(Binomial(50, 0.75))
> 42
>
> julia> typeof(k)
> Int64
>
> julia> inits = [[:k => k, :j => 34.3]]
> 1-element Array{Dict{Symbol,Any},1}:
>  [:j=>34.3,:k=>42]
>
> But this doesn't, i.e. automatic type conversion doesn't work:
>
> julia> inits = [[:k => k, :j => 34.3] for i in 1:nchains]
> 3-element Array{Union(Dict{Symbol,Float64},Dict{Symbol,Any}),1}:
>  [:j=>34.3,:k=>42]
>  [:j=>34.3,:k=>42]
>  [:j=>34.3,:k=>42]
>
>
> If I specify the type, it works:
> julia> inits = [(Symbol => Any)[:k => k, :j => 34.3] for i in 1:nchains]
>
> I'm using:
>
> julia> versioninfo()
> Julia Version 0.3.3
> Commit b24213b* (2014-11-23 20:19 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin13.3.0)
>   CPU: Intel(R) Core(TM) i7-4558U CPU @ 2.80GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> Am I doing anything wrong?
>
> Cheers,
> Andrew
>

Re: [julia-users] Reviewing a Julia programming book for Packt

[cdm]

gratis or libre ... ?

On Thursday, December 4, 2014 5:35:52 PM UTC-8, John Myles White wrote:
>
> I hate to say it, but Packt's handling of its Julia publications is rather 
> troubling. I received a request to review this book and told them I wasn't 
> free, but the truth is that I would prefer that they not pubilsh this kind 
> of book at all right now. The blurb refers to several things that may not 
> even exist in JuliaStats, including lists, factors and ANOVA's. I think the 
> whole thing is premature.
>
>  -- John
>

Re: [julia-users] Re: DataFrames and NamedArrays: are they suitable for heavier computations ?

[Tom Short]

For DataFrames, it depends on what you want to do. It is difficult to get
performance with DataArrays as columns using the current implementation.
With the ongoing work by John Myles White on the use of a Nullable type,
that should be much better. Also, you can use standard Arrays as columns of
a DataFrame. It's not documented well, but it can be done.

Also, if you want to treat a DataFrame like a matrix, then generally the
answer is no. With some "trickery", you can store a view to a matrix in a
DataFrame. Basically, you have to create column views into the matrix. Here
is an example. It might be useful if you want to treat all or part of a
DataFrame as a matrix.

julia> using DataFrames

julia> m = rand(5,5)
5x5 Array{Float64,2}:
 0.186736  0.247699   0.0968634  0.471383   0.145244
 0.985306  0.966015   0.663865   0.0468244  0.0471465
 0.981947  0.707241   0.0841202  0.0539529  0.692217
 0.918222  0.0415162  0.646298   0.581983   0.653881
 0.515692  0.0344289  0.0821672  0.877258   0.653756

julia> d = DataFrame(Any[sub(m, :, i) for i in 1:size(m, 2)], [:a, :b, :c,
:d, :e])
5x5 DataFrames.DataFrame
| Row | a| b | c | d | e |
|-|--|---|---|---|---|
| 1   | 0.186736 | 0.247699  | 0.0968634 | 0.471383  | 0.145244  |
| 2   | 0.985306 | 0.966015  | 0.663865  | 0.0468244 | 0.0471465 |
| 3   | 0.981947 | 0.707241  | 0.0841202 | 0.0539529 | 0.692217  |
| 4   | 0.918222 | 0.0415162 | 0.646298  | 0.581983  | 0.653881  |
| 5   | 0.515692 | 0.0344289 | 0.0821672 | 0.877258  | 0.653756  |

julia> d[:b]
5-element SubArray{Float64,1,Array{Float64,2},(Colon,Int64),2}:
 0.247699
 0.966015
 0.707241
 0.0415162
 0.0344289



On Fri, Dec 5, 2014 at 8:37 AM, Tim Holy  wrote:

> The new SubArrays steal mercilessly from the good ideas of both the old
> SubArray and ArrayViews, and then add some new tricks of their own. In
> theory,
> they should be a strict improvement on both of their predecessors.
>
> --Tim
>
> On Friday, December 05, 2014 05:13:28 AM David van Leeuwen wrote:
> > So what is the relation between ArrayViews and 0.4 `SubArray revamp'?
>  Are
> > they targeting different use cases or is one of them going to be phased
> > out?
> >
> > On Friday, December 5, 2014 1:28:16 PM UTC+1, Tim Holy wrote:
> > > In 0.4, the views are a revamp of SubArray. So if NamedArrays already
> > > interacts well with SubArrays, you're basically set.
> > >
> > > Most likely not, as SubArrays are new to me (I've tried sub() in
> >
> > production code in the past, but it was always better to write out a
> > loop)).
> >
> > > FYI the implementation in 0.4 is largely backwards-compatible, but
> there
> > > are
> > > some important differences. If you need to dig into the internal
> > > implementation
> > > of SubArrays, you can find documentation on the changes for 0.4 here:
> > > http://docs.julialang.org/en/latest/devdocs/subarrays/
> > >
> > > OK, I'll have to study this in order to understand the implications for
> >
> > NamedArrays.
> >
> > ---david
> >
> > > --Tim
> > >
> > > On Friday, December 05, 2014 04:18:08 AM David van Leeuwen wrote:
> > > > Hi,
> > > >
> > > > On Friday, December 5, 2014 8:47:22 AM UTC+1, Ján Dolinský wrote:
> > > > > Hi,
> > > > >
> > > > > I am exploring DataFrames and NamedArrays packages and I would
> like to
> > >
> > > ask
> > >
> > > > > whether their are suitable for heavier computations and whether I
> can
> > >
> > > use
> > >
> > > > > them directly in BLAS calls (e.g. gemv() etc.). In addition, is it
> > > > > possible
> > > > > to create views of e.g. DataFrames or NamedArrays ?
> > > > >
> > > > > I can only speak for NamedArrays.  On the one hand the deployment
> of
> > >
> > > BLAS
> > >
> > > > should be transparant and the use of NamedArray vs Array not lead to
> > >
> > > much
> > >
> > > > degradation in performance.  E.g., "a * b" with `a` and `b` a
> > >
> > > NamedArray,
> > >
> > > > effectively calls "a.array * b.array" which Base implements with
> > > > BLAS.gemm().  There is just a little overhead of filling in sensible
> > >
> > > names
> > >
> > > > in the result---so if you have small matrices in an inner loop,
> you're
> > > > going to get hurt.
> > > >
> > > > On the other hand, I am not sure how much of the Julia BLAS
> cleverness
> > >
> > > is
> > >
> > > > retained in NamedArrays---but the intention of the package is that
> it is
> > > > completely transparent, and if you notice bad performance for a
> > >
> > > particular
> > >
> > > > situation then you should file an issue (or make a PR:-).  Individual
> > > > element indexing of a NamedArray with integers is just a little bit
> > >
> > > slower
> > >
> > > > than that of an Array.  Indexing by name is quite a bit slower---you
> may
> > > > try a different Associative than the standard Dict.
> > > >
> > > > Incidentally, I've been toying with the idea of NamedArrays `*`
> check on
> > > > consistency of index and dimension names, but my 

Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Páll Haraldsson]

On Friday, December 5, 2014 2:39:11 PM UTC, Tim Holy wrote:
>
> I'm glad you're enthusiastic about Julia. If you're looking to pitch in, 
> one 
> good place to look is the list of open issues: 
> https://github.com/JuliaLang/julia/issues 
> If you're most interested in "features," filtering on the "up for grabs" 
> label 
> might be a good start.
>

I did.. The "issue" was closed and I was pointed to the groups. Anyway I 
noted the Prolog answer in this thread. I have my forth issue comming but 
think I'll post in julia-dev for discussion first as not really a "bug"..


> Best, 
> --Tim 
>
> On Friday, December 05, 2014 06:00:31 AM Páll Haraldsson wrote: 
> > On Friday, December 5, 2014 11:34:46 AM UTC, Tamas Papp wrote: 
> > > On Fri, Dec 05 2014, Páll Haraldsson  > 
> > > 
> > > wrote: 
> > > > On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote: 
> > > >> I find your aversion to femtolisp difficult to understand, probably 
> > > >> because I tend to think of Julia as a Lisp with the following key 
> > > > 
> > > >> features: 
> > > > I don't really have an aversion to femtolisp. I understand it's an 
> > > 
> > > awesome 
> > > 
> > > > implementation of Scheme. 
> > > > 
> > > > If you "think of Julia as a Lisp" (including Scheme, right?) then 
> when 
> > > > would you prefer Lisp (or Scheme) for new things after Julia came 
> along? 
> > > 
> > > Sorry, but did you read my e-mail? As I said, Julia is much more 
> > > optimizable 
> > > 
> > > 
> > > 
> > > with its richer type system, which is a great advantage for 
> > > me. Common Lisp is remarkably nice, but 
> > 
> > Yes I did read it. Note, I meant would you still recommend (Common) Lisp 
> > for anything, you seem to argue well for Julia (and against 
> > "Lisp"/S-expressions while you're at it?). Note also, I said "would you 
> > prefer Lisp (or Scheme)". I know Scheme is a dialect of Lisp and Racket 
> of 
> > Scheme, but am not expert on the differences. I may be grouping all the 
> > Lisps together unfairly. Your objections to Common Lisp may not 
> generalize 
> > to them all. 
> > 
> > Personally, I like S-expressions too, but many people prefer 
> > 
> > > M-expressions, especially for math (they are indeed more compact). 
> > 
> > Is there a good way to call any (or all) of the S-expressions languages 
> > from Julia? I'm not even sure it's important too, there could be lots of 
> > useful preexisting code. 
> > 
> > > >> I am not so 
> > > >> sure that current technology allows a single language to be good at 
> > > >> everything, languages like C seem to be difficult to replace with 
> > > >> dynamic languages in some situations. 
> > > 
> > > These are very abstract points, and I am not sure that discussing them 
> > > as such is very productive. As many have remarked in this thread, 
> > > languages are tools, designed for a given prupose. Is a hammer better 
> > > than a screwdriver? Etc. 
> > 
> > Libraries are also "tools", I'm just not at all convinced we need many 
> > languages (for different "purposes", maybe with very few limited 
> > exceptions) rather than just new libraries. That seems to be a failure 
> of 
> > computer science. 
> > 
> > > > Why? For C, Julia seems already better for almost all users. If 
> > > 
> > > "languages 
> > > 
> > > > like C" means C++, I could see all new code in Julia and C++ as 
> legacy. 
> > > > What other "like C" do you mean? 
> > > 
> > > Again, I am wondering if you actually read the replies to your 
> > > questions. Many have remarked on these issues in their replies to you, 
> > > eg dynamic vs manual memory allocation, etc. C, C++, and Fortran are 
> > > fundamentally different from Julia at the moment. 
> > 
> > I read all the replies (might have missed some). I already mentioned 
> > dynamic memory allocation in my first post as a temporary limitation 
> > (currently would be a problem for very few users/uses). Never programmed 
> in 
> > Fortran but think it also uses manual memory allocation. While Julia 
> uses 
> > those languages in part I think manual is not the reason for their (or 
> > Julia's) speed; in general that they are fundamentally different in a 
> > better way or others. Garbage collection can be hard real-time and fast 
> > (and Julia - the core language wouldn't need changes that break 
> > compatibility). 
> > 
> > or by 
> > 
> > > helping to discover where it could be improved. 
> > > 
> > > Partly why I'm writing this. I want to know what needs improving or if 
> > 
> > something can't be improved, unless breaking things in a minor way or 
> > fundamentally that Julia can't work. 
> > 
> > > Frankly, I don't understand your decision problem -- are you trying to 
> > > decide whether to invest learning in Julia vs some other language? 
> Even 
> > > though that question does not have a well-defined answer either, it is 
> > > possible that you would get more useful advice. 
> > 
> > Yes, I'm not too worried about me. I don't think I'm wasting ti

Re: [julia-users] Inferring constructor parameters from parameters of arguments

[Tim Holy]

When you create an inner constructor, it deletes all default constructors. So 
you have to provide the default outer constructor:

TLPixel{T}(img:Image{T}) = TLPixel{T}(img)

Despite appearances, {T} on the left hand side is very different from {T} on 
the right: on the left it's acting as a parameter for dispatch, on the right 
it's declaring the type you want to create. You could, of course, put some 
other type in there:

TLPixel{T<:Integer}(img:Image{T}) = TLPixel{Float32}(img)
TLPixel{T<:FloatingPoint}(img:Image{T}) = TLPixel{T}(img)


If you believe that this information is missing from the documentation, please 
take the time to improve it:
https://github.com/JuliaLang/julia/edit/master/doc/manual/constructors.rst
(click on the pencil icon).

--Tim

On Friday, December 05, 2014 06:35:56 AM Andrew Gibb wrote:
> I want to create a parametric type whose parameter is inferred from the
> parameter of an argument. A toy example:
> 
> using Images
> 
> type TLPixel{T}
> data::T
> function TLPixel(img::Image{T})
> new(img.data[1,1])
> end
> end
> 
> If I do this:
> 
> julia> tlp = TLPixel{typeof(img.data[1,1])}(img)
> 
> This works fine. However, I would have expected the dispatcher(?) to
> realise that the parameter on the image, T, is the same as the one in the
> type declaration. But it doesn't:
> 
> julia> tlp = TLPixel(img)
> `TLPixel{T}` has no method matching TLPixel{T}(::Image{RGB{UfixedBase{Uint8,
> 8}},2,Array{RGB{UfixedBase{Uint8,8}},2}})
> while loading In[4], in expression starting on line 1
> 
> 
> Have I done something wrong here, or should I not expect this to work?

Re: [julia-users] Inferring constructor parameters from parameters of arguments

[Mauro]

you have to provide an outer constructor as well when you define an
inner one.  This is a bit confusing, have a look at the manual & search
the list.  Here using your example using Arrays as I don't know Images:

type TLPixel{T}
data::T
function TLPixel(img::Array{T})
new(img[1])
end
end
TLPixel{T}(img::Array{T}) = TLPixel{T}(img)


> type TLPixel{T}
> data::T
> function TLPixel(img::Image{T})
> new(img.data[1,1])
> end
> end
>
> If I do this:
>
> julia> tlp = TLPixel{typeof(img.data[1,1])}(img)
>
> This works fine. However, I would have expected the dispatcher(?) to realise
> that the parameter on the image, T, is the same as the one in the type
> declaration. But it doesn't:
>
> julia> tlp = TLPixel(img)
> `TLPixel{T}` has no method matching TLPixel{T}(::Image{RGB{UfixedBase{Uint8,8
> }},2,Array{RGB{UfixedBase{Uint8,8}},2}})
> while loading In[4], in expression starting on line 1
>
>
>
> Have I done something wrong here, or should I not expect this to work?

Re: [julia-users] Reviewing a Julia programming book for Packt

[Evan Miller]

Another reason to serve as a reviewer: to see if any passages look
"familiar."

There's a Packt book about Nginx development that extensively plagiarizes
material from my website. The book is niche enough that I haven't bothered
seeking damages, but they've been very non-helpful after many emails.
Overall they seem like a pretty shady company.

I wouldn't ever do business with Packt, but serving as a reviewer may help
push things in a good direction, as you say.


On Thu, Dec 4, 2014 at 7:51 PM, John Myles White 
wrote:

> It does make me feel better knowing that you'll be reviewing the book.
>
>  -- John
>
> On Dec 4, 2014, at 5:49 PM, Jacob Quinn  wrote:
>
> That's a good point John. I definitely had the thought looking over the
> outline that a bunch of the 0.4 changes will make certain parts out of date
> pretty quickly.
>
> Then again, I figured if I helped review, I could perhaps help push things
> in a good direction and help make it as timely as possible.
>
> -Jacob
>
> On Thu, Dec 4, 2014 at 8:35 PM, John Myles White  > wrote:
>
>> I hate to say it, but Packt's handling of its Julia publications is
>> rather troubling. I received a request to review this book and told them I
>> wasn't free, but the truth is that I would prefer that they not pubilsh
>> this kind of book at all right now. The blurb refers to several things that
>> may not even exist in JuliaStats, including lists, factors and ANOVA's. I
>> think the whole thing is premature.
>>
>>  -- John
>>
>>
>> On Dec 4, 2014, at 3:31 PM, Wilfred Hughes  wrote:
>>
>> I received an email today about being a technical reviewer for a book on
>> Julia!
>>
>> We're currently developing a book titled *Mastering Julia* aiming at
>>> building statistical models with linear regressions and analysis of
>>> variance (ANOVA) and will be working on probability, probability
>>> distributions, and random variables covering  data structures such as
>>> matrices, lists, factors, and data frames. This book is targeted at 
>>> Intermediate
>>> level developer in statistical languages and one who will be having
>>> understanding of Core elements and applications.
>>>
>>> Would you be interested in acting as reviewer for this book?
>>>
>> Now, I enjoy Julia, and I'm happy to help promote the language, but I
>> don't think I'm particularly qualified to be a technical reviewer of a book
>> on Julia programming. I found this thread on julia-dev:
>> https://groups.google.com/forum/#!msg/julia-dev/HrdpknFgdfk/SAVMyyacT_sJ
>> where Packt contacted a large number of folks seeking an author.
>>
>> Has anyone else received something like this? In principle, I'm all in
>> favour of producing promotional or teaching materials, but I'm surprised it
>> lead to me being contacted.
>>
>>
>>
>
>


-- 
Evan Miller
http://www.evanmiller.org/

Re: [julia-users] julia literals for bittypes

[John Myles White]

0x03

 — John

On Dec 5, 2014, at 3:17 AM, Francesco  wrote:

> When I write:
> 
> julia> x = 3
> 
> I assign to x a Int64 by default.
> 
> julia> typeof(x)
> Int64
> 
> Let say that 3 should be Uint8, then I write:
> julia> x = convert(Uint8, 3)
> 
> Is there a more idiomatic way of doing it?
> Maybe with literals?

Re: [julia-users] julia literals for bittypes

[Michele Zaffalon]

uint8(3)

See here:
http://julia.readthedocs.org/en/release-0.3/manual/integers-and-floating-point-numbers/


On Fri, Dec 5, 2014 at 12:17 PM, Francesco  wrote:

> When I write:
>
> julia> x = 3
>
> I assign to x a Int64 by default.
>
> julia> typeof(x)
> Int64
>
> Let say that 3 should be Uint8, then I write:
> julia> x = convert(Uint8, 3)
>
> Is there a more idiomatic way of doing it?
> Maybe with literals?
>

[julia-users] julia literals for bittypes

[Francesco]

When I write:

julia> x = 3

I assign to x a Int64 by default.

julia> typeof(x)
Int64

Let say that 3 should be Uint8, then I write:
julia> x = convert(Uint8, 3)

Is there a more idiomatic way of doing it?
Maybe with literals?

[julia-users] type conversion in array comprehension

[Andrew Ellis]

I'm trying to construct an array of Dicts (Dict{Symbol,Any}, to be used as 
initial values for MCMC chains by the Mamba package). The following problem 
doesn't appear to have anything to do with Mamba, though.


julia> using Distributions

The following works, i.e. autoamatic conversion works: rand(Binomial(50, 
0.75)) will returns an Int64 and 34.3 is a Float64

julia> inits = [[:k => rand(Binomial(50, 0.75)), :j => 34.3] for i in 1:2]
2-element Array{Dict{Symbol,Any},1}:
 [:j=>34.3,:k=>39]
 [:j=>34.3,:k=>42]


This also works:

julia> k= rand(Binomial(50, 0.75))
42

julia> typeof(k)
Int64

julia> inits = [[:k => k, :j => 34.3]]
1-element Array{Dict{Symbol,Any},1}:
 [:j=>34.3,:k=>42]

But this doesn't, i.e. automatic type conversion doesn't work:

julia> inits = [[:k => k, :j => 34.3] for i in 1:nchains]
3-element Array{Union(Dict{Symbol,Float64},Dict{Symbol,Any}),1}:
 [:j=>34.3,:k=>42]
 [:j=>34.3,:k=>42]
 [:j=>34.3,:k=>42]


If I specify the type, it works:
julia> inits = [(Symbol => Any)[:k => k, :j => 34.3] for i in 1:nchains]

I'm using:

julia> versioninfo()
Julia Version 0.3.3
Commit b24213b* (2014-11-23 20:19 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.3.0)
  CPU: Intel(R) Core(TM) i7-4558U CPU @ 2.80GHz
  WORD_SIZE: 64
  BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

Am I doing anything wrong?

Cheers,
Andrew

[julia-users] How can I sort Dict efficiently?

[Michiaki Ariga]

Hi,
I have a question about Dict().

I found there are no method such as sort_by() after v0.3.
But I want to count word frequency with Dict() and sort by its value to 
find frequent word.
So, how can I sort Dict efficiently?

Of course, I know sort using DataFrame like following,

```
counts = Dict{String, Int64}("apple" => 100, "town" => 250, "space" => 24)
df = DataFrame(word = collect(keys(counts)), count = 
collect(values(counts)))
sort(df, cols = [:count], rev = true)
```

I think it is natural `convert(DataFrame, dict)` returns Nx2 DataFrame 
instead of 1xN one.

Thanks,

---
Michiaki Ariga
https://github.com/chezou

Re: [julia-users] Re: What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Sebastian Nowozin]

Hi,

I find Julia great, but for the technical computing goal, my biggest grime 
with Julia (0.3.3 and 0.4.0-dev) at the moment is the lack of simple 
OpenMP-style parallelism.
There is DArray and pmap, but they have large communication overheads for 
shared-memory parallelism, and also, quite frankly, an unintuitive 
parallelism model and lack of documentation.

I often have code of the OpenMP-style type:



for i=1:N
  # (i.e. all memory-writes are disjoint)
end

Doing this cheaply on a multicore shared-memory machine is currently 
difficult in Julia (on Windows at least), so I only use one out of my 12 
cores.
With C++ I have to add one line of "#pragma omp parallel for 
schedule(dynamic)" to use 12 out of 12 cores.

Sebastian

On Thursday, 4 December 2014 19:38:20 UTC, Stefan Karpinski wrote:
>
> Wow, that's a pretty interesting graph – I'd like to start using something 
> like that in presentations. Of course, it's bound to be contentious because 
> no one has really spent any effort on making the benchmark codes terser. In 
> fact, I was pretty cut-and-paste happy with the initial versions in other 
> languages because I just wanted to bang out something that worked in each 
> language, rather than take lots of time to figure out the most elegant way 
> to time things, for example.
>
> On Thu, Dec 4, 2014 at 2:25 PM, Simon Danisch  > wrote:
>
>> Hi,
>> Recently I made a graphic, plotting code length vs speed from the Julia 
>> benchmarks and I was surprised how strongly it favors Julia: 
>> 
>>
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> (I removed comments, newlines an normalized the length. For the speed I 
>> simply took the average of the benchmarks. Fortran has some weirdly high 
>> values in the csv on JuliaLang though.)
>>
>> Well using code length as a metric is a difficult issue, but I was happy 
>> about the nice, empty area around Julia ;)
>> This could be strongly biased though, maybe someone with more knowledge 
>> about the benchmarks can immediately point out, that Julia is simply the 
>> most polished one.
>>
>>
>> Am Donnerstag, 4. Dezember 2014 19:12:24 UTC+1 schrieb Páll Haraldsson:
>>
>>>
>>> Hi,
>>>
>>> This is my first post here and since I've gotten your attention, my 
>>> answer: Julia is (or seems to be) good at "everything".[*] But I'm just not 
>>> sure.. [You could stop reading here.]
>>>
>>> I think Julia could be the last language people need to learn (and 
>>> should be the first).[*] Maybe I'm being incredibly naive thinking no 
>>> *better* language will come along and I need to qualify that[*] but it 
>>> seems people here, when saying the Wired article has it wrong (e.g. 
>>> Bezanson), are being modest (or know better than I do). Maybe I just do not 
>>> have enough perspective on languages/paradigms out there. I'm probably 
>>> ignorant on (new) language/paradigm research..
>>>
>>> Is Julia ready for prime time (0.3.3 considered stable)? I see some talk 
>>> of breaking changes ("Array nirvana" and "staged functions" (for C++) will 
>>> they break anything?). I already recommend Julia for technical computing 
>>> (quant/financial) at least (to learn/try); there may be issues (especially 
>>> for those doing non-technical) - for now. That seems to be changing fast.
>>>
>>> I would be preaching to the choir saying Julia is great for its target 
>>> audience. But why do you just want to unify all of technical computing in 
>>> one language and not all of computing? "A fresh approach to technical 
>>> computing" might stop other people from considering Julia. I guess it's 
>>> good to have a niche but I hope other people do not get scared away.
>>>
>>> What is needed is to support all the important platforms so that people 
>>> will not overlook Julia as "it doesn't support my work or run on my 
>>> platform". This means the web (JavaScript as an "assembly language" 
>>> target), Android (and iOS..).
>>>
>>>
>>> At least Bezanson seems to like (love?) Scheme ("femtolisp"). I wander 
>>> if Scheme/Lisp (or any language) is *clearly* better than Julia for 
>>> anything? Or would he stop using Scheme except to maintain Julia's core.. 
>>> [Maybe femtolisp should be removed from Julia (e.g. to bootstrap Julia)..]
>>>
>>> While functional style is getting more popular, people seem to like 
>>> imperative and Julia isn't either or. Can/should !-functions be enforced? 
>>> It is only a recommendation?
>>>
>>> I know Lisp-syntax is "simple". Maybe non-infix notation is "better" in 
>>> a language but only for the interpreter it seems; or in regular math, had 
>>> it been used first/what people are used to. I and most people just don't 
>>> see it. I wander if there is anything to this other than prefe

Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Tamas Papp]

On Fri, Dec 05 2014, Páll Haraldsson  wrote:

> Yes I did read it. Note, I meant would you still recommend (Common) Lisp 
> for anything, you seem to argue well for Julia (and against 
> "Lisp"/S-expressions while you're at it?). Note also, I said "would you 

Sure -- for example, if I wanted a language with macros and a stable
standard, I would go for CL at the moment. Or if I wanted well-tested
statistics libraries and plotting, I would put up with R for a little
more time. For some tasks I would use C. etc etc.

(Also, I think you misunderstood something -- I never argued against
S-expressions. I like them, very much, in fact.)

> Is there a good way to call any (or all) of the S-expressions languages 
> from Julia? I'm not even sure it's important too, there could be lots of 
> useful preexisting code.

I am not sure why you would want to do that -- reimplementation would
almost always be preferable.

> Libraries are also "tools", I'm just not at all convinced we need many 
> languages (for different "purposes", maybe with very few limited 
> exceptions) rather than just new libraries. That seems to be a failure of 
> computer science.

Well, then don't create new languages. The creators of Julia were
convinced they needed a new language, so they made one. I am not sure
that eveyone's preferences can be aggregated into a "we". People create
languages when they are motivated to do so, this is not centrally
planned or coordinated.

> Yes, I'm not too worried about me. I don't think I'm wasting time
> learning (more about) Julia, I just do not want to point people to it
> if there are even better languages available or if there is some
> defect in Julia I'm missing. It seems to be a good first language to
> learn, not just for "matrix methods" (is that all the Universities
> have started teaching with Julia?).

Julia as a first language... dunno. Possibly with a well-qualified
instructor who puts a lot of effort into it, it could work even at this
stage. But in a university setting the lack of a textbook is a problem,
also I guess TA's would be hard to find. Depends on the audience and
what they want to do with the language. As a self-taught first language:
probably not the best choice at this stage.

Best,

Tamas

[julia-users] Re: [ANN - SolveDSGE] A Julia package to solve DSGE models

[Stéphane Adjemian]

Hi,

Actually we do plan in the coming months to add the possibility for the
Dynare preprocessor to write the dynamic and static DSGE models with the
julia language. These routines are used to compute the steady state of
the model, and evaluate the jacobian and hessian matrices of the model
(needed for the first order and second order approximation of the DSGE
models). We will then add some Julia routines for simulation and
estimation. As pointed out by Sébastien it is not possible (nor
desirable) to reimplement all what is done in Dynare/Matlab/Octave...
Because we have to maintain the Matlab/Octave version. So we will only
implement some of the Dynare features (I hope by using codes already
written by the Julia community, for instance for the Bayesian estimation
and MCMC).

Best,
Stéphane


Le 03/12/2014 10:43, sebast...@debian.org a
écrit :
> Hi Richard (and other participants to this thread),
> 
> Concerning Dynare: it is indeed written in MATLAB/Octave (with some parts in 
> C++, like the preprocessor and some optimized portions of code). Dynare 
> currently covers a very large range of features, and replicating all of them 
> in Julia would take a lot of time. The Dynare Team has currently no plan to 
> port the existing Dynare to Julia, given the size of this endeavour and the 
> limited resources of the team.
> 
> However, as has already been pointed, I have started writing something from 
> scratch (https://github.com/DynareTeam/Dynare.jl). This package is able to 
> solve models at first order in rational expectations mode, and with full 
> nonlinearities in perfect foresight mode. The interesting thing about this 
> package is that you can write equations naturally as you would in Dynare: the 
> package uses the Julia parser to get the equations and to compute their 
> symbolic derivatives, and then forms the model matrices automatically.
> 
> I am rather busy at the moment so I have not been able to improve on that 
> package in the last couple of months. But it should be functional. Bugreports 
> and improvements are welcome. I definitely plan to continue working on it 
> when time permits. I may get help from other members of the Dynare Team, but 
> this is not guaranteed at this stage.
> 
> Richard: it would be great if we could join our efforts and create a nice 
> Julia package for DSGE modeling, out of our two prototypes. I am open to any 
> suggestion, so feel free to get back to me.
> 
> Best,
> 
> --
> Sébastien Villemot
> Economist
> OFCE — Sciences Po
> http://sebastien.villemot.name
> 


-- 
Stéphane Adjemian
Université du Maine, Dynare Team

Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Tim Holy]

I'm glad you're enthusiastic about Julia. If you're looking to pitch in, one 
good place to look is the list of open issues:
https://github.com/JuliaLang/julia/issues
If you're most interested in "features," filtering on the "up for grabs" label 
might be a good start.

Best,
--Tim

On Friday, December 05, 2014 06:00:31 AM Páll Haraldsson wrote:
> On Friday, December 5, 2014 11:34:46 AM UTC, Tamas Papp wrote:
> > On Fri, Dec 05 2014, Páll Haraldsson >
> > 
> > wrote:
> > > On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote:
> > >> I find your aversion to femtolisp difficult to understand, probably
> > >> because I tend to think of Julia as a Lisp with the following key
> > > 
> > >> features:
> > > I don't really have an aversion to femtolisp. I understand it's an
> > 
> > awesome
> > 
> > > implementation of Scheme.
> > > 
> > > If you "think of Julia as a Lisp" (including Scheme, right?) then when
> > > would you prefer Lisp (or Scheme) for new things after Julia came along?
> > 
> > Sorry, but did you read my e-mail? As I said, Julia is much more
> > optimizable
> > 
> > 
> > 
> > with its richer type system, which is a great advantage for
> > me. Common Lisp is remarkably nice, but
> 
> Yes I did read it. Note, I meant would you still recommend (Common) Lisp
> for anything, you seem to argue well for Julia (and against
> "Lisp"/S-expressions while you're at it?). Note also, I said "would you
> prefer Lisp (or Scheme)". I know Scheme is a dialect of Lisp and Racket of
> Scheme, but am not expert on the differences. I may be grouping all the
> Lisps together unfairly. Your objections to Common Lisp may not generalize
> to them all.
> 
> Personally, I like S-expressions too, but many people prefer
> 
> > M-expressions, especially for math (they are indeed more compact).
> 
> Is there a good way to call any (or all) of the S-expressions languages
> from Julia? I'm not even sure it's important too, there could be lots of
> useful preexisting code.
> 
> > >> I am not so
> > >> sure that current technology allows a single language to be good at
> > >> everything, languages like C seem to be difficult to replace with
> > >> dynamic languages in some situations.
> > 
> > These are very abstract points, and I am not sure that discussing them
> > as such is very productive. As many have remarked in this thread,
> > languages are tools, designed for a given prupose. Is a hammer better
> > than a screwdriver? Etc.
> 
> Libraries are also "tools", I'm just not at all convinced we need many
> languages (for different "purposes", maybe with very few limited
> exceptions) rather than just new libraries. That seems to be a failure of
> computer science.
> 
> > > Why? For C, Julia seems already better for almost all users. If
> > 
> > "languages
> > 
> > > like C" means C++, I could see all new code in Julia and C++ as legacy.
> > > What other "like C" do you mean?
> > 
> > Again, I am wondering if you actually read the replies to your
> > questions. Many have remarked on these issues in their replies to you,
> > eg dynamic vs manual memory allocation, etc. C, C++, and Fortran are
> > fundamentally different from Julia at the moment.
> 
> I read all the replies (might have missed some). I already mentioned
> dynamic memory allocation in my first post as a temporary limitation
> (currently would be a problem for very few users/uses). Never programmed in
> Fortran but think it also uses manual memory allocation. While Julia uses
> those languages in part I think manual is not the reason for their (or
> Julia's) speed; in general that they are fundamentally different in a
> better way or others. Garbage collection can be hard real-time and fast
> (and Julia - the core language wouldn't need changes that break
> compatibility).
> 
> or by
> 
> > helping to discover where it could be improved.
> > 
> > Partly why I'm writing this. I want to know what needs improving or if
> 
> something can't be improved, unless breaking things in a minor way or
> fundamentally that Julia can't work.
> 
> > Frankly, I don't understand your decision problem -- are you trying to
> > decide whether to invest learning in Julia vs some other language? Even
> > though that question does not have a well-defined answer either, it is
> > possible that you would get more useful advice.
> 
> Yes, I'm not too worried about me. I don't think I'm wasting time learning
> (more about) Julia, I just do not want to point people to it if there are
> even better languages available or if there is some defect in Julia I'm
> missing. It seems to be a good first language to learn, not just for
> "matrix methods" (is that all the Universities have started teaching with
> Julia?).
> 
> Best regards,
> Palli.

[julia-users] Inferring constructor parameters from parameters of arguments

[Andrew Gibb]

I want to create a parametric type whose parameter is inferred from the 
parameter of an argument. A toy example:

using Images

type TLPixel{T}
data::T
function TLPixel(img::Image{T})
new(img.data[1,1])
end
end

If I do this:

julia> tlp = TLPixel{typeof(img.data[1,1])}(img)

This works fine. However, I would have expected the dispatcher(?) to 
realise that the parameter on the image, T, is the same as the one in the 
type declaration. But it doesn't:

julia> tlp = TLPixel(img)
`TLPixel{T}` has no method matching TLPixel{T}(::Image{RGB{UfixedBase{Uint8,
8}},2,Array{RGB{UfixedBase{Uint8,8}},2}})
while loading In[4], in expression starting on line 1


Have I done something wrong here, or should I not expect this to work?

Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Páll Haraldsson]

On Friday, December 5, 2014 11:34:46 AM UTC, Tamas Papp wrote:
>
>
> On Fri, Dec 05 2014, Páll Haraldsson > 
> wrote: 
>
> > On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote: 
> >> 
> >> I find your aversion to femtolisp difficult to understand, probably 
> >> because I tend to think of Julia as a Lisp with the following key 
> >> features: 
> >> 
> > 
> > I don't really have an aversion to femtolisp. I understand it's an 
> awesome 
> > implementation of Scheme. 
> > 
> > If you "think of Julia as a Lisp" (including Scheme, right?) then when 
> > would you prefer Lisp (or Scheme) for new things after Julia came along? 
>
> Sorry, but did you read my e-mail? As I said, Julia is much more 
> optimizable

 

> with its richer type system, which is a great advantage for 
> me. Common Lisp is remarkably nice, but


Yes I did read it. Note, I meant would you still recommend (Common) Lisp 
for anything, you seem to argue well for Julia (and against 
"Lisp"/S-expressions while you're at it?). Note also, I said "would you 
prefer Lisp (or Scheme)". I know Scheme is a dialect of Lisp and Racket of 
Scheme, but am not expert on the differences. I may be grouping all the 
Lisps together unfairly. Your objections to Common Lisp may not generalize 
to them all.

Personally, I like S-expressions too, but many people prefer 
> M-expressions, especially for math (they are indeed more compact). 
>

Is there a good way to call any (or all) of the S-expressions languages 
from Julia? I'm not even sure it's important too, there could be lots of 
useful preexisting code.
 

> >> I am not so 
> >> sure that current technology allows a single language to be good at 
> >> everything, languages like C seem to be difficult to replace with 
> >> dynamic languages in some situations. 
>
> These are very abstract points, and I am not sure that discussing them 
> as such is very productive. As many have remarked in this thread, 
> languages are tools, designed for a given prupose. Is a hammer better 
> than a screwdriver? Etc.
>

Libraries are also "tools", I'm just not at all convinced we need many 
languages (for different "purposes", maybe with very few limited 
exceptions) rather than just new libraries. That seems to be a failure of 
computer science.


> > Why? For C, Julia seems already better for almost all users. If 
> "languages 
> > like C" means C++, I could see all new code in Julia and C++ as legacy. 
> > What other "like C" do you mean? 
>
> Again, I am wondering if you actually read the replies to your 
> questions. Many have remarked on these issues in their replies to you, 
> eg dynamic vs manual memory allocation, etc. C, C++, and Fortran are 
> fundamentally different from Julia at the moment.
>

I read all the replies (might have missed some). I already mentioned 
dynamic memory allocation in my first post as a temporary limitation 
(currently would be a problem for very few users/uses). Never programmed in 
Fortran but think it also uses manual memory allocation. While Julia uses 
those languages in part I think manual is not the reason for their (or 
Julia's) speed; in general that they are fundamentally different in a 
better way or others. Garbage collection can be hard real-time and fast 
(and Julia - the core language wouldn't need changes that break 
compatibility). 

or by 
> helping to discover where it could be improved. 
>
> Partly why I'm writing this. I want to know what needs improving or if 
something can't be improved, unless breaking things in a minor way or 
fundamentally that Julia can't work.
 

> Frankly, I don't understand your decision problem -- are you trying to 
> decide whether to invest learning in Julia vs some other language? Even 
> though that question does not have a well-defined answer either, it is 
> possible that you would get more useful advice.
>

Yes, I'm not too worried about me. I don't think I'm wasting time learning 
(more about) Julia, I just do not want to point people to it if there are 
even better languages available or if there is some defect in Julia I'm 
missing. It seems to be a good first language to learn, not just for 
"matrix methods" (is that all the Universities have started teaching with 
Julia?).

Best regards,
Palli.

Re: [julia-users] why are variables not local by default?

[John Drummond]

Thanks. I missed a couple of those links, though I did try seaching. 
Yes I'd read the last performance tips, but what I hadn't found was why it 
wasn't harder to have global variables or in what cases they'd be essential.


On Friday, December 5, 2014 1:06:19 PM UTC, Isaiah wrote:
>
> See the discussions in
> http://julia.readthedocs.org/en/release-0.3/manual/performance-tips/
> https://github.com/JuliaLang/julia/issues/524
> https://github.com/JuliaLang/julia/issues/8870
> (and elsewhere)
>
>
> On Fri, Dec 5, 2014 at 7:13 AM, John Drummond  > wrote:
>
>> I suspect I'm missing something here.
>>
>> I had a simple script to strip out nuls from a text file.
>> placing a let at the beginning and end at the end resulted in a 70 times 
>> speed up.
>>
>> I'm wondering what the reason is that there isn't the equivalent of a let 
>> end wrapped around everything, and where global variables have to be used 
>> they have to be specifically declared as such?
>>
>>
>>
>>
>

Re: [julia-users] Re: DataFrames and NamedArrays: are they suitable for heavier computations ?

[Tim Holy]

The new SubArrays steal mercilessly from the good ideas of both the old 
SubArray and ArrayViews, and then add some new tricks of their own. In theory, 
they should be a strict improvement on both of their predecessors.

--Tim

On Friday, December 05, 2014 05:13:28 AM David van Leeuwen wrote:
> So what is the relation between ArrayViews and 0.4 `SubArray revamp'?   Are
> they targeting different use cases or is one of them going to be phased
> out?
> 
> On Friday, December 5, 2014 1:28:16 PM UTC+1, Tim Holy wrote:
> > In 0.4, the views are a revamp of SubArray. So if NamedArrays already
> > interacts well with SubArrays, you're basically set.
> > 
> > Most likely not, as SubArrays are new to me (I've tried sub() in
> 
> production code in the past, but it was always better to write out a
> loop)).
> 
> > FYI the implementation in 0.4 is largely backwards-compatible, but there
> > are
> > some important differences. If you need to dig into the internal
> > implementation
> > of SubArrays, you can find documentation on the changes for 0.4 here:
> > http://docs.julialang.org/en/latest/devdocs/subarrays/
> > 
> > OK, I'll have to study this in order to understand the implications for
> 
> NamedArrays.
> 
> ---david
> 
> > --Tim
> > 
> > On Friday, December 05, 2014 04:18:08 AM David van Leeuwen wrote:
> > > Hi,
> > > 
> > > On Friday, December 5, 2014 8:47:22 AM UTC+1, Ján Dolinský wrote:
> > > > Hi,
> > > > 
> > > > I am exploring DataFrames and NamedArrays packages and I would like to
> > 
> > ask
> > 
> > > > whether their are suitable for heavier computations and whether I can
> > 
> > use
> > 
> > > > them directly in BLAS calls (e.g. gemv() etc.). In addition, is it
> > > > possible
> > > > to create views of e.g. DataFrames or NamedArrays ?
> > > > 
> > > > I can only speak for NamedArrays.  On the one hand the deployment of
> > 
> > BLAS
> > 
> > > should be transparant and the use of NamedArray vs Array not lead to
> > 
> > much
> > 
> > > degradation in performance.  E.g., "a * b" with `a` and `b` a
> > 
> > NamedArray,
> > 
> > > effectively calls "a.array * b.array" which Base implements with
> > > BLAS.gemm().  There is just a little overhead of filling in sensible
> > 
> > names
> > 
> > > in the result---so if you have small matrices in an inner loop, you're
> > > going to get hurt.
> > > 
> > > On the other hand, I am not sure how much of the Julia BLAS cleverness
> > 
> > is
> > 
> > > retained in NamedArrays---but the intention of the package is that it is
> > > completely transparent, and if you notice bad performance for a
> > 
> > particular
> > 
> > > situation then you should file an issue (or make a PR:-).  Individual
> > > element indexing of a NamedArray with integers is just a little bit
> > 
> > slower
> > 
> > > than that of an Array.  Indexing by name is quite a bit slower---you may
> > > try a different Associative than the standard Dict.
> > > 
> > > Incidentally, I've been toying with the idea of NamedArrays `*` check on
> > > consistency of index and dimension names, but my guess is that people
> > 
> > would
> > 
> > > find such a thing annoying.
> > > 
> > > ArrayViews are currently not aware of NameArrays.  I believe the views
> > 
> > are
> > 
> > > going to be part ov julia-0.4, so then it would be a task for NamedArray
> > 
> > to
> > 
> > > implement views of NamedArrays I gather.
> > > 
> > > Cheers,
> > > 
> > > ---david
> > > 
> > > > Thanks,
> > > > Jan

Re: [julia-users] Re: DataFrames and NamedArrays: are they suitable for heavier computations ?

[David van Leeuwen]

So what is the relation between ArrayViews and 0.4 `SubArray revamp'?   Are 
they targeting different use cases or is one of them going to be phased 
out? 

On Friday, December 5, 2014 1:28:16 PM UTC+1, Tim Holy wrote:
>
> In 0.4, the views are a revamp of SubArray. So if NamedArrays already 
> interacts well with SubArrays, you're basically set. 
>
> Most likely not, as SubArrays are new to me (I've tried sub() in 
production code in the past, but it was always better to write out a 
loop)). 
 

> FYI the implementation in 0.4 is largely backwards-compatible, but there 
> are 
> some important differences. If you need to dig into the internal 
> implementation 
> of SubArrays, you can find documentation on the changes for 0.4 here: 
> http://docs.julialang.org/en/latest/devdocs/subarrays/ 
>
> OK, I'll have to study this in order to understand the implications for 
NamedArrays.  

---david
 

> --Tim 
>
> On Friday, December 05, 2014 04:18:08 AM David van Leeuwen wrote: 
> > Hi, 
> > 
> > On Friday, December 5, 2014 8:47:22 AM UTC+1, Ján Dolinský wrote: 
> > > Hi, 
> > > 
> > > I am exploring DataFrames and NamedArrays packages and I would like to 
> ask 
> > > whether their are suitable for heavier computations and whether I can 
> use 
> > > them directly in BLAS calls (e.g. gemv() etc.). In addition, is it 
> > > possible 
> > > to create views of e.g. DataFrames or NamedArrays ? 
> > > 
> > > I can only speak for NamedArrays.  On the one hand the deployment of 
> BLAS 
> > 
> > should be transparant and the use of NamedArray vs Array not lead to 
> much 
> > degradation in performance.  E.g., "a * b" with `a` and `b` a 
> NamedArray, 
> > effectively calls "a.array * b.array" which Base implements with 
> > BLAS.gemm().  There is just a little overhead of filling in sensible 
> names 
> > in the result---so if you have small matrices in an inner loop, you're 
> > going to get hurt. 
> > 
> > On the other hand, I am not sure how much of the Julia BLAS cleverness 
> is 
> > retained in NamedArrays---but the intention of the package is that it is 
> > completely transparent, and if you notice bad performance for a 
> particular 
> > situation then you should file an issue (or make a PR:-).  Individual 
> > element indexing of a NamedArray with integers is just a little bit 
> slower 
> > than that of an Array.  Indexing by name is quite a bit slower---you may 
> > try a different Associative than the standard Dict. 
> > 
> > Incidentally, I've been toying with the idea of NamedArrays `*` check on 
> > consistency of index and dimension names, but my guess is that people 
> would 
> > find such a thing annoying. 
> > 
> > ArrayViews are currently not aware of NameArrays.  I believe the views 
> are 
> > going to be part ov julia-0.4, so then it would be a task for NamedArray 
> to 
> > implement views of NamedArrays I gather. 
> > 
> > Cheers, 
> > 
> > ---david 
> > 
> > > Thanks, 
> > > Jan 
>
>

Re: [julia-users] why are variables not local by default?

[Isaiah Norton]

See the discussions in
http://julia.readthedocs.org/en/release-0.3/manual/performance-tips/
https://github.com/JuliaLang/julia/issues/524
https://github.com/JuliaLang/julia/issues/8870
(and elsewhere)


On Fri, Dec 5, 2014 at 7:13 AM, John Drummond  wrote:

> I suspect I'm missing something here.
>
> I had a simple script to strip out nuls from a text file.
> placing a let at the beginning and end at the end resulted in a 70 times
> speed up.
>
> I'm wondering what the reason is that there isn't the equivalent of a let
> end wrapped around everything, and where global variables have to be used
> they have to be specifically declared as such?
>
>
>
>

Re: [julia-users] Decreasing rate of return on number of blas threads

[Johan Sigfrids]

This was first released in AMD's Bulldozer architecture in 2011. I believe, 
and this is speculation on my part, that the long term goal AMD is working 
toward are heterogeneous CPUs. This would be a CPU where you have a pile of 
high performance integer cores working similar to cores on CPUs today. This 
would then be combines with a small number of high-performance floating 
point cores for single-threaded floating point performance, and also a 
array of GPU like cores for massive parallel flops. Essentially integrating 
the CPU and GPU into a unified heterogeneous system architecture. You don't 
need lots of floating point CPU cores if you have convenient access to GPU 
like floating point computation that is an order of magnitude faster. 

On Friday, December 5, 2014 6:59:59 AM UTC+2, Viral Shah wrote:
>
> That is very interesting. Any idea why they are doing this?
>
> -viral
>
>

Re: [julia-users] Re: DataFrames and NamedArrays: are they suitable for heavier computations ?

[Tim Holy]

In 0.4, the views are a revamp of SubArray. So if NamedArrays already 
interacts well with SubArrays, you're basically set.

FYI the implementation in 0.4 is largely backwards-compatible, but there are 
some important differences. If you need to dig into the internal implementation 
of SubArrays, you can find documentation on the changes for 0.4 here:
http://docs.julialang.org/en/latest/devdocs/subarrays/

--Tim

On Friday, December 05, 2014 04:18:08 AM David van Leeuwen wrote:
> Hi,
> 
> On Friday, December 5, 2014 8:47:22 AM UTC+1, Ján Dolinský wrote:
> > Hi,
> > 
> > I am exploring DataFrames and NamedArrays packages and I would like to ask
> > whether their are suitable for heavier computations and whether I can use
> > them directly in BLAS calls (e.g. gemv() etc.). In addition, is it
> > possible
> > to create views of e.g. DataFrames or NamedArrays ?
> > 
> > I can only speak for NamedArrays.  On the one hand the deployment of BLAS
> 
> should be transparant and the use of NamedArray vs Array not lead to much
> degradation in performance.  E.g., "a * b" with `a` and `b` a NamedArray,
> effectively calls "a.array * b.array" which Base implements with
> BLAS.gemm().  There is just a little overhead of filling in sensible names
> in the result---so if you have small matrices in an inner loop, you're
> going to get hurt.
> 
> On the other hand, I am not sure how much of the Julia BLAS cleverness is
> retained in NamedArrays---but the intention of the package is that it is
> completely transparent, and if you notice bad performance for a particular
> situation then you should file an issue (or make a PR:-).  Individual
> element indexing of a NamedArray with integers is just a little bit slower
> than that of an Array.  Indexing by name is quite a bit slower---you may
> try a different Associative than the standard Dict.
> 
> Incidentally, I've been toying with the idea of NamedArrays `*` check on
> consistency of index and dimension names, but my guess is that people would
> find such a thing annoying.
> 
> ArrayViews are currently not aware of NameArrays.  I believe the views are
> going to be part ov julia-0.4, so then it would be a task for NamedArray to
> implement views of NamedArrays I gather.
> 
> Cheers,
> 
> ---david
> 
> > Thanks,
> > Jan

[julia-users] Re: DataFrames and NamedArrays: are they suitable for heavier computations ?

[David van Leeuwen]

Hi, 

On Friday, December 5, 2014 8:47:22 AM UTC+1, Ján Dolinský wrote:
>
> Hi,
>
> I am exploring DataFrames and NamedArrays packages and I would like to ask 
> whether their are suitable for heavier computations and whether I can use 
> them directly in BLAS calls (e.g. gemv() etc.). In addition, is it possible 
> to create views of e.g. DataFrames or NamedArrays ?
>
> I can only speak for NamedArrays.  On the one hand the deployment of BLAS 
should be transparant and the use of NamedArray vs Array not lead to much 
degradation in performance.  E.g., "a * b" with `a` and `b` a NamedArray, 
effectively calls "a.array * b.array" which Base implements with 
BLAS.gemm().  There is just a little overhead of filling in sensible names 
in the result---so if you have small matrices in an inner loop, you're 
going to get hurt. 

On the other hand, I am not sure how much of the Julia BLAS cleverness is 
retained in NamedArrays---but the intention of the package is that it is 
completely transparent, and if you notice bad performance for a particular 
situation then you should file an issue (or make a PR:-).  Individual 
element indexing of a NamedArray with integers is just a little bit slower 
than that of an Array.  Indexing by name is quite a bit slower---you may 
try a different Associative than the standard Dict. 

Incidentally, I've been toying with the idea of NamedArrays `*` check on 
consistency of index and dimension names, but my guess is that people would 
find such a thing annoying.  

ArrayViews are currently not aware of NameArrays.  I believe the views are 
going to be part ov julia-0.4, so then it would be a task for NamedArray to 
implement views of NamedArrays I gather. 

Cheers, 

---david
 

> Thanks,
> Jan 
>

[julia-users] why are variables not local by default?

[John Drummond]

I suspect I'm missing something here.

I had a simple script to strip out nuls from a text file.
placing a let at the beginning and end at the end resulted in a 70 times 
speed up.

I'm wondering what the reason is that there isn't the equivalent of a let 
end wrapped around everything, and where global variables have to be used 
they have to be specifically declared as such?

Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Tamas Papp]

On Fri, Dec 05 2014, Páll Haraldsson  wrote:

> On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote:
>>
>> I find your aversion to femtolisp difficult to understand, probably 
>> because I tend to think of Julia as a Lisp with the following key 
>> features: 
>>
>
> I don't really have an aversion to femtolisp. I understand it's an awesome 
> implementation of Scheme.
>
> If you "think of Julia as a Lisp" (including Scheme, right?) then when 
> would you prefer Lisp (or Scheme) for new things after Julia came along?

Sorry, but did you read my e-mail? As I said, Julia is much more
optimizable with its richer type system, which is a great advantage for
me. Common Lisp is remarkably nice, but even nontrivial numeric code
ends up being

1) non-optimized,

2) peppered with type declarations, specialized for a specific
application,

3) wrapped in a fragile and complicated mess of template macrology.

The kind people who designed Julia essentially took care of (3) for
me -- how could I not like it? :D

>> But given these two (very important) differences
>
> Why "very important"? I understand there is a difference in the syntax, is 
> it important as in better *fro something*? Or just different.

Personally, I like S-expressions too, but many people prefer
M-expressions, especially for math (they are indeed more compact). 

> What I thought. What I'm getting at, if Julia is better at somethings (e.g. 
> the above) must it then be worse for other things?
>
> The core of Julia is generic enough to be a potential substitute for all 
>> dynamic languages in the long run, as the language matures.
>
> Not already? Then some dynamic language should currently be better, I would 
> like to know why.
>
>> I am not so 
>> sure that current technology allows a single language to be good at 
>> everything, languages like C seem to be difficult to replace with 
>> dynamic languages in some situations.

These are very abstract points, and I am not sure that discussing them
as such is very productive. As many have remarked in this thread,
languages are tools, designed for a given prupose. Is a hammer better
than a screwdriver? Etc.

> Why? For C, Julia seems already better for almost all users. If "languages 
> like C" means C++, I could see all new code in Julia and C++ as legacy. 
> What other "like C" do you mean?

Again, I am wondering if you actually read the replies to your
questions. Many have remarked on these issues in their replies to you,
eg dynamic vs manual memory allocation, etc. C, C++, and Fortran are
fundamentally different from Julia at the moment.

Whether, in the long run, Julia will have features that dominate these
in some markets remains to be seen, but at the moment this would be
nothing more than idle speculation.

In any case, history of computer languages teaches us that rich
languages, especially in the Lisp family (where I include Julia) have
features that interact in a manner that is difficult to describe and
design in advance. If these are constraining, either the language is
extended or a new one is introduced. But a priori it is nearly
impossible to say what happens, so I think the best thing for
stakeholders at this point is to work in Julia and see where it is
going, and possibly try to shape its development, either directly or by
helping to discover where it could be improved.

Frankly, I don't understand your decision problem -- are you trying to
decide whether to invest learning in Julia vs some other language? Even
though that question does not have a well-defined answer either, it is
possible that you would get more useful advice.

Best,

Tamas

Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Páll Haraldsson]

On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote:
>
> I find your aversion to femtolisp difficult to understand, probably 
> because I tend to think of Julia as a Lisp with the following key 
> features: 
>

I don't really have an aversion to femtolisp. I understand it's an awesome 
implementation of Scheme.

If you "think of Julia as a Lisp" (including Scheme, right?) then when 
would you prefer Lisp (or Scheme) for new things after Julia came along?

I "learned" Scheme (and ML) in the "programming language Uni course", never 
to use them (or other functional languages) again. That is, I put in quotes 
as we didn't go into macros if I recall, it may have been mentioned as a 
concept.

But given these two (very important) differences
>

Why "very important"? I understand there is a difference in the syntax, is 
it important as in better *fro something*? Or just different.


> Modern CL implementations can be very fast, but it turns out that the 
> type system of CL is not rich enough to allow optimizations necessary 
> for generic numerical code (at least without a lot of biolerplate).
>

What I thought. What I'm getting at, if Julia is better at somethings (e.g. 
the above) must it then be worse for other things?
 

>
> but infix 
> clearly makes macros easier because the AST is much cleaner.


This is the thing I do not get, is non-infix then a problem in Julia? Will 
(user) code get bigger more complicated?

The core of Julia is generic enough to be a potential substitute for all 
> dynamic languages in the long run, as the language matures.


Not already? Then some dynamic language should currently be better, I would 
like to know why.
 

> I am not so 
> sure that current technology allows a single language to be good at 
> everything, languages like C seem to be difficult to replace with 
> dynamic languages in some situations.
>

Why? For C, Julia seems already better for almost all users. If "languages 
like C" means C++, I could see all new code in Julia and C++ as legacy. 
What other "like C" do you mean?

>
> Best, 
>
> Tamas 
>
> On Thu, Dec 04 2014, Páll Haraldsson > 
> wrote: 
>
> > Hi, 
> > 
> > This is my first post here and since I've gotten your attention, my 
> answer: 
> > Julia is (or seems to be) good at "everything".[*] But I'm just not 
> sure.. 
> > [You could stop reading here.] 
> > 
> > I think Julia could be the last language people need to learn (and 
> should 
> > be the first).[*] Maybe I'm being incredibly naive thinking no *better* 
> > language will come along and I need to qualify that[*] but it seems 
> people 
> > here, when saying the Wired article has it wrong (e.g. Bezanson), are 
> being 
> > modest (or know better than I do). Maybe I just do not have enough 
> > perspective on languages/paradigms out there. I'm probably ignorant on 
> > (new) language/paradigm research.. 
> > 
> > Is Julia ready for prime time (0.3.3 considered stable)? I see some talk 
> of 
> > breaking changes ("Array nirvana" and "staged functions" (for C++) will 
> > they break anything?). I already recommend Julia for technical computing 
> > (quant/financial) at least (to learn/try); there may be issues 
> (especially 
> > for those doing non-technical) - for now. That seems to be changing 
> fast. 
> > 
> > I would be preaching to the choir saying Julia is great for its target 
> > audience. But why do you just want to unify all of technical computing 
> in 
> > one language and not all of computing? "A fresh approach to technical 
> > computing" might stop other people from considering Julia. I guess it's 
> > good to have a niche but I hope other people do not get scared away. 
> > 
> > What is needed is to support all the important platforms so that people 
> > will not overlook Julia as "it doesn't support my work or run on my 
> > platform". This means the web (JavaScript as an "assembly language" 
> > target), Android (and iOS..). 
> > 
> > 
> > At least Bezanson seems to like (love?) Scheme ("femtolisp"). I wander 
> if 
> > Scheme/Lisp (or any language) is *clearly* better than Julia for 
> anything? 
> > Or would he stop using Scheme except to maintain Julia's core.. [Maybe 
> > femtolisp should be removed from Julia (e.g. to bootstrap Julia)..] 
> > 
> > While functional style is getting more popular, people seem to like 
> > imperative and Julia isn't either or. Can/should !-functions be 
> enforced? 
> > It is only a recommendation? 
> > 
> > I know Lisp-syntax is "simple". Maybe non-infix notation is "better" in 
> a 
> > language but only for the interpreter it seems; or in regular math, had 
> it 
> > been used first/what people are used to. I and most people just don't 
> see 
> > it. I wander if there is anything to this other than preference. The 
> > S-expressions that come with Lisp and infix, do they have an inherent 
> > advantage that Julia can't match? In other words, I think that means, 
> are 
> > Julia's "Lisp-like" macros and its homoiconicity as p

Re: [julia-users] Re: what's the best way to do R table() in julia? (why does StatsBase.count(x,k) need k?)

[David van Leeuwen]

With the danger that this thread becomes slightly off-topic, I would just 
want to add that I believe that most of the issues raised w.r.t. 
NamedArrays are addressed in NamedArrays v0.4.0, which is now in METATDATA. 

Specifically,
 - the type is now parameterized by its member variable types for Array and 
Dict
 - which can be any AbstractArray and Associative
 - keys to the index names can be of any type, although some types (e.g., 
arrays) will probably lead to trouble.  But integers, rationals or floats 
can be used without too much semantic ambiguity. 

As a bonus, I changed the license to a more Julia-friendly one. 

Cheers, 

---david

On Thursday, December 4, 2014 1:24:03 AM UTC+1, David van Leeuwen wrote:
>
> Hello Milan, 
>
> I just uploaded a new version of NamedArrays to github.  I've 
> reimplemented the getindex() mess---the never ending chain of ambiguities 
> was unworkable.  It is much cleaner now, I believe, and I've replaced the 
> `negative index' implementation with a simple `Not()` type for performance 
> reasons. So now you can say
>
> n[Not(1),:]
>
> to remove the first row, or equivalently use
>
> n[Not("one"),:]
>
> if you happened to have indexed with strings.  You should be able to use 
> an associative index now with all kinds of types, e.g., rationals or 
> perhaps even integers---I haven't tested that yet.  
>
> The standard travis test includes a simple getindex performance benchmark, 
> indexing with integers is slightly slower than for normal arrays, but 
> indeed quite a bit slower for names.  
>
> On Sunday, November 30, 2014 11:22:39 AM UTC+1, Milan Bouchet-Valat wrote:
>>
>> Le mercredi 26 novembre 2014 à 09:30 -0800, David van Leeuwen a écrit : 
>> > Hello again, 
>> > 
>> > 
>>
>> The idea is that any type could be used instead of a Dict, as long as it 
>> can be indexed with a key and return the index. For small NamedArrays, 
>> doing a linear search on an array is faster than using a Dict. And when 
>> computing frequency tables from PooledDataArrays, we could reuse the 
>> existing pool instead of creating a Dict from it, it would save some 
>> memory. 
>>
>>
>> Also, John suggested that the array that a NamedArray wraps could be of 
>> any AbstractArray type, not just Array. Sounds like a good idea (e.g. to 
>> wrap a sparse matrix). 
>>
>> I tried replacing Array by AbstractArray and Dict by Associative in the 
> type definition, and all works fine, except that plain indexing becomes 
> very slow again.  So I left that out for now.  The array and associative 
> types themselves should probably become part of the type parameter list.  
>
> ---david
>
>  
>

Re: [julia-users] Re: What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Páll Haraldsson]

On Friday, December 5, 2014 1:11:12 AM UTC, ivo welch wrote:
>
>
> there are no good web development language environments (server, browser) 
> IMHO, and julia will not fit this bill, either.
>

You are forgetting PHP :)

All joking aside, you got me intrigued. If there is no good language, then 
what is it you want? Why is web-programming special? And wouldn't Julia be 
as least as good a fit (for server side) as any other language?

For client side, I was thinking of writing a separate post on that. Julia 
could work..

Is it a problem that you have separate languages on either side? Then Julia 
or any language wouldn't be perfect (until Julia works client side, I don't 
think JavaScript is better for server-side (than Julia) or best for 
non-web..).

As for server side I had this crazy idea that Julia and PHP could be 
combined.. I'm not sure what the best way is to get people to stop using 
PHP and rewriting from scratch isn't good..

Best regards,
Palli.

Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Tamas Papp]

I find your aversion to femtolisp difficult to understand, probably
because I tend to think of Julia as a Lisp with the following key
features:

1) a focus on being heavily optimizable,
2) infix/M-expression-like surface syntax.

But given these two (very important) differences, I find Julia very,
very similar to, say, Common Lisp (subset of CLOS, DSL for AST
manipulation).

Modern CL implementations can be very fast, but it turns out that the
type system of CL is not rich enough to allow optimizations necessary
for generic numerical code (at least without a lot of biolerplate).

Infix vs prefix can seem like a matter of personal preference, but infix
clearly makes macros easier because the AST is much cleaner. However,
apparently a lot of thought went into designing the Julia surface
syntax, and it turns out to be remarkably macro-friendly. I am not so
sure about the mandatory macro prefix, but time will tell.

The core of Julia is generic enough to be a potential substitute for all
dynamic languages in the long run, as the language matures. I am not so
sure that current technology allows a single language to be good at
everything, languages like C seem to be difficult to replace with
dynamic languages in some situations.

Best,

Tamas

On Thu, Dec 04 2014, Páll Haraldsson  wrote:

> Hi,
>
> This is my first post here and since I've gotten your attention, my answer: 
> Julia is (or seems to be) good at "everything".[*] But I'm just not sure.. 
> [You could stop reading here.]
>
> I think Julia could be the last language people need to learn (and should 
> be the first).[*] Maybe I'm being incredibly naive thinking no *better* 
> language will come along and I need to qualify that[*] but it seems people 
> here, when saying the Wired article has it wrong (e.g. Bezanson), are being 
> modest (or know better than I do). Maybe I just do not have enough 
> perspective on languages/paradigms out there. I'm probably ignorant on 
> (new) language/paradigm research..
>
> Is Julia ready for prime time (0.3.3 considered stable)? I see some talk of 
> breaking changes ("Array nirvana" and "staged functions" (for C++) will 
> they break anything?). I already recommend Julia for technical computing 
> (quant/financial) at least (to learn/try); there may be issues (especially 
> for those doing non-technical) - for now. That seems to be changing fast.
>
> I would be preaching to the choir saying Julia is great for its target 
> audience. But why do you just want to unify all of technical computing in 
> one language and not all of computing? "A fresh approach to technical 
> computing" might stop other people from considering Julia. I guess it's 
> good to have a niche but I hope other people do not get scared away.
>
> What is needed is to support all the important platforms so that people 
> will not overlook Julia as "it doesn't support my work or run on my 
> platform". This means the web (JavaScript as an "assembly language" 
> target), Android (and iOS..).
>
>
> At least Bezanson seems to like (love?) Scheme ("femtolisp"). I wander if 
> Scheme/Lisp (or any language) is *clearly* better than Julia for anything? 
> Or would he stop using Scheme except to maintain Julia's core.. [Maybe 
> femtolisp should be removed from Julia (e.g. to bootstrap Julia)..]
>
> While functional style is getting more popular, people seem to like 
> imperative and Julia isn't either or. Can/should !-functions be enforced? 
> It is only a recommendation?
>
> I know Lisp-syntax is "simple". Maybe non-infix notation is "better" in a 
> language but only for the interpreter it seems; or in regular math, had it 
> been used first/what people are used to. I and most people just don't see 
> it. I wander if there is anything to this other than preference. The 
> S-expressions that come with Lisp and infix, do they have an inherent 
> advantage that Julia can't match? In other words, I think that means, are 
> Julia's "Lisp-like" macros and its homoiconicity as powerful as Lisp's?
>
> As for the (linked) lists (L in Lisp), of course we need lists (and trees) 
> sometimes and Julia has them, but as a basic data structure of a language, 
> seems to me to be a performance killer. I do not see caches (locality of 
> reference) going away any time soon..
>
>
> As all (Turing-complete) languages are equivalent in a sense, one can't be 
> more "powerful" than another; "C can implement Lisp", but without that 
> exception ("Greenspunning"), programming a new runtime, languages with real 
> macros can be more powerful. I used to associate macros with Lisp, are 
> there (m)any other "ALGOL-like"/non-S-expression/not-list-based languages 
> with real macros? Is Julia a first? I understand macros are the key to 
> Lisp's power and Lisp is said to be the most powerful language.
>
>
> In short is there any area where another language (which one and for what) 
> would be (*clearly*) better (not just slightly, see my metric below)? Maybe 
> I'm not asking the 

Re: [julia-users] Re: What is Julia bad for - currently? Practically (or theoretically) - any other language more "powerful"?

[Tamas Papp]

On Fri, Dec 05 2014, ivo welch  wrote:

> the most immediate problems for using julia in teaching (instead of R) are 
> (a) the lack of local experts and (b) the lack of books.  perl won out 
> around here because of two books: Learning Perl and the Perl Cookbook.  I 
> can't emphasize enough how much these two books did for perl adoption.  R 
> is tolerable only because it has such a terrific and deep support group 
> (mailing list) on the internet.

I wanted to switch to Julia (from R) for a teaching course
(computational methods in economics), and decided against it for now,
for the following reasons:

1. plotting is not (yet) comparable,
2. debugging in Julia is currently more difficult than R,
3. the library syntax is a moving target.

Still, given the pace the master branch is moving at, I guess a year
from now Julia will be ready for teaching a course to non-CS students. I
am very much looking forward to this, R has a lot of quirks and traps
that distract students from the course content, Julia has a much more
consistent design.

Best,

Tamas