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

I find the way that you need to use `linspace` and `range` objects a bit jarring for when you want to write vectorized code, or when I want to pass an array to a function that requires an Array. I get how nice the iterators are when writing loops and that you can use `collect(iter)` to get a a

[julia-users] simple parallel assembly example...

Hi, I am trying to speedup my Julia finite element code. Right now I use the built in sparse solver to solve the linear system in parallel and the solving step is very fast. But my system matrix assembly is done serially using single process and its slow. I would like to speed up by assembling

[julia-users] What happened with the Pkg.generate?

I found Pkg.generate disappeared in the master branch today. Is it just removed or transfered to another package?

[julia-users] eval() in try block

I'm trying to eval an expression in a try block and it doesn't seem to work. a=[] for i=1:4 try if i==3 error() end eval(:(push!(a,i))) catch e end end a After running the above code a evaluates to: 0-element Array{Any,1} I'm expecting and want the same result a

[julia-users] eval() in try/catch

I'm trying to eval() an expression in a try block as below. However the evaluation does not seem to happen and *a* is unchanged after the code block. a=[] for i=1:4 try if i==3 error() end eval(:(push!(a,i))) catch e end end a evaluates to: 0-element Array{Any

[julia-users] Re: ANN: ParallelAccelerator.jl v0.1 released

Hi Eric, These two use cases are not currently targeted but they are interesting. They seem possible to implement in ParallelAccelerator.jl. You are more than welcome to give them a try if you are interested :) Bests, -Ehsan On Tuesday, October 20, 2015 at 6:13:46 PM UTC-7, Eric Forgy wrote: >

[julia-users] Re: Performance compared to Matlab

Is it possible to tell Julia to run the vectorized code in parallel? Looking at the documentation I see that you can do it easily for the looped version but is there a macro or something to pass the vectorized version so that is becomes parallel? On Sunday, 18 October 2015 22:03:13 UTC-7, Glen

[julia-users] Re: What happened with the Pkg.generate?

Transferred: https://github.com/JuliaLang/PkgDev.jl On Wednesday, October 21, 2015 at 9:11:43 AM UTC+2, Lanting Guo wrote: > > I found Pkg.generate disappeared in the master branch today. Is it just > removed or transfered to another package? >

[julia-users] Re: eval() in try block

The try block is hiding an error, ERROR: UndefVarError: i not defined. You need to interpolate the i variable in the quoted expression using $i: for i=1:4 try if i==3 error() end eval(:(push!(a,$i))) catch e end end — Mike ​ On Wednesday, 21 October 2015 09:11:44 UT

[julia-users] Re: What happened with the Pkg.generate?

Thank you, Kristoffer On Wednesday, October 21, 2015 at 3:28:39 PM UTC+8, Kristoffer Carlsson wrote: > > Transferred: https://github.com/JuliaLang/PkgDev.jl > > On Wednesday, October 21, 2015 at 9:11:43 AM UTC+2, Lanting Guo wrote: >> >> I found Pkg.generate disappeared in the master branch today

Re: [julia-users] ANN: ParallelAccelerator.jl v0.1 released

The license looks like a totally standard BSD 2 to me, which is as permissive as things get and essentially equivalent to MIT. Nice work to the Intel Labs team, it's great that this has been publicly released. I hope to see the subset of the language that it can handle grow over time. Leveragin

[julia-users] Re: eval() in try block

Thank you Mike, your solution works. However, I don't understand why the $ interpolation is required. I see the variable *a* does not require interpolation, why does *i* require it? On Wednesday, 21 October 2015 15:30:42 UTC+8, Michael Hatherly wrote: > > The try block is hiding an error, ERROR:

[julia-users] Re: eval() in try/catch

sorry, double post. I accidentally pressed a bunch of keys and thought I lost the post.

[julia-users] Re: eval() in try block

I see the variable a does not require interpolation, why does i require it? eval evaluates expressions in a module’s global scope. a is defined in the global scope, but i is local to the for loop and is undefined outside of the loop. — Mike ​ On Wednesday, 21 October 2015 11:18:34 UTC+2, 2n w

