Re: [julia-users] Re: How to accelerate the Warm-up process of `svds`?

[Todd Leo]

Isn't svd/svds already included in base? Do I need to precompile them?

On Saturday, February 7, 2015 at 3:48:50 AM UTC+8, Tim Holy wrote:
>
> Since it allocates 120MB on the first call and only 9kB on the second, all 
> that 
> memory is just due to compilation. 
>
> The only way I know to fix that is to precompile some of the functions 
> when you 
> build julia. If this is a big deal to you, consider adding your own custom 
> userimg.jl (and see base/precompile.jl for a model). 
>
>
> http://docs.julialang.org/en/latest/manual/modules/?highlight=userimg#module-initialization-and-precompilation
>  
>
> --Tim 
>
> On Friday, February 06, 2015 11:23:52 AM Viral Shah wrote: 
> > This is because the internal operations with svds are allocating new 
> > vectors every iteration. This PR should address it, but needs to be 
> > completed, 
> > 
> > https://github.com/JuliaLang/julia/pull/7907 
> > 
> > Also, array indexing giving views by default will also help here. 
> > 
> > -viral 
> > 
> > On Friday, February 6, 2015 at 7:50:24 PM UTC+5:30, Todd Leo wrote: 
> > > Hi Julians, 
> > > 
> > > I am trying to apply svd on a very large sparse matrix using svds. 
> When 
> > > warming up svds function, I used a very small random vector, and the 
> > > number 
> > > of singular values (nsv) is set to one. However, this simple set up 
> > > results 
> > > in a considerable high cost of time, and as much as 120MB memory is 
> > > occupied. To me, it doesn't make sense, and one can reproduce it by: 
> > > 
> > > julia> @time svds(sprand(3,3,0.1), nsv = 1) 
> > > 
> > >> elapsed time: 2.640233094 seconds (117 MB allocated, 1.06% gc time in 
> 5 
> > >> 
> > >>> pauses with 0 full sweep) 
> > > 
> > > Regards, 
> > > Todd 
>
>

Re: [julia-users] Re: Standard File Dialogs

[Steven G. Johnson]

On Tuesday, February 24, 2015 at 10:16:25 PM UTC-5, Steven G. Johnson wrote:
>
> Yes, something like the EasyDialogs  
> Python package would be great.
>

(EasyDialogs doesn't work anymore and was never cross-platform, but that 
sort of interface seems useful.)

Re: [julia-users] Re: Standard File Dialogs

[Steven G. Johnson]

Yes, something like the EasyDialogs  
Python package would be great.

Re: [julia-users] Mutate C struct represented as Julia immutable

[Jameson Nash]

You can't modify an immutable. There are no exceptions.

Even when I implement this optimization, it will still not enable you to
modify an immutable. It will just provide a simpler way of writing
something that could already be done to mutable types.

Why do you insist on writing `pointer([x])`? I have repeated said that is
an invalid code fragment. However, in this case, perhaps you meant
`unsafe_store(C.range,z)`?


On Tue, Feb 24, 2015 at 11:36 AM J Luis  wrote:

>
>
> use unsafe_load() to convert the value to a julia object, then
>> unsafe_store() to write the new struct back.
>>
>> at some point, I want to modify unsafe_load/unsafe_store to take a
>> fieldname symbol as the second argument to make this functionality more
>> direct available. however, there hasn't seemed to be a request / issue open
>> for it yet.
>>
>
> PLEASE, do.
>
> I have the same type of problem but I'm not able to solve it with the
> solutions proposed in this thread.
> See, I have this and want to change the *rgb_low*
>
> julia> gmt_lut = unsafe_load(C.range, 1);
>
> julia> gmt_lut.rgb_low
> GMT.Array_4_Cdouble(0.583,0.0,1.0,0.0)
>
> which is a
>
> immutable Array_4_Cdouble
> d1::Cdouble
> d2::Cdouble
> d3::Cdouble
> d4::Cdouble
> end
>
> so I do
>
> julia> z = GMT.Array_4_Cdouble(0.0, 0.0, 0.0, 0.0)
> GMT.Array_4_Cdouble(0.0,0.0,0.0,0.0)
>
> julia> unsafe_store!(pointer([gmt_lut.rgb_low]), z)
> Ptr{GMT.Array_4_Cdouble} @0x819faf60
>
> no errors but I don't know where new *z* immutable landed on because I
> keep seeing the old value
>
> julia> gmt_lut.rgb_low
> GMT.Array_4_Cdouble(0.583,0.0,1.0,0.0)
>
> I suspect part of it is dues to the pointer([gmt_lut.rgb_low]) command
> because when I do several of those on line I keep getting different
> addresses
>
> julia> pointer([gmt_lut.rgb_low])
> Ptr{GMT.Array_4_Cdouble} @0x82b7baf0
>
> julia> pointer([gmt_lut.rgb_low])
> Ptr{GMT.Array_4_Cdouble} @0x82ba00d0
>
> julia> pointer([gmt_lut.rgb_low])
> Ptr{GMT.Array_4_Cdouble} @0x82ba0670
>
> but than how can modify this field(s)?
>
>
>
>
>

Re: [julia-users] Re: Standard File Dialogs

[Jameson Nash]

It's nice to see that Tk's usual inflexibility as a toolkit actually serves
it well here on OS X, and it just uses the native dialog boxes. Gtk has
better themes, although it's stock look does leave a bit to be desired on
OSX and the homebrew installation seems to have failed at the theme
installation/configuration step, resulting in the non-fatal warnings that
you observed (please file a bug against this on Gtk.jl – I use a
MacPorts-installed gtk, so I don't see this same issue).

I'm hoping someday there will be a Julia package that provides simple
access to each platforms basic standard (native) dialog boxes for
open/save/etc.

On Tue Feb 24 2015 at 7:55:56 PM j verzani  wrote:

> You can try `GetOpenFile`, `GetSaveFile`, or `ChooseDirectory` in the
> Tk.jl package. They all return a file name or "" if canceled. If you have
> other calls you want, these are just simple wrappers. For example, `
> GetOpenFile() = tcl("tk_getOpenFile")`.
>
>
> On Tuesday, February 24, 2015 at 6:56:21 PM UTC-5, Eric S wrote:
>>
>> I did try the Tk package instead. The message dialog look a lot better,
>> but there is nothing in the documentation which suggests how to get at Tk's
>> askopenfile or other dialogs. Any help would be appreciated.
>>
>> Eric
>>
>> On Tuesday, February 24, 2015 at 5:22:19 PM UTC-6, Eric S wrote:
>>>
>>> I'm enjoying Julia, but one thing I'm missing is standard file open and
>>> file save dialogs. I've found the Gtk package and tried that. It does
>>> indeed generate a file dialog, but it is really ugly and nonstandard (on OS
>>> X) and also generates the following error like messages in the terminal
>>> (below). Perhaps there is something wrong with my installation.
>>>
>>> Is there something like how R works where you can just type ">
>>> file.choose()" and a nice file picker dialog comes up.
>>>
>>> -Eric
>>>
>>> Gtk-Message: GtkDialog mapped without a transient parent. This is
>>> discouraged.
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion
>>> 'G_IS_OBJECT (object)' failed
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion
>>> 'G_IS_OBJECT (object)' failed
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion
>>> 'G_IS_OBJECT (object)' failed
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion
>>> 'G_IS_OBJECT (object)' failed
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion
>>> 'G_IS_OBJECT (object)' failed
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion
>>> 'G_IS_OBJECT (object)' failed
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion
>>> 'G_IS_OBJECT (object)' failed
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): Gtk-WARNING **: Error loading theme icon
>>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>>
>>>
>>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion
>>> 'G_IS_OBJECT (object)' failed
>>>
>>>
>>> (:2678): GLib-GObject-CRITICAL **: g_object_unre

Re: [julia-users] Re: Constructing matrices

[Bill Hart]

Sorry, I wrote 0D array, when I actually meant 0xn or nx0 arrays, (which my
colleague and I agree should be 2D).

On 25 February 2015 at 01:10, Bill Hart  wrote:

>
>
> On 25 February 2015 at 00:18, Matt Bauman  wrote:
>
>> I don't understand the distinction you're making between "flat arrays"
>> and "column matrices."  Internally, the vectors and matrices are laid
>> out identically
>> ,
>> with the exception that there are two dimensions instead of one and that 2D
>> arrays cannot grow.
>>
>
> Sure. I only mean that you have extra data and extra branches to deal with
> 2D instead of 1D arrays. I agree it's probably slight. But I can't believe
> someone did this accidentally without having a performance reason in mind.
> Perhaps I am just wrong.
>
>
>> This is how `vec` is able to convert matrices to 1D vectors without
>> copying the data.  I would be very surprised if there was a performance
>> difference between the two (when using logical indexing for both).  There
>> is, however, a difference in how they behave.
>>
>> There's already a major change slated for the [a,b] and [a;b] syntaxes —
>> they will no longer be equivalent once the switch is flipped on
>> https://github.com/JuliaLang/julia/pull/8599.  The former will always be
>> a 1D vector of its arguments.  The latter will perform a vertical
>> concatenation of its arguments.  The result shape will be dependent upon
>> the shapes of its arguments — it could be 1D or more.
>>
>
> How can a vertical concatenation yield a 1D array?
>
> julia> [1 1 1; 2 2 2; 3 3 3]
> 3x3 Array{Int64,2}:
>  1  1  1
>  2  2  2
>  3  3  3
>
> julia> [1 1; 2 2; 3 3]
> 3x2 Array{Int64,2}:
>  1  1
>  2  2
>  3  3
>
> Surely I expect
>
> julia> [1; 2; 3]
> 3x1 Array{Int64, 2}:
>  1
>  2
>  3
>
>
>> I agree that changing it to always be at least 2D has some merit.  Now
>> would certainly be the time to do it!
>>
>
> Since I can't understand how you could end up with 1D, I obviously prefer
> 2D as the minimum result. I am quite happy for it to be higher of course,
> if the arguments have higher than 1D.
>
> One of my (mathematical) colleagues today asked about 0D arrays. He claims
> to have met nasty corner cases in code because 0xn and nx0 arrays were not
> supported in the language he was using.
>
> I don't know what that would look like. [ ; ; ; ; ] perhaps, for columns.
> And [[] [] [] []] for rows? Though to be fair, I can't imagine an actual
> user creating arrays this way. They probably only need to be supported at
> the type level, not at the literal level.
>
> It seems like these are supported at the type level. With some work I
> found that the following constructs a 3x0: [[]'; []'; []']
>
> This came up because I showed him what [[1]; [2]; [3]] resulted in.
> Neither of us could have predicted the outcome.
>
> We tried [[]; []; []] and couldn't predict the outcome there either.
>
> By the way, we found a strange thing with array printing. The following
> prints a huge space before the array:
>
> [1 2; BigInt(10)^1000 3]
>
> We think it is deliberate, but weren't sure. We couldn't construct an
> example where this would be wanted behaviour, except perhaps in a kind of
> divide and conquer printing routine where you want rows to line up when
> printing multiple matrices next to each other, where the size of the
> maximum entry over all the matrices is known in advance, for example.
>
> We then decided that printing of large objects would be a good thesis
> topic. :-)
>
>
>> On Tuesday, February 24, 2015 at 5:42:23 PM UTC-5, Bill Hart wrote:
>>>
>>> This might not be a trivial change. Presumably its done this way so that
>>> functions like linear solving do not take a column matrix as one of its
>>> inputs (which maybe has a relatively inefficient representation?), but so
>>> that they can take a flat array as input, which does have an efficient
>>> representation.
>>>
>>> So it might not just be a matter of changing the syntax. Users who are
>>> currently using [1; 2; 3] with such functions would have to switch to using
>>> [1, 2, 3]. Or, the functions that currently expect flat array inputs when
>>> they really mean column would have to be changed to accept the other.
>>>
>>> I understand the logic of why this was done. I just don't prefer it on
>>> consistency grounds, especially given that it was nontrivial to work out
>>> how to generate an actual nx1 matrix.
>>>
>>> I'm all in favour of changing it. I just don't think it was an accident.
>>> The documentation explicitly mentions that Julia uses a flat array instead.
>>>
>>> On 24 February 2015 at 23:18, Kevin Squire  wrote:
>>>
 I (think I) would be in favor of changing [1; 2; 3] to mean a 1-column
 matrix.  Arguments against?

 Kevin

 On Tue, Feb 24, 2015 at 11:45 AM, Bill Hart 
 wrote:

> Julia distinguishes between them at the level of types, yes. I was
> talking abo

[julia-users] Re: Standard File Dialogs

[j verzani]

You can try `GetOpenFile`, `GetSaveFile`, or `ChooseDirectory` in the Tk.jl 
package. They all return a file name or "" if canceled. If you have other 
calls you want, these are just simple wrappers. For example, `GetOpenFile() 
= tcl("tk_getOpenFile")`.

On Tuesday, February 24, 2015 at 6:56:21 PM UTC-5, Eric S wrote:
>
> I did try the Tk package instead. The message dialog look a lot better, 
> but there is nothing in the documentation which suggests how to get at Tk's 
> askopenfile or other dialogs. Any help would be appreciated.
>
> Eric
>
> On Tuesday, February 24, 2015 at 5:22:19 PM UTC-6, Eric S wrote:
>>
>> I'm enjoying Julia, but one thing I'm missing is standard file open and 
>> file save dialogs. I've found the Gtk package and tried that. It does 
>> indeed generate a file dialog, but it is really ugly and nonstandard (on OS 
>> X) and also generates the following error like messages in the terminal 
>> (below). Perhaps there is something wrong with my installation. 
>>
>> Is there something like how R works where you can just type "> 
>> file.choose()" and a nice file picker dialog comes up.
>>
>> -Eric
>>
>> Gtk-Message: GtkDialog mapped without a transient parent. This is 
>> discouraged.
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_unref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): GLib-GObject-CRITICAL **: g_object_unref: assertion 
>> 'G_IS_OBJECT (object)' failed
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> (:2678): Gtk-WARNING **: Error loading theme icon 
>> 'image-missing' for stock: Icon 'image-missing' not present in theme
>>
>>
>> 

