Re: [julia-users] line continuation

[Gunnar Farnebäck]

You can also use parentheses to make the first line incomplete.

if (a>b
&& b>c)

Den torsdagen den 17:e april 2014 kl. 00:30:41 UTC+2 skrev K leo:
>
> Thanks for the answer. 
>
> I tested previously this but it did not work: 
> if a>b && b>c && c>d 
>  && d>e && e>f 
>
> But now this works: 
> if a>b && b>c && c>d && 
>  d>e && e>f 
>
> So the && got to be on the end of the first for it to know that the line 
> is not finished. 
>
>
> On 04/17/2014 06:25 AM, Stefan Karpinski wrote: 
> > If the expression is incomplete, continuation is automatic. There is no 
> explicit continuation syntax. 
> > 
> >> On Apr 16, 2014, at 6:01 PM, cnbiz850 > 
> wrote: 
> >> 
> >> Searched but didn't find an answer. 
> >> 
> >> Does Julia allow statement to continue on the next line? 
>
>

[julia-users] Re: Should 10x1 Array{Float64,2} be the same than 10-element Array{Float64,1}

[joanenric barcelo]

Hi James,

Thank you for your answer!
I agree with you in all. Of course column vectors and row vectors are 
different things all together and I fully agree they should be treated in a 
different way. However, my example is a little bit different. I'm dealing 
with column vectors all the time, but the Type is different when you 
construct them using e.g. zeros(10,1) or zeros(10). Both constructors will 
create a 10x1 (column vector), but they will be treated differently in some 
parts of the code since they belong to different types (kinda matrix and 
array respectively). 

Hope it make sense

El miércoles, 16 de abril de 2014 16:25:23 UTC+1, James Porter escribió:
>
> Hi joanenric—
>
> Julia makes a distinction between column vectors (10-element 
> Array{Float64,1}) and row vectors (10x1 Array{Float64,2}). You can see this 
> reflected in how they print:
>
> julia> [1,2,3]
> 3-element Array{Int64,1}:
>  1
>  2
>  3  # column vector
>
> julia> [1 2 3]
> 1x3 Array{Int64,2}:
>  1  2  3  # row vector
>
>
> This takes a bit of getting used to coming from other numerical computing 
> environments (I know it took me a while to notice and learn the 
> difference), but it is sensible from the perspective of mathematics: column 
> and row vectors are different kinds of objects with different behavior. For 
> most things if you just want a vector you want a column vector.
>
> I don't know too much about DataFrames, but I believe that columns of a 
> DataFrame are defined to be columns vectors, so what's actually happening 
> when you say:
>
> df2 = DataFrame(A = ones(2,1))
>
> is that you are getting a 1-row DataFrame, whose first element in the "A" 
> column, is a two-element row vector:
>
> julia> df2[:A]
> 1-element DataArray{Array{Float64,2},1}:
>  2x1 Array{Float64,2}:
>  1.0
>  1.0
>
> Does that make sense? I'm somewhat surprised that the DataFrames 
> constructor doesn't raise a warning here, given the potential for confusion.
>
> —James
>
> On Wednesday, April 16, 2014 6:20:04 AM UTC-5, joanenric barcelo wrote:
>>
>> Hello,
>>
>> I'm coming from Matlab and now, I'm staring playing with Julia and her 
>> packages. One of the things that surprised me the most is that ones(1)  and 
>> ones(1,1) does not output the same result. The first one outputs 10-element 
>> Array{Float64,1} while the second command 10x1 Array{Float64,2}. In most 
>> situations this behavior is all right. However, when I was experimenting 
>> with DataFrames.jl the behavior is slightly different. The output is 
>> similar to as follows
>>
>> julia> df1 = DataFrame(A = ones(2))
>> 2x1 DataFrame
>> ¦¦--¦
>> ¦ Row #  ¦ A¦
>> ¦ 1  ¦ 1.0  ¦
>> ¦ 2  ¦ 1.0  ¦
>>
>>
>> julia> df2 = DataFrame(A = ones(2,1))
>> 2x1 DataFrame
>> ¦¦--¦
>> ¦ Row #  ¦ A¦
>> ¦ 1  ¦ 2x1 Array{Float64,2}: 
>> 1.0
>> 1.0 ¦
>> In the second option, the whole array is stored in the first position of 
>> the first column so I cannot access easily to the single elements of the 
>> DataFrame. Let's say
>>
>> julia> df2[1, :A]
>> 2x1 Array{Float64,2}:
>>  1.0
>>  1.0
>>
>> julia> df2[2, :A]
>> ERROR: BoundError()
>>
>>
>> one way to overcome this situation is explicitly add [:] to the 
>> {Float64,2} array
>>
>> julia> df2 = DataFrame(A = ones(2,1)[:])
>> 2x1 DataFrame
>> ¦¦--¦
>> ¦ Row #  ¦ A¦
>> ¦ 1  ¦ 1.0  ¦
>> ¦ 2  ¦ 1.0  ¦
>>
>> Should it be considered an issue or it is actually made on purpose for 
>> other situations?
>>
>

Re: [julia-users] Should 10x1 Array{Float64,2} be the same than 10-element Array{Float64,1}

[joanenric barcelo]

Thanks for your reply John.

It was confusing for me at the beginning when using your package. 
Mathematically, zeros(3,1) and zeros(3) are both column vectors and 
intuitively they should be treated similarly. It took me a while to figure 
out the error.

Thanks and congrats for your great work with DataFrames package.



El miércoles, 16 de abril de 2014 19:16:30 UTC+1, John Myles White escribió:
>
> Yes, this is a less well-known property of DataFrames: they'll allow 
> anything as inputs, including objects of very high order. That's actually 
> useful, especially when working with Hive. But it is confusing, so we could 
> raise an error when taking in a scalar object of a type that has ndims > 1.
>
>  -- John
>
> On Apr 16, 2014, at 8:25 AM, James Porter > 
> wrote:
>
> Hi joanenric—
>
> Julia makes a distinction between column vectors (10-element 
> Array{Float64,1}) and row vectors (10x1 Array{Float64,2}). You can see this 
> reflected in how they print:
>
> julia> [1,2,3]
> 3-element Array{Int64,1}:
>  1
>  2
>  3  # column vector
>
> julia> [1 2 3]
> 1x3 Array{Int64,2}:
>  1  2  3  # row vector
>
>
> This takes a bit of getting used to coming from other numerical computing 
> environments (I know it took me a while to notice and learn the 
> difference), but it is sensible from the perspective of mathematics: column 
> and row vectors are different kinds of objects with different behavior. For 
> most things if you just want a vector you want a column vector.
>
> I don't know too much about DataFrames, but I believe that columns of a 
> DataFrame are defined to be columns vectors, so what's actually happening 
> when you say:
>
> df2 = DataFrame(A = ones(2,1))
>
> is that you are getting a 1-row DataFrame, whose first element in the "A" 
> column, is a two-element row vector:
>
> julia> df2[:A]
> 1-element DataArray{Array{Float64,2},1}:
>  2x1 Array{Float64,2}:
>  1.0
>  1.0
>
> Does that make sense? I'm somewhat surprised that the DataFrames 
> constructor doesn't raise a warning here, given the potential for confusion.
>
> —James
>
> On Wednesday, April 16, 2014 6:20:04 AM UTC-5, joanenric barcelo wrote:
>>
>> Hello,
>>
>> I'm coming from Matlab and now, I'm staring playing with Julia and her 
>> packages. One of the things that surprised me the most is that ones(1)  and 
>> ones(1,1) does not output the same result. The first one outputs 10-element 
>> Array{Float64,1} while the second command 10x1 Array{Float64,2}. In most 
>> situations this behavior is all right. However, when I was experimenting 
>> with DataFrames.jl the behavior is slightly different. The output is 
>> similar to as follows
>>
>> julia> df1 = DataFrame(A = ones(2))
>> 2x1 DataFrame
>> ¦¦--¦
>> ¦ Row #  ¦ A¦
>> ¦ 1  ¦ 1.0  ¦
>> ¦ 2  ¦ 1.0  ¦
>>
>>
>> julia> df2 = DataFrame(A = ones(2,1))
>> 2x1 DataFrame
>> ¦¦--¦
>> ¦ Row #  ¦ A¦
>> ¦ 1  ¦ 2x1 Array{Float64,2}: 
>> 1.0
>> 1.0 ¦
>> In the second option, the whole array is stored in the first position of 
>> the first column so I cannot access easily to the single elements of the 
>> DataFrame. Let's say
>>
>> julia> df2[1, :A]
>> 2x1 Array{Float64,2}:
>>  1.0
>>  1.0
>>
>> julia> df2[2, :A]
>> ERROR: BoundError()
>>
>>
>> one way to overcome this situation is explicitly add [:] to the 
>> {Float64,2} array
>>
>> julia> df2 = DataFrame(A = ones(2,1)[:])
>> 2x1 DataFrame
>> ¦¦--¦
>> ¦ Row #  ¦ A¦
>> ¦ 1  ¦ 1.0  ¦
>> ¦ 2  ¦ 1.0  ¦
>>
>> Should it be considered an issue or it is actually made on purpose for 
>> other situations?
>>
>
>

[julia-users] Re: Performance expectations and benchmarks

[Tobias Knopp]

I would like to second this. Actually this was one reason I stopped working 
on a template based c++ multi-dimentional array library I was working on 
before. While one can get very fast results and a very clean interface with 
c++ templates, the effort to get there is very huge. Compile times are the 
major gotcha for me in combination with error messages that are unreadable.

I then reimplemented some code to Julia and was at about the same speed 
(factor 1.2) and this was so frustrating that I decided to better 
investigate into Julia.

Recently, SIMD vectorization using the @simd macro landed in Julia master 
but I have not benchmarked it against the C/C++ gcc autovectorizer so far.

The missing OpenMP like parallelization is one of the last things that 
could take me writing a performance critical part in C/C++. But this is 
IMHO absolutely ok at this point. I once played a little bit around with 
calling a Julia function from a multhreaded for loop in C and even got it 
working when precompiling the Julia function. But getting this really 
working would require to make Julia internally thread-safe, which is a 
major effort.

