Re: [julia-users] Re: Comprehension (generator) with statement IF and the number of true

All higher-order functions? I thought it was mainly anonymous functions. Either way, that's a seriously big slowdown. On Thursday, October 27, 2016 at 4:55:40 PM UTC+2, Steven G. Johnson wrote: > > > > On Wednesday, October 26, 2016 at 3:29:39 PM UTC-4, DNF wrote: >> >&

Re: [julia-users] Re: Comprehension (generator) with statement IF and the number of true

vy Matlab use. Cryptic one-liners and contorted vectorizations are second nature to me. Quite often, reduce and generators make things easier and clearer, but not this time, even for me. On Wednesday, October 26, 2016 at 4:55:45 PM UTC+2, Gregory Salvan wrote: > > 2016-10-26 13:09 GM

Re: [julia-users] Re: Comprehension (generator) with statement IF and the number of true

I don't have the impression that reduce is slow. The reduce function that you're using is complicated and may have features that preclude optimizations, such as vectorization. But perhaps more importantly, the reduce version, while probably very clever, is almost completely impossible to

[julia-users] Re: Comprehension (generator) with statement IF and the number of true

Could you explain why you are unhappy with v1? It seems like a near-optimal implementation to me. It is idiomatic Julia, clean, clear, and fast. Are you certain that you're not looking for a one-liner out of force of habit? On Tuesday, October 25, 2016 at 9:15:54 AM UTC+2, Martin Florek wrote:

[julia-users] Re: Merge functions from different headers (Matrix vs. Vector)

On Friday, October 14, 2016 at 3:16:31 PM UTC+2, Martin Florek wrote: > > Thank you very much. This is very elegant way, I think that it solve my > problem. > You're welcome. If you are looking to improve performance further, you could add @inbounds and @simd macro calls, as seen here:

[julia-users] Re: Merge functions from different headers (Matrix vs. Vector)

As a proposal, this is what I would do, given you requirements: function _scaleRestore!(Z, Zout, shift, stretch) for j in 1:size(Z, 2), i in 1:size(Z, 1) Zout[i, j] = Z[i, j] * stretch[j] + shift[j] end return Zout end scaleRestore!(Z::Vector, shift::Number, stretch::Number) =

[julia-users] Re: Merge functions from different headers (Matrix vs. Vector)

, October 14, 2016 at 10:35:56 AM UTC+2, Martin Florek wrote: > > Thanks DNF, > but I want to just merge version 1 and 2 with limited to one vector - two > scalars OR one matrix - two vectors into a single definition. On the > function f_scaleRestore does not matter, can have dif

[julia-users] Re: Merge functions from different headers (Matrix vs. Vector)

others. Unless you have some particular reason to constrain the inputs in some way, I wouldn't add all the type declarations, but just leave the function generic. On Friday, October 14, 2016 at 9:55:21 AM UTC+2, DNF wrote: > > This should work for the three cases you have

[julia-users] Re: Merge functions from different headers (Matrix vs. Vector)

This should work for the three cases you have set up: f_scaleRestore(a, b, c) = a .* b' .+ c' On Friday, October 14, 2016 at 9:12:55 AM UTC+2, Martin Florek wrote: > > Hi all, > > I have the following two functions and I want to sensibly merge them into > one. How to marge headers and body of

[julia-users] Re: I have two data collection for mapreduce() vs. generator, which is correct/better implementation? (Julia 0.5)

e same order when SIMD is used. > Floating point addition is not commutative so you get slightly different > answers. > > On Thursday, October 13, 2016 at 9:14:31 AM UTC+2, DNF wrote: >> >> This is about twice as fast with, with @simd: >> >> function f2(a, p) >

[julia-users] Re: I have two data collection for mapreduce() vs. generator, which is correct/better implementation? (Julia 0.5)

This is about twice as fast with, with @simd: function f2(a, p) @assert length(a) == length(p) s = 0.0 @simd for i in eachindex(a) @inbounds s += abs((a[i] - p[i])/a[i]) end return 100s/length(a) end julia> @benchmark f(a, p) BenchmarkTools.Trial: samples:

[julia-users] Error printing for too many ouputs

I recently spent an unreasonable amount of time figuring out what my error was in a function analogous to the following: too_many_outputs() = rand(100, 100), zeros(100, 100) a, b, c = too_many_outputs() The output from this is, on 0.5.0, several screenfuls of red numerical data, and an error

Re: [julia-users] 'translate' not defined

Thanks. The response in JunoLab is slightly different, an UndefVarError. Is this the same thing? On Monday, September 26, 2016 at 10:14:44 PM UTC+2, Yichao Yu wrote: > > https://github.com/JuliaLang/julia/issues/14787 > > On Mon, Sep 26, 2016 at 4:00 PM, DNF <oyv...@gmail.com >

[julia-users] 'translate' not defined

I am seeing an odd warning/error during tab-completion: In the Julia REPL, whenever I am using tab-completion I get the following warning: WARNING: both JLD and Plots export "translate"; uses of it in module Main must be qualified Is tab-completions somehow trying to call this function? The

Re: [julia-users] Re: equivalent of numpy newaxis?

e operators do not do the fusing yet, check right at the bottom of the > linked manual section. I think you can work around it by using their > functional form: > > x .+ y # not fused > (+).(x,y) # fused > > So: > > out .= abs2.((-).(x, y.')) > > > DNF wr

[julia-users] Re: equivalent of numpy newaxis?

For your particular example, it looks like what you want is (and I am just guessing what mag_sqr means): dist = abs2.(x .- y.') The performance should be the similar to a hand-written loop on version 0.5. You can read about it here:

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

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++

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

[julia-users] Re: Problem with Plots/Compat on RC4

Thanks. After deleting .julia/lib and restarting julia I get some warnings before the prompt shows up: WARNING: Method definition cgrad(Any, Any) in module PlotUtils at ~/.julia/ PlotUtils/src/color_gradients.jl:82 overwritten at ~/.julia/PlotUtils/src/ color_gradients.jl:99. WARNING: Method

[julia-users] Problem with Plots/Compat on RC4

After updating to RC4 (binary download) plotting completely stopped working for me. julia> plot(rand(5)) [Plots.jl] Initializing backend: gr INFO: Precompiling module GR. WARNING: Module Compat with uuid 169833921923513 is missing from the cache. This may mean module Compat does not support

Re: [julia-users] slow for loops because of comparisons

ocations: 1.922 KB) julia> @time essai(200,a,d); 9.199016 seconds (5 allocations: 1.922 KB) So I concede it's not such a big part after all. On Friday, September 9, 2016 at 1:04:32 AM UTC+2, DNF wrote: > > But if branch prediction doesn't factor in, what is the explanation of >

Re: [julia-users] slow for loops because of comparisons

But if branch prediction doesn't factor in, what is the explanation of this: *julia> *a *=* *rand*(5000); *julia> *b *=* *rand*(5000); *julia> *c *=* *rand*(5000) *+* 0.5; *julia> *d *=* *rand*(5000) *+* 1; *julia> **@time* *essai*(200,a,b); 14.607105 seconds (5 allocations: 1.922 KB)

Re: [julia-users] slow for loops because of comparisons

, DNF wrote: > > If you change your test to > > a = rand(1,5000) > b = rand(1,5000) + 1 > > you will see significant speedup of you original code. This is a branch > prediction problem, isn't it? You are branching on the comparison of two > random vectors, that is th

Re: [julia-users] slow for loops because of comparisons

If you change your test to a = rand(1,5000) b = rand(1,5000) + 1 you will see significant speedup of you original code. This is a branch prediction problem, isn't it? You are branching on the comparison of two random vectors, that is the hardest thing you can ask for. Prediction will be

[julia-users] Re: Hard time with Compat and 0.5

In the first one you are passing in [X.name...] while in the other one you are passing in X.name. Could you not just write: name = String([X.name...]) On Saturday, August 27, 2016 at 3:29:32 AM UTC+2, J Luis wrote: > > Ok, I figured that one (Really needed a first argument 'Array') > > But

[julia-users] Re: How to build a range of -Inf to Inf

