Thanks. This certainly works great. I guess I more or less could have known
this but that I also wanted to probe whether there was not a far superior
approach to tackle these kind of problems. I guess I could wrap this
behaviour in a simple MemoryBuffer type.
On Tuesday, June 3, 2014 1:05:09
The conj in DualNumbers is a noop to avoid the problem with ctranspose.
2014-06-03 10:07 GMT+02:00 Chris Foster chris...@gmail.com:
I was imagining that ' is the traditional transpose, and I think
that's the right thing - I'm thinking of a dual number as a real
number plus a *real*
Julia is still a very young language, and it's common to hear people
talking of hoped for improvements in the compiler which will further speed
up the language. According to the current benchmarks, Julia is consistently
(and incredibly!) within a factor 1.5-2 or Fortran's speed, and this is
Some of what's in that paper apply to Julia (preallocation, creation of
temporaries), some doesn't (vectorization). Read through this blog post if
you have some time
-
http://www.johnmyleswhite.com/notebook/2013/12/22/the-relationship-between-vectorized-and-devectorized-code/
there the
Thomas,
If you're trying to invert (factorize) a matrix as part of your objective
function, it's generally a much better idea to reformulate your
optimization problem and use a different algorithm. Anywhere that you're
essentially trying to use inv(A)*x, you should try introducing a new
Whoops, didn't finish writing a sentence there... was saying that most of
the algorithms in Optim don't implement equality constraints, but you've
got other choices of optimization solvers.
On Tuesday, June 3, 2014 3:39:44 AM UTC-7, Tony Kelman wrote:
Thomas,
If you're trying to invert
The relation between the exponential integrals E1 and Ei is
(x real and positive):
Ei(x) = -E1(-x) - pi*1i
and so the following results are correct:
E1( 3.0) = 0.01304838...
E1(-3.0) = -9.933833... - 3.141593i
Ei( 3.0) = 9.933833...
Ei(-3.0) = -0.013048... - 3.141593i
Thanks for the suggestion, Tony. The problem I'm working with is that of
fitting a gaussian process to data, so my objective function (the log
likelihood of a GP given some data x) includes both an x' inv(K(theta)) x term
and a log determinant of K(theta). Here K() is a big dense positive
Alright if K is dense then Ipopt may not be your best choice. How do the
theta parameters enter into K(theta)? Is the problem convex? Would the dual
problem be easier to work with? Have you read Boyd and Vandenberghe more
recently than I have? This sounds suspiciously like it can be expressed
Currently it only handles strings. The reason is that PEG theoretically
have infinite look-ahead. I think this can be made a little better by
having a stream that loads data on-demand. In general, I think PEG's choice
of memory over speed is good for many things, but you'll probably find some
In the GP setting I'm using, K is the set of pair wise gaussian kernel
evaluations between all the points in my data. So if a point is x_i,z_i (x is
the dependent variable and the z's are effectively explanatory variables), K_ij
is more or less exp(-.5 * (z_i - z_j)^2 * theta).
I don't
On Tuesday, June 3, 2014 7:57:28 AM UTC-2:30, Tony Kelman wrote:
Not sure what you mean by optimizing matrix chain multiplication, I think
when it comes to operator precedence and making associative transformations
these are not currently performed automatically. Dominique Orban has a
The reason why A*B*C is parsed as *(A,B,C) is so this can be done but no one
has implemented it yet. Shouldn't be hard though.
On Jun 3, 2014, at 9:05 AM, Adam Burry abu...@gmail.com wrote:
On Tuesday, June 3, 2014 7:57:28 AM UTC-2:30, Tony Kelman wrote:
Not sure what you mean by optimizing
I'm new to Julia, and it is looking very promising. I like how you can
specify the type of a function argument by using ::TypeName after the name,
so for example:
myfunc (x::Float64)
As this make the variable name more prominent when looking at the code
since it comes first. I naturally went
On Tue, Jun 3, 2014 at 1:13 PM, Chris Foster chris...@gmail.com wrote:
So you can compute the real part L of the Cholesky decomposition exactly as
usual. Given that you now have L, you want the lower triangular matrix M.
Because L and M are lower triangular that's actually quite easy: matrix
That should work. This works for me:
julia function f(x)
y::Float64 = 4.5
y = x + 5 + y
return y
end
f (generic function with 1 method)
julia f(5)
14.5
However, there are some subtleties, have a look at the manual
http://docs.julialang.org/en/latest/manual/types/
OK, but I still cannot seem to find out if there is output available. Try:
julia function test_redirect(f::Function)
stdout_orig = STDOUT
rd, wr = redirect_stdout()
f()
close(wr)
nb = nb_available(rd)
redirect_stdout(stdout_orig)
On Wed, Jun 4, 2014 at 2:12 AM, Chris Foster chris...@gmail.com wrote:
fiddling with Base.BLAS.dot only got me as far as a segfault so far.
Actually I think I've fixed that now in the gist and using BLAS.dot
directly is faster, though still not very impressive. According to
@time, I've still
readall or readbytes
The number of bytes that can be read without a syscall (nb_available) is
not a good test of how much can be gotten from a syscall. However, after
eof returns true, then nb_available is the upper bound on the data that can
be read.
On Tuesday, June 3, 2014, Bob Nnamtrop
One issue might be that you change the type of L, which I believe boxes it
(but someone closer to the compiler will have to verify).
Maybe try using a different variable for the result of the decomposition?
Cheers, Kevin
On Tuesday, June 3, 2014, Chris Foster chris...@gmail.com
OK. I've got something that works, but it seems necessary to add a dummy
write and then strip it out at the end.
julia function return_stdout(f::Function)
stdout_orig = STDOUT
rd, wr = redirect_stdout()
print(_) # dummy write so eof(rd) doesn't block when f()
You could always pyimport pyplot directly, without using the PyPlot
package. (The main reason for PyPlot is to set up the GUI, although I
agree that it should allow more flexibility regarding the backend.) i.e.
pyimport(matplotlib)[:use](Agg)
@pyimport matplotlib.pyplot as plt
plt.plot(1:10)
Thanks, that works nicely.
--Peter
From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On
Behalf Of Steven G. Johnson
Sent: Tuesday, June 03, 2014 11:17 AM
To: julia-users@googlegroups.com
Subject: [julia-users] Re: Off-line plots using PyPlot
You could always
Without the calls to close(rd) and eof(rd) the code above hangs on the
first call (Case 1) at readall. If I use readbytes then I need the number
of bytes which I cannot get without calling eof. If I replace readall
with readavailable then it works w/o the close or eof calls. This is why
I was
I am tying to use OrderedDict by loading the *DataStructures *package but
it doesn't work; not too sure if it is a bug or I am missing something?
Pkg.init()
Pkg.status()
Pkg.add(DataStructure)
Pkg.update()
d = OrderedDict(Char,Int)
I certainly hope that we'll be able to close the gap and match C and
Fortran in the future – there's really nothing standing in the way of this.
Beating C/Fortran is a different thing entirely and less likely – largely
because if you can do something to make your code go faster then it can
also be
You still need a line
using DataStructures
before you can use DataStructures.
All the package system does is get the code to your computer. The `using`
statement actually evaluates it.
On Tuesday, June 3, 2014 4:27:23 PM UTC-4, James Perry wrote:
I am tying to use OrderedDict by loading
There was also this PR by Steven Johnson where the use of a
macro/meta-programming capabilities allowed for a Julia version that beat
out 2 other well-known C implementations (in Matlab and SciPy).
This point is crucial to me as I think over a longer-term horizon. Sure
performance is king and
Yes, there is a non-trivial area where it's *possible* to do something
really clever and fast in C/Fortran but so annoying that no one ever
actually does it. Having macros and jit can make these things convenient,
thereby making it possible for mere mortals to benefit from these kinds of
tricks.
Nice work, Chris.
Your code is about twice as fast (when N = 1000) as the code I initially
posted. I think the speed gains come from the fact that your code does all
its work on real numbers, so it only has to do one floating point operation
per operation, while my choldn works directly on
Ah right, that seems to be related to the problem. It's a little better if
L = chol(A, :U)
L = full(L)
is replaced with
L = full(chol(A, :U))
but the big improvement comes from putting in a type annotation there:
L = full(chol(A, :U)) :: typeof(A)
I'm not sure if that's the
hi all,
My main interest in JuliaCon is to discuss/plan the development of
statistics and machine learning libraries. I'm hoping for some
hacking sessions, pair programming, etc.
Given that the conference is single-track, will there be space for
this? How many people are interested in this?
Hey Gustavo,
I think what you're looking for will be the primary focus of the Hack Day
we're holding at the University of Chicago the Saturday after the
conference. Register on Meetup if you want to attend!:
http://www.meetup.com/JuliaChicago/events/181343542/
On Tue, Jun 3, 2014 at 5:33 PM,
I thought that using within a module would not affect the name space of
the enclosing module. Could someone please explain why PyPlot is visible
in Main after executing the lines below?
julia isdefined(:PyPlot)
false
julia module A
using PyPlot
end
INFO: Loading help data...
In Jeff's original implementation there was a largely inaccessible Root
module that was where all the top-level bindings existed – mostly just
bindings to other modules. However, if I recall correctly, I convinced him
to just merge Main and Root instead. That's why all loaded top-level
modules
I see, Main is a special case. Now the following makes sense to me...
julia isdefined(:PyPlot)
false
julia module B
module B1
using PyPlot
end
end
INFO: Loading help data...
julia isdefined(Main,:PyPlot)
true
julia isdefined(B,:PyPlot)
false
julia
Thanks! This worked.
On Tuesday, 3 June 2014 21:59:21 UTC+1, David Einstein wrote:
You still need a line
using DataStructures
before you can use DataStructures.
All the package system does is get the code to your computer. The `using`
statement actually evaluates it.
On Tuesday, June
Awesome. Thanks, James.
Gustavo
--
Gustavo Lacerda
http://www.optimizelife.com
On Tue, Jun 3, 2014 at 6:44 PM, James Porter porterjam...@gmail.com wrote:
Hey Gustavo,
I think what you're looking for will be the primary focus of the Hack Day
we're holding at the University of Chicago the
A related issue: in the new (0.3.0-prerelease+3335) Julia console under
Win7 the text we see does not appear in the stdout pipe, nor do error
messages in the stderr. I had some code, which captured the content of
these pipes and put it on the Windows clipboard, but they stopped working.
Was it
On Tuesday, 3 June 2014 08:29:31 UTC-4, andrew cooke wrote:
On Tuesday, 3 June 2014 08:16:49 UTC-4, Abe Schneider wrote:
Currently it only handles strings. The reason is that PEG theoretically
have infinite look-ahead. I think this can be made a little better by
having a stream that
Thanks for the reply, but it isn't the function that is the problem
(whitespace shouldn't matter either).
Let me state the problem more clearly, in the global scope why can't I
specify a variable using the ::TypeName syntax? So for example I have an
undefined name y that I want to be Float64:
Yeah, that's a good point. I think instead of using a string an iterator
should be used. It should be fairly easy to replace the
string-implementation with an iterator-implementation.
On Tuesday, June 3, 2014 9:27:05 PM UTC-4, andrew cooke wrote:
On Tuesday, 3 June 2014 08:29:31 UTC-4,
I have a macro that is defined in a module that creates a dictionary of
anonymous functions. These anonymous functions wrap arbitrary code which I
pass in. If I pass in simple pieces of code (e.g. just returning a simple
value), my test script everything works as expected.
However, if I make
On Wednesday, June 4, 2014 12:13:30 AM UTC+8, Mauro wrote:
However, there are some subtleties, have a look at the manual
http://docs.julialang.org/en/latest/manual/types/
On Wednesday, June 4, 2014 9:52:01 AM UTC+8, Andrew Simper wrote:
Is there some obscure reason that the global scope
I do think it would be a good thing to fix, however. It's just not as
pressing as other issues.
On Tue, Jun 3, 2014 at 10:25 PM, Jameson Nash vtjn...@gmail.com wrote:
adding a type declaration to a global const is not really necessary. since
you've already told the compiler that the value
I’m not sure there’s any single correct way to do benchmarks without
information about what you’re trying to optimize.
If you’re trying to optimize the experience of people using your code, I think
it’s important to use means rather than medians because you want to use a
metric that’s effected
if you're using a string and an integer index, you're going to have
problems with multi-byte utf8 (if i understand the docs correctly).
i think there should be *some* abstraction. then people can (ab)use that
to do things you don't expect. and julia's iterators are as lightweight
and
All good here, you were polite and to the point and it is easy to work
around. Basically I took from the replies:
Jameson: that is a redundant thing to do since that case is already handled
another way
Stefan: yes, but it is inconsistent since inside functions this same syntax
is recommended
The expression y = int64(4) returns its right hand side, not the value of
y. If you add an explicit `return y` after that, it does what you expect.
On Wed, Jun 4, 2014 at 1:22 AM, Andrew Simper andrewsim...@gmail.com
wrote:
All good here, you were polite and to the point and it is easy to work
49 matches
Mail list logo