[julia-users] Re: speed increase of factor 70 for mixed scalar-vector vcat

Thanks for the pointer to https://github.com/JuliaLang/julia/issues/3738 . I filed a documentation issue https://github.com/JuliaLang/julia/issues/13702

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

It doesn't directly answer your question, but one thought is to not force many of these ranges to become vectors. For instance, the line t = t0 + [0:Ns-1;]*Ts; could also have been written t = t0 + (0:Ns-1)*Ts; and that would still be valid input to functions like sin, cos, exp, etc... On Wedn

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

I'd argue that this should work: julia> rand(4,4)*(1:4) ERROR: MethodError: `A_mul_B!` has no method matching A_mul_B!(::Array{Float64,1}, ::Array{Float64,2}, ::UnitRange{Int64}) i.e. ranges should be equivalent to column vectors. But others more knowledgeable on the linear algebra code may hav

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

Nice to see this is coming up again. (hopefully many more times). There seems to be a small group of people (me included) who are really bothered by this. Here is the link to the last discussion I remember: https://groups.google.com/forum/#!searchin/julia-users/linspace/julia-users/qPqgJS-usrU/

[julia-users] map() vs. comprehensions

Hi, I'd like to check which approach is a better one for the example below. The task is rather simple, each string in vector "s" should be "surrounded" by square brackets. e.g. s = AbstractString["as", "sdf", "qwer"] # s is typically a lot longer @time st1 = AbstractString[ "[" * i * "]" for

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

Gabriel, I rewrote your code to not ever explicitly convert ranges to arrays and it still works fine. Maybe I'm not quite understanding the issue? function Jakes_Flat( fd, Ts, Ns, t0 = 0, E0 = 1, phi_N = 0 ) # Inputs: # # Outputs: N0 = 8; # As suggested by Jakes N = 4*N0+2

[julia-users] Re: map() vs. comprehensions

I'm going to guess either it's because of the anonymous function definition within your map function. Note that you aren't getting *exactly* the same results, as the Array types are different. It also isn't universally true that comprehensions are faster. See the following counter-example: *ju

[julia-users] Re: map() vs. comprehensions

Hi Randy, Thanks for an excellent example. It is probably the anonymous function combined with some type inference happening. Shall I define a separate concatenating function and pass it to map() ? Cheers, Jan Dňa streda, 21. októbra 2015 15:10:16 UTC+2 Randy Zwitch napísal(-a): > > I'm going

[julia-users] Re: ANN: ParallelAccelerator.jl v0.1 released

This is fantastic work! Thanks and congratulations to the team at Intel. On Tuesday, October 20, 2015 at 8:57:17 PM UTC-4, Lindsey Kuper wrote: > > The High Performance Scripting team at Intel Labs is pleased to announce > the release of version 0.1 of ParallelAccelerator.jl, a package for > h

[julia-users] Re: map() vs. comprehensions

Interestingly: _g(x) = "[" * x * "]" _g (generic function with 1 method) @time st2 = map(_g, s) 0.44 seconds (11 allocations: 544 bytes) 3-element Array{ASCIIString,1}: "[as]" "[sdf]" "[qwer]" This time map() has even lower footprint then original comprehension. Jan > >>

[julia-users] Re: map() vs. comprehensions