Re: [julia-users] Re: Constructing matrices

[Bill Hart]

On 25 February 2015 at 00:18, Matt Bauman  wrote:

> I don't understand the distinction you're making between "flat arrays" and
> "column matrices."  Internally, the vectors and matrices are laid out
> identically
> ,
> with the exception that there are two dimensions instead of one and that 2D
> arrays cannot grow.
>

Sure. I only mean that you have extra data and extra branches to deal with
2D instead of 1D arrays. I agree it's probably slight. But I can't believe
someone did this accidentally without having a performance reason in mind.
Perhaps I am just wrong.


> This is how `vec` is able to convert matrices to 1D vectors without
> copying the data.  I would be very surprised if there was a performance
> difference between the two (when using logical indexing for both).  There
> is, however, a difference in how they behave.
>
> There's already a major change slated for the [a,b] and [a;b] syntaxes —
> they will no longer be equivalent once the switch is flipped on
> https://github.com/JuliaLang/julia/pull/8599.  The former will always be
> a 1D vector of its arguments.  The latter will perform a vertical
> concatenation of its arguments.  The result shape will be dependent upon
> the shapes of its arguments — it could be 1D or more.
>

How can a vertical concatenation yield a 1D array?

julia> [1 1 1; 2 2 2; 3 3 3]
3x3 Array{Int64,2}:
 1  1  1
 2  2  2
 3  3  3

julia> [1 1; 2 2; 3 3]
3x2 Array{Int64,2}:
 1  1
 2  2
 3  3

Surely I expect

julia> [1; 2; 3]
3x1 Array{Int64, 2}:
 1
 2
 3


> I agree that changing it to always be at least 2D has some merit.  Now
> would certainly be the time to do it!
>

Since I can't understand how you could end up with 1D, I obviously prefer
2D as the minimum result. I am quite happy for it to be higher of course,
if the arguments have higher than 1D.

One of my (mathematical) colleagues today asked about 0D arrays. He claims
to have met nasty corner cases in code because 0xn and nx0 arrays were not
supported in the language he was using.

I don't know what that would look like. [ ; ; ; ; ] perhaps, for columns.
And [[] [] [] []] for rows? Though to be fair, I can't imagine an actual
user creating arrays this way. They probably only need to be supported at
the type level, not at the literal level.

It seems like these are supported at the type level. With some work I found
that the following constructs a 3x0: [[]'; []'; []']

This came up because I showed him what [[1]; [2]; [3]] resulted in. Neither
of us could have predicted the outcome.

We tried [[]; []; []] and couldn't predict the outcome there either.

By the way, we found a strange thing with array printing. The following
prints a huge space before the array:

[1 2; BigInt(10)^1000 3]

We think it is deliberate, but weren't sure. We couldn't construct an
example where this would be wanted behaviour, except perhaps in a kind of
divide and conquer printing routine where you want rows to line up when
printing multiple matrices next to each other, where the size of the
maximum entry over all the matrices is known in advance, for example.

We then decided that printing of large objects would be a good thesis
topic. :-)


> On Tuesday, February 24, 2015 at 5:42:23 PM UTC-5, Bill Hart wrote:
>>
>> This might not be a trivial change. Presumably its done this way so that
>> functions like linear solving do not take a column matrix as one of its
>> inputs (which maybe has a relatively inefficient representation?), but so
>> that they can take a flat array as input, which does have an efficient
>> representation.
>>
>> So it might not just be a matter of changing the syntax. Users who are
>> currently using [1; 2; 3] with such functions would have to switch to using
>> [1, 2, 3]. Or, the functions that currently expect flat array inputs when
>> they really mean column would have to be changed to accept the other.
>>
>> I understand the logic of why this was done. I just don't prefer it on
>> consistency grounds, especially given that it was nontrivial to work out
>> how to generate an actual nx1 matrix.
>>
>> I'm all in favour of changing it. I just don't think it was an accident.
>> The documentation explicitly mentions that Julia uses a flat array instead.
>>
>> On 24 February 2015 at 23:18, Kevin Squire  wrote:
>>
>>> I (think I) would be in favor of changing [1; 2; 3] to mean a 1-column
>>> matrix.  Arguments against?
>>>
>>> Kevin
>>>
>>> On Tue, Feb 24, 2015 at 11:45 AM, Bill Hart 
>>> wrote:
>>>
 Julia distinguishes between them at the level of types, yes. I was
 talking about the syntax for creating them. There they become conflated.

 [1; 2; 3] is precisely the same thing as [1, 2, 3]

 Sorry for not being clearer about that.

 It's clear this is done intentionally, not accidentally. It's just
 extremely confusing and I'll bet it will bite somewhere down the track.
 It's e

[julia-users] Re: Standard File Dialogs

[Eric S]

I did try the Tk package instead. The message dialog look a lot better, but 
there is nothing in the documentation which suggests how to get at Tk's 
askopenfile or other dialogs. Any help would be appreciated.

Eric

On Tuesday, February 24, 2015 at 5:22:19 PM UTC-6, Eric S wrote:
>
> I'm enjoying Julia, but one thing I'm missing is standard file open and 
> file save dialogs. I've found the Gtk package and tried that. It does 
> indeed generate a file dialog, but it is really ugly and nonstandard (on OS 
> X) and also generates the following error like messages in the terminal 
> (below). Perhaps there is something wrong with my installation. 
>
> Is there something like how R works where you can just type "> 
> file.choose()" and a nice file picker dialog comes up.
>
> -Eric
>
> Gtk-Message: GtkDialog mapped without a transient parent. This is 
> discouraged.
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_unref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_unref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): GLib-GObject-CRITICAL **: g_object_unref: assertion 
> 'G_IS_OBJECT (object)' failed
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
> for stock: Icon 'image-missing' not present in theme
>
>
> (:2678): GLib-GObject-

[julia-users] workflow for devloping large modules

[lapeyre . math122a]

I'm looking for a workflow, maybe someone can point me to a thread or
a document.

I was developing a large module without actually putting it in a
module. It is 7500 lines of code (counting every newline) and the
test suite is about 700 lines. I arranged things so the module loads
in about 2-3 seconds and the test suite runs the first time in about
20 seconds and subsequently in less than a second (or more if I reload
some code) I had to restart very rarely. So for the majority of
changes, I could reload one file and run the entire test suite in,
maybe 1 to 8 seconds, occasionally longer

Recently, I decided to depend on SymPy, which takes 20 seconds to
load. Now, starting from zero and running my module's test suite is 45 
seconds.

I already have a single file MyModule.jl that includes all the other
code. So now I wrap all the 'includes' inside a 'module' block in
MyModule.jl.  Now my workflow is so slow that for practical purposes,
I can no longer work on the module.

When I am working on core code, for every change I make. I have to
restart and wait 45 seconds.

I spent a few hours, now, and in the past, reading threads on
workflows.  I tried a few things, but no luck. I didn't try all the
secret recipes.

I don't understand how people get around the need to reload the
entire module each time they make a change to it, and what the
potential problems from doing this are. My test suite
fails to run if I load the module twice. I spent some time trying
to understand why. Maybe finding this problem is the only solution?

Here are two possible solutions:

1. Fully qualify all identifiers in the module. Then, if I understand,
I can reload pieces of the code.

2. Break the code into several modules, polluting the namespace at
the module level

[julia-users] Re: Does sizehint! make sense for sparse matrices?

[Seth]

On Tuesday, February 24, 2015 at 2:04:07 PM UTC-8, Douglas Bates wrote:
>
> sizehint! could be applied to the .rowval and .nzval fields but it will 
> only make things easier if you then add elements to the last columns.  Even 
> if the vectors don't need to be resized, adding a non-zero value to an 
> interior column of a sparse matrix requires inserting in the middle of a 
> vector.
>
> If it makes sense in your application you are better off using nonzeros to 
> get the triplet representation, pushing values onto the end of those 
> vectors and, when you are finished, using sparse to convert back to 
> SparseMatrixCSC.  
>


Wow, this is amazing:

function adjmx2(g::AbstractGraph)
n_v = nv(g)
mx = spzeros(Int,0)  # this throws a warning but I'll fix it
mx.n = n_v
mx.m = n_v
colindex = 1
for r in g.finclist
colvals = Int[]
for e in r
push!(colvals, dst(e))
push!(mx.nzval, 1)
colindex += 1
end
sort!(colvals)
append!(mx.rowval, colvals)
push!(mx.colptr, colindex)
end
return mx
end

julia> g = Graph(20_000,50_000)
{2, 5} undirected graph

julia> @time z = adjacency_matrix(g);   # using standard sparsematrix 
assignments, already compiled
elapsed time: 2.39827398 seconds (7 MB allocated, 0.34% gc time in 1 pauses 
with 0 full sweep)

julia> @time y = LightGraphs.adjmx2(g); # using above, already compiled 
elapsed time: 0.01251955 seconds (7 MB allocated)

julia> z == y
true



Thanks for the tips!

Seth.

[julia-users] Standard File Dialogs

[Eric S]

I'm enjoying Julia, but one thing I'm missing is standard file open and 
file save dialogs. I've found the Gtk package and tried that. It does 
indeed generate a file dialog, but it is really ugly and nonstandard (on OS 
X) and also generates the following error like messages in the terminal 
(below). Perhaps there is something wrong with my installation. 

Is there something like how R works where you can just type "> 
file.choose()" and a nice file picker dialog comes up.

-Eric

Gtk-Message: GtkDialog mapped without a transient parent. This is 
discouraged.


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): Gtk-WARNING **: Error loading theme icon 'image-missing' 
for stock: Icon 'image-missing' not present in theme


(:2678): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed


(:2678): GLib-GObject-

Re: [julia-users] Re: Constructing matrices

[Matt Bauman]

I don't understand the distinction you're making between "flat arrays" and 
"column matrices."  Internally, the vectors and matrices are laid out 
identically 
,
 
with the exception that there are two dimensions instead of one and that 2D 
arrays cannot grow.  This is how `vec` is able to convert matrices to 1D 
vectors without copying the data.  I would be very surprised if there was a 
performance difference between the two (when using logical indexing for 
both).  There is, however, a difference in how they behave.

There's already a major change slated for the [a,b] and [a;b] syntaxes — 
they will no longer be equivalent once the switch is flipped 
on https://github.com/JuliaLang/julia/pull/8599.  The former will always be 
a 1D vector of its arguments.  The latter will perform a vertical 
concatenation of its arguments.  The result shape will be dependent upon 
the shapes of its arguments — it could be 1D or more.  I agree that 
changing it to always be at least 2D has some merit.  Now would certainly 
be the time to do it!

On Tuesday, February 24, 2015 at 5:42:23 PM UTC-5, Bill Hart wrote:
>
> This might not be a trivial change. Presumably its done this way so that 
> functions like linear solving do not take a column matrix as one of its 
> inputs (which maybe has a relatively inefficient representation?), but so 
> that they can take a flat array as input, which does have an efficient 
> representation.
>
> So it might not just be a matter of changing the syntax. Users who are 
> currently using [1; 2; 3] with such functions would have to switch to using 
> [1, 2, 3]. Or, the functions that currently expect flat array inputs when 
> they really mean column would have to be changed to accept the other.
>
> I understand the logic of why this was done. I just don't prefer it on 
> consistency grounds, especially given that it was nontrivial to work out 
> how to generate an actual nx1 matrix.
>
> I'm all in favour of changing it. I just don't think it was an accident. 
> The documentation explicitly mentions that Julia uses a flat array instead.
>
> On 24 February 2015 at 23:18, Kevin Squire  > wrote:
>
>> I (think I) would be in favor of changing [1; 2; 3] to mean a 1-column 
>> matrix.  Arguments against?
>>
>> Kevin
>>
>> On Tue, Feb 24, 2015 at 11:45 AM, Bill Hart > > wrote:
>>
>>> Julia distinguishes between them at the level of types, yes. I was 
>>> talking about the syntax for creating them. There they become conflated.
>>>
>>> [1; 2; 3] is precisely the same thing as [1, 2, 3]
>>>
>>> Sorry for not being clearer about that.
>>>
>>> It's clear this is done intentionally, not accidentally. It's just 
>>> extremely confusing and I'll bet it will bite somewhere down the track. 
>>> It's especially bad for metaprogramming for example.
>>>
>>> Bill.
>>>
>>> On 24 February 2015 at 20:39, David P. Sanders >> > wrote:
>>>


 El martes, 24 de febrero de 2015, 8:18:28 (UTC-6), Bill Hart escribió:
