Re: [julia-users] merged arrays?

AFAIK, there's nothing really like that right now, but what do you plan to do with the data? Most linear algebra code, for example, calls out to BLAS, which requires data to be contiguous (or at least strided) in memory. Other code may or may not have this same restriction. It should be relative

[julia-users] Re: CALL FOR PARTICIPATION: JuliaCon 2015, June 24-28, MIT

Proposal submission deadline extended by popular request to *Sunday, April 12 at 11:59pm EDT*.

[julia-users] merged arrays?

I can use sub to pretend a larger array is a smaller, or differently shaped one. Is there functionality to allow me to treat several smaller arrays as a larger one without copying them? In effect, mimicking hcat and friends, but without copying data.

Re: [julia-users] Re: Default behavior from omitted catch block when a finally block is added.

I have put in a pull request for a documentation change related to this https://github.com/JuliaLang/julia/pull/10776 Please note it contains a few more edits that seemed appropriate. Please approve or let me know what needs to change. I would be happy to amend the documentation again if you deci

Re: [julia-users] Usage of floating point template arguments with many different values

It already is Interval{Float64}. The issue is choosing defaults for a and b which aren't inferrable from the type. I think I'm convinced that just using NaN should work, with other domains having a similar representation for parameters not set. Sent from my iPhone > On 9 Apr 2015, at 6:41 am,

[julia-users] Errors from make doctest

Hello, I did a fresh build of julia from master/latest source and I get tons of errors for "make doctest" (all errors are identical though) I am attempting to run "make doctest" from the doc/ subdirectory. My goal is to make sure my edits and corrections pass the doctest I have tried two ways

Re: [julia-users] Usage of floating point template arguments with many different values

On Tuesday, April 7, 2015 at 5:53:09 PM UTC-4, Sheehan Olver wrote: > > > The current problem is > > f=Fun(x->x^2,Chebyshev(Interval(a,b))) > > represents a function on [a,b] as type Fun{Float64,Chebyshev}. But > sometimes one needs to convert numbers to functions a la > >

[julia-users] code review: my first outer constructor :)

Hi guys! Here is [part of] some code I recently wrote for solving a physics problem: https://gist.github.com/berceanu/010d331884848205acef It's the first time I try to use Julia constructors properly (or improperly?!) so I need your opinion on a couple of points. 1. On Julia's IRC channel I was

Re: [julia-users] Direct access to fields in a type, unjulian?

> Mauro, thanks for the link. I read the paper by Logg and it seems > interesting. Do you have any references for how the mapping from the cells > to the actual finite elements is done? No, I never got that far. But it doesn't contain any nodes, so presumably those are all separate from the geo

Re: [julia-users] Direct access to fields in a type, unjulian?

Thank you Tim for your suggestion about creating functions returning iterators. That sounds indeed like a very clean way to do it. Mauro, thanks for the link. I read the paper by Logg and it seems interesting. Do you have any references for how the mapping from the cells to the actual finite el

Re: [julia-users] Direct access to fields in a type, unjulian?

> Can you comment on the performance implications of directly accessing > fields vs your approach? I'm guessing that directly accessing the fields > would be faster? I think usually it should get inlined and there is no difference: julia> immutable A a::Int end julia> function f

Re: [julia-users] Direct access to fields in a type, unjulian?

On Wednesday, April 8, 2015 at 8:00:42 AM UTC-7, Tim Holy wrote: > > It's a matter of taste, really, but in general I agree that the Julian way > is > to reduce the number of accesses to fields directly. That said, I do > sometimes > access the fields. > > However, your iterator example is a

Re: [julia-users] Holt-Winters D-E Smoothing in Julia

Thank you.

Re: [julia-users] Re: Unexpected behaviour when running parallelized code on single worker

Thank you Tim for explaining that more clearly. This morning's reply was ENOCOFFEE :D Please do file an issue, Nils, and thanks for investigating further. On Wednesday, April 8, 2015 at 10:03:04 AM UTC-5, Tim Holy wrote: > > Sounds like a bug, but I think what Patrick was trying to say is that i