I wonder what is wrong with using anonymous function ... Thanks, Jan Dňa streda, 21. októbra 2015 15:31:08 UTC+2 Ján Dolinský napísal(-a): > > Interestingly: > > _g(x) = "[" * x * "]" > _g (generic function with 1 method) > > @time st2 = map(_g, s) > 0.44 seconds (11 allocations: 544 bytes

[julia-users] Re: simple parallel assembly example...

Hi. I ran across the same issue before, but after some tests, I still can't beat the speed of the built in K=Sparse(I,J,V). Actually, if the local element matrices are expensive, one can make the assembly of I, J and V in parallel, but the overall speed will depend on the memory copy. On Wed

[julia-users] Re: ANN: ParallelAccelerator.jl v0.1 released

Great news! Apart from the focus on parallelism, the architecture seems similar to numba . Good to finally have shared memory parallelism in Julia (not counting the shared memory array under Linux via shm). I wonder how this is going to interact with the upcoming multit

[julia-users] Re: map() vs. comprehensions

It's a well known issue: https://github.com/JuliaLang/julia/issues/1864 Sadly, it's not that easy to fix. There's a temporary fix in form of a package: https://github.com/timholy/FastAnonymous.jl We might get fast anonymous functions in 0.5, though! Am Mittwoch, 21. Oktober 2015 14:55:50 UTC+2 sc

[julia-users] Re: map() vs. comprehensions

Hi Simon, Thanks for the clarification. Best Regards, Jan Dňa streda, 21. októbra 2015 16:13:23 UTC+2 Simon Danisch napísal(-a): > > It's a well known issue: https://github.com/JuliaLang/julia/issues/1864 > Sadly, it's not that easy to fix. > There's a temporary fix in form of a package: > http

Re: [julia-users] Re: map() vs. comprehensions

Le mercredi 21 octobre 2015 à 06:10 -0700, Randy Zwitch a écrit : > I'm going to guess either it's because of the anonymous function > definition within your map function. Note that you aren't getting > *exactly* the same results, as the Array types are different. > > It also isn't universally tru

[julia-users] Re: Shared Array on remote machines?

Indeed I am not trying to share memory across processes on different machines. Yes neither do I understand why the code above doesn't work. I was hoping I might get suggestions as to what such workaround might be. On Tuesday, October 20, 2015 at 2:10:27 PM UTC+1, Páll Haraldsson wrote: > > "Sha

[julia-users] Re: TinySegmenter benchmark

Thanks for Steven's great help, I learned many things to optimize string operation of Julia. Finally, I wrote this episode on my blog (in Japanese only, sorry). http://chezou.hatenablog.com/entry/2015/10/21/234317 -- chezou 2015年10月21日水曜日 2時49分56秒 UTC+9 Steven G. Johnson: > > I thought people m

[julia-users] Module reloading/Autoreloading workflow in 0.4

I'm struggling to get a good workflow going in 0.4. The docs tell me what I can do, but not so much what I should. How does everybody work? What does your "startup code" look like? In particular: 1. Should I `push!(LOAD_PATH, ".")`, or

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

No that is a good point. Often you can use an iterator where an explicit array would also work. The issue I guess is that this puts the burden on the developer to always write generic code that when you would want to accept an Array you also need to accept a iterator like LinSpace. Maybe this

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

On Wed, Oct 21, 2015, at 11:38 AM, Gabriel Gellner wrote: > No that is a good point. Often you can use an iterator where an > explicit array would also work. The issue I guess is that this puts > the burden on the developer to always write generic code that when you > would want to accept an Array

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

Actually it is that easy... you just have to get in the habit of doing it: julia> function mysum(arr::Array) s = zero(eltype(arr)) for a in arr s += a end s end mysum (generic function with 1 method) julia> mysum(1:10) ERROR: Meth

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

Just to add to Spencer's answer: Is there a particular reason to have your function arguments have type annotations at all in the function definition? You could just write function f(x) y= x[3:5] # or whatever z = length(x) end and now someone could call f with any kind of object that supp

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

On Wednesday, October 21, 2015 at 3:11:44 AM UTC-4, Gabriel Gellner wrote: > > I find the way that you need to use `linspace` and `range` objects a bit > jarring for when you want to write vectorized code, or when I want to pass > an array to a function that requires an Array. I get how nice th

Re: [julia-users] Re: map() vs. comprehensions

element-wise multiplication of string vectors works too, but only if one vector is of length 1: julia> @time ["["] .* ["as", "sdf", "qwer"] .* ["]"] 0.33 seconds (35 allocations: 1.656 KB) 3-element Array{ASCIIString,1}: "[as]" "[sdf]" "[qwer]" if you prefer this syntax to map or compre

[julia-users] Re: Module reloading/Autoreloading workflow in 0.4

Hi, I'm the author of Autoreload. I stopped maintaining it since I now use the great Atom Julia plugin (https://github.com/JunoLab/atom-julia-client, built by Mike Innes, who participates in this forum). Its workflow is described in https://github.com/JunoLab/atom-julia-client/blob/master/docs/

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

On Wednesday, October 21, 2015 at 11:57:08 AM UTC-4, Jonathan Malmaud wrote: > > Just to add to Spencer's answer: Is there a particular reason to have your > function arguments have type annotations at all in the function definition? > You could just write > > function f(x) > y= x[3:5] # or

Re: [julia-users] Re: map() vs. comprehensions

correction-- element-wise multiplication of string vectors also works if the two are of equal length: julia> ["a","b"] .* ["c","d"] 2-element Array{ASCIIString,1}: "ac" "bd"

Re: [julia-users] Re: Installing package (Cpp). Could not spawn 'make'.

Thank you Tony for your answer. I have just recently got into Python and building/compiling with MinGW-w32 and CMake (a lot of the terminology still goes over my head). Great talk! One main question from it; using Windows, is it possible to download a package from GitHub (which currently does not

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

All true. One tip: if you want to find out what abstract type is a parent to all the concrete types you're interested in, you can use the "typejoin" function. julia> typejoin(Array, LinSpace) AbstractArray{T,N} julia> typejoin(Vector,LinSpace) AbstractArray{T,1} On Wednesday, October 21, 20

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

On Wednesday, October 21, 2015 at 11:50:32 AM UTC-4, Spencer Russell wrote: > > For efficiency you'll still want to use a concrete Vector field if you're > defining your own types, but luckily there seems to be a convert method > defined so you can do: > > type MyArr{T} > x::Vector{T} > en

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

On Wed, Oct 21, 2015, at 12:08 PM, Steven G. Johnson wrote: > On Wednesday, October 21, 2015 at 11:50:32 AM UTC-4, Spencer Russell wrote:  >> >> For efficiency you'll still want to use a concrete Vector field if >> you're defining your own types, but luckily there seems to be a >> convert method de

Re: [julia-users] Julia garbage collection - question on status and future (and interaction when using with other languages)

Different selectable GCs would be a reasonable thing to have – it's unclear whether a single GC strategy can be sufficiently good to satisfy all possible requirements. That being said, the eventual standard Julia GC ought to be good enough for most use cases. I also dislike having too many knobs to

Re: [julia-users] Julia and Object-Oriented Programming

On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey wrote: > The US Supreme Court may get involved if you call it Scalia. Hard to know > in which direction. The watershed Scalia vs. Scalia case of 2016.

Re: [julia-users] Julia and Object-Oriented Programming

On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey wrote: > > > Above, a relatively simple macro can replace all the "Type..." with the > fields of the composed types, applying multiple inheritance of the > structures without the baggage required in classic OOP. Then you can > compose your type fro

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

I *really* wish there was a way to collapse LinSpace and FloatRange into a single type, but I cannot for the life of me figure out how to do it without making both of them much slower. On Tue, Oct 20, 2015 at 11:14 PM, Art Kuo wrote: > By the way, the original issue has been addressed and is now

Re: [julia-users] Re: Performance compared to Matlab

On Tue, Oct 20, 2015 at 1:07 PM, Gabriel Gellner wrote: > Is it possible to tell Julia to run the vectorized code in parallel? > Looking at the documentation I see that you can do it easily for the looped > version but is there a macro or something to pass the vectorized version so > that is beco

Re: [julia-users] Re: TinySegmenter benchmark

That's an excellent performance comparison case study! Nice work, Chezou and nice blog post (the Google translation is pretty readable). On Wed, Oct 21, 2015 at 10:58 AM, Michiaki Ariga wrote: > Thanks for Steven's great help, I learned many things to optimize string > operation of Julia. > > Fi

Re: [julia-users] Re: map() vs. comprehensions

Fortunately, this performance issue is currently in Jeff's sights and doesn't have long to live. On Wed, Oct 21, 2015 at 10:13 AM, Simon Danisch wrote: > It's a well known issue: https://github.com/JuliaLang/julia/issues/1864 > Sadly, it's n

Re: [julia-users] Julia and Object-Oriented Programming

I think this discussion shows complementary definitions of traits: - verb-based traits: a type agrees to implement all the verbs appropriate to the given "verb trait" - noun-based traits: a type agrees to contain certain underlying data (and thus the getter/setter verbs could be implic

[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] Any plans for free tutorials on Coursera,edX or Udacity?

Hi, Are there any plans for free online tutorials at Coursera, EdX or Udacity? I guess "Introduction to Julia", "Introduction to Data Analysis with Julia", "Introduction to Machine Learning with Julia" etc. would bring a lot of attention and "spread the word". Best, Brian

[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 rai

Re: [julia-users] Re: Installing package (Cpp). Could not spawn 'make'.

The answer is a not-particularly-helpful "it depends." Which library are you interested in as a starting point? Not everything will be easy to build on Windows, there are often posix/unix assumptions in the code or build system. Usually the easiest way to get started is by installing MSYS2 http

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

Bleh. I submitted my answer many hours ago, but since it was my first post ever, it had to go through an approval process. So now I look like some johnny-come-lately with my code :/ Mauro: This looks a lot like a bug to me. For example: julia> ones(4)' * (1:4) 1-element Array{Float64,1}:

[julia-users] Re: ANN: ParallelAccelerator.jl v0.1 released

Hi Steven, We are working closely with the authors of the threading support in Julia. Our plan is to support it as soon as it is ready. Best, -Ehsan On Wednesday, October 21, 2015 at 7:12:50 AM UTC-7, Steven Sagaert wrote: > > Great news! > Apart from the focus on parallelism, the architecture

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

Call `collect` on them ;) On Wed, Oct 21, 2015 at 12:43 PM, Stefan Karpinski wrote: > I *really* wish there was a way to collapse LinSpace and FloatRange into a > single type, but I cannot for the life of me figure out how to do it > without making both of them much slower. > > On Tue, Oct 20,

[julia-users] ccall and type definition in a macro

Hi, I am having the following problem. Here is my code: julia> macro myname(arg) typname = esc(arg) privtypname = esc(symbol(string("priv",arg))) code = quote typealias $(typname) ccall( (:clock, "libc"), Int32, ()) type

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

Wow! Thanks everyone for all the advice!!! Super helpful. I now see that it is super easy to deal with the LinSpace objects. That being said I guess I get scared when the docs tell me to use concrete types for performance ;) Most of the code I write for myself is working with Float64 arrays a

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

I agree with this downvote so much it hurts. The logspace/linspace is painfully ugly. linrange is the right name in my find for the iterator version. On Wednesday, 30 September 2015 10:31:55 UTC-7, Alex Ames wrote: > > Another downvote on linspace returning a range object. It seems odd for > li

[julia-users] What does sizehint! do, exactly?

I know it's good to use sizehint! with an estimate of the sizes of (variable-length) containers such as vectors, but I have a couple of questions I'm hoping someone could answer: 1) what are the benefits of using sizehint!? (How does it work, and under what circumstances is it beneficial?) 2) w

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

