Re: [julia-users] Julia package style / learning

[Ivar Nesje]

Just for the record. To convert from Array{Array{Float64, 1}, 1} to 
Array{Float64,2} you can use hcat(a...)

Ivar

kl. 15:50:36 UTC+1 mandag 24. mars 2014 skrev Ethan Anderes følgende:
>
> Yep, that was my situation: no linear algebra but a lot of grabbing 
> columns within for loops. Looking forward to non-copying array slices:) 
>
> Thanks,
> Ethan
>

Re: [julia-users] Julia package style / learning

[Ethan Anderes]

Yep, that was my situation: no linear algebra but a lot of grabbing columns 
within for loops. Looking forward to non-copying array slices:) 

Thanks,
Ethan

Re: [julia-users] Julia package style / learning

[John Myles White]

I think comparisons between those two will depend a lot on context. If you need 
to use linear algebra functions, the Array{Array{Float64, 1}, 1} approach won’t 
work at all, so it’ll be infinitely slow. If you’re constantly just grabbing 
columns stored that way, it might be faster since you might avoid some copying 
— at the moment, for an array, A, A[:, i] does a copy which you might slow 
things down depending on context.

 — John

On Mar 24, 2014, at 7:33 AM, Ethan Anderes  wrote:

> I'm definitely not an expert but I thought I would chime in on your "arrays 
> of arrays vrs matrices" question. 
> 
> I recently developed a project where I started out using: 
> Array{Array{Float64,1},1} as a container for a set of state vectors in an ODE 
> flow. This seemed most natural but I figured once I got it to work, I would 
> speed it up by representing everything in a compact matrix representation: 
> Array{Float64,2}. However, I was never able to speed things up much with 
> Array{Float64,2} over the Array{Array{Float64,1},1} container. 
> 
> I ended up with the impression  (experts can confirm or deny this) that 
> although Array{Float64,2} may be stored in memory more compactly than 
> Array{Array{Float64,1},1}, the latter container is already very efficient so 
> that any speed gains were marginal.
> 
> Is this the experience of others?
> 
> Cheers,
> Ethan

[julia-users] Julia package style / learning

[Ethan Anderes]

I'm definitely not an expert but I thought I would chime in on your "arrays of 
arrays vrs matrices" question. 

I recently developed a project where I started out using: 
Array{Array{Float64,1},1} as a container for a set of state vectors in an ODE 
flow. This seemed most natural but I figured once I got it to work, I would 
speed it up by representing everything in a compact matrix representation: 
Array{Float64,2}. However, I was never able to speed things up much with 
Array{Float64,2} over the Array{Array{Float64,1},1} container. 

I ended up with the impression  (experts can confirm or deny this) that 
although Array{Float64,2} may be stored in memory more compactly than 
Array{Array{Float64,1},1}, the latter container is already very efficient so 
that any speed gains were marginal.

Is this the experience of others?

Cheers,
Ethan

[julia-users] Julia package style / learning

[Ryan Gehring]

Hey all,
I decided to start learning Julia over the weekend and am having fun so 
far. I implemented the wikipedia single layer perceptron algorithm as well 
as kendall's tau to see what it would be like to develop a medium sized 
package in the language. Link to the repo is below (the title just popped 
into my head there's no amazing product or grand plan meant by the name.)

https://github.com/rgehring/SimpleNets

As a student of the language I'd love to hear anyone's thoughts on any 
style issues or mistakes they see, I'm sure there are plenty. Here are some 
things I think I did wrong right off the top of my head...

   - Submodule importing. In src/util/association_measures.jl I wanted to 
   just expose KendallsTau.kendallstau as AssociationMeasures.kendallstau and 
   I think I should have used import rather than include / using ?
   - Test inclusion strategy: I thought it would make sense to have a unit 
   test file for every src file and to import the src file at the top of each 
   test, but this makes the tests brittle to directory changes, is it a better 
   idea to include all the files in test_runner.jl?
   - Excessively specific typing and casting to ints and floats.
   - Arrays of Arrays - should I have used matrices or the native 
   multidimensional array structure?

Here are some things that I think might be good:

   - Tried to keep a reasonable degree of abstraction on all the files, 
   although I may have been too heavy on the use of submodules.
   - Test coverage + a (very basic) actual statistical validation script 
   for the algorithms.
   - Tried to be explicit about public API's to the submodules. I may have 
   carried this too far with src/util/association_measures.jl which is 
   basically an interface module designed to only expose the public API's of 
   each included submodule (presently only KendallsTau).

I'm potentially interested in contributing to the codebase as a way to keep 
learning, does anyone have any small, bite-sized github issues they'd be 
interested in help with or seeing a pull request for?