Your in-method is a bit odd: Base.in{T}(x::T, r::BasicInterval{T}) = (r.start <= x <= r.stop) ? true : false Why don't you just write Base.in{T}(x::T, r::BasicInterval{T}) = (r.start <= x <= r.stop) ? The extra stuff is redundant.

[julia-users] Re: Is Julia slow with large arrays?

Out of curiosity: My understanding has been that type instabilities are related to the compiler not being able to predict the types of variables based on input types, not variables simply (and predictably) changing types during program execution. Should the compiler ideally be able to catch

Re: [julia-users] julia equivalent of python [] (aka list)

On Wednesday, May 25, 2016 at 11:50:43 AM UTC+2, DNF wrote: > > > This works, however, even though Vector is not a subtype of Vector{Any}: > >> goodbye(v::Vector) = println("bye, bye") > goodbye (generic function with 1 method) > >> goodbye([2,'a']) >

Re: [julia-users] julia equivalent of python [] (aka list)

I was pointing out that Vector{Any} is not a drop-in replacement for Python list, especially for type annotations. > You're hitting type invariance. See > > http://docs.julialang.org/en/latest/manual/types/#parametric-composite-types > and look for this term in the mailing list archives. >

Re: [julia-users] julia equivalent of python [] (aka list)

Is ::Array{Any, 1} the correct annotation? >> hello(v::Vector{Any}) = println("Hello") >> hello([2,'a']) Hello >> hello([2,2]) ERROR: MethodError: no method matching hello(::Array{Int64,1}) in eval(::Module, ::Any) at /usr/local/Cellar/julia/HEAD/lib/julia/sys. dylib:-1 It only works for

[julia-users] Re: Splatting speed

On version 0.5, after warm-up. (Notice that I use collect() instead of [], since the latter doesn't work like that anymore) function test_broad(N) @time for _ in 1:N broadcast( (x...) -> +(x...), collect(1:1000), collect(1001:2000) ) end @time for _ in 1:N broadcast( (x...) -> +(x...),

[julia-users] Re: Why does julia use END for block end?

I find 'end' to be the best choice of block terminator among the ones I have seen. It is very clear and explicit, there is no doubt as to what it means, unlike '}' which is way too small and ambiguous (does it mean end of block, or end of dict definition, etc.), and just does not jump out at

[julia-users] Re: Trouble with parametric parts of a type def

I was going to suggest: type MyType{A<:AbstractArray, T<:Unsigned} data::A{T} end which does not work. The error is: *ERROR: TypeError: Type{...} expression: expected Type{T}, got TypeVar* Does anyone know whether this should work in an ideal world, or does the type definition simply

Re: [julia-users] Re: [ANN] CmplxRoots.jl: Fast Complex Polynomial Root Finder

There is a reason, then ;) But I see you have already changed the name from cmplx_roots to CmplxRoots.jl to keep up with Julia naming conventions, so going all the way would be even better! Who knows what odd reasons or compromises may be behind the original name. Just to refer to the Julia

[julia-users] Re: [ANN] CmplxRoots.jl: Fast Complex Polynomial Root Finder

Just a question: Is there some particular reason you chose to to skip the letters 'o' and 'e' in the name? It seems like the kind of thing that would make the package hard to find, and cause confusion and frustration. In fact, while I immediately saw that you skipped the 'e', it read it many

Re: [julia-users] Re: is accessing tuple elements more efficient than accessing elements of a 1d array?

On Tuesday, April 12, 2016 at 3:50:13 PM UTC+2, Yichao Yu wrote: > > > NTuple is just a constructor for tuple so there's no difference. > Ah. OK, thanks. It's a bit clearer now.

Re: [julia-users] Re: is accessing tuple elements more efficient than accessing elements of a 1d array?

Apr 12, 2016 at 5:43 AM, DNF <oyv...@gmail.com > > wrote: > > Wow! That is a huge difference. > > > > I suspected that my benchmark was flawed, but I don't understand in what > > way, since is doesn't seem like anything is being inappropriately > optimized

[julia-users] Re: is accessing tuple elements more efficient than accessing elements of a 1d array?