Re: [julia-users] A method with an optional parameter may result in a different method being called

Thanks, Seth, that example looks even stranger than what I encountered. I have suggested adding a short paragraph to the manual: https://github.com/JuliaLang/julia/pull/10769 I can't think of a case where the author of code would like a default value of a method to be used in another method inst

Re: [julia-users] Re: Unexpected behaviour when running parallelized code on single worker

In a sense, a SharedArray should act like an Array if you're using a single core. I'm not saying all methods have been implemented for them, but if the code runs then it certainly shouldn't give different answers. So I'd say this is a bug. So now that we know it's a bug, I'd urge you to file an

Re: [julia-users] Direct access to fields in a type, unjulian?

Nat and I once started on a mesh library which implements some of that: https://bitbucket.org/maurow/mesh.jl but it has gone a bit stale. In the spirit of Tim's response, it defines a big mesh datatype and then helper dataytpes, for instance Vertices, which are just a thin wrapper around the mesh.

Re: [julia-users] Re: Unexpected behaviour when running parallelized code on single worker

Apologies again for being a little slow (mentally now, not in terms of response time); by trying an Array you mean running the code in single-core mode and using an Array instead of a SharedArray? Running it in parallel with a regular Array (unsurprisingly) doesn't work. So I have: Single core:

Re: [julia-users] Re: Unexpected behaviour when running parallelized code on single worker

Sounds like a bug, but I think what Patrick was trying to say is that it would help to test it with Arrays first just to make sure there's not some problem with your code. Assuming that it works for Arrays but not for SharedArrays, then you should probably file an issue. Best, --Tim On Wednesd

Re: [julia-users] Direct access to fields in a type, unjulian?

It's a matter of taste, really, but in general I agree that the Julian way is to reduce the number of accesses to fields directly. That said, I do sometimes access the fields. However, your iterator example is a good opportunity to illustrate a more julian approach: mesh = mesh(...) for vertex

Re: [julia-users] Re: [ANN] JuliaIO and FileIO

No criticism intended, I just wanted to save you (or anyone else) time :-). I agree that it's also a great opportunity to refactor, and (without taking the time to think about it too deeply) your suggestions seem very reasonable. Best, --Tim On Wednesday, April 08, 2015 07:23:40 AM Simon Danisc

[julia-users] Re: [ANN] JuliaIO and FileIO

Excuse my ignorance Tim! I just don't allow myself to waste too much time on this, so that I'm not looking into things very deeply. This indeed solves the issue in a slightly different way. I think we can definitely reuse more of what Images is currently doing. It makes a lot of sense to switch ou

Re: [julia-users] A method with an optional parameter may result in a different method being called

> That is a bit surprising indeed. Maybe worth an addition to > > http://docs.julialang.org/en/latest/manual/methods/#note-on-optional-and-keyword-arguments > > ? > It's not only surprising, I'd consider it (absent a real reason why it should be this way) incorrect. Once you've decided whi

Re: [julia-users] A method with an optional parameter may result in a different method being called

