[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

[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

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

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

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

[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

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,

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

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

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

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

[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

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] 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.

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

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

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:

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

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

[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

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

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 >

[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

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

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

[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

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

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 >

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

[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, ())

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

[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

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

[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

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

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

[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

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

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

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

[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

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

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,

[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

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

[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

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

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

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,

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

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

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

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

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

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

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

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

[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

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

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

I thought Juno is still the brandname for the LightTable plug in. In any case, the command “Set current module” doesn’t seem to exist for me > On 22 Oct 2015, at 8:19 AM, Jonathan Malmaud wrote: > > Juno is the brand name of atom-julia-client. > >> On Oct 21,

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

Within IJulia, Autoreload.jl will automatically reload any changed files that were "require"ed before a cell is executed. That isn't possible in the normal Julia REPL at the moment, but I have a proposal out (https://github.com/JuliaLang/julia/issues/6445) that would enable it. On

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

Juno is the brand name of atom-julia-client. > On Oct 21, 2015, at 5:18 PM, Sheehan Olver wrote: > > The link describing the workflow is for Juno, not atom-julia-client. How do > you do the same in Atom? > > On Thursday, October 22, 2015 at 3:05:08 AM UTC+11, Jonathan

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

I think much of the problem is that many necessary packages (e.g. for plotting) don’t currently allow Range/AbstractVector, and many functions in Base are slower for ranges than for vectors. These are probably just teething problems, but until they are resolved “collect” ends up

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

Is there a reason Julia doesn't use jl_array_del_end as a means to allow users to shrink the allocation for an array (either within sizehint! or as a separate function)? On Wednesday, October 21, 2015 at 12:32:04 PM UTC-7, Jacob Quinn wrote: > > I believe it stays allocated until the object is

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

The whole notion of always using a single dense array type is simply a non-starter. Do we just scrap the whole sparse array thing? There goes half of the stuff you might want to do in linear algebra or machine learning. Special matrix types like Diagonal or UpperTriangular, etc.? Toss those out

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

On Wed, Oct 21, 2015 at 5:13 PM, Gabriel Gellner wrote: > Maybe all this is just transitional that soon LinSpace objects will always > work like Arrays in all code I might use as an end user. Currently as a new > user I have not had this experience. I have noticed that

Re: [julia-users] Re: TinySegmenter benchmark

On 21 October 2015 at 17:49, Stefan Karpinski wrote: > > That's an excellent performance comparison case study! Nice work, Chezou and > nice blog post (the Google translation is pretty readable). Very readable indeed and I am always happy to see more NLP code in Julia!

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

This looks to be a known issue (2586). The entire expression is sent to the compiler as a single "thunk" because of the `ccall`, but type declarations can only be evaluated at global scope. You would see the same error when trying to evaluate the resulting quoted expression, so this is not unique

Re: [julia-users] numerical trig question about refining good approximation to sin,cos

from the credit where credit is due department: Arb (available with Nemo.jl) is better. On Saturday, October 17, 2015 at 7:43:02 PM UTC-4, John Gibson wrote: > > I have to take back a couple things. The Julia docs are clearer than I > thought about the BigFloat type: it's fixed-sized but

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

I think that's why there's an open issue :) On Wed, Oct 21, 2015 at 3:29 PM, Seth wrote: > Is there a reason Julia doesn't use jl_array_del_end as a means to allow > users to shrink the allocation for an array (either within sizehint! or as > a separate function)? > >

[julia-users] Re: Performance compared to Matlab

It's fantastic to see some good ParallelAccelerator results "in the wild"! Thanks for sharing. Lindsey On Wednesday, October 21, 2015 at 1:23:53 PM UTC-7, Kristoffer Carlsson wrote: > > Btw it is really cool to see julia running at 400% CPU when running a list > comprehension. > > I did some

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

Okay so I am starting to see the light. I see that if LinSpace becomes fully replacable for an Array it is fine. Final Questions: * I can't use LinSpace in matrix mult A * b::LinSpace, is this simply a Bug/Missing Feature? Or intentional? In general if basic builtin functions that operate on

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

Looking at the original example of the Cpp.jl package, it appears to only be needing to call `make` at Pkg.build time in order to compile a demo test library. It should be pretty easy to modify it so it would fail gracefully with a warning rather than an error. On Wednesday, October 21, 2015

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

Hi Jonathan, Thank you for maintaining Autoreload and for all the pointers. It made me seriously consider Atom. Do you know if it's the future of Juno (vs. Lighttable)? How do you like it as a Jupyter notebook replacement? I'll try to get some reproducible bug description filed. Best, Cédric

[julia-users] Re: Help on performance issues

I got interested in trying to optimize this problem even further. Here are the results: https://gist.github.com/jwmerrill/5b364d1887f40f889142 I was able to get the benchmark down to a few microseconds (or ~100 microseconds if you count the time to build a look up table). Either way, it's a

[julia-users] Workflow for making pull request for others Packages?

This is probably more of a git question, but thought I'd ask here anyways. Right now if I want to make a fix for someone else's package (e.g., 0.4 deprecated warnings) my workflow is fairly complicated: 1)Create fork on github.com 2)Delete .julia/v0.4/Foo 3)git clone

Re: [julia-users] Re: Help on performance issues

That's a very nice implementation. Great example of how making custom types can give you a really lovely combination of usability and performance. I may use this in some talks if you don't mind! On Wed, Oct 21, 2015 at 7:08 PM, Jason Merrill wrote: > I got interested in

[julia-users] Workflow for making pull request for others Packages?

No need to delete the package. Just add your fork as a new remote repo. git remote add forkremote https://forkremoteaddress... Make changes on prbranch then git push forkremote prbranch And then make the pr from your fork.

[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] Re: Help on performance issues

Excellent. I will – with attribution, of course! On Wed, Oct 21, 2015 at 7:26 PM, Jason Merrill wrote: > Thanks! Definitely feel free to use this wherever you like. > > On Wed, Oct 21, 2015 at 7:13 PM Stefan Karpinski > wrote: > >> That's a very nice

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

Sweetness. Thank you. AbstractArray it is for me! On Wednesday, 21 October 2015 16:29:28 UTC-7, Tim Holy wrote: > > On Wednesday, October 21, 2015 03:32:04 PM Gabriel Gellner wrote: > > * I can't use LinSpace in matrix mult A * b::LinSpace, is this simply a > > Bug/Missing Feature? > > Yes >

Re: [julia-users] Workflow for making pull request for others Packages?

Thanks for the tips! That helps a lot. > On 22 Oct 2015, at 10:35 AM, Tim Holy wrote: > > I find this much easier: > > julia> cd(Pkg.dir("BustedPkg")) > > # The next is optional, but recommended > julia> ;git checkout -b myinitials/myfixedbranch > > julia>

[julia-users] Altering matrix inside function

I want to change a matrix inside a function. Example( just to illustrate): julia> x = ones(2,3) 2x3 Array{Float64,2}: 1.0 1.0 1.0 1.0 1.0 1.0 julia> function deletecolumns(x,i) x = x[:,1:size(x,2) .!= i] end deletecolumns (generic function with 1 method) julia>

Re: [julia-users] Workflow for making pull request for others Packages?

That's really nice, I had no idea... It's well documented , too. On Wednesday, October 21, 2015 at 7:36:00 PM UTC-4, Tim Holy wrote: > > I find this much easier: > > julia>

Re: [julia-users] Re: Help on performance issues

Thanks! Definitely feel free to use this wherever you like. On Wed, Oct 21, 2015 at 7:13 PM Stefan Karpinski wrote: > That's a very nice implementation. Great example of how making custom > types can give you a really lovely combination of usability and > performance. I may

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

On Wednesday, October 21, 2015 03:32:04 PM Gabriel Gellner wrote: > * I can't use LinSpace in matrix mult A * b::LinSpace, is this simply a > Bug/Missing Feature? Yes > * LinSpace objects seem much slower when used in things like element > multiplication A .* b::LinSpace is much much Slower than

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

Isn't the situation actually similar to functions like `eye` which returns a dense array (which doesn't feel intuitive for what an eye or diagonal matrix actually is) whereas we have to call the special version seye to get a sparse array. For most users linspace is like `eye` by default

Re: [julia-users] Workflow for making pull request for others Packages?

I find this much easier: julia> cd(Pkg.dir("BustedPkg")) # The next is optional, but recommended julia> ;git checkout -b myinitials/myfixedbranch julia> edit("src/BustedPkg.jl") julia> ;git commit -a -m "Fix broken stuff" julia> Pkg.submit("BustedPkg") The last line is probably the main

Re: [julia-users] Re: Type array bug?

It worked, thanks. On Friday, October 16, 2015 at 6:38:50 PM UTC-3, Yichao Yu wrote: > > On Fri, Oct 16, 2015 at 5:35 PM, Thuener Silva > wrote: > > I'm having this kind of problem in different situations. Another > example: > > > > julia> groups_1 = [Array((Int),0) for

  1   2   >