>
> The specific use case where I hit this as a problem is in wrapping 
> external libraries like flint and pari, which unlike julia do not 
> conflate 
> 1xn matrices with flat arrays.
>
> However, I have just realised that Julia only conflates column vectors 
> with flat arrays, not row vectors.
>

 That is not my interpretation. Julia carefully distinguishes between 
 the different options:

 (i) a 1D object (which could be called a "vector"), i.e. with 1 index 
 (what I understand you mean by "flat array"):

 julia> v = [3, 4, 5, 6]
 4-element Array{Int64,1}:
  3
  4
  5
  6

 This is (unfortunately?) displayed in a column, but is just a 
 one-dimensional list of things.

 (ii) A matrix object of size  1 x n  (which could be called a "row 
 vector", but is actually a matrix):

 julia> w = [3 4 5 6]
 1x4 Array{Int64,2}:
  3  4  5  6

 (iii) A matrix of size  n x 1   (which could be called a "column 
 vector", but is actually a matrix):
 julia> z = reshape([3, 4, 5, 6], (4,1)) 
 4x1 Array{Int64,2}:
  3
  4
  5
  6

 (The output looks superficially the same as that for v, but the object 
 is of a different type -- Array{Int64, 2} vs. Array{Int64, 1}. I.e. there 
 are now *two* indices.)

 I do not find the nomenclature "row vector" and "column vector" useful 
 in this (or almost any other!) context.

 David.

  

>
> Therefore I can overload my constructor for the external flint and 
> pari types to interpret Julia flat arrays as column vectors. Fortunately, 
> I 
> only need to do that in one place. I can't imagine overloading every 
> single 
> function for every possible combination of flat array vs matrix for each 
> parameter to the function.
>
>>

Re: [julia-users] Re: Constructing matrices

[Bill Hart]

This might not be a trivial change. Presumably its done this way so that
functions like linear solving do not take a column matrix as one of its
inputs (which maybe has a relatively inefficient representation?), but so
that they can take a flat array as input, which does have an efficient
representation.

So it might not just be a matter of changing the syntax. Users who are
currently using [1; 2; 3] with such functions would have to switch to using
[1, 2, 3]. Or, the functions that currently expect flat array inputs when
they really mean column would have to be changed to accept the other.

I understand the logic of why this was done. I just don't prefer it on
consistency grounds, especially given that it was nontrivial to work out
how to generate an actual nx1 matrix.

I'm all in favour of changing it. I just don't think it was an accident.
The documentation explicitly mentions that Julia uses a flat array instead.

On 24 February 2015 at 23:18, Kevin Squire  wrote:

> I (think I) would be in favor of changing [1; 2; 3] to mean a 1-column
> matrix.  Arguments against?
>
> Kevin
>
> On Tue, Feb 24, 2015 at 11:45 AM, Bill Hart 
> wrote:
>
>> Julia distinguishes between them at the level of types, yes. I was
>> talking about the syntax for creating them. There they become conflated.
>>
>> [1; 2; 3] is precisely the same thing as [1, 2, 3]
>>
>> Sorry for not being clearer about that.
>>
>> It's clear this is done intentionally, not accidentally. It's just
>> extremely confusing and I'll bet it will bite somewhere down the track.
>> It's especially bad for metaprogramming for example.
>>
>> Bill.
>>
>> On 24 February 2015 at 20:39, David P. Sanders 
>> wrote:
>>
>>>
>>>
>>> El martes, 24 de febrero de 2015, 8:18:28 (UTC-6), Bill Hart escribió:

 The specific use case where I hit this as a problem is in wrapping
 external libraries like flint and pari, which unlike julia do not conflate
 1xn matrices with flat arrays.

 However, I have just realised that Julia only conflates column vectors
 with flat arrays, not row vectors.

>>>
>>> That is not my interpretation. Julia carefully distinguishes between the
>>> different options:
>>>
>>> (i) a 1D object (which could be called a "vector"), i.e. with 1 index
>>> (what I understand you mean by "flat array"):
>>>
>>> julia> v = [3, 4, 5, 6]
>>> 4-element Array{Int64,1}:
>>>  3
>>>  4
>>>  5
>>>  6
>>>
>>> This is (unfortunately?) displayed in a column, but is just a
>>> one-dimensional list of things.
>>>
>>> (ii) A matrix object of size  1 x n  (which could be called a "row
>>> vector", but is actually a matrix):
>>>
>>> julia> w = [3 4 5 6]
>>> 1x4 Array{Int64,2}:
>>>  3  4  5  6
>>>
>>> (iii) A matrix of size  n x 1   (which could be called a "column
>>> vector", but is actually a matrix):
>>> julia> z = reshape([3, 4, 5, 6], (4,1))
>>> 4x1 Array{Int64,2}:
>>>  3
>>>  4
>>>  5
>>>  6
>>>
>>> (The output looks superficially the same as that for v, but the object
>>> is of a different type -- Array{Int64, 2} vs. Array{Int64, 1}. I.e. there
>>> are now *two* indices.)
>>>
>>> I do not find the nomenclature "row vector" and "column vector" useful
>>> in this (or almost any other!) context.
>>>
>>> David.
>>>
>>>
>>>

 Therefore I can overload my constructor for the external flint and pari
 types to interpret Julia flat arrays as column vectors. Fortunately, I only
 need to do that in one place. I can't imagine overloading every single
 function for every possible combination of flat array vs matrix for each
 parameter to the function.

 The only reason I did things that way is because I initially thought
 Julia arrays had cartesian product semantics (pointwise operations) rather
 than matrix semantics.

 So actually, I guess I can live with the way things are right now.

 On 24 February 2015 at 14:29, Jiahao Chen  wrote:

> Clearly Julia wants to deliberately conflate row and column vectors,
>> which is fine if you aren't working with an algorithm that depends on the
>> individual dimensions of your matrices, and you aren't interfacing to an
>> external library.
>>
>
> Could you elaborate on what you mean here? As part of Issue #4474 I've
> been trying to collect specific examples.
>


>>
>

Re: [julia-users] Re: Constructing matrices

[Kevin Squire]

I (think I) would be in favor of changing [1; 2; 3] to mean a 1-column
matrix.  Arguments against?

Kevin

On Tue, Feb 24, 2015 at 11:45 AM, Bill Hart 
wrote:

> Julia distinguishes between them at the level of types, yes. I was talking
> about the syntax for creating them. There they become conflated.
>
> [1; 2; 3] is precisely the same thing as [1, 2, 3]
>
> Sorry for not being clearer about that.
>
> It's clear this is done intentionally, not accidentally. It's just
> extremely confusing and I'll bet it will bite somewhere down the track.
> It's especially bad for metaprogramming for example.
>
> Bill.
>
> On 24 February 2015 at 20:39, David P. Sanders 
> wrote:
>
>>
>>
>> El martes, 24 de febrero de 2015, 8:18:28 (UTC-6), Bill Hart escribió:
>>>
>>> The specific use case where I hit this as a problem is in wrapping
>>> external libraries like flint and pari, which unlike julia do not conflate
>>> 1xn matrices with flat arrays.
>>>
>>> However, I have just realised that Julia only conflates column vectors
>>> with flat arrays, not row vectors.
>>>
>>
>> That is not my interpretation. Julia carefully distinguishes between the
>> different options:
>>
>> (i) a 1D object (which could be called a "vector"), i.e. with 1 index
>> (what I understand you mean by "flat array"):
>>
>> julia> v = [3, 4, 5, 6]
>> 4-element Array{Int64,1}:
>>  3
>>  4
>>  5
>>  6
>>
>> This is (unfortunately?) displayed in a column, but is just a
>> one-dimensional list of things.
>>
>> (ii) A matrix object of size  1 x n  (which could be called a "row
>> vector", but is actually a matrix):
>>
>> julia> w = [3 4 5 6]
>> 1x4 Array{Int64,2}:
>>  3  4  5  6
>>
>> (iii) A matrix of size  n x 1   (which could be called a "column vector",
>> but is actually a matrix):
>> julia> z = reshape([3, 4, 5, 6], (4,1))
>> 4x1 Array{Int64,2}:
>>  3
>>  4
>>  5
>>  6
>>
>> (The output looks superficially the same as that for v, but the object is
>> of a different type -- Array{Int64, 2} vs. Array{Int64, 1}. I.e. there are
>> now *two* indices.)
>>
>> I do not find the nomenclature "row vector" and "column vector" useful in
>> this (or almost any other!) context.
>>
>> David.
>>
>>
>>
>>>
>>> Therefore I can overload my constructor for the external flint and pari
>>> types to interpret Julia flat arrays as column vectors. Fortunately, I only
>>> need to do that in one place. I can't imagine overloading every single
>>> function for every possible combination of flat array vs matrix for each
>>> parameter to the function.
>>>
>>> The only reason I did things that way is because I initially thought
>>> Julia arrays had cartesian product semantics (pointwise operations) rather
>>> than matrix semantics.
>>>
>>> So actually, I guess I can live with the way things are right now.
>>>
>>> On 24 February 2015 at 14:29, Jiahao Chen  wrote:
>>>
 Clearly Julia wants to deliberately conflate row and column vectors,
> which is fine if you aren't working with an algorithm that depends on the
> individual dimensions of your matrices, and you aren't interfacing to an
> external library.
>

 Could you elaborate on what you mean here? As part of Issue #4474 I've
 been trying to collect specific examples.

>>>
>>>
>

Re: [julia-users] Does sizehint! make sense for sparse matrices?

[Jiahao Chen]

The definition of the CSC format does not ordinarily admit for allocated
but unused space:

http://netlib.org/linalg/html_templates/node92.html

You may recognize that CSC is a sorted representation of a trie of depth 2
(one for the rows, then for the columns).

Theoretically we could relax the definition so that we can have allocated
but unused space in the val array. However, it's not clear what sizehint!
should do? - allocate more space and distribute the unused space amongst
each column? It's very tricky and won't be robust enough for general use
cases.

Thanks,

Jiahao Chen
Staff Research Scientist
MIT Computer Science and Artificial Intelligence Laboratory

On Tue, Feb 24, 2015 at 4:47 PM, Seth  wrote:

> I was surprised to find that there is no method on sizehint! for sparse
> matrices:
>
> ERROR: MethodError: `sizehint!` has no method matching sizehint!(::Base.
> SparseMatrix.SparseMatrixCSC{Int64,Int64}, ::Int64)
>
>
> Is this intentional? I noticed that insert performance on sparse matrices (
> setindex! in particular) is the bottleneck in my code, and I was hoping
> to optimize a bit more.
>
>

[julia-users] Re: Does sizehint! make sense for sparse matrices?

[Douglas Bates]

On Tuesday, February 24, 2015 at 3:47:12 PM UTC-6, Seth wrote:
>
> I was surprised to find that there is no method on sizehint! for sparse 
> matrices:
>
> ERROR: MethodError: `sizehint!` has no method matching sizehint!(::Base.
> SparseMatrix.SparseMatrixCSC{Int64,Int64}, ::Int64)
>
>
> Is this intentional? I noticed that insert performance on sparse matrices (
> setindex! in particular) is the bottleneck in my code, and I was hoping 
> to optimize a bit more.
>

sizehint! could be applied to the .rowval and .nzval fields but it will 
only make things easier if you then add elements to the last columns.  Even 
if the vectors don't need to be resized, adding a non-zero value to an 
interior column of a sparse matrix requires inserting in the middle of a 
vector.

If it makes sense in your application you are better off using nonzeros to 
get the triplet representation, pushing values onto the end of those 
vectors and, when you are finished, using sparse to convert back to 
SparseMatrixCSC.  

[julia-users] Does sizehint! make sense for sparse matrices?

[Seth]

I was surprised to find that there is no method on sizehint! for sparse 
matrices:

ERROR: MethodError: `sizehint!` has no method matching sizehint!(::Base.
SparseMatrix.SparseMatrixCSC{Int64,Int64}, ::Int64)


Is this intentional? I noticed that insert performance on sparse matrices (
setindex! in particular) is the bottleneck in my code, and I was hoping to 
optimize a bit more.

[julia-users] Re: Making optional fields of unknown type more efficient

[Ben Ward]

I've thought about it a bit, and I wonder if this is a better solution 
instead of expecting nodes of the tree structure to be able to work with 
many different possible types, rather using dictionaries that pair a set of 
nodes with one type of data are better:

type TreeAnnotations{T}
 x::Phylogeny
 dict::Dict{PhyNode, T}
end

So if you have a load of DNA data, you could annotate the tree by having 
the dict associate PhyNodes with Ts - in this case DNA sequence types.
Then if you had some other data like comments, you'd make another such 
dictionary, where T would be String, and so on.

Best,
Ben.

On Tuesday, February 24, 2015 at 1:30:57 AM UTC, Ben Ward 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.
>

[julia-users] Re: splice! function. Instead of removing a single item, remove a collection of items stored in an array.

[Patrick O'Leary]

On Monday, February 23, 2015 at 9:08:46 PM UTC-6, Aero_flux wrote:
>
> Restarting Julia, adding functions and running @time gives a longer 
> elapsed time for both. Rerunning @time returns tiny values.
>

The first time you run a Julia method with a given set of argument types, 
you incur the cost of compilation. On subsequent invocations, you get 
cached, already compiled code.

Patrick

Re: [julia-users] linking Julia with C to improve performances

[Stefan Karpinski]

On Tue, Feb 24, 2015 at 8:03 AM, Tim Holy  wrote:

> Giovanni,
>
> Before you start going to that kind of effort, take a look at
>
> julia> @code_native 3+5
> .text
> Filename: int.jl
> Source line: 12
> pushRBP
> mov RBP, RSP
> Source line: 12
> add RDI, RSI
> mov RAX, RDI
> pop RBP
> ret
>
> I think you're going to have a pretty hard time finding a C compiler that
> does
> better than this :-). Especially since it gets inlined at the call site.
>

Not only is a C compiler not going to do better than this, but if you take
things like adding two numbers and put them inside a C function, then you
can only call that code by a call instruction, which is significantly more
costly than actually doing the addition. There are many situations where
you get the opposite effect: by moving code into Julia from C, the code can
be inlined and specialized, making it significantly faster. In general, if
properly written Julia code is slower than C, the solution is not to
rewrite it in C, but to fix whatever is making Julia slower than C.

Re: [julia-users] Re: Constructing matrices

[Bill Hart]

Julia distinguishes between them at the level of types, yes. I was talking
about the syntax for creating them. There they become conflated.

[1; 2; 3] is precisely the same thing as [1, 2, 3]

Sorry for not being clearer about that.

It's clear this is done intentionally, not accidentally. It's just
extremely confusing and I'll bet it will bite somewhere down the track.
It's especially bad for metaprogramming for example.

Bill.

On 24 February 2015 at 20:39, David P. Sanders  wrote:

>
>
> El martes, 24 de febrero de 2015, 8:18:28 (UTC-6), Bill Hart escribió:
>>
>> The specific use case where I hit this as a problem is in wrapping
>> external libraries like flint and pari, which unlike julia do not conflate
>> 1xn matrices with flat arrays.
>>
>> However, I have just realised that Julia only conflates column vectors
>> with flat arrays, not row vectors.
>>
>
> That is not my interpretation. Julia carefully distinguishes between the
> different options:
>
> (i) a 1D object (which could be called a "vector"), i.e. with 1 index
> (what I understand you mean by "flat array"):
>
> julia> v = [3, 4, 5, 6]
> 4-element Array{Int64,1}:
>  3
>  4
>  5
>  6
>
> This is (unfortunately?) displayed in a column, but is just a
> one-dimensional list of things.
>
> (ii) A matrix object of size  1 x n  (which could be called a "row
> vector", but is actually a matrix):
>
> julia> w = [3 4 5 6]
> 1x4 Array{Int64,2}:
>  3  4  5  6
>
> (iii) A matrix of size  n x 1   (which could be called a "column vector",
> but is actually a matrix):
> julia> z = reshape([3, 4, 5, 6], (4,1))
> 4x1 Array{Int64,2}:
>  3
>  4
>  5
>  6
>
> (The output looks superficially the same as that for v, but the object is
> of a different type -- Array{Int64, 2} vs. Array{Int64, 1}. I.e. there are
> now *two* indices.)
>
> I do not find the nomenclature "row vector" and "column vector" useful in
> this (or almost any other!) context.
>
> David.
>
>
>
>>
>> Therefore I can overload my constructor for the external flint and pari
>> types to interpret Julia flat arrays as column vectors. Fortunately, I only
>> need to do that in one place. I can't imagine overloading every single
>> function for every possible combination of flat array vs matrix for each
>> parameter to the function.
>>
>> The only reason I did things that way is because I initially thought
>> Julia arrays had cartesian product semantics (pointwise operations) rather
>> than matrix semantics.
>>
>> So actually, I guess I can live with the way things are right now.
>>
>> On 24 February 2015 at 14:29, Jiahao Chen  wrote:
>>
>>> Clearly Julia wants to deliberately conflate row and column vectors,
 which is fine if you aren't working with an algorithm that depends on the
 individual dimensions of your matrices, and you aren't interfacing to an
 external library.

>>>
>>> Could you elaborate on what you mean here? As part of Issue #4474 I've
>>> been trying to collect specific examples.
>>>
>>
>>

Re: [julia-users] Re: Constructing matrices

[David P. Sanders]

El martes, 24 de febrero de 2015, 8:18:28 (UTC-6), Bill Hart escribió:
>
> The specific use case where I hit this as a problem is in wrapping 
> external libraries like flint and pari, which unlike julia do not conflate 
> 1xn matrices with flat arrays.
>
> However, I have just realised that Julia only conflates column vectors 
> with flat arrays, not row vectors.
>

That is not my interpretation. Julia carefully distinguishes between the 
different options:

(i) a 1D object (which could be called a "vector"), i.e. with 1 index (what 
I understand you mean by "flat array"):

julia> v = [3, 4, 5, 6]
4-element Array{Int64,1}:
 3
 4
 5
 6

This is (unfortunately?) displayed in a column, but is just a 
one-dimensional list of things.

(ii) A matrix object of size  1 x n  (which could be called a "row vector", 
but is actually a matrix):

julia> w = [3 4 5 6]
1x4 Array{Int64,2}:
 3  4  5  6

(iii) A matrix of size  n x 1   (which could be called a "column vector", 
but is actually a matrix):
julia> z = reshape([3, 4, 5, 6], (4,1)) 
4x1 Array{Int64,2}:
 3
 4
 5
 6

(The output looks superficially the same as that for v, but the object is 
of a different type -- Array{Int64, 2} vs. Array{Int64, 1}. I.e. there are 
now *two* indices.)

I do not find the nomenclature "row vector" and "column vector" useful in 
this (or almost any other!) context.

David.

 

>
> Therefore I can overload my constructor for the external flint and pari 
> types to interpret Julia flat arrays as column vectors. Fortunately, I only 
> need to do that in one place. I can't imagine overloading every single 
> function for every possible combination of flat array vs matrix for each 
> parameter to the function.
>
> The only reason I did things that way is because I initially thought Julia 
> arrays had cartesian product semantics (pointwise operations) rather than 
> matrix semantics.
>
> So actually, I guess I can live with the way things are right now. 
>
> On 24 February 2015 at 14:29, Jiahao Chen > 
> wrote:
>
>> Clearly Julia wants to deliberately conflate row and column vectors, 
>>> which is fine if you aren't working with an algorithm that depends on the 
>>> individual dimensions of your matrices, and you aren't interfacing to an 
>>> external library.
>>>
>>
>> Could you elaborate on what you mean here? As part of Issue #4474 I've 
>> been trying to collect specific examples. 
>>
>
>

Re: [julia-users] linking Julia with C to improve performances

[Steven G. Johnson]

On Tuesday, February 24, 2015 at 8:25:30 AM UTC-5, Bill Hart wrote:
>
> So long as your shared library has no other dependencies, you can set 
> Julia's DL_LOAD_PATH to specify the location of the shared library (I'm not 
> sure if this is considered best practice or not)
>

Best practice (in a package) is to just compute the absolute path of the 
shared library and use that in ccall; this is what BinDeps does.

[julia-users] Re: How to store the state of current rand generator (not set the seed)

[Simon Byrne]

That is a good idea and something we are working toward. Unfortunately 
situation is a bit complicated at the moment: in the 0.4 branch, there are 
actually 2 RNGs operating side-by-side (one for Base rand methods, and for 
the Rmath library used by Distributions). Hopefully this can get resolved 
soon, as we do want to make these sort of stateful computations clearer and 
easier to work with.

Simon


On Tuesday, 24 February 2015 16:41:24 UTC, Steve Kay wrote:
>
> Many thanks for your replies Simon and Jameson.
>
> From my perspective it would be great if Julia could replicate the python 
> functions random.getstate(), random.setstate(state) amd 
> random.jumpahead(n) on https://docs.python.org/2/library/random.html .
>
> My trouble with your suggestion Jameson is my strategies will be drawing 
> from different distributions ( e.g poisson for one, normal for another). I 
> realise I could use inverse CDF method on unif draws (but thought this 
> would take longer to run than simply drawing from the correct distributions 
> (maybe I'm wrong). Thanks again.
>
> Steve
>
> On Monday, February 23, 2015 at 5:02:01 PM UTC, Steve Kay 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: ERROR: `checked_mul` has no method matching checked_mul(::Int64, ::Base.GMP.BigInt)

[Ismael VC]

Done: https://github.com/JuliaLang/julia/issues/10311

El martes, 24 de febrero de 2015, 10:58:15 (UTC-6), Ismael VC escribió:
>
> Hello every one! 
>
> This only fails in v0.4.0-dev+ this is the log:
>
>
>- https://travis-ci.org/Ismael-VC/AHN.jl/jobs/51998218
>
>
> Here it is in v0.3.6:
>
>
>- https://travis-ci.org/Ismael-VC/AHN.jl/jobs/51998217
>
> And here is my test file`:
>
>
>- 
>https://github.com/Ismael-VC/AHN.jl/blob/master/test/atomic_tests.jl#L5
>
>
> I have narrowed down to this:
>
> julia> versioninfo()
> Julia Version 0.4.0-dev+3353
> Commit 0179028* (2015-02-14 17:08 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i3 CPU   M 350  @ 2.27GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> julia> nums_data = [
>(int8(n), Int8),
>(uint8(n), UInt8),
>(int16(n), Int16),
>(uint16(n), UInt16),
>(int32(n), Int32),
>(uint32(n), UInt32),
>(int64(n), Int64),
>(uint64(n), UInt64),
>(int128(n), Int128),
>(uint128(n), UInt128),
>(true, Bool),
>(complex(true, true), Bool),
>(float16(n), Float16),
>(float32(n), Float32),
>(float64(n), Float64),
>(BigInt(n), BigInt),
>(BigFloat(n), BigFloat),
>(n//n, Rational{Int}),
>(n//n + n//big(n)*im, Rational{BigInt}),
>(n+n*im, Int),
>(Inf*im, Float64)
>]
> ERROR: MethodError: `checked_mul` has no method matching 
> checked_mul(::Int64, ::
> LastMain.LastMain.Base.GMP.BigInt)
> Closest candidates are:
>   checked_mul(::Int64, ::Int64)
>   checked_mul(::LastMain.LastMain.Base.GMP.BigInt, 
> ::LastMain.LastMain.Base.GMP.
> BigInt)
>
>  in + at rational.jl:166
>  in + at complex.jl:118
>
>
> It doesn't mater if I use `Compat` or not.
>

[julia-users] Re: ERROR: `checked_mul` has no method matching checked_mul(::Int64, ::Base.GMP.BigInt)

[Ismael VC]

I will Stefan, thanks!

El martes, 24 de febrero de 2015, 10:58:15 (UTC-6), Ismael VC escribió:
>
> Hello every one! 
>
> This only fails in v0.4.0-dev+ this is the log:
>
>
>- https://travis-ci.org/Ismael-VC/AHN.jl/jobs/51998218
>
>
> Here it is in v0.3.6:
>
>
>- https://travis-ci.org/Ismael-VC/AHN.jl/jobs/51998217
>
> And here is my test file`:
>
>
>- 
>https://github.com/Ismael-VC/AHN.jl/blob/master/test/atomic_tests.jl#L5
>
>
> I have narrowed down to this:
>
> julia> versioninfo()
> Julia Version 0.4.0-dev+3353
> Commit 0179028* (2015-02-14 17:08 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i3 CPU   M 350  @ 2.27GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> julia> nums_data = [
>(int8(n), Int8),
>(uint8(n), UInt8),
>(int16(n), Int16),
>(uint16(n), UInt16),
>(int32(n), Int32),
>(uint32(n), UInt32),
>(int64(n), Int64),
>(uint64(n), UInt64),
>(int128(n), Int128),
>(uint128(n), UInt128),
>(true, Bool),
>(complex(true, true), Bool),
>(float16(n), Float16),
>(float32(n), Float32),
>(float64(n), Float64),
>(BigInt(n), BigInt),
>(BigFloat(n), BigFloat),
>(n//n, Rational{Int}),
>(n//n + n//big(n)*im, Rational{BigInt}),
>(n+n*im, Int),
>(Inf*im, Float64)
>]
> ERROR: MethodError: `checked_mul` has no method matching 
> checked_mul(::Int64, ::
> LastMain.LastMain.Base.GMP.BigInt)
> Closest candidates are:
>   checked_mul(::Int64, ::Int64)
>   checked_mul(::LastMain.LastMain.Base.GMP.BigInt, 
> ::LastMain.LastMain.Base.GMP.
> BigInt)
>
>  in + at rational.jl:166
>  in + at complex.jl:118
>
>
> It doesn't mater if I use `Compat` or not.
>

[julia-users] Re: ERROR: `checked_mul` has no method matching checked_mul(::Int64, ::Base.GMP.BigInt)

[Ismael VC]

0.3.6:

julia> n//n + n//big(n)*im
1//1 + 1//1*im

0.4.0-dev+:

julia> n//n + n//big(n)*im
ERROR: MethodError: `checked_mul` has no method matching 
checked_mul(::Int64, ::
LastMain.LastMain.LastMain.Base.GMP.BigInt)
Closest candidates are:
  checked_mul(::Int64, ::Int64)
  checked_mul(::LastMain.LastMain.LastMain.Base.GMP.BigInt, 
::LastMain.LastMain.
LastMain.Base.GMP.BigInt)

 in + at rational.jl:166
 in + at complex.jl:118



El martes, 24 de febrero de 2015, 10:58:15 (UTC-6), Ismael VC escribió:
>
> Hello every one! 
>
> This only fails in v0.4.0-dev+ this is the log:
>
>
>- https://travis-ci.org/Ismael-VC/AHN.jl/jobs/51998218
>
>
> Here it is in v0.3.6:
>
>
>- https://travis-ci.org/Ismael-VC/AHN.jl/jobs/51998217
>
> And here is my test file`:
>
>
>- 
>https://github.com/Ismael-VC/AHN.jl/blob/master/test/atomic_tests.jl#L5
>
>
> I have narrowed down to this:
>
> julia> versioninfo()
> Julia Version 0.4.0-dev+3353
> Commit 0179028* (2015-02-14 17:08 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i3 CPU   M 350  @ 2.27GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
> julia> nums_data = [
>(int8(n), Int8),
>(uint8(n), UInt8),
>(int16(n), Int16),
>(uint16(n), UInt16),
>(int32(n), Int32),
>(uint32(n), UInt32),
>(int64(n), Int64),
>(uint64(n), UInt64),
>(int128(n), Int128),
>(uint128(n), UInt128),
>(true, Bool),
>(complex(true, true), Bool),
>(float16(n), Float16),
>(float32(n), Float32),
>(float64(n), Float64),
>(BigInt(n), BigInt),
>(BigFloat(n), BigFloat),
>(n//n, Rational{Int}),
>(n//n + n//big(n)*im, Rational{BigInt}),
>(n+n*im, Int),
>(Inf*im, Float64)
>]
> ERROR: MethodError: `checked_mul` has no method matching 
> checked_mul(::Int64, ::
> LastMain.LastMain.Base.GMP.BigInt)
> Closest candidates are:
>   checked_mul(::Int64, ::Int64)
>   checked_mul(::LastMain.LastMain.Base.GMP.BigInt, 
> ::LastMain.LastMain.Base.GMP.
> BigInt)
>
>  in + at rational.jl:166
>  in + at complex.jl:118
>
>
> It doesn't mater if I use `Compat` or not.
>

Re: [julia-users] ERROR: `checked_mul` has no method matching checked_mul(::Int64, ::Base.GMP.BigInt)

[Stefan Karpinski]

Would you mind opening an issue?


> On Feb 24, 2015, at 11:58 AM, Ismael VC  wrote:
> 
> Hello every one! 
> 
> This only fails in v0.4.0-dev+ this is the log:
> 
> https://travis-ci.org/Ismael-VC/AHN.jl/jobs/51998218
> 
> Here it is in v0.3.6:
> 
> https://travis-ci.org/Ismael-VC/AHN.jl/jobs/51998217
> And here is my test file`:
> 
> https://github.com/Ismael-VC/AHN.jl/blob/master/test/atomic_tests.jl#L5
> 
> I have narrowed down to this:
> 
> julia> versioninfo()
> Julia Version 0.4.0-dev+3353
> Commit 0179028* (2015-02-14 17:08 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i3 CPU   M 350  @ 2.27GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
> 
> julia> nums_data = [
>(int8(n), Int8),
>(uint8(n), UInt8),
>(int16(n), Int16),
>(uint16(n), UInt16),
>(int32(n), Int32),
>(uint32(n), UInt32),
>(int64(n), Int64),
>(uint64(n), UInt64),
>(int128(n), Int128),
>(uint128(n), UInt128),
>(true, Bool),
>(complex(true, true), Bool),
>(float16(n), Float16),
>(float32(n), Float32),
>(float64(n), Float64),
>(BigInt(n), BigInt),
>(BigFloat(n), BigFloat),
>(n//n, Rational{Int}),
>(n//n + n//big(n)*im, Rational{BigInt}),
>(n+n*im, Int),
>(Inf*im, Float64)
>]
> ERROR: MethodError: `checked_mul` has no method matching checked_mul(::Int64, 
> ::
> LastMain.LastMain.Base.GMP.BigInt)
> Closest candidates are:
>   checked_mul(::Int64, ::Int64)
>   checked_mul(::LastMain.LastMain.Base.GMP.BigInt, 
> ::LastMain.LastMain.Base.GMP.
> BigInt)
> 
>  in + at rational.jl:166
>  in + at complex.jl:118
> 
> 
> It doesn't mater if I use `Compat` or not.

[julia-users] ERROR: `checked_mul` has no method matching checked_mul(::Int64, ::Base.GMP.BigInt)

[Ismael VC]

Hello every one! 

This only fails in v0.4.0-dev+ this is the log:


   - https://travis-ci.org/Ismael-VC/AHN.jl/jobs/51998218
   

Here it is in v0.3.6:


   - https://travis-ci.org/Ismael-VC/AHN.jl/jobs/51998217
   
And here is my test file`:


   - https://github.com/Ismael-VC/AHN.jl/blob/master/test/atomic_tests.jl#L5


I have narrowed down to this:

julia> versioninfo()
Julia Version 0.4.0-dev+3353
Commit 0179028* (2015-02-14 17:08 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i3 CPU   M 350  @ 2.27GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

julia> nums_data = [
   (int8(n), Int8),
   (uint8(n), UInt8),
   (int16(n), Int16),
   (uint16(n), UInt16),
   (int32(n), Int32),
   (uint32(n), UInt32),
   (int64(n), Int64),
   (uint64(n), UInt64),
   (int128(n), Int128),
   (uint128(n), UInt128),
   (true, Bool),
   (complex(true, true), Bool),
   (float16(n), Float16),
   (float32(n), Float32),
   (float64(n), Float64),
   (BigInt(n), BigInt),
   (BigFloat(n), BigFloat),
   (n//n, Rational{Int}),
   (n//n + n//big(n)*im, Rational{BigInt}),
   (n+n*im, Int),
   (Inf*im, Float64)
   ]
ERROR: MethodError: `checked_mul` has no method matching 
checked_mul(::Int64, ::
LastMain.LastMain.Base.GMP.BigInt)
Closest candidates are:
  checked_mul(::Int64, ::Int64)
  checked_mul(::LastMain.LastMain.Base.GMP.BigInt, 
::LastMain.LastMain.Base.GMP.
BigInt)

 in + at rational.jl:166
 in + at complex.jl:118


It doesn't mater if I use `Compat` or not.

[julia-users] Re: SAVE THE DATE: JuliaCon 2015, June 24 - 28

[Hunter Owens]

Yup! We're shooting for roughly ~March 15th, but we will post on 
julia-users when registration is available. 

On Monday, February 23, 2015 at 6:02:42 PM UTC-6, Carlo di Celico wrote:
>
> 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: How to store the state of current rand generator (not set the seed)

[Steve Kay]

Many thanks for your replies Simon and Jameson.

>From my perspective it would be great if Julia could replicate the python 
functions random.getstate(), random.setstate(state) amd random.jumpahead(n) on 
https://docs.python.org/2/library/random.html .

My trouble with your suggestion Jameson is my strategies will be drawing 
from different distributions ( e.g poisson for one, normal for another). I 
realise I could use inverse CDF method on unif draws (but thought this 
would take longer to run than simply drawing from the correct distributions 
(maybe I'm wrong). Thanks again.

Steve

On Monday, February 23, 2015 at 5:02:01 PM UTC, Steve Kay 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
>

Re: [julia-users] Mutate C struct represented as Julia immutable

[J Luis]

use unsafe_load() to convert the value to a julia object, then 
> unsafe_store() to write the new struct back.
>
> at some point, I want to modify unsafe_load/unsafe_store to take a 
> fieldname symbol as the second argument to make this functionality more 
> direct available. however, there hasn't seemed to be a request / issue open 
> for it yet.
>

PLEASE, do.

I have the same type of problem but I'm not able to solve it with the 
solutions proposed in this thread.
See, I have this and want to change the *rgb_low*

julia> gmt_lut = unsafe_load(C.range, 1);

julia> gmt_lut.rgb_low
GMT.Array_4_Cdouble(0.583,0.0,1.0,0.0)

which is a

immutable Array_4_Cdouble
d1::Cdouble
d2::Cdouble
d3::Cdouble
d4::Cdouble
end

so I do 

julia> z = GMT.Array_4_Cdouble(0.0, 0.0, 0.0, 0.0)
GMT.Array_4_Cdouble(0.0,0.0,0.0,0.0)

julia> unsafe_store!(pointer([gmt_lut.rgb_low]), z)
Ptr{GMT.Array_4_Cdouble} @0x819faf60

no errors but I don't know where new *z* immutable landed on because I keep 
seeing the old value

julia> gmt_lut.rgb_low
GMT.Array_4_Cdouble(0.583,0.0,1.0,0.0)

I suspect part of it is dues to the pointer([gmt_lut.rgb_low]) command  
because when I do several of those on line I keep getting different 
addresses

julia> pointer([gmt_lut.rgb_low])
Ptr{GMT.Array_4_Cdouble} @0x82b7baf0

julia> pointer([gmt_lut.rgb_low])
Ptr{GMT.Array_4_Cdouble} @0x82ba00d0

julia> pointer([gmt_lut.rgb_low])
Ptr{GMT.Array_4_Cdouble} @0x82ba0670

but than how can modify this field(s)?



 

Re: [julia-users] Bokeh.jl update released: call for feedback

[Simon Danisch]

Well, sticking to the Cairo API is not an option, quite frankly.
I want to create something completely interactive at high speeds. I want to
see, if I can actually compile parts of my event tree completely to the GPU
and directly manipulate the points of, e.g. a rendered path, in GPU memory.
Which is far, far away from Cairo's approach (and actually any approach
I've seen so far).
If there is a demand for exporting other formats, which Cairo is really
great at, I much rather go for a thin wrapper, that can translate my calls
into Cairo calls.

To give you a context and a better understanding from where I come from:
I want visual debugging and interactive programming and at some future
point in time 2D/3D manipulation capabilities comparable to Illustrator or
3DS Max.
This is very hard to achieve if you have 1 million paths, or 2 billion
triangles. Definitely not achievable with Cairo or what not.
So while this is great stuff for the scientific community in terms of
scalability, it's not immediately useful.
Most scientists will be perfectly fine with something slower, as long as it
has a lot of features ;)


2015-02-24 16:10 GMT+01:00 Andreas Lobinger :

> Hello collea
>
> *gue,*
>
> On Tuesday, February 24, 2015 at 11:17:44 AM UTC+1, Eric Forgy wrote:
>>
>> On Tuesday, February 24, 2015 at 3:19:17 AM UTC+8, Samuel Colvin wrote:
>>>
>>> (and saying someone mildly antagonistic to kick off some debate, sorry).
>>>
>>
>> Hehe. I can't resist :)
>>
>> 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.
>>
>>
>> I looked at the whole canvas vs SVG thing and went with d3 for my
>> visualizations. Depending on your application, SVG can also be fast. Here
>> is a nice comparison: When to Use  and when to Use SVG: The
>> Scenarios
>> 
>> .
>>
>> Particularly for web-based visualizations, I really want things to come
>> alive, i.e. be dynamic and interactive. And as Tim was looking for, it is
>> very simple to have an interaction with d3 launch some Julia code
>> asynchronously.
>>
>> PS: TIm, if you ever have some free time to play around with javascript,
>> I think you may like it. I come from 20+ years of Matlab with a bit of Java
>> thrown in here and there, but have been learning javascript since August
>> and love it. The old perceptions of it being slow are... well... old :)
>> Even the Julia benchmark shows javascript approaching Julia speeds.
>> Javascript is also fun because with little clue, you can hack something
>> together easily, but the deeper you go, the more satisfying it can be.
>>
>> Well the point isn't that JS is still an inferior langauage or that SVG
> cannot be considered a drawing API (which is true in some sense), the
> problem is, you are creating a large dependency as you assume an engine
> that can execute JS AND at the same time has access to a rendering engine.
> Yes i agree on recent systems a browser is usually available, but even in
> browser-world they come in different flavours.
>
>
>

Re: [julia-users] Bokeh.jl update released: call for feedback

[Samuel Colvin]

I've just read you post and done a double take.

You're suggesting in the medium term future that the only browsers
available will either not be able to execute js or won't have a rendering
engine? Seriously?

So in 2018 people will be browsing the internet using only Lynx?

Yes there are different browsers but all the major ones implement
javascript, SVG and canvas. Also Chrome (which has the richest feature set
of all) is available for all platforms. You can't really write off web
technology because 0.4% of people still have IE6.

Many of the concerns raised above to my proposition make a lot of sense,
but this one seems pretty bizarre to me.



--

Samuel Colvin
s...@muelcolvin.com,
07801160713

On 24 February 2015 at 15:10, Andreas Lobinger  wrote:

> Hello collea
>
> *gue,*
>
> On Tuesday, February 24, 2015 at 11:17:44 AM UTC+1, Eric Forgy wrote:
>>
>> On Tuesday, February 24, 2015 at 3:19:17 AM UTC+8, Samuel Colvin wrote:
>>>
>>> (and saying someone mildly antagonistic to kick off some debate, sorry).
>>>
>>
>> Hehe. I can't resist :)
>>
>> 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.
>>
>>
>> I looked at the whole canvas vs SVG thing and went with d3 for my
>> visualizations. Depending on your application, SVG can also be fast. Here
>> is a nice comparison: When to Use  and when to Use SVG: The
>> Scenarios
>> 
>> .
>>
>> Particularly for web-based visualizations, I really want things to come
>> alive, i.e. be dynamic and interactive. And as Tim was looking for, it is
>> very simple to have an interaction with d3 launch some Julia code
>> asynchronously.
>>
>> PS: TIm, if you ever have some free time to play around with javascript,
>> I think you may like it. I come from 20+ years of Matlab with a bit of Java
>> thrown in here and there, but have been learning javascript since August
>> and love it. The old perceptions of it being slow are... well... old :)
>> Even the Julia benchmark shows javascript approaching Julia speeds.
>> Javascript is also fun because with little clue, you can hack something
>> together easily, but the deeper you go, the more satisfying it can be.
>>
>> Well the point isn't that JS is still an inferior langauage or that SVG
> cannot be considered a drawing API (which is true in some sense), the
> problem is, you are creating a large dependency as you assume an engine
> that can execute JS AND at the same time has access to a rendering engine.
> Yes i agree on recent systems a browser is usually available, but even in
> browser-world they come in different flavours.
>
>
>

Re: [julia-users] Re: Equivalent of MATLAB struct with subfields and constant values

[Milan Bouchet-Valat]

Le mardi 24 février 2015 à 07:03 -0800, Pooya a écrit :
> Thanks for your suggestion. DataFrames should work well for my
> application. I am not sure about the differences of NamedArrays and
> DataFrames. I can see that in NamedArrays one can name rows as well.
> Is that all? Or are there other reasons why one might use one instead
> of the other?
That's kind of the same difference as between DataArray and DataFrame. a
NamedArray simply wraps an array by adding names to it, while a
DataFrame is a set of vectors which have each their own element type.
DataFrames are intended for database-like data, while arrays are useful
when you want to use matrix algebra and things like that.


Regards

> On Saturday, February 21, 2015 at 5:08:44 AM UTC-5, Milan Bouchet-Valat wrote:
> Le vendredi 20 février 2015 à 22:26 -0800, Viral Shah a écrit : 
> > You could explore DataArrays. 
> > https://github.com/JuliaStats/DataArrays.jl 
> I guess you mean DataFrames? Indeed, the column names would provide 
> the 
> equivalent of your variables/subfields. 
> 
> flows.out wouldn't be possible, but you can always create a names 
> like 
> flows_out, flows_in... to keep a mental representation of categories. 
> Is 
> that enough for you? 
> 
> > If you do not need to otherwise manipulate the whole array directly 
> > (like say do an svd on the 100x30 matrix), and only work with the 
> > fields, it would be best to create a composite type with those 
> field 
> > names. 
> OTOH if you need a real array, not a set of columns, you can explore 
> NamedArrays instead of DataFrames. 
> 
> 
> Regards 
> 
> > -viral 
> > 
> > On Saturday, February 21, 2015 at 7:18:24 AM UTC+5:30, Pooya wrote: 
> > Hi there, 
> > 
> > 
> > I am new to Julia, trying to transfer all I do from MATLAB 
> to 
> > Julia. I have a bunch of matrices of numerical data (say 
> > 100x30). In order to keep track of what each column is 
> > representing, I defined different variables (say flows) 
> whose 
> > values were the associated column number in MATLAB. Now I 
> can 
> > use data(:,flows) instead of data(:,X), so I don't need to 
> > worry about the column orders and numbers every time I need 
> to 
> > use the data. In order to avoid mistakes I was using 
> "struct" 
> > in MATLAB to avoid introducing many new variables into each 
> > code that I have. Then all those constant values (column 
> > numbers) were defined in a function (say myconstants) and 
> when 
> > I needed to use them, I would just say C = myconstants, and 
> > then use C.flow for the column number. The problem is that 
> > there are a few categories of these constants, and they all 
> > have subfields with meaningful names and values 
> representing 
> > the column number in each matrix of data. In MATLAB all I 
> > needed to define these was for example, C.flows.out = 5. 
> > 
> > 
> > I am now thinking of the best way to handle this in Julia. 
> I 
> > have learnt a bit about immutable composite types. But 
> first, 
> > because they do not accept default values, the code will be 
> > very messy with a lot of different fields. I am also not 
> sure 
> > if you can define the fields of an immutable to be an 
> > immutable type itself. Is that possible? Any ideas on 
> better 
> > ways to handle this situation? In addition, if I use 
> composite 
> > types it seems that I am using a very powerful thing 
> > (composite types) for a very basic application! Any 
> thoughts 
> > are greatly appreciated. 
> > 
> > 
> > Thanks, 
> > Pooya 
> 

Re: [julia-users] Bokeh.jl update released: call for feedback

[Andreas Lobinger]

Hello collea

*gue,*
On Tuesday, February 24, 2015 at 11:17:44 AM UTC+1, Eric Forgy wrote:
>
> On Tuesday, February 24, 2015 at 3:19:17 AM UTC+8, Samuel Colvin wrote:
>>
>> (and saying someone mildly antagonistic to kick off some debate, sorry).
>>
>
> Hehe. I can't resist :)
>
> 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.
>
>
> I looked at the whole canvas vs SVG thing and went with d3 for my 
> visualizations. Depending on your application, SVG can also be fast. Here 
> is a nice comparison: When to Use  and when to Use SVG: The 
> Scenarios 
> 
> .
>
> Particularly for web-based visualizations, I really want things to come 
> alive, i.e. be dynamic and interactive. And as Tim was looking for, it is 
> very simple to have an interaction with d3 launch some Julia code 
> asynchronously.
>
> PS: TIm, if you ever have some free time to play around with javascript, I 
> think you may like it. I come from 20+ years of Matlab with a bit of Java 
> thrown in here and there, but have been learning javascript since August 
> and love it. The old perceptions of it being slow are... well... old :) 
> Even the Julia benchmark shows javascript approaching Julia speeds. 
> Javascript is also fun because with little clue, you can hack something 
> together easily, but the deeper you go, the more satisfying it can be.
>
> Well the point isn't that JS is still an inferior langauage or that SVG 
cannot be considered a drawing API (which is true in some sense), the 
problem is, you are creating a large dependency as you assume an engine 
that can execute JS AND at the same time has access to a rendering engine. 
Yes i agree on recent systems a browser is usually available, but even in 
browser-world they come in different flavours. 

Re: [julia-users] Re: Equivalent of MATLAB struct with subfields and constant values

[Pooya]

Thanks for your suggestion. DataFrames should work well for my application. 
I am not sure about the differences of NamedArrays and DataFrames. I can 
see that in NamedArrays one can name rows as well. Is that all? Or are 
there other reasons why one might use one instead of the other?

On Saturday, February 21, 2015 at 5:08:44 AM UTC-5, Milan Bouchet-Valat 
wrote:
>
> Le vendredi 20 février 2015 à 22:26 -0800, Viral Shah a écrit : 
> > You could explore DataArrays. 
> > https://github.com/JuliaStats/DataArrays.jl 
> I guess you mean DataFrames? Indeed, the column names would provide the 
> equivalent of your variables/subfields. 
>
> flows.out wouldn't be possible, but you can always create a names like 
> flows_out, flows_in... to keep a mental representation of categories. Is 
> that enough for you? 
>
> > If you do not need to otherwise manipulate the whole array directly 
> > (like say do an svd on the 100x30 matrix), and only work with the 
> > fields, it would be best to create a composite type with those field 
> > names. 
> OTOH if you need a real array, not a set of columns, you can explore 
> NamedArrays instead of DataFrames. 
>
>
> Regards 
>
> > -viral 
> > 
> > On Saturday, February 21, 2015 at 7:18:24 AM UTC+5:30, Pooya wrote: 
> > Hi there, 
> > 
> > 
> > I am new to Julia, trying to transfer all I do from MATLAB to 
> > Julia. I have a bunch of matrices of numerical data (say 
> > 100x30). In order to keep track of what each column is 
> > representing, I defined different variables (say flows) whose 
> > values were the associated column number in MATLAB. Now I can 
> > use data(:,flows) instead of data(:,X), so I don't need to 
> > worry about the column orders and numbers every time I need to 
> > use the data. In order to avoid mistakes I was using "struct" 
> > in MATLAB to avoid introducing many new variables into each 
> > code that I have. Then all those constant values (column 
> > numbers) were defined in a function (say myconstants) and when 
> > I needed to use them, I would just say C = myconstants, and 
> > then use C.flow for the column number. The problem is that 
> > there are a few categories of these constants, and they all 
> > have subfields with meaningful names and values representing 
> > the column number in each matrix of data. In MATLAB all I 
> > needed to define these was for example, C.flows.out = 5. 
> > 
> > 
> > I am now thinking of the best way to handle this in Julia. I 
> > have learnt a bit about immutable composite types. But first, 
> > because they do not accept default values, the code will be 
> > very messy with a lot of different fields. I am also not sure 
> > if you can define the fields of an immutable to be an 
> > immutable type itself. Is that possible? Any ideas on better 
> > ways to handle this situation? In addition, if I use composite 
> > types it seems that I am using a very powerful thing 
> > (composite types) for a very basic application! Any thoughts 
> > are greatly appreciated. 
> > 
> > 
> > Thanks, 
> > Pooya 
>
>

[julia-users] Re: Bokeh.jl update released: call for feedback

[Andreas Lobinger]

[Note to myself: Choose carefully in which window to press the post button.]

...Again...
So if i can make a suggestion for you project: Try to stay as close as 
possible to the Cairo API. 
There are already too many (fast) 2D drawing APIs around. And people keep 
inventing (e.g. https://www.bassi.io/articles/2014/07/29/guadec-2014-gsk/).

[julia-users] Re: Bokeh.jl update released: call for feedback

[Andreas Lobinger]

Hello colleague,

could you elaborate a little bit on this:

On Monday, February 23, 2015 at 11:21:31 PM UTC+1, Simon Danisch wrote:
>
> 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).
>

afaiu the cairo EGL/OpenGL backend (which is still considered experimental) 
wasn't introduced for speed only, think about the way forward replacing X 
with Wayland.

You have a valid point, that choosing Cairo (which is somehow a standard as 
it's cross system and recently also the basis of GTK rending ) is good move 
for interoperability and interfacing with different other standards (Cairo 
e.g. doesn't render to bitmaps only, you can render to PDFs or SVGs).
At the same time you loose raw rendering speed for local windows. 

So if i can make a suggestion for you project: Try to stay as close as 
possible to the Cairo API. 

[julia-users] Re: Best way to find the directory a package is in

[Scott T]

Steven J has given a partial solution to this here 
: if 
a package wants to know where it is, it should probably use 
dirpath(@__FILE__) to get the location of the file that's doing the work. 
Pkg.dir() still probably needs to be smarter overall, but this at least 
lets me fix the issue with Nettle.

Scott

On Tuesday, 24 February 2015 13:44:45 UTC, Scott T wrote:
>
> Hi all,
>
> I've been playing around with trying to install Julia and some basic 
> packages system-wide to run a workshop for our department in a couple of 
> weeks time. Mostly it's working well, and I'm really excited about seeing 
> what people think!
>
> I ran into the problem that Pkg.dir("PackageName"), although documented as 
> returning the path to a package, doesn't necessarily do this in the right 
> way. In particular, if a user has set up their own .julia directory, doing 
> Pkg.dir("ASharedPackage") returns ~/.julia/v0.x/ASharedPackage even if that 
> folder doesn't exist. 
>
> That is, if JULIA_PKGDIR is not the same as the directory the package is 
> *actually* in, Pkg.dir("Package") won't give the right location.
>
> I hit this problem trying to get IJulia installed for everyone to use, 
> becase one of its dependencies Nettle uses Pkg.dir("Nettle") to find itself 
> when loaded, and so if installed system-wide (in /local/share) it 
> won't work.
>
> So, is there a more reliable way to get the path to a package? 
>
> [Pkg.dir might need to be smarter instead, but that's more a development 
> question. I commented on that here 
> ]
>
> Cheers,
> Scott
>

[julia-users] Re: Best way to find the directory a package is in

[Scott T]

Sorry, that should be dirname(@__FILE__)

Scott

On Tuesday, 24 February 2015 14:36:58 UTC, Scott T wrote:
>
> dirpath(@__FILE__)
>

Re: [julia-users] linking Julia with C to improve performances

[Bill Hart]

On 24 February 2015 at 14:33, Milan Bouchet-Valat  wrote:

> Le mardi 24 février 2015 à 05:25 -0800, Bill Hart a écrit :
> > In answer to your original question, assuming you had a very complex C
> > program that Julia just didn't handle efficiently (it's possible), or
> > you had already written a very large external library which you didn't
> > want to rewrite in Julia, and someone else hasn't already written an
> > interface to it from Julia
> >
> >
> > First you want to make a shared library. For this you can use gcc.
> > First compile your C file to an object file with the -c option. Then
> > link your object file to make a shared library with the -shared
> > option. This will make a shared library (.so or .dll or .dylib,
> > depending on what operating system you have).
> >
> >
> > It's the .so or .dll or .dylib file that Julia wants to be able to
> > find, not the C file.
> >
> >
> > So long as your shared library has no other dependencies, you can set
> > Julia's DL_LOAD_PATH to specify the location of the shared library
> > (I'm not sure if this is considered best practice or not).
> >
> >
> > Otherwise, on most systems the dynamic linker has various places it
> > will look for your library. This depends on your system though, so it
> > varies between Unix, Linux, Windows and OSX.
> This should work, but I think the "best practice" if you need to make
> your code public at some point is to use BinDeps, as explained in the
> thread I linked to. Though if you're the only one to work on it, a few
> hacks to build and locate the library might be enough.
>

It depends on a lot of things. For example, locally, people are getting
very excited about hashdist. So persuading them to use BinDeps may be
somewhat difficult.

For the time being I have persuaded them to support both (when we finally
get around to packaging). But if hashdist goes on in leaps and bounds,
people will want to use that instead.


>
>
> Regards
>
> > On Tuesday, 24 February 2015 14:10:31 UTC+1, Bill Hart wrote:
> > One important thing to note is that if you do a + b at the top
> > level, it won't be fast.
> >
> >
> > But as soon as you do a + b inside a function, it will be as
> > fast as C.
> >
> > For example
> >
> >
> > a = 20
> > b = 10
> > for i = 1:10
> >c = a + b
> > end
> >
> >
> > takes about 34s
> >
> >
> > But the following is almost instantaneous:
> >
> >
> > function doit()
> >a = 20
> >b = 10
> >for i = 1:10
> >   c = a + b
> >end
> > end
> >
> >
> > doit()
> >
> >
> > On Tuesday, 24 February 2015 14:03:07 UTC+1, Tim Holy wrote:
> > Giovanni,
> >
> > Before you start going to that kind of effort, take a
> > look at
> >
> > julia> @code_native 3+5
> > .text
> > Filename: int.jl
> > Source line: 12
> > pushRBP
> > mov RBP, RSP
> > Source line: 12
> > add RDI, RSI
> > mov RAX, RDI
> > pop RBP
> > ret
> >
> > I think you're going to have a pretty hard time
> > finding a C compiler that does
> > better than this :-). Especially since it gets inlined
> > at the call site.
> >
> > Best,
> > --Tim
> >
> > On Tuesday, February 24, 2015 01:13:52 AM
> > giovan...@gmail.com wrote:
> > > Hello,
> > >
> > > I am a beginner to Julia and would like to try out
> > some features. I would
> > > like to improve performances of some bottleneck
> > functions by translating
> > > them into C.
> > > A simple example is :
> > > main.jl
> > >
> > > a ::Int64 = 20
> > > b ::Int64 = 10
> > > ccall(:do_sum, Int64, (Int64, Int64), a, b)
> > >
> > >
> > >
> > > test.c
> > > #include 
> > >
> > > int do_sum (int a,int b)
> > > {
> > > int c;
> > > c = a+b;
> > > printf("f\n:",c);
> > > return c;
> > > }
> > >
> > > where should I put the C file ?
> > >
> > > Thanks,
> > > G.
> >
>
>

Re: [julia-users] Re: linking Julia with C to improve performances

[Bill Hart]

I was aware of this, but I believe good C compilers also do this
optimisation with link time optimisation these days. It's nice to be able
to demonstrate the same behaviour in Julia.

On 24 February 2015 at 14:47, Simon Danisch  wrote:

> @Bill Hart
> small note on your example: you don't return anything, which is why LLVM's
> code elimination jumps in and removes your whole function body, which
> results in a very fast "addition" :P
> Even if you return c, LLVM is smart enough to just precalculate the value
> resulting in doit() = 30 as the method definition.
> Even having doit take a and b as arguments results in doit(a,b) = a+b.
>
> Even this:
> function doit(n)
>c = 0
>for i = 1:n
>   c += i
>end
> end
> gets turned into a constant expression.
> It's actually not that easy, to get the plus benchmark, as it gets heavily
> optimized.
> I think something like this will approximate the time needed better:
> function doit(n)
>bench = 0.0
>for i = 1:n
> a = rand()
> tic()
> a+a
> t = toq()
> bench += t
>end
>bench
> end
> doit(10^6)
> @show doit(10^6)
> doit(10 ^ 6) = 0.09192137800017194
>
> This is actually pretty awesome about Julia, as even someone like me with
> only a small background in computer science is able to find out all these
> things.
> (via @code_llvm, @code_native, etc)
>
> Am Dienstag, 24. Februar 2015 10:13:52 UTC+1 schrieb giovan...@gmail.com:
>>
>> Hello,
>>
>> I am a beginner to Julia and would like to try out some features. I would
>> like to improve performances of some bottleneck functions by translating
>> them into C.
>> A simple example is :
>> main.jl
>>
>> a ::Int64 = 20
>> b ::Int64 = 10
>> ccall(:do_sum, Int64, (Int64, Int64), a, b)
>>
>>
>>
>> test.c
>> #include 
>>
>> int do_sum (int a,int b)
>> {
>> int c;
>> c = a+b;
>> printf("f\n:",c);
>> return c;
>> }
>>
>> where should I put the C file ?
>>
>> Thanks,
>> G.
>>
>>

Re: [julia-users] Making optional fields of unknown type more efficient

[Ben Ward]

I see, I've hardcoded the most common attributes stored in nodes into the
nodes themselves - branch-lengths and confidence values and so on. I can
see this get's mind-bending in cases where nodes have different types and
so on. I wonder if a different approach is better - I've just had an idea
to do this differently, which might be a lot better. I'll write up some
solid code later and post back.



On Tue, Feb 24, 2015 at 8:25 AM, Mauro  wrote:

> Sorry my first sentence should have read:
> > Julia will *not* 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  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.
>
>

[julia-users] Re: linking Julia with C to improve performances

[Patrick O'Leary]

On Tuesday, February 24, 2015 at 7:00:34 AM UTC-6, Sean Marshallsay wrote:
>
> As Milan says, you shouldn't need C unless your program requires something 
> like LAPACK or BLAS.
>

Even then, many BLAS and LAPACK calls are already wrapped in Julia and can 
be used directly. 

Re: [julia-users] Re: Constructing matrices

[Bill Hart]

The specific use case where I hit this as a problem is in wrapping external
libraries like flint and pari, which unlike julia do not conflate 1xn
matrices with flat arrays.

However, I have just realised that Julia only conflates column vectors with
flat arrays, not row vectors.

Therefore I can overload my constructor for the external flint and pari
types to interpret Julia flat arrays as column vectors. Fortunately, I only
need to do that in one place. I can't imagine overloading every single
function for every possible combination of flat array vs matrix for each
parameter to the function.

The only reason I did things that way is because I initially thought Julia
arrays had cartesian product semantics (pointwise operations) rather than
matrix semantics.

So actually, I guess I can live with the way things are right now.

On 24 February 2015 at 14:29, Jiahao Chen  wrote:

> Clearly Julia wants to deliberately conflate row and column vectors, which
>> is fine if you aren't working with an algorithm that depends on the
>> individual dimensions of your matrices, and you aren't interfacing to an
>> external library.
>>
>
> Could you elaborate on what you mean here? As part of Issue #4474 I've
> been trying to collect specific examples.
>

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

[Randy Zwitch]

Submitted. Looking forward to making it to JuliaCon this year, speaker or 
otherwise!

On Monday, February 23, 2015 at 9:46:57 PM UTC-5, 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 .
> JuliaCon website: juliacon.org (to be updated shortly)
> JuliaCon program committee email: juli...@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 juli...@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 Q&A.
>- Each lightning talk will receive *8 minutes* to speak and *2 minutes* 
>for Q&A.
>- 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 f

[julia-users] Re: SAVE THE DATE: JuliaCon 2015, June 24 - 28

[Westley Hennigh]

Awesome!

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

Re: [julia-users] Re: World of Julia

[Westley Hennigh]

I think the issue is that the github api has two methods for getting commit 
history. One contains detailed information and excludes merge commits, but 
is only available for the top 100 contributors. The other is available for 
all contributors, but as just a single "number of commits".

On Monday, February 23, 2015 at 3:58:30 PM UTC-5, Stefan Karpinski wrote:
>
> 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  > 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  
>>> 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] Using a function on a group of data

[Tom Short]

Here are some links that might help:

http://dataframesjl.readthedocs.org/en/latest/split_apply_combine.html

https://github.com/JuliaStats/DataFramesMeta.jl/

https://groups.google.com/forum/#!topic/julia-users/BFW2cvAOfC4


On Tue, Feb 24, 2015 at 6:47 AM, pgs  wrote:

> Hi
> I have a txt file which I'm trying to perform a compuation(FUNCTION) on
> groups of data - the Grouping being Col1 then Col2.
> eg
>
> Say my txt file has the following
>
> Col1,Col2,Col3 Col4
> A 15:00 4  8
> A 15:00 6  5
> A 15:30 2  4
> A 15:30 8  7
> B 12:00 5  2
> B 12:00 4 1
> B 18:00 2 6
> B 18:00 1 7
> B 18:00 4 0.5  etc etc
>
> myfunction = map((x,y) -> x / y * 2, Col3,Col4)
> I then want to sum the results of my computation using the function e g
>
> So, when applying "myfunction"? - the result set is...
> A 15:00 1
> A 15:00 2.4
> sum 3.4
> A 15:30 1
> A 15:30 2.28
> sum 3.28
> So, the end game for me is just to see the final "sum" as an output - eg
> A 15:00 3.4
> A 15:30 3.28
> etc
> is this possible?
>
> Regards
>
>

[julia-users] Re: linking Julia with C to improve performances

[Simon Danisch]

@Bill Hart
small note on your example: you don't return anything, which is why LLVM's 
code elimination jumps in and removes your whole function body, which 
results in a very fast "addition" :P
Even if you return c, LLVM is smart enough to just precalculate the value 
resulting in doit() = 30 as the method definition.
Even having doit take a and b as arguments results in doit(a,b) = a+b.

Even this: 
function doit(n)
   c = 0
   for i = 1:n
  c += i
   end
end
gets turned into a constant expression.
It's actually not that easy, to get the plus benchmark, as it gets heavily 
optimized. 
I think something like this will approximate the time needed better:
function doit(n)
   bench = 0.0
   for i = 1:n
a = rand()
tic()
a+a
t = toq()
bench += t   
   end
   bench
end
doit(10^6)
@show doit(10^6)
doit(10 ^ 6) = 0.09192137800017194

This is actually pretty awesome about Julia, as even someone like me with 
only a small background in computer science is able to find out all these 
things.
(via @code_llvm, @code_native, etc)

Am Dienstag, 24. Februar 2015 10:13:52 UTC+1 schrieb giovan...@gmail.com:
>
> Hello,
>
> I am a beginner to Julia and would like to try out some features. I would 
> like to improve performances of some bottleneck functions by translating 
> them into C.
> A simple example is :
> main.jl
>
> a ::Int64 = 20  
> b ::Int64 = 10
> ccall(:do_sum, Int64, (Int64, Int64), a, b)
>
>
>
> test.c
> #include 
>
> int do_sum (int a,int b)
> {
> int c;
> c = a+b;
> printf("f\n:",c);
> return c;
> }
>
> where should I put the C file ? 
>
> Thanks,
> G.
>
>

[julia-users] Best way to find the directory a package is in

[Scott T]

Hi all,

I've been playing around with trying to install Julia and some basic 
packages system-wide to run a workshop for our department in a couple of 
weeks time. Mostly it's working well, and I'm really excited about seeing 
what people think!

I ran into the problem that Pkg.dir("PackageName"), although documented as 
returning the path to a package, doesn't necessarily do this in the right 
way. In particular, if a user has set up their own .julia directory, doing 
Pkg.dir("ASharedPackage") returns ~/.julia/v0.x/ASharedPackage even if that 
folder doesn't exist. 

That is, if JULIA_PKGDIR is not the same as the directory the package is 
*actually* in, Pkg.dir("Package") won't give the right location.

I hit this problem trying to get IJulia installed for everyone to use, 
becase one of its dependencies Nettle uses Pkg.dir("Nettle") to find itself 
when loaded, and so if installed system-wide (in /local/share) it 
won't work.

So, is there a more reliable way to get the path to a package? 

[Pkg.dir might need to be smarter instead, but that's more a development 
question. I commented on that here 
]

Cheers,
Scott

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

[Jiahao Chen]

On Tuesday, February 24, 2015 at 1:12:18 AM UTC-5, Christian Peel wrote:
>
> 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 
>
 
Yes, Xiaodong had asked for speakers and I'm glad Katherine was available. 
Is the talk up somewhere?

At the moment we're looking for voluntary contributions, as opposed to 
volunteered contributions. :) Naturally, we hope that Katherine will submit 
something on her own accord.
 

> BTW, I'd love to see Juliacon in the SF Bay area.
>

We'd need a critical mass of volunteers in the area for that to happen. If 
you're willing to coordinate that effort for 2016, we'd be very interested. 
:)

Re: [julia-users] linking Julia with C to improve performances

[Milan Bouchet-Valat]

Le mardi 24 février 2015 à 05:25 -0800, Bill Hart a écrit :
> In answer to your original question, assuming you had a very complex C
> program that Julia just didn't handle efficiently (it's possible), or
> you had already written a very large external library which you didn't
> want to rewrite in Julia, and someone else hasn't already written an
> interface to it from Julia
> 
> 
> First you want to make a shared library. For this you can use gcc.
> First compile your C file to an object file with the -c option. Then
> link your object file to make a shared library with the -shared
> option. This will make a shared library (.so or .dll or .dylib,
> depending on what operating system you have).
> 
> 
> It's the .so or .dll or .dylib file that Julia wants to be able to
> find, not the C file.
> 
> 
> So long as your shared library has no other dependencies, you can set
> Julia's DL_LOAD_PATH to specify the location of the shared library
> (I'm not sure if this is considered best practice or not).
> 
> 
> Otherwise, on most systems the dynamic linker has various places it
> will look for your library. This depends on your system though, so it
> varies between Unix, Linux, Windows and OSX.
This should work, but I think the "best practice" if you need to make
your code public at some point is to use BinDeps, as explained in the
thread I linked to. Though if you're the only one to work on it, a few
hacks to build and locate the library might be enough.


Regards

> On Tuesday, 24 February 2015 14:10:31 UTC+1, Bill Hart wrote:
> One important thing to note is that if you do a + b at the top
> level, it won't be fast.
> 
> 
> But as soon as you do a + b inside a function, it will be as
> fast as C.
> 
> For example
> 
> 
> a = 20
> b = 10
> for i = 1:10
>c = a + b
> end
> 
> 
> takes about 34s
> 
> 
> But the following is almost instantaneous:
> 
> 
> function doit()
>a = 20
>b = 10
>for i = 1:10
>   c = a + b
>end
> end
> 
> 
> doit()
>
> 
> On Tuesday, 24 February 2015 14:03:07 UTC+1, Tim Holy wrote:
> Giovanni, 
> 
> Before you start going to that kind of effort, take a
> look at 
> 
> julia> @code_native 3+5 
> .text 
> Filename: int.jl 
> Source line: 12 
> pushRBP 
> mov RBP, RSP 
> Source line: 12 
> add RDI, RSI 
> mov RAX, RDI 
> pop RBP 
> ret 
> 
> I think you're going to have a pretty hard time
> finding a C compiler that does 
> better than this :-). Especially since it gets inlined
> at the call site. 
> 
> Best, 
> --Tim 
> 
> On Tuesday, February 24, 2015 01:13:52 AM
> giovan...@gmail.com wrote: 
> > Hello, 
> > 
> > I am a beginner to Julia and would like to try out
> some features. I would 
> > like to improve performances of some bottleneck
> functions by translating 
> > them into C. 
> > A simple example is : 
> > main.jl 
> > 
> > a ::Int64 = 20 
> > b ::Int64 = 10 
> > ccall(:do_sum, Int64, (Int64, Int64), a, b) 
> > 
> > 
> > 
> > test.c 
> > #include  
> > 
> > int do_sum (int a,int b) 
> > { 
> > int c; 
> > c = a+b; 
> > printf("f\n:",c); 
> > return c; 
> > } 
> > 
> > where should I put the C file ? 
> > 
> > Thanks, 
> > G. 
> 

Re: [julia-users] Re: Constructing matrices

[Jiahao Chen]

>
> Clearly Julia wants to deliberately conflate row and column vectors, which
> is fine if you aren't working with an algorithm that depends on the
> individual dimensions of your matrices, and you aren't interfacing to an
> external library.
>

Could you elaborate on what you mean here? As part of Issue #4474 I've been
trying to collect specific examples.

Re: [julia-users] linking Julia with C to improve performances

[Bill Hart]

In answer to your original question, assuming you had a very complex C 
program that Julia just didn't handle efficiently (it's possible), or you 
had already written a very large external library which you didn't want to 
rewrite in Julia, and someone else hasn't already written an interface to 
it from Julia

First you want to make a shared library. For this you can use gcc. First 
compile your C file to an object file with the -c option. Then link your 
object file to make a shared library with the -shared option. This will 
make a shared library (.so or .dll or .dylib, depending on what operating 
system you have).

It's the .so or .dll or .dylib file that Julia wants to be able to find, 
not the C file.

So long as your shared library has no other dependencies, you can set 
Julia's DL_LOAD_PATH to specify the location of the shared library (I'm not 
sure if this is considered best practice or not).

Otherwise, on most systems the dynamic linker has various places it will 
look for your library. This depends on your system though, so it varies 
between Unix, Linux, Windows and OSX.

On Tuesday, 24 February 2015 14:10:31 UTC+1, Bill Hart wrote:
>
> One important thing to note is that if you do a + b at the top level, it 
> won't be fast.
>
> But as soon as you do a + b inside a function, it will be as fast as C.
>
> For example
>
> a = 20
> b = 10
> for i = 1:10
>c = a + b
> end
>
> takes about 34s
>
> But the following is almost instantaneous:
>
> function doit()
>a = 20
>b = 10
>for i = 1:10
>   c = a + b
>end
> end
>
> doit()
>
>
> On Tuesday, 24 February 2015 14:03:07 UTC+1, Tim Holy wrote:
>>
>> Giovanni, 
>>
>> Before you start going to that kind of effort, take a look at 
>>
>> julia> @code_native 3+5 
>> .text 
>> Filename: int.jl 
>> Source line: 12 
>> pushRBP 
>> mov RBP, RSP 
>> Source line: 12 
>> add RDI, RSI 
>> mov RAX, RDI 
>> pop RBP 
>> ret 
>>
>> I think you're going to have a pretty hard time finding a C compiler that 
>> does 
>> better than this :-). Especially since it gets inlined at the call site. 
>>
>> Best, 
>> --Tim 
>>
>> On Tuesday, February 24, 2015 01:13:52 AM giovan...@gmail.com wrote: 
>> > Hello, 
>> > 
>> > I am a beginner to Julia and would like to try out some features. I 
>> would 
>> > like to improve performances of some bottleneck functions by 
>> translating 
>> > them into C. 
>> > A simple example is : 
>> > main.jl 
>> > 
>> > a ::Int64 = 20 
>> > b ::Int64 = 10 
>> > ccall(:do_sum, Int64, (Int64, Int64), a, b) 
>> > 
>> > 
>> > 
>> > test.c 
>> > #include  
>> > 
>> > int do_sum (int a,int b) 
>> > { 
>> > int c; 
>> > c = a+b; 
>> > printf("f\n:",c); 
>> > return c; 
>> > } 
>> > 
>> > where should I put the C file ? 
>> > 
>> > Thanks, 
>> > G. 
>>
>>

Re: [julia-users] linking Julia with C to improve performances

[Bill Hart]

One important thing to note is that if you do a + b at the top level, it 
won't be fast.

But as soon as you do a + b inside a function, it will be as fast as C.

For example

a = 20
b = 10
for i = 1:10
   c = a + b
end

takes about 34s

But the following is almost instantaneous:

function doit()
   a = 20
   b = 10
   for i = 1:10
  c = a + b
   end
end

doit()
   

On Tuesday, 24 February 2015 14:03:07 UTC+1, Tim Holy wrote:
>
> Giovanni, 
>
> Before you start going to that kind of effort, take a look at 
>
> julia> @code_native 3+5 
> .text 
> Filename: int.jl 
> Source line: 12 
> pushRBP 
> mov RBP, RSP 
> Source line: 12 
> add RDI, RSI 
> mov RAX, RDI 
> pop RBP 
> ret 
>
> I think you're going to have a pretty hard time finding a C compiler that 
> does 
> better than this :-). Especially since it gets inlined at the call site. 
>
> Best, 
> --Tim 
>
> On Tuesday, February 24, 2015 01:13:52 AM giovan...@gmail.com 
>  wrote: 
> > Hello, 
> > 
> > I am a beginner to Julia and would like to try out some features. I 
> would 
> > like to improve performances of some bottleneck functions by translating 
> > them into C. 
> > A simple example is : 
> > main.jl 
> > 
> > a ::Int64 = 20 
> > b ::Int64 = 10 
> > ccall(:do_sum, Int64, (Int64, Int64), a, b) 
> > 
> > 
> > 
> > test.c 
> > #include  
> > 
> > int do_sum (int a,int b) 
> > { 
> > int c; 
> > c = a+b; 
> > printf("f\n:",c); 
> > return c; 
> > } 
> > 
> > where should I put the C file ? 
> > 
> > Thanks, 
> > G. 
>
>

[julia-users] Re: Constructing matrices

[Bill Hart]

Thanks. The hvcat is somewhat awkward as a matrix syntax.

But from your hint I also see that [[1]'; 2; 3] or [1 2 3]' works.

That's a bit ugly, but workable for now. I really wish the semicolon had 
been reserved for terminating the row of a matrix.

Clearly Julia wants to deliberately conflate row and column vectors, which 
is fine if you aren't working with an algorithm that depends on the 
individual dimensions of your matrices, and you aren't interfacing to an 
external library.

On Monday, 23 February 2015 21:16:27 UTC+1, Pablo Zubieta wrote:
>
> 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] linking Julia with C to improve performances

[Tim Holy]

Giovanni,

Before you start going to that kind of effort, take a look at

julia> @code_native 3+5
.text
Filename: int.jl
Source line: 12
pushRBP
mov RBP, RSP
Source line: 12
add RDI, RSI
mov RAX, RDI
pop RBP
ret

I think you're going to have a pretty hard time finding a C compiler that does 
better than this :-). Especially since it gets inlined at the call site.

Best,
--Tim

On Tuesday, February 24, 2015 01:13:52 AM giovanni.m...@gmail.com wrote:
> Hello,
> 
> I am a beginner to Julia and would like to try out some features. I would
> like to improve performances of some bottleneck functions by translating
> them into C.
> A simple example is :
> main.jl
> 
> a ::Int64 = 20
> b ::Int64 = 10
> ccall(:do_sum, Int64, (Int64, Int64), a, b)
> 
> 
> 
> test.c
> #include 
> 
> int do_sum (int a,int b)
> {
> int c;
> c = a+b;
> printf("f\n:",c);
> return c;
> }
> 
> where should I put the C file ?
> 
> Thanks,
> G.

[julia-users] Re: linking Julia with C to improve performances

[Sean Marshallsay]

As Milan says, you shouldn't need C unless your program requires something 
like LAPACK or BLAS. Before even thinking about C you should read

http://docs.julialang.org/en/release-0.3/manual/performance-tips/

*very* carefully. If you're still struggling with performance issues feel 
free to ask questions about on here.

On Tuesday, 24 February 2015 09:13:52 UTC, giovan...@gmail.com wrote:
>
> Hello,
>
> I am a beginner to Julia and would like to try out some features. I would 
> like to improve performances of some bottleneck functions by translating 
> them into C.
> A simple example is :
> main.jl
>
> a ::Int64 = 20  
> b ::Int64 = 10
> ccall(:do_sum, Int64, (Int64, Int64), a, b)
>
>
>
> test.c
> #include 
>
> int do_sum (int a,int b)
> {
> int c;
> c = a+b;
> printf("f\n:",c);
> return c;
> }
>
> where should I put the C file ? 
>
> Thanks,
> G.
>
>

Re: [julia-users] linking Julia with C to improve performances

[Milan Bouchet-Valat]

Le mardi 24 février 2015 à 01:13 -0800, giovanni.m...@gmail.com a
écrit :
> Hello,
> 
> I am a beginner to Julia and would like to try out some features. I
> would like to improve performances of some bottleneck functions by
> translating them into C.
Do you think that's really necessary? One of the main goals of Julia is
to make it possible to write efficient code without mixing a high-level
and a low-level language. Carefully written Julia code should be quite
close to C in terms of performance.

> A simple example is :
> main.jl
> 
> a ::Int64 = 20  
> b ::Int64 = 10
> ccall(:do_sum, Int64, (Int64, Int64), a, b)
> 
> 
> 
> test.c
> #include 
> 
> int do_sum (int a,int b)
> {
> int c;
> c = a+b;
> printf("f\n:",c);
> return c;
> }
> 
> where should I put the C file ? 
I think you should have a look at this thread:
https://groups.google.com/d/msg/julia-users/VeaoUzvEwZQ/1Pa_IClBvYIJ

(This could probably go into the manual at some point.)


Regards

Re: [julia-users] Finding indices in an array matching a logical expression

[Milan Bouchet-Valat]

Le mardi 24 février 2015 à 00:46 -0800, Grunde Waag a écrit :
> Hi,
> I have an array, for instance x = linspace(0, 10, 20);, and I want to
> find the index for which x==1 and then change the value of x at that
> index.
> 
> 
> In Matlab this is easy: x(x==0) = 100;
> 
> 
> What is the best way to do this in julia!
Simply
x[x .== 0] = 100

You can have a look at the manual for more details about the difference
between == and .== in Julia.


Regards

[julia-users] Finding indices in an array matching a logical expression

[Grunde Waag]

Hi,
I have an array, for instance x = linspace(0, 10, 20);, and I want to find 
the index for which x==1 and then change the value of x at that index.

In Matlab this is easy: x(x==0) = 100;

What is the best way to do this in julia!

Grunde

[julia-users] linking Julia with C to improve performances

[giovanni . msla]

Hello,

I am a beginner to Julia and would like to try out some features. I would 
like to improve performances of some bottleneck functions by translating 
them into C.
A simple example is :
main.jl

a ::Int64 = 20  
b ::Int64 = 10
ccall(:do_sum, Int64, (Int64, Int64), a, b)



test.c
#include 

int do_sum (int a,int b)
{
int c;
c = a+b;
printf("f\n:",c);
return c;
}

where should I put the C file ? 

Thanks,
G.

[julia-users] Using a function on a group of data

[pgs]

Hi
I have a txt file which I'm trying to perform a compuation(FUNCTION) on 
groups of data - the Grouping being Col1 then Col2.
eg

Say my txt file has the following

Col1,Col2,Col3 Col4
A 15:00 4  8
A 15:00 6  5
A 15:30 2  4
A 15:30 8  7
B 12:00 5  2
B 12:00 4 1
B 18:00 2 6
B 18:00 1 7
B 18:00 4 0.5  etc etc

myfunction = map((x,y) -> x / y * 2, Col3,Col4) 
I then want to sum the results of my computation using the function e g

So, when applying "myfunction"? - the result set is...
A 15:00 1
A 15:00 2.4
sum 3.4
A 15:30 1
A 15:30 2.28
sum 3.28
So, the end game for me is just to see the final "sum" as an output - eg
A 15:00 3.4
A 15:30 3.28
etc
is this possible?

Regards

Re: [julia-users] Bokeh.jl update released: call for feedback

[Eric Forgy]

On Tuesday, February 24, 2015 at 3:19:17 AM UTC+8, Samuel Colvin wrote:
>
> (and saying someone mildly antagonistic to kick off some debate, sorry).
>

Hehe. I can't resist :)

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.


I looked at the whole canvas vs SVG thing and went with d3 for my 
visualizations. Depending on your application, SVG can also be fast. Here 
is a nice comparison: When to Use  and when to Use SVG: The 
Scenarios 

.

Particularly for web-based visualizations, I really want things to come 
alive, i.e. be dynamic and interactive. And as Tim was looking for, it is 
very simple to have an interaction with d3 launch some Julia code 
asynchronously.

PS: TIm, if you ever have some free time to play around with javascript, I 
think you may like it. I come from 20+ years of Matlab with a bit of Java 
thrown in here and there, but have been learning javascript since August 
and love it. The old perceptions of it being slow are... well... old :) 
Even the Julia benchmark shows javascript approaching Julia speeds. 
Javascript is also fun because with little clue, you can hack something 
together easily, but the deeper you go, the more satisfying it can be.

[julia-users] Re: How to store the state of current rand generator (not set the seed)

[Simon Byrne]

One idiom that we are slowly moving toward is requiring that all methods 
(such as rand) which use random numbers should accept an RNG as an 
argument, so you might be able to write something like

r = MersenneTwister()
stage1(r)

r_a = deepcopy(r)
stage2_a(r_a)

r_b = deepcopy(r)
stage2_b(r_b)

Within each function, you need to make sure that each call to rand includes 
references the RNG argument. At the moment, this won't work with 
Distributions.jl, so you're limited to the rand methods in Base.



On Monday, 23 February 2015 17:02:01 UTC, Steve Kay 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
>

Re: [julia-users] Making optional fields of unknown type more efficient

[Mauro]

Sorry my first sentence should have read:
> Julia will *not* 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  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.