[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-14 Thread Steven G. Johnson
On Wednesday, September 14, 2016 at 7:12:31 AM UTC-4, Neal Becker wrote: > > I'd expect it to be called with a large array as input, so hopefully it's > performant enough as is, leaving the type of the argument determined at > runtime: My issue is more with how it is used. The whole

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-14 Thread Neal Becker
Steven G. Johnson wrote: ... > > Note that you have the same problem in several places, e.g. in > Constellation.jl. > > (I don't really understand what that file is doing, but it seems to be > constructing lots of little arrays that would be better of constructed > implicitly as part of other

Re: [julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-13 Thread Stefan Karpinski
On Tue, Sep 13, 2016 at 1:23 PM, Neal Becker wrote: > > Thanks for the ideas. Here, though, the generated values need to be > Uniform([0...2^N]), where N could be any number. For example [0...2^3]. > So the output array itself would be Array{Int64} for example, but the >

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-13 Thread Chris Rackauckas
A range is a type that essentially acts as an array, but really is only three numbers: start, end, and the step length. I.e. a=0:2^N would make a range where a[1]=0, a[i]==i-1, and a[end]=2^N. I haven't looked at the whole code, but if you're using rand([0...2^N]), then each time you do that

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-13 Thread Neal Becker
I'm not following you here. IIUC a range is a single scalar value? Are you suggesting I want an Array{range}? Chris Rackauckas wrote: > Do you need to use an array? That sounds better suited for a range. > > On Tuesday, September 13, 2016 at 10:24:15 AM UTC-7, Neal Becker wrote: >> >> Steven

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-13 Thread Chris Rackauckas
Do you need to use an array? That sounds better suited for a range. On Tuesday, September 13, 2016 at 10:24:15 AM UTC-7, Neal Becker wrote: > > Steven G. Johnson wrote: > > > > > > > > > On Monday, September 12, 2016 at 7:32:48 AM UTC-4, Neal Becker wrote: > >> > >> PnSeq.jl calls rand() to

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-13 Thread Neal Becker
Steven G. Johnson wrote: > > > > On Monday, September 12, 2016 at 7:32:48 AM UTC-4, Neal Becker wrote: >> >> PnSeq.jl calls rand() to get a Int64, caching the result and then >> providing >> N bits at a time to fill an Array. It's supposed to be a fast way to get >> an >> Array of small-width

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-13 Thread Steven G. Johnson
On Monday, September 12, 2016 at 8:16:52 AM UTC-4, Steven G. Johnson wrote: > > > > On Monday, September 12, 2016 at 7:59:33 AM UTC-4, DNF wrote: >> >> function(p::pnseq)(n,T=Int64) >> >>> > Note that the real problem with this function declaration is that the type > T is known only at runtime,

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-13 Thread Steven G. Johnson
On Monday, September 12, 2016 at 7:32:48 AM UTC-4, Neal Becker wrote: > > PnSeq.jl calls rand() to get a Int64, caching the result and then > providing > N bits at a time to fill an Array. It's supposed to be a fast way to get > an > Array of small-width random integers. > rand(T, n)

Re: [julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-13 Thread Páll Haraldsson
On Monday, September 12, 2016 at 7:01:05 PM UTC, Yichao Yu wrote: > > On Sep 12, 2016 2:52 PM, "Páll Haraldsson" > wrote: > > > > On Monday, September 12, 2016 at 11:32:48 AM UTC, Neal Becker wrote: > >> > >> Anyone care to make suggestions on this code, how to make it

Re: [julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread Yichao Yu
On Sep 12, 2016 2:52 PM, "Páll Haraldsson" wrote: > > On Monday, September 12, 2016 at 11:32:48 AM UTC, Neal Becker wrote: >> >> Anyone care to make suggestions on this code, how to make it faster, or more >> idiomatic Julia? > > > > It may not matter, but this

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread Páll Haraldsson
On Monday, September 12, 2016 at 11:32:48 AM UTC, Neal Becker wrote: > Anyone care to make suggestions on this code, how to make it faster, or > more > idiomatic Julia? > It may not matter, but this function: function coef_from_func(func, delta, size) center = float(size-1)/2 return

Re: [julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread Stefan Karpinski
All of the globals setup in bench1 are non-const, which means the top-level benchmarking code is pretty slow, but if N is small, this won't matter much. If N is large, it's worth either wrapping the setup in a function body or making all these variables const. On Mon, Sep 12, 2016 at 8:37 AM,

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread Neal Becker
Steven G. Johnson wrote: > > > > On Monday, September 12, 2016 at 7:59:33 AM UTC-4, DNF wrote: >> >> function(p::pnseq)(n,T=Int64) >> >>> > Note that the real problem with this function declaration is that the type > T is known only at runtime, not at compile-time. It would be better to >

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread DNF
The code is not particularly long, but it seems like almost every type has its own module, which makes it harder to get an overview. A few of the composite types are defined with abstract types as fields, such as FNNyquistPulse. That is not optimal:

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread Steven G. Johnson
On Monday, September 12, 2016 at 7:59:33 AM UTC-4, DNF wrote: > > function(p::pnseq)(n,T=Int64) > >> Note that the real problem with this function declaration is that the type T is known only at runtime, not at compile-time. It would be better to do function (p::pnseq){T}(n,

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread Neal Becker
Patrick Kofod Mogensen wrote: > This surprised me as well, where did you find this syntax? > > On Monday, September 12, 2016 at 1:59:33 PM UTC+2, DNF wrote: >> >> I haven't looked very closely at your code, but a brief look reveals that >> you are defining your functions in a very unusual way.

Re: [julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread Steven G. Johnson
On Monday, September 12, 2016 at 8:07:55 AM UTC-4, Yichao Yu wrote: > > > > On Mon, Sep 12, 2016 at 8:03 AM, Patrick Kofod Mogensen < > patrick@gmail.com > wrote: > >> This surprised me as well, where did you find this syntax? >> > > Call overload. > (i.e. it's the new syntax for call

Re: [julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread Yichao Yu
On Mon, Sep 12, 2016 at 8:03 AM, Patrick Kofod Mogensen < patrick.mogen...@gmail.com> wrote: > This surprised me as well, where did you find this syntax? > Call overload. > > > On Monday, September 12, 2016 at 1:59:33 PM UTC+2, DNF wrote: >> >> I haven't looked very closely at your code, but a

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread Patrick Kofod Mogensen
This surprised me as well, where did you find this syntax? On Monday, September 12, 2016 at 1:59:33 PM UTC+2, DNF wrote: > > I haven't looked very closely at your code, but a brief look reveals that > you are defining your functions in a very unusual way. Two examples: > > function

[julia-users] Re: 1st try julia, 2/3 speed of python/c++

2016-09-12 Thread DNF
I haven't looked very closely at your code, but a brief look reveals that you are defining your functions in a very unusual way. Two examples: function (f::FIRFilter)(x) return filt(f, x) end function(p::pnseq)(n,T=Int64) out = Array{T}(n) for i in eachindex(out) if p.count