snapshot is pushed. If you verify I'll publish the new artifacts.
On Sun, Mar 15, 2015 at 1:14 AM, Yu Ishikawa
wrote:
> David Hall who is a breeze creator told me that it's a bug. So, I made a
> jira
> ticket about this issue. We need to upgrade breeze from 0.11.1 to 0.11.2
ping?
On Sun, Mar 15, 2015 at 9:38 PM, David Hall wrote:
> snapshot is pushed. If you verify I'll publish the new artifacts.
>
> On Sun, Mar 15, 2015 at 1:14 AM, Yu Ishikawa > wrote:
>
>> David Hall who is a breeze creator told me that it's a bug. So, I made
t;
> Thanks.
> Deb
> On Mar 15, 2015 9:39 PM, "David Hall" wrote:
>
>> snapshot is pushed. If you verify I'll publish the new artifacts.
>>
>> On Sun, Mar 15, 2015 at 1:14 AM, Yu Ishikawa <
>> yuu.ishikawa+sp...@gmail.com>
>> wrote:
(I don't know anything spark specific, so I'm going to treat it like a
Breeze question...)
As I understand it, Spark uses ARPACK via Breeze for SVD, and presumably
the same approach can be used for EVD. Basically, you make a function that
multiplies your "matrix" (which might be represented
implic
; >
> > OWL-QN seems to mostly be stable, but probably deserves more testing.
> > Presumably it has whatever defects my LBFGS does. (It's really pretty
> > straightforward to implement given an L-BFGS)
> >
> > We don't provide an L-BFGS-B implementation. We do have
On Wed, Mar 5, 2014 at 1:57 PM, DB Tsai wrote:
> Hi David,
>
> On Tue, Mar 4, 2014 at 8:13 PM, dlwh wrote:
> > I'm happy to help fix any problems. I've verified at points that the
> > implementation gives the exact same sequence of iterates for a few
> different
> > functions (with a particular
them.
>
> Thanks.
> Deb
>
>
>
> On Wed, Mar 5, 2014 at 2:00 PM, David Hall wrote:
>
> > On Wed, Mar 5, 2014 at 1:57 PM, DB Tsai wrote:
> >
> > > Hi David,
> > >
> > > On Tue, Mar 4, 2014 at 8:13 PM, dlwh wrote:
> > > > I'm
0866125635, diff 0.0
> Iteration 29: loss 0.30788249908237314, diff 0.23885980452569502
>
> Sincerely,
>
> DB Tsai
> Machine Learning Engineer
> Alpine Data Labs
> --
> Web: http://alpinenow.com/
>
>
> On Wed, Mar 5, 2014 at 2:
On Sat, Mar 22, 2014 at 8:59 AM, Pascal Voitot Dev <
pascal.voitot@gmail.com> wrote:
> The problem I was talking about is when you try to use typeclass converters
> and make them contravariant/covariant for input/output. Something like:
>
> Reader[-I, +O] { def read(i:I): O }
>
> Doing this, y
13: loss 0.9907956302751622, diff 0.0
> > >> Iteration 14: loss 0.9184205380342829, diff 0.07304737423337761
> > >> Iteration 15: loss 0.9184205380342829, diff 0.0
> > >> Iteration 16: loss 0.9184205380342829, diff 0.0
> > >> Iteration 17: loss 0.8259870936519939, diff 0.
tic constraints...
>
I wonder how our general projected gradient solver would do? Clearly having
dedicated QP support is better, but in terms of just getting it working, it
might be enough.
-- David
>
>
>
> On Sun, Mar 30, 2014 at 4:40 PM, David Hall wrote:
>
> > On Sun,
Another usage that's nice is:
logDebug {
val timeS = timeMillis/1000.0
s"Time: $timeS"
}
which can be useful for more complicated expressions.
On Thu, Apr 10, 2014 at 5:55 PM, Michael Armbrust wrote:
> BTW...
>
> You can do calculations in string interpolation:
> s"Time: ${timeMillis / 1
On Wed, Apr 23, 2014 at 9:30 PM, Evan Sparks wrote:
> What is the number of non zeroes per row (and number of features) in the
> sparse case? We've hit some issues with breeze sparse support in the past
> but for sufficiently sparse data it's still pretty good.
>
Any chance you remember what the
Was the weight vector sparse? The gradients? Or just the feature vectors?
On Wed, Apr 23, 2014 at 10:08 PM, DB Tsai wrote:
> The figure showing the Log-Likelihood vs Time can be found here.
>
>
> https://github.com/dbtsai/spark-lbfgs-benchmark/raw/fd703303fb1c16ef5714901739154728550becf4/result
ture is sparse.
> >
> > Sincerely,
> >
> > DB Tsai
> > ---
> > My Blog: https://www.dbtsai.com
> > LinkedIn: https://www.linkedin.com/in/dbtsai
> >
> >
> > On Wed, Apr 23, 2014 at
LBFGS will not take a step that sends the objective value up. It might try
a step that is "too big" and reject it, so if you're just logging
everything that gets tried by LBFGS, you could see that. The "iterations"
method of the minimizer should never return an increasing objective value.
If you're
ready
>>> excludes the reject step? Or should I just call "iterations" method and
>>> check "iteratingShouldStop" instead?
>>>
>>> Thanks.
>>>
>>>
>>> Sincerely,
>>>
>>> DB Tsai
>>> -
--------
> My Blog: https://www.dbtsai.com
> LinkedIn: https://www.linkedin.com/in/dbtsai
>
>
> On Mon, Apr 28, 2014 at 8:55 AM, David Hall wrote:
>
>> That's right.
>>
>> FWIW, caching should be automatic now, but it
Lbfgs and other optimizers would not work immediately, as they require
vector spaces over double. Otherwise it should work.
On May 5, 2014 3:03 PM, "DB Tsai" wrote:
> Breeze could take any type (Int, Long, Double, and Float) in the matrix
> template.
>
>
> Sincerely,
>
> DB Tsai
> ---
memory available...
>
>
> On Mon, May 5, 2014 at 3:06 PM, David Hall wrote:
>
> > Lbfgs and other optimizers would not work immediately, as they require
> > vector spaces over double. Otherwise it should work.
> > On May 5, 2014 3:03 PM, "DB Tsai" wrote:
&g
--
> My Blog: https://www.dbtsai.com
> LinkedIn: https://www.linkedin.com/in/dbtsai
>
>
> On Mon, May 5, 2014 at 3:06 PM, David Hall wrote:
>
> > Lbfgs and other optimizers would not work immediately, as they require
> > vector spaces over doubl
I have no ideas on benchmarks, but breeze has a CG solver:
https://github.com/scalanlp/breeze/tree/master/math/src/main/scala/breeze/optimize/linear/ConjugateGradient.scala
https://github.com/scalanlp/breeze/blob/e2adad3b885736baf890b306806a56abc77a3ed3/math/src/test/scala/breeze/optimize/linear/C
In general, in Breeze we allocate separate work arrays for each call to
lapack, so it should be fine. In general concurrent modification isn't
thread safe of course, but things that "ought" to be thread safe really
should be.
On Wed, Sep 3, 2014 at 10:41 AM, RJ Nowling wrote:
> No, it's not in
rm that += is not thread safe but + is? I'm assuming +
> allocates a new object for the write, while += doesn't.
>
> Thanks!
> RJ
>
>
> On Wed, Sep 3, 2014 at 2:50 PM, David Hall wrote:
>
>> In general, in Breeze we allocate separate work arrays for eac
yeah, breeze.storage.Zero was introduced in either 0.8 or 0.9.
On Fri, Oct 3, 2014 at 9:45 AM, Xiangrui Meng wrote:
> Did you add a different version of breeze to the classpath? In Spark
> 1.0, we use breeze 0.7, and in Spark 1.1 we use 0.9. If the breeze
> version you used is different from the
25 matches
Mail list logo