Wow! That is a huge difference. I suspected that my benchmark was flawed, but I don't understand in what way, since is doesn't seem like anything is being inappropriately optimized away. Quite the contrary, my benchmark is running slowly with lots of allocations. The question remains, though,

Re: [julia-users] is accessing tuple elements more efficient than accessing elements of a 1d array?

But what if you do have a very small number of elements? Let's say I am working with 2D or 3D points and wonder whether to represent them as vectors, tuples or a custom type, like immutable Point2D{T<:Real} x::T y::T end Base.(:+){T}(p1::Point2D{T}, p2::Point2D{T}) = Point2D(p1.x+p2.x,

[julia-users] Re: Find the indice of the element with the nearest value of a float in an array

, and then see if it works the way you intend it to. On Monday, April 11, 2016 at 12:15:31 PM UTC+2, Fred wrote: > > Thank you for this explanation DNF ! It is the first time I use collect and > the reason why I used it was an error message suggesting that I should use > it :) maybe b

[julia-users] Re: Find the indice of the element with the nearest value of a float in an array

I messed up copy-paste here: >> test_dist(1:0.1:10, 8.22, 1) > 0.641741 seconds (1.82 M allocations: 749.817 MB, 7.57% gc time) > 0.007380 seconds > 0.005570 seconds > > It should be (looping 1 times) >> test_dist(1:0.1:10, 8.22, 10^4) 0.641741 seconds (1.82 M allocations: 749.817 MB, 7.57%

[julia-users] Re: Find the indice of the element with the nearest value of a float in an array

The big error you made originally is calling collect in every iteration of the loop. Just deleting collect speeds things up by 100x. The lesson is that you should (almost) never use collect. The other lesson is: don't do [1:0.1:10]. It makes your code slower, and very soon your it will stop

[julia-users] Re: Cross-correlation: rfft() VS fft() VS xcorr() performances

On Friday, April 8, 2016 at 1:31:54 PM UTC+2, DNF wrote: > > FFT is O(N*logN), while time domain is O(L*logN) where L is the number of > lags. > I meant, of course, that the time domain xcorr is O(L*N).

[julia-users] Re: Cross-correlation: rfft() VS fft() VS xcorr() performances

Hmm. Thinking a bit more about it, it might be hard to beat the FFT with when your signals are *that* long. FFT is O(N*logN), while time domain is O(L*logN) where L is the number of lags. log2(60*48000) is less than 22(!) so the FFT will be *very* beneficial. Here you can have a look at a

[julia-users] Re: Cross-correlation: rfft() VS fft() VS xcorr() performances

The xcorr function calls the conv function, which again uses fft. If you know the general structure and length of your signals ahead of time, you can probably gain some performance by planning the ffts beforehand. I don't know why it doesn't work for you, but you could have a look in at conv in

[julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

On Tuesday, April 5, 2016 at 3:36:09 PM UTC+2, Gabriel Gellner wrote: > > you can do the python example as: > > a[[1, 4] + range(7, 17, 2)] > (ignoring the issues that this is not the same range as julia since python > uses 0-based indices ...) > Thanks. I'm getting an error, though:

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

On Tuesday, April 5, 2016 at 2:47:15 PM UTC+2, Sisyphuss wrote: > > np.array([a[i] for i in [1,2,4] + list(range(7,17,2))]) > > This works, albeit awkward. Python was not originally designed for > mathematics. > Thanks :) But that this is also my point: I find it mind-boggling that someone

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

to the elegance of Julia. On Tuesday, April 5, 2016 at 10:32:40 AM UTC+2, Sisyphuss wrote: > > You can use list compression in python > > [a[i] for i in [1,2,4,7,9] ] > > On Apr 5, 2016 8:55 AM, "DNF" <> wrote: > > > > Typo, I meant to type: > &

[julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

far I've got: a[np.concatenate(([1,4], np.arange(7,17,2)))] On Tuesday, April 5, 2016 at 8:46:57 AM UTC+2, DNF wrote: > > > On Saturday, April 2, 2016 at 1:55:55 PM UTC+2, Spiritus Pap wrote: >> >> A simple example why it makes my *life hard*: Assume there is an array >&

[julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

On Saturday, April 2, 2016 at 1:55:55 PM UTC+2, Spiritus Pap wrote: > > A simple example why it makes my *life hard*: Assume there is an array of > size 100, and i want to take the i_th portion of it out of n. This is a > common scenario for research-code, at least for me and my friends. > In

[julia-users] Re: Is there going to be an abstract type/trait-ocalypse?

I guess maybe this question is difficult to answer with any confidence; I certainly have no particular insight. There have been previous discussions, but I don't know what the prevailing opinion is currently. I just wanted to bump it, and add that this is exactly the kind of topic I find

[julia-users] Re: good practice question: dispatch on type or on type instance

What is the purpose of the H type parameter here? You can just use > takedecision(::Type{Dice}) = println("throw a dice") > takedecision(Dice) throw a dice That would remove the objection of 'ugliness'. immutable Dice end > immutable Coin end > > takedecision{H <:

Re: [julia-users] What to read to understand finishing v0.5?

I had no idea. I guess it shows that unless one knows what to look for, it can be a bit hard to get an impression of the state of development in some cases. Anyway, to me this is wonderful news, and the single most exciting thing I've heard for a while (about Julia, that is :) On Thursday,

Re: [julia-users] Re: What to read to understand finishing v0.5?

On Thursday, March 10, 2016 at 7:00:46 AM UTC+1, Viral Shah wrote: > > This is about the right time to start the triage for the various 0.5 > issues. With all the amazing compiler improvements, LLVM upgrade, Cxx > readiness, thread-safety (will probably remain disabled for 0.5 potentially >

[julia-users] Re: ANN: A potential new Discourse-based Julia forum

So, what happened to this experiment? Has the move been abandoned, or just been put on ice? The Google forum looks pretty primitive, and especially reading code is a real pain. But is there just not a lot of enthusiasm for the new platform? On the surface it looks vastly superior, but I don't

Re: [julia-users] Re: ANN: A potential new Discourse-based Julia forum

for code. > > The problem with various forums is that each community has a different > one. I would prefer not to deal with N web interfaces, no matter how > nice and featureful, instead of my nicely customized inbox in Emacs. > > Best, > > Tamas > > On Tue, Jan 12 20

Re: [julia-users] Re: ANN: A potential new Discourse-based Julia forum

On Tuesday, January 12, 2016 at 11:32:21 AM UTC+1, Tamas Papp wrote: > > I don't see an alternative given my preferences --- as I said, I don't > want to deal with different web interfaces. Also, sometimes I work > offline. I see how that can work for you. But don't all such forums support

[julia-users] Re: python a[range(x), y] equivalent in Julia

You can write a[[1,2], [2,1]] in Julia, but it means something different from what it (apparently) means in numpy. The meaning in Julia is equivalent to the Matlab meaning. To achieve what you seem to want you can use sub2ind: *julia> **a[sub2ind(size(a), [1,2], [2,1])]* *2-element

[julia-users] Re: optimizing Julia code for numerical integration of PDE

Your last line is: u = real(ifft(u)) In that case you seem to be throwing away all the intermediate calculations. Should it be: u = real(ifft(uf)) ?

Re: [julia-users] Writing a function for two different types, avoiding code duplication

On Thursday, December 17, 2015 at 12:05:59 PM UTC+1, ami...@gmail.com wrote: > > I should mention, however, that the exact solution I needed was: > myf{T1,T2}(x::Union{T1,T2}). > What was wrong with myf(x::Union{T1,T2})? Looks right to me. Why do you need to parameterize?

[julia-users] Re: Easiest way to get indexes of elements that satisfy a certain condition

In Matlab, the preferred way of doing this is: find(s < x) In Julia, it's almost exactly the same: find(s .< x) If you don't need the indices, only the elements, you would do: s[s .< x] which, again, is almost identical to Matlab. The reason you are getting a matrix output is that [1 2 5

[julia-users] Re: Ray tracing for complex geometry

I can't really help you, but I think that http://www.cs.columbia.edu/~keenan/Projects/QuaternionJulia/ does not have anything to do with Julia the programming language, but is related to Julia sets . On Friday, November 20, 2015 at 4:18:46 PM UTC+1,

[julia-users] Re: indexing with non Integer Reals is deprecated

You can also do D[i+1-d>>1:j-3+q*5] which is actually slightly faster. It looks a bit obscure at first, but now I think of it as the 'halve stuff n times' operator, which is often the correct idiom. On Wednesday, November 18, 2015 at 10:08:08 AM UTC+1, Eric Forgy wrote: > > Hi Jon, > > Have

Re: [julia-users] Do I have simd?

On Monday, November 9, 2015 at 10:14:24 PM UTC+1, DNF wrote: > > Thanks a lot. That indeed works. > Oh, and by "that", I mean installing the Julia 0.4.1 app.

Re: [julia-users] Do I have simd?

Thanks a lot. That indeed works. The speedup is not particularly large, and varies quite a bit, from 1.5 to 3 times speedup. But it *is* working, and code_llvm reports a vector block. Though performance isn't all that impressive, at least I know there is nothing fundamentally stopping the SIMD

Re: [julia-users] Do I have simd?

OK, wow! I tried following the advice in https://github.com/staticfloat/homebrew-julia specifically, $ brew rm gcc openblas-julia suite-sparse-julia arpack-julia $ brew install gcc openblas-julia suite-sparse-julia arpack-julia Now, there is a difference: the non-SIMD version is *much slower*

Re: [julia-users] Do I have simd?

On Friday, November 6, 2015 at 12:20:38 PM UTC+1, Giuseppe Ragusa wrote: > > I am pretty sure must something specific to your installation. > Do you mean my Julia installation?

Re: [julia-users] Do I have simd?

Thanks for the feedback. It seems like this is not a problem for most. If anyone has even the faintest clue where I could start looking for a solution to this, I would be grateful. Perhaps there is some software I could run that would detect hardware problems, or maybe I am missing software

Re: [julia-users] Re: a=[1:1:10] WARNING ? What to creat vectors in 4.0 ?

Did you try my suggestion? Just use a = 1:10 Doesn't it work the way you want?

Re: [julia-users] Do I have simd?

On Thursday, November 5, 2015 at 4:07:05 PM UTC+1, Yichao Yu wrote: > > You can check with `code_llvm(innersimd, > Tuple{Vector{Float32},Vector{Float32}})` > I tried it, and got this output, but don't know how to make sense of it *julia> **code_llvm(innersimd,

Re: [julia-users] Do I have simd?

I install using homebrew from here: https://github.com/staticfloat/homebrew-julia I have limited understanding of the process, but believe there is some compilation involved.

Re: [julia-users] Do I have simd?

I see. Do you know if I need to install something to get SIMD support? According to this review of my computer model: "Haswell chips also include new instructions enhancing SIMD vector

[julia-users] Do I have simd?

I have been looking through the performance tips section of the manual. Specifically, I am curious about @simd (http://docs.julialang.org/en/release-0.4/manual/performance-tips/#performance-annotations). When I cut and paste the code demonstrating the @simd macro, I don't get substantial

Re: [julia-users] a=[1:1:10] WARNING ? What to creat vectors in 4.0 ?

A vector is a 1-dimensional array, so *Array{element_type,1} *means *Vector{element_type}.* But I would like to suggest that you should *not* collect into an array. Just use a = 1:10 and use that directly. 1:10 is a Range which again is an *AbstractVector. *Just try if you can use that, and

[julia-users] Re: Automatic conversion from 1x1 matrix/array/vector to a real/float num.

In this particular example, why not use rand() instead of rand(1,1) ? On Saturday, October 31, 2015 at 5:33:05 PM UTC+1, Xiaowei Song wrote: > > v=zeros(2,3) > x=rand(1,1) > v[2,1]=x > # `convert` has no method matching convert(::Type{Float64}, > ::Array{Float64, 2}) > > #work around >

[julia-users] Re: Order of multiple for-loops

To me it makes sense to think of the loops as 'inner' and 'outer'. So here: for i2=1:n, i1=1:m A[ i1, i2 ] = 10 * i1 + i2 end i1 is the 'inner' loop variable. And here: A = [ 10 * i1 + i2 for i2=1:n, i1=1:m ] i1 is the 'outer' loop variable. Makes things quite easy to think

Re: [julia-users] Re: For loop = or in?

On Wednesday, October 28, 2015 at 9:51:10 AM UTC+1, Tamas Papp wrote: > > I am probably old-fashined, but I always prefer to stick to ASCII unless > there is a compelling reason. If I want something to stick out, I can > always customize Emacs to do it. > Well, both 'in' and '=' are ASCII,

[julia-users] Re: For loop = or in?

You are right, of course. It's just one of those minor cosmetic things you fix in a pre-1.0 version, or then maybe never. And it's good not to have too many of those. Also for i ∈ 1:N just looks incredibly awesome. On Wednesday, October 28, 2015 at 1:38:57 PM UTC+1, STAR0SS wrote: > > I

Re: [julia-users] Re: For loop = or in?

On Wednesday, October 28, 2015 at 2:29:54 PM UTC+1, Stefan Karpinski wrote: > > I think we're getting into Parkinson's law territory here. First off, I > don't think this causes all that much confusion. Second, since this is pure > syntax involving a keyword no less, this is one of the easiest

Re: [julia-users] Re: For loop = or in?

On Wednesday, October 28, 2015 at 10:22:45 AM UTC+1, Glen O wrote: > > The thing is, it IS an assignment that's going on. In the case of a range, > especially, "for i=1:5" says "loop 5 times, with i=1, then i=2, then i=3, > then i=4, then i=5". "i' is being assigned to on each iteration. Think

Re: [julia-users] Re: For loop = or in?

On Wednesday, October 28, 2015 at 8:56:44 AM UTC+1, DNF wrote: > > I don't think = and in represent an elegant duality. They seem a very odd > couple to me (even though I have been using = in Matlab for 15 years.) On > the other hand, = and ∈ do seem to offer an elegant duali

Re: [julia-users] Re: For loop = or in?

On Wednesday, October 28, 2015 at 7:56:54 AM UTC+1, Gabor wrote: > > Confusion? > Considering the investment into learning all the new and powerful Julia > language constructs, > I don't see why exactly this elegant duality would be a problem for anyone. > I don't think = and in represent an

Re: [julia-users] A question of Style: Iterators into regular Arrays

I think that the point of the idea was to get rid of the Abstract prefix. It can be a bit confusing that some, but not all, abstract types have the Abstract prefix, and as seen in this thread it has led to some misunderstandings. On Tuesday, October 27, 2015 at 8:29:21 AM UTC+1, Tomas Lycken

Re: [julia-users] Re: For loop = or in?

On Tuesday, October 27, 2015 at 4:56:12 PM UTC+1, Glen O wrote: > > Incidentally, it would be nice if ∈ could be used as another option - it's > just another way of saying "in", but it would look nicer in certain > mathematical contexts, and it's not like the symbol would be used in > another

Re: [julia-users] functions on iterable types

Hmm. Trying to answer myself: I guess my suggested solution would miss functions that don't specify the type, but just rely on the iterable behaviour. On Monday, October 26, 2015 at 6:53:03 AM UTC+1, DNF wrote: > > I may be missing something, but what about using the TypeTrees

Re: [julia-users] functions on iterable types

I must admit I don't understand very well what snippet is supposed to do. But, for example, it doesn't work for :sum or :maximum or anything like that. On Monday, October 26, 2015 at 9:23:35 AM UTC+1, harven wrote: > > > > Le lundi 26 octobre 2015 07:15:56 UTC+1, DNF a écrit : >&

[julia-users] Re: Please help me understand comprehensions for creating an array

I learn new great stuff all the time with this language: You should actually do p = fill(a/Nb, Nb) On Monday, October 26, 2015 at 12:59:03 PM UTC+1, DNF wrote: > > If you want constant values you should do > > p = zeros(Nb) + a/Nb > or > p = ones(Nb) * a/Nb >

[julia-users] Re: Please help me understand comprehensions for creating an array

If you want constant values you should do p = zeros(Nb) + a/Nb or p = ones(Nb) * a/Nb On Monday, October 26, 2015 at 11:35:06 AM UTC+1, Ferran Mazzanti wrote: > > Hi folks, > > I try to create an array of constant float64 values. Something I did was: > > a = 0.8; > Nb = 100; > p = zeros(Nb)

[julia-users] Re: Please help me understand comprehensions for creating an array

OK. The phrasing of the question indicated to me that you were trying to create an array of Float64 values, and that the comprehension was just the tool to accomplish that. In that case, Kristoffer Carlsson gave a good answer: p = Float64[ a/Nb for i in 1:Nb] On Monday, October 26, 2015 at

Re: [julia-users] functions on iterable types

I may be missing something, but what about using the TypeTrees module to obtain the typenames, and then using methodswith() to establish whether each type has the methods start, next and stop? It would be a bit slow, of course, but if you dig around in the source code of methodswith you could

[julia-users] Re: functions on iterable types

The function 'methodswith' is probably what you're looking for. On Sunday, October 25, 2015 at 9:49:45 PM UTC+1, harven wrote: > > An iterable type is obtained by defining start, next and end methods for > such a type. > Is there a way to obtain the list of all functions that work on iterable >

[julia-users] Re: map() vs broadcast()

I guess this is mostly about the behaviour of map!, but for avoiding allocations I think this makes more sense: function mape4b(A, F) tmp = zero(eltype(A)) N = length(A) for i in 1:N tmp += abs(_f(A[i], F[i])) end return 100 * tmp / N end For some reason, the time

[julia-users] Re: A question of Style: Iterators into regular Arrays

The general advice would be: don't make explicit arrays. Treat the ranges as arrays, and explicit arrays will be made for you automatically when you use them in expressions. In some cases you may have to use collect(), but that would be the exception rather than the rule, and would probably

[julia-users] Re: A question of Style: Iterators into regular Arrays

There is no need for doing collect or [ ;] most of the time. Whenever you use a range as input to a vectorized function, like sin, it returns a vector as expected. This code should do the same as the one you posted: function jakes_flat(fd, Ts, Ns, t0 = 0.0, E0 = 1.0, phi_N = 0.0) N0 = 8

[julia-users] Re: A question of Style: Iterators into regular Arrays

nspace to be the vector version. On Wednesday, October 21, 2015 at 7:03:05 PM UTC+2, DNF wrote: > > There is no need for doing collect or [ ;] most of the time. Whenever you > use a range as input to a vectorized function, like sin, it returns a > vector as expected. > > This

Re: [julia-users] A question of Style: Iterators into regular Arrays

21, 2015 at 10:03:27 PM UTC+2, DNF wrote: > > I was thinking specifically of AbstractString, not AbstractArray. I just > don't quite get why it had to be made consistent with Array/AbstractArray, > when String was a nice general name, and it would be consistent with the > IO/IOStrea

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

I actually tend to think that's a pretty strong reason. On Wednesday, October 21, 2015 at 10:07:23 PM UTC+2, Gabriel Gellner wrote: > > That doesn't feel like a reason that they can't be iterators, rather that > they might be slow ;) a la python. >

Re: [julia-users] A question of Style: Iterators into regular Arrays

I was thinking specifically of AbstractString, not AbstractArray. I just don't quite get why it had to be made consistent with Array/AbstractArray, when String was a nice general name, and it would be consistent with the IO/IOStream/IOBuffer example that you mention. On Wednesday, October 21,

[julia-users] Re: A question of Style: Iterators into regular Arrays

I see that we are thinking the same way here :) I understand that there has been a push toward renaming abstract types AbstractXXX. Unless all abstract types are going to get the 'Abstract' prefix, I don't quite understand this. On Wednesday, October 21, 2015 at 9:19:30 PM UTC+2, Gabriel

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

The reason why not all arrays can be iterators is that in general arrays can not be 'compressed' like that. A linear range can be compressed to: a start value, an increment, and a length, making it incredibly lightweight. Doing this for sin() is not that easy. Doing it for rand() is simply

  1   2   >