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
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
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
>
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
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
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
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
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,
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)
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
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
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
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,
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
>
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:
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,
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.
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
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
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
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
21 matches
Mail list logo