Re: [julia-users] Re: optim stopping without reaching convergence
We have an alternate implementation at gonum that's BSD. https://godoc.org/github.com/gonum/optimize#NelderMead Should be pretty easy to wrap your function through command line calls. I'm happy to help if you'd like it. On Monday, January 25, 2016 at 3:39:16 AM UTC-7, Tim Holy wrote: > > If you think there's a bug, one thing you can do is compare Julia's > implementation to another implementation for the same problem and same > starting point. You have to be careful not to read code that has an > incompatible license (either proprietary or GPL), or you become "tainted" > and > can't contribute fixes related to anything you read. > > One safe thing to do is modify your own objective function simply to print > out > the location it's being fed for evaluation---that way you can find out > whether > the sequence of points is the same, without ever looking at the > algorithm's > source code. You can control the initial step with the `initial_step` > keyword. > > --Tim > > On Monday, January 25, 2016 12:15:16 AM Patrick Kofod Mogensen wrote: > > How did you verify that? Or are you guessing? Did you @show the > iteration > > counter's increment? If not, how do you know it starts high? > > > > On Sunday, January 24, 2016 at 7:45:48 PM UTC+1, grande...@gmail.com > wrote: > > > thanks but that s not the issue. for some reasons. the number of > > > iterations is really high to begin with > > > > > > On Friday, January 22, 2016 at 7:01:56 PM UTC-6, Kristoffer Carlsson > wrote: > > >> Look at the source > > >> https://github.com/JuliaOpt/Optim.jl/blob/master/src/nelder_mead.jl > > >> The number of iterations is not necessarily the same as the number of > > >> objective function evaluations > >
[julia-users] Re: Fw: Fwd: [External-faculty] Silicon Valley Start-Up Software Engineer Position
I got that email too!
Re: [julia-users] Re: Order of multiple for-loops
On Thursday, October 29, 2015 at 9:11:27 PM UTC-6, Steven G. Johnson wrote: > > > > On Thursday, October 29, 2015 at 1:24:23 PM UTC-4, Stefan Karpinski wrote: >> >> Yes, this is an unfortunate consequence of mathematics being column-major >> – oh how I wish it weren't so. >> > > I'm not sure what you mean by "mathematics being column major". Fortran > is column-major, and a lot of the linear-algebra libraries (LAPACK etc.) > are column-major in consequence, and Matlab is column-major. > > However, if Julia had chosen row-major, it would have been possible with a > little care to call LAPACK and other column-major libraries without making > a copy of any data, basically because for every linear-algebra operation > there is an equivalent operation on the transpose of the matrix. > It's not that simple. QR decomposition (dqeqrf) does not allow you to specify the transpose of the matrix directly. Sure, you can compute A^T instead, but then it's trickier to use the result to do the follow-on operations like linear solving and computing the condition number.
[julia-users] Re: Help on optimization problem
> 2. (JuMP Specific) - Should I specify my known positions as model > variables with equality constraints, or just normal julia variables that > show up in my objective function? > Don't specify them as equality constraints. Build your function with those variables removed from the optimization altogether. Perhaps that's what you meant by "normal julia variables"? In any event, unconstrained optimization is much more robust and mature, and you will likely get better results the fewer constraints you give.
Re: [julia-users] Julia and Object-Oriented Programming
On Friday, October 23, 2015 at 7:38:37 AM UTC-6, Abe Schneider wrote:
>
> An OO approach is really just specifying an interface in a formal manner.
> The second you write any type of interface, you always risk making a choice
> that will haunt you down the road. I don't see the difference between:
>
> class Foo {
> float getX() { ... }
> float getY() { ... }
> }
>
> and:
>
> type Foo { ... }
> function getX(f::Foo) -> float { ... }
> function getY(f::Foo) -> float { ... }
>
> except that an instance of `foo` is being passed implicitly in the first
> case. To that extent, I would say Julia OO (i.e. on the dispatching). Where
> it is not OO is in the layout of the data.
>
In some languages there is no difference. In Go, a method is exactly a
function that can be called with a special syntax. One can do
c := mat64.NewDense(5, 5, nil)
c.Mul(a, b)
or one can do
(*mat64.Dense).Mul(c, a, b)
There aren't many cases where one would actually want to do the latter, but
it makes the definition of behavior clear.
I think the difference in Julia would be the interaction with multiple
dispatch. In the former case, it seems like getX would live in its own
namespace (only accessible through the Foo class), while in the latter case
it would add to the many definitions of getX.
It is true that with a more OO language, because of its formalism, you run
> the risk of declaring variable types in a parent class that might not be
> correct in the child classes, so some planning is required. However, what
> you gain is better code in the long run. For example, I might have:
>
> abstract Baz
>
> type Foo <: Baz {
> x::Float
> }
>
> type Bar <: Baz {
> x::Float
> }
>
> and an interface:
>
> getX{T <: Baz}(b::T) -> Float = b.x
>
>
> which works fine, except maybe someone else comes along and writes:
>
> type Blob <: Baz {
> myX::Float
> }
>
> Now to fix your interface, you have to write a separate `getX` for `Blob`.
> This might not seem like a big deal, except you might not catch this issue
> until run time (I don't think there is a way a static-checker could
> identify the problem). Imagine a large library or base of code, with many
> people working on the code, and you suddenly are exposed to a large number
> of issues.
>
This seems more like an issue of compiler vs. no compiler issue than one
with OO vs. multiple dispatch.
You can do OO without inheritance (or OO like things if your definition of
OO includes inheritance). In Go, one would define
type GetXer interface {
GetX() float64
}
I could then write a function
func SquareX(g GetXer) float64 {
v := g.GetX()
return v * v
}
Now, any type that has a GetX method can be passed to SquareX. There is no
inheritance necessary to make this happen.
Re: [julia-users] Julia and Object-Oriented Programming
On Friday, October 23, 2015 at 7:22:28 AM UTC-6, Abe Schneider wrote:
>
> Ah, okay, that is different then. What's the advantage of creating a new
> method versus copying the fields? I would imagine there is a penalty with
> each deference you have to follow in order to make that work.
>
The advantage is simplicity. A unicycle is a Frame, a Seat, and a Wheel, no
more, no less (unless we added more to the definition of course).
Inheritance gets complicated fast in C++ (again, can't speak for Scala)
with virtual functions, virtual vs. nonvirtual descructors. Additionally,
Unicycle doesn't inherit from anything. It's not a subclass of anything. It
can be used however.
As to dereferencing, types in Go are not boxed like in Java (for example).
We could construct Unicycle as
type Unicycle struct {
Frame
Seat
Wheel
}
or as
type Unicycle struct {
*Frame
*Seat
*Wheel
}
or any combination you'd like. In the latter case they are pointers, and in
the former they are not. So, first of all you can avoid the dereferencing
by not having pointers. Secondly, in Go all of the types are known at
compile type, so I believe you can call the function without going through
extra deferencing, even in the case where they are pointers.
Re: [julia-users] Julia and Object-Oriented Programming
> I do like this approach to composition/delegation, but it requires
> automatically adding a lot of methods to the delegator, i.e. Unicycle in
> this example, from all of its components, which feels kind of nasty and
> dangerous, especially since we allow dynamic addition of methods
> after-the-fact. In other words, you might add a method to Wheel, Frame or
> Seat at any time, which would presumably then also apply to Unicycle
> objects, potentially with unexpected consequences. It would be nice if the
> delegation was more limited than that. Go doesn't have this problem since
> you can't dynamically add methods – everything is known at compile time.
>
Yea, it's this kind of thing that makes it tricky in Julia. The obvious
problem is that you add a method (say cushiness to Frame) which makes
dispatch ambiguous. One could add higher-level dispatch rules, but that's
likely to add a lot of complexity.
On Thursday, October 22, 2015 at 7:03:43 AM UTC-6, Abe Schneider wrote:
>
> I think this is generally in-line with what I've been advocating for, and
> not that different from Scala's mix-ins:
>
> trait Wheel {
> // ...
> }
>
> trait Frame {
> // ...
> }
>
> class Unicycle extends trait Wheel, Frame {
>// ...
> }
>
> is essentially doing the same thing (i.e. copying the member variables and
> methods over).
>
>
I'm not familiar with Scala, so sorry if I'm telling you something you
know, but in go the member variables and methods are not copied over. The
Unicycle struct in go does not itself have those fields, the fields of the
struct do. In other words, defining
type Unicycle struct {
Frame
Wheel
Seat
}
Is exactly like declaring
type Unicycle struct {
Frame Frame
Wheel Wheel
SeatSeat
}
except that in the former case one can call unicycle.Cushiness() , and in
the latter one must call unicycle.Seat.Cushiness(). In particular, if you
swap out one Frame in the unicycle for a different Frame, the field values
change (the methods won't, since methods are with a type).
Re: [julia-users] Julia and Object-Oriented Programming
On Tuesday, October 20, 2015 at 3:39:00 PM UTC-6, Stefan Karpinski wrote:
>
> ScalaJulia is a skunkworks project Martin and I have been working on for a
> while now. The hardest part so far has been deciding between whether to
> call it ScalaJulia or JuliaScala. Other names we considered: Julala, Scalia.
The US Supreme Court may get involved if you call it Scalia. Hard to know
in which direction.
> Above, a relatively simple macro can replace all the "Type..." with the
fields of the composed types, applying multiple inheritance of the
structures without the baggage required in classic OOP. Then you can
compose your type from other types, but without having to write
"unicycle.wheel.radius"... you can just write "unicycle.radius".
As Stefan mentioned, Go is not traditional OO. This "composition-based"
approach is part of Go's OO approach. In go, a type can have named fields
of different types (like most OO languages), but also has "embedding". For
example, if one declared
type Unicycle struct {
Wheel
Frame
Seat
}
then you could access the individual fields directly. So, if "u' is of type
Unicycle, then you could access/set u.Cushiness directly. Similarly, if the
embedded types had methods, i.e. frame.Color(), they can be called directly
through unicycle, u.Color(). This is similar to, but distinct from,
inheritance (the difference is that the Unicycle type doesn't actually have
these fields, just the ability to call them easily, which is significant
because of interfaces). In the case of clashes, the program must specify
which is meant, so if both Seat and Frame had a Color() method, the user
would have to specify u.Frame.Color vs. u.Seat.Color. In Go, this is
handled by the compiler, and would need to be handled somewhere in the
Julia runtime/REPL. It's a very nice paradigm, but would have to be made to
fit within the broader Julia context.
[julia-users] Re: lu factorization with partial pivoting
The documentation for lu(A) says " lu(*A*) → L, U, p Compute the LU factorization of A, such that A[p,:] = L*U. " This is an LU decomposition with partial pivoting. The P matrix is the pivot table.
