Re: [julia-users] Why does my Julia code run so slow?
Kuba, most of the relevant discussion was happening here: https://github.com/JuliaLang/julia/pull/8699 On Monday, 23 February 2015 07:27:55 UTC, Kuba Roth wrote: Sorry for a off topic question. @Viral. Is there any discussion going on about new GC you mentioned? Can you point it to me please? I wonder what are the changes? Thnaks.
Re: [julia-users] Re: Share Library and Julia
http://www.agner.org/optimize/calling_conventions.pdf --Tim On Monday, February 23, 2015 01:33:08 AM DP wrote: What are the suffices on account of creation of shared library(c++) i = Int d = Double etc? On Monday, February 23, 2015 at 2:56:21 PM UTC+5:30, Jeff Waller wrote: What can be the problem? I think this: jeffw@dub1:~$ echo _Z6CP_lliPc | c++filt CP_lli(char*) jeffw@dub1:~$ echo _Z6CP_lliPh | c++filt CP_lli(unsigned char*)
[julia-users] Re: splice! function. Instead of removing a single item, remove a collection of items stored in an array.
Thanks for the reply. I did try deleteat! without much success. What did work for me was the following though: errors=reverse(errors) #start with the largest index first and work down for x=1:length(errors) splice!(data,errors[x]) end On Monday, February 23, 2015 at 8:17:29 AM UTC, Josh Langsfeld wrote: corrected_data = deleteat!(x, errors) should be what you're looking for. Alternately, a more functionally pure way to do it is to compute the good indices and then just do corrected_data = x[good_idx], though this will make a copy of those elements of x. On Sunday, February 22, 2015 at 3:14:11 PM UTC-5, Aero_flux wrote: Hello everybody, I might be going about this the wrong way. I have a sequence of data in a 1-D array x. Now I have done some calculations and have a 1-D array of the indexed points in x that erroneous. What I would like to to is remove all the data points in x that uses the saved indices. I figured I would use corrected_data = splice!(x, errors) but of course it won't take arrays. Any hints? Many thanks
Re: [julia-users] Re: Suppress printed output from PyPlot
Hi,
thank you for the tips but the second method return an error:
ERROR: IJulia not defined
in withfig at /home/gdmsl/.julia/v0.3/PyPlot/src/PyPlot.jl:547
On Fri, Feb 13, 2015 at 10:16 PM, Steven G. Johnson stevenj@gmail.com
wrote:
On Friday, February 13, 2015 at 4:58:44 AM UTC-5, gdmsl wrote:
julia plot(rand(10),rand(10));
Figure(PyObject matplotlib.figure.Figure object at 0x7f7979d24dd8)
Figure(PyObject matplotlib.figure.Figure object at 0x7f7979d24dd8)
I really need to suppress output like Figure(PyObject
matplotlib.figure.Figure object at 0x7f7979d24dd8)
The plot command (and similar) displays its output as a side effect (think
of it as a println statement, but via display). In the REPL, the
default display backend just calls `print`. You can suppress this in
two ways:
1) You could define your own display backend that silently ignores
`Figure` objects, and push it onto the display stack (see the Multimedia
I/O section of the manual.
2) You could wrap your plot commands in withfig:
f = figure()
withfig(f) do
plot commands ...
end;
The withfig command converts the plot results from a side effect into a
return value (which you can suppress with a semicolon). It was intended
for use with the Interact package, but should work as well here.
[julia-users] Passing pointer to struct to a julia callback function
Hello!
I started experimenting with Julia-C interface and found out that it
seems to be hard to pass a struct defined in C to a callback function
defined in Julia as follows:
type ab_struct
a::Cint
b::Cdouble
end
function const_ab_struct(a_::Cint, b_::Cdouble, c_::Ptr{ab_struct})
c_ref = unsafe_pointer_to_objref(c_)
c_ref.a = a_
c_ref.b = b_
return 0
retval::Cint
end
const c_const_ab_struct = cfunction(const_ab_struct, Cint, (Cint, Cdouble,
Ptr{ab_struct}))
ccall( (:testme_ab_callback, my_lib), Void, (Ptr{Void},),
c_const_ab_struct)
In my_lib dynamic library I have
typedef struct {
int a;
double b;
} ab_struct;
void testme_ab_callback(int (*fun)(int, double, ab_struct*))
{
ab_struct foo;
fun(1,0.5,foo);
printf(%i, %f\n, foo.a, foo.b);
}
This will yield segfault (seemingly) from c_ref.a=a_ (I'm using osx 10.10
and julia version 0.3.5 installed from .dmg)
Am I doing something wrong (which is a more probable than..)? Is this kind
of struct-callback construct possible to implement (cleanly)?
Thanks,
Juhani
[julia-users] Project organization
I'm having some trouble figuring out the proper way to organize a project in Julia. I understand how a *package* is organized (from the many available examples), but now I am writing code that uses various packages (my own and others) and I don't feel like I have a good idea on how a *project* should be organized. Let's say I have a project called Major Calculations that uses the packages Foo.jl, Bar.jl, and Important.jl. 1. Should I use Pkg.generate() to create Major Calculations? In other words, should it be a package (in the julia sense)? It isn't going to be a library of types and methods, but rather a project where I give it large amounts of data and it outputs modified data and plots. 2. Should I break down Major Calculations into separate modules? For example, there are groups of functions that are related. Should each of these get their own module? 3. What should the directory layout of Major Calculations be? Should I have a main.jl? What if I want to process the data in steps (e.g., first.jl, second.jl, ...). 4. When I use the project, I want to pass it two files: a configuration file, and the data file. The configuration file will define a bunch of constants that are used throughout Major Calculations (i.e., it is required). Should these be declared as global consts? If that's the case, should I have a file (e.g., constants.jl) that I include at the start of main.jl that reads the file and just sets all constants? And should this be completely in the global scope? 5. If the two modules Foo and Bar both export functions with the same name (but different parameters), how do I avoid conflicts? Should the project use import instead of using? In essence, I am just having a hard time differentiating how code is organized when it is a package for general usage, compared to how it organized when it is a project used to process data. Thanks for your time.
Re: [julia-users] Re: Tensor-product function for multidimensional arrays (2 dims)
Hey Tim,
Yep, sure does.
For those who find this later (i.e. future me), here are a couple ways to
replicate the example in the numpy docs using TensorOperations.jl:
using TensorOperations, IndexNotation
# NOTE: we build it inside-out and then permute to match numpy's row major
# reshape with Julia's column major reshape.
a = permutedims(reshape(0:59.0, (5, 4, 3)), (3, 2, 1))
b = permutedims(reshape(0:23.0, (2, 3, 4)), (3, 2, 1))
# first method -- using IndexNotation
c1 = a[la,b,c]*b[lb,a,d]
# second method -- calling tensorcontract
c2 = tensorcontract(a, [a, b, c], b, [b, a, d])
# third method -- using inlace operations
c3 = Array(Float64, 5, 2)
TensorOperations.tensorcontract!(1,a,[a, b, c],'N',b,[b, a,
d],'N',0.0, c3,[c, d])
On Sunday, February 22, 2015 at 6:34:12 AM UTC-5, Tim Holy wrote:
Does TensorOperations.jl do what you want?
--Tim
On Sunday, February 22, 2015 12:32:34 AM Viral Shah wrote:
Best to file an issue.
-viral
On Sunday, February 22, 2015 at 12:52:17 PM UTC+5:30, Spencer Lyon
wrote:
Bump on this thread. I need this functionality again...
On Friday, December 6, 2013 at 11:04:44 AM UTC-5, Spencer Lyon wrote:
I am working with tensors with more than 2 dimensions. I would like
to
find a Julia equivalent to the numpy function tensordot. The
docstring
for the function explains its use well, so I will just copy/paste it
here:
def tensordot(a, b, axes=2):
Compute tensor dot product along specified axes for arrays =
1-D.
Given two tensors (arrays of dimension greater than or equal to
one),
``a`` and ``b``, and an array_like object containing two
array_like
objects, ``(a_axes, b_axes)``, sum the products of ``a``'s and
``b``'s
elements (components) over the axes specified by ``a_axes`` and
``b_axes``. The third argument can be a single non-negative
integer_like scalar, ``N``; if it is such, then the last ``N``
dimensions of ``a`` and the first ``N`` dimensions of ``b`` are
summed
over.
Parameters
--
a, b : array_like, len(shape) = 1
Tensors to dot.
axes : variable type
* integer_like scalar
Number of axes to sum over (applies to both arrays); or
* array_like, shape = (2,), both elements array_like
Axes to be summed over, first sequence applying to ``a``,
second
to ``b``.
See Also
dot, einsum
Notes
-
When there is more than one axis to sum over - and they are not
the
last
(first) axes of ``a`` (``b``) - the argument ``axes`` should
consist
of
two sequences of the same length, with the first axis to sum over
given
first in both sequences, the second axis second, and so forth.
Examples
A traditional example:
a = np.arange(60.).reshape(3,4,5)
b = np.arange(24.).reshape(4,3,2)
c = np.tensordot(a,b, axes=([1,0],[0,1]))
c.shape
(5, 2)
c
array([[ 4400., 4730.],
[ 4532., 4874.],
[ 4664., 5018.],
[ 4796., 5162.],
[ 4928., 5306.]])
# A slower but equivalent way of computing the same...
d = np.zeros((5,2))
for i in range(5):
... for j in range(2):
... for k in range(3):
... for n in range(4):
... d[i,j] += a[k,n,i] * b[n,k,j]
c == d
array([[ True, True],
[ True, True],
[ True, True],
[ True, True],
[ True, True]], dtype=bool)
I think the functionality laid out in the explicit for loops would be
quite easy to replicate using the @nloops and @nref macros in
Cartesian,
but I am not sure if that will be most performant way to implement
such a
function. Also, I wanted to check here to see if this has already
been
done
before I spend some time working on this.
Thanks,
[julia-users] Re: Project organization
Thanks for your input. I have some questions about your reply: 4. Yes, putting constants in global scope is fine. I believe there will not be a performance issue is you mark the variables as const How do I load the configuration file if Major Calculations is a package? using MajorCalculations won't work because MajorCalculations.jl requires a configuration file to define constants. And how to I pass the data to MajorCalculations.jl? For example, if MajorCalculations is my main file, I would like to write $ julia MajorCalculations.jl configuration.txt data.txt But how does this work in conjunction with using or import MajorCalculations? Thanks.
[julia-users] Re: splice! function. Instead of removing a single item, remove a collection of items stored in an array.
It's working fine for me:
julia x1 = rand(1:10,5); x2 = copy(x1)
5-element Array{Int64,1}:
7
4
6
8
2
julia errs = [2,4];
julia deleteat!(x1,errs);
julia x1
3-element Array{Int64,1}:
7
6
2
julia for i=length(errs):-1:1
splice!(x2,errs[i])
end
julia x2
3-element Array{Int64,1}:
7
6
2
On Monday, February 23, 2015 at 8:07:43 AM UTC-5, Aero_flux wrote:
Thanks for the reply. I did try deleteat! without much success. What did
work for me was the following though:
errors=reverse(errors) #start with the largest index first and work down
for x=1:length(errors)
splice!(data,errors[x])
end
On Monday, February 23, 2015 at 8:17:29 AM UTC, Josh Langsfeld wrote:
corrected_data = deleteat!(x, errors) should be what you're looking for.
Alternately, a more functionally pure way to do it is to compute the good
indices and then just do corrected_data = x[good_idx], though this will
make a copy of those elements of x.
On Sunday, February 22, 2015 at 3:14:11 PM UTC-5, Aero_flux wrote:
Hello everybody,
I might be going about this the wrong way. I have a sequence of data in
a 1-D array x. Now I have done some calculations and have a 1-D array of
the indexed points in x that erroneous. What I would like to to is remove
all the data points in x that uses the saved indices. I figured I would
use corrected_data = splice!(x, errors) but of course it won't take arrays.
Any hints?
Many thanks
Re: [julia-users] Passing pointer to struct to a julia callback function
unsafe_pointer_to_objref expects a reference to a Julia object (allocated
by Julia), whereas you've passed a reference to memory allocated by C.
Julia types are layout-compatible with C, but it still matters who
allocated them when doing the translation.
unsafe_load should work for you.
On Mon Feb 23 2015 at 8:57:50 AM Juhani Kataja juh...@gmail.com wrote:
Hello!
I started experimenting with Julia-C interface and found out that it
seems to be hard to pass a struct defined in C to a callback function
defined in Julia as follows:
type ab_struct
a::Cint
b::Cdouble
end
function const_ab_struct(a_::Cint, b_::Cdouble, c_::Ptr{ab_struct})
c_ref = unsafe_pointer_to_objref(c_)
c_ref.a = a_
c_ref.b = b_
return 0
retval::Cint
end
const c_const_ab_struct = cfunction(const_ab_struct, Cint, (Cint, Cdouble,
Ptr{ab_struct}))
ccall( (:testme_ab_callback, my_lib), Void, (Ptr{Void},),
c_const_ab_struct)
In my_lib dynamic library I have
typedef struct {
int a;
double b;
} ab_struct;
void testme_ab_callback(int (*fun)(int, double, ab_struct*))
{
ab_struct foo;
fun(1,0.5,foo);
printf(%i, %f\n, foo.a, foo.b);
}
This will yield segfault (seemingly) from c_ref.a=a_ (I'm using osx 10.10
and julia version 0.3.5 installed from .dmg)
Am I doing something wrong (which is a more probable than..)? Is this kind
of struct-callback construct possible to implement (cleanly)?
Thanks,
Juhani
[julia-users] Re: Project organization
So I am not sure there are cannonical answers to some of these questions, but I'll try to address some of them based of my current opininions. So imho, and fwiw etc... 1. Major Calculations should mostly be a package. A package is not necessarily a library, it is a self contained unit of code sharing. So if you want to share your code publicly, it should most certainly be a package. If its only a private piece of code, private to you or your organisation, then you can get away with not making it a package. However, I think you would benefit from making it one, if only for the reason that the src/ directory of all packages are automatically in the load path. 2. I think this is a personal choice based on your domain and design. Creating separate modules will create clear boundaries between parts of your code. Only you can decide if that is valuable to you. 3. If you make this a package, then your main file should be MajorCalculations.jl . This file will be loaded when calling using MajorCalculations . Beyond that, your are free to layout your code as you wish. The majority of Julia packages these days I think have functionality in separate files (and optionally separate modules) that are included in the main file for the package In terms of steps, I believe you should model your steps as function calls. So one way would be #file: MajorCalculations.jl module MajorCalculations include(first.jl) #define function first() include(second.jl) #define function second() function process() first() second() end #function end #process 4. Yes, putting constants in global scope is fine. I believe there will not be a performance issue is you mark the variables as const 5. If the functions have different number of types of parameters, they will not clash, they will be multiple methods of a single function (so long as correcly imported). If they really clash, then don't export them from the module, call them with a fully qualified name Module.func() On Monday, 23 February 2015 14:39:49 UTC, Marc Gallant wrote: I'm having some trouble figuring out the proper way to organize a project in Julia. I understand how a *package* is organized (from the many available examples), but now I am writing code that uses various packages (my own and others) and I don't feel like I have a good idea on how a *project* should be organized. Let's say I have a project called Major Calculations that uses the packages Foo.jl, Bar.jl, and Important.jl. 1. Should I use Pkg.generate() to create Major Calculations? In other words, should it be a package (in the julia sense)? It isn't going to be a library of types and methods, but rather a project where I give it large amounts of data and it outputs modified data and plots. 2. Should I break down Major Calculations into separate modules? For example, there are groups of functions that are related. Should each of these get their own module? 3. What should the directory layout of Major Calculations be? Should I have a main.jl? What if I want to process the data in steps (e.g., first.jl, second.jl, ...). 4. When I use the project, I want to pass it two files: a configuration file, and the data file. The configuration file will define a bunch of constants that are used throughout Major Calculations (i.e., it is required). Should these be declared as global consts? If that's the case, should I have a file (e.g., constants.jl) that I include at the start of main.jl that reads the file and just sets all constants? And should this be completely in the global scope? 5. If the two modules Foo and Bar both export functions with the same name (but different parameters), how do I avoid conflicts? Should the project use import instead of using? In essence, I am just having a hard time differentiating how code is organized when it is a package for general usage, compared to how it organized when it is a project used to process data. Thanks for your time.
[julia-users] Bokeh.jl update released: call for feedback
To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
[julia-users] How to store the state of current rand generator (not set the seed)
I'm trying to build a simulation model with sequential stages. I only want to set the seed for the random number generator once at the very start of the simulation comparing different possible strategies. Stage 1 is common to all strategies and involves running lots of sims to reach stage 2 . At this stage my strategies follow different routes. Ideally I'd like to store the state of the random number generator just before starting stage 2 (and be able to recall it at a later time). That way I can run my first strategy through, then reset to the same state at the start of stage 2 and run the next strategy through, etc. All strategies then facing the same random conditions (without having to rerun stage 1 or set another seed at stage 2).. Are there such commands that store and reset the number generator to a particular state? Any help much appreciated. Best, Steve
[julia-users] What was allp function and what happened to it?
I have been looking at the following code snippet from the julia-dev forum:
valuetypeof(::()) = ()
valuetypeof{T}(::(T,)) = T
function valuetypeof(x::Tuple)
t = typeof(x[1])
@assert allp(y-typeof(y)==t, x)
t
end
I would like to know what allp is and what happened to it?
Thanks
Re: [julia-users] Bokeh.jl update released: call for feedback
Thanks for being accepting of my provocation. Some emphasis on graphics makes sense, I just think it would be a mistake to spend too long wrestling with c libraries when projects like threejs show how much can be done with just javascript. Technologies like chrome, v8, html5 have consumed masses of time and money, it makes sense to piggy back of as much of it as possible. The saving file -- opening file is definitely just the first step, websockets should allow real time data transfer in both directions. HTML5 can definitely handle the graphs, take a look at these examples: http://dlmf.nist.gov/21.4.F1h.webgl So I think there's no reason why the above example shouldn't be possible with nothing more than the Julia standard library, WebSockets.jl, reference to a JavaScript file and a browser. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 20:16, Tim Holy tim.h...@gmail.com wrote: On Monday, February 23, 2015 11:19:17 AM Samuel Colvin wrote: Answers inline below. But generally I'm not suggesting that Bokeh.jl is a complete or a viable all round option yet: I was just making a general point (and saying someone mildly antagonistic to kick off some debate, sorry). Oh, I appreciate your interaction on this. While we've made a lot of progress, there's still room for improvement in our graphics subspace, and not very much unity. (I need to check out Mike's Blink.jl, too.) Perhaps at the next JuliaCon graphics can be a big topic of discussion and perhaps hacking. I think you're probably right about WebGL, Bokeh doesn't have any support for 3D plotting yet, although I read somewhere (can't find it now) that they're looking at all the options and will work on 3D when they decide on a good approach - maybe that says a lot in itself. For some examples of 3D plotting in the browser plotly have some pretty cool demos: https://plot.ly/python/3d-plots-tutorial/ Those are indeed nice, but for some insight into about what's actually possible...check out this amazing video by Simon Danish (using his GLPlot.jl collection of packages): https://www.youtube.com/watch?v=nJdGHVY2b2g It's my understanding that this video was just capturing what was going on inside a window on his desktop, *in real time*. That would be pretty hard to achieve by saving data to files and popping up browser windows... --Tim - I'm worried about the overhead of plotting huge datasets. Because I'm too lazy to check for myself :-), can you describe how do you pass data to Bokeh? Can you do it without making a copy? (I.e., in the RAM of your machine, there is only one copy of the data, ever, and both the julia side and the HTML side use the same chunk of RAM.) If so, this may not be so bad. If conversely you have to convert to ASCII or something, that's a dealbreaker. I'm not sure it's a dealbreaker but all Bokeh.jl does is write an HTML file with a reference to bokeh.js and insert the plot data in a big clump of JSON. It then just prompts your default browser to open that file. I know it sounds inefficient, but in the end there's a finite limit on how much data you should ever have to pass to a plot - enough data to fill the screen. If your passing GB (or even MB normally) of data to the plot there's a lot of down sampling you can do before it will be noticeable in the plot. That down sampling should be done in Julia, but obviously that's not started yet. The timing above is just the time taken to generate and write the HTML file, that's why I included (in my first message) a manual measurement of how long it take to display the data in chrome - about 6 seconds. - Can you point me to how one writes callback functions? (User clicks on a single point on a plot, I want it to call back to my *julia* code so I can do some more detailed analysis/visualization on the data corresponding to that particular point. I don't want to have to write that code in javascript.) I imagine this is possible (probably some kind of socket communication?), but I'd love to have someone point me to how it's done. There may be circumstances where one wants fast callbacks, although for interactive usage I expect that callback time will be dwarfed by the rendering time. Bokeh can do this but not Bokeh.jl yet, It should just require sockets and will call a function in Julia so no javascript required. These are the things that make me worry about relying on HTML/javascript. I also recognize that path holds some attractions. Yes the ease of installation, publishing and transferring HTML plots is pretty cool. Do you know of another plotting library which has a self contained export format for interactive plots which virtually every computer in the world has a viewer for? --Tim
Re: [julia-users] Re: World of Julia
I wonder if there isn't some API option to exclude them – they must already have this information, since they use it on the site. On Mon, Feb 23, 2015 at 3:13 PM, Ivar Nesje iva...@gmail.com wrote: Strange that GitHub excludes merge commits on their site, but not in their API. mandag 23. februar 2015 19.57.19 UTC+1 skrev Jiahao Chen følgende: Fair enough, but that would mean actually parsing the commit history :) Thanks, Jiahao Chen Staff Research Scientist MIT Computer Science and Artificial Intelligence Laboratory On Mon, Feb 23, 2015 at 1:08 PM, Patrick O'Leary patrick...@gmail.com wrote: On Sunday, February 22, 2015 at 5:50:09 PM UTC-6, Jiahao Chen wrote: World of Julia is now updated in time for the 2015 Oscars. 336 contributors to JuliaLang/julia 545 packages 695 devs total IJulia notebook: https://github.com/jiahao/ijulia-notebooks/blob/ma ster/2014-06-30-world-of-julia.ipynb Nbviewer link: http://nbviewer.ipython.org/urls/raw.github.com/jiahao /ijulia-notebooks/master/2014-06-30-world-of-julia.ipynb A small suggestion: it may be more insightful if you remove merge commits; I would say I'm definitely overcounted in the current results.
Re: [julia-users] Bokeh.jl update released: call for feedback
Gadfly, while awesome, isn't exactly a speed demon – I think you'd need to compare with something like native visualization using Gtk. On Mon, Feb 23, 2015 at 1:27 PM, Samuel Colvin s...@muelcolvin.com wrote: You're probably right about research publications, I guess plots these don't need to be interactive which makes things easier from a cross platform perspective. Performance wise I'm not sure you're right, with Julia 0.3.6 and latest packages: julia using Gadfly julia x=1:100 1:100 julia y=sqrt(x); julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 33.860814218 seconds (2043746808 bytes allocated, 3.83% gc time) julia import Bokeh julia Bokeh.autoopen(true) true julia @time Bokeh.plot(x, y) elapsed time: 1.557460583 seconds (125617712 bytes allocated) Plot(Bokeh Plot with 1 datacolumns) Timing on my phone, the Bokeh plot had opened in chrome in 6 seconds. It was a little slow but still fine to zoom/pan etc. One of the nice things about Bokeh is that unlike d3, plotly or Gadfly it uses canvas not SVG for it's plots which makes it way faster. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 18:00, Stefan Karpinski ste...@karpinski.org wrote: Bokeh and Bokeh.jl are both very cool – thanks so much for all the work on the package! There seem to still be visualization tasks that have scale and performance requirements such that HTML and JavaScript don't cut it. Web technologies are also generally not up to the task of producing publication-quality graphics, e.g. for research publications. The gaps are probably both diminishing, but I don't think we're quite there yet. On Mon, Feb 23, 2015 at 12:38 PM, Samuel Colvin samcol...@gmail.com wrote: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
Re: [julia-users] Bokeh.jl update released: call for feedback
Humm, gadfly does seem very slow even on subsequent calls, perhaps plot is generating the SVG even though it's not used? julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 37.313627903 seconds (2044604824 bytes allocated, 3.81% gc time) julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 21.228884246 seconds (1128013088 bytes allocated, 3.59% gc time) julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 21.632743948 seconds (1128006012 bytes allocated, 6.86% gc time) julia import Bokeh julia Bokeh.autoopen(true) julia @time Bokeh.plot(x, y) elapsed time: 1.815997064 seconds (125026480 bytes allocated, 4.95% gc time) Plot(Bokeh Plot with 1 datacolumns) julia @time Bokeh.plot(x, y) elapsed time: 0.003634852 seconds (24107784 bytes allocated) Plot(Bokeh Plot with 1 datacolumns) julia versioninfo() Julia Version 0.3.6 Commit a05f87b* (2015-01-08 22:33 UTC) Platform Info: System: Linux (x86_64-linux-gnu) CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz WORD_SIZE: 64 BLAS: libopenblas (NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY Sandybridge) LAPACK: liblapack.so.3 LIBM: libopenlibm LLVM: libLLVM-3.3 -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 18:35, Stefan Karpinski ste...@karpinski.org wrote: Yes, that 33 seconds for the first Gadfly plot is all code generation – the second time you do it, it certainly doesn't take 33 seconds. On Mon, Feb 23, 2015 at 1:34 PM, Tim Holy tim.h...@gmail.com wrote: Do those timings include compilation? It's not really meaningful on the first run. For reference: on my laptop, Winston (on the second run): julia @time (p = plot(x,y); display(p)) elapsed time: 0.256627468 seconds (16 MB allocated, 1.77% gc time in 1 pauses with 0 full sweep) Even this is slow by comparison to where I think we want to be. --Tim On Monday, February 23, 2015 06:27:24 PM Samuel Colvin wrote: You're probably right about research publications, I guess plots these don't need to be interactive which makes things easier from a cross platform perspective. Performance wise I'm not sure you're right, with Julia 0.3.6 and latest packages: julia using Gadfly julia x=1:100 1:100 julia y=sqrt(x); julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 33.860814218 seconds (2043746808 bytes allocated, 3.83% gc time) julia import Bokeh julia Bokeh.autoopen(true) true julia @time Bokeh.plot(x, y) elapsed time: 1.557460583 seconds (125617712 bytes allocated) Plot(Bokeh Plot with 1 datacolumns) Timing on my phone, the Bokeh plot had opened in chrome in 6 seconds. It was a little slow but still fine to zoom/pan etc. One of the nice things about Bokeh is that unlike d3, plotly or Gadfly it uses canvas not SVG for it's plots which makes it way faster. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 18:00, Stefan Karpinski ste...@karpinski.org wrote: Bokeh and Bokeh.jl are both very cool – thanks so much for all the work on the package! There seem to still be visualization tasks that have scale and performance requirements such that HTML and JavaScript don't cut it. Web technologies are also generally not up to the task of producing publication-quality graphics, e.g. for research publications. The gaps are probably both diminishing, but I don't think we're quite there yet. On Mon, Feb 23, 2015 at 12:38 PM, Samuel Colvin samcol...@gmail.com wrote: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
Re: [julia-users] What was allp function and what happened to it?
It was pointed out that allp could just be a method of all – so just delete
the p.
On Mon, Feb 23, 2015 at 12:21 PM, Benjamin Turk
vehbi.esref.bayrak...@gmail.com wrote:
I have been looking at the following code snippet from the julia-dev forum:
valuetypeof(::()) = ()
valuetypeof{T}(::(T,)) = T
function valuetypeof(x::Tuple)
t = typeof(x[1])
@assert allp(y-typeof(y)==t, x)
t
end
I would like to know what allp is and what happened to it?
Thanks
[julia-users] Re: World of Julia
On Sunday, February 22, 2015 at 5:50:09 PM UTC-6, Jiahao Chen wrote: World of Julia is now updated in time for the 2015 Oscars. 336 contributors to JuliaLang/julia 545 packages 695 devs total IJulia notebook: https://github.com/jiahao/ijulia-notebooks/blob/master/2014-06-30-world-of-julia.ipynb Nbviewer link: http://nbviewer.ipython.org/urls/raw.github.com/jiahao/ijulia-notebooks/master/2014-06-30-world-of-julia.ipynb A small suggestion: it may be more insightful if you remove merge commits; I would say I'm definitely overcounted in the current results.
Re: [julia-users] Bokeh.jl update released: call for feedback
Yes, that 33 seconds for the first Gadfly plot is all code generation – the second time you do it, it certainly doesn't take 33 seconds. On Mon, Feb 23, 2015 at 1:34 PM, Tim Holy tim.h...@gmail.com wrote: Do those timings include compilation? It's not really meaningful on the first run. For reference: on my laptop, Winston (on the second run): julia @time (p = plot(x,y); display(p)) elapsed time: 0.256627468 seconds (16 MB allocated, 1.77% gc time in 1 pauses with 0 full sweep) Even this is slow by comparison to where I think we want to be. --Tim On Monday, February 23, 2015 06:27:24 PM Samuel Colvin wrote: You're probably right about research publications, I guess plots these don't need to be interactive which makes things easier from a cross platform perspective. Performance wise I'm not sure you're right, with Julia 0.3.6 and latest packages: julia using Gadfly julia x=1:100 1:100 julia y=sqrt(x); julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 33.860814218 seconds (2043746808 bytes allocated, 3.83% gc time) julia import Bokeh julia Bokeh.autoopen(true) true julia @time Bokeh.plot(x, y) elapsed time: 1.557460583 seconds (125617712 bytes allocated) Plot(Bokeh Plot with 1 datacolumns) Timing on my phone, the Bokeh plot had opened in chrome in 6 seconds. It was a little slow but still fine to zoom/pan etc. One of the nice things about Bokeh is that unlike d3, plotly or Gadfly it uses canvas not SVG for it's plots which makes it way faster. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 18:00, Stefan Karpinski ste...@karpinski.org wrote: Bokeh and Bokeh.jl are both very cool – thanks so much for all the work on the package! There seem to still be visualization tasks that have scale and performance requirements such that HTML and JavaScript don't cut it. Web technologies are also generally not up to the task of producing publication-quality graphics, e.g. for research publications. The gaps are probably both diminishing, but I don't think we're quite there yet. On Mon, Feb 23, 2015 at 12:38 PM, Samuel Colvin samcol...@gmail.com wrote: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
Re: [julia-users] Re: World of Julia
Fair enough, but that would mean actually parsing the commit history :) Thanks, Jiahao Chen Staff Research Scientist MIT Computer Science and Artificial Intelligence Laboratory On Mon, Feb 23, 2015 at 1:08 PM, Patrick O'Leary patrick.ole...@gmail.com wrote: On Sunday, February 22, 2015 at 5:50:09 PM UTC-6, Jiahao Chen wrote: World of Julia is now updated in time for the 2015 Oscars. 336 contributors to JuliaLang/julia 545 packages 695 devs total IJulia notebook: https://github.com/jiahao/ijulia-notebooks/blob/ master/2014-06-30-world-of-julia.ipynb Nbviewer link: http://nbviewer.ipython.org/urls/raw.github.com/ jiahao/ijulia-notebooks/master/2014-06-30-world-of-julia.ipynb A small suggestion: it may be more insightful if you remove merge commits; I would say I'm definitely overcounted in the current results.
Re: [julia-users] Bokeh.jl update released: call for feedback
Answers inline below. But generally I'm not suggesting that Bokeh.jl is a complete or a viable all round option yet: I was just making a general point (and saying someone mildly antagonistic to kick off some debate, sorry). On Monday, 23 February 2015 18:17:24 UTC, Tim Holy wrote: This looks interesting, I should definitely give this a whirl sometime. On Monday, February 23, 2015 09:38:45 AM Samuel Colvin wrote: I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work? I'm pretty ignorant about HTML, so pardon some stupid questions/observations: - I have the impression that Web3D seems to be a fairly limited subset of what OpenGL offers I think you're probably right about WebGL, Bokeh doesn't have any support for 3D plotting yet, although I read somewhere (can't find it now) that they're looking at all the options and will work on 3D when they decide on a good approach - maybe that says a lot in itself. For some examples of 3D plotting in the browser plotly have some pretty cool demos: https://plot.ly/python/3d-plots-tutorial/ - I'm worried about the overhead of plotting huge datasets. Because I'm too lazy to check for myself :-), can you describe how do you pass data to Bokeh? Can you do it without making a copy? (I.e., in the RAM of your machine, there is only one copy of the data, ever, and both the julia side and the HTML side use the same chunk of RAM.) If so, this may not be so bad. If conversely you have to convert to ASCII or something, that's a dealbreaker. I'm not sure it's a dealbreaker but all Bokeh.jl does is write an HTML file with a reference to bokeh.js and insert the plot data in a big clump of JSON. It then just prompts your default browser to open that file. I know it sounds inefficient, but in the end there's a finite limit on how much data you should ever have to pass to a plot - enough data to fill the screen. If your passing GB (or even MB normally) of data to the plot there's a lot of down sampling you can do before it will be noticeable in the plot. That down sampling should be done in Julia, but obviously that's not started yet. The timing above is just the time taken to generate and write the HTML file, that's why I included (in my first message) a manual measurement of how long it take to display the data in chrome - about 6 seconds. - Can you point me to how one writes callback functions? (User clicks on a single point on a plot, I want it to call back to my *julia* code so I can do some more detailed analysis/visualization on the data corresponding to that particular point. I don't want to have to write that code in javascript.) I imagine this is possible (probably some kind of socket communication?), but I'd love to have someone point me to how it's done. There may be circumstances where one wants fast callbacks, although for interactive usage I expect that callback time will be dwarfed by the rendering time. Bokeh can do this but not Bokeh.jl yet, It should just require sockets and will call a function in Julia so no javascript required. These are the things that make me worry about relying on HTML/javascript. I also recognize that path holds some attractions. Yes the ease of installation, publishing and transferring HTML plots is pretty cool. Do you know of another plotting library which has a self contained export format for interactive plots which virtually every computer in the world has a viewer for? --Tim
[julia-users] Re: Tensor-product function for multidimensional arrays (2 dims)
On Sunday, February 22, 2015 at 3:32:34 AM UTC-5, Viral Shah wrote: Best to file an issue. See https://github.com/JuliaLang/julia/issues/3250
Re: [julia-users] Bokeh.jl update released: call for feedback
This looks interesting, I should definitely give this a whirl sometime. On Monday, February 23, 2015 09:38:45 AM Samuel Colvin wrote: I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work? I'm pretty ignorant about HTML, so pardon some stupid questions/observations: - I have the impression that Web3D seems to be a fairly limited subset of what OpenGL offers - I'm worried about the overhead of plotting huge datasets. Because I'm too lazy to check for myself :-), can you describe how do you pass data to Bokeh? Can you do it without making a copy? (I.e., in the RAM of your machine, there is only one copy of the data, ever, and both the julia side and the HTML side use the same chunk of RAM.) If so, this may not be so bad. If conversely you have to convert to ASCII or something, that's a dealbreaker. - Can you point me to how one writes callback functions? (User clicks on a single point on a plot, I want it to call back to my *julia* code so I can do some more detailed analysis/visualization on the data corresponding to that particular point. I don't want to have to write that code in javascript.) I imagine this is possible (probably some kind of socket communication?), but I'd love to have someone point me to how it's done. There may be circumstances where one wants fast callbacks, although for interactive usage I expect that callback time will be dwarfed by the rendering time. These are the things that make me worry about relying on HTML/javascript. I also recognize that path holds some attractions. --Tim
Re: [julia-users] Bokeh.jl update released: call for feedback
Do those timings include compilation? It's not really meaningful on the first run. For reference: on my laptop, Winston (on the second run): julia @time (p = plot(x,y); display(p)) elapsed time: 0.256627468 seconds (16 MB allocated, 1.77% gc time in 1 pauses with 0 full sweep) Even this is slow by comparison to where I think we want to be. --Tim On Monday, February 23, 2015 06:27:24 PM Samuel Colvin wrote: You're probably right about research publications, I guess plots these don't need to be interactive which makes things easier from a cross platform perspective. Performance wise I'm not sure you're right, with Julia 0.3.6 and latest packages: julia using Gadfly julia x=1:100 1:100 julia y=sqrt(x); julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 33.860814218 seconds (2043746808 bytes allocated, 3.83% gc time) julia import Bokeh julia Bokeh.autoopen(true) true julia @time Bokeh.plot(x, y) elapsed time: 1.557460583 seconds (125617712 bytes allocated) Plot(Bokeh Plot with 1 datacolumns) Timing on my phone, the Bokeh plot had opened in chrome in 6 seconds. It was a little slow but still fine to zoom/pan etc. One of the nice things about Bokeh is that unlike d3, plotly or Gadfly it uses canvas not SVG for it's plots which makes it way faster. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 18:00, Stefan Karpinski ste...@karpinski.org wrote: Bokeh and Bokeh.jl are both very cool – thanks so much for all the work on the package! There seem to still be visualization tasks that have scale and performance requirements such that HTML and JavaScript don't cut it. Web technologies are also generally not up to the task of producing publication-quality graphics, e.g. for research publications. The gaps are probably both diminishing, but I don't think we're quite there yet. On Mon, Feb 23, 2015 at 12:38 PM, Samuel Colvin samcol...@gmail.com wrote: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
Re: [julia-users] Bokeh.jl update released: call for feedback
Ouch, it looks like it does even after code generation. I need to look into that. I never noticed because I always use hexbin for these sorts of plots, which also could be faster but is still only 2.5 seconds for this example. On Monday, February 23, 2015 at 10:36:28 AM UTC-8, Stefan Karpinski wrote: Yes, that 33 seconds for the first Gadfly plot is all code generation – the second time you do it, it certainly doesn't take 33 seconds. On Mon, Feb 23, 2015 at 1:34 PM, Tim Holy tim@gmail.com javascript: wrote: Do those timings include compilation? It's not really meaningful on the first run. For reference: on my laptop, Winston (on the second run): julia @time (p = plot(x,y); display(p)) elapsed time: 0.256627468 seconds (16 MB allocated, 1.77% gc time in 1 pauses with 0 full sweep) Even this is slow by comparison to where I think we want to be. --Tim On Monday, February 23, 2015 06:27:24 PM Samuel Colvin wrote: You're probably right about research publications, I guess plots these don't need to be interactive which makes things easier from a cross platform perspective. Performance wise I'm not sure you're right, with Julia 0.3.6 and latest packages: julia using Gadfly julia x=1:100 1:100 julia y=sqrt(x); julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 33.860814218 seconds (2043746808 bytes allocated, 3.83% gc time) julia import Bokeh julia Bokeh.autoopen(true) true julia @time Bokeh.plot(x, y) elapsed time: 1.557460583 seconds (125617712 bytes allocated) Plot(Bokeh Plot with 1 datacolumns) Timing on my phone, the Bokeh plot had opened in chrome in 6 seconds. It was a little slow but still fine to zoom/pan etc. One of the nice things about Bokeh is that unlike d3, plotly or Gadfly it uses canvas not SVG for it's plots which makes it way faster. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 18:00, Stefan Karpinski ste...@karpinski.org javascript: wrote: Bokeh and Bokeh.jl are both very cool – thanks so much for all the work on the package! There seem to still be visualization tasks that have scale and performance requirements such that HTML and JavaScript don't cut it. Web technologies are also generally not up to the task of producing publication-quality graphics, e.g. for research publications. The gaps are probably both diminishing, but I don't think we're quite there yet. On Mon, Feb 23, 2015 at 12:38 PM, Samuel Colvin samc...@gmail.com javascript: wrote: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
[julia-users] Julia users @ APS March Meeting?
The annual March Meeting of the American Physical Society is next week in San Antonio, and I am wondering if any Julia users would be interested in getting together there to chat for a bit. I already know of 4-5 Julia users attending, but surely there will be others I don't yet know of. Let me know if you'd be interested in joining us. Cheers, - Jim
Re: [julia-users] Bokeh.jl update released: call for feedback
Bokeh and Bokeh.jl are both very cool – thanks so much for all the work on the package! There seem to still be visualization tasks that have scale and performance requirements such that HTML and JavaScript don't cut it. Web technologies are also generally not up to the task of producing publication-quality graphics, e.g. for research publications. The gaps are probably both diminishing, but I don't think we're quite there yet. On Mon, Feb 23, 2015 at 12:38 PM, Samuel Colvin samcol...@gmail.com wrote: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
Re: [julia-users] Re: Suppress printed output from PyPlot
On Monday, February 23, 2015 at 6:52:25 AM UTC-5, gdmsl wrote: thank you for the tips but the second method return an error: Oh, right, withfig currently only works with IJulia (which has a display queue and an undisplay function to remove things from the queue).It won't work with the REPL. So, probably you need the other solution: implement and push a (trivial) custom display backend then.
Re: [julia-users] Re: Large memory allocation and GC time in fractal renderer
On Sunday, February 22, 2015 at 10:06:44 AM UTC-5, DumpsterDoofus wrote: Nope, I was just manually typing them in, but thanks for pointing that out. I tried it by calling `import Base.Math.@horner` and then implemented it like this: f = @horner(x, a0, a1, a2, a3, a4) fP = @horner(x, a1, 2*a2, 3*a3, 4*a4) fPP = @horner(x, 2*a2, 6*a3, 12*a4) Performance was the same as manually entering the Horner forms by hand (ie, much better than the non-Horner form). Good to know! Better to just use @evalpoly(x, a0, a1, ...). This has the advantage of being documented and exported already.It inlines to @horner for real x and to a different algorithm for complex x (where you can do better than horner).
Re: [julia-users] Bokeh.jl update released: call for feedback
You're probably right about research publications, I guess plots these don't need to be interactive which makes things easier from a cross platform perspective. Performance wise I'm not sure you're right, with Julia 0.3.6 and latest packages: julia using Gadfly julia x=1:100 1:100 julia y=sqrt(x); julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 33.860814218 seconds (2043746808 bytes allocated, 3.83% gc time) julia import Bokeh julia Bokeh.autoopen(true) true julia @time Bokeh.plot(x, y) elapsed time: 1.557460583 seconds (125617712 bytes allocated) Plot(Bokeh Plot with 1 datacolumns) Timing on my phone, the Bokeh plot had opened in chrome in 6 seconds. It was a little slow but still fine to zoom/pan etc. One of the nice things about Bokeh is that unlike d3, plotly or Gadfly it uses canvas not SVG for it's plots which makes it way faster. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 18:00, Stefan Karpinski ste...@karpinski.org wrote: Bokeh and Bokeh.jl are both very cool – thanks so much for all the work on the package! There seem to still be visualization tasks that have scale and performance requirements such that HTML and JavaScript don't cut it. Web technologies are also generally not up to the task of producing publication-quality graphics, e.g. for research publications. The gaps are probably both diminishing, but I don't think we're quite there yet. On Mon, Feb 23, 2015 at 12:38 PM, Samuel Colvin samcol...@gmail.com wrote: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
Re: [julia-users] Bokeh.jl update released: call for feedback
Gadfly is definitely not efficient. Your 2nd timing on Bokeh seems either extremely encouraging or a bit suspicious. For reference, with Winston I get (after warmup) julia @time plot(x,y) elapsed time: 0.003610142 seconds (278 kB allocated) julia @time display(plot(x,y)) elapsed time: 0.262181796 seconds (16 MB allocated) The first one just creates the task (essentially, constructing the scene graph), and the rendering happens after the `@time` macro ends. The second version includes the time to render it. So, does your ~4ms timing include rendering, or is it just the time needed to hand the task off to Bokeh? --Tim On Monday, February 23, 2015 06:43:49 PM Samuel Colvin wrote: Humm, gadfly does seem very slow even on subsequent calls, perhaps plot is generating the SVG even though it's not used? julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 37.313627903 seconds (2044604824 bytes allocated, 3.81% gc time) julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 21.228884246 seconds (1128013088 bytes allocated, 3.59% gc time) julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 21.632743948 seconds (1128006012 bytes allocated, 6.86% gc time) julia import Bokeh julia Bokeh.autoopen(true) julia @time Bokeh.plot(x, y) elapsed time: 1.815997064 seconds (125026480 bytes allocated, 4.95% gc time) Plot(Bokeh Plot with 1 datacolumns) julia @time Bokeh.plot(x, y) elapsed time: 0.003634852 seconds (24107784 bytes allocated) Plot(Bokeh Plot with 1 datacolumns) julia versioninfo() Julia Version 0.3.6 Commit a05f87b* (2015-01-08 22:33 UTC) Platform Info: System: Linux (x86_64-linux-gnu) CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz WORD_SIZE: 64 BLAS: libopenblas (NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY Sandybridge) LAPACK: liblapack.so.3 LIBM: libopenlibm LLVM: libLLVM-3.3 -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 18:35, Stefan Karpinski ste...@karpinski.org wrote: Yes, that 33 seconds for the first Gadfly plot is all code generation – the second time you do it, it certainly doesn't take 33 seconds. On Mon, Feb 23, 2015 at 1:34 PM, Tim Holy tim.h...@gmail.com wrote: Do those timings include compilation? It's not really meaningful on the first run. For reference: on my laptop, Winston (on the second run): julia @time (p = plot(x,y); display(p)) elapsed time: 0.256627468 seconds (16 MB allocated, 1.77% gc time in 1 pauses with 0 full sweep) Even this is slow by comparison to where I think we want to be. --Tim On Monday, February 23, 2015 06:27:24 PM Samuel Colvin wrote: You're probably right about research publications, I guess plots these don't need to be interactive which makes things easier from a cross platform perspective. Performance wise I'm not sure you're right, with Julia 0.3.6 and latest packages: julia using Gadfly julia x=1:100 1:100 julia y=sqrt(x); julia @time draw(PNG(test.png, 6inch, 3inch), plot(x=x, y=y)) elapsed time: 33.860814218 seconds (2043746808 bytes allocated, 3.83% gc time) julia import Bokeh julia Bokeh.autoopen(true) true julia @time Bokeh.plot(x, y) elapsed time: 1.557460583 seconds (125617712 bytes allocated) Plot(Bokeh Plot with 1 datacolumns) Timing on my phone, the Bokeh plot had opened in chrome in 6 seconds. It was a little slow but still fine to zoom/pan etc. One of the nice things about Bokeh is that unlike d3, plotly or Gadfly it uses canvas not SVG for it's plots which makes it way faster. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 18:00, Stefan Karpinski ste...@karpinski.org wrote: Bokeh and Bokeh.jl are both very cool – thanks so much for all the work on the package! There seem to still be visualization tasks that have scale and performance requirements such that HTML and JavaScript don't cut it. Web technologies are also generally not up to the task of producing publication-quality graphics, e.g. for research publications. The gaps are probably both diminishing, but I don't think we're quite there yet. On Mon, Feb 23, 2015 at 12:38 PM, Samuel Colvin samcol...@gmail.com wrote: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples
Re: [julia-users] Bokeh.jl update released: call for feedback
On Monday, February 23, 2015 11:19:17 AM Samuel Colvin wrote: Answers inline below. But generally I'm not suggesting that Bokeh.jl is a complete or a viable all round option yet: I was just making a general point (and saying someone mildly antagonistic to kick off some debate, sorry). Oh, I appreciate your interaction on this. While we've made a lot of progress, there's still room for improvement in our graphics subspace, and not very much unity. (I need to check out Mike's Blink.jl, too.) Perhaps at the next JuliaCon graphics can be a big topic of discussion and perhaps hacking. I think you're probably right about WebGL, Bokeh doesn't have any support for 3D plotting yet, although I read somewhere (can't find it now) that they're looking at all the options and will work on 3D when they decide on a good approach - maybe that says a lot in itself. For some examples of 3D plotting in the browser plotly have some pretty cool demos: https://plot.ly/python/3d-plots-tutorial/ Those are indeed nice, but for some insight into about what's actually possible...check out this amazing video by Simon Danish (using his GLPlot.jl collection of packages): https://www.youtube.com/watch?v=nJdGHVY2b2g It's my understanding that this video was just capturing what was going on inside a window on his desktop, *in real time*. That would be pretty hard to achieve by saving data to files and popping up browser windows... --Tim - I'm worried about the overhead of plotting huge datasets. Because I'm too lazy to check for myself :-), can you describe how do you pass data to Bokeh? Can you do it without making a copy? (I.e., in the RAM of your machine, there is only one copy of the data, ever, and both the julia side and the HTML side use the same chunk of RAM.) If so, this may not be so bad. If conversely you have to convert to ASCII or something, that's a dealbreaker. I'm not sure it's a dealbreaker but all Bokeh.jl does is write an HTML file with a reference to bokeh.js and insert the plot data in a big clump of JSON. It then just prompts your default browser to open that file. I know it sounds inefficient, but in the end there's a finite limit on how much data you should ever have to pass to a plot - enough data to fill the screen. If your passing GB (or even MB normally) of data to the plot there's a lot of down sampling you can do before it will be noticeable in the plot. That down sampling should be done in Julia, but obviously that's not started yet. The timing above is just the time taken to generate and write the HTML file, that's why I included (in my first message) a manual measurement of how long it take to display the data in chrome - about 6 seconds. - Can you point me to how one writes callback functions? (User clicks on a single point on a plot, I want it to call back to my *julia* code so I can do some more detailed analysis/visualization on the data corresponding to that particular point. I don't want to have to write that code in javascript.) I imagine this is possible (probably some kind of socket communication?), but I'd love to have someone point me to how it's done. There may be circumstances where one wants fast callbacks, although for interactive usage I expect that callback time will be dwarfed by the rendering time. Bokeh can do this but not Bokeh.jl yet, It should just require sockets and will call a function in Julia so no javascript required. These are the things that make me worry about relying on HTML/javascript. I also recognize that path holds some attractions. Yes the ease of installation, publishing and transferring HTML plots is pretty cool. Do you know of another plotting library which has a self contained export format for interactive plots which virtually every computer in the world has a viewer for? --Tim
[julia-users] Constructing matrices
I'm writing some code which takes 2-dimensional Julia arrays and converts them to an external matrix type. For example Mat([1 2; 3 4; 5 6]) creates a 3x2 matrix. But I cannot figure out the syntax for nx1 arrays in Julia. Note that I need to be able to construct nx1 and 1xn matrices. I assumed the syntax would be [1 2 3] for 1x3 and [1; 2; 3] for 3x1. But this doesn't seem to work, currently. It looks like the latter is a synonym for [1, 2, 3], which makes no sense at all to me. Also, what's with julia transpose(transpose([1; 2; 3])) == [1; 2; 3] false ?
[julia-users] Re: Constructing matrices
Yeah, I have never thought of that, but it seems kind of confusing.
You can do
julia hvcat(1, 1, 2, 3)
3x1 Array{Int64,2}:
1
2
3
julia hvcat(1, 1, 2, 3)'' == hvcat(1, 1, 2, 3)
true
Greetings.
Re: [julia-users] Re: World of Julia
Strange that GitHub excludes merge commits on their site, but not in their API. mandag 23. februar 2015 19.57.19 UTC+1 skrev Jiahao Chen følgende: Fair enough, but that would mean actually parsing the commit history :) Thanks, Jiahao Chen Staff Research Scientist MIT Computer Science and Artificial Intelligence Laboratory On Mon, Feb 23, 2015 at 1:08 PM, Patrick O'Leary patrick...@gmail.com javascript: wrote: On Sunday, February 22, 2015 at 5:50:09 PM UTC-6, Jiahao Chen wrote: World of Julia is now updated in time for the 2015 Oscars. 336 contributors to JuliaLang/julia 545 packages 695 devs total IJulia notebook: https://github.com/jiahao/ijulia-notebooks/blob/ master/2014-06-30-world-of-julia.ipynb Nbviewer link: http://nbviewer.ipython.org/urls/raw.github.com/ jiahao/ijulia-notebooks/master/2014-06-30-world-of-julia.ipynb A small suggestion: it may be more insightful if you remove merge commits; I would say I'm definitely overcounted in the current results.
Re: [julia-users] Bokeh.jl update released: call for feedback
Technologies like OpenGL have consumed masses of time and money as well :-) Having worked on 3D visualization of large datasets (512^3) I am pretty sure that one has to utilize the graphics hardware in order to obtain full speed. But it seems it all is about use cases. Exporting to html has the big advantage that publishing online becomes easy (preserving interactivity). For publication ready plots I love to use PyPlot as it gives me a lot of control over my plot. Since PyPlot is slow I favor a combination of Gtk and Winston to do interactive applications with plots Cheers, Tobi Am Montag, 23. Februar 2015 21:47:25 UTC+1 schrieb Samuel Colvin: Thanks for being accepting of my provocation. Some emphasis on graphics makes sense, I just think it would be a mistake to spend too long wrestling with c libraries when projects like threejs show how much can be done with just javascript. Technologies like chrome, v8, html5 have consumed masses of time and money, it makes sense to piggy back of as much of it as possible. The saving file -- opening file is definitely just the first step, websockets should allow real time data transfer in both directions. HTML5 can definitely handle the graphs, take a look at these examples: http://dlmf.nist.gov/21.4.F1h.webgl So I think there's no reason why the above example shouldn't be possible with nothing more than the Julia standard library, WebSockets.jl, reference to a JavaScript file and a browser. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 20:16, Tim Holy tim@gmail.com javascript: wrote: On Monday, February 23, 2015 11:19:17 AM Samuel Colvin wrote: Answers inline below. But generally I'm not suggesting that Bokeh.jl is a complete or a viable all round option yet: I was just making a general point (and saying someone mildly antagonistic to kick off some debate, sorry). Oh, I appreciate your interaction on this. While we've made a lot of progress, there's still room for improvement in our graphics subspace, and not very much unity. (I need to check out Mike's Blink.jl, too.) Perhaps at the next JuliaCon graphics can be a big topic of discussion and perhaps hacking. I think you're probably right about WebGL, Bokeh doesn't have any support for 3D plotting yet, although I read somewhere (can't find it now) that they're looking at all the options and will work on 3D when they decide on a good approach - maybe that says a lot in itself. For some examples of 3D plotting in the browser plotly have some pretty cool demos: https://plot.ly/python/3d-plots-tutorial/ Those are indeed nice, but for some insight into about what's actually possible...check out this amazing video by Simon Danish (using his GLPlot.jl collection of packages): https://www.youtube.com/watch?v=nJdGHVY2b2g It's my understanding that this video was just capturing what was going on inside a window on his desktop, *in real time*. That would be pretty hard to achieve by saving data to files and popping up browser windows... --Tim - I'm worried about the overhead of plotting huge datasets. Because I'm too lazy to check for myself :-), can you describe how do you pass data to Bokeh? Can you do it without making a copy? (I.e., in the RAM of your machine, there is only one copy of the data, ever, and both the julia side and the HTML side use the same chunk of RAM.) If so, this may not be so bad. If conversely you have to convert to ASCII or something, that's a dealbreaker. I'm not sure it's a dealbreaker but all Bokeh.jl does is write an HTML file with a reference to bokeh.js and insert the plot data in a big clump of JSON. It then just prompts your default browser to open that file. I know it sounds inefficient, but in the end there's a finite limit on how much data you should ever have to pass to a plot - enough data to fill the screen. If your passing GB (or even MB normally) of data to the plot there's a lot of down sampling you can do before it will be noticeable in the plot. That down sampling should be done in Julia, but obviously that's not started yet. The timing above is just the time taken to generate and write the HTML file, that's why I included (in my first message) a manual measurement of how long it take to display the data in chrome - about 6 seconds. - Can you point me to how one writes callback functions? (User clicks on a single point on a plot, I want it to call back to my *julia* code so I can do some more detailed analysis/visualization on the data corresponding to that particular point. I don't want to have to write that code in javascript.) I imagine this is possible (probably some kind of socket communication?), but I'd love to have someone point me to how it's done. There may be circumstances where one wants fast callbacks,
[julia-users] Re: Bokeh.jl update released: call for feedback
*To qualify what I mean by easier, I guess I mean: Easier in most cases for most developers, c and c++ are all very well, but the popularity and ease of development of JavaScript can't be argued with.* That's exactly why I hope that Julia will replace javascript, also for graphics. Like this we have both scientific and graphics algorithms in the same language, which would be huge! Concerning WebGL, I believe that WebGL itself is for the most things not that much slower. It's just more restrictive and doesn't have some options to really speed things up (complicated topic really). So simple OpenGL will have very comparable performance to WebGL. Also the whole stack around it makes it difficult, to interactively change and upload huge amounts of values from within julia... Well, all can surely be done with a lot of magic, but I think you end up with the same amount of work, like you would end up with when you cleanly implement it with Julia. While the latter leaves you with an incredible base to do even bigger things (Like having game engines and physics engines, OpenCL/CUDA and the like, which would be a great benefit for the scientific community). Am Montag, 23. Februar 2015 18:38:45 UTC+1 schrieb Samuel Colvin: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
Re: [julia-users] Re: Bokeh.jl update released: call for feedback
I had no idea until today about your effort to use Julia for graphics. It's really exciting. If graphics is becoming one of Julia's core purposes then work on graphics at a low level isn't wasted. It sounds like on most of this we're actually agreeing. I'm as keen as anyone for JavaScript to be a stop gap before something better, just that right now it's the best stop gap. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 22:41, Simon Danisch sdani...@gmail.com wrote: *To qualify what I mean by easier, I guess I mean: Easier in most cases for most developers, c and c++ are all very well, but the popularity and ease of development of JavaScript can't be argued with.* That's exactly why I hope that Julia will replace javascript, also for graphics. Like this we have both scientific and graphics algorithms in the same language, which would be huge! Concerning WebGL, I believe that WebGL itself is for the most things not that much slower. It's just more restrictive and doesn't have some options to really speed things up (complicated topic really). So simple OpenGL will have very comparable performance to WebGL. Also the whole stack around it makes it difficult, to interactively change and upload huge amounts of values from within julia... Well, all can surely be done with a lot of magic, but I think you end up with the same amount of work, like you would end up with when you cleanly implement it with Julia. While the latter leaves you with an incredible base to do even bigger things (Like having game engines and physics engines, OpenCL/CUDA and the like, which would be a great benefit for the scientific community). Am Montag, 23. Februar 2015 18:38:45 UTC+1 schrieb Samuel Colvin: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
Re: [julia-users] Re: Bokeh.jl update released: call for feedback
Great to hear =) Well it's a rocky road, to be honest... But I think it'll pay off double in the end! I'm a little afraid of Julia's garbage collector, but besides that Julia seems to be very fit for high performance graphics. 2015-02-23 23:48 GMT+01:00 Samuel Colvin s...@muelcolvin.com: I had no idea until today about your effort to use Julia for graphics. It's really exciting. If graphics is becoming one of Julia's core purposes then work on graphics at a low level isn't wasted. It sounds like on most of this we're actually agreeing. I'm as keen as anyone for JavaScript to be a stop gap before something better, just that right now it's the best stop gap. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 22:41, Simon Danisch sdani...@gmail.com wrote: *To qualify what I mean by easier, I guess I mean: Easier in most cases for most developers, c and c++ are all very well, but the popularity and ease of development of JavaScript can't be argued with.* That's exactly why I hope that Julia will replace javascript, also for graphics. Like this we have both scientific and graphics algorithms in the same language, which would be huge! Concerning WebGL, I believe that WebGL itself is for the most things not that much slower. It's just more restrictive and doesn't have some options to really speed things up (complicated topic really). So simple OpenGL will have very comparable performance to WebGL. Also the whole stack around it makes it difficult, to interactively change and upload huge amounts of values from within julia... Well, all can surely be done with a lot of magic, but I think you end up with the same amount of work, like you would end up with when you cleanly implement it with Julia. While the latter leaves you with an incredible base to do even bigger things (Like having game engines and physics engines, OpenCL/CUDA and the like, which would be a great benefit for the scientific community). Am Montag, 23. Februar 2015 18:38:45 UTC+1 schrieb Samuel Colvin: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
Re: [julia-users] Bokeh.jl update released: call for feedback
You're quite right about the cost of OpenGL, my bad. WebGL is still using graphics hardware, and dealing happily with big datasets, take a look at: http://carvisualizer.plus360degrees.com/threejs/ - that's definitely using my graphics card fairly heavily. I guess my point was (not that I explained it clearly at all) that web technologies are built on top of libraries like OpenGL, they still use graphics hardware but make accessing it way easier. To qualify what I mean by easier, I guess I mean: Easier in most cases for most developers, c and c++ are all very well, but the popularity and ease of development of JavaScript can't be argued with. In my experience the easier the tools are to use, the better the end product is (all other things being equal). With something like graphics which isn't the core purpose of Julia we should use all the tools available to have the strongest offering with the resources available. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 21:53, Tobias Knopp tobias.kn...@googlemail.com wrote: Technologies like OpenGL have consumed masses of time and money as well :-) Having worked on 3D visualization of large datasets (512^3) I am pretty sure that one has to utilize the graphics hardware in order to obtain full speed. But it seems it all is about use cases. Exporting to html has the big advantage that publishing online becomes easy (preserving interactivity). For publication ready plots I love to use PyPlot as it gives me a lot of control over my plot. Since PyPlot is slow I favor a combination of Gtk and Winston to do interactive applications with plots Cheers, Tobi Am Montag, 23. Februar 2015 21:47:25 UTC+1 schrieb Samuel Colvin: Thanks for being accepting of my provocation. Some emphasis on graphics makes sense, I just think it would be a mistake to spend too long wrestling with c libraries when projects like threejs show how much can be done with just javascript. Technologies like chrome, v8, html5 have consumed masses of time and money, it makes sense to piggy back of as much of it as possible. The saving file -- opening file is definitely just the first step, websockets should allow real time data transfer in both directions. HTML5 can definitely handle the graphs, take a look at these examples: http://dlmf.nist.gov/21.4.F1h.webgl So I think there's no reason why the above example shouldn't be possible with nothing more than the Julia standard library, WebSockets.jl, reference to a JavaScript file and a browser. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 20:16, Tim Holy tim@gmail.com wrote: On Monday, February 23, 2015 11:19:17 AM Samuel Colvin wrote: Answers inline below. But generally I'm not suggesting that Bokeh.jl is a complete or a viable all round option yet: I was just making a general point (and saying someone mildly antagonistic to kick off some debate, sorry). Oh, I appreciate your interaction on this. While we've made a lot of progress, there's still room for improvement in our graphics subspace, and not very much unity. (I need to check out Mike's Blink.jl, too.) Perhaps at the next JuliaCon graphics can be a big topic of discussion and perhaps hacking. I think you're probably right about WebGL, Bokeh doesn't have any support for 3D plotting yet, although I read somewhere (can't find it now) that they're looking at all the options and will work on 3D when they decide on a good approach - maybe that says a lot in itself. For some examples of 3D plotting in the browser plotly have some pretty cool demos: https://plot.ly/python/3d-plots-tutorial/ Those are indeed nice, but for some insight into about what's actually possible...check out this amazing video by Simon Danish (using his GLPlot.jl collection of packages): https://www.youtube.com/watch?v=nJdGHVY2b2g It's my understanding that this video was just capturing what was going on inside a window on his desktop, *in real time*. That would be pretty hard to achieve by saving data to files and popping up browser windows... --Tim - I'm worried about the overhead of plotting huge datasets. Because I'm too lazy to check for myself :-), can you describe how do you pass data to Bokeh? Can you do it without making a copy? (I.e., in the RAM of your machine, there is only one copy of the data, ever, and both the julia side and the HTML side use the same chunk of RAM.) If so, this may not be so bad. If conversely you have to convert to ASCII or something, that's a dealbreaker. I'm not sure it's a dealbreaker but all Bokeh.jl does is write an HTML file with a reference to bokeh.js and insert the plot data in a big clump of JSON. It then just prompts your default browser to open that file. I know it sounds inefficient, but in the end there's a finite limit on how much data you should ever have to pass to a plot -
[julia-users] Re: Bokeh.jl update released: call for feedback
I'll be really happy, if everything worked without javascript and html, to be honest. Yeah it's great to use it and gives you quick, awesome looking results, but it's the lazy way out in my view. It's great that you can use Julia in a web browser, but it gets pretty restrictive, as soon as you want to do more serious things. The browser makes much sense, if the packages are really hard to install, but if Julia is easy to install, I don't see a huge difference. (Besides publishing things quickly on websites. But for that an HTML exporter should be sufficient, instead of building the whole graphics stack with web technologies) If you go down the web way, you might find yourself bound to a huge, heterogeneous technology stack, where parts are often slow, written in different languages, are just fast by an incredible amount of work (like in the case of javascript), or are simply closed source. So this thread basically sums up the motivation for my OpenGL efforts. Yes, GLPlot should be pretty fast, at least the rendering itself. Event management and such is not that performant, and I haven't optimized much yet. But it builds upon modern OpenGL, which even without optimizations enables me to render around ~40 mio anti aliased triangles fluently on my onboard HD 4400. Here is a short overview over the state of my projects: GLPlot.jl: pretty much on hold at the moment, as I'm rewriting the whole infrastructure, to have it all use one generic rendering platform and a unified geometry stack. Romeo.jl: on hold as well, pretty much a crude prototype of something, that should become comparable to IJulia. Experimental Features (not all are activated at the moment): Plots via GLPlot, Gadfly and PyPlot can be inlined (best support for GLPlot, obviously, where you can actually click on things and change them). All variables have a default edit and visualize function, which means you can just click on your matrix and see a e.g. surface plot. The edit functions returns a visualization and a signal of that type. With that you get an editable visualization of, e.g. text, colors, or numbers. Editable Representation can be something like a slider or a textfield ;) Everything can be editable really, if it's the vertexes of your 3D mesh, the values of your surface, or the labels of you plot. This is all on hold, as I want to have a unified 2D/3D mesh representation, which relies on FixedSizeArrays, which both isn't in place yet. Also I'm slowly moving forward with an opengl accelerated 2D drawing api, which will be really awesome (possibly a lot faster than other libraries, including Cairo even with its new OpenGL backend, while keeping comparable rendering quality). Additionally, I'm trying to incorporate some of my newer findings into GLAbstraction and slowly have a better abstraction of the OpenGL array types. I'm also slowly moving into the direction of building prototypes for HyperSignals, which can be thought of as an high performance alternative to Reactive, which compiles code just in time for the current situation. It is thought to solve a lot of problems which I currently have in an elegant way. (Like, when can a whole event branch be executed on the GPU, when am I allowed to do multi threading and things like that). Sorry to hijack this thread, but I think it's relevant to this discussion, as it shows what could possibly achieved with native Julia alone. If you get the idea to try out Romeo, don't be disappointed, it's a little funky and might not work at all. I'm currently not wasting any time on it and instead try to put it on a solid base. Best, Simon Am Montag, 23. Februar 2015 18:38:45 UTC+1 schrieb Samuel Colvin: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
[julia-users] Re: Why does my Julia code run so slow?
How does it compare to c by now?
[julia-users] Re: splice! function. Instead of removing a single item, remove a collection of items stored in an array.
corrected_data = deleteat!(x, errors) should be what you're looking for. Alternately, a more functionally pure way to do it is to compute the good indices and then just do corrected_data = x[good_idx], though this will make a copy of those elements of x. On Sunday, February 22, 2015 at 3:14:11 PM UTC-5, Aero_flux wrote: Hello everybody, I might be going about this the wrong way. I have a sequence of data in a 1-D array x. Now I have done some calculations and have a 1-D array of the indexed points in x that erroneous. What I would like to to is remove all the data points in x that uses the saved indices. I figured I would use corrected_data = splice!(x, errors) but of course it won't take arrays. Any hints? Many thanks
[julia-users] Re: Why does my Julia code run so slow?
About 3.5x slower. 在 2015年2月23日星期一 UTC+8下午4:01:16，Simon Danisch写道： How does it compare to c by now?
Re: [julia-users] memory usage of worker processes
`@everywhere gc()` doesn't help. If it's related to unfixed bugs, maybe I should use rmprocs() to kill the worker processes and start them again for temporary use. 在 2015年2月23日星期一 UTC+8下午3:55:27，Amit Murthy写道： There are a bunch of memory related issues w.r.t. distributed computing still pending resolution. I guess an `@everywhere gc()` in between the `remotecall_fetch` calls did not help? I suspect that https://github.com/JuliaLang/julia/issues/6597 is a probable cause of these leaks. On Mon, Feb 23, 2015 at 12:41 PM, Zhixuan Yang jave...@gmail.com javascript: wrote: Hello everyone, If I have a very large array in the main process and I use remotecall() or pmap() to copy the array to worker processes and modify the array in parallel (all modifications are wrapped in a function). After returning from the worker process, will the copied array be released? See the following REPL session run on my laptop (OS X with 8GB memory) $ ~/julia/julia -p 1 julia A = randn(1*1); # According to the system monitor, the main process of julia used about 800MB of memory, and the worker process used about 80MB julia A[1] = remotecall_fetch(2, x-(x[1] = 1.0), A); # Now the main process used about 1.6GB of memory, the worker process used about 800MB julia @everywhere gc() # Now Both the main proess and the worker process used about 800MB of memory, the copied array in the worker process wasn't released julia A[1] = remotecall_fetch(2, x-(x[1] = 2.0), A); # If I want to iterate the computing, the situation gets worse. Now the worker process used about 1.6GB julia A[1] = remotecall_fetch(2, x-(x[1] = 3.0), A); # worker process used about 2.4GB now julia A[1] = remotecall_fetch(2, x-(x[1] = 4.0), A); # worker process used about 3GB julia A[1] = remotecall_fetch(2, x-(x[1] = 5.0), A); # worker process used about 3.8GB In my real code, the array is even larger and there is more processes. After one or two iterations of pmap(), the computation becomes much slower than the first iteration. I think it's because the huge memory consumption triggers page swapping constantly. PS. In fact I prefer using shared memory or multithreading in my project, but I don't know how to share a object with a user defined type besides shared array. Regards, Yang Zhixuan
[julia-users] Re: Share Library and Julia
What are the suffices on account of creation of shared library(c++) i = Int d = Double etc? On Monday, February 23, 2015 at 2:56:21 PM UTC+5:30, Jeff Waller wrote: What can be the problem? I think this: jeffw@dub1:~$ echo _Z6CP_lliPc | c++filt CP_lli(char*) jeffw@dub1:~$ echo _Z6CP_lliPh | c++filt CP_lli(unsigned char*)
[julia-users] Share Library and Julia
Created a shared library (c++) to be used in Julia via cpp package. ccall: could not find function _Z6CP_lliPh in library However, nm -D file.so There is _Z6CP_lliPc What can be the problem?
[julia-users] Re: Share Library and Julia
What can be the problem? I think this: jeffw@dub1:~$ echo _Z6CP_lliPc | c++filt CP_lli(char*) jeffw@dub1:~$ echo _Z6CP_lliPh | c++filt CP_lli(unsigned char*)
[julia-users] Making optional fields of unknown type more efficient
Hi,
In Julia, if you are not sure of an arguments type beforehand, you can use
'Any', or if you know it comes under an abstract type, you can use that.
I've been working on a type for BioJulia which allows for representation of
a node of a phylogenetic tree that will allow annotation with biological
data in the form of other types from the packages from BioJulia:
@doc
PhyExtension allows defining arbitrary metadata to annotate nodes.
This allows the PhyNode type to support any phylogenetic tree format
that includes annotations (e.g. PhyloXML, NeXML), and allows programmatic
extension of nodes with annotations.
-
type PhyExtension{T}
value::T
end
@doc
PhyNode represents a node in a phylogenetic tree.
A node can have:
- `name`
- `branchlength`
- one or more `extensions`
- a reference to its `parent` PhyNode
- reference to one or more `children`
-
type PhyNode
name::String
branchlength::Float64
confidence::Float64
extensions::Vector{PhyExtension}
children::Vector{PhyNode}
parent::PhyNode
# Inner constructor goes here.
As you can see - PhyExtension is parametric so can be constructed to
contain any type.
I'm wondering, though is this the best that can be done, can I handle the
potential to hold any number of types with unknown variables any better -
if so, how?
Is specifying a Vector of PhyExtension, where a PhyExtenision is a type
that contains any other type really giving that much information to the
Julia system to work on efficiently?
My understanding is that PhyExtension is parametric so a version is
effectively defined for every possible {T} (including user defined
composite types they might come up with). But then I imagine that's not
much information when creating the Vector{PhyExtension} as an element could
be any of the many possible PhyExtensions - the compiler has to allow for
an array that can store any PhyExtension? Or is it that the array contains
references to PhyExtensions so actually the array is simple?
Thanks,
Ben.
Re: [julia-users] Re: Bokeh.jl update released: call for feedback
The new GC is very nice. --T On Monday, February 23, 2015 11:57:38 PM Simon Danisch wrote: Great to hear =) Well it's a rocky road, to be honest... But I think it'll pay off double in the end! I'm a little afraid of Julia's garbage collector, but besides that Julia seems to be very fit for high performance graphics. 2015-02-23 23:48 GMT+01:00 Samuel Colvin s...@muelcolvin.com: I had no idea until today about your effort to use Julia for graphics. It's really exciting. If graphics is becoming one of Julia's core purposes then work on graphics at a low level isn't wasted. It sounds like on most of this we're actually agreeing. I'm as keen as anyone for JavaScript to be a stop gap before something better, just that right now it's the best stop gap. -- Samuel Colvin s...@muelcolvin.com, 07801160713 On 23 February 2015 at 22:41, Simon Danisch sdani...@gmail.com wrote: *To qualify what I mean by easier, I guess I mean: Easier in most cases for most developers, c and c++ are all very well, but the popularity and ease of development of JavaScript can't be argued with.* That's exactly why I hope that Julia will replace javascript, also for graphics. Like this we have both scientific and graphics algorithms in the same language, which would be huge! Concerning WebGL, I believe that WebGL itself is for the most things not that much slower. It's just more restrictive and doesn't have some options to really speed things up (complicated topic really). So simple OpenGL will have very comparable performance to WebGL. Also the whole stack around it makes it difficult, to interactively change and upload huge amounts of values from within julia... Well, all can surely be done with a lot of magic, but I think you end up with the same amount of work, like you would end up with when you cleanly implement it with Julia. While the latter leaves you with an incredible base to do even bigger things (Like having game engines and physics engines, OpenCL/CUDA and the like, which would be a great benefit for the scientific community). Am Montag, 23. Februar 2015 18:38:45 UTC+1 schrieb Samuel Colvin: To coincide (approximately) with the release of Bokeh v0.8.0 I've released a significantly improved version of Bokeh.jl: http://bokeh.github.io/Bokeh.jl/ This is the first plotting library I've built and the first proper Julia package. I would therefore really appreciate any feedback on the plotting interface and the structure of the package itself. Bokeh.jl is still a bit rough round the edges and missing some basic features, but the examples above demonstrate what it can do. Bokeh http://bokeh.pydata.org/en/latest/ is an interactive plotting library originally developed for python which uses HTML Javascript as it's backend to display and manipulate plots. Whether by using Bokeh or other libraries, web technologies are the obvious option for Julia to get great visualization/graphics/UI without the pain. I suggest (and I assume I'm about to get shot down) that the Julia community stops messing around with any OS specific graphics code and adopts HTML for all future visualizations. Are there any cases where that wouldn't work?
[julia-users] Unable to set up AppVeyor.
This is the log:
[00:00:00] Build started
[00:00:10] git clone -q --branch=master
git://github.com/Ismael-VC/AHN.jl.git C:\projects\ahn-jl
[00:00:17] git checkout -qf 49367576242db296b6cd360e086b0ca4acc0d492
[00:00:17] Running Install scripts
[00:00:17] if ($env:APPVEYOR_PULL_REQUEST_NUMBER -and
$env:APPVEYOR_BUILD_NUMBER -ne ((Invoke-RestMethod `
https://ci.appveyor.com/api/projects/mlubin/$env:APPVEYOR_PROJECT_SLUG/history?recordsNumber=50).builds
| ` Where-Object pullRequestId -eq
$env:APPVEYOR_PULL_REQUEST_NUMBER)[0].buildNumber) { ` throw There are
newer queued builds for this pull request, failing early. }
[00:00:17] (new-object
net.webclient).DownloadFile($(http://status.julialang.org/download/+$env:JULIAVERSION),
C:\projects\julia-binary.exe)
[00:00:19] C:\projects\julia-binary.exe /S /D=C:\projects\julia
[00:00:19] This version of C:\projects\julia-binary.exe is not compatible
with the version of Windows you're running. Check your computer's system
information and then contact the software publisher.
[00:00:19] Command exited with code 1
- https://ci.appveyor.com/project/Ismael-VC/ahn-jl/build/1.0.9/messages
This is my `appveyor.yml`:
environment:
matrix:
- JULIAVERSION: stable/win32
skip_commits:
# Add [av skip] to commit messages for docfixes, etc to reduce load on queue
message: /\[av skip\]/
install:
# if there's a newer build queued for the same PR, cancel this one
- ps: if ($env:APPVEYOR_PULL_REQUEST_NUMBER -and $env:APPVEYOR_BUILD_NUMBER
-ne ((Invoke-RestMethod `
https://ci.appveyor.com/api/projects/mlubin/$env:APPVEYOR_PROJECT_SLUG/history?recordsNumber=50).builds
| `
Where-Object pullRequestId -eq
$env:APPVEYOR_PULL_REQUEST_NUMBER)[0].buildNumber) { `
throw There are newer queued builds for this pull request, failing
early. }
# Download most recent Julia Windows binary
- ps: (new-object
net.webclient).DownloadFile($(http://status.julialang.org/download/+$env:JULIAVERSION),
C:\projects\julia-binary.exe)
# Run installer silently, output to C:\projects\julia
- C:\projects\julia-binary.exe /S /D=C:\projects\julia
build_script:
# Need to convert from shallow to complete for Pkg.clone to work
- IF EXIST .git\shallow (git fetch --unshallow)
- C:\projects\julia\bin\julia-debug -e versioninfo(); Pkg.init();
Pkg.clone(pwd(), \AHN\)
test_script:
- C:\projects\julia\bin\julia-debug -e Pkg.test(\AHN\)
- https://github.com/Ismael-VC/AHN.jl/blob/master/appveyor.yml
[julia-users] Re: splice! function. Instead of removing a single item, remove a collection of items stored in an array.
Yup you are absolutely right. Working for me as well. Thought I would give
the @time macro a try. Haven't used it before. Will stick to deleteat!.
Thanks
function f1(n)
x1 = rand(1:10,5);
errs = [2,4];
deleteat!(x1,errs);
end
function f2(n)
x1 = rand(1:10,5);
errs = [2,4];
for i=length(errs):-1:1
splice!(x2,errs[i])
end
end
julia @time f1(1)
elapsed time: 0.266245646 seconds (595924 bytes allocated)
julia @time f2(1)
elapsed time: 0.59141116 seconds (1087272 bytes allocated)
On Monday, February 23, 2015 at 3:08:08 PM UTC, Josh Langsfeld wrote:
It's working fine for me:
julia x1 = rand(1:10,5); x2 = copy(x1)
5-element Array{Int64,1}:
7
4
6
8
2
julia errs = [2,4];
julia deleteat!(x1,errs);
julia x1
3-element Array{Int64,1}:
7
6
2
julia for i=length(errs):-1:1
splice!(x2,errs[i])
end
julia x2
3-element Array{Int64,1}:
7
6
2
On Monday, February 23, 2015 at 8:07:43 AM UTC-5, Aero_flux wrote:
Thanks for the reply. I did try deleteat! without much success. What did
work for me was the following though:
errors=reverse(errors) #start with the largest index first and work down
for x=1:length(errors)
splice!(data,errors[x])
end
On Monday, February 23, 2015 at 8:17:29 AM UTC, Josh Langsfeld wrote:
corrected_data = deleteat!(x, errors) should be what you're looking for.
Alternately, a more functionally pure way to do it is to compute the good
indices and then just do corrected_data = x[good_idx], though this will
make a copy of those elements of x.
On Sunday, February 22, 2015 at 3:14:11 PM UTC-5, Aero_flux wrote:
Hello everybody,
I might be going about this the wrong way. I have a sequence of data in
a 1-D array x. Now I have done some calculations and have a 1-D array of
the indexed points in x that erroneous. What I would like to to is
remove
all the data points in x that uses the saved indices. I figured I would
use corrected_data = splice!(x, errors) but of course it won't take
arrays.
Any hints?
Many thanks
[julia-users] Re: SAVE THE DATE: JuliaCon 2015, June 24 - 28
Looking forward to this! I'm guessing registration will open through Juliacon.org sometime soon? On Tuesday, January 27, 2015 at 12:18:36 AM UTC-5, Jiahao Chen wrote: On behalf of the organizing committee, it is my pleasure to announce that JuliaCon 2015 will be held at the MIT Stata Center during the dates of Wednesday, June 24 through Sunday, June 28. More details forthcoming. We look forward to seeing you in Cambridge, Massachusetts six months from now, sans blustering bombogenetic blizzard.
[julia-users] Re: CALL FOR PARTICIPATION: JuliaCon 2015, June 24-28, MIT
Are you open to suggestions? On Saturday in Berkeley we heard Katherine Hyatt give a great talk on using Julia for simulating quantum systems. She also talked about how it was much easier to get people up to speed on Julia than C++ and went in to details as to why. So there's two angles, the quantum simulations themselves, and the utility of Julia over previous tools due to ease of use and speed. Here's her web page: http://web.physics.ucsb.edu/~kshyatt/ BTW, I'd love to see Juliacon in the SF Bay area. On Monday, February 23, 2015 at 6:47:00 PM UTC-8, Jiahao Chen wrote: On behalf of the JuliaCon 2015 Program Committee, it is my pleasure to announce that the *Call for Participation **for JuliaCon 2015 is now open.* Venue: MIT Ray Maria Stata Center, 32 Vassar Street, Cambridge, Massachusetts 02139. *Call for Participation closes: April 8, 2015, 11:59pm EDT* *Estimated notification: April 18, 2015* *JuliaCon dates: June 24 - 28, 2015* JuliaCon proposal submission form: link http://goo.gl/forms/NH6Kkr6n9Y. JuliaCon website: juliacon.org (to be updated shortly) JuliaCon program committee email: juli...@googlegroups.com javascript:. JuliaCon 2015 is looking for Julia users like you to speak! We’re looking for talks and workshops about using Julia, whether that means writing a Julia package or doing your research using Julia. *Who will decide the program?* The JuliaCon program committee is composed of entirely of volunteer organizers and can be reached at juli...@googlegroups.com javascript: with any questions or comments. Please limit your submissions to no more than 3 proposals. If you’re having trouble deciding on a topic, please send us an email; we’re happy to help. *What kinds of presentations are we looking for?* We are looking for speakers for three types of presentations: regular talks, lightning talks, and workshops. The types of presentations differ in the amount of time allotted. - Each regular talk will receive *35 minutes* of presentation time and *5 minutes* for QA. - Each lightning talk will receive *8 minutes* to speak and *2 minutes* for QA. - Workshops are larger blocks of time which are useful for tutorials, in-depth presentations of deeper ideas, and hackathons. Each workshop slot will be given *up to 3 hours*. Please note in your proposal how much time your workshop will require. Speakers are expected to bring their own laptops to connect to the projectors. *What will the audience be like?* The audience will be users of Julia, and come from widely varying backgrounds and interests. They range from professional programmers who enjoy new languages to professors who use Julia as a tool in their work. While many Julia users are very comfortable with math and statistics, the only thing you can consistently assume is that they’ve written some Julia code before. JuliaCon 2015 will also feature a tutorial for new users. *What topics are you looking for?* As long as it’s about Julia or using Julia, it’s on topic. We’re looking for talks about work that you’ve already done or have made significant progress on. Demos are welcome. Last year, there were many talks about specific Julia packages. This is a great way to advertise a package you wrote (or love to use). We want to know what your package does, how it does it, and how did using Julia affect your package, for better or worse. See the video recordings from last year at juliacon.org to get a feel for what people presented and what the audience expected. If you want to speak but are having trouble coming up with a topic, the best topics are centered on your experience using Julia. Besides creating or maintaining a package, your experience teaching Julia or using Julia in your work or research would also be interesting. We are specifically interested in your experience with Julia in a classroom setting. If you’re looking for presentation ideas, consider talks about: compilers, runtimes, parallelism, experiences teaching Julia, scientific computing, and/or visualization. *Do you have any tips for filling out the submission form?* *Biography:* This will be listed on the website when the speakers are announced. This is a good place to mention if you’ve created a Julia package or maintain one. *Title:* Make your title reflect your topic (rather than being clever) Please reserve “Julia In Production” style titles for experience reports of using Julia at companies, not research. (customer-facing, revenue-generating, etc). However, we still do want to hear about using Julia for research, just don’t use the word production in the title. *Abstract:* The abstract is a summary of what you wanted to do, what you ended up doing, the results you obtained, and what you learned from the experience. This will be listed on the website if your talk is accepted. *Special notes:*
[julia-users] Re: Julia users @ APS March Meeting?
I'm interested. On Monday, February 23, 2015 at 8:39:23 PM UTC+1, Jim Garrison wrote: The annual March Meeting of the American Physical Society is next week in San Antonio, and I am wondering if any Julia users would be interested in getting together there to chat for a bit. I already know of 4-5 Julia users attending, but surely there will be others I don't yet know of. Let me know if you'd be interested in joining us. Cheers, - Jim
Re: [julia-users] How to store the state of current rand generator (not set the seed)
Couldn't you just use a random number extracted from the first random number generator to create N new, identical random numbers generates for the second stage? Or just generate the full data set at the start of the second stage (from the random number generator), and feed that list into the subsequent stages? On Mon Feb 23 2015 at 12:02:04 PM Steve Kay stevekay...@googlemail.com wrote: I'm trying to build a simulation model with sequential stages. I only want to set the seed for the random number generator once at the very start of the simulation comparing different possible strategies. Stage 1 is common to all strategies and involves running lots of sims to reach stage 2 . At this stage my strategies follow different routes. Ideally I'd like to store the state of the random number generator just before starting stage 2 (and be able to recall it at a later time). That way I can run my first strategy through, then reset to the same state at the start of stage 2 and run the next strategy through, etc. All strategies then facing the same random conditions (without having to rerun stage 1 or set another seed at stage 2).. Are there such commands that store and reset the number generator to a particular state? Any help much appreciated. Best, Steve
[julia-users] Re: splice! function. Instead of removing a single item, remove a collection of items stored in an array.
Yup you are absolutely right. Working for me as well. Thought I would give
the @time macro a try. Haven't used it before. Restarting Julia, adding
functions and running @time gives a longer elapsed time for both. Rerunning
@time returns tiny values. The time listed below is for re-entering the
functions followed by @time, which is closer to what would happen every
time I rerun a script without closing Julia. Will stick to deleteat!. Thanks
function f1(n)
x1 = rand(1:10,5);
errs = [2,4];
deleteat!(x1,errs);
end
function f2(n)
x2 = rand(1:10,5);
errs = [2,4];
for i=length(errs):-1:1
splice!(x2,errs[i])
end
end
julia @time f1(1)
elapsed time: 0.002991644 seconds (62712 bytes allocated)
julia @time f2(1)
elapsed time: 0.006547346 seconds (129080 bytes allocated)
On Monday, February 23, 2015 at 3:08:08 PM UTC, Josh Langsfeld wrote:
It's working fine for me:
julia x1 = rand(1:10,5); x2 = copy(x1)
5-element Array{Int64,1}:
7
4
6
8
2
julia errs = [2,4];
julia deleteat!(x1,errs);
julia x1
3-element Array{Int64,1}:
7
6
2
julia for i=length(errs):-1:1
splice!(x2,errs[i])
end
julia x2
3-element Array{Int64,1}:
7
6
2
On Monday, February 23, 2015 at 8:07:43 AM UTC-5, Aero_flux wrote:
Thanks for the reply. I did try deleteat! without much success. What did
work for me was the following though:
errors=reverse(errors) #start with the largest index first and work down
for x=1:length(errors)
splice!(data,errors[x])
end
On Monday, February 23, 2015 at 8:17:29 AM UTC, Josh Langsfeld wrote:
corrected_data = deleteat!(x, errors) should be what you're looking for.
Alternately, a more functionally pure way to do it is to compute the good
indices and then just do corrected_data = x[good_idx], though this will
make a copy of those elements of x.
On Sunday, February 22, 2015 at 3:14:11 PM UTC-5, Aero_flux wrote:
Hello everybody,
I might be going about this the wrong way. I have a sequence of data in
a 1-D array x. Now I have done some calculations and have a 1-D array of
the indexed points in x that erroneous. What I would like to to is
remove
all the data points in x that uses the saved indices. I figured I would
use corrected_data = splice!(x, errors) but of course it won't take
arrays.
Any hints?
Many thanks
[julia-users] CALL FOR PARTICIPATION: JuliaCon 2015, June 24-28, MIT
On behalf of the JuliaCon 2015 Program Committee, it is my pleasure to announce that the *Call for Participation **for JuliaCon 2015 is now open.* Venue: MIT Ray Maria Stata Center, 32 Vassar Street, Cambridge, Massachusetts 02139. *Call for Participation closes: April 8, 2015, 11:59pm EDT* *Estimated notification: April 18, 2015* *JuliaCon dates: June 24 - 28, 2015* JuliaCon proposal submission form: link http://goo.gl/forms/NH6Kkr6n9Y. JuliaCon website: juliacon.org (to be updated shortly) JuliaCon program committee email: julia...@googlegroups.com. JuliaCon 2015 is looking for Julia users like you to speak! We’re looking for talks and workshops about using Julia, whether that means writing a Julia package or doing your research using Julia. *Who will decide the program?* The JuliaCon program committee is composed of entirely of volunteer organizers and can be reached at julia...@googlegroups.com with any questions or comments. Please limit your submissions to no more than 3 proposals. If you’re having trouble deciding on a topic, please send us an email; we’re happy to help. *What kinds of presentations are we looking for?* We are looking for speakers for three types of presentations: regular talks, lightning talks, and workshops. The types of presentations differ in the amount of time allotted. - Each regular talk will receive *35 minutes* of presentation time and *5 minutes* for QA. - Each lightning talk will receive *8 minutes* to speak and *2 minutes* for QA. - Workshops are larger blocks of time which are useful for tutorials, in-depth presentations of deeper ideas, and hackathons. Each workshop slot will be given *up to 3 hours*. Please note in your proposal how much time your workshop will require. Speakers are expected to bring their own laptops to connect to the projectors. *What will the audience be like?* The audience will be users of Julia, and come from widely varying backgrounds and interests. They range from professional programmers who enjoy new languages to professors who use Julia as a tool in their work. While many Julia users are very comfortable with math and statistics, the only thing you can consistently assume is that they’ve written some Julia code before. JuliaCon 2015 will also feature a tutorial for new users. *What topics are you looking for?* As long as it’s about Julia or using Julia, it’s on topic. We’re looking for talks about work that you’ve already done or have made significant progress on. Demos are welcome. Last year, there were many talks about specific Julia packages. This is a great way to advertise a package you wrote (or love to use). We want to know what your package does, how it does it, and how did using Julia affect your package, for better or worse. See the video recordings from last year at juliacon.org to get a feel for what people presented and what the audience expected. If you want to speak but are having trouble coming up with a topic, the best topics are centered on your experience using Julia. Besides creating or maintaining a package, your experience teaching Julia or using Julia in your work or research would also be interesting. We are specifically interested in your experience with Julia in a classroom setting. If you’re looking for presentation ideas, consider talks about: compilers, runtimes, parallelism, experiences teaching Julia, scientific computing, and/or visualization. *Do you have any tips for filling out the submission form?* *Biography:* This will be listed on the website when the speakers are announced. This is a good place to mention if you’ve created a Julia package or maintain one. *Title:* Make your title reflect your topic (rather than being clever) Please reserve “Julia In Production” style titles for experience reports of using Julia at companies, not research. (customer-facing, revenue-generating, etc). However, we still do want to hear about using Julia for research, just don’t use the word production in the title. *Abstract:* The abstract is a summary of what you wanted to do, what you ended up doing, the results you obtained, and what you learned from the experience. This will be listed on the website if your talk is accepted. *Special notes:* Please note in your submission if: - You do not want your presentation recorded and posted on the JuliaCon website. We plan to record all presentations by default. - You need additional resources beyond the standard video projector and laser pointer. (We expect speakers to bring their own laptops unless you ask for one.) - You require travel funding to attend JuliaCon. *Support for Speakers* Travel funding and conference fee waivers may be available for a limited group of speakers. Please note in your submission if you will be unable to attend JuliaCon without funding. We look forward to receiving your proposals and seeing you at JuliaCon 2015 in
Re: [julia-users] Making optional fields of unknown type more efficient
Julia will be able to produce specialised code for any non-concrete type
in your PhyNode. It does not matter whether it's Any or some other
abstract/parameter-less type. At least that is how I read the docs:
http://docs.julialang.org/en/latest/manual/performance-tips/#type-declarations
However, I think a method will only be slow if it actually uses the
PhyNode.extensions field, otherwise it should be fine.
Anyway, can you not construct your type like so:
type PhyExtension{T}
value::T
end
type PhyNode{T}
name::String
branchlength::Float64
confidence::Float64
extensions::Vector{PhyExtension{T}}
children::Vector{PhyNode{T}}
parent::PhyNode{T}
end
If a user needs to have different types of things in PhyNode.extensions
she can choose PhyExtension{Any} and loose some performance, otherwise a
concrete type, like PhyExtension{Float64}, will be fast.
On Tue, 2015-02-24 at 02:30, Ben Ward axolotlfan9...@gmail.com wrote:
Hi,
In Julia, if you are not sure of an arguments type beforehand, you can use
'Any', or if you know it comes under an abstract type, you can use that.
I've been working on a type for BioJulia which allows for representation of
a node of a phylogenetic tree that will allow annotation with biological
data in the form of other types from the packages from BioJulia:
@doc
PhyExtension allows defining arbitrary metadata to annotate nodes.
this allows the PhyNode type to support any phylogenetic tree format
that includes annotations (e.g. PhyloXML, NeXML), and allows programmatic
extension of nodes with annotations.
-
type PhyExtension{T}
value::T
end
@doc
PhyNode represents a node in a phylogenetic tree.
A node can have:
- `name`
- `branchlength`
- one or more `extensions`
- a reference to its `parent` PhyNode
- reference to one or more `children`
-
type PhyNode
name::String
branchlength::Float64
confidence::Float64
extensions::Vector{PhyExtension}
children::Vector{PhyNode}
parent::PhyNode
# Inner constructor goes here.
As you can see - PhyExtension is parametric so can be constructed to
contain any type.
I'm wondering, though is this the best that can be done, can I handle the
potential to hold any number of types with unknown variables any better -
if so, how?
Is specifying a Vector of PhyExtension, where a PhyExtenision is a type
that contains any other type really giving that much information to the
Julia system to work on efficiently?
My understanding is that PhyExtension is parametric so a version is
effectively defined for every possible {T} (including user defined
composite types they might come up with). But then I imagine that's not
much information when creating the Vector{PhyExtension} as an element could
be any of the many possible PhyExtensions - the compiler has to allow for
an array that can store any PhyExtension? Or is it that the array contains
references to PhyExtensions so actually the array is simple?
Thanks,
Ben.
