[julia-users] Re: Adding new column to dataframe

[Sam L]

> df = DataFrame(A=rand(10), B=rand(10))
> df[:C] = df[:A] .+ df[:B]

does the trick in DataFrames v0.5.4.

On Thursday, May 15, 2014 7:59:54 PM UTC-7, Jason Solack wrote:
>
> So i feel like this a simple question, but i can't find reference to it.  
>
> Lets say i have a DataFrame with columns A and B and i want to add a new 
> column C that is A+B.  How would i do that?
>
> Sorry if i'm overlooking an easy answer!
>
> jason
>

[julia-users] Adding new column to dataframe

[Jason Solack]

So i feel like this a simple question, but i can't find reference to it.  

Lets say i have a DataFrame with columns A and B and i want to add a new 
column C that is A+B.  How would i do that?

Sorry if i'm overlooking an easy answer!

jason

[julia-users] Re: JuliaCon Question Thread

[Viral B. Shah]

There will be a bit of everything. It is certainly not experts only.

-viral

On Wednesday, May 14, 2014 1:08:55 AM UTC+5:30, G. Patrick Mauroy wrote:
>
> Will the conference target Julia experts with only advanced topics or will 
> it be appropriate/beneficial to newcomers and prospective ones who are 
> tempted but perhaps a bit "skittish"?
>
> I would find it useful if there was a little abstract for each 
> presentation.  I understand it might be early for that...
>
> On Monday, May 12, 2014 11:43:34 PM UTC-4, Hunter Owens wrote:
>>
>> Hey All-
>>
>> As, you (hopefully) know, registration for JuliaCon is 
>> now open. 
>>
>> I'm starting this thread so you can ask me (or any of the other 
>> organizers, who are cc'ed) any questions you may have about the conference. 
>>
>> Please do consider submitting a talk proposal or attending the 
>> conference, as we are looking forward to seeing folks in Chicago summer. 
>>
>> Thanks,
>> Hunter
>>
>

Re: [julia-users] Re: build failure in vagrant/virtualbox?

[S Wade]

Yes

I used those same build setting but got the same failure. The only difference 
is that I'm allowing make to download the packages rather than using the 
prebuilt ones. 

thanks,
wade

> On May 15, 2014, at 2:49 PM, Patrick O'Leary  wrote:
> 
> Have you checked the Vagrantfile (and README) in contrib/vagrant? I don't 
> exactly recall what all I ran into but I know I ended up relying on mostly 
> system packages, ran into the AVX thing with VirtualBox, and had to work 
> around the limitation that there are no symlinks in VirtualBox shared folders.
> 
> None of these look like the problem you're having, but I want to make sure 
> you knew that it was there in case it's helpful.
> 
>> On Sunday, May 11, 2014 11:13:28 AM UTC-5, S Wade wrote:
>> Hi all,
>> 
>> I'd appreciate help building julia HEAD.  We're prepping a VM for vagrant 
>> deployment and the build process fails at the very end as it's bootstrapping:
>> 
>> ```
>> deprecated.jl
>> pkg.jl
>> graphics.jl
>> profile.jl
>> precompile.jl
>> Killed
>> make[3]: *** [/home/vagrant/julia/usr/lib/julia/sys0.o] Error 137
>> ```
>> 
>> From googling it looked like it may be due to OpenBlas and AVX support 
>> (which seems to build successfully but does warn about lack of AVX support). 
>>  I tried compiling from scratch with `make OPENBLAS_TARGET_ARCH=NEHALEM` but 
>> this doesn't seem to solve the problem.  I also tried `make dist`.
>> 
>> thanks,
>> wade
>> 

Re: [julia-users] for loops

[Mike Innes]

Ah, I see what you mean. I'm not sure if it's possible, though.

You'd have to determine whether f() do ... meant "function with do block"
or "iterator with do block", which isn't possible in general. So at least
you'd need special syntax for it, and by that point it's probably easier to
stick with map.


On 15 May 2014 22:33, Cameron McBride  wrote:

> Sure, Mike.  But the idea is to have this for all iterator objects
> intrinsically rather than defining it for each function that returns an
> iterator.
>
> There is likely a way to do this automagically for all iterators, but my
> julia-fu isn't strong enough that it jumped out at me when I looked over
> some source in base/.  I expect it's simple, but I don't have time to
> figure it out today.
>
> Cameron
>
>
>
> On Thu, May 15, 2014 at 4:51 PM, Mike Innes wrote:
>
>> Well, if you want the first syntax you can easily define
>>
>> Base.enumerate(f::Function, args...) = map(t->f(t...), enumerate(args
>> ...))
>>
>> You could always open a pull request if you wanted to see this in Base,
>> too.
>>
>>
>> On Thursday, 15 May 2014 21:18:31 UTC+1, Cameron McBride wrote:
>>
>>> I missed enumerate() for a while,  and was happy I found it.  I find it
>>> amusing how satisfying a few missing keystrokes can be.
>>>
>>> On a related but different note, from a similar influence, I keep
>>> wanting to pass blocks to iterators.  Any chance that will ever happen?
>>>
>>> I realize that do..end blocks are used currently as syntactic sugar for
>>> methods that take a function as the first arg (e.g. open(), map()), and the
>>> same functionality can be achieved with three letters and two braces (map),
>>> but it still seems somewhat cleaner to write:
>>>
>>> enumerate(a) do i,x
>>> ...
>>> end
>>>
>>> over
>>>
>>> map(enumerate(a)) do i,x
>>> ...
>>> end
>>>
>>> which are really just equivalent, as we know, to
>>>
>>> for i,x, in enumerate(a)
>>> ...
>>> end
>>>
>>> Are there technical reasons this is a bad idea to assume?
>>>
>>> Cameron
>>>
>>> On Thu, May 15, 2014 at 1:01 PM, John Myles White 
>>> wrote:
>>>
 I kind of suspect Stefan, like me, would instinctively call this
 operation `each_with_index`.

  -- John

 On May 15, 2014, at 6:33 AM, Kevin Squire  wrote:

 One nice thing about Julia is that she borrows many (though not all) good
 ideas from other languages. In this case, enumerate came from Python
 (although it likely has other incarnations).

 Cheers!
Kevin


 On Thursday, May 15, 2014, Billou Bielour  wrote:

> I was thinking the same thing the other day, when using *for x in xs* I
> often find myself needing an index at some point and then I have to change
> the for loop, or write an index manually.
>
> Enumerate is exactly what I need in this case.
>
> +1 for Julia
>
>

>>>
>

Re: [julia-users] for loops

[Cameron McBride]

Sure, Mike.  But the idea is to have this for all iterator objects
intrinsically rather than defining it for each function that returns an
iterator.

There is likely a way to do this automagically for all iterators, but my
julia-fu isn't strong enough that it jumped out at me when I looked over
some source in base/.  I expect it's simple, but I don't have time to
figure it out today.

Cameron



On Thu, May 15, 2014 at 4:51 PM, Mike Innes  wrote:

> Well, if you want the first syntax you can easily define
>
> Base.enumerate(f::Function, args...) = map(t->f(t...), enumerate(args...))
>
> You could always open a pull request if you wanted to see this in Base,
> too.
>
>
> On Thursday, 15 May 2014 21:18:31 UTC+1, Cameron McBride wrote:
>
>> I missed enumerate() for a while,  and was happy I found it.  I find it
>> amusing how satisfying a few missing keystrokes can be.
>>
>> On a related but different note, from a similar influence, I keep wanting
>> to pass blocks to iterators.  Any chance that will ever happen?
>>
>> I realize that do..end blocks are used currently as syntactic sugar for
>> methods that take a function as the first arg (e.g. open(), map()), and the
>> same functionality can be achieved with three letters and two braces (map),
>> but it still seems somewhat cleaner to write:
>>
>> enumerate(a) do i,x
>> ...
>> end
>>
>> over
>>
>> map(enumerate(a)) do i,x
>> ...
>> end
>>
>> which are really just equivalent, as we know, to
>>
>> for i,x, in enumerate(a)
>> ...
>> end
>>
>> Are there technical reasons this is a bad idea to assume?
>>
>> Cameron
>>
>> On Thu, May 15, 2014 at 1:01 PM, John Myles White 
>> wrote:
>>
>>> I kind of suspect Stefan, like me, would instinctively call this
>>> operation `each_with_index`.
>>>
>>>  -- John
>>>
>>> On May 15, 2014, at 6:33 AM, Kevin Squire  wrote:
>>>
>>> One nice thing about Julia is that she borrows many (though not all) good
>>> ideas from other languages. In this case, enumerate came from Python
>>> (although it likely has other incarnations).
>>>
>>> Cheers!
>>>Kevin
>>>
>>>
>>> On Thursday, May 15, 2014, Billou Bielour  wrote:
>>>
 I was thinking the same thing the other day, when using *for x in xs* I
 often find myself needing an index at some point and then I have to change
 the for loop, or write an index manually.

 Enumerate is exactly what I need in this case.

 +1 for Julia


>>>
>>

Re: [julia-users] for loops

[Mike Innes]

Well, if you want the first syntax you can easily define

Base.enumerate(f::Function, args...) = map(t->f(t...), enumerate(args...))

You could always open a pull request if you wanted to see this in Base, too.

On Thursday, 15 May 2014 21:18:31 UTC+1, Cameron McBride wrote:
>
> I missed enumerate() for a while,  and was happy I found it.  I find it 
> amusing how satisfying a few missing keystrokes can be.  
>
> On a related but different note, from a similar influence, I keep wanting 
> to pass blocks to iterators.  Any chance that will ever happen?
>
> I realize that do..end blocks are used currently as syntactic sugar for 
> methods that take a function as the first arg (e.g. open(), map()), and the 
> same functionality can be achieved with three letters and two braces (map), 
> but it still seems somewhat cleaner to write: 
>
> enumerate(a) do i,x
> ...
> end
>
> over
>  
> map(enumerate(a)) do i,x
> ...
> end
>
> which are really just equivalent, as we know, to
>
> for i,x, in enumerate(a) 
> ...
> end
>
> Are there technical reasons this is a bad idea to assume?
>
> Cameron
>
> On Thu, May 15, 2014 at 1:01 PM, John Myles White 
> 
> > wrote:
>
>> I kind of suspect Stefan, like me, would instinctively call this 
>> operation `each_with_index`.
>>
>>  -- John
>>
>> On May 15, 2014, at 6:33 AM, Kevin Squire > 
>> wrote:
>>
>> One nice thing about Julia is that she borrows many (though not all) good 
>> ideas from other languages. In this case, enumerate came from Python 
>> (although it likely has other incarnations).
>>
>> Cheers!
>>Kevin 
>>
>> On Thursday, May 15, 2014, Billou Bielour > 
>> wrote:
>>
>>> I was thinking the same thing the other day, when using *for x in xs* I 
>>> often find myself needing an index at some point and then I have to change 
>>> the for loop, or write an index manually.
>>>
>>> Enumerate is exactly what I need in this case. 
>>>
>>> +1 for Julia
>>>
>>>
>>
>

Re: [julia-users] for loops

[Cameron McBride]

I missed enumerate() for a while,  and was happy I found it.  I find it
amusing how satisfying a few missing keystrokes can be.

On a related but different note, from a similar influence, I keep wanting
to pass blocks to iterators.  Any chance that will ever happen?

I realize that do..end blocks are used currently as syntactic sugar for
methods that take a function as the first arg (e.g. open(), map()), and the
same functionality can be achieved with three letters and two braces (map),
but it still seems somewhat cleaner to write:

enumerate(a) do i,x
...
end

over

map(enumerate(a)) do i,x
...
end

which are really just equivalent, as we know, to

for i,x, in enumerate(a)
...
end

Are there technical reasons this is a bad idea to assume?

Cameron

On Thu, May 15, 2014 at 1:01 PM, John Myles White
wrote:

> I kind of suspect Stefan, like me, would instinctively call this operation
> `each_with_index`.
>
>  -- John
>
> On May 15, 2014, at 6:33 AM, Kevin Squire  wrote:
>
> One nice thing about Julia is that she borrows many (though not all) good
> ideas from other languages. In this case, enumerate came from Python
> (although it likely has other incarnations).
>
> Cheers!
>Kevin
>
> On Thursday, May 15, 2014, Billou Bielour  wrote:
>
>> I was thinking the same thing the other day, when using *for x in xs* I
>> often find myself needing an index at some point and then I have to change
>> the for loop, or write an index manually.
>>
>> Enumerate is exactly what I need in this case.
>>
>> +1 for Julia
>>
>>
>

Re: [julia-users] purpose of the end keyword

[Stefan Karpinski]

Yes, the point about metaprogramming is a good one.


On Thu, May 15, 2014 at 4:03 PM, Steven G. Johnson wrote:

> It's a tradeoff. The cost of having an explicit "end" is a few extra
> characters that you have to type, and an extra line of code at the end of
> each block.  On the other hand, the benefits include less error-prone
> cut-and-paste (as Stefan mentioned), the possibility of automated
> reformatting of code (e.g. think emacs indent-region or gofmt), and
> flexibility in writing one-liners (e.g. "try foo() end").
>
> I think the metaprogramming facilities in Julia also favor the choice of
> explicit block delimiters.  In Julia, code can also be a symbolic
> expression, simply by surrounding it with :() or quote ... end, and
> whitespace sensitivity within symbolic expressions seems like it would get
> annoying quickly
>
> Probably this should be in the Julia FAQ or Manual, since our inexplicable
> rejection of the holy whitespace seems to be the first thing that every
> Python programmer asks about.  (If you hate typing extraneous characters,
> the colons in Python must drive you bonkers.)
>
> (People who like maximum terseness in a practical programming language
> should take a look at J.   The J examples on 
> RosettaCodeare pretty amazing.)
>

Re: [julia-users] purpose of the end keyword

[Steven G. Johnson]

It's a tradeoff. The cost of having an explicit "end" is a few extra 
characters that you have to type, and an extra line of code at the end of 
each block.  On the other hand, the benefits include less error-prone 
cut-and-paste (as Stefan mentioned), the possibility of automated 
reformatting of code (e.g. think emacs indent-region or gofmt), and 
flexibility in writing one-liners (e.g. "try foo() end").

I think the metaprogramming facilities in Julia also favor the choice of 
explicit block delimiters.  In Julia, code can also be a symbolic 
expression, simply by surrounding it with :() or quote ... end, and 
whitespace sensitivity within symbolic expressions seems like it would get 
annoying quickly

Probably this should be in the Julia FAQ or Manual, since our inexplicable 
rejection of the holy whitespace seems to be the first thing that every 
Python programmer asks about.  (If you hate typing extraneous characters, 
the colons in Python must drive you bonkers.)

(People who like maximum terseness in a practical programming language 
should take a look at J.   The J examples on 
RosettaCodeare pretty amazing.)

Re: [julia-users] Trouble with Type Parameters

[Kevin Squire]

FWIW, I really appreciate you pointing out the different uses of :: Toivo.
 Along with the different meanings of parameterizations in types and
functions, this is another area I haven't been clear about (and I wasn't
even aware of it until you pointed it out).

Cheers!
   Kevin


On Thu, May 15, 2014 at 11:49 AM, Toivo Henningsson wrote:

>
>
> On Thursday, 15 May 2014 10:59:07 UTC+2, Tomas Lycken wrote:
>>
>> it silently uses :: in a different sense than anywhere else in the
>>> language
>>
>>
>> I started writing a reply here, but realized it would be more instructive
>> to have it as an IJulia notebook, where we can actually inspect the values
>> of various statements along the way - take a look here instead:
>> http://nbviewer.ipython.org/github/tlycken/IJulia-Notebooks/blob/master/
>> A%20more%20thorough%20look%20at%20Julia's%20%22double%
>> 20colon%22%20syntax.ipynb
>>
>> I hope it makes things a little clearer. I tried to base it on the
>> relevant section on `::` in the manual (http://docs.julialang.org/en/
>> latest/manual/types/#type-declarations) and expand it with more examples
>> etc, so I hope it's possible to see the connections.
>>
>
> Oh, it's quite clear to me. But do you agree that the usage of x::T as a
> formal parameter is quite different when T is a type parameter compared to
> when it is a plain type? Different enough that it's not really about an
> isa relationship anymore? To my mind, this should warrant using another
> operator than :: when T is a type parameter (though there's preciously few
> good operator symbols left, and it would be quite a disruptive change...).
>
>  / Toivo
>

Re: [julia-users] purpose of the end keyword

[Stefan Karpinski]

It's a matter of taste – and the fact that we wanted Julia to feel familiar
in particular to Matlab users (and to a lesser extent Ruby users). I
personally don't like significant indentation. It gets really awkward and
fiddly when you're trying to cut and paste into a terminal or into an
editor. I've seen a significant number of live Python demos flounder as the
presenter struggled with indentation issues. It feels to me like Python
programs trail off into space with never-ending scopes. Jeff and Viral both
happen to feel similarly, so Julia ended up looking more like Matlab than
like Python.


On Thu, May 15, 2014 at 3:04 PM, Dustin Lee  wrote:

> Thanks.  I should probably have been more clear.  I understand what it
> *is* doing.  I'm just curious if there was a reason besides "taste" to
> choose that over whitespace significance.
>
>
> On Thursday, May 15, 2014 12:55:07 PM UTC-6, Stefan Karpinski wrote:
>
>> The `end` keyword closes blocks. Python uses indentation for this. In
>> Julia indentation is not significant.
>>
>>
>> On Thu, May 15, 2014 at 2:51 PM, Dustin Lee  wrote:
>>
>>> Coming from python I've found that julias's "end" statement doesn't
>>> bother me as much as I would have thought, but when I show some code to my
>>> python colleagues this really annoys them.  But this got me thinking, what
>>> *is* the purpose of "end".  Is it just a taste issue, a way to make parsing
>>> easier, something else?
>>>
>>> My make believe answer that I found myself starting to make to my
>>> colleagues was that it was for ease of writing a parser, but then I wasn't
>>> sure how this squares with the fact that languages like python and haskell
>>> don't seem to have too much trouble w/out braces or end keywords.
>>>
>>> Just curious,
>>>
>>> dustin
>>>
>>
>>

Re: [julia-users] purpose of the end keyword

[Dustin Lee]

Thanks.  I should probably have been more clear.  I understand what it *is* 
doing.  I'm just curious if there was a reason besides "taste" to choose 
that over whitespace significance.

On Thursday, May 15, 2014 12:55:07 PM UTC-6, Stefan Karpinski wrote:
>
> The `end` keyword closes blocks. Python uses indentation for this. In 
> Julia indentation is not significant.
>
>
> On Thu, May 15, 2014 at 2:51 PM, Dustin Lee 
> > wrote:
>
>> Coming from python I've found that julias's "end" statement doesn't 
>> bother me as much as I would have thought, but when I show some code to my 
>> python colleagues this really annoys them.  But this got me thinking, what 
>> *is* the purpose of "end".  Is it just a taste issue, a way to make parsing 
>> easier, something else?
>>
>> My make believe answer that I found myself starting to make to my 
>> colleagues was that it was for ease of writing a parser, but then I wasn't 
>> sure how this squares with the fact that languages like python and haskell 
>> don't seem to have too much trouble w/out braces or end keywords.
>>
>> Just curious,
>>
>> dustin
>>
>
>

Re: [julia-users] purpose of the end keyword

[Stefan Karpinski]

The `end` keyword closes blocks. Python uses indentation for this. In Julia
indentation is not significant.


On Thu, May 15, 2014 at 2:51 PM, Dustin Lee  wrote:

> Coming from python I've found that julias's "end" statement doesn't bother
> me as much as I would have thought, but when I show some code to my python
> colleagues this really annoys them.  But this got me thinking, what *is*
> the purpose of "end".  Is it just a taste issue, a way to make parsing
> easier, something else?
>
> My make believe answer that I found myself starting to make to my
> colleagues was that it was for ease of writing a parser, but then I wasn't
> sure how this squares with the fact that languages like python and haskell
> don't seem to have too much trouble w/out braces or end keywords.
>
> Just curious,
>
> dustin
>

[julia-users] purpose of the end keyword

[Dustin Lee]

Coming from python I've found that julias's "end" statement doesn't bother 
me as much as I would have thought, but when I show some code to my python 
colleagues this really annoys them.  But this got me thinking, what *is* 
the purpose of "end".  Is it just a taste issue, a way to make parsing 
easier, something else?

My make believe answer that I found myself starting to make to my 
colleagues was that it was for ease of writing a parser, but then I wasn't 
sure how this squares with the fact that languages like python and haskell 
don't seem to have too much trouble w/out braces or end keywords.

Just curious,

dustin

Re: [julia-users] Trouble with Type Parameters

[Toivo Henningsson]

On Thursday, 15 May 2014 10:59:07 UTC+2, Tomas Lycken wrote:
>
> it silently uses :: in a different sense than anywhere else in the language
>
>
> I started writing a reply here, but realized it would be more instructive 
> to have it as an IJulia notebook, where we can actually inspect the values 
> of various statements along the way - take a look here instead: 
> http://nbviewer.ipython.org/github/tlycken/IJulia-Notebooks/blob/master/A%20more%20thorough%20look%20at%20Julia's%20%22double%20colon%22%20syntax.ipynb
>
> I hope it makes things a little clearer. I tried to base it on the 
> relevant section on `::` in the manual (
> http://docs.julialang.org/en/latest/manual/types/#type-declarations) and 
> expand it with more examples etc, so I hope it's possible to see the 
> connections.
>

Oh, it's quite clear to me. But do you agree that the usage of x::T as a 
formal parameter is quite different when T is a type parameter compared to 
when it is a plain type? Different enough that it's not really about an 
isarelationship anymore? To my mind, this should warrant using another 
operator than :: when T is a type parameter (though there's preciously few 
good operator symbols left, and it would be quite a disruptive change...).

 / Toivo

[julia-users] Re: build failure in vagrant/virtualbox?

[Patrick O'Leary]

Have you checked the Vagrantfile (and README) in contrib/vagrant? I don't 
exactly recall what all I ran into but I know I ended up relying on mostly 
system packages, ran into the AVX thing with VirtualBox, and had to work 
around the limitation that there are no symlinks in VirtualBox shared 
folders.

None of these look like the problem you're having, but I want to make sure 
you knew that it was there in case it's helpful.

On Sunday, May 11, 2014 11:13:28 AM UTC-5, S Wade wrote:
>
> Hi all,
>
> I'd appreciate help building julia HEAD.  We're prepping a VM for vagrant 
> deployment and the build process fails at the very end as it's 
> bootstrapping:
>
> ```
> deprecated.jl
> pkg.jl
> graphics.jl
> profile.jl
> precompile.jl
> Killed
> make[3]: *** [/home/vagrant/julia/usr/lib/julia/sys0.o] Error 137
> ```
>
> From googling it looked like it may be due to OpenBlas and AVX support 
> (which seems to build successfully but does warn about lack of AVX 
> support).  I tried compiling from scratch with `make 
> OPENBLAS_TARGET_ARCH=NEHALEM` but this doesn't seem to solve the problem. 
>  I also tried `make dist`.
>
> thanks,
> wade
>
>

[julia-users] Re: Fast, robust predicates with Julia

[Toivo Henningsson]

On Thursday, 15 May 2014 09:36:06 UTC+2, Ariel Keselman wrote:
>
> they are MIT licensed, no need for permission :)
>

Right, I missed that. Good :) 
 

> how efficient is Voroni construction using conic hulls, I think Qhull 
> which uses convex hulls is way slower than what I plan with the algorithms 
> described in here: http://arxiv.org/pdf/0901.4107v3.pdf
>

 Short answer: I don't think that it should have to be different.

Long anwser: The way that I see it, the difference is more about how you 
think about what you are doing than the actual implementation. I find that 
working with conic hulls unifies some concepts compared to Delaunay 
triangulations/Voronoi diagrams/power diagrams. (But they can be 
specialized again for efficiency.) The data structures and predicates are 
really the same. Perhaps the fact that Delaunay triangulations correspond 
to a special case of convex hulls (where all the points lie on a paraboloid 
surface) might allow some simplified algorithms compared to the general 
case, but those could still be implemented in the same framework.

Looking at the paper, the data structures are almost identical to what I 
use. A Delaunay triangulation in R^n corresponds to a conic hull in 
R^(n+2). I describe the mesh by the collection of facets of the conic hull; 
each facet is made up of n+1 generators and corresponds exactly to a 
simplex in the triangulation. For each facet i store the generators, 
keeping track of their positive orientation, and the neighboring facet 
opposite to each generator.

The Delaunay triangulation of a set of generators x_k in R^n can be found 
by taking the conic hull of the generators y_k,

y_k = [1, x_k, ||x_k||^2]

(whether we represent the generators as vectors in R^(n+2) or just store 
x_k is of course up to us.)
We actually only need the lower hull. One way to avoid constructing the 
upper hull is to add the generator

y_0 = [0, zeros(n), 1]

which I will call the *primary generator*. Note that it lies outside the 
paraboloid surface; since the conic hull is pretty much a conic hull in 
homogeneous coordinates it can be seen the infinity point that generators 
go to when ||x|| goes to infinity. By including the primary generator we 
get a complete conic hull without having to represent the upper hull (which 
would correspond to the furthest point Voronoi diagram). This makes it 
possible to insert generators outside the convex hull of the existing x_k 
without adding any special cases.

For conic hulls in R^(n+2), we only need one predicate: the sign of the 
determinant of n+2 generators (concatenated in some given order into a 
matrix). This can be seen as forming the linear function which is zero in 
the plane of the n+1 first generators, and evaluating it in the last one. 
The plane function can be evaluated with a partial determinant computation 
and could be stored with e.g. each facet. It gives homogeneous coordinates 
for the corresponding Voronoi/power diagram vertex.

With all generators on the paraboloid, the determinant predicate is 
equivalent to the determinant (3) in the paper (the in-circle test). With 
the primary generator as one of the generators, it reduces to the 
orientation test (4) in the paper. (Up to the sign of the permutation 
needed to bring out the primary generator to a fixed index in the list.) So 
the predicates are really the same.

If one doesn't want to have the primary generator in the hull, one could 
work with an incomplete hull where the links to the facets that would 
contain it are undefined. One would then have to make sure that the 
implicit facets would always remain as facets of the hull, analogous to not 
inserting generators into the Delaunay triangulation outside of the convex 
hull of the current ones.

I really liked the overview of different algorithms for Delaunay 
triangulations in the paper; I didn't know that the flipping method has 
such good perfomance in practice. I have considered it but haven't worked 
out yet how to make it foolproof in the case of generators in degenerate 
position, so I started with a method that I could. The method applied to a 
lower convex hull would mean to try to flip simplexes formed by adjacent 
facets if it increases the volume of the hull, and all new facets are still 
oriented downward.

So I think that what we want to achieve is actually very similar. I'm not 
interested in conic hulls for their own sake but for constructing 
Voronoi/power diagrams, and also in the specializations that apply to these 
cases. Now if/when I will get the time to go ahead and do all this stuff is 
another matter unfortunately...

Re: [julia-users] for loops

[John Myles White]

I kind of suspect Stefan, like me, would instinctively call this operation 
`each_with_index`.

 -- John

On May 15, 2014, at 6:33 AM, Kevin Squire  wrote:

> One nice thing about Julia is that she borrows many (though not all) good 
> ideas from other languages. In this case, enumerate came from Python 
> (although it likely has other incarnations).
> 
> Cheers!
>Kevin 
> 
> On Thursday, May 15, 2014, Billou Bielour  wrote:
> I was thinking the same thing the other day, when using for x in xs I often 
> find myself needing an index at some point and then I have to change the for 
> loop, or write an index manually.
> 
> Enumerate is exactly what I need in this case. 
> 
> +1 for Julia
> 

Re: [julia-users] Optimisation troubles

[Adrian Cuthbertson]

Hi Tom,

I've had good use of NLopt with GP optimisation. I plan in due course to
package and release the GP stuff I've been working on, but not for a few
weeks yet. However, for now here are the functions I use for NLopt...

function optinf(gp::GPmodel, maxopt; algo=:LD_LBFGS,
l_b=Float64[],u_b=Float64[], with_dnlz=true)
# :LN_COBYLA :LD_LBFGS
prms = getHypers(gp)
f = (parms::Vector, grads::Vector) -> optfn(parms, grads, gp,
with_dnlz=with_dnlz)
opt = NLopt.Opt(algo, length(prms));
#opt = NLopt.Opt(:LN_COBYLA, length(prms));
NLopt.maxeval!(opt, maxopt)
if length(l_b) > 0
NLopt.lower_bounds!(opt, l_b)
end
if length(u_b) > 0
NLopt.upper_bounds!(opt, u_b)
end
NLopt.min_objective!(opt, f)
(optf,optx,ret) = NLopt.optimize(opt,prms)
end

function optfn(parms::Vector, grads::Vector, gp::GPmodel;
with_dnlz=with_dnlz)
if !with_dnlz && length(grads) > 0
error("with_dnlz is false, but len grads > 0")
end
setHypers(gp,parms);
post,nlZ,dnlZ = inference(gp, with_dnlz=with_dnlz)
if with_dnlz && length(grads) > 0
for j=1:length(dnlZ)
grads[j] = dnlZ[j]
end
end
return nlZ[1]
end

optinf sets up NLopt and creates a closure over the objective function
optfn, which captures the initial parameters, gp (the GPmodel) and
with_dnlz which lets the gp model know whether we need derivatives. The
inference function performs exact inferencing over the current
hyper-parameters and *most importantly* returns the gradients (if needed),
which *must* be copied into grads as is shown. That's where I battled in
the beginning.

Sorry this is a bit complex without the rest of my GPmodel context, but
hopefully that will get you on the right track in terms of using NLopt.

- Adrian.





On Thu, May 15, 2014 at 12:23 PM, Tom Nickson  wrote:

> Hi all,
>
> I am trying to optimise the log-likelihood of the Gaussian Process. This
> is a straight port of some code form MATLAB, so I know the gradients are
> correct. Using Optim.jl I don't have too many problems (I was one told
> "dphia < 0" however I can't replicate it).
> Using NLopt, which the documentation seems to imply should be more stable,
> I regularly get failures if I try to run for more than a couple of
> iterations - generally it will work with 5 to 10, no more. The exit code is
> quite unhelpful, simply "NLopt failure". I have no problems running
> non-gradient based methods, (eg COBYLA) which would lead me to think my
> gradients where incorrect - except that they work in MATLAB and with
> Optim.jl, and checkout with finite differencing.
>
> Any ideas of how to start debugging this? I could do with being able to
> apply constraints.
>
> Tom
>

[julia-users] Re: Macro question

[Abe Schneider]

That works, thanks! 


On Thursday, May 15, 2014 8:00:29 AM UTC-4, Mike Innes wrote:
>
> Oh, the other thing I should point out (sorry to post repeatedly) is that 
> the macro hygiene pass will mean that `foo` is not actually defined by this 
> macro. You probably want:
>
> macro createVar(name, value)
>   quote
> $(esc(name)) = $value;
>   end
> end
>
> See the 
> hygienesection
>  of the manual.
>
> On Thursday, 15 May 2014 12:53:13 UTC+1, Mike Innes wrote:
>>
>> Alternatively
>>
>> macroexpand(:@createVar(foo, 5))
>>
>> Might have the desired behaviour.
>>
>>
>> On Thursday, 15 May 2014 12:51:15 UTC+1, Mike Innes wrote:
>>>
>>> I think your second snippet must have gotten a bit muddled, since `expr` 
>>> should end up with the value 5.
>>>
>>> macro createVar(name, value)
>>>   quote
>>> $name = $value;
>>>   end
>>> end
>>>
>>> expr = @createVar foo 5
>>> # This is equivalent to `expr = (foo = 5)`, *not* `expr = :(foo = 5)`
>>>
>>> expr == 5
>>>
>>> If you do want `createVar` to return an expression, it should be a 
>>> function instead of a macro. Maybe try running the example again to check 
>>> it's behaving in the expected way?
>>>
>>>
>>> On Thursday, 15 May 2014 12:29:13 UTC+1, Abe Schneider wrote:

 As an experiment I wrote a simple macro to set a variable:

 macro createVar(name, value)
   eval(quote
 $name = $value;
   end)
 end

 which works as expected:

 @createVar foobar 5;
 println("foobar = $foobar"); # "foobar = 5" (OK)

 However, if I instead do:

 macro createVar(name, value)
   quote
 $name = $value;
   end
 end

 expr = @createVar(foobar, 5);

 println("$expr"); # "foobar = 5" (OK)

 # now evaluate the expression to do the actual assignment
 eval(expr);
 println("foobar = $foobar");

 I get "ERROR: foobar not defined". I would expect that if I do the eval 
 outside of the macro I should get the same result as doing the eval inside 
 the macro. Is this expected behavior?

 I should add that I'm using a version of 0.3 from the repository.

>>>

[julia-users] Re: Macro question

[Abe Schneider]

You are correct -- it's weird, because I'm sure I tested it several times 
before posting, but I now get '5', as you suggest.

On Thursday, May 15, 2014 7:51:15 AM UTC-4, Mike Innes wrote:
>
> I think your second snippet must have gotten a bit muddled, since `expr` 
> should end up with the value 5.
>
> macro createVar(name, value)
>   quote
> $name = $value;
>   end
> end
>
> expr = @createVar foo 5
> # This is equivalent to `expr = (foo = 5)`, *not* `expr = :(foo = 5)`
>
> expr == 5
>
> If you do want `createVar` to return an expression, it should be a 
> function instead of a macro. Maybe try running the example again to check 
> it's behaving in the expected way?
>
>
> On Thursday, 15 May 2014 12:29:13 UTC+1, Abe Schneider wrote:
>>
>> As an experiment I wrote a simple macro to set a variable:
>>
>> macro createVar(name, value)
>>   eval(quote
>> $name = $value;
>>   end)
>> end
>>
>> which works as expected:
>>
>> @createVar foobar 5;
>> println("foobar = $foobar"); # "foobar = 5" (OK)
>>
>> However, if I instead do:
>>
>> macro createVar(name, value)
>>   quote
>> $name = $value;
>>   end
>> end
>>
>> expr = @createVar(foobar, 5);
>>
>> println("$expr"); # "foobar = 5" (OK)
>>
>> # now evaluate the expression to do the actual assignment
>> eval(expr);
>> println("foobar = $foobar");
>>
>> I get "ERROR: foobar not defined". I would expect that if I do the eval 
>> outside of the macro I should get the same result as doing the eval inside 
>> the macro. Is this expected behavior?
>>
>> I should add that I'm using a version of 0.3 from the repository.
>>
>

Re: [julia-users] for loops

[Yakir Gagnon]

Love the Lazy thing, I'm real tempted to use lazy more, will do once I'm
more sure of what I'm doing.


Yakir Gagnon
The Queensland Brain Institute (Building #79)
The University of Queensland
Brisbane QLD 4072
Australia

cell +61 (0)424 393 332
work +61 (0)733 654 089


On Thu, May 15, 2014 at 11:39 PM, Yakir Gagnon <12.ya...@gmail.com> wrote:

> OMG. So awesome! Thanks!!!
>
>
> Yakir Gagnon
> The Queensland Brain Institute (Building #79)
> The University of Queensland
> Brisbane QLD 4072
> Australia
>
> cell +61 (0)424 393 332
> work +61 (0)733 654 089
>
>
> On Thu, May 15, 2014 at 11:33 PM, Kevin Squire wrote:
>
>> One nice thing about Julia is that she borrows many (though not all) good
>> ideas from other languages. In this case, enumerate came from Python
>> (although it likely has other incarnations).
>>
>> Cheers!
>> Kevin
>>
>>
>> On Thursday, May 15, 2014, Billou Bielour 
>> wrote:
>>
>>> I was thinking the same thing the other day, when using *for x in xs* I
>>> often find myself needing an index at some point and then I have to change
>>> the for loop, or write an index manually.
>>>
>>> Enumerate is exactly what I need in this case.
>>>
>>> +1 for Julia
>>>
>>>
>

Re: [julia-users] for loops

[Yakir Gagnon]

OMG. So awesome! Thanks!!!


Yakir Gagnon
The Queensland Brain Institute (Building #79)
The University of Queensland
Brisbane QLD 4072
Australia

cell +61 (0)424 393 332
work +61 (0)733 654 089


On Thu, May 15, 2014 at 11:33 PM, Kevin Squire wrote:

> One nice thing about Julia is that she borrows many (though not all) good
> ideas from other languages. In this case, enumerate came from Python
> (although it likely has other incarnations).
>
> Cheers!
>Kevin
>
>
> On Thursday, May 15, 2014, Billou Bielour  wrote:
>
>> I was thinking the same thing the other day, when using *for x in xs* I
>> often find myself needing an index at some point and then I have to change
>> the for loop, or write an index manually.
>>
>> Enumerate is exactly what I need in this case.
>>
>> +1 for Julia
>>
>>

Re: [julia-users] for loops

[Mike Innes]

You may also be interested in zip:

for (file, i) in zip(files, 1:length(files))
  println(file, " ", i)
end

# Even better:
using Lazy

for (file, i) in zip(files, range())
  println(file, " ", i)
end

Enumerate is definitely the best solution here, but zip is more general if 
you find yourself bumping against similar problems.


On Thursday, 15 May 2014 14:00:09 UTC+1, Michele Zaffalon wrote:
>
> What about enumerate: 
> http://docs.julialang.org/en/latest/stdlib/base/?highlight=enumerate#Base.enumerate?
>
>
> On Thu, May 15, 2014 at 2:48 PM, Yakir Gagnon <12.y...@gmail.com
> > wrote:
>
>> I love the 
>> for file in files
>> ... do something with file ...
>> end
>>
>> syntax. But sometimes it's really useful to be able to have an iterator 
>> accessible in the for loop, like:
>>
>> for file in files
>> ... do something with file ...
>> ... and with i that equals find(file == files) ...
>> end
>>
>>
>> Is there something built in like that, other than the usual way of:
>>
>> for i = 1:length(files)
>> ... do something with files(i) ...
>> ... and with i ...
>> end
>>
>> ?
>>
>
>

Re: [julia-users] for loops

[Kevin Squire]

One nice thing about Julia is that she borrows many (though not all) good
ideas from other languages. In this case, enumerate came from Python
(although it likely has other incarnations).

Cheers!
   Kevin

On Thursday, May 15, 2014, Billou Bielour  wrote:

> I was thinking the same thing the other day, when using *for x in xs* I
> often find myself needing an index at some point and then I have to change
> the for loop, or write an index manually.
>
> Enumerate is exactly what I need in this case.
>
> +1 for Julia
>
>

Re: [julia-users] for loops

[Billou Bielour]

I was thinking the same thing the other day, when using *for x in xs* I 
often find myself needing an index at some point and then I have to change 
the for loop, or write an index manually.

Enumerate is exactly what I need in this case. 

+1 for Julia

Re: [julia-users] for loops

[Michele Zaffalon]

What about enumerate:
http://docs.julialang.org/en/latest/stdlib/base/?highlight=enumerate#Base.enumerate?


On Thu, May 15, 2014 at 2:48 PM, Yakir Gagnon <12.ya...@gmail.com> wrote:

> I love the
> for file in files
> ... do something with file ...
> end
>
> syntax. But sometimes it's really useful to be able to have an iterator
> accessible in the for loop, like:
>
> for file in files
> ... do something with file ...
> ... and with i that equals find(file == files) ...
> end
>
>
> Is there something built in like that, other than the usual way of:
>
> for i = 1:length(files)
> ... do something with files(i) ...
> ... and with i ...
> end
>
> ?
>

[julia-users] for loops

[Yakir Gagnon]

I love the 
for file in files
... do something with file ...
end

syntax. But sometimes it's really useful to be able to have an iterator 
accessible in the for loop, like:

for file in files
... do something with file ...
... and with i that equals find(file == files) ...
end


Is there something built in like that, other than the usual way of:

for i = 1:length(files)
... do something with files(i) ...
... and with i ...
end

?

[julia-users] Re: ODBC query: arrayset not defined

[Andrew B. Martin]

Thanks for your response Jacob!

I'm still getting the error, so I'll open an issue.

Cheers,
Andrew

[julia-users] Re: Macro question

[Mike Innes]

Oh, the other thing I should point out (sorry to post repeatedly) is that 
the macro hygiene pass will mean that `foo` is not actually defined by this 
macro. You probably want:

macro createVar(name, value)
  quote
$(esc(name)) = $value;
  end
end

See the 
hygienesection
 of the manual.

On Thursday, 15 May 2014 12:53:13 UTC+1, Mike Innes wrote:
>
> Alternatively
>
> macroexpand(:@createVar(foo, 5))
>
> Might have the desired behaviour.
>
>
> On Thursday, 15 May 2014 12:51:15 UTC+1, Mike Innes wrote:
>>
>> I think your second snippet must have gotten a bit muddled, since `expr` 
>> should end up with the value 5.
>>
>> macro createVar(name, value)
>>   quote
>> $name = $value;
>>   end
>> end
>>
>> expr = @createVar foo 5
>> # This is equivalent to `expr = (foo = 5)`, *not* `expr = :(foo = 5)`
>>
>> expr == 5
>>
>> If you do want `createVar` to return an expression, it should be a 
>> function instead of a macro. Maybe try running the example again to check 
>> it's behaving in the expected way?
>>
>>
>> On Thursday, 15 May 2014 12:29:13 UTC+1, Abe Schneider wrote:
>>>
>>> As an experiment I wrote a simple macro to set a variable:
>>>
>>> macro createVar(name, value)
>>>   eval(quote
>>> $name = $value;
>>>   end)
>>> end
>>>
>>> which works as expected:
>>>
>>> @createVar foobar 5;
>>> println("foobar = $foobar"); # "foobar = 5" (OK)
>>>
>>> However, if I instead do:
>>>
>>> macro createVar(name, value)
>>>   quote
>>> $name = $value;
>>>   end
>>> end
>>>
>>> expr = @createVar(foobar, 5);
>>>
>>> println("$expr"); # "foobar = 5" (OK)
>>>
>>> # now evaluate the expression to do the actual assignment
>>> eval(expr);
>>> println("foobar = $foobar");
>>>
>>> I get "ERROR: foobar not defined". I would expect that if I do the eval 
>>> outside of the macro I should get the same result as doing the eval inside 
>>> the macro. Is this expected behavior?
>>>
>>> I should add that I'm using a version of 0.3 from the repository.
>>>
>>

Re: [julia-users] Re: [ANN] Julia + Light Table!

[Marcus Kriele]

To me it looks as if the shell unquotes your argument and then interprets 
your string as two strings, "/Users/feldt/Library/Application " and 
"Support/LightTable/plugins/Jewel/jl/init.jl". I would try to copy the 
folder "LightTable" and all its contents to a location without spaces in 
the path and then try to call it from there.  

On Tuesday, May 13, 2014 7:50:04 AM UTC-4, Robert Feldt wrote:
>
> Unfortunately after a restart I'm even more confused. Something might be 
> very weird with my setup. If anyone has pointers I'd appreciate them though:
>
> feldt:~$ which julia
> /usr/local/bin/julia
> feldt:~$ ls -al /usr/local/bin/julia
> lrwxr-xr-x  1 feldt  admin  64 13 Maj 13:47 /usr/local/bin/julia -> 
> /Applications/Julia-0.2.1.app/Contents/Resources/julia/bin/julia
> feldt:~$ julia "/Users/feldt/Library/Application 
> Support/LightTable/plugins/Jewel/jl/init.jl"
> ERROR: could not open file /Users/feldt/Library/Application
>  in include at boot.jl:238
>  in include_from_node1 at loading.jl:114
>  in process_options at client.jl:303
>  in _start at client.jl:389
>
> feldt:~$ /Applications/Julia-0.2.1.app/Contents/Resources/julia/bin/julia 
> "/Users/feldt/Library/Application 
> Support/LightTable/plugins/Jewel/jl/init.jl"
> ERROR: BoundsError()
>  in indexed_next at tuple.jl:20
>  in include at boot.jl:238
>  in include_from_node1 at loading.jl:114
>  in process_options at client.jl:303
>  in _start at client.jl:389
> at /Users/feldt/Library/Application 
> Support/LightTable/plugins/Jewel/jl/init.jl:1
>
> /Robert
>
>>

[julia-users] Re: Macro question

[Mike Innes]

Alternatively

macroexpand(:@createVar(foo, 5))

Might have the desired behaviour.


On Thursday, 15 May 2014 12:51:15 UTC+1, Mike Innes wrote:
>
> I think your second snippet must have gotten a bit muddled, since `expr` 
> should end up with the value 5.
>
> macro createVar(name, value)
>   quote
> $name = $value;
>   end
> end
>
> expr = @createVar foo 5
> # This is equivalent to `expr = (foo = 5)`, *not* `expr = :(foo = 5)`
>
> expr == 5
>
> If you do want `createVar` to return an expression, it should be a 
> function instead of a macro. Maybe try running the example again to check 
> it's behaving in the expected way?
>
>
> On Thursday, 15 May 2014 12:29:13 UTC+1, Abe Schneider wrote:
>>
>> As an experiment I wrote a simple macro to set a variable:
>>
>> macro createVar(name, value)
>>   eval(quote
>> $name = $value;
>>   end)
>> end
>>
>> which works as expected:
>>
>> @createVar foobar 5;
>> println("foobar = $foobar"); # "foobar = 5" (OK)
>>
>> However, if I instead do:
>>
>> macro createVar(name, value)
>>   quote
>> $name = $value;
>>   end
>> end
>>
>> expr = @createVar(foobar, 5);
>>
>> println("$expr"); # "foobar = 5" (OK)
>>
>> # now evaluate the expression to do the actual assignment
>> eval(expr);
>> println("foobar = $foobar");
>>
>> I get "ERROR: foobar not defined". I would expect that if I do the eval 
>> outside of the macro I should get the same result as doing the eval inside 
>> the macro. Is this expected behavior?
>>
>> I should add that I'm using a version of 0.3 from the repository.
>>
>

[julia-users] Re: Macro question

[Mike Innes]

I think your second snippet must have gotten a bit muddled, since `expr` 
should end up with the value 5.

macro createVar(name, value)
  quote
$name = $value;
  end
end

expr = @createVar foo 5
# This is equivalent to `expr = (foo = 5)`, *not* `expr = :(foo = 5)`

expr == 5

If you do want `createVar` to return an expression, it should be a function 
instead of a macro. Maybe try running the example again to check it's 
behaving in the expected way?


On Thursday, 15 May 2014 12:29:13 UTC+1, Abe Schneider wrote:
>
> As an experiment I wrote a simple macro to set a variable:
>
> macro createVar(name, value)
>   eval(quote
> $name = $value;
>   end)
> end
>
> which works as expected:
>
> @createVar foobar 5;
> println("foobar = $foobar"); # "foobar = 5" (OK)
>
> However, if I instead do:
>
> macro createVar(name, value)
>   quote
> $name = $value;
>   end
> end
>
> expr = @createVar(foobar, 5);
>
> println("$expr"); # "foobar = 5" (OK)
>
> # now evaluate the expression to do the actual assignment
> eval(expr);
> println("foobar = $foobar");
>
> I get "ERROR: foobar not defined". I would expect that if I do the eval 
> outside of the macro I should get the same result as doing the eval inside 
> the macro. Is this expected behavior?
>
> I should add that I'm using a version of 0.3 from the repository.
>

Re: [julia-users] Optimisation troubles

[Hans W Borchers]

Which of the optimization solvers in NLopt are you talking about, there are 
many.

I am a contributor to the 'nloptr' R package and my experience is that 
most/all 
of the solvers in NLopt are accurate and more reliable than any of the 
(many!) 
optimization functions in R.

PS: Might be better to ask such wuestions on the "julia-opt" mailing list, 
perhaps some of the Julia optimization specialist are more inclined to 
answer 
questions there.


On Thursday, May 15, 2014 12:51:20 PM UTC+2, Tim Holy wrote:
>
> I've had similar experiences. For me, Optim.jl is currently somewhat more 
> reliable than NLopt, although it's not as if Optim.jl is without its 
> problems. 
> I confess I haven't tried hard to track down what's happening with NLopt. 
> In 
> Optim, there's a branch, teh/constrained, which contains some 
> not-yet-worthy- 
> of-merging work but which (in my hands) further enhances Optim's 
> reliability. 
> If you like, you can check that branch out yourself and experiment with 
> it. 
>
> Another alternative to consider is JuMP/Ipopt; I don't yet have a lot of 
> experience with it, but Ipopt is well-respected. 
>
> Best, 
> --Tim 
>
> On Thursday, May 15, 2014 03:23:56 AM Tom Nickson wrote: 
> > Hi all, 
> > 
> > I am trying to optimise the log-likelihood of the Gaussian Process. This 
> is 
> > a straight port of some code form MATLAB, so I know the gradients are 
> > correct. Using Optim.jl I don't have too many problems (I was one told 
> > "dphia < 0" however I can't replicate it). 
> > Using NLopt, which the documentation seems to imply should be more 
> stable, 
> > I regularly get failures if I try to run for more than a couple of 
> > iterations - generally it will work with 5 to 10, no more. The exit code 
> is 
> > quite unhelpful, simply "NLopt failure". I have no problems running 
> > non-gradient based methods, (eg COBYLA) which would lead me to think my 
> > gradients where incorrect - except that they work in MATLAB and with 
> > Optim.jl, and checkout with finite differencing. 
> > 
> > Any ideas of how to start debugging this? I could do with being able to 
> > apply constraints. 
> > 
> > Tom 
>

[julia-users] Macro question

[Abe Schneider]

As an experiment I wrote a simple macro to set a variable:

macro createVar(name, value)
  eval(quote
$name = $value;
  end)
end

which works as expected:

@createVar foobar 5;
println("foobar = $foobar"); # "foobar = 5" (OK)

However, if I instead do:

macro createVar(name, value)
  quote
$name = $value;
  end
end

expr = @createVar(foobar, 5);

println("$expr"); # "foobar = 5" (OK)

# now evaluate the expression to do the actual assignment
eval(expr);
println("foobar = $foobar");

I get "ERROR: foobar not defined". I would expect that if I do the eval 
outside of the macro I should get the same result as doing the eval inside 
the macro. Is this expected behavior?

I should add that I'm using a version of 0.3 from the repository.

Re: [julia-users] Trouble with Type Parameters

[Mauro]

> Although instructive, that example is almost identical to the corresponding 
> doc section 
> (http://julia.readthedocs.org/en/latest/manual/methods/#parametric-methods) 
> so I doubt I could add much value other than a link to the docs ;)

But isn't, for instance, your first examples also in the doc?

Anyways, playing around with your first example, I encountered this
feature which seem like a bug to me:

julia> bar1(x) = x::Real
bar1 (generic function with 1 method)

julia> bar2(x) = (x::Real;x)
bar2 (generic function with 1 method)

julia> bar3(x) = (x::Real;x=x;x)
bar3 (generic function with 1 method)

julia> bar4(x) = x::Real=x
bar4 (generic function with 1 method)

julia> bar1(3+0im)
ERROR: type: typeassert: expected Real, got Complex{Int64}
 in bar1 at none:1

julia> bar2(3+0im)
3 + 0im

julia> bar3(3+0im)
3

julia> bar4(3+0im)
3

Is this a bug?  I would expect all to behave like bar3 & bar4, namely
the declare-and-convert behavior.  Not the assert behavior from bar1,
and no-op from bar2.

See last paragraph of:
http://julia.readthedocs.org/en/latest/manual/types/#type-declarations

> // T
>
> On Thursday, May 15, 2014 11:39:53 AM UTC+2, Mauro wrote:
>>
>> This is a good summary, cheers. 
>>
>> Maybe you include an example of a parametric function as well as was 
>> discussed in this tread earlier?  For instance: 
>>
>> julia> foofoo{T<:Real}(x::T,y::T) = x 
>> foofoo (generic function with 1 method) 
>>
>> julia> barbar(x::Real,y::Real) = x 
>> barbar (generic function with 1 method) 
>>
>> julia> foofoo(3//2,2) 
>> ERROR: no method foofoo(Rational{Int64}, Int64) 
>>
>> julia> barbar(3//2,2) 
>> 3//2 
>>
>> Then, for reference, I've been musing about this a few month ago too: 
>> https://groups.google.com/d/msg/julia-dev/pGvM_QVmjX4/V6OdzhwoIykJ 
>> and here it get discussed a bit too: 
>> https://github.com/JuliaLang/julia/issues/1090 
>>
>>
>> On Thu, 2014-05-15 at 09:59, tomas@gmail.com  wrote: 
>> >> 
>> >> it silently uses :: in a different sense than anywhere else in the 
>> language 
>> > 
>> > 
>> > I started writing a reply here, but realized it would be more 
>> instructive 
>> > to have it as an IJulia notebook, where we can actually inspect the 
>> values 
>> > of various statements along the way - take a look here 
>> > instead: 
>> http://nbviewer.ipython.org/github/tlycken/IJulia-Notebooks/blob/master/A%20more%20thorough%20look%20at%20Julia's%20%22double%20colon%22%20syntax.ipynb
>>  
>> > 
>> > I hope it makes things a little clearer. I tried to base it on the 
>> relevant 
>> > section on `::` in the manual 
>> > (http://docs.julialang.org/en/latest/manual/types/#type-declarations) 
>> and 
>> > expand it with more examples etc, so I hope it's possible to see the 
>> > connections. 
>> > 
>> > // T 
>>

-- 

Re: [julia-users] Optimisation troubles

[Tim Holy]

I've had similar experiences. For me, Optim.jl is currently somewhat more 
reliable than NLopt, although it's not as if Optim.jl is without its problems. 
I confess I haven't tried hard to track down what's happening with NLopt. In 
Optim, there's a branch, teh/constrained, which contains some not-yet-worthy-
of-merging work but which (in my hands) further enhances Optim's reliability. 
If you like, you can check that branch out yourself and experiment with it.

Another alternative to consider is JuMP/Ipopt; I don't yet have a lot of 
experience with it, but Ipopt is well-respected.

Best,
--Tim

On Thursday, May 15, 2014 03:23:56 AM Tom Nickson wrote:
> Hi all,
> 
> I am trying to optimise the log-likelihood of the Gaussian Process. This is
> a straight port of some code form MATLAB, so I know the gradients are
> correct. Using Optim.jl I don't have too many problems (I was one told
> "dphia < 0" however I can't replicate it).
> Using NLopt, which the documentation seems to imply should be more stable,
> I regularly get failures if I try to run for more than a couple of
> iterations - generally it will work with 5 to 10, no more. The exit code is
> quite unhelpful, simply "NLopt failure". I have no problems running
> non-gradient based methods, (eg COBYLA) which would lead me to think my
> gradients where incorrect - except that they work in MATLAB and with
> Optim.jl, and checkout with finite differencing.
> 
> Any ideas of how to start debugging this? I could do with being able to
> apply constraints.
> 
> Tom

Re: [julia-users] Trouble with Type Parameters

[Tomas Lycken]

Although instructive, that example is almost identical to the corresponding 
doc section 
(http://julia.readthedocs.org/en/latest/manual/methods/#parametric-methods) 
so I doubt I could add much value other than a link to the docs ;)

// T

On Thursday, May 15, 2014 11:39:53 AM UTC+2, Mauro wrote:
>
> This is a good summary, cheers. 
>
> Maybe you include an example of a parametric function as well as was 
> discussed in this tread earlier?  For instance: 
>
> julia> foofoo{T<:Real}(x::T,y::T) = x 
> foofoo (generic function with 1 method) 
>
> julia> barbar(x::Real,y::Real) = x 
> barbar (generic function with 1 method) 
>
> julia> foofoo(3//2,2) 
> ERROR: no method foofoo(Rational{Int64}, Int64) 
>
> julia> barbar(3//2,2) 
> 3//2 
>
> Then, for reference, I've been musing about this a few month ago too: 
> https://groups.google.com/d/msg/julia-dev/pGvM_QVmjX4/V6OdzhwoIykJ 
> and here it get discussed a bit too: 
> https://github.com/JuliaLang/julia/issues/1090 
>
>
> On Thu, 2014-05-15 at 09:59, tomas@gmail.com  wrote: 
> >> 
> >> it silently uses :: in a different sense than anywhere else in the 
> language 
> > 
> > 
> > I started writing a reply here, but realized it would be more 
> instructive 
> > to have it as an IJulia notebook, where we can actually inspect the 
> values 
> > of various statements along the way - take a look here 
> > instead: 
> http://nbviewer.ipython.org/github/tlycken/IJulia-Notebooks/blob/master/A%20more%20thorough%20look%20at%20Julia's%20%22double%20colon%22%20syntax.ipynb
>  
> > 
> > I hope it makes things a little clearer. I tried to base it on the 
> relevant 
> > section on `::` in the manual 
> > (http://docs.julialang.org/en/latest/manual/types/#type-declarations) 
> and 
> > expand it with more examples etc, so I hope it's possible to see the 
> > connections. 
> > 
> > // T 
>

[julia-users] Optimisation troubles

[Tom Nickson]

Hi all,

I am trying to optimise the log-likelihood of the Gaussian Process. This is 
a straight port of some code form MATLAB, so I know the gradients are 
correct. Using Optim.jl I don't have too many problems (I was one told 
"dphia < 0" however I can't replicate it). 
Using NLopt, which the documentation seems to imply should be more stable, 
I regularly get failures if I try to run for more than a couple of 
iterations - generally it will work with 5 to 10, no more. The exit code is 
quite unhelpful, simply "NLopt failure". I have no problems running 
non-gradient based methods, (eg COBYLA) which would lead me to think my 
gradients where incorrect - except that they work in MATLAB and with 
Optim.jl, and checkout with finite differencing.

Any ideas of how to start debugging this? I could do with being able to 
apply constraints.

Tom

Re: [julia-users] Trouble with Type Parameters

[Mauro]

This is a good summary, cheers.

Maybe you include an example of a parametric function as well as was
discussed in this tread earlier?  For instance:

julia> foofoo{T<:Real}(x::T,y::T) = x
foofoo (generic function with 1 method)

julia> barbar(x::Real,y::Real) = x
barbar (generic function with 1 method)

julia> foofoo(3//2,2)
ERROR: no method foofoo(Rational{Int64}, Int64)

julia> barbar(3//2,2)
3//2

Then, for reference, I've been musing about this a few month ago too:
https://groups.google.com/d/msg/julia-dev/pGvM_QVmjX4/V6OdzhwoIykJ
and here it get discussed a bit too:
https://github.com/JuliaLang/julia/issues/1090


On Thu, 2014-05-15 at 09:59, tomas.lyc...@gmail.com wrote:
>>
>> it silently uses :: in a different sense than anywhere else in the language
>
>
> I started writing a reply here, but realized it would be more instructive 
> to have it as an IJulia notebook, where we can actually inspect the values 
> of various statements along the way - take a look here 
> instead: 
> http://nbviewer.ipython.org/github/tlycken/IJulia-Notebooks/blob/master/A%20more%20thorough%20look%20at%20Julia's%20%22double%20colon%22%20syntax.ipynb
>
> I hope it makes things a little clearer. I tried to base it on the relevant 
> section on `::` in the manual 
> (http://docs.julialang.org/en/latest/manual/types/#type-declarations) and 
> expand it with more examples etc, so I hope it's possible to see the 
> connections.
>
> // T

Re: [julia-users] Trouble with Type Parameters

[Tomas Lycken]

>
> it silently uses :: in a different sense than anywhere else in the language


I started writing a reply here, but realized it would be more instructive 
to have it as an IJulia notebook, where we can actually inspect the values 
of various statements along the way - take a look here 
instead: 
http://nbviewer.ipython.org/github/tlycken/IJulia-Notebooks/blob/master/A%20more%20thorough%20look%20at%20Julia's%20%22double%20colon%22%20syntax.ipynb

I hope it makes things a little clearer. I tried to base it on the relevant 
section on `::` in the manual 
(http://docs.julialang.org/en/latest/manual/types/#type-declarations) and 
expand it with more examples etc, so I hope it's possible to see the 
connections.

// T

[julia-users] Re: Fast, robust predicates with Julia

[Ariel Keselman]

they are MIT licensed, no need for permission :)

how efficient is Voroni construction using conic hulls, I think Qhull which 
uses convex hulls is way slower than what I plan with the algorithms 
described in here: http://arxiv.org/pdf/0901.4107v3.pdf