Am Donnerstag, 17. April 2014 08:21:18 UTC+2 schrieb John Travers:
>
> Hi Gilberto,
>
> I am currently translating a very complex and highly tuned C++ code for 
> solving some PDEs to Julia. This code is heavily template based and has 
> many 'custom' classes. It has been tuned very carefully for inlining, 
> vectorization and performance in general.
>
> In general my Julia code (which involves types, parametrization and 
> closures) is within a factor of 2 in performance after a first translation 
> attempt, but I can often get it down to 1.2x after careful profiling and 
> optimisation. This is compared to my C++ code compiled with full safe 
> optimisation (i.e O3 with g++), but without using parallelism (can't quite 
> beat openmp with Julia's current parallel tools).
>
> Hope that helps. I was skeptical at first too, but after many personal 
> benchmarks and code translations I am now totally convinced with the < 2x 
> performance (along with the many other associated benefits of using Julia).
>
> Cheers,
> John
>
>
>
>

Re: [julia-users] Re: How to use GLPK.exact ?

[Carlo Baldassi]

Stéphane, sorry for the confusion (I should have made myself clearer
before), but the new version of the blog post is not correct, in that the
difference between 1-X and 1.-X has nothing to do with Int64 vs Float64,
but rather with the difference between the operators `-` (minus) and `.-`
(dot-minus, i.e. element-wise-minus). That's because the expressions above
are parsed as 1 - X and 1 .- X so the number on the left is always an Int.
(Using spaces around operators is always advisable for clarity anyway, and
in this case where ambiguity can arise it may become mandatory at some
point.)
So the main points are:

i) when dealing with Arrays, `-` and `.-` are distinct. In Julia 0.2 you
are allowed to use `Number - Array` (or `Array + Number` etc.), but in
upcoming Julia 0.3 you'll receive a warning telling you to use `Number .-
Array` instead (or `Array .+ Number` etc.), and you would only use `-` (and
`+`) between Arrays of the same shape.

ii) using an Int is no problem, it will get automatically promoted and
there is no ambiguity, and this is not going to change.



On Sat, Apr 12, 2014 at 5:50 PM, Stéphane Laurent wrote:

> Thank you everybody. I have updated my blog 
> post,
> especially to include Carlo's comments.
> Unfortunately I have some problems to use JuMP (I have opened another
> discussion about it). And installing pycddlib on Windows 64bit is a real
> nightmare.
>

[julia-users] Re: Performance expectations and benchmarks

[Gunnar Farnebäck]

I have, in the process of evaluating Julia, ported some proprietary matlab 
image processing code, at the order of 3k lines matlab and 1k lines C mex 
code, into pure Julia. The matlab code is fairly well optimized with most 
computations vectorized (usually comes natural in image processing) and 
some critical hot spots offloaded to C. The Julia code is mostly direct 
translations of the vectorized matlab code and the loopy C code. 

For recent versions of Julia this results in about twice the speed of 
Matlab 2007b. With Matlab 2013b the difference is substantially smaller but 
should still be in Julia's favor (not fully investigated yet). However, the 
same algorithms also have highly optimized C++ implementations, which are 
more than 10 times faster than both Julia and Matlab.

My profiling analysis points to two areas that primarily hold back Julia's 
performance on this code:
1. For the tight loop code ported from C, Julia loses on SIMD optimizations 
and OpenMP multithreading.
2. For the vectorized code Julia seems to spend way too much time on memory 
management.

Den torsdagen den 17:e april 2014 kl. 03:24:54 UTC+2 skrev Gilberto Noronha:
>
> Hi all,
>
> I was looking at some benchmark results (mainly the ones on julialang.org) 
> and I could not resist the thought that they are a bit misleading. I say 
> this as a Julia fan (I wish I did not think this way!) because 
> realistically I don't think one can expect a real world Julia application 
> to be even close (performance-wise)  to a highly optimized C, C++ or 
> Fortran program (the website suggests that the performance ratio is almost 
> one to one).
>
> In my (highly subjective) experience it is possible to hope for a Julia 
> program to be competitive with Java and Go (which is already a very good 
> thing, when Python and Matlab can be hundreds of times slower!). 
> But I am curious about other's experiences and whether I could find "more 
> realistic" benchmarks. In particular, I am curious about benchmarks 
> involving custom objects/classes. My gut feeling is that Julia is not as 
> good with those, but I believe it still beats Matlab very easily (because, 
> among other things, Matlab classes seem to be horribly slow).
>
> Any thoughts?
>
> Gilberto  
>

[julia-users] Re: question on multiple assignment

[Gunnar Farnebäck]

You can do multiple assignment with anything you can iterate over on the 
right hand side, in this case you could do e.g. aa, bb = 12:3:15 with the 
same assignment to aa and bb. One difference is in the value of the 
expression, as printed by the REPL, which coincides with the RHS but would 
usually be discarded. A more interesting difference is how well the code 
generation can optimize away or avoid generating temporary objects for the 
RHS, in your case a tuple and an array respectively, in my example a range. 
I don't have sufficiently deep insights to say something with confidence 
here but in my opinion your first option is the most natural one and I'd be 
surprised if any other solution would be more efficient.

Den torsdagen den 17:e april 2014 kl. 05:40:18 UTC+2 skrev K leo:
>
> Can anyone explain the difference of the following 2 ways?  Which is 
> more preferred? 
>
> julia> aa, bb = 12, 15 
> (12,15) 
>
> julia> aa, bb = [12, 15] 
> 2-element Array{Int64,1}: 
>   12 
>   15 
>
>

Re: [julia-users] Re: How to use GLPK.exact ?

[Stéphane Laurent]

Thank you Iain I will try your solver soon I hope. And thank you again 
Carlo, I will update my post.

Re: [julia-users] interp1-like functionality from Grid.jl

[Tim Holy]

That's fine. That's how it always works; things happen in Julia when someone 
finds the time to do them.

--Tim

On Wednesday, April 16, 2014 10:07:46 PM Spencer Lyon wrote:
> I'd love to beef up this wrapper type and add it to grid, but unfortunately
> I wont' be able to get to it for a while -- probably late June.
> 
> On Tuesday, April 15, 2014 9:06:57 AM UTC-4, Tim Holy wrote:
> > On Tuesday, April 15, 2014 05:35:27 AM Spencer Lyon wrote:
> > > It seems to me that this would be fairly standard functionality. I am
> > 
> > sure
> > 
> > > there is a benefit to having the default getindex methods deal in “index
> > > units” instead of physical ones, but I can’t tell what that benefit is?
> > 
> > Is
> > 
> > > there a reason you chose to have it set up the way it is?
> > 
> > When physical units = indexing units, you save one multiply and one add on
> > each interpolation operation. So it's best to implement the base operation
> > "minimally," and add wrapper types that require more operations around it.
> > I've not personally ever needed anything else (I mostly do interpolation
> > on
> > images), and no one else has added it to Grid, either.
> > 
> > If you wanted to add your wrapper type to Grid, I think that would be
> > great.
> > Some additional things to think about:
> > - Derivatives (here, the chain rule is your friend)
> > - Dimensions higher than 1
> > - It's no longer just a shift, it's also scaled, so a name change might be
> > in
> > order.
> > 
> > --Tim

[julia-users] question on generating random numbers

[X Du]

Hi All,

  Is there a comment to save and restore the current state to reproduce 
exactly the same random numbers? e.g. the code in Matlab:

stream = RandStream.getGlobalStream;
savedState = stream.State;
u1 = rand(1,5)
u1 =
0.81470.90580.12700.91340.6324

stream.State = savedState;
u2 = rand(1,5)
u2 =
0.81470.90580.12700.91340.6324

Thanks!

Isaac

[julia-users] Question on generating rand numbers with fixed state

[X Du]

 Hi All,

 Is there some comments to save or load a particular state when generating 
rand numbers?  
e.g. the code in Matlab:

stream = RandStream.getGlobalStream;
savedState = stream.State;
u1 = rand(1,5)
u1 =
0.81470.90580.12700.91340.6324

stream.State = savedState;
u2 = rand(1,5)
u2 =
0.81470.90580.12700.91340.6324

which can produce exactly the same random numbers.


Thanks!

Isaac

Re: [julia-users] Question on generating rand numbers with fixed state

[Isaiah Norton]

Try srand:

http://docs.julialang.org/en/release-0.2/stdlib/base/#random-numbers


On Thu, Apr 17, 2014 at 6:45 AM, X Du  wrote:

>
>  Hi All,
>
>  Is there some comments to save or load a particular state when generating
> rand numbers?
> e.g. the code in Matlab:
>
> stream = RandStream.getGlobalStream;
> savedState = stream.State;
> u1 = rand(1,5)
> u1 =
> 0.81470.90580.12700.91340.6324
>
> stream.State = savedState;
> u2 = rand(1,5)
> u2 =
> 0.81470.90580.12700.91340.6324
>
> which can produce exactly the same random numbers.
>
>
> Thanks!
>
> Isaac
>
>
>
>

[julia-users] Re: question on multiple assignment

[Toivo Henningsson]

Yes, the first option should be preferred. It should compile down to just 
the same as aa = 12, bb = 15.
The second option afaik forces Julia to allocate an Array object, fill it 
in, read back the element values, and discard the Array object.

On Thursday, 17 April 2014 11:56:52 UTC+2, Gunnar Farnebäck wrote:
>
> You can do multiple assignment with anything you can iterate over on the 
> right hand side, in this case you could do e.g. aa, bb = 12:3:15 with the 
> same assignment to aa and bb. One difference is in the value of the 
> expression, as printed by the REPL, which coincides with the RHS but would 
> usually be discarded. A more interesting difference is how well the code 
> generation can optimize away or avoid generating temporary objects for the 
> RHS, in your case a tuple and an array respectively, in my example a range. 
> I don't have sufficiently deep insights to say something with confidence 
> here but in my opinion your first option is the most natural one and I'd be 
> surprised if any other solution would be more efficient.
>
> Den torsdagen den 17:e april 2014 kl. 05:40:18 UTC+2 skrev K leo:
>>
>> Can anyone explain the difference of the following 2 ways?  Which is 
>> more preferred? 
>>
>> julia> aa, bb = 12, 15 
>> (12,15) 
>>
>> julia> aa, bb = [12, 15] 
>> 2-element Array{Int64,1}: 
>>   12 
>>   15 
>>
>>

[julia-users] Help performance for loop

[El suisse]

Hi, I want improve the performance of the for loop, any suggestion?

https://gist.github.com/elsuizo/10986149

I try:

k3 = Int64[ sum(s .< z[i]) for i = 2:n-1]

but is still slower than Matlab


Thanks in advance

Re: [julia-users] Help performance for loop

[Stefan Karpinski]

First off, try putting it inside of a function instead of in global scope:

http://julia.readthedocs.org/en/latest/manual/performance-tips/#avoid-global-variables


On Thu, Apr 17, 2014 at 10:15 AM, El suisse  wrote:

> Hi, I want improve the performance of the for loop, any suggestion?
>
> https://gist.github.com/elsuizo/10986149
>
> I try:
>
> k3 = Int64[ sum(s .< z[i]) for i = 2:n-1]
>
> but is still slower than Matlab
>
>
> Thanks in advance
>

Re: [julia-users] Re: Create formatted string

[Stefan Karpinski]

I'm not sure what you mean, but doing things in a loop and timing it is the
normal way. The lack of usefulness of my answer may be indicative that I
don't understand the question.


On Wed, Apr 16, 2014 at 11:13 PM, Dominique Orban  wrote:

> How would one go about benchmarking a set of implementations like those?
>
>
> On Sunday, April 13, 2014 3:22:58 PM UTC-7, Stefan Karpinski wrote:
>
>> Please don't do this – or if you do and your program is amazingly slow,
>> then consider yourself warned. You can define a custom formatting function
>> pretty easily:
>>
>> julia> fmt = "%8.1e"
>> "%8.1e"
>>
>> julia> @eval dofmt(x) = @sprintf($fmt, x)
>> dofmt (generic function with 1 method)
>>
>> julia> dofmt(1)
>> " 1.0e+00"
>>
>> julia> dofmt(123.456)
>> " 1.2e+02"
>>
>>
>> The difference is that you compile the function definition with eval
>> *once* and then call it many times, rather than calling eval every time you
>> want to print something.
>>
>>
>> On Sun, Apr 13, 2014 at 6:17 PM, Mike Innes  wrote:
>>
>>> It occurs to me that, if you really need this, you can define
>>>
>>> sprintf(args...) = eval(:@sprintf($(args...)))
>>>
>>> It's not pretty or ideal in terms of performance, but it will do the job.
>>>
>>> fmt = "%8.1e"
>>> sprintf(fmt, 3.141) #=> " 3.1e+00"
>>>
>>> On Sunday, 13 April 2014 22:47:12 UTC+1, Dominique Orban wrote:

 So what's the preferred Julia syntax to achieve what I meant here:

 julia> fmt = "%8.1e";
 julia> @sprintf(fmt, 3.1415)
 ERROR: first or second argument must be a format string



 On Sunday, April 13, 2014 1:31:57 PM UTC-7, John Myles White wrote:
>
> As far as the macro is concerned, the splat isn’t executed: it’s just
> additional syntax that gets taken in as a whole expression.
>
> The contrast between how a function with splatting works and how a
> macro with splatting works might be helpful:
>
> julia> function splat(a, b...)
>println(a)
>println(b)
>return
>end
> splat (generic function with 2 methods)
>
> julia> splat(1, 2, 3)
> 1
> (2,3)
>
> julia> splat(1, [2, 3]...)
> 1
> (2,3)
>
> julia> macro splat(a, b...)
>   println(a)
>   println(b)
>   :()
>   end
>
> julia> @splat(1, 2, 3)
> 1
> (2,3)
> ()
>
> julia> @splat(1, [2, 3]...)
> 1
> (:([2,3]...),)
> ()
>
>
>  — John
>
> On Apr 13, 2014, at 1:20 PM, Jeff Waller  wrote:
>
> > Likewise I am having problems with @sprintf
> >
> > Is this because @sprinf is macro?  The shorthand of expanding a
> printf with format the contents of an array is desirable.  I would have
> expected the ... operator to take an array of length 2 and turn it into 2
> arguments.
> >
> > julia> X=[1 2]
> >1x2 Array{Int64,2}:
> > 1  2
> >
> > julia> @sprintf("%d%d",1,2)
> > "12"
> >
> > julia> @sprintf("%d%d",X...)
> > ERROR: @sprintf: wrong number of arguments
> >
> > julia> @sprintf("%d%d",(1,2)...)
> > ERROR: @sprintf: wrong number of arguments
> >
> > julia> @sprintf("%d",X...)
> > ERROR: error compiling anonymous: unsupported or misplaced
> expression ... in function anonymous
> > in sprint at io.jl:460
> > in sprint at io.jl:464
> >
> > julia> macroexpand(quote @sprintf("%d%d",X...) end)
> > :($(Expr(:error, ErrorException("@sprintf: wrong number of
> arguments"
> >
>
>
>>

[julia-users] Type of elements in array comprehension

[Paweł Biernat]

Could someone please explain to me the difference between the two cases?

julia> y=[1]
1-element Array{Int64,1}:
 1

julia> [y[1] for i=1]
1-element Array{Any,1}:
 1

julia> [y[1]]
1-element Array{Int64,1}:
 1

In particular, why is in the first case the element type is Any, but in the 
second case it is Int64?

Re: [julia-users] Type of elements in array comprehension

[John Myles White]

Because list comprehensions in the global scope can't be sure that you aren't 
changing the type of y along the way.

 -- John

On Apr 17, 2014, at 7:37 AM, Paweł Biernat  wrote:

> Could someone please explain to me the difference between the two cases?
> 
> julia> y=[1]
> 1-element Array{Int64,1}:
>  1
> 
> julia> [y[1] for i=1]
> 1-element Array{Any,1}:
>  1
> 
> julia> [y[1]]
> 1-element Array{Int64,1}:
>  1
> 
> In particular, why is in the first case the element type is Any, but in the 
> second case it is Int64?

Re: [julia-users] Type of elements in array comprehension

[Paweł Biernat]

Can you elaborate on that?  How can you change the type of y in my example?

W dniu czwartek, 17 kwietnia 2014 16:38:48 UTC+2 użytkownik John Myles 
White napisał:
>
> Because list comprehensions in the global scope can't be sure that you 
> aren't changing the type of y along the way.
>
>  -- John
>
> On Apr 17, 2014, at 7:37 AM, Paweł Biernat > 
> wrote:
>
> Could someone please explain to me the difference between the two cases?
>
> julia> y=[1]
> 1-element Array{Int64,1}:
>  1
>
> julia> [y[1] for i=1]
> 1-element Array{Any,1}:
>  1
>
> julia> [y[1]]
> 1-element Array{Int64,1}:
>  1
>
> In particular, why is in the first case the element type is Any, but in 
> the second case it is Int64?
>
>
>

Re: [julia-users] Type of elements in array comprehension

[John Myles White]

y = [1]

y = [1.0]

[y[1] for i = 1]

On Apr 17, 2014, at 7:44 AM, Paweł Biernat  wrote:

> Can you elaborate on that?  How can you change the type of y in my example?
> 
> W dniu czwartek, 17 kwietnia 2014 16:38:48 UTC+2 użytkownik John Myles White 
> napisał:
> Because list comprehensions in the global scope can't be sure that you aren't 
> changing the type of y along the way.
> 
>  -- John
> 
> On Apr 17, 2014, at 7:37 AM, Paweł Biernat  wrote:
> 
>> Could someone please explain to me the difference between the two cases?
>> 
>> julia> y=[1]
>> 1-element Array{Int64,1}:
>>  1
>> 
>> julia> [y[1] for i=1]
>> 1-element Array{Any,1}:
>>  1
>> 
>> julia> [y[1]]
>> 1-element Array{Int64,1}:
>>  1
>> 
>> In particular, why is in the first case the element type is Any, but in the 
>> second case it is Int64?
> 

Re: [julia-users] Type of elements in array comprehension

[Tim Holy]

A more elaborate example:

julia> y = [1,2]
2-element Array{Int64,1}:
 1
 2

julia> [(y = float64(y); y[i]) for i = 1:2]
2-element Array{Any,1}:
 1.0
 2.0

When your code is inside a function, julia will analyze it and determine that 
the type isn't changing.

--Tim

On Thursday, April 17, 2014 07:56:28 AM John Myles White wrote:
> y = [1]
> 
> y = [1.0]
> 
> [y[1] for i = 1]
> 
> On Apr 17, 2014, at 7:44 AM, Paweł Biernat  wrote:
> > Can you elaborate on that?  How can you change the type of y in my
> > example?
> > 
> > W dniu czwartek, 17 kwietnia 2014 16:38:48 UTC+2 użytkownik John Myles
> > White napisał: Because list comprehensions in the global scope can't be
> > sure that you aren't changing the type of y along the way.> 
> >  -- John
> > 
> > On Apr 17, 2014, at 7:37 AM, Paweł Biernat  wrote:
> >> Could someone please explain to me the difference between the two cases?
> >> 
> >> julia> y=[1]
> >> 
> >> 1-element Array{Int64,1}:
> >>  1
> >> 
> >> julia> [y[1] for i=1]
> >> 
> >> 1-element Array{Any,1}:
> >>  1
> >> 
> >> julia> [y[1]]
> >> 
> >> 1-element Array{Int64,1}:
> >>  1
> >> 
> >> In particular, why is in the first case the element type is Any, but in
> >> the second case it is Int64?

Re: [julia-users] Type of elements in array comprehension

[Paweł Biernat]

I see that you change the type of y, but you do that before using the list 
comprehension.  I still don't get why [y[1] for i = 1] should give a 
different result than [y[1]] when used in the same conditions.

W dniu czwartek, 17 kwietnia 2014 16:56:28 UTC+2 użytkownik John Myles 
White napisał:
>
> y = [1]
>
> y = [1.0]
>
> [y[1] for i = 1]
>
> On Apr 17, 2014, at 7:44 AM, Paweł Biernat > 
> wrote:
>
> Can you elaborate on that?  How can you change the type of y in my example?
>
> W dniu czwartek, 17 kwietnia 2014 16:38:48 UTC+2 użytkownik John Myles 
> White napisał:
>>
>> Because list comprehensions in the global scope can't be sure that you 
>> aren't changing the type of y along the way.
>>
>>  -- John
>>
>> On Apr 17, 2014, at 7:37 AM, Paweł Biernat  wrote:
>>
>> Could someone please explain to me the difference between the two cases?
>>
>> julia> y=[1]
>> 1-element Array{Int64,1}:
>>  1
>>
>> julia> [y[1] for i=1]
>> 1-element Array{Any,1}:
>>  1
>>
>> julia> [y[1]]
>> 1-element Array{Int64,1}:
>>  1
>>
>> In particular, why is in the first case the element type is Any, but in 
>> the second case it is Int64?
>>
>>
>>
>

[julia-users] OpenGL <-> OpenCV <-> Julia

[Simon Danisch]

Hi,
I wondered, if it isn't about time to sit together and discuss the bindings 
between Julia, OpenGL and OpenCL and define APIs and a general structure.
I'm always tending to ignore CUDA, as I don't like to support something 
that tries to enforce a monopoly, but I guess it can't be ignored it should 
be put into the mix as well...

When I read through the mailing-list, it seems that there are multiple 
people working on this, but without a lot of inter communication between 
the parties.
I hope we can change this, as for example the OpenGL and OpenCL packages 
should be developed very congruently.
A lot of things are very similar between OpenGL and OpenCL.
For example, automatic kernel/shader generation, or Arrays, that need to be 
uploaded/downloaded to video memory.
It would be a pity, if we develop completely different APIs for these 
operation, and even worse, have redundant code.
I must admit, planning this all out goes a little bit over my expertise and 
time budget. 
But I would be very happy to participate in a discussion and redefine the 
OpenGL package accordingly.
It would be incredibly awesome, if we can build an API with an unified and 
concise way of defining kernels, that can be run in parallel on any kind of 
back-end.
The final transformations of the data for a nice visualization should also 
work hand in hand with this.

Topics that need to be discussed (that I can think of, there are definitely 
more)

   - What is the right platform to discuss this? (a new mailing-list? 
   Julia-dev? Github?)
   - Is it possible to create efficient kernel code from LLVM code for 
   OpenGL, CUDA, OpenCL
   - What are the alternatives
   - How does an array/datatypes need to be designed, to work with 
   Julia/OpenCL/OpenGL seamlessly
   - How to glue everything together
   - Syntax for choosing the device and operation
   - Make more hardware information available in Julia, to enable macros 
   like @OpenGL3.3?

I hope we can find a few people and work together on this!

Best,
Simon

Re: [julia-users] Type of elements in array comprehension

[Paweł Biernat]

Thanks, now I get why it doesn't work as I expected.  Enclosing the array 
comprehension in a function, as you suggested, works much better

julia> g(y)=[y[1] for i=1]
g (generic function with 1 method)

julia> g(y)
1-element Array{Float64,1}:
 1.0


W dniu czwartek, 17 kwietnia 2014 17:03:53 UTC+2 użytkownik Tim Holy 
napisał:
>
> A more elaborate example: 
>
> julia> y = [1,2] 
> 2-element Array{Int64,1}: 
>  1 
>  2 
>
> julia> [(y = float64(y); y[i]) for i = 1:2] 
> 2-element Array{Any,1}: 
>  1.0 
>  2.0 
>
> When your code is inside a function, julia will analyze it and determine 
> that 
> the type isn't changing. 
>
> --Tim 
>
> On Thursday, April 17, 2014 07:56:28 AM John Myles White wrote: 
> > y = [1] 
> > 
> > y = [1.0] 
> > 
> > [y[1] for i = 1] 
> > 
> > On Apr 17, 2014, at 7:44 AM, Paweł Biernat 
> > > 
> wrote: 
> > > Can you elaborate on that?  How can you change the type of y in my 
> > > example? 
> > > 
> > > W dniu czwartek, 17 kwietnia 2014 16:38:48 UTC+2 użytkownik John Myles 
> > > White napisał: Because list comprehensions in the global scope can't 
> be 
> > > sure that you aren't changing the type of y along the way.> 
> > >  -- John 
> > > 
> > > On Apr 17, 2014, at 7:37 AM, Paweł Biernat  
> wrote: 
> > >> Could someone please explain to me the difference between the two 
> cases? 
> > >> 
> > >> julia> y=[1] 
> > >> 
> > >> 1-element Array{Int64,1}: 
> > >>  1 
> > >> 
> > >> julia> [y[1] for i=1] 
> > >> 
> > >> 1-element Array{Any,1}: 
> > >>  1 
> > >> 
> > >> julia> [y[1]] 
> > >> 
> > >> 1-element Array{Int64,1}: 
> > >>  1 
> > >> 
> > >> In particular, why is in the first case the element type is Any, but 
> in 
> > >> the second case it is Int64? 
>

Re: [julia-users] Re: Performance expectations and benchmarks

[Stefan Karpinski]

Another example that was posted some time ago was this comparison of a
Julia finite element programming implementation with FEniCS (Python/C++)
and FreeFem++ (C++):

http://www.codeproject.com/Articles/579983/Finite-Element-programming-in-Julia

There's a fair body of evidence at this point that you really do generally
get into that 1-2x C range with Julia code. It's typical for the first
thing you try to be in the 1-5x range, and getting down to the 1-2x range
is fairly straightforward – avoid
globals,
make sure your code is
type-stable,
hoist 
allocationsout
of loops, use
@inboundswhere
appropriate, and try the built-in
profiler . Contrary
to some impressions, Julia's vectorized code isn't slower than vectorized
NumPy or Matlab – it's usually faster – but it can be "slow" in the sense
that it's not as fast as devectorized Julia, which is at or close to C
speed.

Gunnar mentioned SIMD and OpenMP as weak spots compared to heavily
optimized C code, and this is indeed the case – although a lot of
progresshas been made
recently in on SIMD support. Of course, if you already have
highly optimized C code that uses SIMD or OpenMP, you can just call it from
Julia – we do this with BLAS, LAPACK, FFTW, and other high-performance
libraries. Wrapping these kinds of libraries is easy and has the same exact
performance as calling them from C.

Bottom line: if you want to write normal, single-threaded C-style code
(i.e. not using SIMD or OpenMP pragmas, or heavy use of pthreads), then you
can definitely get comparable performance from straightforward Julia code.


On Thu, Apr 17, 2014 at 5:24 AM, Gunnar Farnebäck wrote:

> I have, in the process of evaluating Julia, ported some proprietary matlab
> image processing code, at the order of 3k lines matlab and 1k lines C mex
> code, into pure Julia. The matlab code is fairly well optimized with most
> computations vectorized (usually comes natural in image processing) and
> some critical hot spots offloaded to C. The Julia code is mostly direct
> translations of the vectorized matlab code and the loopy C code.
>
> For recent versions of Julia this results in about twice the speed of
> Matlab 2007b. With Matlab 2013b the difference is substantially smaller but
> should still be in Julia's favor (not fully investigated yet). However, the
> same algorithms also have highly optimized C++ implementations, which are
> more than 10 times faster than both Julia and Matlab.
>
> My profiling analysis points to two areas that primarily hold back Julia's
> performance on this code:
> 1. For the tight loop code ported from C, Julia loses on SIMD
> optimizations and OpenMP multithreading.
> 2. For the vectorized code Julia seems to spend way too much time on
> memory management.
>
> Den torsdagen den 17:e april 2014 kl. 03:24:54 UTC+2 skrev Gilberto
> Noronha:
>
>> Hi all,
>>
>> I was looking at some benchmark results (mainly the ones on julialang.org)
>> and I could not resist the thought that they are a bit misleading. I say
>> this as a Julia fan (I wish I did not think this way!) because
>> realistically I don't think one can expect a real world Julia application
>> to be even close (performance-wise)  to a highly optimized C, C++ or
>> Fortran program (the website suggests that the performance ratio is almost
>> one to one).
>>
>> In my (highly subjective) experience it is possible to hope for a Julia
>> program to be competitive with Java and Go (which is already a very good
>> thing, when Python and Matlab can be hundreds of times slower!).
>> But I am curious about other's experiences and whether I could find "more
>> realistic" benchmarks. In particular, I am curious about benchmarks
>> involving custom objects/classes. My gut feeling is that Julia is not as
>> good with those, but I believe it still beats Matlab very easily (because,
>> among other things, Matlab classes seem to be horribly slow).
>>
>> Any thoughts?
>>
>> Gilberto
>>
>

Re: [julia-users] Help performance for loop

[El suisse]

Thanks for the fast reply ¡¡ :)

try something like this?

function k_vector(s :: Array{Float64,1}, z :: Array{Float64,1})
n = length(s)
k = Int64[sum(s .< z[i]) for i = 2:n-1]

return k
end



yes is better, but not so much. Maybe with another more smart method for
calculate k






2014-04-17 11:22 GMT-03:00 Stefan Karpinski :

> First off, try putting it inside of a function instead of in global scope:
>
>
> http://julia.readthedocs.org/en/latest/manual/performance-tips/#avoid-global-variables
>
>
> On Thu, Apr 17, 2014 at 10:15 AM, El suisse  wrote:
>
>> Hi, I want improve the performance of the for loop, any suggestion?
>>
>> https://gist.github.com/elsuizo/10986149
>>
>> I try:
>>
>> k3 = Int64[ sum(s .< z[i]) for i = 2:n-1]
>>
>> but is still slower than Matlab
>>
>>
>> Thanks in advance
>>
>
>

Re: [julia-users] OpenGL <-> OpenCV <-> Julia

[Tim Holy]

Another issue, especially relevant if you throw CUDA into the mix, is that 
there may be some tension between "making a common interface," "exposing the 
functionality in the underlying toolkit," and "making it familiar to people 
migrating to Julia with experience in other domains." There will be some 
inevitable tradeoffs, but that doesn't mean it's not worth thinking about.

With regards to array/datatypes, I'm a bit skeptical that there will be such a 
thing as "seamless" interoperability. Because of the overhead of transport, I 
suspect that it's too important to know whether your array is in main memory 
or is on the device. As an example, in my own work I've avoided implementing 
`getindex` for arrays that are living on the device. But that doesn't mean 
that you can't have a rich range of operations possible with arrays on the 
device, it just means you have to provide the functionality in terms of device 
code.

Of course, getting to the point of being able to compile Julia code to kernel 
code will change everything :). Looking forward to that day.

--Tim

On Thursday, April 17, 2014 08:07:01 AM Simon Danisch wrote:
> Hi,
> I wondered, if it isn't about time to sit together and discuss the bindings
> between Julia, OpenGL and OpenCL and define APIs and a general structure.
> I'm always tending to ignore CUDA, as I don't like to support something
> that tries to enforce a monopoly, but I guess it can't be ignored it should
> be put into the mix as well...
> 
> When I read through the mailing-list, it seems that there are multiple
> people working on this, but without a lot of inter communication between
> the parties.
> I hope we can change this, as for example the OpenGL and OpenCL packages
> should be developed very congruently.
> A lot of things are very similar between OpenGL and OpenCL.
> For example, automatic kernel/shader generation, or Arrays, that need to be
> uploaded/downloaded to video memory.
> It would be a pity, if we develop completely different APIs for these
> operation, and even worse, have redundant code.
> I must admit, planning this all out goes a little bit over my expertise and
> time budget.
> But I would be very happy to participate in a discussion and redefine the
> OpenGL package accordingly.
> It would be incredibly awesome, if we can build an API with an unified and
> concise way of defining kernels, that can be run in parallel on any kind of
> back-end.
> The final transformations of the data for a nice visualization should also
> work hand in hand with this.
> 
> Topics that need to be discussed (that I can think of, there are definitely
> more)
> 
>- What is the right platform to discuss this? (a new mailing-list?
>Julia-dev? Github?)
>- Is it possible to create efficient kernel code from LLVM code for
>OpenGL, CUDA, OpenCL
>- What are the alternatives
>- How does an array/datatypes need to be designed, to work with
>Julia/OpenCL/OpenGL seamlessly
>- How to glue everything together
>- Syntax for choosing the device and operation
>- Make more hardware information available in Julia, to enable macros
>like @OpenGL3.3?
> 
> I hope we can find a few people and work together on this!
> 
> Best,
> Simon

Re: [julia-users] Help performance for loop

[Steven G. Johnson]

On Thursday, April 17, 2014 11:24:44 AM UTC-4, El suisse wrote:
>
> function k_vector(s :: Array{Float64,1}, z :: Array{Float64,1})
> n = length(s)
> k = Int64[sum(s .< z[i]) for i = 2:n-1]
>

 This allocates a temporary array (to hold s .< z[i]) for each i.To 
optimize this sort of code in Julia, you usually want to devectorize it and 
just write a loop:

function k_vector2(s, z)
n = length(s)
k = Array(Int64, n-2)
for i = 2:n-1
c = 0
for j = 1:n
c += s[j] < z[i]
end
k[i-1] = c
end
return k
end

However, when benchmarking against Matlab, there is another thing to be 
careful of.  By default, many Matlab operations will use multiple threads 
if you have a multi-core machine.  To perform an apples-to-apples 
comparison of serial performance you should launch Matlab with the 
-singleCompThread option.

Re: [julia-users] Performance expectations and benchmarks

[Steven G. Johnson]

On Wednesday, April 16, 2014 9:54:31 PM UTC-4, Gilberto Noronha wrote:
>
> Well, I would like to see something with custom types and more complexity.
>
>>
Just to expand on Jameson's comments, one of the remarkable things about 
Julia is that types that are built-in in other languages are actually 
implemented in Julia code, even the basic numeric types like integers and 
floating-point types.  Of course, certain operations like 32-bit integer 
addition that map directly to hardware instructions will benefit from that, 
but e.g. look at Julia's complex-number type for a basic numeric type where 
operations are explicitly coded in Julia.

If you look in Julia's standard library 
(https://github.com/JuliaLang/julia/tree/master/base), you will find that 
there is generally nothing "magic" about the built-in types, other than the 
fact that they are bundled with Julia, that you cannot replicate in user 
code.

So, even a "simple" benchmark is actually exercising a large and complex 
library written in Julia.

Re: [julia-users] Create formatted string

[John Myles White]

I think the question is how to time a proposed sprintf() function vs. the 
existing @sprintf macro.

 -- John

On Apr 17, 2014, at 7:27 AM, Stefan Karpinski  wrote:

> I'm not sure what you mean, but doing things in a loop and timing it is the 
> normal way. The lack of usefulness of my answer may be indicative that I 
> don't understand the question.
> 
> 
> On Wed, Apr 16, 2014 at 11:13 PM, Dominique Orban  
> wrote:
> How would one go about benchmarking a set of implementations like those?
> 
> 
> On Sunday, April 13, 2014 3:22:58 PM UTC-7, Stefan Karpinski wrote:
> Please don't do this – or if you do and your program is amazingly slow, then 
> consider yourself warned. You can define a custom formatting function pretty 
> easily:
> 
> julia> fmt = "%8.1e"
> "%8.1e"
> 
> julia> @eval dofmt(x) = @sprintf($fmt, x)
> dofmt (generic function with 1 method)
> 
> julia> dofmt(1)
> " 1.0e+00"
> 
> julia> dofmt(123.456)
> " 1.2e+02"
> 
> The difference is that you compile the function definition with eval *once* 
> and then call it many times, rather than calling eval every time you want to 
> print something.
> 
> 
> On Sun, Apr 13, 2014 at 6:17 PM, Mike Innes  wrote:
> It occurs to me that, if you really need this, you can define
> 
> sprintf(args...) = eval(:@sprintf($(args...)))
> 
> It's not pretty or ideal in terms of performance, but it will do the job.
> 
> fmt = "%8.1e"
> sprintf(fmt, 3.141) #=> " 3.1e+00"
> 
> On Sunday, 13 April 2014 22:47:12 UTC+1, Dominique Orban wrote:
> So what's the preferred Julia syntax to achieve what I meant here:
> 
> julia> fmt = "%8.1e";
> julia> @sprintf(fmt, 3.1415)
> ERROR: first or second argument must be a format string
> 
> 
> 
> On Sunday, April 13, 2014 1:31:57 PM UTC-7, John Myles White wrote:
> As far as the macro is concerned, the splat isn’t executed: it’s just 
> additional syntax that gets taken in as a whole expression. 
> 
> The contrast between how a function with splatting works and how a macro with 
> splatting works might be helpful: 
> 
> julia> function splat(a, b...) 
>println(a) 
>println(b) 
>return 
>end 
> splat (generic function with 2 methods) 
> 
> julia> splat(1, 2, 3) 
> 1 
> (2,3) 
> 
> julia> splat(1, [2, 3]...) 
> 1 
> (2,3) 
> 
> julia> macro splat(a, b...) 
>   println(a) 
>   println(b) 
>   :() 
>   end 
> 
> julia> @splat(1, 2, 3) 
> 1 
> (2,3) 
> () 
> 
> julia> @splat(1, [2, 3]...) 
> 1 
> (:([2,3]...),) 
> () 
> 
> 
>  — John 
> 
> On Apr 13, 2014, at 1:20 PM, Jeff Waller  wrote: 
> 
> > Likewise I am having problems with @sprintf 
> > 
> > Is this because @sprinf is macro?  The shorthand of expanding a printf with 
> > format the contents of an array is desirable.  I would have expected the 
> > ... operator to take an array of length 2 and turn it into 2 arguments. 
> > 
> > julia> X=[1 2] 
> >1x2 Array{Int64,2}: 
> > 1  2 
> > 
> > julia> @sprintf("%d%d",1,2) 
> > "12" 
> > 
> > julia> @sprintf("%d%d",X...) 
> > ERROR: @sprintf: wrong number of arguments 
> > 
> > julia> @sprintf("%d%d",(1,2)...) 
> > ERROR: @sprintf: wrong number of arguments 
> > 
> > julia> @sprintf("%d",X...) 
> > ERROR: error compiling anonymous: unsupported or misplaced expression 
> > ... in function anonymous 
> > in sprint at io.jl:460 
> > in sprint at io.jl:464 
> > 
> > julia> macroexpand(quote @sprintf("%d%d",X...) end) 
> > :($(Expr(:error, ErrorException("@sprintf: wrong number of 
> > arguments" 
> > 
> 
> 
> 

Re: [julia-users] Help performance for loop

[El suisse]

Yeah Julia wins¡¡  :) Thanks for fast reply and the amazing open-source
language

pd : Is hard to reset the brain for devectorization ¡¡

pd2 : This part of code is the implementation of this paper(if anyone is
interested):

http://mortari.tamu.edu/k-vector/AAS%2000-128.pdf






2014-04-17 12:36 GMT-03:00 Steven G. Johnson :

>
>
> On Thursday, April 17, 2014 11:24:44 AM UTC-4, El suisse wrote:
>>
>> function k_vector(s :: Array{Float64,1}, z :: Array{Float64,1})
>> n = length(s)
>> k = Int64[sum(s .< z[i]) for i = 2:n-1]
>>
>
>  This allocates a temporary array (to hold s .< z[i]) for each i.To
> optimize this sort of code in Julia, you usually want to devectorize it and
> just write a loop:
>
> function k_vector2(s, z)
> n = length(s)
> k = Array(Int64, n-2)
> for i = 2:n-1
> c = 0
> for j = 1:n
> c += s[j] < z[i]
> end
> k[i-1] = c
> end
> return k
> end
>
> However, when benchmarking against Matlab, there is another thing to be
> careful of.  By default, many Matlab operations will use multiple threads
> if you have a multi-core machine.  To perform an apples-to-apples
> comparison of serial performance you should launch Matlab with the
> -singleCompThread option.
>
>
>

[julia-users] Re: Question on generating rand numbers with fixed state

[X Du]

Thanks Isaiah,

 It seems that srand([*rng*], *seed*) does not work, I always got the error 
rng is not defined.
I tried to set MersenneTwister([*2*]) and use rand(*rng::AbstractRNG*[, 
*dims...*]) to generate the random number. It did not work.

Could you please give me an example? Many thanks in advance.

Isaac


On Thursday, April 17, 2014 12:45:01 PM UTC+2, X Du wrote:
>
>
>  Hi All,
>
>  Is there some comments to save or load a particular state when generating 
> rand numbers?  
> e.g. the code in Matlab:
>
> stream = RandStream.getGlobalStream;
> savedState = stream.State;
> u1 = rand(1,5)
> u1 =
> 0.81470.90580.12700.91340.6324
>
> stream.State = savedState;
> u2 = rand(1,5)
> u2 =
> 0.81470.90580.12700.91340.6324
>
> which can produce exactly the same random numbers.
>
>
> Thanks!
>
> Isaac
>
>
>
>

Re: [julia-users] Re: Question on generating rand numbers with fixed state

[Andreas Noack Jensen]

You can do

julia> srand(123)
julia> rand(3)
3-element Array{Float64,1}:
 0.768448
 0.940515
 0.673959

julia> srand(123)
julia> rand(3)
3-element Array{Float64,1}:
 0.768448
 0.940515
 0.673959

but it appears that something is wrong when using an RNG object.

2014-04-17 19:18 GMT+02:00 X Du :
>
>
> Thanks Isaiah,
>
>  It seems that srand([rng], seed) does not work, I always got the error
rng is not defined.
> I tried to set MersenneTwister([2]) and use rand(rng::AbstractRNG[,
dims...]) to generate the random number. It did not work.
>
> Could you please give me an example? Many thanks in advance.
>
> Isaac
>
>
>
> On Thursday, April 17, 2014 12:45:01 PM UTC+2, X Du wrote:
>>
>>
>>  Hi All,
>>
>>  Is there some comments to save or load a particular state when
generating rand numbers?
>> e.g. the code in Matlab:
>>
>> stream = RandStream.getGlobalStream;
>> savedState = stream.State;
>> u1 = rand(1,5)
>> u1 =
>> 0.81470.90580.12700.91340.6324
>>
>> stream.State = savedState;
>> u2 = rand(1,5)
>> u2 =
>> 0.81470.90580.12700.91340.6324
>>
>> which can produce exactly the same random numbers.
>>
>>
>> Thanks!
>>
>> Isaac
>>
>>
>>



--
Med venlig hilsen

Andreas Noack Jensen

Re: [julia-users] Re: Question on generating rand numbers with fixed state

[Miguel Bazdresch]

The distributions.jl package extends Julia's random number capabilities,
it's worth a look:

https://github.com/JuliaStats/Distributions.jl

-- mb


On Thu, Apr 17, 2014 at 1:18 PM, X Du  wrote:

>
> Thanks Isaiah,
>
>  It seems that srand([*rng*], *seed*) does not work, I always got the
> error rng is not defined.
> I tried to set MersenneTwister([*2*]) and use rand(*rng::AbstractRNG*[,
> *dims...*]) to generate the random number. It did not work.
>
> Could you please give me an example? Many thanks in advance.
>
> Isaac
>
>
> On Thursday, April 17, 2014 12:45:01 PM UTC+2, X Du wrote:
>>
>>
>>  Hi All,
>>
>>  Is there some comments to save or load a particular state when
>> generating rand numbers?
>> e.g. the code in Matlab:
>>
>> stream = RandStream.getGlobalStream;
>> savedState = stream.State;
>> u1 = rand(1,5)
>> u1 =
>> 0.81470.90580.12700.91340.6324
>>
>> stream.State = savedState;
>> u2 = rand(1,5)
>> u2 =
>> 0.81470.90580.12700.91340.6324
>>
>> which can produce exactly the same random numbers.
>>
>>
>> Thanks!
>>
>> Isaac
>>
>>
>>
>>

[julia-users] Re: OpenGL <-> OpenCV <-> Julia

[Simon Danisch]

These are exactly the issues we need to discuss!

Well, seamless is relative…
It would be already great, to have vector/matrix datatypes that doesn’t 
need to be converted before uploading. And we should agree on one and use 
them across all abstraction packages.
A normal array can be used for this. But as soon, as you put vectors into 
the array, things become a little more complex.

Also, having the same names for the same high-level functionalities would 
be already great (Like free, upload, etc).
For example, I have a function called render, which basically uploads 
anything it knows to a shader location. I’ve defined quite a few functions, 
to handle a lot of different argument type combinations. (And by now, 
render is really not a good name for it anymore)
Now the question would be, does someone have implemented something similar?
If yes, we should definitely try to agree on a name and functionality.

Well, there are a lot of questions like this and I don’t really know where 
to start.
Maybe everyone that did something into this direction can describe his 
approach, and we can start to figure out similarities and conflicts.
That would be already quite a good start, as doing this alone, by browsing 
packages from others is a very tiring job.
I hope, that we can end up with something like this:

 Incredibly awesome, High Level Packages
 /   |\
GLGraphics, GLPlot,etc  <=> ComputerVisionCL, NumberCrunchingCL <=> 
Vectorization
|  | |
OpenGL-Abstraction   <=>  OpenCL-Abstraction<=> 
SIMD-Abstraction
|  | |
OpenGL Interface <=> OpenCL Interface  <=> SIMD 
Interface

Whereas the Interfaces are written in Julia and are as bare bone as 
possible.

As you might have noticed, I’m working on an OpenGL-Util package, which is 
my version of an abstraction layer for OpenGL.
When I look left and right, I see, that there are similar abstraction 
packages on their way for CUDA and OpenCL.
So I just want to make sure that we all work into the same direction and 
interchange know how and code!

Best,
Simon

Re: [julia-users] Re: Question on generating rand numbers with fixed state

[Andreas Noack Jensen]

Distributions.jl provides much but all random number generation is done in
Base and right now there is only one RNG, i.e. the Mersenne Twister
implementation dSFMT.


2014-04-17 19:24 GMT+02:00 Miguel Bazdresch :

> The distributions.jl package extends Julia's random number capabilities,
> it's worth a look:
>
> https://github.com/JuliaStats/Distributions.jl
>
> -- mb
>
>
> On Thu, Apr 17, 2014 at 1:18 PM, X Du  wrote:
>
>>
>> Thanks Isaiah,
>>
>>  It seems that srand([*rng*], *seed*) does not work, I always got the
>> error rng is not defined.
>> I tried to set MersenneTwister([*2*]) and use rand(*rng::AbstractRNG*[,
>> *dims...*]) to generate the random number. It did not work.
>>
>> Could you please give me an example? Many thanks in advance.
>>
>> Isaac
>>
>>
>> On Thursday, April 17, 2014 12:45:01 PM UTC+2, X Du wrote:
>>>
>>>
>>>  Hi All,
>>>
>>>  Is there some comments to save or load a particular state when
>>> generating rand numbers?
>>> e.g. the code in Matlab:
>>>
>>> stream = RandStream.getGlobalStream;
>>> savedState = stream.State;
>>> u1 = rand(1,5)
>>> u1 =
>>> 0.81470.90580.12700.91340.6324
>>>
>>> stream.State = savedState;
>>> u2 = rand(1,5)
>>> u2 =
>>> 0.81470.90580.12700.91340.6324
>>>
>>> which can produce exactly the same random numbers.
>>>
>>>
>>> Thanks!
>>>
>>> Isaac
>>>
>>>
>>>
>>>
>


-- 
Med venlig hilsen

Andreas Noack Jensen

Re: [julia-users] OpenGL <-> OpenCV <-> Julia

[Jake Bolewski]

I would be up for working together to implement OpenGL <--> OpenCL 
integration.  No work has been done in this area because I don't need it 
and no-one has stepped up to implement it.  Another stumbling block is that 
the only GPU's I have access to run on a headless remote cluster. 

The surface area for OpenGL interop in the OpenCL API is pretty small, a 
handful of functions.  The main source of commonality between the OpenCL / 
OpenGL would be how to define the texture image datatypes.  This would be a 
great area to collaborate as we could share datatypes between the two 
libraries.  This functionality could be split out in its own package so 
OpenGL does not become a dependency for OpenCL.   It is useful to use 
Texture memory ("Images" in OpenCL parlance) in situations that do not 
require OpenGL, although as caches on GPU's increase in size the advantages 
of using Texture memory are diminishing.  I've implemented partial texture 
support in a branch of OpenCL.jl so that could be a point of discussion if 
you want to push things further. 

As for collaboration between higher level API's, I think that some 
commonality can be found between OpenCL, OpenGL, and CUDA.  All libraries 
have to copy data back and forth over some type of channel (a "stream" in 
CUDA, or a "queue" in OpenCL) and have some operations to manually manage 
(free).  These operations are not conceptually different from copying data 
to / from a remote processor so it would make sense for the API's of these 
libraries to align with what is in Base.  Cuda and OpenCL have to launch 
kernels over a range of data, so it might make sense to align these two 
API's.  I hope eventually we can implement a common GPUArray datatype with 
Cuda / OpenCL backends so this could be re-used as a common datatype for 
CUDA / OpenCL math libraries (BLAS, FFT) and common gpu array functions. 

On Thursday, April 17, 2014 11:28:53 AM UTC-4, Tim Holy wrote:
>
> Another issue, especially relevant if you throw CUDA into the mix, is that 
> there may be some tension between "making a common interface," "exposing 
> the 
> functionality in the underlying toolkit," and "making it familiar to 
> people 
> migrating to Julia with experience in other domains." There will be some 
> inevitable tradeoffs, but that doesn't mean it's not worth thinking about. 
>
> With regards to array/datatypes, I'm a bit skeptical that there will be 
> such a 
> thing as "seamless" interoperability. Because of the overhead of 
> transport, I 
> suspect that it's too important to know whether your array is in main 
> memory 
> or is on the device. As an example, in my own work I've avoided 
> implementing 
> `getindex` for arrays that are living on the device. But that doesn't mean 
> that you can't have a rich range of operations possible with arrays on the 
> device, it just means you have to provide the functionality in terms of 
> device 
> code. 
>
> Of course, getting to the point of being able to compile Julia code to 
> kernel 
> code will change everything :). Looking forward to that day. 
>
> --Tim 
>
> On Thursday, April 17, 2014 08:07:01 AM Simon Danisch wrote: 
> > Hi, 
> > I wondered, if it isn't about time to sit together and discuss the 
> bindings 
> > between Julia, OpenGL and OpenCL and define APIs and a general 
> structure. 
> > I'm always tending to ignore CUDA, as I don't like to support something 
> > that tries to enforce a monopoly, but I guess it can't be ignored it 
> should 
> > be put into the mix as well... 
> > 
> > When I read through the mailing-list, it seems that there are multiple 
> > people working on this, but without a lot of inter communication between 
> > the parties. 
> > I hope we can change this, as for example the OpenGL and OpenCL packages 
> > should be developed very congruently. 
> > A lot of things are very similar between OpenGL and OpenCL. 
> > For example, automatic kernel/shader generation, or Arrays, that need to 
> be 
> > uploaded/downloaded to video memory. 
> > It would be a pity, if we develop completely different APIs for these 
> > operation, and even worse, have redundant code. 
> > I must admit, planning this all out goes a little bit over my expertise 
> and 
> > time budget. 
> > But I would be very happy to participate in a discussion and redefine 
> the 
> > OpenGL package accordingly. 
> > It would be incredibly awesome, if we can build an API with an unified 
> and 
> > concise way of defining kernels, that can be run in parallel on any kind 
> of 
> > back-end. 
> > The final transformations of the data for a nice visualization should 
> also 
> > work hand in hand with this. 
> > 
> > Topics that need to be discussed (that I can think of, there are 
> definitely 
> > more) 
> > 
> >- What is the right platform to discuss this? (a new mailing-list? 
> >Julia-dev? Github?) 
> >- Is it possible to create efficient kernel code from LLVM code for 
> >OpenGL, CUDA, OpenCL 
> >- What are the a

Re: [julia-users] Create formatted string

[Dominique Orban]

Here are some timings comparing @printf with the proposed @eval option. I 
also wanted to try a variant that calls libc's printf directly. I came up 
with this implementation: https://gist.github.com/11000433. Its "advantage" 
is that you can print an array's address using %p (for what it's worth).

I didn't find a way around another @eval due to what ccall expects its 
arguments to look like. I thought it would be easy to call libc's printf, 
but it wasn't! (Also I'm sure cprintf should be more sophisticated than it 
currently is, but for now, it does what I need.)

Running time_printf.jl on my Macbook pro gives the following timings:

   macro  eval  libc
8.06e-05  5.91e-02  6.63e-03

These are averages over 1000 calls. The call to libc's printf isn't doing 
too badly compared to the simpler @eval proposed by Stefan. But I'm 
wondering if it's possible to avoid the @eval in cprintf and call the C 
function directly?!

Are there other options?

I'm all for performance but when it comes to printing, convenience and 
flexibility are also a must in my opinion. Because printing is inherently 
inefficient, I'm willing to accept performance hits there.

Many thanks for all the help.

ps: Shoudln't @time return the execution time?


On Thursday, April 17, 2014 9:17:59 AM UTC-7, John Myles White wrote:
>
> I think the question is how to time a proposed sprintf() function vs. the 
> existing @sprintf macro.
>
>  -- John
>
> On Apr 17, 2014, at 7:27 AM, Stefan Karpinski 
> > 
> wrote:
>
> I'm not sure what you mean, but doing things in a loop and timing it is 
> the normal way. The lack of usefulness of my answer may be indicative that 
> I don't understand the question.
>
>
> On Wed, Apr 16, 2014 at 11:13 PM, Dominique Orban 
> 
> > wrote:
>
>> How would one go about benchmarking a set of implementations like those?
>>
>>
>> On Sunday, April 13, 2014 3:22:58 PM UTC-7, Stefan Karpinski wrote:
>>
>>> Please don't do this – or if you do and your program is amazingly slow, 
>>> then consider yourself warned. You can define a custom formatting function 
>>> pretty easily:
>>>
>>> julia> fmt = "%8.1e"
>>> "%8.1e"
>>>
>>> julia> @eval dofmt(x) = @sprintf($fmt, x)
>>> dofmt (generic function with 1 method)
>>>
>>> julia> dofmt(1)
>>> " 1.0e+00"
>>>
>>> julia> dofmt(123.456)
>>> " 1.2e+02"
>>>
>>>
>>> The difference is that you compile the function definition with eval 
>>> *once* and then call it many times, rather than calling eval every time you 
>>> want to print something.
>>>  
>>>
>>> On Sun, Apr 13, 2014 at 6:17 PM, Mike Innes  wrote:
>>>
 It occurs to me that, if you really need this, you can define

 sprintf(args...) = eval(:@sprintf($(args...)))

 It's not pretty or ideal in terms of performance, but it will do the 
 job.

 fmt = "%8.1e"
 sprintf(fmt, 3.141) #=> " 3.1e+00"

 On Sunday, 13 April 2014 22:47:12 UTC+1, Dominique Orban wrote:
>
> So what's the preferred Julia syntax to achieve what I meant here:
>
> julia> fmt = "%8.1e";
> julia> @sprintf(fmt, 3.1415)
> ERROR: first or second argument must be a format string
>
>
>
> On Sunday, April 13, 2014 1:31:57 PM UTC-7, John Myles White wrote:
>>
>> As far as the macro is concerned, the splat isn’t executed: it’s just 
>> additional syntax that gets taken in as a whole expression. 
>>
>> The contrast between how a function with splatting works and how a 
>> macro with splatting works might be helpful: 
>>
>> julia> function splat(a, b...) 
>>println(a) 
>>println(b) 
>>return 
>>end 
>> splat (generic function with 2 methods) 
>>
>> julia> splat(1, 2, 3) 
>> 1 
>> (2,3) 
>>
>> julia> splat(1, [2, 3]...) 
>> 1 
>> (2,3) 
>>
>> julia> macro splat(a, b...) 
>>   println(a) 
>>   println(b) 
>>   :() 
>>   end 
>>
>> julia> @splat(1, 2, 3) 
>> 1 
>> (2,3) 
>> () 
>>
>> julia> @splat(1, [2, 3]...) 
>> 1 
>> (:([2,3]...),) 
>> () 
>>
>>
>>  — John 
>>
>> On Apr 13, 2014, at 1:20 PM, Jeff Waller  wrote: 
>>
>> > Likewise I am having problems with @sprintf 
>> > 
>> > Is this because @sprinf is macro?  The shorthand of expanding a 
>> printf with format the contents of an array is desirable.  I would have 
>> expected the ... operator to take an array of length 2 and turn it into 
>> 2 
>> arguments. 
>> > 
>> > julia> X=[1 2] 
>> >1x2 Array{Int64,2}: 
>> > 1  2 
>> > 
>> > julia> @sprintf("%d%d",1,2) 
>> > "12" 
>> > 
>> > julia> @sprintf("%d%d",X...) 
>> > ERROR: @sprintf: wrong number of arguments 
>> > 
>> > julia> @sprintf("%d%d",(1,2)...) 
>> > ERROR: @sprintf: wrong number of arguments 
>> > 
>> >  

[julia-users] Re: Performance expectations and benchmarks

[Gilberto Noronha]

Thank you all for your answers! I guess what I take from this is that 
things are better than I thought and I need to spend more serious time with 
Julia (so far, I've only done ports of small/toy programs, and without 
trying too hard to optimize things).
But maybe some of the things said here could figure more prominently on the 
documentation, like the state of support for OpenMP/SIMD?

Gilberto  

On Wednesday, 16 April 2014 21:24:54 UTC-4, Gilberto Noronha wrote:
>
> Hi all,
>
> I was looking at some benchmark results (mainly the ones on julialang.org) 
> and I could not resist the thought that they are a bit misleading. I say 
> this as a Julia fan (I wish I did not think this way!) because 
> realistically I don't think one can expect a real world Julia application 
> to be even close (performance-wise)  to a highly optimized C, C++ or 
> Fortran program (the website suggests that the performance ratio is almost 
> one to one).
>
> In my (highly subjective) experience it is possible to hope for a Julia 
> program to be competitive with Java and Go (which is already a very good 
> thing, when Python and Matlab can be hundreds of times slower!). 
> But I am curious about other's experiences and whether I could find "more 
> realistic" benchmarks. In particular, I am curious about benchmarks 
> involving custom objects/classes. My gut feeling is that Julia is not as 
> good with those, but I believe it still beats Matlab very easily (because, 
> among other things, Matlab classes seem to be horribly slow).
>
> Any thoughts?
>
> Gilberto  
>

[julia-users] Huge performance boost with USE_SYSTEM_LIBM=1

[John Travers]

For a function which contains many calls to exp, sin, cos I got about a 4x 
performance boost by compiling with USE_SYSTEM_LIBM=1. Is this expected? 
Why exactly does Julia bundle and default to using its own libm? For 
consistency and accuracy? I'm on the latest MacBook Pro with a Haswell CPU 
- maybe this is to do with AVX?

Re: [julia-users] Re: Performance expectations and benchmarks

[Stefan Karpinski]

SIMD support is experimental – and thus not documented – and OpenMP support
is non-existent. I'm not sure it makes sense to explicitly state that we
don't support OpenMP. Doesn't not mentioning it, imply that we don't
support it?


On Thu, Apr 17, 2014 at 3:44 PM, Gilberto Noronha wrote:

> Thank you all for your answers! I guess what I take from this is that
> things are better than I thought and I need to spend more serious time with
> Julia (so far, I've only done ports of small/toy programs, and without
> trying too hard to optimize things).
> But maybe some of the things said here could figure more prominently on
> the documentation, like the state of support for OpenMP/SIMD?
>
> Gilberto
>
>
> On Wednesday, 16 April 2014 21:24:54 UTC-4, Gilberto Noronha wrote:
>>
>> Hi all,
>>
>> I was looking at some benchmark results (mainly the ones on julialang.org)
>> and I could not resist the thought that they are a bit misleading. I say
>> this as a Julia fan (I wish I did not think this way!) because
>> realistically I don't think one can expect a real world Julia application
>> to be even close (performance-wise)  to a highly optimized C, C++ or
>> Fortran program (the website suggests that the performance ratio is almost
>> one to one).
>>
>> In my (highly subjective) experience it is possible to hope for a Julia
>> program to be competitive with Java and Go (which is already a very good
>> thing, when Python and Matlab can be hundreds of times slower!).
>> But I am curious about other's experiences and whether I could find "more
>> realistic" benchmarks. In particular, I am curious about benchmarks
>> involving custom objects/classes. My gut feeling is that Julia is not as
>> good with those, but I believe it still beats Matlab very easily (because,
>> among other things, Matlab classes seem to be horribly slow).
>>
>> Any thoughts?
>>
>> Gilberto
>>
>

Re: [julia-users] Huge performance boost with USE_SYSTEM_LIBM=1

[Stefan Karpinski]

Apple's libm is very good, which may explain some of this, but my guess is
that LLVM is clever enough to notice calls into the system libm and replace
them with x86 instructions for the same functions. The hardware
implementations are fast but don't always have the same accuracy as
openlibm. Other operating systems don't have nearly as good default libm's
– they are often inaccurate, slow, or both.


On Thu, Apr 17, 2014 at 4:07 PM, John Travers  wrote:

> For a function which contains many calls to exp, sin, cos I got about a 4x
> performance boost by compiling with USE_SYSTEM_LIBM=1. Is this expected?
> Why exactly does Julia bundle and default to using its own libm? For
> consistency and accuracy? I'm on the latest MacBook Pro with a Haswell
> CPU - maybe this is to do with AVX?
>
>

[julia-users] Bokeh Binding for Julia

[Samuel Colvin]

Access to Bokeh  would be an excellent extra 
string to Julia's plotting bow.

I guess for now it should be reasonably simple to use it though PyCall.

I've created an issue with 
Bokeh and as you can see they are willing to help.

Any other Julia people interested in using this?

Re: [julia-users] Huge performance boost with USE_SYSTEM_LIBM=1

[Simon Kornblith]

They still look like function calls to me, but given the performance 
difference, I would be surprised if they are as accurate. sin is >4x faster 
for Float64, which is on par with VML with 1 ulp accuracy, but VML has the 
benefit of vectorization. Indeed, if 
thisis
 the right file:

If the rounding mode is round-to-nearest, return sine(x) within a
few ULP.  The maximum error of this routine is not precisely
known.  The maximum error of the reduction might be around 3 ULP,
although this is partly a guess.  The polynomials have small
errors.  The polynomial evaluation might have an error under 1
ULP.  So the worst error for this routine might be under 4 ULP.


On Thursday, April 17, 2014 4:26:07 PM UTC-4, Stefan Karpinski wrote:
>
> Apple's libm is very good, which may explain some of this, but my guess is 
> that LLVM is clever enough to notice calls into the system libm and replace 
> them with x86 instructions for the same functions. The hardware 
> implementations are fast but don't always have the same accuracy as 
> openlibm. Other operating systems don't have nearly as good default libm's 
> – they are often inaccurate, slow, or both.
>
>
> On Thu, Apr 17, 2014 at 4:07 PM, John Travers 
> > wrote:
>
>> For a function which contains many calls to exp, sin, cos I got about a 
>> 4x performance boost by compiling with USE_SYSTEM_LIBM=1. Is this expected? 
>> Why exactly does Julia bundle and default to using its own libm? For 
>> consistency and accuracy? I'm on the latest MacBook Pro with a Haswell 
>> CPU - maybe this is to do with AVX?
>>
>>
>

[julia-users] array with different column types

[Stéphane Laurent]

Hello,

 I need to deal with some objects represented as arrays whose some columns 
are BigFloat, some columns are Int, some columns are logical. Is it a good 
idea to use a DataFrame ? Is there a better solution ?This is for a 
computationally intensive program.

[julia-users] Re: Performance expectations and benchmarks

[harven]

Le jeudi 17 avril 2014 03:24:54 UTC+2, Gilberto Noronha a écrit :
>
> Hi all,
>
> I was looking at some benchmark results (mainly the ones on julialang.org) 
> and I could not resist the thought that they are a bit misleading. I say 
> this as a Julia fan (I wish I did not think this way!) 
>

I also think that the benchmarks are misleading because it is easy to 
produce benchmarks that give the exact opposite conclusions as the one 
advertised on the main page. Don't misunderstand me, I think that julia is 
very interesting and it is a very promising language. tl;dr: don't take 
benchmarks too seriously.

So let us compute the product of the first 10 first integers.

# loop sucks
julia> @time let r = big(1) ; for i=1:10 r*=i end ; end
elapsed time: 9.886083072 seconds (9033715264 bytes allocated)

# don't use prod to compute a product
julia> @time prod([big(1):big(10)]);
elapsed time: 17.195070345 seconds (9045715656 bytes allocated)

# map is so fast
julia> @time mapreduce(big,*, 1:10) ;
elapsed time: 0.157378324 seconds (23751120 bytes allocated)

# the true way is to delegate the work to gmp (hello mathlab & python)
julia> @time factorial(big(10)) ;
elapsed time: 0.028151758 seconds (1154168 bytes allocated)

# the mandatory bug report :-)
julia> big(1):big(10)
1:10
julia> prod(big(1):big(10))
ERROR: no method prod_rgn(UnitRange{BigInt}, Int64, BigInt)
 in prod at reduce.jl:353
julia> prod(big(1):big(1):big(10))
ERROR: no method prod_rgn(StepRange{BigInt,BigInt}, Int64, BigInt)
 in prod at reduce.jl:353
#grmbl. 
julia> prod(big(1:10))  
3628800  # ah!

Re: [julia-users] array with different column types

[Stefan Karpinski]

A DataFrame does seem like a good option, but those have NA support that
you may not need. Can you elaborate a little more on the use case? Is it a
fixed set of column names and types? Or will you need to support different
schemas?


On Thu, Apr 17, 2014 at 5:16 PM, Stéphane Laurent wrote:

> Hello,
>
>  I need to deal with some objects represented as arrays whose some columns
> are BigFloat, some columns are Int, some columns are logical. Is it a good
> idea to use a DataFrame ? Is there a better solution ?This is for a
> computationally intensive program.
>

Re: [julia-users] Re: Performance expectations and benchmarks

[Stefan Karpinski]

... and you can write slow code in any language.


On Thu, Apr 17, 2014 at 5:19 PM, harven  wrote:

>
>
> Le jeudi 17 avril 2014 03:24:54 UTC+2, Gilberto Noronha a écrit :
>
>> Hi all,
>>
>> I was looking at some benchmark results (mainly the ones on julialang.org)
>> and I could not resist the thought that they are a bit misleading. I say
>> this as a Julia fan (I wish I did not think this way!)
>>
>
> I also think that the benchmarks are misleading because it is easy to
> produce benchmarks that give the exact opposite conclusions as the one
> advertised on the main page. Don't misunderstand me, I think that julia is
> very interesting and it is a very promising language. tl;dr: don't take
> benchmarks too seriously.
>
> So let us compute the product of the first 10 first integers.
>
> # loop sucks
> julia> @time let r = big(1) ; for i=1:10 r*=i end ; end
> elapsed time: 9.886083072 seconds (9033715264 bytes allocated)
>
> # don't use prod to compute a product
> julia> @time prod([big(1):big(10)]);
> elapsed time: 17.195070345 seconds (9045715656 bytes allocated)
>
> # map is so fast
> julia> @time mapreduce(big,*, 1:10) ;
> elapsed time: 0.157378324 seconds (23751120 bytes allocated)
>
> # the true way is to delegate the work to gmp (hello mathlab & python)
> julia> @time factorial(big(10)) ;
> elapsed time: 0.028151758 seconds (1154168 bytes allocated)
>
> # the mandatory bug report :-)
> julia> big(1):big(10)
> 1:10
> julia> prod(big(1):big(10))
> ERROR: no method prod_rgn(UnitRange{BigInt}, Int64, BigInt)
>  in prod at reduce.jl:353
> julia> prod(big(1):big(1):big(10))
> ERROR: no method prod_rgn(StepRange{BigInt,BigInt}, Int64, BigInt)
>  in prod at reduce.jl:353
> #grmbl.
> julia> prod(big(1:10))
> 3628800  # ah!
>
>

Re: [julia-users] Re: Performance expectations and benchmarks

[John Myles White]

I'm not sure this is a super helpful way to think about Julia. You're pretty 
aggresively mixing up a lot of different issues in your benchmarks: your first 
one is type-unstable; the next one does superfluous memory allocation; the 
third one is doing type conversion on the fly. Reaching conclusions based on a 
convenience sample of alternative function definitions seems a little fraught.

 -- John

On Apr 17, 2014, at 2:19 PM, harven  wrote:

> 
> 
> Le jeudi 17 avril 2014 03:24:54 UTC+2, Gilberto Noronha a écrit :
> Hi all,
> 
> I was looking at some benchmark results (mainly the ones on julialang.org) 
> and I could not resist the thought that they are a bit misleading. I say this 
> as a Julia fan (I wish I did not think this way!) 
> 
> I also think that the benchmarks are misleading because it is easy to produce 
> benchmarks that give the exact opposite conclusions as the one advertised on 
> the main page. Don't misunderstand me, I think that julia is very interesting 
> and it is a very promising language. tl;dr: don't take benchmarks too 
> seriously.
> 
> So let us compute the product of the first 10 first integers.
> 
> # loop sucks
> julia> @time let r = big(1) ; for i=1:10 r*=i end ; end
> elapsed time: 9.886083072 seconds (9033715264 bytes allocated)
> 
> # don't use prod to compute a product
> julia> @time prod([big(1):big(10)]);
> elapsed time: 17.195070345 seconds (9045715656 bytes allocated)
> 
> # map is so fast
> julia> @time mapreduce(big,*, 1:10) ;
> elapsed time: 0.157378324 seconds (23751120 bytes allocated)
> 
> # the true way is to delegate the work to gmp (hello mathlab & python)
> julia> @time factorial(big(10)) ;
> elapsed time: 0.028151758 seconds (1154168 bytes allocated)
> 
> # the mandatory bug report :-)
> julia> big(1):big(10)
> 1:10
> julia> prod(big(1):big(10))
> ERROR: no method prod_rgn(UnitRange{BigInt}, Int64, BigInt)
>  in prod at reduce.jl:353
> julia> prod(big(1):big(1):big(10))
> ERROR: no method prod_rgn(StepRange{BigInt,BigInt}, Int64, BigInt)
>  in prod at reduce.jl:353
> #grmbl. 
> julia> prod(big(1:10))  
> 3628800  # ah!
> 

Re: [julia-users] array with different column types

[John Myles White]

It's actually possible to place pure Julia vectors in a DataFrame, which might 
be convenient in this case. But you could always just store the columns in a 
Vector{Any}, which is what the DataFrame does behind the scenes anyway.

 -- John

On Apr 17, 2014, at 2:27 PM, Stefan Karpinski  wrote:

> A DataFrame does seem like a good option, but those have NA support that you 
> may not need. Can you elaborate a little more on the use case? Is it a fixed 
> set of column names and types? Or will you need to support different schemas?
> 
> 
> On Thu, Apr 17, 2014 at 5:16 PM, Stéphane Laurent  
> wrote:
> Hello,
> 
>  I need to deal with some objects represented as arrays whose some columns 
> are BigFloat, some columns are Int, some columns are logical. Is it a good 
> idea to use a DataFrame ? Is there a better solution ?This is for a 
> computationally intensive program.
> 

Re: [julia-users] array with different column types

[Stéphane Laurent]

Yes, there is a fixed number of columns with fixed types. There's no 
slowness with DataFrame or the Any type (as for dataframe and list in R) ?

Re: [julia-users] array with different column types

[John Myles White]

The thing that matters for speed is making sure that the columns has 
appropriate types. For example, do you really need BigFloat? That's a big 
performance loss -- much worse than fetching out of a Vector{Any}.

 -- John

On Apr 17, 2014, at 2:38 PM, Stéphane Laurent  wrote:

> Yes, there is a fixed number of columns with fixed types. There's no slowness 
> with DataFrame or the Any type (as for dataframe and list in R) ?

Re: [julia-users] array with different column types

[Stéphane Laurent]

Yes, I need BigFloat. 
For example, a DataFrame with only Int columns, is as performant as an 
Array{Int} ?

Le jeudi 17 avril 2014 23:39:28 UTC+2, John Myles White a écrit :
>
> The thing that matters for speed is making sure that the columns has 
> appropriate types. For example, do you really need BigFloat? That's a big 
> performance loss -- much worse than fetching out of a Vector{Any}. 
>
>  -- John 
>
> On Apr 17, 2014, at 2:38 PM, Stéphane Laurent 
> > 
> wrote: 
>
> > Yes, there is a fixed number of columns with fixed types. There's no 
> slowness with DataFrame or the Any type (as for dataframe and list in R) ? 
>
>

Re: [julia-users] array with different column types

[Simon Kornblith]

The most performant approach would be to store the columns as vectors in a 
tuple or immutable. DataFrames can be nearly as performant if you:

- Extract columns (df[:mycol]) and index into them whenever possible 
instead of indexing individual elements (df[1, :mycol])
- Add typeasserts when you perform indexing operations 
(df[:mycol]::Vector{Int}), or pass the columns to another function

Otherwise you will incur a slowdown because the compiler doesn't know the 
types.

Simon

On Thursday, April 17, 2014 5:34:24 PM UTC-4, John Myles White wrote:
>
> It's actually possible to place pure Julia vectors in a DataFrame, which 
> might be convenient in this case. But you could always just store the 
> columns in a Vector{Any}, which is what the DataFrame does behind the 
> scenes anyway.
>
>  -- John
>
> On Apr 17, 2014, at 2:27 PM, Stefan Karpinski 
> > 
> wrote:
>
> A DataFrame does seem like a good option, but those have NA support that 
> you may not need. Can you elaborate a little more on the use case? Is it a 
> fixed set of column names and types? Or will you need to support different 
> schemas?
>
>
> On Thu, Apr 17, 2014 at 5:16 PM, Stéphane Laurent 
> 
> > wrote:
>
>> Hello,
>>
>>  I need to deal with some objects represented as arrays whose some 
>> columns are BigFloat, some columns are Int, some columns are logical. Is it 
>> a good idea to use a DataFrame ? Is there a better solution ?This is for a 
>> computationally intensive program.
>>
>
>
>

Re: [julia-users] Re: Performance expectations and benchmarks

[harven]

Le jeudi 17 avril 2014 23:28:52 UTC+2, Stefan Karpinski a écrit :
>
> ... and you can write slow code in any language.
>

Sure. I am just pointing out that microbenchmarks are not always easy to 
interpret.

On a different subject, It would be nice to be able to pass big(1):big(10)  
to prod in order to avoid creating a temporary array but I don't know why 
this does not work. Should I raise an issue?

Also it would be nice if factorial raises a warning if its argument is an 
Int64 bigger than 20 (in which case an overflow occurs and the factorial 
does not return the correct result).

Thanks to the julia team for this very nice language!

Re: [julia-users] array with different column types

[Stéphane Laurent]

Thank you. I need to extract the lines too. A line looks like

 type line{T}

 a::T

 pair:Int

 end


This doesn't work, do you have something to propose :

D = DataFrame(A = [1.,2.], B = [1,2])

D[1,:]::line{Float64}


?

Le jeudi 17 avril 2014 23:48:29 UTC+2, Simon Kornblith a écrit :
>
> The most performant approach would be to store the columns as vectors in a 
> tuple or immutable. DataFrames can be nearly as performant if you:
>
> - Extract columns (df[:mycol]) and index into them whenever possible 
> instead of indexing individual elements (df[1, :mycol])
> - Add typeasserts when you perform indexing operations 
> (df[:mycol]::Vector{Int}), or pass the columns to another function
>
> Otherwise you will incur a slowdown because the compiler doesn't know the 
> types.
>
> Simon
>
> On Thursday, April 17, 2014 5:34:24 PM UTC-4, John Myles White wrote:
>>
>> It's actually possible to place pure Julia vectors in a DataFrame, which 
>> might be convenient in this case. But you could always just store the 
>> columns in a Vector{Any}, which is what the DataFrame does behind the 
>> scenes anyway.
>>
>>  -- John
>>
>> On Apr 17, 2014, at 2:27 PM, Stefan Karpinski  
>> wrote:
>>
>> A DataFrame does seem like a good option, but those have NA support that 
>> you may not need. Can you elaborate a little more on the use case? Is it a 
>> fixed set of column names and types? Or will you need to support different 
>> schemas?
>>
>>
>> On Thu, Apr 17, 2014 at 5:16 PM, Stéphane Laurent wrote:
>>
>>> Hello,
>>>
>>>  I need to deal with some objects represented as arrays whose some 
>>> columns are BigFloat, some columns are Int, some columns are logical. Is it 
>>> a good idea to use a DataFrame ? Is there a better solution ?This is for a 
>>> computationally intensive program.
>>>
>>
>>
>>

Re: [julia-users] array with different column types

[John Myles White]

Each row of a DataFrame is itself a DataFrame.

Why not just store things in a vector of Line objects?

type Line{T}
a::T
pair::Int
end

df = DataFrame(A = Line[Line(1.0, 1), Line(2.0, 2)])

I've changed things from your code because there's a convention of using 
uppercase letters to start the names of types.

 -- John

On Apr 17, 2014, at 3:18 PM, Stéphane Laurent  wrote:

> Thank you. I need to extract the lines too. A line looks like
> 
>  type line{T}
>  a::T
>  pair:Int
>  end
> 
> This doesn't work, do you have something to propose :
> 
> D = DataFrame(A = [1.,2.], B = [1,2])
> D[1,:]::line{Float64}
> 
> ?
> 
> Le jeudi 17 avril 2014 23:48:29 UTC+2, Simon Kornblith a écrit :
> The most performant approach would be to store the columns as vectors in a 
> tuple or immutable. DataFrames can be nearly as performant if you:
> 
> - Extract columns (df[:mycol]) and index into them whenever possible instead 
> of indexing individual elements (df[1, :mycol])
> - Add typeasserts when you perform indexing operations 
> (df[:mycol]::Vector{Int}), or pass the columns to another function
> 
> Otherwise you will incur a slowdown because the compiler doesn't know the 
> types.
> 
> Simon
> 
> On Thursday, April 17, 2014 5:34:24 PM UTC-4, John Myles White wrote:
> It's actually possible to place pure Julia vectors in a DataFrame, which 
> might be convenient in this case. But you could always just store the columns 
> in a Vector{Any}, which is what the DataFrame does behind the scenes anyway.
> 
>  -- John
> 
> On Apr 17, 2014, at 2:27 PM, Stefan Karpinski  wrote:
> 
>> A DataFrame does seem like a good option, but those have NA support that you 
>> may not need. Can you elaborate a little more on the use case? Is it a fixed 
>> set of column names and types? Or will you need to support different schemas?
>> 
>> 
>> On Thu, Apr 17, 2014 at 5:16 PM, Stéphane Laurent  wrote:
>> Hello,
>> 
>>  I need to deal with some objects represented as arrays whose some columns 
>> are BigFloat, some columns are Int, some columns are logical. Is it a good 
>> idea to use a DataFrame ? Is there a better solution ?This is for a 
>> computationally intensive program.
>> 
> 

Re: [julia-users] array with different column types

[Stéphane Laurent]

How do I extract a line and a column with this method ?



Le vendredi 18 avril 2014 00:21:26 UTC+2, John Myles White a écrit :
>
> Each row of a DataFrame is itself a DataFrame.
>
> Why not just store things in a vector of Line objects?
>
> type Line{T}
> a::T
> pair::Int
> end
>
> df = DataFrame(A = Line[Line(1.0, 1), Line(2.0, 2)])
>
> I've changed things from your code because there's a convention of using 
> uppercase letters to start the names of types.
>
>  -- John
>
> On Apr 17, 2014, at 3:18 PM, Stéphane Laurent 
> > 
> wrote:
>
> Thank you. I need to extract the lines too. A line looks like
>
>  type line{T}
>
>  a::T
>
>  pair:Int
>
>  end
>
>
> This doesn't work, do you have something to propose :
>
> D = DataFrame(A = [1.,2.], B = [1,2])
>
> D[1,:]::line{Float64}
>
>
> ?
>
> Le jeudi 17 avril 2014 23:48:29 UTC+2, Simon Kornblith a écrit :
>>
>> The most performant approach would be to store the columns as vectors in 
>> a tuple or immutable. DataFrames can be nearly as performant if you:
>>
>> - Extract columns (df[:mycol]) and index into them whenever possible 
>> instead of indexing individual elements (df[1, :mycol])
>> - Add typeasserts when you perform indexing operations 
>> (df[:mycol]::Vector{Int}), or pass the columns to another function
>>
>> Otherwise you will incur a slowdown because the compiler doesn't know the 
>> types.
>>
>> Simon
>>
>> On Thursday, April 17, 2014 5:34:24 PM UTC-4, John Myles White wrote:
>>>
>>> It's actually possible to place pure Julia vectors in a DataFrame, which 
>>> might be convenient in this case. But you could always just store the 
>>> columns in a Vector{Any}, which is what the DataFrame does behind the 
>>> scenes anyway.
>>>
>>>  -- John
>>>
>>> On Apr 17, 2014, at 2:27 PM, Stefan Karpinski  
>>> wrote:
>>>
>>> A DataFrame does seem like a good option, but those have NA support that 
>>> you may not need. Can you elaborate a little more on the use case? Is it a 
>>> fixed set of column names and types? Or will you need to support different 
>>> schemas?
>>>
>>>
>>> On Thu, Apr 17, 2014 at 5:16 PM, Stéphane Laurent wrote:
>>>
 Hello,

  I need to deal with some objects represented as arrays whose some 
 columns are BigFloat, some columns are Int, some columns are logical. Is 
 it 
 a good idea to use a DataFrame ? Is there a better solution ?This is for a 
 computationally intensive program.

>>>
>>>
>>>
>

Re: [julia-users] array with different column types

[John Myles White]

df[:A] gives you a column, which is vector of Line objects.

df[:A][1] gives you the first entry of that vector.

df[:A][1].a gives you the a element of the first entry of that vector.

I think you're better off just using a raw vector of immutables. Instead of 
defining type Line, define immutable Line.

 -- John

On Apr 17, 2014, at 3:33 PM, Stéphane Laurent  wrote:

> How do I extract a line and a column with this method ?
> 
> 
> 
> Le vendredi 18 avril 2014 00:21:26 UTC+2, John Myles White a écrit :
> Each row of a DataFrame is itself a DataFrame.
> 
> Why not just store things in a vector of Line objects?
> 
> type Line{T}
>   a::T
>   pair::Int
> end
> 
> df = DataFrame(A = Line[Line(1.0, 1), Line(2.0, 2)])
> 
> I've changed things from your code because there's a convention of using 
> uppercase letters to start the names of types.
> 
>  -- John
> 
> On Apr 17, 2014, at 3:18 PM, Stéphane Laurent  wrote:
> 
>> Thank you. I need to extract the lines too. A line looks like
>> 
>>  type line{T}
>>  a::T
>>  pair:Int
>>  end
>> 
>> This doesn't work, do you have something to propose :
>> 
>> D = DataFrame(A = [1.,2.], B = [1,2])
>> D[1,:]::line{Float64}
>> 
>> ?
>> 
>> Le jeudi 17 avril 2014 23:48:29 UTC+2, Simon Kornblith a écrit :
>> The most performant approach would be to store the columns as vectors in a 
>> tuple or immutable. DataFrames can be nearly as performant if you:
>> 
>> - Extract columns (df[:mycol]) and index into them whenever possible instead 
>> of indexing individual elements (df[1, :mycol])
>> - Add typeasserts when you perform indexing operations 
>> (df[:mycol]::Vector{Int}), or pass the columns to another function
>> 
>> Otherwise you will incur a slowdown because the compiler doesn't know the 
>> types.
>> 
>> Simon
>> 
>> On Thursday, April 17, 2014 5:34:24 PM UTC-4, John Myles White wrote:
>> It's actually possible to place pure Julia vectors in a DataFrame, which 
>> might be convenient in this case. But you could always just store the 
>> columns in a Vector{Any}, which is what the DataFrame does behind the scenes 
>> anyway.
>> 
>>  -- John
>> 
>> On Apr 17, 2014, at 2:27 PM, Stefan Karpinski  wrote:
>> 
>>> A DataFrame does seem like a good option, but those have NA support that 
>>> you may not need. Can you elaborate a little more on the use case? Is it a 
>>> fixed set of column names and types? Or will you need to support different 
>>> schemas?
>>> 
>>> 
>>> On Thu, Apr 17, 2014 at 5:16 PM, Stéphane Laurent  
>>> wrote:
>>> Hello,
>>> 
>>>  I need to deal with some objects represented as arrays whose some columns 
>>> are BigFloat, some columns are Int, some columns are logical. Is it a good 
>>> idea to use a DataFrame ? Is there a better solution ?This is for a 
>>> computationally intensive program.
>>> 
>> 
> 

[julia-users] Re: Bokeh Binding for Julia

[Tony Kelman]

Bokeh looks very nice indeed! I would absolutely use this, if I didn't have 
to go through Python.

Re: [julia-users] Re: Bokeh Binding for Julia

[Stefan Karpinski]

Being able to use Bokeh easily from Julia would be great – definitely
something of interest.


On Thu, Apr 17, 2014 at 6:44 PM, Tony Kelman  wrote:

> Bokeh looks very nice indeed! I would absolutely use this, if I didn't
> have to go through Python.
>
>

[julia-users] Re: open a file and writing lines to it

[gdeloscampos]

Thanks a lot, this was very helpful!

Gustavo

On Wednesday, April 16, 2014 1:49:53 AM UTC-5, harven wrote:
>
>
>
> Le mercredi 16 avril 2014 05:49:44 UTC+2, gdeloscampos a écrit :
>>
>> Hello, I am wondering if anyone can point me to documentation about 
>> opening, reading and writing to  connections?
>>
>  
> IO = open("temp", "a")  # a stands for append
>  write(IO, "string1\n")
>  write(IO, "string2\n")
>  close(IO)
>
> Another syntax that guarantees that the handle is closed even if something
> goes wrong during the writing phase.
>
> open("temp", "a") do IO
> write(IO, "string1\n")
> write(IO, "string2\n")
>   end
>

[julia-users] CUDA with Windows

[Laszlo Hars]

I added the package CUDA, but obviously it needs some tweaking for Windows 
(e.g. after installing CUDA 6.0 for Win7-64 there is no libcuda, which I 
was supposed to add to the library loading path). Can anyone help me with a 
list of things I need to do in Windows to get the Julia CUDA package 
working? -thx

[julia-users] Macros inside functions

[Ben Ward]

Hi Is it possible to use macros inside o functions in Julia if they are 
expanded at compile time as the manual says? I've been playing with a toy 
type:

type MeltingTemperature
  value::Int
end




myvar = MeltingTemperature(56)


and say I want to make a function that write it out as an XML string: 
"56

Now I want to make a function that constructs that string by 1). Adding the 
open tag 2). Checking the temperature is not nothing and if it is not, 
including it in the string. 3). add the closing tag.

I figured step 2 would be a good candidate for a macro for a larger type as 
checking each value is not nothing would be tedious. So:

macro INN(string, value)
  value != nothing ? "$string$value" : "$string"
end


function writePhyXML(x::MeltingTemperature)
  outstring = ""
  outstring = @INN outstring x.value;
  outstring = "$(outstring)"
  outstring
end


I figured the macro would be expanded and the function definition would 
become:

function writePhyXML(x::MeltingTemperature)
  outstring = ""
  outstring = x.value != nothing ? "$outstring$x.value" : "$outstring"
  outstring = "$(outstring)"
  outstring
end


But results in "outstringx.value"

Is it possible to do this with macro's? I had presumed it is.

(I know it's possible by just using a sub function, but I wanted to see how 
to try and use macros to generate code for function definitions if 
possible.)

Thanks,
Ben.

Re: [julia-users] Macros inside functions

[Jameson Nash]

disclaimer: I would use a function, not a macro for this purpose:
INN( outstring, value ) = value !== nothing ? "$outstring$value" : outstring
INN(outstring, x.value)

it is simpler, and gives up nothing in exchange for actually being
readable and versatile

but assuming you had a more interesting use case: when you expand the
macro as written, the result is:
"$string$value", with string=:outstring and value=:(x.value), exactly
as you specified: "outstringx.value"

but you want the string before interpolation (note that I'm switching
to the functional form of string interpolation because it is easier to
read in macro form), so we need this complicated thing to make a macro
that is actually just a function:
macro INN(str, val)
  :( v = $(esc(val)); s = $(esc(str)); v != nothing ? string(v, s) : s )
end

but the better way to write that is:
INN( outstring, value ) = value !== nothing ? "$outstring$value" : outstring
macro INN(str, val)
  :( INN($(esc(str)), $(esc(val))) )
end

why is this better? it's easier to read, write, and debug (also,
because it makes it obvious that you should not be using a macro for
this)

finally, there's the even cleaner options:
  outstring = "$(x.value!==nothing?x.value:"")"

or, using multiple dispatch -- my favorite option (excellent API for
future extensibility):
  mystr(::Nothing) = ""
  mystr(x) = x
  outstring = "$(mystr(x))"

note that since in your type, you have value::Int, so value will
always be an Int, never another type (like nothing), so it's a
pointless test

final note, string concatenation using $ or * or string (all of which
are exactly equivalent) is going to be slow compared to making an
IOBuffer, printing / writing / or showing all of your text to the
buffer, then calling takebuf_string(iobuf) at then end

On Thu, Apr 17, 2014 at 11:38 PM, Ben Ward  wrote:
> Hi Is it possible to use macros inside o functions in Julia if they are
> expanded at compile time as the manual says? I've been playing with a toy
> type:
>
> type MeltingTemperature
>   value::Int
> end
>
>
>
>
> myvar = MeltingTemperature(56)
>
>
> and say I want to make a function that write it out as an XML string:
> "56
>
> Now I want to make a function that constructs that string by 1). Adding the
> open tag 2). Checking the temperature is not nothing and if it is not,
> including it in the string. 3). add the closing tag.
>
> I figured step 2 would be a good candidate for a macro for a larger type as
> checking each value is not nothing would be tedious. So:
>
> macro INN(string, value)
>   value != nothing ? "$string$value" : "$string"
> end
>
>
> function writePhyXML(x::MeltingTemperature)
>   outstring = ""
>   outstring = @INN outstring x.value;
>   outstring = "$(outstring)"
>   outstring
> end
>
>
> I figured the macro would be expanded and the function definition would
> become:
>
> function writePhyXML(x::MeltingTemperature)
>   outstring = ""
>   outstring = x.value != nothing ? "$outstring$x.value" : "$outstring"
>   outstring = "$(outstring)"
>   outstring
> end
>
>
> But results in "outstringx.value"
>
> Is it possible to do this with macro's? I had presumed it is.
>
> (I know it's possible by just using a sub function, but I wanted to see how
> to try and use macros to generate code for function definitions if
> possible.)
>
> Thanks,
> Ben.

Re: [julia-users] array with different column types

[Stéphane Laurent]

Ah ok I see now. But it's not cool because I can't extract a column. For 
example

 df = DataFrame(A = Line[Line(1.0, 1), Line(2.0, 2)])


I'd like to extract the "column" [1.0, 2.0].

I don't know what is immutable, I will see if I find. Thank you for your 
help.


Le vendredi 18 avril 2014 00:34:57 UTC+2, John Myles White a écrit :
>
> df[:A] gives you a column, which is vector of Line objects.
>
> df[:A][1] gives you the first entry of that vector.
>
> df[:A][1].a gives you the a element of the first entry of that vector.
>
> I think you're better off just using a raw vector of immutables. Instead 
> of defining type Line, define immutable Line.
>
>  -- John
>
> On Apr 17, 2014, at 3:33 PM, Stéphane Laurent 
> > 
> wrote:
>
> How do I extract a line and a column with this method ?
>
>
>
> Le vendredi 18 avril 2014 00:21:26 UTC+2, John Myles White a écrit :
>>
>> Each row of a DataFrame is itself a DataFrame.
>>
>> Why not just store things in a vector of Line objects?
>>
>> type Line{T}
>> a::T
>> pair::Int
>> end
>>
>> df = DataFrame(A = Line[Line(1.0, 1), Line(2.0, 2)])
>>
>> I've changed things from your code because there's a convention of using 
>> uppercase letters to start the names of types.
>>
>>  -- John
>>
>> On Apr 17, 2014, at 3:18 PM, Stéphane Laurent  wrote:
>>
>> Thank you. I need to extract the lines too. A line looks like
>>
>>  type line{T}
>>
>>  a::T
>>
>>  pair:Int
>>
>>  end
>>
>>
>> This doesn't work, do you have something to propose :
>>
>> D = DataFrame(A = [1.,2.], B = [1,2])
>>
>> D[1,:]::line{Float64}
>>
>>
>> ?
>>
>> Le jeudi 17 avril 2014 23:48:29 UTC+2, Simon Kornblith a écrit :
>>>
>>> The most performant approach would be to store the columns as vectors in 
>>> a tuple or immutable. DataFrames can be nearly as performant if you:
>>>
>>> - Extract columns (df[:mycol]) and index into them whenever possible 
>>> instead of indexing individual elements (df[1, :mycol])
>>> - Add typeasserts when you perform indexing operations 
>>> (df[:mycol]::Vector{Int}), or pass the columns to another function
>>>
>>> Otherwise you will incur a slowdown because the compiler doesn't know 
>>> the types.
>>>
>>> Simon
>>>
>>> On Thursday, April 17, 2014 5:34:24 PM UTC-4, John Myles White wrote:

 It's actually possible to place pure Julia vectors in a DataFrame, 
 which might be convenient in this case. But you could always just store 
 the 
 columns in a Vector{Any}, which is what the DataFrame does behind the 
 scenes anyway.

  -- John

 On Apr 17, 2014, at 2:27 PM, Stefan Karpinski  
 wrote:

 A DataFrame does seem like a good option, but those have NA support 
 that you may not need. Can you elaborate a little more on the use case? Is 
 it a fixed set of column names and types? Or will you need to support 
 different schemas?


 On Thu, Apr 17, 2014 at 5:16 PM, Stéphane Laurent 
 wrote:

> Hello,
>
>  I need to deal with some objects represented as arrays whose some 
> columns are BigFloat, some columns are Int, some columns are logical. Is 
> it 
> a good idea to use a DataFrame ? Is there a better solution ?This is for 
> a 
> computationally intensive program.
>



>>
>