Oh man thanks for this link. Makes me feel better that I am not alone in feeling this pain. This is really the first *wart* I have felt in the language decisions in Julia. Forcing iterators as the default such a common array generation object feels so needless. Calling any code that asks for a

Re: [julia-users] What does sizehint! do, exactly?

The way I came to understand was to just take a peak at the [source code]( https://github.com/JuliaLang/julia/blob/ae154d076a6ae75bfdb9a0a377a6a5f9b0e1096f/src/array.c#L670); I find it pretty legible. The basic idea is that the underlying "storage" of a Julia Array{T,N} can actually be (and often i

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

It’s still hard for me to understanding what the value of returning an array is by default. By getting a structured LinSpace object, it enables things like having the REPL print it in a special way, to optimize arithmetic operations on it (so that adding a scalar to a LinSpace is O(1) instead

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

This thread is tragically long on opinions and short on arguments backing them up. It occurs to me that we can write specialized methods for collect(::LinSpace) that generate the collected version more efficiently than generic iteration does, which eliminates one of the potential arguments for just

Re: [julia-users] What does sizehint! do, exactly?

If you expect that you're going to have to push a lot of values onto a vector, you can avoid the cost of incremental reallocation by doing it once up front. On Wednesday, October 21, 2015, Jacob Quinn wrote: > The way I came to understand was to just take a peak at the [source code]( > https://g

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

Continuing to think about all the ideas presented in this thread. It seems that the general advice is that almost all functions should at first pass be of "Abstract" or untyped (duck typed) versions. If this is the case why is Abstract not the default meaning for Array? Is this just a historical

[julia-users] Re: ARM binaries for julia 0.4

Viral - What Linux distribution, GCC version, etc was used to build these? -Tony On Friday, October 2, 2015 at 5:50:05 PM UTC-7, Viral Shah wrote: > > Folks, please try out our first ARM binaries. Elliot is working on making > this part of the standard build so that we can get them automatical

Re: [julia-users] What does sizehint! do, exactly?

Thanks, Jacob and Stefan. What happens if you overestimate? Is the allocated-but-not-used memory eventually freed, or is it tied up until the object gets removed? On Wednesday, October 21, 2015 at 12:18:28 PM UTC-7, Stefan Karpinski wrote: > > If you expect that you're going to have to push a lo

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

I don't really agree that it is a wart. Because the Ranges have such nice behaviours, I think it is reasonable to let them be the default. People should be encouraged to use and get familiar with these very elegant data structures. If (0:N) returned Array{Int, 1}, then that is what everyone wou

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

> On Oct 21, 2015, at 3:19 PM, Gabriel Gellner wrote: > > Continuing to think about all the ideas presented in this thread. It seems > that the general advice is that almost all functions should at first pass be > of "Abstract" or untyped (duck typed) versions. If this is the case why is > Ab

Re: [julia-users] Julia and Object-Oriented Programming

How is the idea that any function defined with Julia tag gets into a first class object with name *Julia* in a combined ScalaJulia language : *Julia* function sphere_vol(r) # julia allows Unicode names (in UTF-8 encoding) # so

[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 Gellner

Re: [julia-users] What does sizehint! do, exactly?

I believe it stays allocated until the object is removed. There's an old issue about providing a way to "shrink" the underlying storage: https://github.com/JuliaLang/julia/issues/2879 -Jacob On Wed, Oct 21, 2015 at 1:26 PM, Seth wrote: > Thanks, Jacob and Stefan. What happens if you overestimat

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

I have no issue with the LinSpace object, I simply do not see why it is the special case for this kind of object (I imagine the choice was made since it was seen to be used mainly for looping vs being used for array creation like similar functions logspace, zeros, ones, etc). If the iterator ver

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

It was motivated by consistency with strings. Initially there was Array <: AbstractArray, but ASCIIString <: String. So to be consistent between those, you have the choice of renaming things to get either 1) ConcreteArray <: Array and ASCIIString <: String or 2) Array <: AbstractArray and ASCIIS

Re: [julia-users] Julia and Object-Oriented Programming

Excellent idea. You should make a PR against the Scala GitHub repo and see how it goes. On Wed, Oct 21, 2015 at 3:31 PM, wrote: > How is the idea that any function defined with Julia tag gets into a first > class object with name *Julia* in a combined ScalaJulia language : > > *Julia* function s

Re: [julia-users] Julia and Object-Oriented Programming

Earlier I posted a statement in this thread that object-oriented programming is in many cases not suitable for scientific software because it forces the designer to make decisions too early in the design process that become unwelcome constraints as the project progresses. If I understand what

[julia-users] Re: Are (+), (*) the only ops that can use n-ary definitions?

good look -- thanks On Sunday, October 18, 2015 at 9:13:14 PM UTC-4, Páll Haraldsson wrote: > > On Monday, October 19, 2015 at 1:00:33 AM UTC, Páll Haraldsson wrote: >> >> On Tuesday, September 1, 2015 at 1:08:38 PM UTC, Jeffrey Sarnoff wrote: >>> >>> import Base:(+),(*),(-) >>> >>> julia> 2+3+4 >

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

I understand. I'm just wondering why consistency between those two cases is particularly important, when there are lots of other parts of the type hierarchy where supertypes do not have the Abstract prefix. Is that the goal, that all abstract types should have an 'Abstract' prefix to their name

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

Well, those need the ‘Abstract’ prefix to distinguish them from their concrete counterpart. There was already “Array” in the language, so what are you gong to call the type that is array-like but not literally an array? But take another common - there is the abstract type “IO", who subtypes inc

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 Impo

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

I don't think there is much to argue about, except perhaps names. 1. `linspace` returns a range, but is otherwise a drop-in replacement for an array, and should act as one for any naive user, other than sometimes being faster and taking less memory. This is not hidden from the user

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, 2

[julia-users] Re: Generated Type from a Macro

Thanks for your help, but it works, but i have another problem, accidentally i opened a new post, here is the link including a ccall and type definition in a macro: https://groups.google.com/forum/#!topic/julia-users/jDayl3Wx8uU. I followed the game you suggested but something is fishy i guess.

Re: [julia-users] Re: Performance compared to Matlab

For fun (and science) I tried out the new package https://github.com/IntelLabs/ParallelAccelerator.jl for this problem. Here is the code: function Jakes_Flat( fd, Ts, Ns, t0 = 0, E0 = 1, phi_N = 0 ) # Inputs: # # Outputs: N0 = 8; # As suggested by Jakes N = 4*N0+2;

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

That doesn't feel like a reason that they can't be iterators, rather that they might be slow ;) a la python. My point is not about speed but the consistency of the language. Are there many cases in Julia where there is a special type like this because it is convenient/elegant to implement? This

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

