[julia-users] Re: Custom Array type
Well you're right there, but inheriting from abstract array can't do magic. What you'd be asking for is, that inheriting from AbstractArray does some magic which can deal with any thinkable array type people can come up with. On the other hand, just defining 4-5 functions is not that much and you can then get quite a few functions for free than. Something what I've been wanting though is, that if the type is really pretty much the same just with another name, it should be possible to inherit all the functions. I opened an issue some time ago about this: https://github.com/JuliaLang/julia/issues/9821 As you can see, it's quite tricky to solve this cleanly. Am Samstag, 25. April 2015 13:50:52 UTC+2 schrieb Marcus Appelros: Consider the definitions: type Cubes:AbstractArray end sum(cubes::Cubes)=sum(convert(Array,cubes).^3) Is it possible to make this work? To create a custom array that has indexing and all at inception? Looked up the definition of Array and it is in the commented section on types implemented in C, its constructor is a ccall, if it isn't possible in pure julia would it be possible with C-code that doesn't prompt a rebuild?
[julia-users] Re: PyPlot : one plot after the other and not simultaneously
apologies ... rather than display below, i should have used figure; so, perhaps figure(1) and figure(2) will do what you need. On Saturday, April 25, 2015 at 9:00:27 AM UTC-7, cdm wrote: does using display(1) #display plot for y1 and display(2) #display plot for y2 get you what you were after?
Re: [julia-users] Re: Defining a function in different modules
3) inside my own namespace, modules continue to use exports but I have to implement SuperSecretBase modules managing my function collapses. (Or minimize the use of modules) However, it probably makes sense to define the meaning of your generic functions somewhere centrally. And this is also were the generic documentation should go, as opposed to having to hunt down the general documentation in different modules. I once opened a feature request that generic functions can be created without methods: https://github.com/JuliaLang/julia/issues/8283 This would fit with that approach.
Re: [julia-users] Re: Defining a function in different modules
Michael, that's not a bad summary. I would make a couple edits. You don't really need to qualify *all* uses. If you want to use `foo` from module `A`, you can put `import A.foo` at the top and then use `foo` in your code. That will have no surprises and no breakage. Also I think calling it SuperSecretBase makes it sound worse than it is. You can have modules that describe a certain named interface, and then other modules extend it. Which reminds me that I need to implement #8283, so you can introduce functions without adding methods yet. On Sat, Apr 25, 2015 at 12:31 PM, Stefan Karpinski ste...@karpinski.org wrote: Scott, I'm not really understanding your problem. Can you give an example? On Sat, Apr 25, 2015 at 11:53 AM, Scott Jones scott.paul.jo...@gmail.com wrote: A problem I'm running into is the following (maybe the best practice for this is documented, and I just to stupid to find it!): I have created a set of functions, which use my own type, so they should never be ambiguous. I would like to export them all, but I have to import any names that already exist... Then tomorrow, somebody adds that name to Base, and my code no longer works... I dislike having to explicitly import names to extend something, how am I supposed to know in advance all the other names that could be used? What am I doing wrong? On Saturday, April 25, 2015 at 11:20:14 AM UTC-4, Stefan Karpinski wrote: I think you're probably being overly optimistic about how infrequently there will be dispatch ambiguities between unrelated functions that happen to have the same name. I would guess that if you try to merge two unrelated generic functions, ambiguities will exist more often than not. If you were to automatically merge generic functions from different modules, there are two sane ways you could handle ambiguities: warn about ambiguities when merging happens; raise an error when ambiguous calls actually occur. Warning when the ambiguity is caused is how we currently deal with ambiguities in individual generic functions. This seems like a good idea, but it turns out to be extremely annoying. In practice, there are fairly legitimate cases where you can have ambiguous intersections between very generic definitions and you just don't care because the ambiguous case makes no sense. This is especially true when loosely related modules extend shared generic functions. As a result, #6190 has gained a lot of support. If warning about ambiguities in a single generic function is annoying, warning about ambiguities when merging different generic functions that happen share a name would be a nightmare. Imagine popular packages A and B both export a function `foo`. Initially there are no ambiguities, so things are fine. Then B adds some methods to its `foo` that introduce ambiguities with A's `foo`. In isolation A and B are both fine – so neither package author sees any warnings or problems. But suddenly every package in the ecosystem that uses both A and B – which is a lot since they're both very popular – is spewing warnings upon loading. Who is responsible? Package A didn't even change anything. Package B just added some methods to its own function and has no issues in isolation. How would someone using both A and B avoid getting these warnings? They would have to stop writing `using A` or `using B` and instead explicitly import all the names they need from either A or B. To avoid inflicting this on their users, A and B would have to carefully coordinate to avoid any ambiguities between all of their generic functions. Except that it's not just A and B – it's all packages. At that point, why have namespaces with exports at all? What if we only raise an error when making calls to `foo` that are ambiguous between `A.foo` and `B.foo`? This eliminates the warning annoyance, which is nice. But it makes code that uses A and B that calls `foo` brittle in dangerous ways. Suppose, for example, you call `foo(x,y)` somewhere and initially this can only mean `A.foo` so things are fine. But then you upgrade B, which adds a method to `B.foo` that also matches the call to `foo(x,y)`. Now your code that used to work will fail at run time – and only when invoked with ambiguous arguments. This case may be possible but rare and not covered by your tests. It's a ticking time bomb introduced into your code just by upgrading dependencies. The way this issue has actually been resolved, if you were using A and B and call `foo`, initially only is exported by A, as soon as package B starts exporting `foo`, you'll get an error and be forced to explicitly disambiguate `foo`. This is a bit annoying, but after you've done that, your code will no longer be affected by any changes to `A.foo` or `B.foo` – it's safe and permanently unambiguous. This still isn't 100% bulletproof. When `B.foo` is initially introduced, your code that used `foo`, expecting to call `A.foo`, will break when `foo` is called
Re: [julia-users] Newbie help... First implementation of 3D heat equation solver VERY slow in Julia
I think it is all the slicing that is killing the performance. Maybe something like arrayviews or the new sub stuff on 0.4 would help. Alternatively devectorizing into a bunch of nested loops. On Saturday, April 25, 2015 at 8:42:09 PM UTC+3, Stefan Karpinski wrote: Stick const in front of T and RHS. On Sat, Apr 25, 2015 at 11:32 AM, Tim Holy tim@gmail.com javascript: wrote: Did you read through http://docs.julialang.org/en/release-0.3/manual/performance-tips/? You should memorize :-) the sections up through the Tools section; the rest you can consult as you discover you need them. --Tim On Saturday, April 25, 2015 01:03:38 AM Ángel de Vicente wrote: Hi, a complete Julia newbie here... I spent a couple of days learning the syntax and main aspects of Julia, and since I heard many good things about it, I decided to try a little program to see how it compares against the other ones I regularly use: Fortran and Python. I wrote a minimal program to solve the 3D heat equation in a cube of 100x100x100 points in the three languages and the time it takes to run in each one is: Fortran: ~7s Python: ~33s Julia:~80s The code runs for 1000 iterations, and I'm being nice to Julia, since the programs in Fortran and Python write 100 HDF5 files with the complete 100^3 data (every 10 iterations). I attach the code (and you can also get it at: http://pastebin.com/y5HnbWQ1) Am I doing something obviously wrong? Any suggestions on how to improve its speed? Thanks a lot, Ángel de Vicente
Re: [julia-users] Re: Defining a function in different modules
I'd love to see interfaces in general, especially for things like iteration. If I implement a base interface for my type I'd like to be able to assert that it is fully implemented. Check out Traits.jl (is getting reasonably stable, although I haven't updated it to post #10380 Julia).
Re: [julia-users] Re: Qwt plotting
On Saturday, April 25, 2015 09:43:20 AM Andreas Lobinger wrote: Can you give more details? I think I once posted some profiling results in some Winston or base julia issue. --Tim
Re: [julia-users] Re: Custom Array type
https://github.com/JuliaLang/julia/pull/3292;
Interesting, has it been implemented now?
No, check the bottom of the thread. But you can just use the macro:
https://github.com/JuliaLang/julia/pull/3292/files
Maybe there is a more efficient method, since we are getting further
away from the definition of Array by adding a data field, the
commented source version is empty as in the OP, so when the
constructor calls C it is storing the identifier Array somewhere. We
can create a identical constructor with the difference that it accepts
a keyword for what to write in place of Array.
On 25/04/2015, Mauro mauro...@runbox.com wrote:
On Sat, 2015-04-25 at 19:55, Marcus Appelros marcus.appel...@gmail.com
wrote:
Feels somehow sufficient to direct all functions to the data field. We can
have a macro like
@foranyfunction f(c::Cubes,a::AnyArgs)=f(c.data,a)
https://github.com/JuliaLang/julia/pull/3292
What you really want to be able to do is delegate everything to the .data
member, but there's no convenient way to do that
There are some existing macros that take a list of functions and define
them on a type, we can wrap a macro that acts on all functions in
methods(T).
Or allow inheriting from concrete types.
Or allow specifying abstract types like AbstractArray{T,N}.
Re: [julia-users] Re: Defining a function in different modules
My point is, if I have been careful, and export methods that always reference at least one of type defined locally in my module, so that they should always be unambiguous, I should NOT have to know about any other module (or Base) that a user of my module might also be using having a function with the same name, and should NOT have to do an import. For methods where I *am* trying to extend some type defined in another module/package or base, then yes, I believe you should do something explicitly to indicate that. I don't think there is any real conflict here... right now it is too restrictive when the module's programmer has clearly signaled their intent by always using their own, unambiguous signitures for their functions. Have I got something fundamentally wrong here? Thanks, Scott On Saturday, April 25, 2015 at 2:10:25 PM UTC-4, Jeff Bezanson wrote: Scott, the behavior you're trying to get sounds to me like IF this function exists in Base then I want to extend it, otherwise just make my own version of the function. That strikes me as a hack. What we've tended to do is let everybody define whatever they want. Then if we see the same name appearing in multiple packages, we decide if there is indeed a common interface, and if so move the packages to using it, e.g. by creating something like StatsBase or maybe adding something to Base. But we don't want Base to grow much more, if at all. Getting an error for using both Base and your package seems annoying, but alternatives that involve doing something silently surely must be considered worse. If a colliding name gets added to Base, the default behavior should not be to assume that you meant to interfere with its behavior. On Sat, Apr 25, 2015 at 1:57 PM, Jeff Bezanson jeff.b...@gmail.com javascript: wrote: Michael, that's not a bad summary. I would make a couple edits. You don't really need to qualify *all* uses. If you want to use `foo` from module `A`, you can put `import A.foo` at the top and then use `foo` in your code. That will have no surprises and no breakage. Also I think calling it SuperSecretBase makes it sound worse than it is. You can have modules that describe a certain named interface, and then other modules extend it. Which reminds me that I need to implement #8283, so you can introduce functions without adding methods yet. On Sat, Apr 25, 2015 at 12:31 PM, Stefan Karpinski ste...@karpinski.org javascript: wrote: Scott, I'm not really understanding your problem. Can you give an example? On Sat, Apr 25, 2015 at 11:53 AM, Scott Jones scott.pa...@gmail.com javascript: wrote: A problem I'm running into is the following (maybe the best practice for this is documented, and I just to stupid to find it!): I have created a set of functions, which use my own type, so they should never be ambiguous. I would like to export them all, but I have to import any names that already exist... Then tomorrow, somebody adds that name to Base, and my code no longer works... I dislike having to explicitly import names to extend something, how am I supposed to know in advance all the other names that could be used? What am I doing wrong? On Saturday, April 25, 2015 at 11:20:14 AM UTC-4, Stefan Karpinski wrote: I think you're probably being overly optimistic about how infrequently there will be dispatch ambiguities between unrelated functions that happen to have the same name. I would guess that if you try to merge two unrelated generic functions, ambiguities will exist more often than not. If you were to automatically merge generic functions from different modules, there are two sane ways you could handle ambiguities: warn about ambiguities when merging happens; raise an error when ambiguous calls actually occur. Warning when the ambiguity is caused is how we currently deal with ambiguities in individual generic functions. This seems like a good idea, but it turns out to be extremely annoying. In practice, there are fairly legitimate cases where you can have ambiguous intersections between very generic definitions and you just don't care because the ambiguous case makes no sense. This is especially true when loosely related modules extend shared generic functions. As a result, #6190 has gained a lot of support. If warning about ambiguities in a single generic function is annoying, warning about ambiguities when merging different generic functions that happen share a name would be a nightmare. Imagine popular packages A and B both export a function `foo`. Initially there are no ambiguities, so things are fine. Then B adds some methods to its `foo` that introduce ambiguities with A's `foo`. In isolation A and B are both fine – so neither package author sees any warnings or problems. But suddenly every
[julia-users] Re: Set construction
How about using a dictionary of vectors?
i.e.
T_GENERATING_BUS = Dict()
for k in BUS
for j=1:gmax
if BUS_T[j] == k
if k in keys(T_GENERATING_BUS)
push!(T_GENERATING_BUS[k], j)
else
T_GENERATING_BUS[k] = [j]
end
end
end
end
On Saturday, April 25, 2015 at 5:17:16 PM UTC-4, Fabrizio wrote:
Thanks Jemeson,
but it seems not enough, indeed T_GENERATING_BUS must be a collection of k
(=maximum(BUS)) but also with enough space to contain an - unknown a priori
- number of Power_Gen attached to it. Moreover if i change the code as
suggested i get the following error
ERROR: `convert` has no method matching convert(::Type{Set{Any}},
::Array{Any,1})
Fabrizio
On Saturday, April 25, 2015 at 8:41:56 PM UTC+2, fabrizio@gmail.com
wrote:
Hi, very newby in Julia/JuMP, my problem is
i have a set of power gen and attached nodes in a grid in this format
PowerGen_ID Node
1 1
2 2
3 1
4 2
i would like to construct a set T_GENERATING_BUS for each node that
contains the Power Gen attached to it
i.e.
T_GENERATING_BUS[1]={1,3};
T_GENERATING_BUS[2]={2,4};
i tried something like:
T_GENERATING_BUS = Set[]
for k in BUS
for j=1:gmax
if BUS_T[j] == k
T_GENERATING_BUS[k] = union(T_GENERATING_BUS[k],j)
end
end
end
but got an error bound
ERROR: BoundsError()
in getindex at array.jl:246 (repeats 2 times)
while loading E:\CodiciSorgente\ProgrammiJulia\UCOTS.jl, in expression
starting on line 101
the problem is that i don't know how to increase the dim of
T_GENERATING_BUS
Any hints?
Thanks
Fabrizio
[julia-users] Re: Is there a canonical method name for first and last index of a collection?
I think it should be ``` start() endof() ``` On Friday, April 24, 2015 at 12:14:26 PM UTC+2, Tomas Lycken wrote: I'm implementing a collection of types that implement indexing, but where the indexes aren't necessarily bounded by `[1, size(collection, dim)]`. Some of them will have these bounds, but others will be indexable e.g. in `[0.5, size(collection, dim) + .5]` and yet others may have completely arbitrary bounds. Is there a canonical name for methods that would return (the upper/lower) bounds for indexing? I am thinking along the lines of ```julia lowerbound(v::Vector) = 1 upperbound(v::Vector) = length(v) bounds(v::AbstractVector) = (lowerbound(v), upperbound(v)) lowerbound(A::Array, d::Int) = 1 upperbound(A::Array, d::Int) = size(A, d) bounds(A::AbstractArray, d::Int) = (lowerbound(A, d), upperbound(A, d)) #etc... ``` but I'd rather add methods to an existing function, if there is one, than just make up my own. (I did try a few searches in the docs, but everything I could find pertained to finding elements in collections...) // T
Re: [julia-users] Re: Defining a function in different modules
I think the key issue is your: I believe they should be able to use both, as long as there aren't any real conflicts, *without* spurious warnings... As Jeff said, the problem is aren't any real conflicts is not possible to determine in all cases, and can be costly in others. And IIUC its not possible to know ahead of time if it can be determined. So because its not practically possible to protect against problematic situations, Julia plays it safe and complains about all situations. Cheers Lex
Re: [julia-users] Re: Defining a function in different modules
The compiler can't determine that there are no conflicts in the case where the method uses a type that is local to the module? That is the *only* case where I am saying that it should not be necessary to have an import Base.bar or import Foo.bar if I want to export a function and have it available at a higher level, and not have to worry that later on somebody adding bar to Base or Foo will cause my module to stop working? What if I had a getsockname function? ;-) That name was just added to Base tonight apparently... so my code would break... Not good! On Saturday, April 25, 2015 at 7:49:33 PM UTC-4, ele...@gmail.com wrote: I think the key issue is your: I believe they should be able to use both, as long as there aren't any real conflicts, *without* spurious warnings... As Jeff said, the problem is aren't any real conflicts is not possible to determine in all cases, and can be costly in others. And IIUC its not possible to know ahead of time if it can be determined. So because its not practically possible to protect against problematic situations, Julia plays it safe and complains about all situations. Cheers Lex
[julia-users] 3rd Julia meetup in Japan: JuliaTokyo #3
Hi, Today we had our 3rd Julia meetup in Japan, JuliaTokyo #3. 40 people, 16 presenters, good vibes. Here's the list of presentation slides; http://juliatokyo.connpass.com/event/13218/presentation/ We also created a website ( http://julia.tokyo/ ) and a repository for discussions ( https://github.com/JuliaTokyo/julia-wakalang/issues ). --- JuliaTokyo #3 Presentation List in English # Main Talks 1. julia-doc translation, design patterns by julia, C wrapper - @ohtaman, et al. 2. Make Julia more popular in Japan!! - @chezou 3. Deep learning sequence models (Deep RNN LSTMs) in #julialang - @QuantixResearch 4. On Macros - @yomichi_137 5. Construction and evaluation of machine learning models by Julia - @sfchaos # Lightning Talks 1. Preprocessing with Julia - @weda_654 2. What's wrong with this Julia? - @bicycle1885 3. W2vUtils.jl - @mrkn 4. Speech signal processing with Julia - @r9y9 5. Data Science Packages - @yutajuly 6. (missed the title) - naoya_ikeda 7. Pythonista tries Julia with Jupyter - @iktakahiro 8. SVM with Julia - @uk24s 9. Cooking with Julia - @nozawa0301 10. Mecha Joshi Shogi (AI Japanese chess) - @kimrin 11. MsgPackRpcClient.jl: live pull-request - @keithseahus --- We also had a survey on what kind of languages and softwares people use on a daily basis. 75 answers (multiple choices allowed); language, #people Python, 49 R, 35 C++, 19 Excel, 18 Java, 18 Others, 17 C, 14 Julia, 14 Ruby, 14 Matlab, 6 Perl, 5 Scala, 5 Go, 4 F#, 3 Clojure, 2 Mathematica, 1 - sorami
[julia-users] Re: Bioinformatics in Julia
I don't know the status of the tools, but there is active development at the BioJulia GitHub organization https://github.com/BioJulia On Saturday, April 25, 2015 at 8:08:16 PM UTC+3, Tim K wrote: Dear All, I am finishing a bioengineering postdoc soon, and am looking to learn some bioinformatics. Accordingly, I was wondering what the status of bioinformatics tools for Julia is? (I would post in the biojulia-dev group, but it has not been updated since July 2014.) Cheers, Tim.
[julia-users] Use Light Table to run Julia is very slow
I use Light Table to run Julia, I found it is very slow compares to Juno. When I type some words, I even need to wait for few seconds. Since Light Table could also run Python and LiteX as well as Julia, I prefer to use Light Table if it could be as faster as Juno. Anyone has the similar problem?
[julia-users] Set construction
Hi, very newby in Julia/JuMP, my problem is
i have a set of power gen and attached nodes in a grid in this format
PowerGen_ID Node
1 1
2 2
3 1
4 2
i would like to construct a set T_GENERATING_BUS for each node that
contains the Power Gen attached to it
i.e.
T_GENERATING_BUS[1]={1,3};
T_GENERATING_BUS[2]={2,4};
i tried something like:
T_GENERATING_BUS = Set[]
for k in BUS
for j=1:gmax
if BUS_T[j] == k
T_GENERATING_BUS[k] = union(T_GENERATING_BUS[k],j)
end
end
end
but got an error bound
ERROR: BoundsError()
in getindex at array.jl:246 (repeats 2 times)
while loading E:\CodiciSorgente\ProgrammiJulia\UCOTS.jl, in expression
starting on line 101
the problem is that i don't know how to increase the dim of T_GENERATING_BUS
Any hints?
Thanks
Fabrizio
[julia-users] Julia in LightTable is slow
I want to use LightTable instead of Juno because I could run python, Julia, LaTex (LiTeX) at the same time. However, I found when I use Julia in LightTable, the typing becomes very slow. When I type a word, I may need to wait several seconds. Anyone has similar problem?
[julia-users] Re: Set construction
Hi Fabrizio,
One of the variables (pt, node_load, or p_flow) is having a problem with a
missing key possibly. Without seeing the whole code its very hard to say
for sure.
Thanks,
Iain
On Saturday, April 25, 2015 at 5:45:29 PM UTC-4, Fabrizio wrote:
Thanks Iain,
this seems to work, at least in the costruction, but i have to deepen the
various commands. However...since i have to use this object in a cns like
that, you can - certainly - give me an hint since i get an error
ERROR: key not found: 3
sorry I am an old C++ guy
for h=1:hmax
for k in BUS
@addConstraint(mod, sum{pt[j,h], j in T_GENERATING_BUS[k]}
-node_load[k,h] == sum{p_flow[(n,b_from,b_to),h],(n,b_from,b_to) in
BRANCH}-sum{p_flow[(n,b_to,b_from),h],(n,b_to,b_from) in BRANCH})
end
end
On Saturday, April 25, 2015 at 8:41:56 PM UTC+2, Fabrizio wrote:
Hi, very newby in Julia/JuMP, my problem is
i have a set of power gen and attached nodes in a grid in this format
PowerGen_ID Node
1 1
2 2
3 1
4 2
i would like to construct a set T_GENERATING_BUS for each node that
contains the Power Gen attached to it
i.e.
T_GENERATING_BUS[1]={1,3};
T_GENERATING_BUS[2]={2,4};
i tried something like:
T_GENERATING_BUS = Set[]
for k in BUS
for j=1:gmax
if BUS_T[j] == k
T_GENERATING_BUS[k] = union(T_GENERATING_BUS[k],j)
end
end
end
but got an error bound
ERROR: BoundsError()
in getindex at array.jl:246 (repeats 2 times)
while loading E:\CodiciSorgente\ProgrammiJulia\UCOTS.jl, in expression
starting on line 101
the problem is that i don't know how to increase the dim of
T_GENERATING_BUS
Any hints?
Thanks
Fabrizio
[julia-users] Re: Custom Array type
On Saturday, April 25, 2015 at 12:05:04 PM UTC-5, Marcus Appelros wrote: Which is exactly what should be possible to avoid, if we anyhow have to define all the functions what is the meaning in descending from AbstractArray? The usefulness of having an abstract Component is to make concrete instances that retain all the abstract functionality. There is no generic way to implement all these methods, though. In a traditional object-oriented environment, these would be abstract methods--define these and then you can get more things for free. There is a generic implementation of `length()` you can get if you define `size()`: length(t::AbstractArray) = prod(size(t))::Int I believe you get `eltype()` and `ndims()` for free, too, looking at the definitions in abstractarray.jl.
Re: [julia-users] Re: Custom Array type
On Sat, 2015-04-25 at 19:55, Marcus Appelros marcus.appel...@gmail.com wrote:
Feels somehow sufficient to direct all functions to the data field. We can
have a macro like
@foranyfunction f(c::Cubes,a::AnyArgs)=f(c.data,a)
https://github.com/JuliaLang/julia/pull/3292
What you really want to be able to do is delegate everything to the .data
member, but there's no convenient way to do that
There are some existing macros that take a list of functions and define
them on a type, we can wrap a macro that acts on all functions in
methods(T).
Or allow inheriting from concrete types.
Or allow specifying abstract types like AbstractArray{T,N}.
Re: [julia-users] Re: Need help/direction on how to optimize some Julia code
Please do read the docs, they are quite thorough: http://docs.julialang.org/en/release-0.3/manual/profile/ You should run your code once before you profile, so you don't get all those calls to inference. As I'm sure you noticed, it makes the output hard to read. Also check out ProfileView.jl. But yes, you identified some bottleneck lines. I don't know that part of julia at all, though, so I'll defer to others. --Tim On Saturday, April 25, 2015 10:50:43 AM Harry B wrote: Here is the output of Profile.print() https://github.com/harikb/scratchpad1/blob/master/julia2/run3.txt I don't know how to interpret these results, but I would guess this is where the most time is spent 10769 stream.jl; stream_wait; line: 263 10774 stream.jl; readavailable; line: 709 10774 stream.jl; wait_readnb; line: 316 Is the issue that stream.jl is reading byte by byte? If a Content-Length is available in the response header (and I know it is), it should probably read as one chunk. Again, I am throwing a dart in the dark. So I should probably stop speculating. Any help is appreciated on the next steps -- Harry On Thursday, April 23, 2015 at 5:52:09 PM UTC-7, Tim Holy wrote: I think it's fair to say that Profile.print() will be quite a lot more informative---all you're getting is the list of lines visited, not anything about how much time each one takes. --Tim On Thursday, April 23, 2015 04:19:08 PM Harry B wrote: I am trying to profile this code, so here is what I have so far. I added the following code to the path taken for the single-process mode. I didn't bother with the multi-process once since I didn't know how to deal with @profile and remotecall_wait @profile processOneFile(3085, 35649, filename) bt, lidict = Profile.retrieve() println(Profiling done) for (k,v) in lidict println(v) end Output is here https://github.com/harikb/scratchpad1/blob/master/julia2/run1.txt (Ran with julia 0.3.7) another run https://github.com/harikb/scratchpad1/blob/master/julia2/run2.txt (Ran with julia-debug 0.3.7) - in case it gave better results. However, there is quite a few lines marked without line or file info. On Wednesday, April 22, 2015 at 2:44:13 AM UTC-7, Yuuki Soho wrote: If I understand correctly now you are doing only 5 requests at the same time? It seems to me you could do much more. But that hides the inefficiency, whatever level it exists. The Go program also uses only 5 parallel connections. On Wednesday, April 22, 2015 at 1:15:20 PM UTC-7, Stefan Karpinski wrote: Honestly, I'm pretty pleased with that performance. This kind of thing is Go's bread and butter – being within a factor of 2 of Go at something like this is really good. That said, if you do figure out anything that's a bottleneck here, please file issues – there's no fundamental reason Julia can't be just as fast or faster than any other language at this. Stefan, yes, it is about 2x if I subtract the 10 seconds or so (whatever it appears to me) as the startup time. I am running Julia 0.3.7 on a box with a deprecated GnuTLS (RHEL). The deprecation warning msg comes about 8 seconds into the run and I wait another 2 seconds before I see the first print statement from my code (Started N processes message). My calculations already exclude these 10 seconds. I wonder if I would get better startup time with 0.4, but Requests.jl is not compatible with it (nor do I find any other library for 0.4). I will try 0.4 again and see I can fix Requests.jl Any help is appreciated on further analysis of the profile output. Thanks The use of Requests.jl makes this very hard to benchmark accurately since it introduces (non-measurable) dependencies on network resources. If you @profile the function, can you tell where it's spending most of its time? On Tuesday, April 21, 2015 at 2:12:52 PM UTC-7, Harry B wrote: Hello, I had the need to take a text file with several million lines, construct a URL with parameters picked from the tab limited file, and fire them one after the other. After I read about Julia, I decided to try this in Julia. However my initial implementation turned out to be slow and I was getting close to my deadline. I then kept the Julia implementation aside and wrote the same thing in Go, my other favorite language. Go version is twice (at least) as fast as the Julia version. Now the task/deadline is over, I am coming back to the Julia version to see what I did wrong. Go and Julia version are not written alike. In Go, I have just one main thread
[julia-users] Re: Bioinformatics in Julia
Thanks guys. Would you say that it's suitable for a newbie, or should I stick with MATLAB or python? On Saturday, 25 April 2015 20:12:08 UTC+2, Daniel Jones wrote: Don't let the lack of activity on the mailing list fool you, it is being actively developed. We just mostly communicate in github issues and on gitter. Browsing the pending PRs in Bio.jl is a good way to get a sense of what's happening: https://github.com/BioJulia/Bio.jl/pulls On Saturday, April 25, 2015 at 10:08:16 AM UTC-7, Tim K wrote: Dear All, I am finishing a bioengineering postdoc soon, and am looking to learn some bioinformatics. Accordingly, I was wondering what the status of bioinformatics tools for Julia is? (I would post in the biojulia-dev group, but it has not been updated since July 2014.) Cheers, Tim.
Re: [julia-users] Re: Defining a function in different modules
I think lindahua had it right: Generally, conflicting extensions of methods are a natural consequence of allowing packages to evolve independently (which we should anyway). It is unavoidable as the eco-system grows (even if we address such the Images + DataArrays problem by other means). If this coupling over packages cannot be addressed in a scalable way, it would severely influence the future prospect of Julia to become a mainstream language. Right now, Julia already has a big mess of overloaded operators and function names that aren't really exactly the same interface... (* and ^ on strings, for example, or ~ in DataFrames :-) ). I do have a lot of experience of how code changes over time ;-) But no, I did not assume that signatures wouldn't change within a package, not at all. My suggestion doesn't break as signatures change... as long as you've, as the package/module creator, have used one of your types, so that you know that things are unambiguous, then things don't break no matter how the signatures of my functions change... Your method means that users are forced to 1) not use using on packages with coincidentally conflicting names and specify everything with the package/module name, or 2) force one of the package developers (if they are even still around) to change their package to avoid conflicting with somebody else's package's names, which will requires users to remember to always use package A before package B (B being the one that had to change their package)... You also seem to think that the only dynamic use of the language will be in the REPL... If I write a system that can dynamically load Julia code from a database and execute it, where are all these warning messages going to be going? Here's another thought: Developer A makes a nice database binding package, with 20 different functions. Developer B totally independently makes a new database binding package, that, because people in the same area are likely to pick similar names, has 3 names (with totally different signatures). Developer C comes along (me), and needs to use both packages... say A for the data sources and B for the backing store... Why should I not be able to use using A using B or using B using A, without worrying that they coincidentally used a few names that conflict, and not have to try to get A B together to come up with some common interface... Remember, I am talking about something that I think would be pretty easy to determine, which somebody else had suggested somewhere here (i.e. using the fact that a type local to the module was in the signature), to say that you don't need the import name if you are exporting a function. I am not talking about never having to do the import name, nor ever having the warnings in the case where you are creating a method on types outside of the module. To me, the fact that you have had to go to this SuperSecretBase points out the problems with the current design... Scott On Saturday, April 25, 2015 at 5:06:04 PM UTC-4, Jeff Bezanson wrote: The reason for it not to work is that we have two different concepts that happen to be spelled the same. To me you're just describing inherent problems with name conflicts and agreeing on interfaces. Having a single method namespace is hardly a magic bullet for that. It seems to require just as much coordination. In Python again, two people might develop socket libraries that implement connect, but one uses foo.connect(address, port) and the other uses bar.connect(port, address). At that point, you absolutely have to get the two developers to agree on one interface so that people can use both, and say x.connect() where x might be either foo or bar. If the libraries can't be changed, you can write shims to make them compatible. But you can do the same thing in julia. In julia the disaster is no bigger than usual. Quite rightly, you are focusing on how code changes over time, and what problems that might cause. But your design focuses on adding functions, and assumes signatures don't change as much and have a particular structure (i.e. typically referring directly to a type defined in the same module). If those assumptions hold, I agree that it could work very well. But it breaks as signatures change, while our design breaks as export lists change. I prefer our tradeoff because method signatures are far more subtle. Comparing method signatures is computationally difficult (exponential worst case!), while looking for a symbol in a list is trivial. Warnings for name conflicts may be annoying, but at least it's dead obvious what's happening. If a subtle adjustment to a signature affects visibility elsewhere, I'd think that would be much harder to track down. On Sat, Apr 25, 2015 at 4:24 PM, Scott Jones scott.pa...@gmail.com javascript: wrote: On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote: I think this is
[julia-users] How long will it take to build v0.4 if I already have built a v0.3
I built Julia v0.3 from the source code. It took me a lot of time. Now if I want to git checkout v0.4, will it take me a lot of time to build again?
Re: [julia-users] Re: Defining a function in different modules
I don't think Any in the same position is a conflict. This would be more of an issue if Julia did not support strong typing, but it does and is a requirement of dynamic dispatch. Consider function foo( x::Any ) Will never be chosen over Type Foo end function foo( x::Foo ) As such I don't get the argument that if I define functions against types I define they cause conflicts. Being in the position of having implemented a good number of modules and being bitten in this way both by my own dev and by changes to other modules I'm very concerned with the direction being taken. I do think formalization of interfaces to modules ( and behaviors) would go a long way but expecting a diverse group of people to coordinate is not going to happen without strong and enforced constructs. As an example I have implemented a document store database interface, this is well represented by an associative collection. It also has a few specific methods which would apply to many databases. It would be nice to be able to share the definition of these common interfaces. I don't advocate adding these to base so how should it be done?
Re: [julia-users] Re: Qwt plotting
I just did some quick/simple plots in my module (calling PyQwt) and PyPlot (calling matplotlib). The UI was a little more responsive with qwt, but I couldn't see any major speed improvements, and I was able to zoom/pan in both. In order to reduce fragmentation, I won't move this into a standalone package. I may, however, give matplotlib another chance and try to figure out whether that can meet my needs (and maybe remember why I switched in the first place).
Re: [julia-users] Re: Custom Array type
https://github.com/JuliaLang/julia/pull/3292;
Interesting, has it been implemented now?
Maybe there is a more efficient method, since we are getting further
away from the definition of Array by adding a data field, the
commented source version is empty as in the OP, so when the
constructor calls C it is storing the identifier Array somewhere. We
can create a identical constructor with the difference that it accepts
a keyword for what to write in place of Array.
On 25/04/2015, Mauro mauro...@runbox.com wrote:
On Sat, 2015-04-25 at 19:55, Marcus Appelros marcus.appel...@gmail.com
wrote:
Feels somehow sufficient to direct all functions to the data field. We can
have a macro like
@foranyfunction f(c::Cubes,a::AnyArgs)=f(c.data,a)
https://github.com/JuliaLang/julia/pull/3292
What you really want to be able to do is delegate everything to the .data
member, but there's no convenient way to do that
There are some existing macros that take a list of functions and define
them on a type, we can wrap a macro that acts on all functions in
methods(T).
Or allow inheriting from concrete types.
Or allow specifying abstract types like AbstractArray{T,N}.
Re: [julia-users] Re: Defining a function in different modules
When two people write packages independently, I claim there are only two options: (1) they implement a common interface, (2) they don't. To pick option (1), there has to be some kind of centralization or agreement. For option (2), which is effectively the default, each package just gets its own totally separate function, and you have to say which one you want. We're not saying you'd better get together with all other developers, because with option (2) you don't need to. IIUC, you're proposing option (3), automatically merge everybody's methods, assuming they don't conflict. But I don't see how this can work. We could have: module A type AConnectionManager end function connect(cm::AConnectionManager, port, address) end end module B type BConnectionManager end function connect(cm::BConnectionManager, address, port) end end Obviously, you cannot do `using A; using B`, and then freely use `connect` and have everything work. The fact that the type of the first argument distinguishes methods doesn't help. The rest of the arguments don't match, and even if they did the behaviors might not implement compatible semantics. The only options I see are my options 1 and 2: (1) move to a common interface, or (2) specify A.connect or B.connect in client code, because the interfaces aren't compatible. On Sat, Apr 25, 2015 at 5:55 PM, Scott Jones scott.paul.jo...@gmail.com wrote: The problem is, in practice, people *will* have names that collide, and will not mean the same thing. It seems that people here are trying to say, if you have a particular name you'd like to use, you'd better get together with all other developers past and future and hammer out who owns the name, and what concept it can be used for... (like mathematical sin and fun sin, or tree bark and dogs bark... it gets even worse when you consider other languages... [Say I'm in Spain, and I write a robotics package that has a function coger..., and somebody in Argentina writes a function coger that does something, well, XXX...]) I just don't see this as working for any length of time (and I think it is already breaking down with Julia... to me, the fact that DataFrames picked using ~ as a binary operator, when that might have been something that somebody wanted to use in the core language, shows how fragile things are now...) Scott On Saturday, April 25, 2015 at 5:27:10 PM UTC-4, Mauro wrote: I don't think it is realistic to expect be able to willy-nilly be 'using' any number of packages and it just works. The way you propose may work most of the time, however, there were some solid arguments made in this thread on how that can lead to hard to catch failures. And maybe more importantly, from a programmer's sanity perspective, I think it is imperative that one generic function does just one conceptual thing. Otherwise it gets really hard to figure out what a piece of code does. On Sat, 2015-04-25 at 22:24, Scott Jones scott.pa...@gmail.com wrote: On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote: I think this is just a different mindset than the one we've adopted. In the mindset you describe, there really *ought* to be only one function with each name, in other words a single global namespace. As long as all new definitions for a function have disjoint signatures, there are no conflicts. To deal with conflicts, each module has its own view of a function that resolves conflicts in favor of its definitions. As a practical point, *why* should I have to know about every other package or module that users of my package might possibly want to use at the same time? With the way it is now, it seems I have to force everybody to not use using, and use fully specified names, which seems utterly against the extensibility of Julia, because if I try to export a function, I must know the intentions of every user, which packages they might load, etc. that might possibly have the same name. I have a module that defines a packed database format, and I want to define a length, push!, and getindex methods... Then (for examples sake) I also want to define a foobar method that people can use, and be able to call it on objects from my module with just foobar(db,arg1,arg2) (where db is from my class). All is well and good, but then some user complains that they can't use my package and package newdb, because coincidentally they also defined a function called foobar, that does have a different signature. I believe they should be able to use both, as long as there aren't any real conflicts, *without* spurious warnings... This approach has a lot in common with class-based OO. For example in Python when you say `x.sin()`, the `sin` name belongs to a single method namespace. Sure there are different namespaces for *top level* definitions, but not for method names. If you want a different `sin` method, you need to make a new class,
[julia-users] Re: PyPlot : one plot after the other and not simultaneously
i may be able to try this from the REPL later today ... in the meantime, what is the result of using PyCall pygui() on your Julia setup? On Saturday, April 25, 2015 at 3:23:32 PM UTC-7, Ferran Mazzanti wrote: Surpsisingly that didn't work either, but shows a strange ehaviour instead: three figure frames (figure boxes) are opened: figure 1 has once again both plots merged, while figures 2 and 3 show the canvas with nothin (fig.3) and the canvas with the axes (fig.2), but the plots themselves are merged in fig.1 as I mentioned (?)... Have you tried that form the command line REPL? That seems to be different from the IJulia notebook behavior...
Re: [julia-users] Re: Ode solver thought, numerical recipes
Keep the type annotations in the EulerSolver type declaration, but get rid of
all of them in your functions. Then read
http://docs.julialang.org/en/release-0.3/manual/performance-tips/,
try the profiler (use ProfileView.jl to inspect the results), and see if you
can
figure out what's wrong. (Bottom line is you likely have a type-instability.)
Best,
--Tim
On Saturday, April 25, 2015 04:58:49 PM François Fayard wrote:
Hi,
Here is a first shot at the program (My first Julia program). It seems that
I don't get good performance (46% of time spent in gc). What is the reason
for that?
type EulerSolver
f::Function
t0::Float64
y0::Vector{Float64}
delta_t::Float64
delta_t_save::Float64
t_right::Vector{Float64}
y_right::Vector{Vector{Float64}}
t_left::Vector{Float64}
y_left::Vector{Vector{Float64}}
end
function ode_solver(f, t0::Float64, y0::Vector{Float64}, delta_t::Float64,
delta_t_save::Float64)
solver = EulerSolver(f, t0, y0, delta_t, delta_t_save, [], [], [], [])
return solver
end
function evaluate(solver::EulerSolver, t_final::Float64)
t::Float64
y::Vector{Float64}
if length(solver.t_right) 0
if t_final = solver.t_right[length(solver.t_right)]
t = solver.t_right[length(solver.t_right)]
y = solver.y_right[length(solver.y_right)]
elseif t_final solver.t_right[1]
t = solver.t0
y = solver.y0
else
k = 1
while t = solver.t_right[k]
k += 1
end
t = solver.t_right[k]
y = solver.y_right[k]
end
else
t = solver.t0
y = solver.y0
end
last_t_saved::Float64 = t
delta_t::Float64 = solver.delta_t
dy_dt::Vector{Float64} = zeros(y)
is_finished::Bool = false
while !is_finished
if t + delta_t t_final
delta_t = t_final - t
is_finished = true
end
f!(dy_dt, t, y)
for k = 1:length(y)
y[k] = y[k] + delta_t * dy_dt[k]
end
t = t + delta_t
if abs(t - last_t_saved) = solver.delta_t_save
println(Save)
last_t_saved = t
push!(solver.t_right, t)
push!(solver.y_right, deepcopy(y))
end
end
return y
end
function f!(dy_dt::Vector{Float64}, t::Float64, y::Vector{Float64})
dy_dt[1] = y[1]
end
t0 = 0.0
y0 = [ 1.0 ]
delta_t = 1.0e-8
delta_t_save = 1.0
solver = ode_solver(f!, t0, y0, delta_t, delta_t_save)
@time println(evaluate(solver, 3.12))
Re: [julia-users] Re: Defining a function in different modules
On Sunday, April 26, 2015 at 10:12:51 AM UTC+10, Scott Jones wrote: The compiler can't determine that there are no conflicts in the case where the method uses a type that is local to the module? That is not a sufficient condition, a function of the same name which uses ::Any in the same parameter position can conflict IIUC. That is the *only* case where I am saying that it should not be necessary to have an import Base.bar or import Foo.bar if I want to export a function and have it available at a higher level, and not have to worry that later on somebody adding bar to Base or Foo will cause my module to stop working? As the module writer you have no control over how your module is used, you shouldn't be trying to enforce that your functions don't conflict since that implies a knowledge of the uses of your module. The user of your module is the only one that knows which function they mean, they have to tell the compiler, not you. What if I had a getsockname function? ;-) That name was just added to Base tonight apparently... so my code would break... Not good! It should break, the compiler cannot in general know if there are no conflicts, and IIUC *cannot even know if it can determine it efficiently*. Yes you can give examples where it would safely work, but if the compiler cannot check that without potentially entering an expensive computation, then it simply cannot check at all. On Saturday, April 25, 2015 at 7:49:33 PM UTC-4, ele...@gmail.com wrote: I think the key issue is your: I believe they should be able to use both, as long as there aren't any real conflicts, *without* spurious warnings... As Jeff said, the problem is aren't any real conflicts is not possible to determine in all cases, and can be costly in others. And IIUC its not possible to know ahead of time if it can be determined. So because its not practically possible to protect against problematic situations, Julia plays it safe and complains about all situations. Cheers Lex
Re: [julia-users] Re: Naming convention
El sábado, 25 de abril de 2015, 8:21:42 (UTC-5), Scott Jones escribió: Yes - I think there are a lot of overshort names in some of the Julia packages/modules... for example, why is it readdlm, and not read_delim? I completely agree that readdlm is a particularly bad offender in the readability contest. +1 for read_delim On Saturday, April 25, 2015 at 9:14:12 AM UTC-4, Tracy Wadleigh wrote: I too like underscores. The thing that bugs me is that they aren't always used. I'm not a fan of conventions that involve judgment calls without an especially compelling reason. On Sat, Apr 25, 2015, 9:07 AM Scott Jones scott.pa...@gmail.com wrote: Umm... the style guide for Julia says *to* use underscore for longer names, *not* camelcase: - modules and type names use capitalization and camel case:module SparseMatrix, immutable UnitRange. - functions are lowercase (maximum() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.maximum , convert() http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.convert) and, when readable, with multiple words squashed together (isequal() http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.isequal , haskey() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.haskey). When necessary, use underscores as word separators. Underscores are also used to indicate a combination of concepts (remotecall_fetch() http://docs.julialang.org/en/release-0.3/stdlib/parallel/#Base.remotecall_fetch as a more efficient implementation of remotecall(fetch(...))) or as modifiers (sum_kbn() http://docs.julialang.org/en/release-0.3/stdlib/arrays/#Base.sum_kbn ). - conciseness is valued, but avoid abbreviation (indexin() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.indexin rather thanindxin()) as it becomes difficult to remember whether and how particular words are abbreviated. Personally, I think the Julia style guide gets it right... also, there have even been studies that show that words separated by _ are easier to read (20% faster to read!) than words with no spaces and camel cased... Scott On Saturday, April 25, 2015 at 6:43:44 AM UTC-4, François Fayard wrote: Hi, I would like to talk about naming convention. I think it's fine to have short names in a langage with few keywords such as C (memcpy), but a langage such as Julia that wants to be also high level with a huge standard library needs convention because the langage might become very large. I find the convention used by Mathematica the best ever made. Nothing is shortened except a few exceptions and consistent use of CamlCase. On the other hand, Matlab is probably one of the worst thing that happen in terms of naming: no consistency at all! I suspect that Cleve Moler who started Matlab not used LAPACK but also the Fortran 77 naming convention which was only there only for technical reasons ;-) I've seen that the naming convention for function in Julia looks like the same as in Python: everything must be lowercase, and don't use underscore. Let's look at different naming conventions, the first one being the one used by Julia. 1) daysinmonth() 2) daysInMonth() 3) days_in_month() I find the first one the most difficult to read. I tend to prefer the last one, but the second one is also easy to read. The fact that Julia uses the first one and the fact that many names are shortened, makes reading code with functions you've never seen a pain. For instance reading a name iso... my mind does not understand if we at talking about a function that returns a Bool (is suggests that) or something that has been standardised (ISO). Using the second naming convention would make things easier. Also it would prevent people using underscores as we have in the standard library without any clear reason. I don't find any disadvantage for the second naming convention over the first one. So why do people use the first one?
[julia-users] Re: Custom Array type
Which is exactly what should be possible to avoid, if we anyhow have to
define all the functions what is the meaning in descending from
AbstractArray? The usefulness of having an abstract Component is to make
concrete instances that retain all the abstract functionality.
On Saturday, 25 April 2015 19:50:20 UTC+3, Simon Danisch wrote:
You need to implement the minimal array interface.
Something along these lines:
length(c::Cube) = length(c.data)
eltype{T,N}(c::Cube{T,N}) = T
ndims{T,N}(c::Cube{T,N}) = N
size(c::Cube) = size(c.data)
size((c::Cube, i::Integer) = size(c.data, i)
[julia-users] Re: Online regression algorithms
It looks like you've implemented a lot. I'll take a look in more depth and see how it fits in with my goals. I'm curious... is there a reason you haven't merged in some way with StreamStats? It seems to overlap pretty heavily, but maybe not. If it makes sense, are you open to collaboration on OnlineStats, or would that complicate things? On Saturday, April 25, 2015 at 11:22:24 AM UTC-4, Josh Day wrote: I've been working on https://github.com/joshday/OnlineStats.jl. The src/README shows the implementation progress. It's partially a playground for my research (on online algorithms for statistics). Please take a look and let me know what you think, but my regression stuff is currently in break-everything mode and will be cleaned up in less than a week.
Re: [julia-users] Re: Defining a function in different modules
I think this is just a different mindset than the one we've adopted. In the mindset you describe, there really *ought* to be only one function with each name, in other words a single global namespace. As long as all new definitions for a function have disjoint signatures, there are no conflicts. To deal with conflicts, each module has its own view of a function that resolves conflicts in favor of its definitions. This approach has a lot in common with class-based OO. For example in Python when you say `x.sin()`, the `sin` name belongs to a single method namespace. Sure there are different namespaces for *top level* definitions, but not for method names. If you want a different `sin` method, you need to make a new class, so the `x` part is different. This corresponds to the requirement you describe of methods referencing some new type from the same julia module. Well, that's not how we do things. For us, if two functions have the same name it's just a cosmetic coincidence, at least initially. In julia two functions can have the same name but refer to totally different concepts. For example you can have Base.sin, which computes the sine of a number, and Transgressions.sin, which implements all sorts of fun behavior. Say Base only defines sin(x::Float64), and Transgressions only defines sin(x::String). They're disjoint. However, if you say map(sin, [1.0, sloth, 2pi, gluttony]) you can't get both behaviors. You'll get a method error on either the 1.0 or the string. You have to decide which notion of `sin` you mean. We're not going to automatically merge the two functions. On Sat, Apr 25, 2015 at 3:27 PM, Scott Jones scott.paul.jo...@gmail.com wrote: My point is, if I have been careful, and export methods that always reference at least one of type defined locally in my module, so that they should always be unambiguous, I should NOT have to know about any other module (or Base) that a user of my module might also be using having a function with the same name, and should NOT have to do an import. For methods where I *am* trying to extend some type defined in another module/package or base, then yes, I believe you should do something explicitly to indicate that. I don't think there is any real conflict here... right now it is too restrictive when the module's programmer has clearly signaled their intent by always using their own, unambiguous signitures for their functions. Have I got something fundamentally wrong here? Thanks, Scott On Saturday, April 25, 2015 at 2:10:25 PM UTC-4, Jeff Bezanson wrote: Scott, the behavior you're trying to get sounds to me like IF this function exists in Base then I want to extend it, otherwise just make my own version of the function. That strikes me as a hack. What we've tended to do is let everybody define whatever they want. Then if we see the same name appearing in multiple packages, we decide if there is indeed a common interface, and if so move the packages to using it, e.g. by creating something like StatsBase or maybe adding something to Base. But we don't want Base to grow much more, if at all. Getting an error for using both Base and your package seems annoying, but alternatives that involve doing something silently surely must be considered worse. If a colliding name gets added to Base, the default behavior should not be to assume that you meant to interfere with its behavior. On Sat, Apr 25, 2015 at 1:57 PM, Jeff Bezanson jeff.b...@gmail.com wrote: Michael, that's not a bad summary. I would make a couple edits. You don't really need to qualify *all* uses. If you want to use `foo` from module `A`, you can put `import A.foo` at the top and then use `foo` in your code. That will have no surprises and no breakage. Also I think calling it SuperSecretBase makes it sound worse than it is. You can have modules that describe a certain named interface, and then other modules extend it. Which reminds me that I need to implement #8283, so you can introduce functions without adding methods yet. On Sat, Apr 25, 2015 at 12:31 PM, Stefan Karpinski ste...@karpinski.org wrote: Scott, I'm not really understanding your problem. Can you give an example? On Sat, Apr 25, 2015 at 11:53 AM, Scott Jones scott.pa...@gmail.com wrote: A problem I'm running into is the following (maybe the best practice for this is documented, and I just to stupid to find it!): I have created a set of functions, which use my own type, so they should never be ambiguous. I would like to export them all, but I have to import any names that already exist... Then tomorrow, somebody adds that name to Base, and my code no longer works... I dislike having to explicitly import names to extend something, how am I supposed to know in advance all the other names that could be used? What am I doing wrong? On Saturday, April 25, 2015 at 11:20:14 AM UTC-4, Stefan Karpinski wrote: I think you're probably
Re: [julia-users] Re: Defining a function in different modules
I don't think it is realistic to expect be able to willy-nilly be 'using' any number of packages and it just works. The way you propose may work most of the time, however, there were some solid arguments made in this thread on how that can lead to hard to catch failures. And maybe more importantly, from a programmer's sanity perspective, I think it is imperative that one generic function does just one conceptual thing. Otherwise it gets really hard to figure out what a piece of code does. On Sat, 2015-04-25 at 22:24, Scott Jones scott.paul.jo...@gmail.com wrote: On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote: I think this is just a different mindset than the one we've adopted. In the mindset you describe, there really *ought* to be only one function with each name, in other words a single global namespace. As long as all new definitions for a function have disjoint signatures, there are no conflicts. To deal with conflicts, each module has its own view of a function that resolves conflicts in favor of its definitions. As a practical point, *why* should I have to know about every other package or module that users of my package might possibly want to use at the same time? With the way it is now, it seems I have to force everybody to not use using, and use fully specified names, which seems utterly against the extensibility of Julia, because if I try to export a function, I must know the intentions of every user, which packages they might load, etc. that might possibly have the same name. I have a module that defines a packed database format, and I want to define a length, push!, and getindex methods... Then (for examples sake) I also want to define a foobar method that people can use, and be able to call it on objects from my module with just foobar(db,arg1,arg2) (where db is from my class). All is well and good, but then some user complains that they can't use my package and package newdb, because coincidentally they also defined a function called foobar, that does have a different signature. I believe they should be able to use both, as long as there aren't any real conflicts, *without* spurious warnings... This approach has a lot in common with class-based OO. For example in Python when you say `x.sin()`, the `sin` name belongs to a single method namespace. Sure there are different namespaces for *top level* definitions, but not for method names. If you want a different `sin` method, you need to make a new class, so the `x` part is different. This corresponds to the requirement you describe of methods referencing some new type from the same julia module. Well, that's not how we do things. For us, if two functions have the same name it's just a cosmetic coincidence, at least initially. In julia two functions can have the same name but refer to totally different concepts. For example you can have Base.sin, which computes the sine of a number, and Transgressions.sin, which implements all sorts of fun behavior. Say Base only defines sin(x::Float64), and Transgressions only defines sin(x::String). They're disjoint. However, if you say map(sin, [1.0, sloth, 2pi, gluttony]) you can't get both behaviors. You'll get a method error on either the 1.0 or the string. You have to decide which notion of `sin` you mean. We're not going to automatically merge the two functions. I'm not saying you should... on the other hand, if I have to functions from different packages, developed independently, that happen to have a name in common, (but with different signatures), the users should not have to somehow get the developers together (who may not even be around anymore), to somehow resolve the conflict (which would probably adversely affect other users of both packages if some names had to be changed) Then if we see the same name appearing in multiple packages, we decide if there is indeed a common interface, and if so move the packages to using it, e.g. by creating something like StatsBase or maybe adding something to Base. But we don't want Base to grow much more, if at all. I'm sorry, but that just seems like a recipe for disaster... you are saying that *after* users finally decide they want to use two packages together, that then somehow you will force the developers of the packages to agree on a common interface, or change the names of conflicting functions, or make everybody use names qualified with the module name(s)... As for your map, example... If instead, I have map(sin, [1.0, myslothdays, 2pi, mygluttonydays] ), where myslothdays and mygluttonydays both have the type MySinDiary, and there is a Transgressions.sin(x::Transgressions.MySinDiary) method... that should work, right? What is a good reason for it not to work? Scott On Sat, Apr 25, 2015 at 3:27 PM, Scott Jones scott.pa...@gmail.com javascript: wrote: My point is, if I have been
[julia-users] Re: Bioinformatics in Julia
Hi, I am a computational biologist and I do my majority of jobs using Julia right now. So far biojulia is not so practical but you can using BioPython package. It is quite convenient and painless to call python package so far. R packages are also necessary for bioinformatics. However, as I known, Julia haven't a good interface to connect with R at this moment. Therefore I wrote some custom code to wrap Rif.jl package in order to better calling R in Julia. Look at RCall package, it has better integration with R then Rif.
[julia-users] Re: PyPlot : one plot after the other and not simultaneously
On Saturday, April 25, 2015 at 11:21:24 AM UTC-4, Ferran Mazzanti wrote: I'm new to Julia (but not to Python) and can't find he right way to use PyPlot as I do in Python. In short, I have a program that should display a plot, wait for the user to close the plot, then show a second plot and g on running. But it is not doing that: it just merges the two plots in one and goes on. The only thing I've managed to do so far is to show the first plot, wait for some time, then show the second plot, and go on: That's because PyPlot defaults to interactive mode. Just run ioff() to turn off interactive mode, and the show() command will be blocking.
Re: [julia-users] Re: Need help/direction on how to optimize some Julia code
Here is the output of Profile.print() https://github.com/harikb/scratchpad1/blob/master/julia2/run3.txt I don't know how to interpret these results, but I would guess this is where the most time is spent 10769 stream.jl; stream_wait; line: 263 10774 stream.jl; readavailable; line: 709 10774 stream.jl; wait_readnb; line: 316 Is the issue that stream.jl is reading byte by byte? If a Content-Length is available in the response header (and I know it is), it should probably read as one chunk. Again, I am throwing a dart in the dark. So I should probably stop speculating. Any help is appreciated on the next steps -- Harry On Thursday, April 23, 2015 at 5:52:09 PM UTC-7, Tim Holy wrote: I think it's fair to say that Profile.print() will be quite a lot more informative---all you're getting is the list of lines visited, not anything about how much time each one takes. --Tim On Thursday, April 23, 2015 04:19:08 PM Harry B wrote: I am trying to profile this code, so here is what I have so far. I added the following code to the path taken for the single-process mode. I didn't bother with the multi-process once since I didn't know how to deal with @profile and remotecall_wait @profile processOneFile(3085, 35649, filename) bt, lidict = Profile.retrieve() println(Profiling done) for (k,v) in lidict println(v) end Output is here https://github.com/harikb/scratchpad1/blob/master/julia2/run1.txt (Ran with julia 0.3.7) another run https://github.com/harikb/scratchpad1/blob/master/julia2/run2.txt (Ran with julia-debug 0.3.7) - in case it gave better results. However, there is quite a few lines marked without line or file info. On Wednesday, April 22, 2015 at 2:44:13 AM UTC-7, Yuuki Soho wrote: If I understand correctly now you are doing only 5 requests at the same time? It seems to me you could do much more. But that hides the inefficiency, whatever level it exists. The Go program also uses only 5 parallel connections. On Wednesday, April 22, 2015 at 1:15:20 PM UTC-7, Stefan Karpinski wrote: Honestly, I'm pretty pleased with that performance. This kind of thing is Go's bread and butter – being within a factor of 2 of Go at something like this is really good. That said, if you do figure out anything that's a bottleneck here, please file issues – there's no fundamental reason Julia can't be just as fast or faster than any other language at this. Stefan, yes, it is about 2x if I subtract the 10 seconds or so (whatever it appears to me) as the startup time. I am running Julia 0.3.7 on a box with a deprecated GnuTLS (RHEL). The deprecation warning msg comes about 8 seconds into the run and I wait another 2 seconds before I see the first print statement from my code (Started N processes message). My calculations already exclude these 10 seconds. I wonder if I would get better startup time with 0.4, but Requests.jl is not compatible with it (nor do I find any other library for 0.4). I will try 0.4 again and see I can fix Requests.jl Any help is appreciated on further analysis of the profile output. Thanks -- Harry On Thursday, April 23, 2015 at 7:21:11 AM UTC-7, Seth wrote: The use of Requests.jl makes this very hard to benchmark accurately since it introduces (non-measurable) dependencies on network resources. If you @profile the function, can you tell where it's spending most of its time? On Tuesday, April 21, 2015 at 2:12:52 PM UTC-7, Harry B wrote: Hello, I had the need to take a text file with several million lines, construct a URL with parameters picked from the tab limited file, and fire them one after the other. After I read about Julia, I decided to try this in Julia. However my initial implementation turned out to be slow and I was getting close to my deadline. I then kept the Julia implementation aside and wrote the same thing in Go, my other favorite language. Go version is twice (at least) as fast as the Julia version. Now the task/deadline is over, I am coming back to the Julia version to see what I did wrong. Go and Julia version are not written alike. In Go, I have just one main thread reading a file and 5 go-routines waiting in a channel and one of them will get the 'line/job' and fire off the url, wait for a response, parse the JSON, and look for an id in a specific place, and go back to wait for more items from the channel. Julia code is very similar to the one discussed in the thread quoted below. I invoke Julia with -p 5 and then have *each* process open the file and read all lines. However each process is only processing 1/5th of the lines and skipping others. It is a slight
[julia-users] Re: PyPlot : one plot after the other and not simultaneously
recognizing that you intend to handle all of this in a program, the following IJulya ( IJulia / Jupyter with a Julia kernel ...) notebook gives a sense of how plot() results are treated as figure objects: https://cloud.sagemath.com/projects/f8b7156e-2e6b-42c9-a53d-b3ae2355f00e/files/2015-04-25-100946.html good luck, cdm
[julia-users] Re: Bioinformatics in Julia
It wouldn't recommend it for real work just yet. There's a lot of functionality yet to be built, or not yet merged, so it can't compete with python or matlab in terms of completeness and stability. I'm pretty happy with how it's coming along though, so hopefully that will change in the future. On Saturday, April 25, 2015 at 11:36:19 AM UTC-7, Tim K wrote: Thanks guys. Would you say that it's suitable for a newbie, or should I stick with MATLAB or python? On Saturday, 25 April 2015 20:12:08 UTC+2, Daniel Jones wrote: Don't let the lack of activity on the mailing list fool you, it is being actively developed. We just mostly communicate in github issues and on gitter. Browsing the pending PRs in Bio.jl is a good way to get a sense of what's happening: https://github.com/BioJulia/Bio.jl/pulls On Saturday, April 25, 2015 at 10:08:16 AM UTC-7, Tim K wrote: Dear All, I am finishing a bioengineering postdoc soon, and am looking to learn some bioinformatics. Accordingly, I was wondering what the status of bioinformatics tools for Julia is? (I would post in the biojulia-dev group, but it has not been updated since July 2014.) Cheers, Tim.
Re: [julia-users] Re: Defining a function in different modules
The reason for it not to work is that we have two different concepts that happen to be spelled the same. To me you're just describing inherent problems with name conflicts and agreeing on interfaces. Having a single method namespace is hardly a magic bullet for that. It seems to require just as much coordination. In Python again, two people might develop socket libraries that implement connect, but one uses foo.connect(address, port) and the other uses bar.connect(port, address). At that point, you absolutely have to get the two developers to agree on one interface so that people can use both, and say x.connect() where x might be either foo or bar. If the libraries can't be changed, you can write shims to make them compatible. But you can do the same thing in julia. In julia the disaster is no bigger than usual. Quite rightly, you are focusing on how code changes over time, and what problems that might cause. But your design focuses on adding functions, and assumes signatures don't change as much and have a particular structure (i.e. typically referring directly to a type defined in the same module). If those assumptions hold, I agree that it could work very well. But it breaks as signatures change, while our design breaks as export lists change. I prefer our tradeoff because method signatures are far more subtle. Comparing method signatures is computationally difficult (exponential worst case!), while looking for a symbol in a list is trivial. Warnings for name conflicts may be annoying, but at least it's dead obvious what's happening. If a subtle adjustment to a signature affects visibility elsewhere, I'd think that would be much harder to track down. On Sat, Apr 25, 2015 at 4:24 PM, Scott Jones scott.paul.jo...@gmail.com wrote: On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote: I think this is just a different mindset than the one we've adopted. In the mindset you describe, there really *ought* to be only one function with each name, in other words a single global namespace. As long as all new definitions for a function have disjoint signatures, there are no conflicts. To deal with conflicts, each module has its own view of a function that resolves conflicts in favor of its definitions. As a practical point, *why* should I have to know about every other package or module that users of my package might possibly want to use at the same time? With the way it is now, it seems I have to force everybody to not use using, and use fully specified names, which seems utterly against the extensibility of Julia, because if I try to export a function, I must know the intentions of every user, which packages they might load, etc. that might possibly have the same name. I have a module that defines a packed database format, and I want to define a length, push!, and getindex methods... Then (for examples sake) I also want to define a foobar method that people can use, and be able to call it on objects from my module with just foobar(db,arg1,arg2) (where db is from my class). All is well and good, but then some user complains that they can't use my package and package newdb, because coincidentally they also defined a function called foobar, that does have a different signature. I believe they should be able to use both, as long as there aren't any real conflicts, *without* spurious warnings... This approach has a lot in common with class-based OO. For example in Python when you say `x.sin()`, the `sin` name belongs to a single method namespace. Sure there are different namespaces for *top level* definitions, but not for method names. If you want a different `sin` method, you need to make a new class, so the `x` part is different. This corresponds to the requirement you describe of methods referencing some new type from the same julia module. Well, that's not how we do things. For us, if two functions have the same name it's just a cosmetic coincidence, at least initially. In julia two functions can have the same name but refer to totally different concepts. For example you can have Base.sin, which computes the sine of a number, and Transgressions.sin, which implements all sorts of fun behavior. Say Base only defines sin(x::Float64), and Transgressions only defines sin(x::String). They're disjoint. However, if you say map(sin, [1.0, sloth, 2pi, gluttony]) you can't get both behaviors. You'll get a method error on either the 1.0 or the string. You have to decide which notion of `sin` you mean. We're not going to automatically merge the two functions. I'm not saying you should... on the other hand, if I have to functions from different packages, developed independently, that happen to have a name in common, (but with different signatures), the users should not have to somehow get the developers together (who may not even be around anymore), to somehow resolve the conflict (which would probably adversely affect other users of both
[julia-users] Re: kernel restarts after running code
I missed to say to get the error, run test_kernel_restart.ipynb https://github.com/prezaei85/JuliaPower/blob/master/test_kernel_restart.ipynb . On Saturday, April 25, 2015 at 4:56:42 PM UTC-4, Pooya wrote: Thank you for your response. My codes are already on Github. I just pushed the latest version: https://github.com/prezaei85/JuliaPower Does that work? If not, let me know to upload a smaller version, but I'm not sure how to make it throw that error and restart the kernel, because I use the same function in other places and it's fine. I also have these lines in my .juliarc.jl (I have written two modules that the codes use): push!(LOAD_PATH, ~/JuliaPower) push!(LOAD_PATH, ~/JuliaPower/data) Also, if you found something obviously non-idomatic, I appreciate if you let me know. By the way, you are awesome in the tutorial video on Youtube from SciPy 2014!! I learnt a lot from that. On Saturday, April 25, 2015 at 10:36:52 AM UTC-4, David P. Sanders wrote: El sábado, 25 de abril de 2015, 9:08:16 (UTC-5), Pooya escribió: These did not work. In one of my functions I am returning a function (myfunc) in output that is defined like myfunc(x;args...) = g(x,y,z,m,n;args...). This was working up to now when I am using myfunc in another function (and also when I use it directly in the global scope). I guess that is causing some problems, but I can't figure out why yet. I am using Debug package, but getting some weird outputs! Try making a minimal example (i.e., a small example that reproduces the problem) and post it here or at gist.github.com so that we can try and diagnose the issue. On Saturday, April 25, 2015 at 12:28:53 AM UTC-4, David P. Sanders wrote: El viernes, 24 de abril de 2015, 21:44:00 (UTC-5), Pooya escribió: I have been using julia in Mac Terminal and IJulia notebook for a while and they have been fine. But now I am getting this error: The kernel appears to have died. It will restart automatically. in IJulia, and the following in Terminal after I run one of my codes. It restarts the kernel in both cases! Can anyone help? julia(8724,0x7fff7315e310) malloc: *** error for object 0x7feed745df10: pointer being realloc'd was not allocated *** set a breakpoint in malloc_error_break to debug signal (6): Abort trap: 6 __pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line) Abort trap: 6 My usual solution for these kinds of problems (i.e. problems in which it's unclear what the problem is and it was previously working!) is the following sequence, testing if it now works after each step (i) Pkg.update() (ii) Pkg.build(IJulia) (iii) Remove entire .julia directory and reinstall IJulia with Pkg.add(IJulia). (This is overkill for what would basically be get the latest version of all dependencies, but it can't do any harm...) Of course it might be an actual bug, in which case these steps won't help at all...
[julia-users] Re: Bioinformatics in Julia
Hi, I am a computational biologist and I do my majority of jobs using Julia right now. So far biojulia is not so practical but you can using BioPython package. It is quite convenient and painless to call python package so far. R packages are also necessary for bioinformatics. However, as I known, Julia haven't a good interface to connect with R at this moment. Therefore I wrote some custom code to wrap Rif.jl package in order to better calling R in Julia. What's ever, the reality is there is no any language even close to prefect for the biological data analysis. You could choice using Python+R, or using Julia plus python and R packages. Most people chose the first one for the tradition reason, but I prefer the latter one due to the incomparable characters of Julia language, even I have to pay some price for its immaturity at this moment. At least, I can do all the jobs using one language now, rather than always shifting between python and R. On Saturday, April 25, 2015 at 7:08:16 PM UTC+2, Tim K wrote: Dear All, I am finishing a bioengineering postdoc soon, and am looking to learn some bioinformatics. Accordingly, I was wondering what the status of bioinformatics tools for Julia is? (I would post in the biojulia-dev group, but it has not been updated since July 2014.) Cheers, Tim.
Re: [julia-users] Re: Defining a function in different modules
The problem is, in practice, people *will* have names that collide, and will not mean the same thing. It seems that people here are trying to say, if you have a particular name you'd like to use, you'd better get together with all other developers past and future and hammer out who owns the name, and what concept it can be used for... (like mathematical sin and fun sin, or tree bark and dogs bark... it gets even worse when you consider other languages... [Say I'm in Spain, and I write a robotics package that has a function coger..., and somebody in Argentina writes a function coger that does something, well, XXX...]) I just don't see this as working for any length of time (and I think it is already breaking down with Julia... to me, the fact that DataFrames picked using ~ as a binary operator, when that might have been something that somebody wanted to use in the core language, shows how fragile things are now...) Scott On Saturday, April 25, 2015 at 5:27:10 PM UTC-4, Mauro wrote: I don't think it is realistic to expect be able to willy-nilly be 'using' any number of packages and it just works. The way you propose may work most of the time, however, there were some solid arguments made in this thread on how that can lead to hard to catch failures. And maybe more importantly, from a programmer's sanity perspective, I think it is imperative that one generic function does just one conceptual thing. Otherwise it gets really hard to figure out what a piece of code does. On Sat, 2015-04-25 at 22:24, Scott Jones scott.pa...@gmail.com javascript: wrote: On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote: I think this is just a different mindset than the one we've adopted. In the mindset you describe, there really *ought* to be only one function with each name, in other words a single global namespace. As long as all new definitions for a function have disjoint signatures, there are no conflicts. To deal with conflicts, each module has its own view of a function that resolves conflicts in favor of its definitions. As a practical point, *why* should I have to know about every other package or module that users of my package might possibly want to use at the same time? With the way it is now, it seems I have to force everybody to not use using, and use fully specified names, which seems utterly against the extensibility of Julia, because if I try to export a function, I must know the intentions of every user, which packages they might load, etc. that might possibly have the same name. I have a module that defines a packed database format, and I want to define a length, push!, and getindex methods... Then (for examples sake) I also want to define a foobar method that people can use, and be able to call it on objects from my module with just foobar(db,arg1,arg2) (where db is from my class). All is well and good, but then some user complains that they can't use my package and package newdb, because coincidentally they also defined a function called foobar, that does have a different signature. I believe they should be able to use both, as long as there aren't any real conflicts, *without* spurious warnings... This approach has a lot in common with class-based OO. For example in Python when you say `x.sin()`, the `sin` name belongs to a single method namespace. Sure there are different namespaces for *top level* definitions, but not for method names. If you want a different `sin` method, you need to make a new class, so the `x` part is different. This corresponds to the requirement you describe of methods referencing some new type from the same julia module. Well, that's not how we do things. For us, if two functions have the same name it's just a cosmetic coincidence, at least initially. In julia two functions can have the same name but refer to totally different concepts. For example you can have Base.sin, which computes the sine of a number, and Transgressions.sin, which implements all sorts of fun behavior. Say Base only defines sin(x::Float64), and Transgressions only defines sin(x::String). They're disjoint. However, if you say map(sin, [1.0, sloth, 2pi, gluttony]) you can't get both behaviors. You'll get a method error on either the 1.0 or the string. You have to decide which notion of `sin` you mean. We're not going to automatically merge the two functions. I'm not saying you should... on the other hand, if I have to functions from different packages, developed independently, that happen to have a name in common, (but with different signatures), the users should not have to somehow get the developers together (who may not even be around anymore), to somehow resolve the conflict (which would probably adversely affect other users of both
[julia-users] Re: Set construction
Here you are Iain,
it's a very one day testing code :-)
thnaks very much
Fabrizio
On Saturday, April 25, 2015 at 8:41:56 PM UTC+2, Fabrizio wrote:
Hi, very newby in Julia/JuMP, my problem is
i have a set of power gen and attached nodes in a grid in this format
PowerGen_ID Node
1 1
2 2
3 1
4 2
i would like to construct a set T_GENERATING_BUS for each node that
contains the Power Gen attached to it
i.e.
T_GENERATING_BUS[1]={1,3};
T_GENERATING_BUS[2]={2,4};
i tried something like:
T_GENERATING_BUS = Set[]
for k in BUS
for j=1:gmax
if BUS_T[j] == k
T_GENERATING_BUS[k] = union(T_GENERATING_BUS[k],j)
end
end
end
but got an error bound
ERROR: BoundsError()
in getindex at array.jl:246 (repeats 2 times)
while loading E:\CodiciSorgente\ProgrammiJulia\UCOTS.jl, in expression
starting on line 101
the problem is that i don't know how to increase the dim of
T_GENERATING_BUS
Any hints?
Thanks
Fabrizio
UCOTS.jl
Description: Binary data
Re: [julia-users] Re: Defining a function in different modules
Hi Scott, While the current system in Julia may not be perfect, I'm finding it hard to follow some of your thoughts right now. Perhaps you could come up with some trivial code which explains your concerns? In particular, I'm not sure what you mean by wouldn't be able to use other packages with were designed to extend package A. I've been using Julia for a couple of years and haven't run into such problems. Cheers! Kevin On Sat, Apr 25, 2015 at 3:25 PM, Scott Jones scott.paul.jo...@gmail.com wrote: No, not at all. I have a bunch of code written using package A. It knows what the correct arguments are to the connect function for type AConnectionManager. I did using A, because having to specify all the time which package (however short the name is), and it means that I wouldn't be able to use other packages with were designed to extend package A (and did use the import A to extend the functions with new methods). Then I need to connect to another database package, that also used the name connect, with other arguments, but no conflicting signatures at all. It has a connect(BConnectionManager, namespacename, globalname) function (with a set of methods). There might also be further packages which extend module B's functions, explicitly doing import B export extendedfunction I think that should work just fine, but you are saying that I *must* specify B.connect, which then also means (AFAIK), that I won't get a C.connect that extends B.connect (and intended to). Why do you want to restrict what can be done, because you have this view that, like the Highlander, there can only be *one* true interface for a name? Scott On Saturday, April 25, 2015 at 6:13:11 PM UTC-4, Jeff Bezanson wrote: When two people write packages independently, I claim there are only two options: (1) they implement a common interface, (2) they don't. To pick option (1), there has to be some kind of centralization or agreement. For option (2), which is effectively the default, each package just gets its own totally separate function, and you have to say which one you want. We're not saying you'd better get together with all other developers, because with option (2) you don't need to. IIUC, you're proposing option (3), automatically merge everybody's methods, assuming they don't conflict. But I don't see how this can work. We could have: module A type AConnectionManager end function connect(cm::AConnectionManager, port, address) end end module B type BConnectionManager end function connect(cm::BConnectionManager, address, port) end end Obviously, you cannot do `using A; using B`, and then freely use `connect` and have everything work. The fact that the type of the first argument distinguishes methods doesn't help. The rest of the arguments don't match, and even if they did the behaviors might not implement compatible semantics. The only options I see are my options 1 and 2: (1) move to a common interface, or (2) specify A.connect or B.connect in client code, because the interfaces aren't compatible. On Sat, Apr 25, 2015 at 5:55 PM, Scott Jones scott.pa...@gmail.com wrote: The problem is, in practice, people *will* have names that collide, and will not mean the same thing. It seems that people here are trying to say, if you have a particular name you'd like to use, you'd better get together with all other developers past and future and hammer out who owns the name, and what concept it can be used for... (like mathematical sin and fun sin, or tree bark and dogs bark... it gets even worse when you consider other languages... [Say I'm in Spain, and I write a robotics package that has a function coger..., and somebody in Argentina writes a function coger that does something, well, XXX...]) I just don't see this as working for any length of time (and I think it is already breaking down with Julia... to me, the fact that DataFrames picked using ~ as a binary operator, when that might have been something that somebody wanted to use in the core language, shows how fragile things are now...) Scott On Saturday, April 25, 2015 at 5:27:10 PM UTC-4, Mauro wrote: I don't think it is realistic to expect be able to willy-nilly be 'using' any number of packages and it just works. The way you propose may work most of the time, however, there were some solid arguments made in this thread on how that can lead to hard to catch failures. And maybe more importantly, from a programmer's sanity perspective, I think it is imperative that one generic function does just one conceptual thing. Otherwise it gets really hard to figure out what a piece of code does. On Sat, 2015-04-25 at 22:24, Scott Jones scott.pa...@gmail.com wrote: On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote: I think this is just a different mindset than the one we've adopted. In the mindset you describe, there
[julia-users] Re: Ode solver thought, numerical recipes
Hi,
Here is a first shot at the program (My first Julia program). It seems that
I don't get good performance (46% of time spent in gc). What is the reason
for that?
type EulerSolver
f::Function
t0::Float64
y0::Vector{Float64}
delta_t::Float64
delta_t_save::Float64
t_right::Vector{Float64}
y_right::Vector{Vector{Float64}}
t_left::Vector{Float64}
y_left::Vector{Vector{Float64}}
end
function ode_solver(f, t0::Float64, y0::Vector{Float64}, delta_t::Float64,
delta_t_save::Float64)
solver = EulerSolver(f, t0, y0, delta_t, delta_t_save, [], [], [], [])
return solver
end
function evaluate(solver::EulerSolver, t_final::Float64)
t::Float64
y::Vector{Float64}
if length(solver.t_right) 0
if t_final = solver.t_right[length(solver.t_right)]
t = solver.t_right[length(solver.t_right)]
y = solver.y_right[length(solver.y_right)]
elseif t_final solver.t_right[1]
t = solver.t0
y = solver.y0
else
k = 1
while t = solver.t_right[k]
k += 1
end
t = solver.t_right[k]
y = solver.y_right[k]
end
else
t = solver.t0
y = solver.y0
end
last_t_saved::Float64 = t
delta_t::Float64 = solver.delta_t
dy_dt::Vector{Float64} = zeros(y)
is_finished::Bool = false
while !is_finished
if t + delta_t t_final
delta_t = t_final - t
is_finished = true
end
f!(dy_dt, t, y)
for k = 1:length(y)
y[k] = y[k] + delta_t * dy_dt[k]
end
t = t + delta_t
if abs(t - last_t_saved) = solver.delta_t_save
println(Save)
last_t_saved = t
push!(solver.t_right, t)
push!(solver.y_right, deepcopy(y))
end
end
return y
end
function f!(dy_dt::Vector{Float64}, t::Float64, y::Vector{Float64})
dy_dt[1] = y[1]
end
t0 = 0.0
y0 = [ 1.0 ]
delta_t = 1.0e-8
delta_t_save = 1.0
solver = ode_solver(f!, t0, y0, delta_t, delta_t_save)
@time println(evaluate(solver, 3.12))
[julia-users] Re: Custom Array type
Feels somehow sufficient to direct all functions to the data field. We can
have a macro like
@foranyfunction f(c::Cubes,a::AnyArgs)=f(c.data,a)
What you really want to be able to do is delegate everything to the .data
member, but there's no convenient way to do that
There are some existing macros that take a list of functions and define
them on a type, we can wrap a macro that acts on all functions in
methods(T).
Or allow inheriting from concrete types.
Or allow specifying abstract types like AbstractArray{T,N}.
[julia-users] Re: Bioinformatics in Julia
Don't let the lack of activity on the mailing list fool you, it is being actively developed. We just mostly communicate in github issues and on gitter. Browsing the pending PRs in Bio.jl is a good way to get a sense of what's happening: https://github.com/BioJulia/Bio.jl/pulls On Saturday, April 25, 2015 at 10:08:16 AM UTC-7, Tim K wrote: Dear All, I am finishing a bioengineering postdoc soon, and am looking to learn some bioinformatics. Accordingly, I was wondering what the status of bioinformatics tools for Julia is? (I would post in the biojulia-dev group, but it has not been updated since July 2014.) Cheers, Tim.
Re: [julia-users] in-place fn in a higher order fn
I think this optimisation should work irrespective of what fn! returns by the fact that the value is not used. This and more seems to happen in the first-order function. Here a version of first-order function which calls a function which returns an inferred Any: const aa = Any[1] hh_ret!(ar,i) = (ar[i] = hh(ar[i]); aa[1]) function f_ret(ar) a = aa[1] for i=1:n a=hh_ret!(ar, i) end a end julia @time f_ret(a); elapsed time: 0.259893608 seconds (160 bytes allocated) It's still fast and doesn't allocate, even though it uses the value! The a= aa[1] is unused and can be removed (well if n is =1). Then I would have thought that first hh_ret() is inlined, then the loop body is visible to the optimiser and the unused value is removed as it is optimised to ar[n]. But if hh_ret() was passed to f_ret() it can only be inlined if f_ret() is re-compiled for each call with a new parameter function. Thats not impossible in a dynamic language like Julia. But still may not work if the function being passed as a parameter is the result of an expression that can't be resolved at compile time. As Tim says its all optimisations that havn't yet been written :) I did run it with --inline=no so the comparison to the higher order function should be fairer, i.e. the hh_ret function was indeed called. Yep, those optimisations, probably should learn how to work on them myself ;-)
[julia-users] Re: kernel restarts after running code
Thank you for your response. My codes are already on Github. I just pushed the latest version: https://github.com/prezaei85/JuliaPower Does that work? If not, let me know to upload a smaller version, but I'm not sure how to make it throw that error and restart the kernel, because I use the same function in other places and it's fine. I also have these lines in my .juliarc.jl (I have written two modules that the codes use): push!(LOAD_PATH, ~/JuliaPower) push!(LOAD_PATH, ~/JuliaPower/data) Also, if you found something obviously non-idomatic, I appreciate if you let me know. By the way, you are awesome in the tutorial video on Youtube from SciPy 2014!! I learnt a lot from that. On Saturday, April 25, 2015 at 10:36:52 AM UTC-4, David P. Sanders wrote: El sábado, 25 de abril de 2015, 9:08:16 (UTC-5), Pooya escribió: These did not work. In one of my functions I am returning a function (myfunc) in output that is defined like myfunc(x;args...) = g(x,y,z,m,n;args...). This was working up to now when I am using myfunc in another function (and also when I use it directly in the global scope). I guess that is causing some problems, but I can't figure out why yet. I am using Debug package, but getting some weird outputs! Try making a minimal example (i.e., a small example that reproduces the problem) and post it here or at gist.github.com so that we can try and diagnose the issue. On Saturday, April 25, 2015 at 12:28:53 AM UTC-4, David P. Sanders wrote: El viernes, 24 de abril de 2015, 21:44:00 (UTC-5), Pooya escribió: I have been using julia in Mac Terminal and IJulia notebook for a while and they have been fine. But now I am getting this error: The kernel appears to have died. It will restart automatically. in IJulia, and the following in Terminal after I run one of my codes. It restarts the kernel in both cases! Can anyone help? julia(8724,0x7fff7315e310) malloc: *** error for object 0x7feed745df10: pointer being realloc'd was not allocated *** set a breakpoint in malloc_error_break to debug signal (6): Abort trap: 6 __pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line) Abort trap: 6 My usual solution for these kinds of problems (i.e. problems in which it's unclear what the problem is and it was previously working!) is the following sequence, testing if it now works after each step (i) Pkg.update() (ii) Pkg.build(IJulia) (iii) Remove entire .julia directory and reinstall IJulia with Pkg.add(IJulia). (This is overkill for what would basically be get the latest version of all dependencies, but it can't do any harm...) Of course it might be an actual bug, in which case these steps won't help at all...
[julia-users] Re: Set construction
Thanks Jemeson,
but it seems not enough, indeed T_GENERATING_BUS must be a collection of k
(=maximum(BUS)) but also with enough space to contain an - unknown a priori
- number of Power_Gen attached to it. Moreover if i change the code as
suggested i get the following error
ERROR: `convert` has no method matching convert(::Type{Set{Any}},
::Array{Any,1})
Fabrizio
On Saturday, April 25, 2015 at 8:41:56 PM UTC+2, fabrizio@gmail.com
wrote:
Hi, very newby in Julia/JuMP, my problem is
i have a set of power gen and attached nodes in a grid in this format
PowerGen_ID Node
1 1
2 2
3 1
4 2
i would like to construct a set T_GENERATING_BUS for each node that
contains the Power Gen attached to it
i.e.
T_GENERATING_BUS[1]={1,3};
T_GENERATING_BUS[2]={2,4};
i tried something like:
T_GENERATING_BUS = Set[]
for k in BUS
for j=1:gmax
if BUS_T[j] == k
T_GENERATING_BUS[k] = union(T_GENERATING_BUS[k],j)
end
end
end
but got an error bound
ERROR: BoundsError()
in getindex at array.jl:246 (repeats 2 times)
while loading E:\CodiciSorgente\ProgrammiJulia\UCOTS.jl, in expression
starting on line 101
the problem is that i don't know how to increase the dim of
T_GENERATING_BUS
Any hints?
Thanks
Fabrizio
Re: [julia-users] Re: Defining a function in different modules
No, not at all. I have a bunch of code written using package A. It knows what the correct arguments are to the connect function for type AConnectionManager. I did using A, because having to specify all the time which package (however short the name is), and it means that I wouldn't be able to use other packages with were designed to extend package A (and did use the import A to extend the functions with new methods). Then I need to connect to another database package, that also used the name connect, with other arguments, but no conflicting signatures at all. It has a connect(BConnectionManager, namespacename, globalname) function (with a set of methods). There might also be further packages which extend module B's functions, explicitly doing import B export extendedfunction I think that should work just fine, but you are saying that I *must* specify B.connect, which then also means (AFAIK), that I won't get a C.connect that extends B.connect (and intended to). Why do you want to restrict what can be done, because you have this view that, like the Highlander, there can only be *one* true interface for a name? Scott On Saturday, April 25, 2015 at 6:13:11 PM UTC-4, Jeff Bezanson wrote: When two people write packages independently, I claim there are only two options: (1) they implement a common interface, (2) they don't. To pick option (1), there has to be some kind of centralization or agreement. For option (2), which is effectively the default, each package just gets its own totally separate function, and you have to say which one you want. We're not saying you'd better get together with all other developers, because with option (2) you don't need to. IIUC, you're proposing option (3), automatically merge everybody's methods, assuming they don't conflict. But I don't see how this can work. We could have: module A type AConnectionManager end function connect(cm::AConnectionManager, port, address) end end module B type BConnectionManager end function connect(cm::BConnectionManager, address, port) end end Obviously, you cannot do `using A; using B`, and then freely use `connect` and have everything work. The fact that the type of the first argument distinguishes methods doesn't help. The rest of the arguments don't match, and even if they did the behaviors might not implement compatible semantics. The only options I see are my options 1 and 2: (1) move to a common interface, or (2) specify A.connect or B.connect in client code, because the interfaces aren't compatible. On Sat, Apr 25, 2015 at 5:55 PM, Scott Jones scott.pa...@gmail.com javascript: wrote: The problem is, in practice, people *will* have names that collide, and will not mean the same thing. It seems that people here are trying to say, if you have a particular name you'd like to use, you'd better get together with all other developers past and future and hammer out who owns the name, and what concept it can be used for... (like mathematical sin and fun sin, or tree bark and dogs bark... it gets even worse when you consider other languages... [Say I'm in Spain, and I write a robotics package that has a function coger..., and somebody in Argentina writes a function coger that does something, well, XXX...]) I just don't see this as working for any length of time (and I think it is already breaking down with Julia... to me, the fact that DataFrames picked using ~ as a binary operator, when that might have been something that somebody wanted to use in the core language, shows how fragile things are now...) Scott On Saturday, April 25, 2015 at 5:27:10 PM UTC-4, Mauro wrote: I don't think it is realistic to expect be able to willy-nilly be 'using' any number of packages and it just works. The way you propose may work most of the time, however, there were some solid arguments made in this thread on how that can lead to hard to catch failures. And maybe more importantly, from a programmer's sanity perspective, I think it is imperative that one generic function does just one conceptual thing. Otherwise it gets really hard to figure out what a piece of code does. On Sat, 2015-04-25 at 22:24, Scott Jones scott.pa...@gmail.com wrote: On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote: I think this is just a different mindset than the one we've adopted. In the mindset you describe, there really *ought* to be only one function with each name, in other words a single global namespace. As long as all new definitions for a function have disjoint signatures, there are no conflicts. To deal with conflicts, each module has its own view of a function that resolves conflicts in favor of its definitions. As a practical point, *why* should I have to know about every other package or module
Re: [julia-users] Re: Custom Array type
The @delegate macro does exist and is used (internally) in
DataStructures.jl.
Cheers,
Kevin
On Sat, Apr 25, 2015 at 12:10 PM, Mauro mauro...@runbox.com wrote:
https://github.com/JuliaLang/julia/pull/3292;
Interesting, has it been implemented now?
No, check the bottom of the thread. But you can just use the macro:
https://github.com/JuliaLang/julia/pull/3292/files
Maybe there is a more efficient method, since we are getting further
away from the definition of Array by adding a data field, the
commented source version is empty as in the OP, so when the
constructor calls C it is storing the identifier Array somewhere. We
can create a identical constructor with the difference that it accepts
a keyword for what to write in place of Array.
On 25/04/2015, Mauro mauro...@runbox.com wrote:
On Sat, 2015-04-25 at 19:55, Marcus Appelros marcus.appel...@gmail.com
wrote:
Feels somehow sufficient to direct all functions to the data field. We
can
have a macro like
@foranyfunction f(c::Cubes,a::AnyArgs)=f(c.data,a)
https://github.com/JuliaLang/julia/pull/3292
What you really want to be able to do is delegate everything to the
.data
member, but there's no convenient way to do that
There are some existing macros that take a list of functions and define
them on a type, we can wrap a macro that acts on all functions in
methods(T).
Or allow inheriting from concrete types.
Or allow specifying abstract types like AbstractArray{T,N}.
Re: [julia-users] Re: Custom Array type
It sounds great in theory, except that it returns an object of the wrong
type half of the time (for example, similar, copy, sub, slice, etc.) and
half the time it will happily do an invalid or meaningless operations (such
as taking dot products of Cubes or mutating them to have the wrong
dimensions) simply because such operations are reasonable on the base type.
And that's just generally worse than useless.
On Sat, Apr 25, 2015 at 1:55 PM Marcus Appelros marcus.appel...@gmail.com
wrote:
Feels somehow sufficient to direct all functions to the data field. We can
have a macro like
@foranyfunction f(c::Cubes,a::AnyArgs)=f(c.data,a)
What you really want to be able to do is delegate everything to the .data
member, but there's no convenient way to do that
There are some existing macros that take a list of functions and define
them on a type, we can wrap a macro that acts on all functions in
methods(T).
Or allow inheriting from concrete types.
Or allow specifying abstract types like AbstractArray{T,N}.
Re: [julia-users] ANN: QuDirac.jl
Nice! I'm curious how tough it would be to simulate Shor's algorithm, even if it's just to factor 15; Is there some reason that this is too tough to include as an example? chris On Thu, Apr 23, 2015 at 6:02 PM, Jarrett Revels jarrettrev...@gmail.com wrote: I'm happy to say that I've finally released QuDirac.jl https://github.com/JuliaQuantum/QuDirac.jl! This package is for performing common quantum mechanical operations using Dirac notation. Feature list: - Implementations of state types (`Ket`,`Bra`), and a variety of operator types (`OpSum`,`OuterProduct`) - Treat states and operators as map-like data structures, enabling label-based analysis for spectroscopy purposes - Implementation of common operations like partial trace (`ptrace`) and partial transpose (`ptranspose`) - Support for abstract/undefined inner products - User-definable custom inner product rules - Subspace selection/transformation via functions on state labels and coefficients: - `xsubspace` allows easy selection of excitation subspaces of states and operators - `permute` and `switch` allows generic permutation of factor labels for states - `filter`/`filter!` are supported on both the labels and coefficients of operators/states - Mapping functions (`map`/`maplabels`/`mapcoeffs`) for applying arbitrary functions to labels and coefficients - Functional generation of operators using `@def_op` and `@rep_op` - `d ... ` literals for natural Dirac notation input syntax -- Jarrett -- chris.p...@ieee.org
Re: [julia-users] Newbie help... First implementation of 3D heat equation solver VERY slow in Julia
It is definitely the slicing that is killing performance. Right now, slicing is expensive since you copy a whole new array for it. Putting const in front of T and RHS and using a loop like this (maybe some mistake but the principle is what is important) makes the code 10x faster: @inbounds for i=2:NX-1, j=2:NY-1, k=2:NZ-1 RHS[i,j,k] = dt*A*( (T[i-1,j,k]-2*T[i,j,k]+T[i+1,j,k])/dx2 + (T[i,j-1,k]-2*T[i,j,k]+T[i,j+1,k])/dy2 + (T[i,j,k-1]-2*T[i,j,k]+T[i,j,k+1])/dz2 ) T[i,j,k] = T[i,j,k] + RHS[i,j,k] end On Saturday, April 25, 2015 at 7:57:01 PM UTC+2, Johan Sigfrids wrote: I think it is all the slicing that is killing the performance. Maybe something like arrayviews or the new sub stuff on 0.4 would help. Alternatively devectorizing into a bunch of nested loops. On Saturday, April 25, 2015 at 8:42:09 PM UTC+3, Stefan Karpinski wrote: Stick const in front of T and RHS. On Sat, Apr 25, 2015 at 11:32 AM, Tim Holy tim@gmail.com wrote: Did you read through http://docs.julialang.org/en/release-0.3/manual/performance-tips/? You should memorize :-) the sections up through the Tools section; the rest you can consult as you discover you need them. --Tim On Saturday, April 25, 2015 01:03:38 AM Ángel de Vicente wrote: Hi, a complete Julia newbie here... I spent a couple of days learning the syntax and main aspects of Julia, and since I heard many good things about it, I decided to try a little program to see how it compares against the other ones I regularly use: Fortran and Python. I wrote a minimal program to solve the 3D heat equation in a cube of 100x100x100 points in the three languages and the time it takes to run in each one is: Fortran: ~7s Python: ~33s Julia:~80s The code runs for 1000 iterations, and I'm being nice to Julia, since the programs in Fortran and Python write 100 HDF5 files with the complete 100^3 data (every 10 iterations). I attach the code (and you can also get it at: http://pastebin.com/y5HnbWQ1) Am I doing something obviously wrong? Any suggestions on how to improve its speed? Thanks a lot, Ángel de Vicente
[julia-users] Re: PyPlot : one plot after the other and not simultaneously
Surpsisingly that didn't work either, but shows a strange ehaviour instead: three figure frames (figure boxes) are opened: figure 1 has once again both plots merged, while figures 2 and 3 show the canvas with nothin (fig.3) and the canvas with the axes (fig.2), but the plots themselves are merged in fig.1 as I mentioned (?)... Have you tried that form the command line REPL? That seems to be different from the IJulia notebook behavior... On Saturday, April 25, 2015 at 7:52:00 PM UTC+2, cdm wrote: recognizing that you intend to handle all of this in a program, the following IJulya ( IJulia / Jupyter with a Julia kernel ...) notebook gives a sense of how plot() results are treated as figure objects: https://cloud.sagemath.com/projects/f8b7156e-2e6b-42c9-a53d-b3ae2355f00e/files/2015-04-25-100946.html good luck, cdm
Re: [julia-users] Re: Defining a function in different modules
In general connect(x, y, z) is dynamically dispatched: you don't always know the type of `x`. So you wouldn't be able to write *generic* code that uses connect. In generic code, there really can be only one interface: if I write code that's supposed to work for any `x`, and I say `connect(x, address, port)`, like it or not my code only works for one of A and B, not both. On Sat, Apr 25, 2015 at 6:25 PM, Scott Jones scott.paul.jo...@gmail.com wrote: No, not at all. I have a bunch of code written using package A. It knows what the correct arguments are to the connect function for type AConnectionManager. I did using A, because having to specify all the time which package (however short the name is), and it means that I wouldn't be able to use other packages with were designed to extend package A (and did use the import A to extend the functions with new methods). Then I need to connect to another database package, that also used the name connect, with other arguments, but no conflicting signatures at all. It has a connect(BConnectionManager, namespacename, globalname) function (with a set of methods). There might also be further packages which extend module B's functions, explicitly doing import B export extendedfunction I think that should work just fine, but you are saying that I *must* specify B.connect, which then also means (AFAIK), that I won't get a C.connect that extends B.connect (and intended to). Why do you want to restrict what can be done, because you have this view that, like the Highlander, there can only be *one* true interface for a name? Scott On Saturday, April 25, 2015 at 6:13:11 PM UTC-4, Jeff Bezanson wrote: When two people write packages independently, I claim there are only two options: (1) they implement a common interface, (2) they don't. To pick option (1), there has to be some kind of centralization or agreement. For option (2), which is effectively the default, each package just gets its own totally separate function, and you have to say which one you want. We're not saying you'd better get together with all other developers, because with option (2) you don't need to. IIUC, you're proposing option (3), automatically merge everybody's methods, assuming they don't conflict. But I don't see how this can work. We could have: module A type AConnectionManager end function connect(cm::AConnectionManager, port, address) end end module B type BConnectionManager end function connect(cm::BConnectionManager, address, port) end end Obviously, you cannot do `using A; using B`, and then freely use `connect` and have everything work. The fact that the type of the first argument distinguishes methods doesn't help. The rest of the arguments don't match, and even if they did the behaviors might not implement compatible semantics. The only options I see are my options 1 and 2: (1) move to a common interface, or (2) specify A.connect or B.connect in client code, because the interfaces aren't compatible. On Sat, Apr 25, 2015 at 5:55 PM, Scott Jones scott.pa...@gmail.com wrote: The problem is, in practice, people *will* have names that collide, and will not mean the same thing. It seems that people here are trying to say, if you have a particular name you'd like to use, you'd better get together with all other developers past and future and hammer out who owns the name, and what concept it can be used for... (like mathematical sin and fun sin, or tree bark and dogs bark... it gets even worse when you consider other languages... [Say I'm in Spain, and I write a robotics package that has a function coger..., and somebody in Argentina writes a function coger that does something, well, XXX...]) I just don't see this as working for any length of time (and I think it is already breaking down with Julia... to me, the fact that DataFrames picked using ~ as a binary operator, when that might have been something that somebody wanted to use in the core language, shows how fragile things are now...) Scott On Saturday, April 25, 2015 at 5:27:10 PM UTC-4, Mauro wrote: I don't think it is realistic to expect be able to willy-nilly be 'using' any number of packages and it just works. The way you propose may work most of the time, however, there were some solid arguments made in this thread on how that can lead to hard to catch failures. And maybe more importantly, from a programmer's sanity perspective, I think it is imperative that one generic function does just one conceptual thing. Otherwise it gets really hard to figure out what a piece of code does. On Sat, 2015-04-25 at 22:24, Scott Jones scott.pa...@gmail.com wrote: On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote: I think this is just a different mindset than the one we've adopted. In the mindset you describe, there really *ought* to be only one function with each
[julia-users] Re: PyPlot : one plot after the other and not simultaneously
also, what happens on your system when you change lines like this: PyPlot.plot(x,y1,color=red,marker=*,linestyle=none) to lines like this: PyPlot.plot(x,y1,color=red,marker=*,linestyle=none,block=true) hopefully, more later ... On Saturday, April 25, 2015 at 3:55:58 PM UTC-7, cdm wrote: i may be able to try this from the REPL later today ... in the meantime, what is the result of using PyCall pygui() on your Julia setup? On Saturday, April 25, 2015 at 3:23:32 PM UTC-7, Ferran Mazzanti wrote: Surpsisingly that didn't work either, but shows a strange ehaviour instead: three figure frames (figure boxes) are opened: figure 1 has once again both plots merged, while figures 2 and 3 show the canvas with nothin (fig.3) and the canvas with the axes (fig.2), but the plots themselves are merged in fig.1 as I mentioned (?)... Have you tried that form the command line REPL? That seems to be different from the IJulia notebook behavior...
Re: [julia-users] Re: Defining a function in different modules
I think you are again misunderstanding... I am *not* writing generic code. I am writing code that accesses database A, with names like connect, set_record, get_record, disconnect It's connect takes an argument of type A.DBManager, with some parameters like address, port, user, password, and returns an A.DBConnection object. There is absolutely no ambiguity with the Base.connect, nor is the interface necessarily even the same, *however*, it is what the users of database A would *expect* as far as names (possibly identical names to database A's C bindings). I also use some other code that extends that package, say BetterA, adding useful stuff like being able to serialize / deserialize Julia objects, and use set_record and get_record. That code was written with A in mind, and *explicitly* imports set_record and get_record, extends them, and exports them. My code does using A, using BetterA, and then does things like: myconn = connect(aManager, 127.0.0.1, 3000, scott, ) ; set_record(myconn, myjuliaobject) That set_record is actually handled nicely by multiple dispatch, the set_record in BetterA takes the Julia object, builds a string, and then calls A's set_record. If I understand correctly (and this is why I said at the very beginning, part of this may be my newness to Julia), then if I have to explicitly reference A.set_record, it will not work, because it will *not* dispatch to BetterA.set_record... Is that correct or not? Note, another reason I *don't* want to have to specify the module/package, is what happens if I want to use another package, that implements the same interface? For example, I started out using MongoDB.connect, MongoDB.set_document!, etc., but then my old classmate, friend and great 6.111 partner Brad Kuzsmaul comes along and convinces me that TokuMX is the greatest thing since sliced bread, so now I want to simply do: using TokuMX instead of using MongoDB, and everything is hunky-dory, but I'll be very sad if I had to go in and edit all the code to say TokuMX.set_document instead of MongoDB.set_document!. Now, after I've gotten my code working for multiple data sources I realize I need to connect to a KVS to use as the backend... So, I want to use a package GTM, that has a connect(gtm_manager, cluster, namespace), and a set_node!(gtmconnect, global, value, subscripts...). Later, I discover that there is another package GlobalsDB, that implements the same interface, and so I have the same issue, I don't want to have been forced to not do using, when there are absolutely no ambiguities, and I really don't want to have to use module names on my calls! The important point is that there can be different, unambiguous, perfectly valid sets of functions, which do not implement the same interface, but which may indeed implement different interfaces (MongoDB TokuMX may implement some sort of Document DB interface, while GTM GlobalsDB implement an ANSI M interface, and MySQL Postgres SQL_Server ODBC all implement a SQL interface... and *all* of them are going to want to call things by the names that make sense to users of their systems... and those users are also going to want to be able to use multiple interfaces without hassle) This is all very real world... @kevin I hope this answers your question as well On Saturday, April 25, 2015 at 6:56:55 PM UTC-4, Jeff Bezanson wrote: In general connect(x, y, z) is dynamically dispatched: you don't always know the type of `x`. So you wouldn't be able to write *generic* code that uses connect. In generic code, there really can be only one interface: if I write code that's supposed to work for any `x`, and I say `connect(x, address, port)`, like it or not my code only works for one of A and B, not both. On Sat, Apr 25, 2015 at 6:25 PM, Scott Jones scott.pa...@gmail.com javascript: wrote: No, not at all. I have a bunch of code written using package A. It knows what the correct arguments are to the connect function for type AConnectionManager. I did using A, because having to specify all the time which package (however short the name is), and it means that I wouldn't be able to use other packages with were designed to extend package A (and did use the import A to extend the functions with new methods). Then I need to connect to another database package, that also used the name connect, with other arguments, but no conflicting signatures at all. It has a connect(BConnectionManager, namespacename, globalname) function (with a set of methods). There might also be further packages which extend module B's functions, explicitly doing import B export extendedfunction I think that should work just fine, but you are saying that I *must* specify B.connect, which then also means (AFAIK), that I won't get a C.connect that extends B.connect (and intended to). Why do you want to restrict what can be done, because you have this view
[julia-users] Re: Custom Array type
Some explanation: Now that Julia thinks that Cube is an array, it assumes that these functions are defined. So when you call show, it will try to display it as an array. By the way I forgot the most important one: getindex(c::Cube, i...) = c.data[i...] setindex!(c::Cube, value, i...) = c.data[i...] = value Am Samstag, 25. April 2015 13:50:52 UTC+2 schrieb Marcus Appelros: Consider the definitions: type Cubes:AbstractArray end sum(cubes::Cubes)=sum(convert(Array,cubes).^3) Is it possible to make this work? To create a custom array that has indexing and all at inception? Looked up the definition of Array and it is in the commented section on types implemented in C, its constructor is a ccall, if it isn't possible in pure julia would it be possible with C-code that doesn't prompt a rebuild?
[julia-users] Re: Custom Array type
You need to implement the minimal array interface.
Something along these lines:
length(c::Cube) = length(c.data)
eltype{T,N}(c::Cube{T,N}) = T
ndims{T,N}(c::Cube{T,N}) = N
size(c::Cube) = size(c.data)
size((c::Cube, i::Integer) = size(c.data, i)
Am Samstag, 25. April 2015 13:50:52 UTC+2 schrieb Marcus Appelros:
Consider the definitions:
type Cubes:AbstractArray
end
sum(cubes::Cubes)=sum(convert(Array,cubes).^3)
Is it possible to make this work? To create a custom array that has
indexing and all at inception? Looked up the definition of Array and it is
in the commented section on types implemented in C, its constructor is a
ccall, if it isn't possible in pure julia would it be possible with C-code
that doesn't prompt a rebuild?
Re: [julia-users] Re: Defining a function in different modules
Scott, the behavior you're trying to get sounds to me like IF this function exists in Base then I want to extend it, otherwise just make my own version of the function. That strikes me as a hack. What we've tended to do is let everybody define whatever they want. Then if we see the same name appearing in multiple packages, we decide if there is indeed a common interface, and if so move the packages to using it, e.g. by creating something like StatsBase or maybe adding something to Base. But we don't want Base to grow much more, if at all. Getting an error for using both Base and your package seems annoying, but alternatives that involve doing something silently surely must be considered worse. If a colliding name gets added to Base, the default behavior should not be to assume that you meant to interfere with its behavior. On Sat, Apr 25, 2015 at 1:57 PM, Jeff Bezanson jeff.bezan...@gmail.com wrote: Michael, that's not a bad summary. I would make a couple edits. You don't really need to qualify *all* uses. If you want to use `foo` from module `A`, you can put `import A.foo` at the top and then use `foo` in your code. That will have no surprises and no breakage. Also I think calling it SuperSecretBase makes it sound worse than it is. You can have modules that describe a certain named interface, and then other modules extend it. Which reminds me that I need to implement #8283, so you can introduce functions without adding methods yet. On Sat, Apr 25, 2015 at 12:31 PM, Stefan Karpinski ste...@karpinski.org wrote: Scott, I'm not really understanding your problem. Can you give an example? On Sat, Apr 25, 2015 at 11:53 AM, Scott Jones scott.paul.jo...@gmail.com wrote: A problem I'm running into is the following (maybe the best practice for this is documented, and I just to stupid to find it!): I have created a set of functions, which use my own type, so they should never be ambiguous. I would like to export them all, but I have to import any names that already exist... Then tomorrow, somebody adds that name to Base, and my code no longer works... I dislike having to explicitly import names to extend something, how am I supposed to know in advance all the other names that could be used? What am I doing wrong? On Saturday, April 25, 2015 at 11:20:14 AM UTC-4, Stefan Karpinski wrote: I think you're probably being overly optimistic about how infrequently there will be dispatch ambiguities between unrelated functions that happen to have the same name. I would guess that if you try to merge two unrelated generic functions, ambiguities will exist more often than not. If you were to automatically merge generic functions from different modules, there are two sane ways you could handle ambiguities: warn about ambiguities when merging happens; raise an error when ambiguous calls actually occur. Warning when the ambiguity is caused is how we currently deal with ambiguities in individual generic functions. This seems like a good idea, but it turns out to be extremely annoying. In practice, there are fairly legitimate cases where you can have ambiguous intersections between very generic definitions and you just don't care because the ambiguous case makes no sense. This is especially true when loosely related modules extend shared generic functions. As a result, #6190 has gained a lot of support. If warning about ambiguities in a single generic function is annoying, warning about ambiguities when merging different generic functions that happen share a name would be a nightmare. Imagine popular packages A and B both export a function `foo`. Initially there are no ambiguities, so things are fine. Then B adds some methods to its `foo` that introduce ambiguities with A's `foo`. In isolation A and B are both fine – so neither package author sees any warnings or problems. But suddenly every package in the ecosystem that uses both A and B – which is a lot since they're both very popular – is spewing warnings upon loading. Who is responsible? Package A didn't even change anything. Package B just added some methods to its own function and has no issues in isolation. How would someone using both A and B avoid getting these warnings? They would have to stop writing `using A` or `using B` and instead explicitly import all the names they need from either A or B. To avoid inflicting this on their users, A and B would have to carefully coordinate to avoid any ambiguities between all of their generic functions. Except that it's not just A and B – it's all packages. At that point, why have namespaces with exports at all? What if we only raise an error when making calls to `foo` that are ambiguous between `A.foo` and `B.foo`? This eliminates the warning annoyance, which is nice. But it makes code that uses A and B that calls `foo` brittle in dangerous ways. Suppose, for example, you call `foo(x,y)` somewhere and initially this can only mean `A.foo` so things
Re: [julia-users] Set construction
T_GENERATING_BUS[k] = union(T_GENERATING_BUS[k],j)
On this line, you are trying to access the k-th element of T_GENERATING_BUS,
but you've declared it as a 0-element vector. You need to initialize it
first. Instead of:
T_GENERATING_BUS = Set[]
try using:
T_GENERATING_BUS = [Set() for i = 1:maximum(BUS)]
On Sat, Apr 25, 2015 at 2:41 PM fabrizio.lacalan...@gmail.com wrote:
Hi, very newby in Julia/JuMP, my problem is
i have a set of power gen and attached nodes in a grid in this format
PowerGen_ID Node
1 1
2 2
3 1
4 2
i would like to construct a set T_GENERATING_BUS for each node that
contains the Power Gen attached to it
i.e.
T_GENERATING_BUS[1]={1,3};
T_GENERATING_BUS[2]={2,4};
i tried something like:
T_GENERATING_BUS = Set[]
for k in BUS
for j=1:gmax
if BUS_T[j] == k
T_GENERATING_BUS[k] = union(T_GENERATING_BUS[k],j)
end
end
end
but got an error bound
ERROR: BoundsError()
in getindex at array.jl:246 (repeats 2 times)
while loading E:\CodiciSorgente\ProgrammiJulia\UCOTS.jl, in expression
starting on line 101
the problem is that i don't know how to increase the dim of
T_GENERATING_BUS
Any hints?
Thanks
Fabrizio
Re: [julia-users] Re: Defining a function in different modules
On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote: I think this is just a different mindset than the one we've adopted. In the mindset you describe, there really *ought* to be only one function with each name, in other words a single global namespace. As long as all new definitions for a function have disjoint signatures, there are no conflicts. To deal with conflicts, each module has its own view of a function that resolves conflicts in favor of its definitions. As a practical point, *why* should I have to know about every other package or module that users of my package might possibly want to use at the same time? With the way it is now, it seems I have to force everybody to not use using, and use fully specified names, which seems utterly against the extensibility of Julia, because if I try to export a function, I must know the intentions of every user, which packages they might load, etc. that might possibly have the same name. I have a module that defines a packed database format, and I want to define a length, push!, and getindex methods... Then (for examples sake) I also want to define a foobar method that people can use, and be able to call it on objects from my module with just foobar(db,arg1,arg2) (where db is from my class). All is well and good, but then some user complains that they can't use my package and package newdb, because coincidentally they also defined a function called foobar, that does have a different signature. I believe they should be able to use both, as long as there aren't any real conflicts, *without* spurious warnings... This approach has a lot in common with class-based OO. For example in Python when you say `x.sin()`, the `sin` name belongs to a single method namespace. Sure there are different namespaces for *top level* definitions, but not for method names. If you want a different `sin` method, you need to make a new class, so the `x` part is different. This corresponds to the requirement you describe of methods referencing some new type from the same julia module. Well, that's not how we do things. For us, if two functions have the same name it's just a cosmetic coincidence, at least initially. In julia two functions can have the same name but refer to totally different concepts. For example you can have Base.sin, which computes the sine of a number, and Transgressions.sin, which implements all sorts of fun behavior. Say Base only defines sin(x::Float64), and Transgressions only defines sin(x::String). They're disjoint. However, if you say map(sin, [1.0, sloth, 2pi, gluttony]) you can't get both behaviors. You'll get a method error on either the 1.0 or the string. You have to decide which notion of `sin` you mean. We're not going to automatically merge the two functions. I'm not saying you should... on the other hand, if I have to functions from different packages, developed independently, that happen to have a name in common, (but with different signatures), the users should not have to somehow get the developers together (who may not even be around anymore), to somehow resolve the conflict (which would probably adversely affect other users of both packages if some names had to be changed) Then if we see the same name appearing in multiple packages, we decide if there is indeed a common interface, and if so move the packages to using it, e.g. by creating something like StatsBase or maybe adding something to Base. But we don't want Base to grow much more, if at all. I'm sorry, but that just seems like a recipe for disaster... you are saying that *after* users finally decide they want to use two packages together, that then somehow you will force the developers of the packages to agree on a common interface, or change the names of conflicting functions, or make everybody use names qualified with the module name(s)... As for your map, example... If instead, I have map(sin, [1.0, myslothdays, 2pi, mygluttonydays] ), where myslothdays and mygluttonydays both have the type MySinDiary, and there is a Transgressions.sin(x::Transgressions.MySinDiary) method... that should work, right? What is a good reason for it not to work? Scott On Sat, Apr 25, 2015 at 3:27 PM, Scott Jones scott.pa...@gmail.com javascript: wrote: My point is, if I have been careful, and export methods that always reference at least one of type defined locally in my module, so that they should always be unambiguous, I should NOT have to know about any other module (or Base) that a user of my module might also be using having a function with the same name, and should NOT have to do an import. For methods where I *am* trying to extend some type defined in another module/package or base, then yes, I believe you should do something explicitly to indicate that. I don't think there is any real conflict here... right now it is too restrictive when the
[julia-users] Re: Set construction
Thanks Iain,
this seems to work, at least in the costruction, but i have to deepen the
various commands. However...since i have to use this object in a cns like
that, you can - certainly - give me an hint since i get an error
ERROR: key not found: 3
sorry I am an old C++ guy
for h=1:hmax
for k in BUS
@addConstraint(mod, sum{pt[j,h], j in T_GENERATING_BUS[k]}
-node_load[k,h] == sum{p_flow[(n,b_from,b_to),h],(n,b_from,b_to) in
BRANCH}-sum{p_flow[(n,b_to,b_from),h],(n,b_to,b_from) in BRANCH})
end
end
On Saturday, April 25, 2015 at 8:41:56 PM UTC+2, Fabrizio wrote:
Hi, very newby in Julia/JuMP, my problem is
i have a set of power gen and attached nodes in a grid in this format
PowerGen_ID Node
1 1
2 2
3 1
4 2
i would like to construct a set T_GENERATING_BUS for each node that
contains the Power Gen attached to it
i.e.
T_GENERATING_BUS[1]={1,3};
T_GENERATING_BUS[2]={2,4};
i tried something like:
T_GENERATING_BUS = Set[]
for k in BUS
for j=1:gmax
if BUS_T[j] == k
T_GENERATING_BUS[k] = union(T_GENERATING_BUS[k],j)
end
end
end
but got an error bound
ERROR: BoundsError()
in getindex at array.jl:246 (repeats 2 times)
while loading E:\CodiciSorgente\ProgrammiJulia\UCOTS.jl, in expression
starting on line 101
the problem is that i don't know how to increase the dim of
T_GENERATING_BUS
Any hints?
Thanks
Fabrizio
[julia-users] Re: Is there a plotting package that works for a current 0.4 build?
My problem might have been at least partly that I had the latest tagged version, rather than the latest master, of most packages. It seems most of these are on top of things but haven't tagged a release yet, so Pkg.checkout() is likely to solve the problems. Thanks for all the answers! // T
Re: [julia-users] Newbie help... First implementation of 3D heat equation solver VERY slow in Julia
Ah! I am also a newbie, and am trying to get a sense for efficiency improvement in julia, and how it works, so I tried a few of the combination of suggestions here, and this doesn't make sense to me. Putting const in front of T and RHS in the original code does not change running time much, but it is critical for the performance of the following nested loops. With nested loops, without const, running time is much more than the original code. The following are the exact run times on my computer (for 100 time steps NT = 100): original code: 21 sec original code with const in front if T and RHS: 20 sec nested loops w/out const in front if T and RHS: 200 sec nested loops with const in front if T and RHS: 3 sec Also, @inbounds does not have much effect in any of the above cases, just a little! Any thoughts are appreciated! On Saturday, April 25, 2015 at 4:45:45 PM UTC-4, Kristoffer Carlsson wrote: It is definitely the slicing that is killing performance. Right now, slicing is expensive since you copy a whole new array for it. Putting const in front of T and RHS and using a loop like this (maybe some mistake but the principle is what is important) makes the code 10x faster: @inbounds for i=2:NX-1, j=2:NY-1, k=2:NZ-1 RHS[i,j,k] = dt*A*( (T[i-1,j,k]-2*T[i,j,k]+T[i+1,j,k])/dx2 + (T[i,j-1,k]-2*T[i,j,k]+T[i,j+1,k])/dy2 + (T[i,j,k-1]-2*T[i,j,k]+T[i,j,k+1])/dz2 ) T[i,j,k] = T[i,j,k] + RHS[i,j,k] end On Saturday, April 25, 2015 at 7:57:01 PM UTC+2, Johan Sigfrids wrote: I think it is all the slicing that is killing the performance. Maybe something like arrayviews or the new sub stuff on 0.4 would help. Alternatively devectorizing into a bunch of nested loops. On Saturday, April 25, 2015 at 8:42:09 PM UTC+3, Stefan Karpinski wrote: Stick const in front of T and RHS. On Sat, Apr 25, 2015 at 11:32 AM, Tim Holy tim@gmail.com wrote: Did you read through http://docs.julialang.org/en/release-0.3/manual/performance-tips/? You should memorize :-) the sections up through the Tools section; the rest you can consult as you discover you need them. --Tim On Saturday, April 25, 2015 01:03:38 AM Ángel de Vicente wrote: Hi, a complete Julia newbie here... I spent a couple of days learning the syntax and main aspects of Julia, and since I heard many good things about it, I decided to try a little program to see how it compares against the other ones I regularly use: Fortran and Python. I wrote a minimal program to solve the 3D heat equation in a cube of 100x100x100 points in the three languages and the time it takes to run in each one is: Fortran: ~7s Python: ~33s Julia:~80s The code runs for 1000 iterations, and I'm being nice to Julia, since the programs in Fortran and Python write 100 HDF5 files with the complete 100^3 data (every 10 iterations). I attach the code (and you can also get it at: http://pastebin.com/y5HnbWQ1) Am I doing something obviously wrong? Any suggestions on how to improve its speed? Thanks a lot, Ángel de Vicente
Re: [julia-users] Re: Defining a function in different modules
The situation I was describing is that there is: module A type Foo end f(a::Any) ... f(a::Foo) ... which expects f(a) to dispatch to its ::Any version for all calls where a is not a Foo, and there is: module B type Bar end f(a::Bar) ... so a user program (assuming the f() functions combined): using A using B b = Bar() f(b) now module A is written expecting this to dispatch to A.f(::Any) and module B is written expecting this to dispatch to B.f(::Bar) so there is an ambiguity which only the user can resolve, nothing tells the compiler which the user meant. Cheers Lex On Sunday, April 26, 2015 at 12:00:50 PM UTC+10, Michael Francis wrote: I don't think Any in the same position is a conflict. This would be more of an issue if Julia did not support strong typing, but it does and is a requirement of dynamic dispatch. Consider function foo( x::Any ) Will never be chosen over Type Foo end function foo( x::Foo ) As such I don't get the argument that if I define functions against types I define they cause conflicts. Being in the position of having implemented a good number of modules and being bitten in this way both by my own dev and by changes to other modules I'm very concerned with the direction being taken. I do think formalization of interfaces to modules ( and behaviors) would go a long way but expecting a diverse group of people to coordinate is not going to happen without strong and enforced constructs. As an example I have implemented a document store database interface, this is well represented by an associative collection. It also has a few specific methods which would apply to many databases. It would be nice to be able to share the definition of these common interfaces. I don't advocate adding these to base so how should it be done?
Re: [julia-users] Re: Defining a function in different modules
Scott-- yes! If BetterA imports and extends a function from A, it is exactly the same function object. A.func and BetterA.func will be identical. Problems only enter if A and BetterA were developed in total isolation, and the authors just happened to pick the same name. The way to go here would be to have the DocumentDB module define an interface, and then both MongoDB and TokuMX extend it. What I don't get is that elsewhere in your argument, you seem to say that coordinating and agreeing on an interface is a non-starter. But I just don't see how you could talk to both MongoDB and TokuMX with the same code unless they agreed on an interface. Now consider `connect`. This might be common to both DocumentDB and SQLDB. Is it similar enough that it should go in an even more abstract interface GeneralDB? I'm not sure, but I think this is exactly the kind of interface design process that happens in any OO language. In Java, you can have a `connect` method whether or not you implement a `Connectable` interface. But only if you explicitly refer to the Connectable interface will you be able to work with code that requires it. I think the same kind of thing is happening here. You can just write a `connect` function, or you can say `import Connectable.connect` first, in which case you will be extending the public `connect` function. On Sun, Apr 26, 2015 at 12:25 AM, ele...@gmail.com wrote: The situation I was describing is that there is: module A type Foo end f(a::Any) ... f(a::Foo) ... which expects f(a) to dispatch to its ::Any version for all calls where a is not a Foo, and there is: module B type Bar end f(a::Bar) ... so a user program (assuming the f() functions combined): using A using B b = Bar() f(b) now module A is written expecting this to dispatch to A.f(::Any) and module B is written expecting this to dispatch to B.f(::Bar) so there is an ambiguity which only the user can resolve, nothing tells the compiler which the user meant. Cheers Lex On Sunday, April 26, 2015 at 12:00:50 PM UTC+10, Michael Francis wrote: I don't think Any in the same position is a conflict. This would be more of an issue if Julia did not support strong typing, but it does and is a requirement of dynamic dispatch. Consider function foo( x::Any ) Will never be chosen over Type Foo end function foo( x::Foo ) As such I don't get the argument that if I define functions against types I define they cause conflicts. Being in the position of having implemented a good number of modules and being bitten in this way both by my own dev and by changes to other modules I'm very concerned with the direction being taken. I do think formalization of interfaces to modules ( and behaviors) would go a long way but expecting a diverse group of people to coordinate is not going to happen without strong and enforced constructs. As an example I have implemented a document store database interface, this is well represented by an associative collection. It also has a few specific methods which would apply to many databases. It would be nice to be able to share the definition of these common interfaces. I don't advocate adding these to base so how should it be done?
Re: [julia-users] How long will it take to build v0.4 if I already have built a v0.3
LLVM requires the most time, and the version has not been bumped so recompile will not be required. OpenBLAS is probably second and it has been bumped, so will require recompile. By the way, to track 0.4-pre (development version) you need `git checkout master`. However, do be aware that there is *a lot* of breakage in packages running against 0.4-dev right now due to some recent changes (see recent threads here and on julia-dev). Many packages are still catching up. Running 0.4 is not recommended right now unless you are fixing packages, or you know that any packages you need have been updated. See status here: http://pkg.julialang.org/pulse.html On Sat, Apr 25, 2015 at 10:02 PM, Sisyphuss zhengwend...@gmail.com wrote: I built Julia v0.3 from the source code. It took me a lot of time. Now if I want to git checkout v0.4, will it take me a lot of time to build again?
[julia-users] How to call the original method that was overloaded?
For example, if I want to overload the Base.display(::Vector) to repress the display when the vector is too long, I coded as below: julia import Base.display julia display(X::Vector)=length(X)10?print(Too long to show.):Base. display(X) display (generic function with 17 methods) julia display([1,2,3]) ERROR: stack overflow in display at none:1 (repeats 39998 times) I want to call the original Base.display when the length of vector is less than 10, but it is became a dead recurring. Is there any way to do it?
Re: [julia-users] Re: Defining a function in different modules
That's why I had asked the following: If I understand correctly (and this is why I said at the very beginning, part of this may be my newness to Julia), then if I have to explicitly reference A.set_record, it will not work, because it will *not* dispatch to BetterA.set_record... Is that correct or not? So you are saying that that is not so, that once I've extended a function in A in my module BetterA, it doesn't matter if I call that function as A.func or BetterA.func? Scott On Saturday, April 25, 2015 at 10:24:54 PM UTC-4, Stefan Karpinski wrote: I think there's some confusion here. If BetterA extends a function from A then those are the same function object and calling A's function is the same as calling BetterA's function by that name. If several modules implement a common interface, they shouldn't simply happen to use the same names – they should implement different methods of the same function object, inherited from a common namespace. These methods should dispatch on a connection object that determines who's method to use. On Apr 25, 2015, at 8:02 PM, Scott Jones scott.pa...@gmail.com javascript: wrote: I think you are again misunderstanding... I am *not* writing generic code. I am writing code that accesses database A, with names like connect, set_record, get_record, disconnect It's connect takes an argument of type A.DBManager, with some parameters like address, port, user, password, and returns an A.DBConnection object. There is absolutely no ambiguity with the Base.connect, nor is the interface necessarily even the same, *however*, it is what the users of database A would *expect* as far as names (possibly identical names to database A's C bindings). I also use some other code that extends that package, say BetterA, adding useful stuff like being able to serialize / deserialize Julia objects, and use set_record and get_record. That code was written with A in mind, and *explicitly* imports set_record and get_record, extends them, and exports them. My code does using A, using BetterA, and then does things like: myconn = connect(aManager, 127.0.0.1, 3000, scott, ) ; set_record(myconn, myjuliaobject) That set_record is actually handled nicely by multiple dispatch, the set_record in BetterA takes the Julia object, builds a string, and then calls A's set_record. If I understand correctly (and this is why I said at the very beginning, part of this may be my newness to Julia), then if I have to explicitly reference A.set_record, it will not work, because it will *not* dispatch to BetterA.set_record... Is that correct or not? Note, another reason I *don't* want to have to specify the module/package, is what happens if I want to use another package, that implements the same interface? For example, I started out using MongoDB.connect, MongoDB.set_document!, etc., but then my old classmate, friend and great 6.111 partner Brad Kuzsmaul comes along and convinces me that TokuMX is the greatest thing since sliced bread, so now I want to simply do: using TokuMX instead of using MongoDB, and everything is hunky-dory, but I'll be very sad if I had to go in and edit all the code to say TokuMX.set_document instead of MongoDB.set_document!. Now, after I've gotten my code working for multiple data sources I realize I need to connect to a KVS to use as the backend... So, I want to use a package GTM, that has a connect(gtm_manager, cluster, namespace), and a set_node!(gtmconnect, global, value, subscripts...). Later, I discover that there is another package GlobalsDB, that implements the same interface, and so I have the same issue, I don't want to have been forced to not do using, when there are absolutely no ambiguities, and I really don't want to have to use module names on my calls! The important point is that there can be different, unambiguous, perfectly valid sets of functions, which do not implement the same interface, but which may indeed implement different interfaces (MongoDB TokuMX may implement some sort of Document DB interface, while GTM GlobalsDB implement an ANSI M interface, and MySQL Postgres SQL_Server ODBC all implement a SQL interface... and *all* of them are going to want to call things by the names that make sense to users of their systems... and those users are also going to want to be able to use multiple interfaces without hassle) This is all very real world... @kevin I hope this answers your question as well On Saturday, April 25, 2015 at 6:56:55 PM UTC-4, Jeff Bezanson wrote: In general connect(x, y, z) is dynamically dispatched: you don't always know the type of `x`. So you wouldn't be able to write *generic* code that uses connect. In generic code, there really can be only one interface: if I write code that's supposed to work for any `x`, and I say `connect(x, address, port)`, like it or not my code only works for one of A and B, not
Re: [julia-users] How long will it take to build v0.4 if I already have built a v0.3
if you remove the `usr` folder, it'll only rebuild what it needs to. but since almost every dependency has been updated since v0.3, yes it'll take awhile. On Sat, Apr 25, 2015 at 10:02 PM Sisyphuss zhengwend...@gmail.com wrote: I built Julia v0.3 from the source code. It took me a lot of time. Now if I want to git checkout v0.4, will it take me a lot of time to build again?
[julia-users] Re: Naming convention
And just before that, it says this:
- Word separation can be indicated by underscores ('_'), but use of
underscores is discouraged unless the name would be hard to read otherwise
.
The documentation is not very consistent...
On Saturday, April 25, 2015 at 10:30:36 PM UTC-4, Sisyphuss wrote:
I find something contradictory :
http://docs.julialang.org/en/latest/manual/variables/#stylistic-conventions
*Names of functions and macros are in lower case, without underscores.*
On Saturday, April 25, 2015 at 3:07:46 PM UTC+2, Scott Jones wrote:
Umm... the style guide for Julia says *to* use underscore for longer
names, *not* camelcase:
- modules and type names use capitalization and camel case:module
SparseMatrix, immutable UnitRange.
- functions are lowercase (maximum()
http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.maximum
, convert()
http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.convert)
and, when readable, with multiple words squashed together (isequal()
http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.isequal,
haskey()
http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.haskey).
When necessary, use underscores as word separators. Underscores are also
used to indicate a combination of concepts (remotecall_fetch()
http://docs.julialang.org/en/release-0.3/stdlib/parallel/#Base.remotecall_fetch
as
a more efficient implementation of remotecall(fetch(...))) or as
modifiers (sum_kbn()
http://docs.julialang.org/en/release-0.3/stdlib/arrays/#Base.sum_kbn
).
- conciseness is valued, but avoid abbreviation (indexin()
http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.indexin
rather
thanindxin()) as it becomes difficult to remember whether and how
particular words are abbreviated.
Personally, I think the Julia style guide gets it right... also, there
have even been studies that show that words separated by _ are easier to
read (20% faster to read!) than words with no spaces and camel cased...
Scott
On Saturday, April 25, 2015 at 6:43:44 AM UTC-4, François Fayard wrote:
Hi,
I would like to talk about naming convention. I think it's fine to have
short names in a langage with few keywords such as C (memcpy), but a
langage such as Julia that wants to be also high level with a huge standard
library needs convention because the langage might become very large. I
find the convention used by Mathematica the best ever made. Nothing is
shortened except a few exceptions and consistent use of CamlCase. On the
other hand, Matlab is probably one of the worst thing that happen in terms
of naming: no consistency at all! I suspect that Cleve Moler who started
Matlab not used LAPACK but also the Fortran 77 naming convention which was
only there only for technical reasons ;-)
I've seen that the naming convention for function in Julia looks like
the same as in Python: everything must be lowercase, and don't use
underscore. Let's look at different naming conventions, the first one being
the one used by Julia.
1) daysinmonth()
2) daysInMonth()
3) days_in_month()
I find the first one the most difficult to read. I tend to prefer the
last one, but the second one is also easy to read. The fact that Julia uses
the first one and the fact that many names are shortened, makes reading
code with functions you've never seen a pain. For instance reading a name
iso... my mind does not understand if we at talking about a function that
returns a Bool (is suggests that) or something that has been standardised
(ISO). Using the second naming convention would make things easier. Also it
would prevent people using underscores as we have in the standard library
without any clear reason.
I don't find any disadvantage for the second naming convention over the
first one. So why do people use the first one?
Re: [julia-users] Is there a REPL shortcut for a subscript numeral?
I really enjoy the unicode feature. It's too bad that julia ‖A‖² = 1.234 ERROR: syntax: invalid character ‖ On Friday, April 24, 2015 at 5:05:38 PM UTC-4, Jiahao Chen wrote: The manual has a list of supported tab completions: http://julia.readthedocs.org/en/release-0.3/manual/unicode-input/ http://julia.readthedocs.org/en/latest/manual/unicode-input/
[julia-users] Re: Naming convention
I find something contradictory : http://docs.julialang.org/en/latest/manual/variables/#stylistic-conventions *Names of functions and macros are in lower case, without underscores.* On Saturday, April 25, 2015 at 3:07:46 PM UTC+2, Scott Jones wrote: Umm... the style guide for Julia says *to* use underscore for longer names, *not* camelcase: - modules and type names use capitalization and camel case:module SparseMatrix, immutable UnitRange. - functions are lowercase (maximum() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.maximum , convert() http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.convert) and, when readable, with multiple words squashed together (isequal() http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.isequal, haskey() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.haskey). When necessary, use underscores as word separators. Underscores are also used to indicate a combination of concepts (remotecall_fetch() http://docs.julialang.org/en/release-0.3/stdlib/parallel/#Base.remotecall_fetch as a more efficient implementation of remotecall(fetch(...))) or as modifiers (sum_kbn() http://docs.julialang.org/en/release-0.3/stdlib/arrays/#Base.sum_kbn ). - conciseness is valued, but avoid abbreviation (indexin() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.indexin rather thanindxin()) as it becomes difficult to remember whether and how particular words are abbreviated. Personally, I think the Julia style guide gets it right... also, there have even been studies that show that words separated by _ are easier to read (20% faster to read!) than words with no spaces and camel cased... Scott On Saturday, April 25, 2015 at 6:43:44 AM UTC-4, François Fayard wrote: Hi, I would like to talk about naming convention. I think it's fine to have short names in a langage with few keywords such as C (memcpy), but a langage such as Julia that wants to be also high level with a huge standard library needs convention because the langage might become very large. I find the convention used by Mathematica the best ever made. Nothing is shortened except a few exceptions and consistent use of CamlCase. On the other hand, Matlab is probably one of the worst thing that happen in terms of naming: no consistency at all! I suspect that Cleve Moler who started Matlab not used LAPACK but also the Fortran 77 naming convention which was only there only for technical reasons ;-) I've seen that the naming convention for function in Julia looks like the same as in Python: everything must be lowercase, and don't use underscore. Let's look at different naming conventions, the first one being the one used by Julia. 1) daysinmonth() 2) daysInMonth() 3) days_in_month() I find the first one the most difficult to read. I tend to prefer the last one, but the second one is also easy to read. The fact that Julia uses the first one and the fact that many names are shortened, makes reading code with functions you've never seen a pain. For instance reading a name iso... my mind does not understand if we at talking about a function that returns a Bool (is suggests that) or something that has been standardised (ISO). Using the second naming convention would make things easier. Also it would prevent people using underscores as we have in the standard library without any clear reason. I don't find any disadvantage for the second naming convention over the first one. So why do people use the first one?
Re: [julia-users] Re: Defining a function in different modules
I think there's some confusion here. If BetterA extends a function from A then those are the same function object and calling A's function is the same as calling BetterA's function by that name. If several modules implement a common interface, they shouldn't simply happen to use the same names – they should implement different methods of the same function object, inherited from a common namespace. These methods should dispatch on a connection object that determines who's method to use. On Apr 25, 2015, at 8:02 PM, Scott Jones scott.paul.jo...@gmail.com wrote: I think you are again misunderstanding... I am *not* writing generic code. I am writing code that accesses database A, with names like connect, set_record, get_record, disconnect It's connect takes an argument of type A.DBManager, with some parameters like address, port, user, password, and returns an A.DBConnection object. There is absolutely no ambiguity with the Base.connect, nor is the interface necessarily even the same, *however*, it is what the users of database A would *expect* as far as names (possibly identical names to database A's C bindings). I also use some other code that extends that package, say BetterA, adding useful stuff like being able to serialize / deserialize Julia objects, and use set_record and get_record. That code was written with A in mind, and *explicitly* imports set_record and get_record, extends them, and exports them. My code does using A, using BetterA, and then does things like: myconn = connect(aManager, 127.0.0.1, 3000, scott, ) ; set_record(myconn, myjuliaobject) That set_record is actually handled nicely by multiple dispatch, the set_record in BetterA takes the Julia object, builds a string, and then calls A's set_record. If I understand correctly (and this is why I said at the very beginning, part of this may be my newness to Julia), then if I have to explicitly reference A.set_record, it will not work, because it will *not* dispatch to BetterA.set_record... Is that correct or not? Note, another reason I *don't* want to have to specify the module/package, is what happens if I want to use another package, that implements the same interface? For example, I started out using MongoDB.connect, MongoDB.set_document!, etc., but then my old classmate, friend and great 6.111 partner Brad Kuzsmaul comes along and convinces me that TokuMX is the greatest thing since sliced bread, so now I want to simply do: using TokuMX instead of using MongoDB, and everything is hunky-dory, but I'll be very sad if I had to go in and edit all the code to say TokuMX.set_document instead of MongoDB.set_document!. Now, after I've gotten my code working for multiple data sources I realize I need to connect to a KVS to use as the backend... So, I want to use a package GTM, that has a connect(gtm_manager, cluster, namespace), and a set_node!(gtmconnect, global, value, subscripts...). Later, I discover that there is another package GlobalsDB, that implements the same interface, and so I have the same issue, I don't want to have been forced to not do using, when there are absolutely no ambiguities, and I really don't want to have to use module names on my calls! The important point is that there can be different, unambiguous, perfectly valid sets of functions, which do not implement the same interface, but which may indeed implement different interfaces (MongoDB TokuMX may implement some sort of Document DB interface, while GTM GlobalsDB implement an ANSI M interface, and MySQL Postgres SQL_Server ODBC all implement a SQL interface... and *all* of them are going to want to call things by the names that make sense to users of their systems... and those users are also going to want to be able to use multiple interfaces without hassle) This is all very real world... @kevin I hope this answers your question as well On Saturday, April 25, 2015 at 6:56:55 PM UTC-4, Jeff Bezanson wrote: In general connect(x, y, z) is dynamically dispatched: you don't always know the type of `x`. So you wouldn't be able to write *generic* code that uses connect. In generic code, there really can be only one interface: if I write code that's supposed to work for any `x`, and I say `connect(x, address, port)`, like it or not my code only works for one of A and B, not both. On Sat, Apr 25, 2015 at 6:25 PM, Scott Jones scott.pa...@gmail.com wrote: No, not at all. I have a bunch of code written using package A. It knows what the correct arguments are to the connect function for type AConnectionManager. I did using A, because having to specify all the time which package (however short the name is), and it means that I wouldn't be able to use other packages with were designed to extend package A (and did use the import A to extend the functions with new methods). Then I need to connect to another
[julia-users] Naming convention
Hi, I would like to talk about naming convention. I think it's fine to have short names in a langage with few keywords such as C (memcpy), but a langage such as Julia that wants to be also high level with a huge standard library needs convention because the langage might become very large. I find the convention used by Mathematica the best ever made. Nothing is shortened except a few exceptions and consistent use of CamlCase. On the other hand, Matlab is probably one of the worst thing that happen in terms of naming: no consistency at all! I suspect that Cleve Moler who started Matlab not used LAPACK but also the Fortran 77 naming convention which was only there only for technical reasons ;-) I've seen that the naming convention for function in Julia looks like the same as in Python: everything must be lowercase, and don't use underscore. Let's look at different naming conventions, the first one being the one used by Julia. 1) daysinmonth() 2) daysInMonth() 3) days_in_month() I find the first one the most difficult to read. I tend to prefer the last one, but the second one is also easy to read. The fact that Julia uses the first one and the fact that many names are shortened, makes reading code with functions you've never seen a pain. For instance reading a name iso... my mind does not understand if we at talking about a function that returns a Bool (is suggests that) or something that has been standardised (ISO). Using the second naming convention would make things easier. Also it would prevent people using underscores as we have in the standard library without any clear reason. I don't find any disadvantage for the second naming convention over the first one. So why do people use the first one?
[julia-users] Re: Online regression algorithms
This is great... I haven't looked at StreamStats yet. It certainly seems like the right package to extend. I'll start a discussion there. Thanks.
Re: [julia-users] Auto warn for unstable types
Iain, I love this idea! Even languages like JavaScript and Visual Basic which embraced dynamic typing added directives to help users avoid the most obvious problems. With the wonderful richness of Julia's type system, it would be nice to be able to 'opt in' to a fully enforced function or module. I'm guessing this will be much more useful when we can type functions? On Friday, April 24, 2015 at 12:49:22 PM UTC-4, Iain Dunning wrote: I think something I'd use was a @strict macro that annotates a function as something I'm willing to get plenty of warnings from, that'd be quite nice. We have the ability to add such compiler flags now, right? On Friday, April 24, 2015 at 12:21:06 PM UTC-4, Peter Brady wrote: Other startup flags have a user/all option which would conceivably solve the problem of getting too many warnings on startup. My views are likely colored by my use case - solving systems of PDEs. Since my work is strictly numerical, I've never met an ::Any that served a useful purpose. On Friday, April 24, 2015 at 9:50:17 AM UTC-6, Tim Holy wrote: Related ongoing discussion in https://github.com/JuliaLang/julia/issues/10980 But I don't think it's practical or desirable to warn about all type instability; there are plenty of cases where it's either a useful or unavoidable property. The goal of optimization should be to eliminate those cases that actually matter for performance, and not worry about the ones that don't. If you run your code (or just, start julia) and see 100 warnings scroll past, you won't know where to begin. --Tim On Friday, April 24, 2015 11:12:57 AM Stefan Karpinski wrote: Yes, I'd like to add exactly this kind of thing. On Fri, Apr 24, 2015 at 10:54 AM, Peter Brady peter...@gmail.com wrote: Tim Holy introduced me to the wonders of @code_warntype in this discussion https://groups.google.com/forum/#!topic/julia-users/sq5gj-3TdQU. I've since been using it to track down other instabilities in my code since it turns out that I'm very good at writing poor julia code. Are there any plans to incorporate automatic warnings about type unstable functions when they are compiled? Maybe even via a startup flag like `-Wunstable`? I would prefer that its on by default. This would go a long way towards helping me write much better code and probably help new users get more of the performance they were expecting.
Re: [julia-users] Re: Defining a function in different modules
Yes... I also would that explicit qualification would be a very good thing. (I also wish Julia also had explicit exception handling, a la CLU... exceptions in CLU didn't cost more than a normal return because of that rule, and it really helped when trying to figure out a clusters correctness) Scott On Saturday, April 25, 2015 at 9:46:00 AM UTC-4, Stefan Karpinski wrote: On Fri, Apr 24, 2015 at 8:51 PM, ele...@gmail.com javascript: wrote: I would have thought stopping intentional behaviour is non-Julian, but accidental errors should indeed be limited. Perhaps adding methods to other modules functions needs to explicit. I think that John Myles White was the first to start advocating for using explicit qualification every time you extend methods from Base or some other module than then one you're currently in. At first this felt a little annoying to me, but I've grown to like it and I do think this may be a good, low-tech solution. Forcing the programmer to be aware of the fact that they're extending someone else's generic function already helps a lot. If we provided some tooling for finding cases where people are monkey patching and made it widely available, then that might really solve the whole issue.
[julia-users] Re: Is there a plotting package that works for a current 0.4 build?
Gadfly is very close or nearly there, though it relies on changes to some downstream packages and I don't know if those have all been updated such that you'll get the edge versions if you grab Gadfly. https://github.com/dcjones/Gadfly.jl/pull/587 https://github.com/dcjones/Gadfly.jl/commit/4daa1759dbf90a10936e2bd21e0b3d0da70b8923 On Saturday, April 25, 2015 at 9:10:43 AM UTC-4, Steven G. Johnson wrote: PyPlot was updated for the tupocolypse; I don't know if it has broken again in the last day or two, though, but it should be easy to fix up again.
Re: [julia-users] Re: Qwt plotting
From the tiny bit I've used Qwt...it was quite a lot faster (5x?) than Cairo- based plotting. Tom, for the long term, Keno's Cxx.jl package would be an attractive way to get to Qwt from Julia. Myself, I'm still mostly interested in helping grow julia's native plotting packages. --Tim On Saturday, April 25, 2015 07:14:09 AM Tom Breloff wrote: It's been several years since I used matplotlib actively, but I think I switched to Qwt because its faster and better for panning/zooming. I don't think its as feature-rich for publication-quality plots. I have used it primarily for real time monitoring of financial time series and related analysis. For those that use matplotlib... Is is speedy and interactive enough for real time applications?
[julia-users] Re: Online regression algorithms
I've been working on https://github.com/joshday/OnlineStats.jl. The src/README shows the implementation progress. It's partially a playground for my research (on online algorithms for statistics). Please take a look and let me know what you think, but my regression stuff is currently in break-everything mode and will be cleaned up in less than a week.
[julia-users] Custom Array type
Consider the definitions: type Cubes:AbstractArray end sum(cubes::Cubes)=sum(convert(Array,cubes).^3) Is it possible to make this work? To create a custom array that has indexing and all at inception? Looked up the definition of Array and it is in the commented section on types implemented in C, its constructor is a ccall, if it isn't possible in pure julia would it be possible with C-code that doesn't prompt a rebuild?
[julia-users] Re: Naming convention
Umm... the style guide for Julia says *to* use underscore for longer names, *not* camelcase: - modules and type names use capitalization and camel case:module SparseMatrix, immutable UnitRange. - functions are lowercase (maximum() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.maximum , convert() http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.convert) and, when readable, with multiple words squashed together (isequal() http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.isequal, haskey() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.haskey). When necessary, use underscores as word separators. Underscores are also used to indicate a combination of concepts (remotecall_fetch() http://docs.julialang.org/en/release-0.3/stdlib/parallel/#Base.remotecall_fetch as a more efficient implementation of remotecall(fetch(...))) or as modifiers (sum_kbn() http://docs.julialang.org/en/release-0.3/stdlib/arrays/#Base.sum_kbn). - conciseness is valued, but avoid abbreviation (indexin() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.indexin rather thanindxin()) as it becomes difficult to remember whether and how particular words are abbreviated. Personally, I think the Julia style guide gets it right... also, there have even been studies that show that words separated by _ are easier to read (20% faster to read!) than words with no spaces and camel cased... Scott On Saturday, April 25, 2015 at 6:43:44 AM UTC-4, François Fayard wrote: Hi, I would like to talk about naming convention. I think it's fine to have short names in a langage with few keywords such as C (memcpy), but a langage such as Julia that wants to be also high level with a huge standard library needs convention because the langage might become very large. I find the convention used by Mathematica the best ever made. Nothing is shortened except a few exceptions and consistent use of CamlCase. On the other hand, Matlab is probably one of the worst thing that happen in terms of naming: no consistency at all! I suspect that Cleve Moler who started Matlab not used LAPACK but also the Fortran 77 naming convention which was only there only for technical reasons ;-) I've seen that the naming convention for function in Julia looks like the same as in Python: everything must be lowercase, and don't use underscore. Let's look at different naming conventions, the first one being the one used by Julia. 1) daysinmonth() 2) daysInMonth() 3) days_in_month() I find the first one the most difficult to read. I tend to prefer the last one, but the second one is also easy to read. The fact that Julia uses the first one and the fact that many names are shortened, makes reading code with functions you've never seen a pain. For instance reading a name iso... my mind does not understand if we at talking about a function that returns a Bool (is suggests that) or something that has been standardised (ISO). Using the second naming convention would make things easier. Also it would prevent people using underscores as we have in the standard library without any clear reason. I don't find any disadvantage for the second naming convention over the first one. So why do people use the first one?
Re: [julia-users] Re: Defining a function in different modules
On Fri, Apr 24, 2015 at 8:51 PM, ele...@gmail.com wrote: I would have thought stopping intentional behaviour is non-Julian, but accidental errors should indeed be limited. Perhaps adding methods to other modules functions needs to explicit. I think that John Myles White was the first to start advocating for using explicit qualification every time you extend methods from Base or some other module than then one you're currently in. At first this felt a little annoying to me, but I've grown to like it and I do think this may be a good, low-tech solution. Forcing the programmer to be aware of the fact that they're extending someone else's generic function already helps a lot. If we provided some tooling for finding cases where people are monkey patching and made it widely available, then that might really solve the whole issue.
[julia-users] Re: kernel restarts after running code
These did not work. In one of my functions I am returning a function (myfunc) in output that is defined like myfunc(x;args...) = g(x,y,z,m,n;args...). This was working up to now when I am using myfunc in another function (and also when I use it directly in the global scope). I guess that is causing some problems, but I can't figure out why yet. I am using Debug package, but getting some weird outputs! On Saturday, April 25, 2015 at 12:28:53 AM UTC-4, David P. Sanders wrote: El viernes, 24 de abril de 2015, 21:44:00 (UTC-5), Pooya escribió: I have been using julia in Mac Terminal and IJulia notebook for a while and they have been fine. But now I am getting this error: The kernel appears to have died. It will restart automatically. in IJulia, and the following in Terminal after I run one of my codes. It restarts the kernel in both cases! Can anyone help? julia(8724,0x7fff7315e310) malloc: *** error for object 0x7feed745df10: pointer being realloc'd was not allocated *** set a breakpoint in malloc_error_break to debug signal (6): Abort trap: 6 __pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line) Abort trap: 6 My usual solution for these kinds of problems (i.e. problems in which it's unclear what the problem is and it was previously working!) is the following sequence, testing if it now works after each step (i) Pkg.update() (ii) Pkg.build(IJulia) (iii) Remove entire .julia directory and reinstall IJulia with Pkg.add(IJulia). (This is overkill for what would basically be get the latest version of all dependencies, but it can't do any harm...) Of course it might be an actual bug, in which case these steps won't help at all...
[julia-users] Re: Qwt plotting
It's been several years since I used matplotlib actively, but I think I switched to Qwt because its faster and better for panning/zooming. I don't think its as feature-rich for publication-quality plots. I have used it primarily for real time monitoring of financial time series and related analysis. For those that use matplotlib... Is is speedy and interactive enough for real time applications?
Re: [julia-users] Naming convention
+1 I too really like the consistency and readability of Mathematica. On Sat, Apr 25, 2015, 6:43 AM François Fayard francois.fay...@gmail.com wrote: Hi, I would like to talk about naming convention. I think it's fine to have short names in a langage with few keywords such as C (memcpy), but a langage such as Julia that wants to be also high level with a huge standard library needs convention because the langage might become very large. I find the convention used by Mathematica the best ever made. Nothing is shortened except a few exceptions and consistent use of CamlCase. On the other hand, Matlab is probably one of the worst thing that happen in terms of naming: no consistency at all! I suspect that Cleve Moler who started Matlab not used LAPACK but also the Fortran 77 naming convention which was only there only for technical reasons ;-) I've seen that the naming convention for function in Julia looks like the same as in Python: everything must be lowercase, and don't use underscore. Let's look at different naming conventions, the first one being the one used by Julia. 1) daysinmonth() 2) daysInMonth() 3) days_in_month() I find the first one the most difficult to read. I tend to prefer the last one, but the second one is also easy to read. The fact that Julia uses the first one and the fact that many names are shortened, makes reading code with functions you've never seen a pain. For instance reading a name iso... my mind does not understand if we at talking about a function that returns a Bool (is suggests that) or something that has been standardised (ISO). Using the second naming convention would make things easier. Also it would prevent people using underscores as we have in the standard library without any clear reason. I don't find any disadvantage for the second naming convention over the first one. So why do people use the first one?
[julia-users] Re: Is there a plotting package that works for a current 0.4 build?
PyPlot was updated for the tupocolypse; I don't know if it has broken again in the last day or two, though, but it should be easy to fix up again.
Re: [julia-users] Re: Naming convention
I too like underscores. The thing that bugs me is that they aren't always used. I'm not a fan of conventions that involve judgment calls without an especially compelling reason. On Sat, Apr 25, 2015, 9:07 AM Scott Jones scott.paul.jo...@gmail.com wrote: Umm... the style guide for Julia says *to* use underscore for longer names, *not* camelcase: - modules and type names use capitalization and camel case:module SparseMatrix, immutable UnitRange. - functions are lowercase (maximum() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.maximum , convert() http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.convert) and, when readable, with multiple words squashed together (isequal() http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.isequal, haskey() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.haskey). When necessary, use underscores as word separators. Underscores are also used to indicate a combination of concepts (remotecall_fetch() http://docs.julialang.org/en/release-0.3/stdlib/parallel/#Base.remotecall_fetch as a more efficient implementation of remotecall(fetch(...))) or as modifiers (sum_kbn() http://docs.julialang.org/en/release-0.3/stdlib/arrays/#Base.sum_kbn ). - conciseness is valued, but avoid abbreviation (indexin() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.indexin rather thanindxin()) as it becomes difficult to remember whether and how particular words are abbreviated. Personally, I think the Julia style guide gets it right... also, there have even been studies that show that words separated by _ are easier to read (20% faster to read!) than words with no spaces and camel cased... Scott On Saturday, April 25, 2015 at 6:43:44 AM UTC-4, François Fayard wrote: Hi, I would like to talk about naming convention. I think it's fine to have short names in a langage with few keywords such as C (memcpy), but a langage such as Julia that wants to be also high level with a huge standard library needs convention because the langage might become very large. I find the convention used by Mathematica the best ever made. Nothing is shortened except a few exceptions and consistent use of CamlCase. On the other hand, Matlab is probably one of the worst thing that happen in terms of naming: no consistency at all! I suspect that Cleve Moler who started Matlab not used LAPACK but also the Fortran 77 naming convention which was only there only for technical reasons ;-) I've seen that the naming convention for function in Julia looks like the same as in Python: everything must be lowercase, and don't use underscore. Let's look at different naming conventions, the first one being the one used by Julia. 1) daysinmonth() 2) daysInMonth() 3) days_in_month() I find the first one the most difficult to read. I tend to prefer the last one, but the second one is also easy to read. The fact that Julia uses the first one and the fact that many names are shortened, makes reading code with functions you've never seen a pain. For instance reading a name iso... my mind does not understand if we at talking about a function that returns a Bool (is suggests that) or something that has been standardised (ISO). Using the second naming convention would make things easier. Also it would prevent people using underscores as we have in the standard library without any clear reason. I don't find any disadvantage for the second naming convention over the first one. So why do people use the first one?
[julia-users] Re: Qwt plotting
What is the advantage of this over Matplotlib?
Re: [julia-users] Re: Naming convention
Yes - I think there are a lot of overshort names in some of the Julia packages/modules... for example, why is it readdlm, and not read_delim? On Saturday, April 25, 2015 at 9:14:12 AM UTC-4, Tracy Wadleigh wrote: I too like underscores. The thing that bugs me is that they aren't always used. I'm not a fan of conventions that involve judgment calls without an especially compelling reason. On Sat, Apr 25, 2015, 9:07 AM Scott Jones scott.pa...@gmail.com javascript: wrote: Umm... the style guide for Julia says *to* use underscore for longer names, *not* camelcase: - modules and type names use capitalization and camel case:module SparseMatrix, immutable UnitRange. - functions are lowercase (maximum() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.maximum , convert() http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.convert) and, when readable, with multiple words squashed together (isequal() http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.isequal, haskey() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.haskey). When necessary, use underscores as word separators. Underscores are also used to indicate a combination of concepts (remotecall_fetch() http://docs.julialang.org/en/release-0.3/stdlib/parallel/#Base.remotecall_fetch as a more efficient implementation of remotecall(fetch(...))) or as modifiers (sum_kbn() http://docs.julialang.org/en/release-0.3/stdlib/arrays/#Base.sum_kbn ). - conciseness is valued, but avoid abbreviation (indexin() http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.indexin rather thanindxin()) as it becomes difficult to remember whether and how particular words are abbreviated. Personally, I think the Julia style guide gets it right... also, there have even been studies that show that words separated by _ are easier to read (20% faster to read!) than words with no spaces and camel cased... Scott On Saturday, April 25, 2015 at 6:43:44 AM UTC-4, François Fayard wrote: Hi, I would like to talk about naming convention. I think it's fine to have short names in a langage with few keywords such as C (memcpy), but a langage such as Julia that wants to be also high level with a huge standard library needs convention because the langage might become very large. I find the convention used by Mathematica the best ever made. Nothing is shortened except a few exceptions and consistent use of CamlCase. On the other hand, Matlab is probably one of the worst thing that happen in terms of naming: no consistency at all! I suspect that Cleve Moler who started Matlab not used LAPACK but also the Fortran 77 naming convention which was only there only for technical reasons ;-) I've seen that the naming convention for function in Julia looks like the same as in Python: everything must be lowercase, and don't use underscore. Let's look at different naming conventions, the first one being the one used by Julia. 1) daysinmonth() 2) daysInMonth() 3) days_in_month() I find the first one the most difficult to read. I tend to prefer the last one, but the second one is also easy to read. The fact that Julia uses the first one and the fact that many names are shortened, makes reading code with functions you've never seen a pain. For instance reading a name iso... my mind does not understand if we at talking about a function that returns a Bool (is suggests that) or something that has been standardised (ISO). Using the second naming convention would make things easier. Also it would prevent people using underscores as we have in the standard library without any clear reason. I don't find any disadvantage for the second naming convention over the first one. So why do people use the first one?
Re: [julia-users] Custom Array type
You want to store the array object inside Cubes.
type Cubes{T,N} : AbstractArray{T,N}
data::Array{T,N}
end
sum(cubes::Cubes) = sum(cubes.data.^3)
--Tim
On Saturday, April 25, 2015 04:50:52 AM Marcus Appelros wrote:
Consider the definitions:
type Cubes:AbstractArray
end
sum(cubes::Cubes)=sum(convert(Array,cubes).^3)
Is it possible to make this work? To create a custom array that has
indexing and all at inception? Looked up the definition of Array and it is
in the commented section on types implemented in C, its constructor is a
ccall, if it isn't possible in pure julia would it be possible with C-code
that doesn't prompt a rebuild?
Re: [julia-users] Re: Defining a function in different modules
(#1255 https://github.com/JuliaLang/julia/issues/1255 would be icing on the cake here.) On Sat, Apr 25, 2015 at 8:19 AM, Stefan Karpinski ste...@karpinski.org wrote: I think you're probably being overly optimistic about how infrequently there will be dispatch ambiguities between unrelated functions that happen to have the same name. I would guess that if you try to merge two unrelated generic functions, ambiguities will exist more often than not. If you were to automatically merge generic functions from different modules, there are two sane ways you could handle ambiguities: - warn about ambiguities when merging happens; - raise an error when ambiguous calls actually occur. Warning when the ambiguity is caused is how we currently deal with ambiguities in individual generic functions. This seems like a good idea, but it turns out to be extremely annoying. In practice, there are fairly legitimate cases where you can have ambiguous intersections between very generic definitions and you just don't care because the ambiguous case makes no sense. This is especially true when loosely related modules extend shared generic functions. As a result, #6190 https://github.com/JuliaLang/julia/issues/6190 has gained a lot of support. If warning about ambiguities in a single generic function is annoying, warning about ambiguities when merging different generic functions that happen share a name would be a nightmare. Imagine popular packages A and B both export a function `foo`. Initially there are no ambiguities, so things are fine. Then B adds some methods to its `foo` that introduce ambiguities with A's `foo`. In isolation A and B are both fine – so neither package author sees any warnings or problems. But suddenly every package in the ecosystem that uses both A and B – which is a lot since they're both very popular – is spewing warnings upon loading. Who is responsible? Package A didn't even change anything. Package B just added some methods to its own function and has no issues in isolation. How would someone using both A and B avoid getting these warnings? They would have to stop writing `using A` or `using B` and instead explicitly import all the names they need from either A or B. To avoid inflicting this on their users, A and B would have to carefully coordinate to avoid any ambiguities between all of their generic functions. Except that it's not just A and B – it's all packages. At that point, why have namespaces with exports at all? What if we only raise an error when *making calls* to `foo` that are ambiguous between `A.foo` and `B.foo`? This eliminates the warning annoyance, which is nice. But it makes code that uses A and B that calls `foo` brittle in dangerous ways. Suppose, for example, you call `foo(x,y)` somewhere and initially this can only mean `A.foo` so things are fine. But then you upgrade B, which adds a method to `B.foo` that also matches the call to `foo(x,y)`. Now your code that used to work will fail *at run time* – and only when invoked with ambiguous arguments. This case may be possible but rare and not covered by your tests. It's a ticking time bomb introduced into your code just by upgrading dependencies. The way this issue has actually been resolved, if you were using A and B and call `foo`, initially only is exported by A, as soon as package B starts exporting `foo`, you'll get an error and be forced to explicitly disambiguate `foo`. This is a bit annoying, but after you've done that, your code will no longer be affected by any changes to `A.foo` or `B.foo` – it's safe and permanently unambiguous. This still isn't 100% bulletproof. When `B.foo` is initially introduced, your code that used `foo`, expecting to call `A.foo`, will break when `foo` is called – but you may not have tests to catch this, so it could happen at an inconvenient time. But introducing new exports is *far* less common than adding methods to existing exports and you are much more likely to have tests that use `foo` in *some* way than you are to have tests that exercise a specific ambiguous case. In particular, it would be fairly straightforward to check if the tests use every name that is referred to anywhere in some code – this would be a simple coverage measure. It is completely intractable, on the other hand, to determine whether your tests cover all possible ambiguities between functions with the same name in all your dependencies. Anyway, I hope that's somewhat convincing. I think that the way this has been resolved is a good balance between convenient usage and programming in the large. On Fri, Apr 24, 2015 at 10:55 PM, Michael Francis mdcfran...@gmail.com wrote: the resolution of that issue seems odd - If I have two completely unrelated libraries. Say DataFrames and one of my own. I export value( ::MyType) I'm happily using it. Some time later I Pkg.update(), unbeknownst to me the DataFrames dev team have added an export of
