I'm on there

But cool!

have to rebuild package since it was previously uploaded on different PPA

I originally tried to upload to the

`jack-poulson/elemental`

ppa but had to create a new one under the team `elemental`

and this requires rebuilding
further, it turns out I had to upload my GPG key first, so I am rebuilding again

thats cool

It looks like the latest spec file builds green with no serious warnings or errors

perhaps the homebrew should be updated after the official release

the reviewer is in italy, so I am assuming we will get to whatever the next step is there tomorrow.

yeah, absolutely.

I’d like to finish BFGS before the next release, if possible.

either that or we can slate TSVD and BFGS for the .88 release

yes, I don't think either TSVD or BFGS are mature enough yet

but they are getting there

TSVD is certainly not making .87 but maybe we can get an initial BFGS in there

it would be good to have some large scale tests as a sanity check of its robustness and performance

testing the Aggressive Early Deflation Schur decomp. against LAPACK revealed the

`std::complex`

performance issues with GCC
you could compare against the MATLAB/Octave BFGS performance

I just implemented the line search from the paper you referenced

the only unclear bit is they say:

`h is differentiable at t with h′(t) > c2s.`

so far I am not checking differentiability..

@poulson I ran the line search, it is failing on a simple quadratic. In particular here is the sequence of step lengths: t: 0.5 t: 0.25 t: 0.125 t: 0.0625 t: 0.03125 t: 0.015625 t: 0.0078125 t: 0.00390625 t: 0.001953125 t: 0.0009765625 t: 0.00048828125 t: 0.000244140625 t: 0.0001220703125 t: 6.103515625e-05 t: 3.0517578125e-05 t: 1.52587890625e-05 t: 7.62939453125e-06 t: 3.814697265625e-06 t: 1.9073486328125e-06 t: 9.5367431640625e-07 t: 4.76837158203125e-07 t: 2.384185791015625e-07 t: 1.192092895507812e-07 t: 5.960464477539062e-08 t: 2.980232238769531e-08 t: 1.490116119384766e-08 t: 7.450580596923828e-09 t: 3.725290298461914e-09 t: 1.862645149230957e-09 t: 9.313225746154785e-10 t: 4.656612873077393e-10 t: 2.328306436538696e-10 t: 1.164153218269348e-10 t: 5.820766091346741e-11 t: 2.91038304567337e-11 t: 1.455191522836685e-11 t: 7.275957614183426e-12 t: 3.637978807091713e-12 t: 1.818989403545856e-12 t: 9.094947017729282e-13 t: 4.547473508864641e-13 t: 2.273736754432321e-13 t: 1.13686837721616e-13 t: 5.684341886080801e-14 t: 2.842170943040401e-14 t: 1.4210854715202e-14 t: 7.105427357601002e-15 t: 3.552713678800501e-15 t: 1.77635683940025e-15 t: 8.881784197001252e-16 t: 4.440892098500626e-16 t: 2.220446049250313e-16 t: 1.110223024625157e-16 t: 5.551115123125783e-17 t: 2.775557561562891e-17 t: 1.387778780781446e-17 t: 6.938893903907228e-18 t: 3.469446951953614e-18 t: 1.734723475976807e-18 t: 8.673617379884035e-19 t: 4.336808689942018e-19 t: 2.168404344971009e-19 t: 1.084202172485504e-19 t: 5.421010862427522e-20 t: 2.710505431213761e-20 t: 1.355252715606881e-20 t: 6.776263578034403e-21 t: 3.388131789017201e-21 t: 1.694065894508601e-21 t: 8.470329472543003e-22 t: 4.235164736271502e-22 t: 2.117582368135751e-22 t: 1.058791184067875e-22 t: 5.293955920339377e-23 t: 2.646977960169689e-23 t: 1.323488980084844e-23 t: 6.617444900424221e-24 t: 3.308722450212111e-24 t: 1.654361225106055e-24 t: 8.271806125530277e-25 t: 4.135903062765138e-25 t: 2.067951531382569e-25 t: 1.033975765691285e-25 t: 5.169878828456423e-26 t: 2.584939414228211e-26 t: 1.292469707114106e-26 t: 6.462348535570529e-27 t: 3.231174267785264e-27 t: 1.615587133892632e-27 t: 8.077935669463161e-28 t: 4.03896783473158e-28 t: 2.01948391736579e-28 t: 1.009741958682895e-28 t: 5.048709793414476e-29 t: 2.524354896707238e-29 t: 1.262177448353619e-29 t: 6.310887241768094e-30 t: 3.155443620884047e-30 t: 1.577721810442024e-30 t: 7.888609052210118e-31

I really don't believe that this can be anything but a bug in your implementation

the only way to make t = .5 is if we divded t by 2

.. essentially the algorithm is so simple, the only way I made a mistake is if I didn’t correctly define the function h(t) = f(x+t*p) - f(x) or if s = limsup_{t->0} h(t)/t is not supposed to just be: s = h’(0).

Overton is no optimization slouch and it would be hard to believe that he would publish something that didn't even work on quadratics...

i think its likely i did mess up one of those things

how do you do an assertion in elemental again?

try comparing side-by-side for each calculation for a small system with a trivial Octave implementation

`if( !condition ) LogicError("Your failure message");`

or

`RuntimeError("Your failure message");`

both of which can accept an arbitrary number of arguments

or measure an invariant that should be maintained

it seems that this is there implementation

there is at least one safegaurd in the implementation not in the paper I am reading.

also, there is clearly something wrong with the treatment in the paper

since if you define h(t) = f(x+t*p) - f(x), then as t->0 h(t) is subtracting two numbers which are very close to each other.

especially when f is very smooth.

I would recommend making sure that you can qualitatively reproduce results before trying to improve the numerics

otherwise you won't be sure where the problem is

looking at his code, he doesn’t implement this as he has written it in the paper

based on the norm of the step

nbisectmax = max(30, round(log2(1e5*dnorm))); % allows more if ||d|| big

nexpandmax = max(10, round(log2(1e5/dnorm))); % allows more if ||d|| small

nexpandmax = max(10, round(log2(1e5/dnorm))); % allows more if ||d|| small

also, it appears launchpad does not support anything except ubuntu (it does not support uploading packages for debian proper)

someone build be a debian package once and put it in a ppa

there isn't a way to do the equivalent of

`dput -f ppa:libelemental/ppa/debian/jessie elemental_0.87-8_amd64.changes`

how do you check if a number is nan? do you have a special function fo rit?

you could compare against

`El::limits::Infinity<Real>()`

if you like
well

wait

oh wait

sorry

it will work