On Wednesday, April 8, 2015 at 3:52:44 PM UTC+2, Mauro wrote: > > > On Wed, 2015-04-08 at 15:34, Daan Huybrechs > wrote: > > I was a little surprised today by the following behaviour: > > > > julia> f(d=2) = d > > f (generic function with 2 methods) > > > > julia> f(a::Int) = -a > > f (gene

Re: [julia-users] A method with an optional parameter may result in a different method being called

On Wed, 2015-04-08 at 15:34, Daan Huybrechs wrote: > I was a little surprised today by the following behaviour: > > julia> f(d=2) = d > f (generic function with 2 methods) > > julia> f(a::Int) = -a > f (generic function with 3 methods) > > julia> f() > -2 > > julia> methods(f) > # 3 methods for g

Re: [julia-users] Short question about type alias with partially known parameter types

Thank you for the code and the pull request link. Very interesting. On Tuesday, April 7, 2015 at 8:55:34 PM UTC+2, Mauro wrote: > > In 0.3 it's not possible in 0.4 this works: > > julia> type A{T,P} >a::T >end > > julia> typealias B{T} A{T, 1} > A{T,1} > > julia> call{T}(

[julia-users] Direct access to fields in a type, unjulian?

I come from a Python background where direct access to fields in for example classes with the dot notation is very common. However, from what I have seen in different conversations, accessing fields directly is not really Julian. Sort of a "fields are an implementation detail" mindset, and "wha

[julia-users] A method with an optional parameter may result in a different method being called

I was a little surprised today by the following behaviour: julia> f(d=2) = d f (generic function with 2 methods) julia> f(a::Int) = -a f (generic function with 3 methods) julia> f() -2 julia> methods(f) # 3 methods for generic function "f": f() at none:1 f(a::Int64) at none:1 f(d) at none:1 Ye

[julia-users] Re: Unexpected behaviour when running parallelized code on single worker

I understand *why* you're using them; the question is whether they're broken or not. One way to figure that out is to not use them and see if you still get the weird behavior. (No worries on the response speed, this is your issue after all!) On Wednesday, April 8, 2015 at 7:57:54 AM UTC-5, Nils

Re: [julia-users] Re: [ANN] JuliaIO and FileIO

Images has (I think) basically already solved this problem. The way it uses magic numbers is described at https://github.com/timholy/Images.jl/blob/master/doc/extendingIO.md For the example (a SIF) file, the magic bytes are enclosed in that b"Andor Technology Multi-Channel File" string. --Tim O

Re: [julia-users] Why enumerate and zip are realized by different types?

That implementation has a few drawbacks: it allocates a vector of indices the length of what it's iterating over; it has to know in advance how long what it's iterating over is; it is more complicated, leading to more complex machine code. On Wed, Apr 8, 2015 at 4:51 AM, Jinxuan Zhu wrote: > Rec

Re: [julia-users] Holt-Winters D-E Smoothing in Julia

Given the lack of replies, I'd guess that the answer is no. Searching "holt-winters julia jl" didn't turn up anything. Your options might be: * Use RCall to call the function in R. RCall is still rather young. * Use PyCall to call a function in Python. PyCall is fairly mature. * Implement your

[julia-users] Re: [ANN] JuliaIO and FileIO

This is half true. Magic numbers are only used in ImageMagick.jl per "accident", as that's how the underlying C-library does things. To be honest, I haven't looked at the details yet myself, as I mostly copy and pasted code to get a first prototype running. I sketch out in FileIO.jl#3

[julia-users] Re: Unexpected behaviour when running parallelized code on single worker

Hi Patrick, Sorry for the late reply (Easter and all that)! The problem with using Arrays in the code above is that they're not available for remote processes to write on, so I'd have to come up with a more complicated structure of passing computations and results around. The whole appeal of S

[julia-users] Re: Default behavior from omitted catch block when a finally block is added.

there is something to be said for the explicitness that comes with only catching exceptions when there is a catch keyword involved. Absolutely. Please go that way. It would be even better to make a "catch" mandatory with each "try", in order to ( as someone else here said ) ease the load on pr

Re: [julia-users] Re: Default behavior from omitted catch block when a finally block is added.

> If we require a 'catch' block for every "try", it would be cleaner. > Otherwise I suggest we had a note in the documentation to state the > caveats. Particularly for those who come from other background and get too > excited about "try end" terse syntax. I would be happy to make some edits >

[julia-users] Why enumerate and zip are realized by different types?

Recently, I am interested about the two functions enumerate(iter) and zip(iter). So I read the iterator.jl and find they are realized by different Types. I thought the enumerate was an alias like zip([1:length(a)], a), however it is not. I am curious that why the two functions are realized by tw

Re: [julia-users] Extreme garbage collection time

just a moment to applaud this exemplary thread !!! excellent closing post ... love the Julia community. best, cdm