Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features
It is only for 2-D plotting, does not do contour or density plot ( two types I tend to use the most). I am sure it will only get improved. There is, actually, some functionality for contour and density plot already, but all the nuts and bolts aren't really tightened yet, and I don't know if the progress so far has been documented at all, but if you have a function `f = (x,y) - z(x,y)`, you can do `plot(f, xmin, xmax, ymin, ymax)` to get a nice contour plot. Support for contour plots of matrices is under construction - take a look at [#293](https://github.com/dcjones/Gadfly.jl/issues/293) for more details. Density plots is sort-of implemented through [Geom.rectbin](http://dcjones.github.io/Gadfly.jl/geom_rectbin.html) which may or may not be what you need. // T On Monday, July 21, 2014 11:09:31 PM UTC+2, Zahirul ALAM wrote: Thanks Stefan. I did find out that I can type \alphatab for Unicode α. My point was more to do with the traditional input / output mode. btw if I am not mistaken I think in markup mode the \alphatab does not work. I guess not even auto complete works in markup mode when pressed tab. May be I am doing it wrong. However it works just fine once the block is compiled. But I think that has nothing to do with IJulia. I have indeed met Gadfly. I had Gadfly in mind when I wrote that. It is indeed very pretty. It is only for 2-D plotting, does not do contour or density plot ( two types I tend to use the most). I am sure it will only get improved. On Monday, 21 July 2014 14:48:17 UTC-4, Stefan Karpinski wrote: On Mon, Jul 21, 2014 at 9:55 AM, Zahirul ALAM zahiru...@gmail.com wrote: One feature I would like to see from IJulia may be is that the input of greek and mathematical symbol in way that looks natural, e.g. using subscript, in division, integration etc as way to input. This will definitely be a significant improvement IMHO. You can do Unicode input using LaTeX codes in IJulia by typing, e.g. \alphatab, which will be turned into a Unicode α. That's not as fancy as what you can do in Mathematica, but I'm not sure we want to go there. I find editing Mathematica code pretty irritating and it's not that much better looking except for the traditional output mode, which you cannot use as an input format anyway. second feature is to be able to plot a function in a way one can do in Mathematica. Plotting packages for Julia does this in very limited way (unless I am missing something) Have you met Gadfly https://github.com/dcjones/Gadfly.jl?
Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features
On Tuesday, July 22, 2014 2:39:31 AM UTC+5:30, Zahirul ALAM wrote: I have indeed met Gadfly. I had Gadfly in mind when I wrote that. It is indeed very pretty. It is only for 2-D plotting, does not do contour or density plot ( two types I tend to use the most). I am sure it will only get improved. You could also look at PyPlot, which uses Matplotlib. -viral
Re: [julia-users] Re: Tips on reducing intermediate garbage?
There is also the GC improvement patch that is waiting for the 0.3 release, which should help improve the GC performance. With better escape analysis, it should be possible to reuse the garbage from vectorized expressions in a loop in the next iteration, and significantly reduce GC load. It should also give much better performance, and stuff like loop fusion should make it possible to avoid devectorization in many cases. -viral On Tuesday, July 22, 2014 1:34:10 AM UTC+5:30, Stefan Karpinski wrote: Automatic, general loop fusion is something that we want to make possible and Jeff and I have been discussion quite a bit lately. There's a few ideas that seem promising, but they won't happen immediately. The combination of doing better escape analysis and loop fusion should help these problems quite a bit and bring high-level vectorized Julia code closer to the performance of manually devectorized, loop fused code. On Mon, Jul 21, 2014 at 6:10 AM, Tim Holy tim.h...@gmail.com wrote: codegen is a big one, as are inference.jl, gf.c, and cgutils.cpp. But there are optimization sprinkled throughout (e.g., ccall.cpp). You might be interested in this: https://github.com/JuliaLang/julia/issues/3440 Most of the optimizations so far are low level; most of the higher-level stuff tends to be macros in packages (@devec being a prime example, I'm working on another now). The fact that @devec didn't work for you is evidence that this is nontrivial (I bet that Dahua would be interested in contributions that improve it). In the longer run, it might be interesting to experiment with LLVM's Polly, but I'm not very clear on how far that project has gotten in practice. --Tim On Monday, July 21, 2014 03:51:11 PM Andrei wrote: Could you please point me to where these optimizations take place? I see some other transformations (like escape analysis, for example) happening in codegen, are there any other places I should look at? On Mon, Jul 21, 2014 at 2:43 PM, Tim Holy tim.h...@gmail.com wrote: On Monday, July 21, 2014 02:33:26 PM Andrei wrote: I see one disadvantage of using these tools, however - they are much harder to read. Are there any plans for automatic code optimization on compiler level? There are already many optimizations in place. But there's always more you could do. --Tim
[julia-users] Re: MLBase v0.5 released
Wow, better than scikit.learn? This is exciting. We should probably discuss in the roadmap issue about what infrastructure we need to support large-scale distributed machine learning problems. -viral On Monday, July 21, 2014 4:08:14 AM UTC+5:30, Dahua Lin wrote: Please see https://github.com/JuliaStats/MLBase.jl/blob/master/NEWS.md for recent updates. Also the documentation is moved from Readme to a Sphinx doc http://mlbasejl.readthedocs.org/en/latest/ Now we already have quite a few packages for various machine learning tasks: MLBase.jl https://github.com/JuliaStats/MLBase.jl: data preprocessing, performance evaluation, cross validation, model tuning, etc Distance.jl https://github.com/JuliaStats/Distance.jl: metric/distance computation (including batch pairwise computation) MultivariateStats.jl https://github.com/JuliaStats/MultivariateStats.jl: multivariate analysis, ridge regression, dimensionality reduction Clustering.jl https://github.com/JuliaStats/Clustering.jl: K-means, K-medoids, Affinity propagation NMF.jl https://github.com/JuliaStats/NMF.jl: Nonnegative matrix factorization In addition, we have a bunch of other packages for Regression, GLM, SVM, etc. We are now beginning to unite the efforts in this domain (see the discussion https://github.com/JuliaStats/Roadmap.jl/issues/14 here). We have been making steady progress, and I believe that we will have a great machine learning ecosystem, one that is comparable or even superior to scikit.learn in not too long future. Cheers, Dahua
Re: [julia-users] iterate over rows of sparse matrix and get index of nonzeros?
Julia 0.4 will have both compressed sparse column as well as compressed sparse row sparse matrices. We should probably write some iterators to work with cases such as these too. They will be convenient to use for sure, but may not give the best performance. -viral On Monday, July 21, 2014 12:15:46 PM UTC+5:30, Florian Oswald wrote: Transposing is fine! Thanks for that! On Sunday, 20 July 2014, Odd Andersen odd.ander...@gmail.com wrote: Sparse matrices in Julia are to my understanding stored as compressed sparse columns. So it is very easy to get the nonzero elements for a given column, but not so easy for rows. To get the indices of nonzeros rows for column 'c' in sparse matrix M, one can use (at least in the current implementation): M.rowval[a.colptr[col] : M.colptr[col+1]-1] To do the same by rows would be more complicated (a quick-and-dirty solution would of course be to transpose your matrix first). I am however not a Julia expert, so perhaps there's a solution I am not aware of.
Re: [julia-users] iterate over rows of sparse matrix and get index of nonzeros?
beautiful! can't wait. cheers florian On 22 July 2014 10:25, Viral Shah vi...@mayin.org wrote: Julia 0.4 will have both compressed sparse column as well as compressed sparse row sparse matrices. We should probably write some iterators to work with cases such as these too. They will be convenient to use for sure, but may not give the best performance. -viral On Monday, July 21, 2014 12:15:46 PM UTC+5:30, Florian Oswald wrote: Transposing is fine! Thanks for that! On Sunday, 20 July 2014, Odd Andersen odd.ander...@gmail.com wrote: Sparse matrices in Julia are to my understanding stored as compressed sparse columns. So it is very easy to get the nonzero elements for a given column, but not so easy for rows. To get the indices of nonzeros rows for column 'c' in sparse matrix M, one can use (at least in the current implementation): M.rowval[a.colptr[col] : M.colptr[col+1]-1] To do the same by rows would be more complicated (a quick-and-dirty solution would of course be to transpose your matrix first). I am however not a Julia expert, so perhaps there's a solution I am not aware of.
[julia-users] Re: How to overcome versioning issues?
Hello colleagues, On Monday, July 21, 2014 4:53:17 PM UTC+2, Tomas Lycken wrote: I think this problem must be resolved by better practices among package maintainers: in short, the goal must be that as long as you only use (the latest) tagged versions of any packages, everything should Just Work (TM). That means, in short, that if a package maintainer adds functionality that depends on some specific addition to a different package, it is up to that package maintainer to make sure *not* to tag a new version until the dependency package has tagged one, in which the new behavior is included, so the dependency can be correctly specified. ... in an ideal world. All that we use around julia has a version number less than 1.0 so hiccups are expected (at least by me). The question was rather how i can help myself and if there is some undocumented work assumption. If i ever publish a package i'll try hard to follow your advice. This interdependency things showed up also in the great julia-graphics thread on julia-dev. Maybe some automatic testing could help? Maybe some dependency graph could be extracted out of the METADATA? Wishing a happy day,
[julia-users] associative property of export/include/import?
Hello colleagues,
i was for some time under the impression, that the exact sequence of
imports do not matter (let's say, i hoped) as the definitions of types and
functions are cumulative, modules should be self contained and use require
where needed.
Today:
lobi@maroon:~/juliarepo$ ../julia/julia
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() to list help topics
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.0-rc1+116 (2014-07-21 15:59 UTC)
_/ |\__'_|_|_|\__'_| | Commit e75595f* (0 days old master)
|__/ | i686-linux-gnu
julia using Gadfly
Warning: could not import Base.has into Gadfly
Warning: could not import StatsBase.bandwidth into Stat
Warning: could not import StatsBase.kde into Stat
julia using Gtk
julia methods(draw)
# 3 methods for generic function draw:
draw(redraw::Function,widget::GtkCanvas) at
/home/lobi/.julia/v0.3/Gtk/src/cairo.jl:56
draw(widget::GtkCanvas) at /home/lobi/.julia/v0.3/Gtk/src/cairo.jl:61
draw(widget::GtkCanvas,immediate::Bool) at
/home/lobi/.julia/v0.3/Gtk/src/cairo.jl:61
julia
In contrast to:
lobi@maroon:~/juliarepo$ ../julia/julia
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() to list help topics
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.0-rc1+116 (2014-07-21 15:59 UTC)
_/ |\__'_|_|_|\__'_| | Commit e75595f* (0 days old master)
|__/ | i686-linux-gnu
julia using Gtk
julia using Gadfly
Warning: could not import Base.has into Gadfly
Warning: could not import StatsBase.bandwidth into Stat
Warning: could not import StatsBase.kde into Stat
julia methods(draw)
# 30 methods for generic function draw:
draw{P}(backend::Backend,t::Transform,units::UnitBox{S,T,U,V},box::AbsoluteBoundingBox,form::Form{P})
at /home/lobi/.julia/v0.3/Compose/src/form.jl:23
draw(backend::Backend,root_canvas::Context) at
/home/lobi/.julia/v0.3/Compose/src/container.jl:271
draw(img::Image{B:ImageBackend},form::Form{P:FormPrimitive}) at
/home/lobi/.julia/v0.3/Compose/src/cairo_backends.jl:680
?
Wishing a happy day,
Andreas
[julia-users] Re: associative property of export/include/import?
The problem is that both Gtk and Gadfly exports a draw function. Internally
those are scoped by module so that their name is Gadfly.draw() and
Gtk.draw(), and you can call them as such in your code. We can't merge the
function's method, because there is no way to know which one to call if
both define a draw(a::Any) method.
When you use `using` you import the exported identifiers into the local
scope, and if there is a conflict you run into trouble because you don't
know which one you'll get.
There is an issue to change the behaviour to give a warning when using an
ambiguous identifier in #4345
https://github.com/JuliaLang/julia/issues/4345.
Ivar
kl. 11:59:39 UTC+2 tirsdag 22. juli 2014 skrev Andreas Lobinger følgende:
Hello colleagues,
i was for some time under the impression, that the exact sequence of
imports do not matter (let's say, i hoped) as the definitions of types and
functions are cumulative, modules should be self contained and use require
where needed.
Today:
lobi@maroon:~/juliarepo$ ../julia/julia
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() to list help topics
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.0-rc1+116 (2014-07-21 15:59 UTC)
_/ |\__'_|_|_|\__'_| | Commit e75595f* (0 days old master)
|__/ | i686-linux-gnu
julia using Gadfly
Warning: could not import Base.has into Gadfly
Warning: could not import StatsBase.bandwidth into Stat
Warning: could not import StatsBase.kde into Stat
julia using Gtk
julia methods(draw)
# 3 methods for generic function draw:
draw(redraw::Function,widget::GtkCanvas) at
/home/lobi/.julia/v0.3/Gtk/src/cairo.jl:56
draw(widget::GtkCanvas) at /home/lobi/.julia/v0.3/Gtk/src/cairo.jl:61
draw(widget::GtkCanvas,immediate::Bool) at
/home/lobi/.julia/v0.3/Gtk/src/cairo.jl:61
julia
In contrast to:
lobi@maroon:~/juliarepo$ ../julia/julia
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() to list help topics
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.0-rc1+116 (2014-07-21 15:59 UTC)
_/ |\__'_|_|_|\__'_| | Commit e75595f* (0 days old master)
|__/ | i686-linux-gnu
julia using Gtk
julia using Gadfly
Warning: could not import Base.has into Gadfly
Warning: could not import StatsBase.bandwidth into Stat
Warning: could not import StatsBase.kde into Stat
julia methods(draw)
# 30 methods for generic function draw:
draw{P}(backend::Backend,t::Transform,units::UnitBox{S,T,U,V},box::AbsoluteBoundingBox,form::Form{P})
at /home/lobi/.julia/v0.3/Compose/src/form.jl:23
draw(backend::Backend,root_canvas::Context) at
/home/lobi/.julia/v0.3/Compose/src/container.jl:271
draw(img::Image{B:ImageBackend},form::Form{P:FormPrimitive}) at
/home/lobi/.julia/v0.3/Compose/src/cairo_backends.jl:680
?
Wishing a happy day,
Andreas
[julia-users] Re: How to overcome versioning issues?
I still think the best way to resolve things if you should encounter problems, is to notify the maintainers. Most people in this community respond surprisingly fast =) There is some automated testing going on already, mainly thanks to [Iain Dunning](https://github.com/IainNZ)'s amazing work with PackageEvaluator and related tools. For example, if you click more options on pkg.julialang.org and then Show package ecosystem statistics for Julia nightly..., you'll see some great data showing the current (and past) state of the entire ecosystem. You'll notice a few dips in the green curve, when changes somewhere suddenly broke a lot of stuff everywhere - and you'll also see that most of it was resolved in a matter of a few days. This happened because semi-automated issues were filed by the system against the packages when they broke, and maintainers were quick to fix whatever they needed. In the case of your problems - someone tagging a version without specifying a correct dependency - that will also be picked up by PkgEval, and the maintainer will be notified. However, since PkgEval only runs every now and then, and since quite a lot of users today live on the edge (and actively report issues when they find them) it's not uncommon that problems like this are picked up by users before PkgEval notices them. It's very likely that, as the ecosystem matures and stabilizes, this problem won't be a problem anymore... // T On Tuesday, July 22, 2014 11:47:32 AM UTC+2, Andreas Lobinger wrote: Hello colleagues, On Monday, July 21, 2014 4:53:17 PM UTC+2, Tomas Lycken wrote: I think this problem must be resolved by better practices among package maintainers: in short, the goal must be that as long as you only use (the latest) tagged versions of any packages, everything should Just Work (TM). That means, in short, that if a package maintainer adds functionality that depends on some specific addition to a different package, it is up to that package maintainer to make sure *not* to tag a new version until the dependency package has tagged one, in which the new behavior is included, so the dependency can be correctly specified. ... in an ideal world. All that we use around julia has a version number less than 1.0 so hiccups are expected (at least by me). The question was rather how i can help myself and if there is some undocumented work assumption. If i ever publish a package i'll try hard to follow your advice. This interdependency things showed up also in the great julia-graphics thread on julia-dev. Maybe some automatic testing could help? Maybe some dependency graph could be extracted out of the METADATA? Wishing a happy day,
[julia-users] Re: associative property of export/include/import?
Isn't it odd, though, that there is no warning Could not import
Gadfly.draw into Main (or Gtk.draw, depending on order)?
// T
On Tuesday, July 22, 2014 12:30:55 PM UTC+2, Ivar Nesje wrote:
The problem is that both Gtk and Gadfly exports a draw function.
Internally those are scoped by module so that their name is Gadfly.draw()
and Gtk.draw(), and you can call them as such in your code. We can't merge
the function's method, because there is no way to know which one to call if
both define a draw(a::Any) method.
When you use `using` you import the exported identifiers into the local
scope, and if there is a conflict you run into trouble because you don't
know which one you'll get.
There is an issue to change the behaviour to give a warning when using an
ambiguous identifier in #4345
https://github.com/JuliaLang/julia/issues/4345.
Ivar
kl. 11:59:39 UTC+2 tirsdag 22. juli 2014 skrev Andreas Lobinger følgende:
Hello colleagues,
i was for some time under the impression, that the exact sequence of
imports do not matter (let's say, i hoped) as the definitions of types and
functions are cumulative, modules should be self contained and use require
where needed.
Today:
lobi@maroon:~/juliarepo$ ../julia/julia
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() to list help topics
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.0-rc1+116 (2014-07-21 15:59 UTC)
_/ |\__'_|_|_|\__'_| | Commit e75595f* (0 days old master)
|__/ | i686-linux-gnu
julia using Gadfly
Warning: could not import Base.has into Gadfly
Warning: could not import StatsBase.bandwidth into Stat
Warning: could not import StatsBase.kde into Stat
julia using Gtk
julia methods(draw)
# 3 methods for generic function draw:
draw(redraw::Function,widget::GtkCanvas) at
/home/lobi/.julia/v0.3/Gtk/src/cairo.jl:56
draw(widget::GtkCanvas) at /home/lobi/.julia/v0.3/Gtk/src/cairo.jl:61
draw(widget::GtkCanvas,immediate::Bool) at
/home/lobi/.julia/v0.3/Gtk/src/cairo.jl:61
julia
In contrast to:
lobi@maroon:~/juliarepo$ ../julia/julia
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() to list help topics
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.0-rc1+116 (2014-07-21 15:59 UTC)
_/ |\__'_|_|_|\__'_| | Commit e75595f* (0 days old master)
|__/ | i686-linux-gnu
julia using Gtk
julia using Gadfly
Warning: could not import Base.has into Gadfly
Warning: could not import StatsBase.bandwidth into Stat
Warning: could not import StatsBase.kde into Stat
julia methods(draw)
# 30 methods for generic function draw:
draw{P}(backend::Backend,t::Transform,units::UnitBox{S,T,U,V},box::AbsoluteBoundingBox,form::Form{P})
at /home/lobi/.julia/v0.3/Compose/src/form.jl:23
draw(backend::Backend,root_canvas::Context) at
/home/lobi/.julia/v0.3/Compose/src/container.jl:271
draw(img::Image{B:ImageBackend},form::Form{P:FormPrimitive}) at
/home/lobi/.julia/v0.3/Compose/src/cairo_backends.jl:680
?
Wishing a happy day,
Andreas
[julia-users] Re: How to overcome versioning issues?
Look what my RSS reader just picked up! =) http://iaindunning.com/2014/pkg-deps.html // T On Tuesday, July 22, 2014 12:37:59 PM UTC+2, Tomas Lycken wrote: I still think the best way to resolve things if you should encounter problems, is to notify the maintainers. Most people in this community respond surprisingly fast =) There is some automated testing going on already, mainly thanks to [Iain Dunning](https://github.com/IainNZ)'s amazing work with PackageEvaluator and related tools. For example, if you click more options on pkg.julialang.org and then Show package ecosystem statistics for Julia nightly..., you'll see some great data showing the current (and past) state of the entire ecosystem. You'll notice a few dips in the green curve, when changes somewhere suddenly broke a lot of stuff everywhere - and you'll also see that most of it was resolved in a matter of a few days. This happened because semi-automated issues were filed by the system against the packages when they broke, and maintainers were quick to fix whatever they needed. In the case of your problems - someone tagging a version without specifying a correct dependency - that will also be picked up by PkgEval, and the maintainer will be notified. However, since PkgEval only runs every now and then, and since quite a lot of users today live on the edge (and actively report issues when they find them) it's not uncommon that problems like this are picked up by users before PkgEval notices them. It's very likely that, as the ecosystem matures and stabilizes, this problem won't be a problem anymore... // T On Tuesday, July 22, 2014 11:47:32 AM UTC+2, Andreas Lobinger wrote: Hello colleagues, On Monday, July 21, 2014 4:53:17 PM UTC+2, Tomas Lycken wrote: I think this problem must be resolved by better practices among package maintainers: in short, the goal must be that as long as you only use (the latest) tagged versions of any packages, everything should Just Work (TM). That means, in short, that if a package maintainer adds functionality that depends on some specific addition to a different package, it is up to that package maintainer to make sure *not* to tag a new version until the dependency package has tagged one, in which the new behavior is included, so the dependency can be correctly specified. ... in an ideal world. All that we use around julia has a version number less than 1.0 so hiccups are expected (at least by me). The question was rather how i can help myself and if there is some undocumented work assumption. If i ever publish a package i'll try hard to follow your advice. This interdependency things showed up also in the great julia-graphics thread on julia-dev. Maybe some automatic testing could help? Maybe some dependency graph could be extracted out of the METADATA? Wishing a happy day,
[julia-users] Re: How to overcome versioning issues?
Hah, yeah, strangely relevant. PkgEval runs nightly (around 1am US Eastern), but obviously with so many people using Julia there is a lot of room for chaos inbetween runs. On Tuesday, July 22, 2014 7:58:46 AM UTC-4, Tomas Lycken wrote: Look what my RSS reader just picked up! =) http://iaindunning.com/2014/pkg-deps.html // T On Tuesday, July 22, 2014 12:37:59 PM UTC+2, Tomas Lycken wrote: I still think the best way to resolve things if you should encounter problems, is to notify the maintainers. Most people in this community respond surprisingly fast =) There is some automated testing going on already, mainly thanks to [Iain Dunning](https://github.com/IainNZ)'s amazing work with PackageEvaluator and related tools. For example, if you click more options on pkg.julialang.org and then Show package ecosystem statistics for Julia nightly..., you'll see some great data showing the current (and past) state of the entire ecosystem. You'll notice a few dips in the green curve, when changes somewhere suddenly broke a lot of stuff everywhere - and you'll also see that most of it was resolved in a matter of a few days. This happened because semi-automated issues were filed by the system against the packages when they broke, and maintainers were quick to fix whatever they needed. In the case of your problems - someone tagging a version without specifying a correct dependency - that will also be picked up by PkgEval, and the maintainer will be notified. However, since PkgEval only runs every now and then, and since quite a lot of users today live on the edge (and actively report issues when they find them) it's not uncommon that problems like this are picked up by users before PkgEval notices them. It's very likely that, as the ecosystem matures and stabilizes, this problem won't be a problem anymore... // T On Tuesday, July 22, 2014 11:47:32 AM UTC+2, Andreas Lobinger wrote: Hello colleagues, On Monday, July 21, 2014 4:53:17 PM UTC+2, Tomas Lycken wrote: I think this problem must be resolved by better practices among package maintainers: in short, the goal must be that as long as you only use (the latest) tagged versions of any packages, everything should Just Work (TM). That means, in short, that if a package maintainer adds functionality that depends on some specific addition to a different package, it is up to that package maintainer to make sure *not* to tag a new version until the dependency package has tagged one, in which the new behavior is included, so the dependency can be correctly specified. ... in an ideal world. All that we use around julia has a version number less than 1.0 so hiccups are expected (at least by me). The question was rather how i can help myself and if there is some undocumented work assumption. If i ever publish a package i'll try hard to follow your advice. This interdependency things showed up also in the great julia-graphics thread on julia-dev. Maybe some automatic testing could help? Maybe some dependency graph could be extracted out of the METADATA? Wishing a happy day,
Re: [julia-users] Re: How to overcome versioning issues?
Reading your post, I'm a little confused Iain. You state: If we consider only packages with at least 1 package depending on them, we find the median to be 3 dependent packages but the mean to be 10.5. This is due to the 15 or so packages with more than 30 dependent packages. Now, I'm not the best at statistics, but isn't the median of *x* defined as *(min(x) + max(x))/2*? If that is the case, (and assuming that we don't have negative package dependency counts) I don't see how the median can be 3, but the mean be 10.5. Perhaps you meant the mode was 3? -E On Tue, Jul 22, 2014 at 9:55 AM, Iain Dunning iaindunn...@gmail.com wrote: Hah, yeah, strangely relevant. PkgEval runs nightly (around 1am US Eastern), but obviously with so many people using Julia there is a lot of room for chaos inbetween runs. On Tuesday, July 22, 2014 7:58:46 AM UTC-4, Tomas Lycken wrote: Look what my RSS reader just picked up! =) http://iaindunning.com/2014/pkg-deps.html // T On Tuesday, July 22, 2014 12:37:59 PM UTC+2, Tomas Lycken wrote: I still think the best way to resolve things if you should encounter problems, is to notify the maintainers. Most people in this community respond surprisingly fast =) There is some automated testing going on already, mainly thanks to [Iain Dunning](https://github.com/IainNZ)'s amazing work with PackageEvaluator and related tools. For example, if you click more options on pkg.julialang.org and then Show package ecosystem statistics for Julia nightly..., you'll see some great data showing the current (and past) state of the entire ecosystem. You'll notice a few dips in the green curve, when changes somewhere suddenly broke a lot of stuff everywhere - and you'll also see that most of it was resolved in a matter of a few days. This happened because semi-automated issues were filed by the system against the packages when they broke, and maintainers were quick to fix whatever they needed. In the case of your problems - someone tagging a version without specifying a correct dependency - that will also be picked up by PkgEval, and the maintainer will be notified. However, since PkgEval only runs every now and then, and since quite a lot of users today live on the edge (and actively report issues when they find them) it's not uncommon that problems like this are picked up by users before PkgEval notices them. It's very likely that, as the ecosystem matures and stabilizes, this problem won't be a problem anymore... // T On Tuesday, July 22, 2014 11:47:32 AM UTC+2, Andreas Lobinger wrote: Hello colleagues, On Monday, July 21, 2014 4:53:17 PM UTC+2, Tomas Lycken wrote: I think this problem must be resolved by better practices among package maintainers: in short, the goal must be that as long as you only use (the latest) tagged versions of any packages, everything should Just Work (TM). That means, in short, that if a package maintainer adds functionality that depends on some specific addition to a different package, it is up to that package maintainer to make sure *not* to tag a new version until the dependency package has tagged one, in which the new behavior is included, so the dependency can be correctly specified. ... in an ideal world. All that we use around julia has a version number less than 1.0 so hiccups are expected (at least by me). The question was rather how i can help myself and if there is some undocumented work assumption. If i ever publish a package i'll try hard to follow your advice. This interdependency things showed up also in the great julia-graphics thread on julia-dev. Maybe some automatic testing could help? Maybe some dependency graph could be extracted out of the METADATA? Wishing a happy day,
Re: [julia-users] Re: associative property of export/include/import?
I agree that there should be some means of resolving conflicts (by warning, by precedence) but just dropping a whole set of methods because they conincidentially have the same name AND at the same time advertising multiple dispatch in julia doesn't fit for me. Multiple dispatch would still work and no methods are dropped, you would just need to fully qualify the generic function, like e.g. `Gadfly.plot`, or you could do `plot = Gadfly.plot` to get the one generic function you want into the global namespace. I think this would be less confusing than the order of `using` be significant.
Re: [julia-users] Re: How to overcome versioning issues?
According to Julia median is defined as n = length(v) if isodd(n) return middle(select!(v,div(n+1,2))) else m = select!(v, div(n,2):div(n,2)+1) return middle(m[1], m[2]) end Ivar kl. 16:03:47 UTC+2 tirsdag 22. juli 2014 skrev Elliot Saba følgende: Reading your post, I'm a little confused Iain. You state: If we consider only packages with at least 1 package depending on them, we find the median to be 3 dependent packages but the mean to be 10.5. This is due to the 15 or so packages with more than 30 dependent packages. Now, I'm not the best at statistics, but isn't the median of *x* defined as *(min(x) + max(x))/2*? If that is the case, (and assuming that we don't have negative package dependency counts) I don't see how the median can be 3, but the mean be 10.5. Perhaps you meant the mode was 3? -E On Tue, Jul 22, 2014 at 9:55 AM, Iain Dunning iaind...@gmail.com javascript: wrote: Hah, yeah, strangely relevant. PkgEval runs nightly (around 1am US Eastern), but obviously with so many people using Julia there is a lot of room for chaos inbetween runs. On Tuesday, July 22, 2014 7:58:46 AM UTC-4, Tomas Lycken wrote: Look what my RSS reader just picked up! =) http://iaindunning.com/2014/pkg-deps.html // T On Tuesday, July 22, 2014 12:37:59 PM UTC+2, Tomas Lycken wrote: I still think the best way to resolve things if you should encounter problems, is to notify the maintainers. Most people in this community respond surprisingly fast =) There is some automated testing going on already, mainly thanks to [Iain Dunning](https://github.com/IainNZ)'s amazing work with PackageEvaluator and related tools. For example, if you click more options on pkg.julialang.org and then Show package ecosystem statistics for Julia nightly..., you'll see some great data showing the current (and past) state of the entire ecosystem. You'll notice a few dips in the green curve, when changes somewhere suddenly broke a lot of stuff everywhere - and you'll also see that most of it was resolved in a matter of a few days. This happened because semi-automated issues were filed by the system against the packages when they broke, and maintainers were quick to fix whatever they needed. In the case of your problems - someone tagging a version without specifying a correct dependency - that will also be picked up by PkgEval, and the maintainer will be notified. However, since PkgEval only runs every now and then, and since quite a lot of users today live on the edge (and actively report issues when they find them) it's not uncommon that problems like this are picked up by users before PkgEval notices them. It's very likely that, as the ecosystem matures and stabilizes, this problem won't be a problem anymore... // T On Tuesday, July 22, 2014 11:47:32 AM UTC+2, Andreas Lobinger wrote: Hello colleagues, On Monday, July 21, 2014 4:53:17 PM UTC+2, Tomas Lycken wrote: I think this problem must be resolved by better practices among package maintainers: in short, the goal must be that as long as you only use (the latest) tagged versions of any packages, everything should Just Work (TM). That means, in short, that if a package maintainer adds functionality that depends on some specific addition to a different package, it is up to that package maintainer to make sure *not* to tag a new version until the dependency package has tagged one, in which the new behavior is included, so the dependency can be correctly specified. ... in an ideal world. All that we use around julia has a version number less than 1.0 so hiccups are expected (at least by me). The question was rather how i can help myself and if there is some undocumented work assumption. If i ever publish a package i'll try hard to follow your advice. This interdependency things showed up also in the great julia-graphics thread on julia-dev. Maybe some automatic testing could help? Maybe some dependency graph could be extracted out of the METADATA? Wishing a happy day,
[julia-users] Using append! with types Array{Int64,1}
Hi,
I started using Julia last week, so newbie. Here is the issue I'm having:
- I want to store a certain unknown number of elements like [1,2] ( type
Array{Int64,1} ).
- I first create an array to store them, using:
julia c_zero = Array(Array{Int64,1},0)
- But then, when I try to append! a new element, I get an error:
julia append!(c_zero,[1,2])
MethodError(convert,(Array{Int64,1},1))
Thanks for any help.
Frederico.
[julia-users] Re: Using append! with types Array{Int64,1}
You must use push!
Julia is very careful about the meaning of a function (partially because
multiple dispatch makes it much more important than in other languages).
push! : appends a single element to a collection
append! : pushes all the elements of a container into another container.
c_zero is an array of arrays, and thus you will have to insert the whole
array [1,2] into c_zero, not all the elements of the array.
Ivar
kl. 16:17:19 UTC+2 tirsdag 22. juli 2014 skrev Frederico Novaes følgende:
Hi,
I started using Julia last week, so newbie. Here is the issue I'm having:
- I want to store a certain unknown number of elements like [1,2] ( type
Array{Int64,1} ).
- I first create an array to store them, using:
julia c_zero = Array(Array{Int64,1},0)
- But then, when I try to append! a new element, I get an error:
julia append!(c_zero,[1,2])
MethodError(convert,(Array{Int64,1},1))
Thanks for any help.
Frederico.
[julia-users] Julia in LaTeX
Mike LaCroix put together a nice latex package that produces In's and Out's
nicely and beautifully but this is unfinished with too much
manual labor required. Just throwing it out there
figuring someone will improve on it.
Perhaps one should also consider minted -- https://code.google.com/p/minted/
which I know Jiahao Chen likes.
I'll bet someone could make some Julia macros that make this more LaTeX
friendly.
Right now I would also define something like
\newcommand{\ja}{\begin{jinput}}
\newcommand{\jb}{\end{jinput}\begin{joutput}\begin{verbatim}}
\newcommand{\jc}{\end{verbatim}\end{joutput}}
so the use would be
\ja
\sh {\# Nice Red Comment} \\
Input line 1 \\
Input line 2 \\
Input line 3
\jb
Output lines without slashes
\jc
and on the input lines I would have to put in backslashes before certain
characters, etc.
but it looks nice and automatically numbers
Viral Shah thought that LateX should just execute julia so there is no
human in the loop.
You just type the Julia command input, and the input and output can appear
properly in the document.
\documentclass{article}
\usepackage{graphicx}
\usepackage{color}
\usepackage{framed}
\definecolor{shadecolor}{gray}{.92}
\definecolor{incolor}{rgb}{0,0,.7}
\definecolor{outcolor}{rgb}{.65,0,0}
\definecolor{syntaxcolor}{rgb}{.65,0,0}
\newcommand{\sh}[1]{\textcolor{syntaxcolor}{#1}}
\newcounter{jcounter}
\newenvironment{jinput}[1][]{\ifx#1\relax\else\setcounter{jcounter}{#1}\addtocounter{jcounter}{-1}\fi\refstepcounter{jcounter}\ttfamily\noindent\begin{minipage}[t]{.19\textwidth}\vskip2ex\hspace*{\fill}\textcolor{incolor}{In[\arabic{jcounter}]: }\end{minipage}\begin{minipage}[t]{.8\textwidth}\vskip-0ex\begin{shaded}}{\end{shaded}\end{minipage}\par}
\newenvironment{joutput}[1][]{\vskip1ex plus .2ex minus .1ex\ifx#1\relax\else\setcounter{jcounter}{#1}\fi\addtocounter{jcounter}{-1}\refstepcounter{jcounter}\ttfamily\noindent\begin{minipage}[t]{.19\textwidth}\vskip0ex\hspace*{\fill}\textcolor{outcolor}{Out[\arabic{jcounter}]: }\end{minipage}\begin{minipage}[t]{.8\textwidth}\vskip-0ex}{\end{minipage}\par\vskip1.5ex}
\begin{document}
Normal text, just to make sure vertical spacing is correct. We can
introduce our makeshift Julia interaction with a paragraph.
\begin{jinput}[8]
f(a::\sh{Any}, b) = \sh{fallback}\\
f(a::Number, b::Number) = \sh{a and b are both numbers}\\
f(a::Number, b) = \sh{a is a number}\\
f(a, b::Number) = \sh{b is a number}\\
f(a::Integer, b::Integer) = \sh{a and b are both integers}
\end{jinput}
\begin{joutput}
f (generic function with 5 methods)
\end{joutput}
\begin{jinput}
f(1.5,2)
\end{jinput}
\begin{joutput}
a and b are both numbers
\end{joutput}
\begin{jinput}\label{jinlabel}
f(1,\sh{bar})
\end{jinput}
\begin{joutput}
a is a number
\end{joutput}
\begin{jinput}
f(1,2)
\end{jinput}
\begin{joutput}\label{anoutlabel}
fallback
\end{joutput}
We can also conclude our interaction with a paragraph. The numbering
is automatic, with each output matching the previous input. This can
be updated manually. We can, for example, refer to
\textcolor{incolor}{In[\ref{jinlabel}]} and \textcolor{outcolor}{Out[\ref{anoutlabel}]}.
\end{document}
sourcecode.pdf
Description: Adobe PDF document
Re: [julia-users] build-in function to find inverse of a matrix
+1 for sticky shell mode. I do like the ? - help and ?? - apropos mapping, as it's clear on the mode what the simple mapping is. But it's a minor point. Cameron On Tue, Jul 22, 2014 at 12:06 AM, Viral Shah vi...@mayin.org wrote: That’s not a crazy idea. ? could do help if there is an exact match, and if there is no match, it can just do apropos. -viral On 22-Jul-2014, at 7:20 am, Stefan Karpinski ste...@karpinski.org wrote: Would it be crazy to make ? just do apropos? Interestingly, I was just thinking of making ;; trigger sticky shell mode where you have to actively escape to get back to julia mode. On Mon, Jul 21, 2014 at 6:48 PM, John Myles White johnmyleswh...@gmail.com wrote: There's one complication here, which is that a single ? already changes the mode of the REPL into help mode. So this would have to be a mode only triggerable from inside of help mode. -- John On Jul 21, 2014, at 6:47 PM, Ethan Anderes ethanande...@gmail.com wrote: +1. For some reason my fingers always get tied up when typing apropos
[julia-users] NotShared Memory
I can create shared variables like @everywhere i=1 but how do I create variables local to a worker. The only possibility is through RemoteRefs with take and put, but this seems overly complicated. What I have in mind is a problem where all the workers only need communicated with the main thread for scheduling and all the computations can be done locally. I would like the results to be stored in local array and be fetched to the main thread once all calculations have finished. For this I need to create a local array on each worker. But I don't know how. Thanks, Sebastian
[julia-users] NotShared Memory
I would like to perform computations on the workers independently only the task assignment is scheduled from the main thread. Instead of passing each result as they come to the main thread I would like to store them on each worker on a local array. When all computations have finished I would like fetch these arrays and combine them then. I can create shared variables using @everywhere i=1 The only possibility that came to my mind is to use take and put using appropriate RemoteRefs, but this seems overly complicated. Thank you, Sebastian
[julia-users] ccall :u8_charnum
I can ccall :u8_charnum function from Windows but get an error on Linux:
Any thoughts appreciated.
Win:
julia x=asdf
asdf
julia ccall(:u8_charnum, Csize_t, (Ptr{Uint8}, Csize_t), pointer(x), 4)
0x0004
On Linux, I get
ERROR: ccall: could not find function u8_charnum
in anonymous at no file
Win version:
Version 0.3.0-rc1+61 (2014-07-17 20:55 UTC)
Commit c4547e6 (4 days old master)
x86_64-w64-mingw32
Linux version:
Version 0.3.0-rc1+73 (2014-07-18 17:57 UTC)
Commit 49ac85f* (3 days old master)
x86_64-redhat-linux
[julia-users] Re: MLBase v0.5 released
On Tuesday, July 22, 2014 4:21:49 AM UTC-5, Viral Shah wrote: Wow, better than scikit.learn? This is exciting. We are not there yet. However, the work to unify our many packages for regression has already been started. If we keep our paces this won't be a too-far-away goal. We should probably discuss in the roadmap issue about what infrastructure we need to support large-scale distributed machine learning problems. -viral On Monday, July 21, 2014 4:08:14 AM UTC+5:30, Dahua Lin wrote: Please see https://github.com/JuliaStats/MLBase.jl/blob/master/NEWS.md for recent updates. Also the documentation is moved from Readme to a Sphinx doc http://mlbasejl.readthedocs.org/en/latest/ Now we already have quite a few packages for various machine learning tasks: MLBase.jl https://github.com/JuliaStats/MLBase.jl: data preprocessing, performance evaluation, cross validation, model tuning, etc Distance.jl https://github.com/JuliaStats/Distance.jl: metric/distance computation (including batch pairwise computation) MultivariateStats.jl https://github.com/JuliaStats/MultivariateStats.jl: multivariate analysis, ridge regression, dimensionality reduction Clustering.jl https://github.com/JuliaStats/Clustering.jl: K-means, K-medoids, Affinity propagation NMF.jl https://github.com/JuliaStats/NMF.jl: Nonnegative matrix factorization In addition, we have a bunch of other packages for Regression, GLM, SVM, etc. We are now beginning to unite the efforts in this domain (see the discussion https://github.com/JuliaStats/Roadmap.jl/issues/14 here). We have been making steady progress, and I believe that we will have a great machine learning ecosystem, one that is comparable or even superior to scikit.learn in not too long future. Cheers, Dahua
Re: [julia-users] Equivalent for Python 'pass' statement in Julia
Because Julia has begin-end blocks, you can just use an empty block. Here are some examples of what I mean: ~~~ function foo() end ~~~ ~~~ if true elseif false else end ~~~ ~~~ for i=1:10 end ~~~ Does that do what you wanted? -- Leah On Tue, Jul 22, 2014 at 3:44 PM, yaoismyh...@gmail.com wrote: Hi, Python has a 'pass' statement which allows null operations to be placed in control flows with ease. I guess I could just use a print statement, but I was just wondering whether Julia had an equivalent? Thanks
Re: [julia-users] Equivalent for Python 'pass' statement in Julia
Thanks Leah, that was exactly what I was looking for! On Tuesday, July 22, 2014 5:04:30 PM UTC-4, Leah Hanson wrote: Because Julia has begin-end blocks, you can just use an empty block. Here are some examples of what I mean: ~~~ function foo() end ~~~ ~~~ if true elseif false else end ~~~ ~~~ for i=1:10 end ~~~ Does that do what you wanted? -- Leah On Tue, Jul 22, 2014 at 3:44 PM, yaois...@gmail.com javascript: wrote: Hi, Python has a 'pass' statement which allows null operations to be placed in control flows with ease. I guess I could just use a print statement, but I was just wondering whether Julia had an equivalent? Thanks
Re: [julia-users] ++ as string concatenation operator
Why is string concatenation done with * not + https://groups.google.com/d/topic/julia-users/nQg_d_n0t1Q/discussion peace, s On Tue, Jul 22, 2014 at 4:58 PM, Stefan Karpinski ste...@karpinski.org wrote: many threads: search string concatenation On Tue, Jul 22, 2014 at 1:55 PM, Ben Arthur bjarthu...@gmail.com wrote: relatedly, is there a thread somewhere that explains why * is used for string concatenation and ^ for string repetition?
[julia-users] iterator construct seems incorrect?
Dear Julia users, As I have mentioned in earlier posts, I am working on a 2-3 tree implementation of a sort-order dict, that is, a dict in which the (key, value) pairs can be retrieved in the sort-order of the keys. According to section 2.1.7 of the manual, for i = I; body ; end translates to: state = start(I) while !done(I, state) (i,state) = next(I,state) body end The more obvious way to implement the loop would be to put the body BEFORE the 'next' statement, and at first I thought that maybe the manual has a typo. But then I checked the file dict.jl, and I found indeed the code: done(t::ObjectIdDict, i) = is(next(t,i),()) So this means that every loop iteration over an ObjectIdDict requires two calls to 'next', one as part of the call to 'done', and a second one to actually advance the loop. I also looked at the code for 'done' for Dict in dict.jl, and it appears to be buggy(??). It does not check whether everything after the current i is deleted(??) For a 2-3 tree, the 'next' operation is logarithmic time, so requiring it twice per loop iteration is undesirable. Can anyone shed light on why the Julia loop construction is implemented this way, so that two separate calls to 'next' are necessary? I suppose that it is possible with additional code complexity to cache the result of the first call to 'next' inside the state, but what exactly is the rationale for the current design? Thanks, Steve Vavasis
Re: [julia-users] iterator construct seems incorrect?
You seem to be attributing a general principle where I don't think there is one. For example, see the iterators in base/range.jl; there are not two calls to next. --Tim On Tuesday, July 22, 2014 02:29:12 PM vava...@uwaterloo.ca wrote: Dear Julia users, As I have mentioned in earlier posts, I am working on a 2-3 tree implementation of a sort-order dict, that is, a dict in which the (key, value) pairs can be retrieved in the sort-order of the keys. According to section 2.1.7 of the manual, for i = I; body ; end translates to: state = start(I) while !done(I, state) (i,state) = next(I,state) body end The more obvious way to implement the loop would be to put the body BEFORE the 'next' statement, and at first I thought that maybe the manual has a typo. But then I checked the file dict.jl, and I found indeed the code: done(t::ObjectIdDict, i) = is(next(t,i),()) So this means that every loop iteration over an ObjectIdDict requires two calls to 'next', one as part of the call to 'done', and a second one to actually advance the loop. I also looked at the code for 'done' for Dict in dict.jl, and it appears to be buggy(??). It does not check whether everything after the current i is deleted(??) For a 2-3 tree, the 'next' operation is logarithmic time, so requiring it twice per loop iteration is undesirable. Can anyone shed light on why the Julia loop construction is implemented this way, so that two separate calls to 'next' are necessary? I suppose that it is possible with additional code complexity to cache the result of the first call to 'next' inside the state, but what exactly is the rationale for the current design? Thanks, Steve Vavasis
Re: [julia-users] Equivalent for Python 'pass' statement in Julia
The ternary syntax is one place where an empty block won't suffice — there must be an expression in both branches. In such a case, you can use `nothing` (which is also what an empty block will return). That said, it's more typical to refactor these cases into short-circuiting expressions: cond ? expr : nothing # could be written as: cond expr cond ? nothing : expr # becomes: cond || expr
[julia-users] Help needed, running slow
To learn how to use Julia, I am running through the project Euler problems (I had already solved most of them using other languages) and up to now, they have all comfortably been solved under 1s without any clever algorithm, even sometimes purposely brute forced. However I am stuck on problem 23 (Find the sum of all the positive integers which cannot be written as the sum of two abundant numbers.) which solves in 8 s. The surprising thing to me is that what I assume to be the hard part is solved in 0.1 s. I have been struggling on and off for the last week but have gone nowhere. I thought a fresh pair of eyes may see something. Here is my code: const maxAbundant = 28123 function sumOfDivisors(n::Int) f = factor(n) counter = 1 for i in keys(f) count = 1 for j in 1:f[i] count += i^j end counter *= count end counter-n end function isAbundant(n::Int) sumOfDivisors(n) n ? true : false end abundantNumbers=Array(Int,1) abundantNumbers[1]=12 sizehint(abundantNumbers, maxAbundant) for i = 13:maxAbundant if isAbundant(i) push!(abundantNumbers, i) end end isSumOfAbundant=falses(1,maxAbundant) tic() for i = 1:length(abundantNumbers) for j = i:length(abundantNumbers) SumOfAbundant = abundantNumbers[i] + abundantNumbers[j] if SumOfAbundant = maxAbundant isSumOfAbundant[SumOfAbundant]=true else break end end end toc() result=0 for i = 1:maxAbundant if !isSumOfAbundant[i] result += i end end result When run with @time I get: elapsed time: 7.967364175 seconds elapsed time: 8.06121492 seconds (1359946448 bytes allocated, 18.32% gc time) So I am convinced the bit between tic() and toc() is not right and gc time may be a clue but I really can't find why. Any help will be greatly appreciated. One thing I find annoying with Julia is that sometimes what seems to me a very insignificant change in the code has dramatic effect in the execution time. It is anyway a great tool to try things and find solutions quickly. I wish I had had Julia when I started on Project Euler. Thanks, Arnaud
[julia-users] Re: iterator construct seems incorrect?
Tim, The fact that 'next' is called before the loop body rather than after means that the 'done' predicate must provide an answer to the question: if 'next' is called on the current state, then would the result be the end of the data structure? The obvious way to answer that question is to actually invoke 'next' to see what happens. For a balanced tree, there is no simpler way that I know of to answer the question other than calling 'next'. It is possible to avoid the performance hit with additional code complexity by caching the result of 'next', but still, the question remains, why are start/done/next implemented in this way instead of the more obvious way (for example, in the C implementation of for(..; .. ; ..) the 'next' operation is invoked at the end of the body). -- Steve On Wednesday, July 23, 2014 12:29:12 AM UTC+3, vav...@uwaterloo.ca wrote: Dear Julia users, As I have mentioned in earlier posts, I am working on a 2-3 tree implementation of a sort-order dict, that is, a dict in which the (key, value) pairs can be retrieved in the sort-order of the keys. According to section 2.1.7 of the manual, for i = I; body ; end translates to: state = start(I) while !done(I, state) (i,state) = next(I,state) body end The more obvious way to implement the loop would be to put the body BEFORE the 'next' statement, and at first I thought that maybe the manual has a typo. But then I checked the file dict.jl, and I found indeed the code: done(t::ObjectIdDict, i) = is(next(t,i),()) So this means that every loop iteration over an ObjectIdDict requires two calls to 'next', one as part of the call to 'done', and a second one to actually advance the loop. I also looked at the code for 'done' for Dict in dict.jl, and it appears to be buggy(??). It does not check whether everything after the current i is deleted(??) For a 2-3 tree, the 'next' operation is logarithmic time, so requiring it twice per loop iteration is undesirable. Can anyone shed light on why the Julia loop construction is implemented this way, so that two separate calls to 'next' are necessary? I suppose that it is possible with additional code complexity to cache the result of the first call to 'next' inside the state, but what exactly is the rationale for the current design? Thanks, Steve Vavasis
[julia-users] Re: Help needed, running slow
I suspect you might find the profiler helpful: http://julia.readthedocs.org/en/latest/stdlib/profile/ (And the ProfileView.jl package provides a nice visualization of profiler results--you should check it out too!) On Tuesday, July 22, 2014 4:47:09 PM UTC-5, Arnaud Amiel wrote: To learn how to use Julia, I am running through the project Euler problems (I had already solved most of them using other languages) and up to now, they have all comfortably been solved under 1s without any clever algorithm, even sometimes purposely brute forced. However I am stuck on problem 23 (Find the sum of all the positive integers which cannot be written as the sum of two abundant numbers.) which solves in 8 s. The surprising thing to me is that what I assume to be the hard part is solved in 0.1 s. I have been struggling on and off for the last week but have gone nowhere. I thought a fresh pair of eyes may see something. Here is my code: const maxAbundant = 28123 function sumOfDivisors(n::Int) f = factor(n) counter = 1 for i in keys(f) count = 1 for j in 1:f[i] count += i^j end counter *= count end counter-n end function isAbundant(n::Int) sumOfDivisors(n) n ? true : false end abundantNumbers=Array(Int,1) abundantNumbers[1]=12 sizehint(abundantNumbers, maxAbundant) for i = 13:maxAbundant if isAbundant(i) push!(abundantNumbers, i) end end isSumOfAbundant=falses(1,maxAbundant) tic() for i = 1:length(abundantNumbers) for j = i:length(abundantNumbers) SumOfAbundant = abundantNumbers[i] + abundantNumbers[j] if SumOfAbundant = maxAbundant isSumOfAbundant[SumOfAbundant]=true else break end end end toc() result=0 for i = 1:maxAbundant if !isSumOfAbundant[i] result += i end end result When run with @time I get: elapsed time: 7.967364175 seconds elapsed time: 8.06121492 seconds (1359946448 bytes allocated, 18.32% gc time) So I am convinced the bit between tic() and toc() is not right and gc time may be a clue but I really can't find why. Any help will be greatly appreciated. One thing I find annoying with Julia is that sometimes what seems to me a very insignificant change in the code has dramatic effect in the execution time. It is anyway a great tool to try things and find solutions quickly. I wish I had had Julia when I started on Project Euler. Thanks, Arnaud
[julia-users] Re: NotShared Memory
Dear Gray, thank you very much. But your answer does not quite help me. The task have quite different execution time so I have to make sure it is executed in an beneficial order. I have posted below a simplified version of the code. However, the code block below #create local variables does not work. Best wishes, Sebastian - times=linspace(0.1,2.0,10) # times in secs representing different difficult computations sort!(times,rev=true) np = nprocs() n = length(times) #create local variables for p=1:np if p != myid() || np == 1 remotecall(p,stack = Float64p[]) #does not work end end @everywhere function fun(s) mid=myid() sleep(s) #s represents some computation save to local stack push!(stack,s) end #asynchronously do the computations @everywhere i = 1 function nextidx() global i idx=i; i+=1; return idx; end @sync begin for p=1:np if p != myid() || np == 1 @async begin j=1 res=zeros(40); while true idx = nextidx() if idx n break end remotecall(fun, times[idx]) end end end end end # collect the results of the computations for p=1:np if p != myid() || np == 1 tmpStack=fetch(p,stack) #do someting with the results end end
Re: [julia-users] Re: How to overcome versioning issues?
The blog post that keeps on giving :D
On Tuesday, July 22, 2014 11:46:01 AM UTC-4, Elliot Saba wrote:
Ah, I was confusing it with midrange. Thanks everybody! Learn something
new every day. :)
-E
On Tue, Jul 22, 2014 at 11:18 AM, John Myles White johnmyl...@gmail.com
javascript: wrote:
FWIW, the mean of the min and max is called the midrange.
— John
On Jul 22, 2014, at 8:17 AM, Spencer Russell s...@mit.edu javascript:
wrote:
Hi Elliot,
The median isn't the mean of the min and max (though that was fun to say).
Wikipedia says it well:
the median is the numerical value separating the higher half of a data
sample, a population, or a probability distribution, from the lower half.
The median of a finite list of numbers can be found by arranging all the
observations from lowest value to highest value and picking the middle one
(e.g., the median of {3, 3, 5, 9, 11} is 5). If there is an even number of
observations, then there is no single middle value; the median is then
usually defined to be the mean of the two middle values
peace,
s
On Tue, Jul 22, 2014 at 10:27 AM, Ivar Nesje iva...@gmail.com
javascript: wrote:
According to Julia median is defined as
n = length(v)
if isodd(n)
return middle(select!(v,div(n+1,2)))
else
m = select!(v, div(n,2):div(n,2)+1)
return middle(m[1], m[2])
end
Ivar
kl. 16:03:47 UTC+2 tirsdag 22. juli 2014 skrev Elliot Saba følgende:
Reading your post, I'm a little confused Iain. You state:
If we consider only packages with at least 1 package depending on them,
we find the median to be 3 dependent packages but the mean to be 10.5.
This
is due to the 15 or so packages with more than 30 dependent packages.
Now, I'm not the best at statistics, but isn't the median of *x*
defined as *(min(x) + max(x))/2*? If that is the case, (and assuming
that we don't have negative package dependency counts) I don't see how the
median can be 3, but the mean be 10.5. Perhaps you meant the mode was 3?
-E
On Tue, Jul 22, 2014 at 9:55 AM, Iain Dunning iaind...@gmail.com
wrote:
Hah, yeah, strangely relevant.
PkgEval runs nightly (around 1am US Eastern), but obviously with so
many people using Julia there is a lot of room for chaos inbetween runs.
On Tuesday, July 22, 2014 7:58:46 AM UTC-4, Tomas Lycken wrote:
Look what my RSS reader just picked up! =)
http://iaindunning.com/2014/pkg-deps.html
// T
On Tuesday, July 22, 2014 12:37:59 PM UTC+2, Tomas Lycken wrote:
I still think the best way to resolve things if you should encounter
problems, is to notify the maintainers. Most people in this community
respond surprisingly fast =)
There is some automated testing going on already, mainly thanks to
[Iain Dunning](https://github.com/IainNZ)'s amazing work with
PackageEvaluator and related tools. For example, if you click more
options on pkg.julialang.org and then Show package ecosystem
statistics for Julia nightly..., you'll see some great data showing
the
current (and past) state of the entire ecosystem. You'll notice a few
dips
in the green curve, when changes somewhere suddenly broke a lot of
stuff
everywhere - and you'll also see that most of it was resolved in a
matter
of a few days. This happened because semi-automated issues were filed
by
the system against the packages when they broke, and maintainers were
quick
to fix whatever they needed.
In the case of your problems - someone tagging a version without
specifying a correct dependency - that will also be picked up by
PkgEval,
and the maintainer will be notified. However, since PkgEval only runs
every
now and then, and since quite a lot of users today live on the edge
(and
actively report issues when they find them) it's not uncommon that
problems
like this are picked up by users before PkgEval notices them. It's very
likely that, as the ecosystem matures and stabilizes, this problem
won't be
a problem anymore...
// T
On Tuesday, July 22, 2014 11:47:32 AM UTC+2, Andreas Lobinger wrote:
Hello colleagues,
On Monday, July 21, 2014 4:53:17 PM UTC+2, Tomas Lycken wrote:
I think this problem must be resolved by better practices among
package maintainers: in short, the goal must be that as long as you
only
use (the latest) tagged versions of any packages, everything should
Just
Work (TM). That means, in short, that if a package maintainer adds
functionality that depends on some specific addition to a different
package, it is up to that package maintainer to make sure *not* to
tag a new version until the dependency package has tagged one, in
which the
new behavior is included, so the dependency can be correctly
specified.
... in an ideal world. All that we use around julia has a version
number less than 1.0 so hiccups are expected (at least by me). The
question
was rather how i can help myself and if there is some undocumented
work
[julia-users] Re: Help needed, running slow
For what its worth, I put everything from abundantNumbers=Array(Int,1) to result in a function, and ran that function with @time. I got elapsed time: 0.074687051 seconds elapsed time: 0.258023294 seconds (22897960 bytes allocated, 4.74% gc time) which seems right. On Tuesday, July 22, 2014 6:13:40 PM UTC-4, Patrick O'Leary wrote: I suspect you might find the profiler helpful: http://julia.readthedocs.org/en/latest/stdlib/profile/ (And the ProfileView.jl package provides a nice visualization of profiler results--you should check it out too!) On Tuesday, July 22, 2014 4:47:09 PM UTC-5, Arnaud Amiel wrote: To learn how to use Julia, I am running through the project Euler problems (I had already solved most of them using other languages) and up to now, they have all comfortably been solved under 1s without any clever algorithm, even sometimes purposely brute forced. However I am stuck on problem 23 (Find the sum of all the positive integers which cannot be written as the sum of two abundant numbers.) which solves in 8 s. The surprising thing to me is that what I assume to be the hard part is solved in 0.1 s. I have been struggling on and off for the last week but have gone nowhere. I thought a fresh pair of eyes may see something. Here is my code: const maxAbundant = 28123 function sumOfDivisors(n::Int) f = factor(n) counter = 1 for i in keys(f) count = 1 for j in 1:f[i] count += i^j end counter *= count end counter-n end function isAbundant(n::Int) sumOfDivisors(n) n ? true : false end abundantNumbers=Array(Int,1) abundantNumbers[1]=12 sizehint(abundantNumbers, maxAbundant) for i = 13:maxAbundant if isAbundant(i) push!(abundantNumbers, i) end end isSumOfAbundant=falses(1,maxAbundant) tic() for i = 1:length(abundantNumbers) for j = i:length(abundantNumbers) SumOfAbundant = abundantNumbers[i] + abundantNumbers[j] if SumOfAbundant = maxAbundant isSumOfAbundant[SumOfAbundant]=true else break end end end toc() result=0 for i = 1:maxAbundant if !isSumOfAbundant[i] result += i end end result When run with @time I get: elapsed time: 7.967364175 seconds elapsed time: 8.06121492 seconds (1359946448 bytes allocated, 18.32% gc time) So I am convinced the bit between tic() and toc() is not right and gc time may be a clue but I really can't find why. Any help will be greatly appreciated. One thing I find annoying with Julia is that sometimes what seems to me a very insignificant change in the code has dramatic effect in the execution time. It is anyway a great tool to try things and find solutions quickly. I wish I had had Julia when I started on Project Euler. Thanks, Arnaud
[julia-users] Re: Help needed, running slow
I just put all your top-level statements (except for the two helper functions) into a function of its own: julia @time main() elapsed time: 0.162065867 seconds (14434040 bytes allocated) 4179871 I don't think my 5 year old laptop could be *that* much faster than your computer. Take a look at the performance tips section for more advice along these lines: http://docs.julialang.org/en/latest/manual/performance-tips/ On Tuesday, July 22, 2014 6:13:40 PM UTC-4, Patrick O'Leary wrote: I suspect you might find the profiler helpful: http://julia.readthedocs.org/en/latest/stdlib/profile/ (And the ProfileView.jl package provides a nice visualization of profiler results--you should check it out too!) On Tuesday, July 22, 2014 4:47:09 PM UTC-5, Arnaud Amiel wrote: To learn how to use Julia, I am running through the project Euler problems (I had already solved most of them using other languages) and up to now, they have all comfortably been solved under 1s without any clever algorithm, even sometimes purposely brute forced. However I am stuck on problem 23 (Find the sum of all the positive integers which cannot be written as the sum of two abundant numbers.) which solves in 8 s. The surprising thing to me is that what I assume to be the hard part is solved in 0.1 s. I have been struggling on and off for the last week but have gone nowhere. I thought a fresh pair of eyes may see something. Here is my code: const maxAbundant = 28123 function sumOfDivisors(n::Int) f = factor(n) counter = 1 for i in keys(f) count = 1 for j in 1:f[i] count += i^j end counter *= count end counter-n end function isAbundant(n::Int) sumOfDivisors(n) n ? true : false end abundantNumbers=Array(Int,1) abundantNumbers[1]=12 sizehint(abundantNumbers, maxAbundant) for i = 13:maxAbundant if isAbundant(i) push!(abundantNumbers, i) end end isSumOfAbundant=falses(1,maxAbundant) tic() for i = 1:length(abundantNumbers) for j = i:length(abundantNumbers) SumOfAbundant = abundantNumbers[i] + abundantNumbers[j] if SumOfAbundant = maxAbundant isSumOfAbundant[SumOfAbundant]=true else break end end end toc() result=0 for i = 1:maxAbundant if !isSumOfAbundant[i] result += i end end result When run with @time I get: elapsed time: 7.967364175 seconds elapsed time: 8.06121492 seconds (1359946448 bytes allocated, 18.32% gc time) So I am convinced the bit between tic() and toc() is not right and gc time may be a clue but I really can't find why. Any help will be greatly appreciated. One thing I find annoying with Julia is that sometimes what seems to me a very insignificant change in the code has dramatic effect in the execution time. It is anyway a great tool to try things and find solutions quickly. I wish I had had Julia when I started on Project Euler. Thanks, Arnaud
Re: [julia-users] Equivalent for Python 'pass' statement in Julia
Matt, could you elaborate? Sorry, not quite sure what the ? means -- does that mean 'or'? Also not sure about what you mean by the phrase ternary syntax. Here is loosely what I am trying to do: for i in testarray if testarray 0 do this else do nothing It seemed to work when I tested it with nothing after else? On Tuesday, July 22, 2014 5:51:24 PM UTC-4, Matt Bauman wrote: The ternary syntax is one place where an empty block won't suffice — there must be an expression in both branches. In such a case, you can use `nothing` (which is also what an empty block will return). That said, it's more typical to refactor these cases into short-circuiting expressions: cond ? expr : nothing # could be written as: cond expr cond ? nothing : expr # becomes: cond || expr
Re: [julia-users] Re: Juila vs Mathematica (Wolfram language): high-level features
If it's possible, do you mind showing the function you were plotting that lead to the extra lines in Gadfly? The current master should already be using the `group` aesthetic for contour lines. On Tuesday, July 22, 2014 10:06:53 AM UTC-7, Zahirul ALAM wrote: Thanks Stefan, Tomas and Viral. Stefan and Tomas: Contourplot definitely looks very pretty in gadfly. Tomas: But I am afraid the plot contains extra lines which some of you have already pointed to be aesthetic issue. It is not entirely clear how to use the group aesthetic to fix it. I will read on. Viral: I am currently using the PyPlot package. btw: on this regard, I am yet to a straight forward manner to do find dual Y axis or dual X axis plot in either Mathematica, Matlab, Matplotlib, or Maple. May be in Gadfly this is a feature that can be built in. On Tuesday, 22 July 2014 03:08:26 UTC-4, Tomas Lycken wrote: It is only for 2-D plotting, does not do contour or density plot ( two types I tend to use the most). I am sure it will only get improved. There is, actually, some functionality for contour and density plot already, but all the nuts and bolts aren't really tightened yet, and I don't know if the progress so far has been documented at all, but if you have a function `f = (x,y) - z(x,y)`, you can do `plot(f, xmin, xmax, ymin, ymax)` to get a nice contour plot. Support for contour plots of matrices is under construction - take a look at [#293]( https://github.com/dcjones/Gadfly.jl/issues/293) for more details. Density plots is sort-of implemented through [Geom.rectbin]( http://dcjones.github.io/Gadfly.jl/geom_rectbin.html) which may or may not be what you need. // T On Monday, July 21, 2014 11:09:31 PM UTC+2, Zahirul ALAM wrote: Thanks Stefan. I did find out that I can type \alphatab for Unicode α. My point was more to do with the traditional input / output mode. btw if I am not mistaken I think in markup mode the \alphatab does not work. I guess not even auto complete works in markup mode when pressed tab. May be I am doing it wrong. However it works just fine once the block is compiled. But I think that has nothing to do with IJulia. I have indeed met Gadfly. I had Gadfly in mind when I wrote that. It is indeed very pretty. It is only for 2-D plotting, does not do contour or density plot ( two types I tend to use the most). I am sure it will only get improved. On Monday, 21 July 2014 14:48:17 UTC-4, Stefan Karpinski wrote: On Mon, Jul 21, 2014 at 9:55 AM, Zahirul ALAM zahiru...@gmail.com wrote: One feature I would like to see from IJulia may be is that the input of greek and mathematical symbol in way that looks natural, e.g. using subscript, in division, integration etc as way to input. This will definitely be a significant improvement IMHO. You can do Unicode input using LaTeX codes in IJulia by typing, e.g. \alphatab, which will be turned into a Unicode α. That's not as fancy as what you can do in Mathematica, but I'm not sure we want to go there. I find editing Mathematica code pretty irritating and it's not that much better looking except for the traditional output mode, which you cannot use as an input format anyway. second feature is to be able to plot a function in a way one can do in Mathematica. Plotting packages for Julia does this in very limited way (unless I am missing something) Have you met Gadfly https://github.com/dcjones/Gadfly.jl?
[julia-users] Checking for Undefined Reference.
I have a type that contains references to other instances of the same type - like a doubly linked list or - as it's intended use, like a tree like structure. They contain references to a parent of the same types and an array of references to children of the same type. However a root or singly constructed instance of the type will not start out with a parent or children and so these fields will be #undef, how can I check for #undef fields? It didn't say in the types section in the manual, although it did say accessing it is an automatic error so I guess a try block might work - but I don't know if try blocks are preferable in Julia to simply anticipating the #undef. I've normally heard the mantra of anticipating an expected exception rather than make excessive try catches. Thanks.
[julia-users] Re: Checking for Undefined Reference.
isdefined(myobject, :myfield) On Tuesday, July 22, 2014 6:54:00 PM UTC-4, Ben Ward wrote: I have a type that contains references to other instances of the same type - like a doubly linked list or - as it's intended use, like a tree like structure. They contain references to a parent of the same types and an array of references to children of the same type. However a root or singly constructed instance of the type will not start out with a parent or children and so these fields will be #undef, how can I check for #undef fields? It didn't say in the types section in the manual, although it did say accessing it is an automatic error so I guess a try block might work - but I don't know if try blocks are preferable in Julia to simply anticipating the #undef. I've normally heard the mantra of anticipating an expected exception rather than make excessive try catches. Thanks.
Re: [julia-users] Re: iterator construct seems incorrect?
Thanks for clarifying. While I know exactly what you're talking about, and I wasn't around when iterators were designed, I've always assumed that the current behavior follows from two principles: (1) `done` must evaluate to a boolean, and (2) the `item` should not leak out of the scope block defined by the `while` loop. Last I thought through it carefully, the current design seemed inevitable. Best, --Tim On Tuesday, July 22, 2014 02:59:33 PM vava...@uwaterloo.ca wrote: Tim, The fact that 'next' is called before the loop body rather than after means that the 'done' predicate must provide an answer to the question: if 'next' is called on the current state, then would the result be the end of the data structure? The obvious way to answer that question is to actually invoke 'next' to see what happens. For a balanced tree, there is no simpler way that I know of to answer the question other than calling 'next'. It is possible to avoid the performance hit with additional code complexity by caching the result of 'next', but still, the question remains, why are start/done/next implemented in this way instead of the more obvious way (for example, in the C implementation of for(..; .. ; ..) the 'next' operation is invoked at the end of the body). -- Steve On Wednesday, July 23, 2014 12:29:12 AM UTC+3, vav...@uwaterloo.ca wrote: Dear Julia users, As I have mentioned in earlier posts, I am working on a 2-3 tree implementation of a sort-order dict, that is, a dict in which the (key, value) pairs can be retrieved in the sort-order of the keys. According to section 2.1.7 of the manual, for i = I; body ; end translates to: state = start(I) while !done(I, state) (i,state) = next(I,state) body end The more obvious way to implement the loop would be to put the body BEFORE the 'next' statement, and at first I thought that maybe the manual has a typo. But then I checked the file dict.jl, and I found indeed the code: done(t::ObjectIdDict, i) = is(next(t,i),()) So this means that every loop iteration over an ObjectIdDict requires two calls to 'next', one as part of the call to 'done', and a second one to actually advance the loop. I also looked at the code for 'done' for Dict in dict.jl, and it appears to be buggy(??). It does not check whether everything after the current i is deleted(??) For a 2-3 tree, the 'next' operation is logarithmic time, so requiring it twice per loop iteration is undesirable. Can anyone shed light on why the Julia loop construction is implemented this way, so that two separate calls to 'next' are necessary? I suppose that it is possible with additional code complexity to cache the result of the first call to 'next' inside the state, but what exactly is the rationale for the current design? Thanks, Steve Vavasis
Re: [julia-users] ++ as string concatenation operator
Thanks for the link, Spencer. This obviously belongs in the FAQ for now. On Tue, Jul 22, 2014 at 2:19 PM, Spencer Russell s...@mit.edu wrote: Why is string concatenation done with * not + https://groups.google.com/d/topic/julia-users/nQg_d_n0t1Q/discussion peace, s On Tue, Jul 22, 2014 at 4:58 PM, Stefan Karpinski ste...@karpinski.org wrote: many threads: search string concatenation On Tue, Jul 22, 2014 at 1:55 PM, Ben Arthur bjarthu...@gmail.com wrote: relatedly, is there a thread somewhere that explains why * is used for string concatenation and ^ for string repetition?
[julia-users] how to properly nest modules in a package
Lets say I'm making a package P.jl. Inside P I define modules A, B and C all in separate files. I'd like to use C inside of A and B, and export a function from C from P. So right now B looks like include(C.jl) module B using C B body end And A looks like include(C.jl) module A using C A body end And P looks like include(A.jl) include(B.jl) include(C.jl) module P using A,B,C P body end I suspect that I'm doing it wrong for a few reasons. 1. I'm using two lines to get a module instead of one (include + using) 2. I've included C three times in P. 3. Autoreload.jl is complaining At the least it seems like I should remove include(C.jl) from P, which seems to help. I'd appreciate some general guidance.
Re: [julia-users] Re: iterator construct seems incorrect?
Two separate calls to next certainly aren't in general necessary, and I haven't hit any issues implementing the iterator interface before. In fact, it felt quite natural in the end. I suspect that no matter which way you do the iteration interface, you'll be able to find an example where you'd prefer it to be the other way - it'd be nice to formalize that. On Tuesday, July 22, 2014 7:34:18 PM UTC-4, Tim Holy wrote: Thanks for clarifying. While I know exactly what you're talking about, and I wasn't around when iterators were designed, I've always assumed that the current behavior follows from two principles: (1) `done` must evaluate to a boolean, and (2) the `item` should not leak out of the scope block defined by the `while` loop. Last I thought through it carefully, the current design seemed inevitable. Best, --Tim On Tuesday, July 22, 2014 02:59:33 PM vav...@uwaterloo.ca javascript: wrote: Tim, The fact that 'next' is called before the loop body rather than after means that the 'done' predicate must provide an answer to the question: if 'next' is called on the current state, then would the result be the end of the data structure? The obvious way to answer that question is to actually invoke 'next' to see what happens. For a balanced tree, there is no simpler way that I know of to answer the question other than calling 'next'. It is possible to avoid the performance hit with additional code complexity by caching the result of 'next', but still, the question remains, why are start/done/next implemented in this way instead of the more obvious way (for example, in the C implementation of for(..; .. ; ..) the 'next' operation is invoked at the end of the body). -- Steve On Wednesday, July 23, 2014 12:29:12 AM UTC+3, vav...@uwaterloo.ca wrote: Dear Julia users, As I have mentioned in earlier posts, I am working on a 2-3 tree implementation of a sort-order dict, that is, a dict in which the (key, value) pairs can be retrieved in the sort-order of the keys. According to section 2.1.7 of the manual, for i = I; body ; end translates to: state = start(I) while !done(I, state) (i,state) = next(I,state) body end The more obvious way to implement the loop would be to put the body BEFORE the 'next' statement, and at first I thought that maybe the manual has a typo. But then I checked the file dict.jl, and I found indeed the code: done(t::ObjectIdDict, i) = is(next(t,i),()) So this means that every loop iteration over an ObjectIdDict requires two calls to 'next', one as part of the call to 'done', and a second one to actually advance the loop. I also looked at the code for 'done' for Dict in dict.jl, and it appears to be buggy(??). It does not check whether everything after the current i is deleted(??) For a 2-3 tree, the 'next' operation is logarithmic time, so requiring it twice per loop iteration is undesirable. Can anyone shed light on why the Julia loop construction is implemented this way, so that two separate calls to 'next' are necessary? I suppose that it is possible with additional code complexity to cache the result of the first call to 'next' inside the state, but what exactly is the rationale for the current design? Thanks, Steve Vavasis
Re: [julia-users] Re: iterator construct seems incorrect?
The other point to make is that if you find it more natural to do your incrementing inside done, there's no rule saying that next has to do any actual work. You can cache the item somewhere and just have next fetch it. --Tim On Tuesday, July 22, 2014 06:13:25 PM Iain Dunning wrote: Two separate calls to next certainly aren't in general necessary, and I haven't hit any issues implementing the iterator interface before. In fact, it felt quite natural in the end. I suspect that no matter which way you do the iteration interface, you'll be able to find an example where you'd prefer it to be the other way - it'd be nice to formalize that. On Tuesday, July 22, 2014 7:34:18 PM UTC-4, Tim Holy wrote: Thanks for clarifying. While I know exactly what you're talking about, and I wasn't around when iterators were designed, I've always assumed that the current behavior follows from two principles: (1) `done` must evaluate to a boolean, and (2) the `item` should not leak out of the scope block defined by the `while` loop. Last I thought through it carefully, the current design seemed inevitable. Best, --Tim On Tuesday, July 22, 2014 02:59:33 PM vav...@uwaterloo.ca javascript: wrote: Tim, The fact that 'next' is called before the loop body rather than after means that the 'done' predicate must provide an answer to the question: if 'next' is called on the current state, then would the result be the end of the data structure? The obvious way to answer that question is to actually invoke 'next' to see what happens. For a balanced tree, there is no simpler way that I know of to answer the question other than calling 'next'. It is possible to avoid the performance hit with additional code complexity by caching the result of 'next', but still, the question remains, why are start/done/next implemented in this way instead of the more obvious way (for example, in the C implementation of for(..; .. ; ..) the 'next' operation is invoked at the end of the body). -- Steve On Wednesday, July 23, 2014 12:29:12 AM UTC+3, vav...@uwaterloo.ca wrote: Dear Julia users, As I have mentioned in earlier posts, I am working on a 2-3 tree implementation of a sort-order dict, that is, a dict in which the (key, value) pairs can be retrieved in the sort-order of the keys. According to section 2.1.7 of the manual, for i = I; body ; end translates to: state = start(I) while !done(I, state) (i,state) = next(I,state) body end The more obvious way to implement the loop would be to put the body BEFORE the 'next' statement, and at first I thought that maybe the manual has a typo. But then I checked the file dict.jl, and I found indeed the code: done(t::ObjectIdDict, i) = is(next(t,i),()) So this means that every loop iteration over an ObjectIdDict requires two calls to 'next', one as part of the call to 'done', and a second one to actually advance the loop. I also looked at the code for 'done' for Dict in dict.jl, and it appears to be buggy(??). It does not check whether everything after the current i is deleted(??) For a 2-3 tree, the 'next' operation is logarithmic time, so requiring it twice per loop iteration is undesirable. Can anyone shed light on why the Julia loop construction is implemented this way, so that two separate calls to 'next' are necessary? I suppose that it is possible with additional code complexity to cache the result of the first call to 'next' inside the state, but what exactly is the rationale for the current design? Thanks, Steve Vavasis
Re: [julia-users] Re: iterator construct seems incorrect?
it can however to better for done() to do no work, but to have next actually compute the next+1 state: start(x) = next(x) next(x,i) = (i, next(x)) done(x,i) = (i===sentinel) this makes next somewhat more expensive to call repeatedly, but has the benefit that the user can hold onto a reference to any arbitrary node (until they mutate the underlying object) to perform custom iteration sequences (where sentinel could either be a special value, or a boolean that is part of the state tuple) On Tue, Jul 22, 2014 at 9:42 PM, Tim Holy tim.h...@gmail.com wrote: The other point to make is that if you find it more natural to do your incrementing inside done, there's no rule saying that next has to do any actual work. You can cache the item somewhere and just have next fetch it. --Tim On Tuesday, July 22, 2014 06:13:25 PM Iain Dunning wrote: Two separate calls to next certainly aren't in general necessary, and I haven't hit any issues implementing the iterator interface before. In fact, it felt quite natural in the end. I suspect that no matter which way you do the iteration interface, you'll be able to find an example where you'd prefer it to be the other way - it'd be nice to formalize that. On Tuesday, July 22, 2014 7:34:18 PM UTC-4, Tim Holy wrote: Thanks for clarifying. While I know exactly what you're talking about, and I wasn't around when iterators were designed, I've always assumed that the current behavior follows from two principles: (1) `done` must evaluate to a boolean, and (2) the `item` should not leak out of the scope block defined by the `while` loop. Last I thought through it carefully, the current design seemed inevitable. Best, --Tim On Tuesday, July 22, 2014 02:59:33 PM vav...@uwaterloo.ca javascript: wrote: Tim, The fact that 'next' is called before the loop body rather than after means that the 'done' predicate must provide an answer to the question: if 'next' is called on the current state, then would the result be the end of the data structure? The obvious way to answer that question is to actually invoke 'next' to see what happens. For a balanced tree, there is no simpler way that I know of to answer the question other than calling 'next'. It is possible to avoid the performance hit with additional code complexity by caching the result of 'next', but still, the question remains, why are start/done/next implemented in this way instead of the more obvious way (for example, in the C implementation of for(..; .. ; ..) the 'next' operation is invoked at the end of the body). -- Steve On Wednesday, July 23, 2014 12:29:12 AM UTC+3, vav...@uwaterloo.ca wrote: Dear Julia users, As I have mentioned in earlier posts, I am working on a 2-3 tree implementation of a sort-order dict, that is, a dict in which the (key, value) pairs can be retrieved in the sort-order of the keys. According to section 2.1.7 of the manual, for i = I; body ; end translates to: state = start(I) while !done(I, state) (i,state) = next(I,state) body end The more obvious way to implement the loop would be to put the body BEFORE the 'next' statement, and at first I thought that maybe the manual has a typo. But then I checked the file dict.jl, and I found indeed the code: done(t::ObjectIdDict, i) = is(next(t,i),()) So this means that every loop iteration over an ObjectIdDict requires two calls to 'next', one as part of the call to 'done', and a second one to actually advance the loop. I also looked at the code for 'done' for Dict in dict.jl, and it appears to be buggy(??). It does not check whether everything after the current i is deleted(??) For a 2-3 tree, the 'next' operation is logarithmic time, so requiring it twice per loop iteration is undesirable. Can anyone shed light on why the Julia loop construction is implemented this way, so that two separate calls to 'next' are necessary? I suppose that it is possible with additional code complexity to cache the result of the first call to 'next' inside the state, but what exactly is the rationale for the current design? Thanks, Steve Vavasis
[julia-users] Re: Where to get the documentation for version 0.3?
1. Download the source, and unzip 2. Under julia/doc its all there. 3. Run make for the details On Tuesday, July 22, 2014 10:56:56 PM UTC-5, K leo wrote:
Re: [julia-users] Re: Where to get the documentation for version 0.3?
Also online: http://docs.julialang.org/en/latest/. On Tue, Jul 22, 2014 at 9:00 PM, Michael Prentiss mcprent...@gmail.com wrote: 1. Download the source, and unzip 2. Under julia/doc its all there. 3. Run make for the details On Tuesday, July 22, 2014 10:56:56 PM UTC-5, K leo wrote:
Re: [julia-users] Re: how to properly nest modules in a package
Ok I see how that works, I wasn't aware of the ..C syntax. That solves the problem asked about, but I'm left with another question. Take for example module A module B foo()=4 export foo end foo() end That doesn't work, I get ERROR: foo not defined because foo is not actually in the A namespace. But if I add using B I get ERROR: B not found. So how do I define B inside A, but also have A import the things that B exports?