The types Vector, Matrix and Tensor were abstract originally . The Array type was the concrete implementation of Tensor. Later on we introduced

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

On Wed, Oct 21, 2015 at 4:07 PM, 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. My point is not about speed but the > consistency of the language. How do you propose making arbitrary arrays into iterators?

[julia-users] Re: Are (+), (*) the only ops that can use n-ary definitions?

I was thinking about continued fraction evaluation. Your 'misread' was very informative. I appreciate the detail -- that is very helpful. On Wednesday, October 21, 2015 at 3:50:52 PM UTC-4, Jeffrey Sarnoff wrote: > > good look -- thanks > > On Sunday, October 18, 2015 at 9:13:14 PM UTC-4, Páll Ha

[julia-users] Re: Performance compared to Matlab

For fun (and science) I tried out the new package https://github.com/IntelLabs/ParallelAccelerator.jl for this problem. Here is the code: function Jakes_Flat( fd, Ts, Ns, t0 = 0, E0 = 1, phi_N = 0 ) # Inputs: # # Outputs: N0 = 8; # As suggested by Jakes N = 4*N0+2;

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

I tried to find this previously, but failed until now: https://github.com/JuliaLang/julia/pull/8872 That's the pull request for the String -> AbstractString renaming. Even though I may not completely agree, this explains a lot about the thinking behind the renaming. On Wednesday, October 21, 2

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

On Wed, Oct 21, 2015, at 04:07 PM, 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. My point is not about speed > but the consistency of the language. Are there many cases in Julia > where there is a special type

[julia-users] Re: Performance compared to Matlab

Btw it is really cool to see julia running at 400% CPU when running a list comprehension. I did some more benchmarks with larger N to reduce the noise a bit and the difference is actually not that great between Matlab and Julia. However, tying with Matlabs parallellized vectorized maps is great

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] Re: A question of Style: Iterators into regular Arrays

You're making good points for sure - logspace and linspace are inconsistent wrt return types. But I just having trouble seeing how it impacts you as a user of the language; it's essentially an implementation detail that allows for some optimizations when performing arithmetic on array-like values

  1   2   >