Math module clearly doesn't conform to the style guidelines. Does it
make sense to go and clean it entirely or should we do it for the ones
we use, when we use it?

Robin

On May 29, 2010, at 11:11 AM, Robin Anil wrote:

> Math module clearly doesn't conform to the style guidelines. Does it
> make sense to go and clean it entirely or should we do it for the ones
> we use, when we use it?
>
>

I'm not a big fan of massive formatting changes.  It breaks a lot of otherwise good patches.  I usually apply them right as I'm about to commit on the files I have open.

-Grant

There are arguments in both directions. In my view, the ideal is:

1) declare a target date.
2) everyone clears the deck of patches.
3) Reformat

Grant's proposal, which goes

1) have a reason to modify some particular bit
2) check in patch
3) check in reformat before someone else starts a patch

is not bad, either.
On Sat, May 29, 2010 at 1:30 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:

>
> On May 29, 2010, at 11:11 AM, Robin Anil wrote:
>
> > Math module clearly doesn't conform to the style guidelines. Does it
> > make sense to go and clean it entirely or should we do it for the ones
> > we use, when we use it?
> >
> >
>
> I'm not a big fan of massive formatting changes.  It breaks a lot of
> otherwise good patches.  I usually apply them right as I'm about to commit
> on the files I have open.
>
> -Grant

Correct me If I am wrong, I believe there are no conflicts for many of the
following top violators (except the matrix/linalg which Jake may have some
changes). So there shouldn't be a problem with formatting these. Is anyone
working on any of these classes?

Robin
 filename l m h number
trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java>
0 224 0 224
trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java>
0 220 0 220
trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java>
0 215 0 215
trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java>
0 104 0 104
trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java>
0 88 0 88
trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java>
0 84 0 84
trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java>
0 82 0 82
trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java>
0 71 0 71
trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java>
0 68 0 68
trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java>
0 57 0 57
trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java>
0 54 0 54
trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java>
0 51 0 51
trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java>
0 48 0 48
trunk/math/src/main/java/org/apache/mahout/math/function/Functions.java<file/trunk/math/src/main/java/org/apache/mahout/math/function/Functions.java>
0 47 0 47
trunk/math/src/main/java/org/apache/mahout/math/jet/random/Poisson.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Poisson.java>
0 47 0 47
trunk/math/src/main/java/org/apache/mahout/math/jet/random/Binomial.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Binomial.java>
0 43 0 43
trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileCalc.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileCalc.java>
0 40 0 40
trunk/math/src/main/java/org/apache/mahout/math/jet/random/sampling/RandomSampler.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/sampling/RandomSampler.java>
0 38 0 38
trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Formatter.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Formatter.java>
0 38 0 38
trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix3D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix3D.java>
0 38 0 38
trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/MersenneTwister.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/MersenneTwister.java>
0 28 0 28
trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/LUDecompositionQuick.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/LUDecompositionQuick.java>
0 26 0 26 trunk/math/src/main/java/org/apache/mahout/math/Partitioning.java<file/trunk/math/src/main/java/org/apache/mahout/math/Partitioning.java>025025
trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/EigenvalueDecomposition.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/EigenvalueDecomposition.java>
0 24 0 24
trunk/math/src/main/java/org/apache/mahout/math/decomposer/hebbian/HebbianSolver.java<file/trunk/math/src/main/java/org/apache/mahout/math/decomposer/hebbian/HebbianSolver.java>
0 23 0 23
trunk/math/src/main/java/org/apache/mahout/math/AbstractVector.java<file/trunk/math/src/main/java/org/apache/mahout/math/AbstractVector.java>
0 21 0 21
trunk/math/src/main/java/org/apache/mahout/math/jet/random/Distributions.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Distributions.java>
0 21 0 21
trunk/math/src/main/java/org/apache/mahout/math/matrix/DoubleFactory2D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/DoubleFactory2D.java>
0 21 0 21
trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Descriptive.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Descriptive.java>
0 20 0 20
trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Statistic.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Statistic.java>
0 20 0 20
trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/SeqBlas.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/SeqBlas.java>
0 19 0 19
trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/SingularValueDecomposition.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/SingularValueDecomposition.java>
0 19 0 19
trunk/math/src/main/java/org/apache/mahout/math/jet/math/IntFunctions.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/IntFunctions.java>
0 18 0 18

Erggg..... once I again I will state that I strongly prefer Grant's
approach.

Do findbugs and formatting "errors" actually cause people physical pain?

Why does this keep coming up?

  -jake

ps. no I doubt anyone is working on those files.  Doesn't change my
opinion of massive formatting checkins.

On Sat, May 29, 2010 at 10:58 AM, Robin Anil <[EMAIL PROTECTED]> wrote:

> Correct me If I am wrong, I believe there are no conflicts for many of the
> following top violators (except the matrix/linalg which Jake may have some
> changes). So there shouldn't be a problem with formatting these. Is anyone
> working on any of these classes?
>
> Robin
>  filename l m h number
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java>
> 0 224 0 224
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java>
> 0 220 0 220
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java>
> 0 215 0 215
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java>
> 0 104 0 104
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java>
> 0 88 0 88
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java>
> 0 84 0 84
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java>
> 0 82 0 82
>
> trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java>
> 0 71 0 71
>
> trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java>
> 0 68 0 68
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java>
> 0 57 0 57
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java>
> 0 54 0 54
>
> trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java>
> 0 51 0 51
>
> trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java>
> 0 48 0 48
>
> trunk/math/src/main/java/org/apache/mahout/math/function/Functions.java<file/trunk/math/src/main/java/org/apache/mahout/math/function/Functions.java>
> 0 47 0 47
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/Poisson.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Poisson.java>
> 0 47 0 47
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/Binomial.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Binomial.java>
> 0 43 0 43
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileCalc.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileCalc.java>
> 0 40 0 40
>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/sampling/RandomSampler.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/sampling/RandomSampler.java>
> 0 38 0 38
>
> trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Formatter.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Formatter.java>

Agree, which is why I'd rather just nail this once rather than dribble it in.

It's reasonable to say you just don't think the formatting and style
stuff matters, but I find it does, indirectly, from a "broken windows
policy" perspective. If your code *looks* a bit uneven and
inconsistent, people have less compunction about checking in more
uneven code (since it already is) and have a general sense that it's
alright to check in stuff that's maybe not as completely baked as
would be ideal -- since it looks like anything goes.

And I don't think we're spending too *much* time thinking about design
and such. So is it so painful to let someone else touch up, on
everyone's behalf, the code base? we really should have been checking
in better code from the get-go.

Turned around... I also don't see the argument against cleaning this
up. Do you have a patch? fine, we can wait until you're ready check
in. This is a real no-skin-off-your-nose change so, ?

On Sat, May 29, 2010 at 2:11 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:
> Erggg..... once I again I will state that I strongly prefer Grant's
> approach.
>
> Do findbugs and formatting "errors" actually cause people physical pain?
>
> Why does this keep coming up?
>
>  -jake
>
> ps. no I doubt anyone is working on those files.  Doesn't change my
> opinion of massive formatting checkins.
>
> On Sat, May 29, 2010 at 10:58 AM, Robin Anil <[EMAIL PROTECTED]> wrote:
>
>> Correct me If I am wrong, I believe there are no conflicts for many of the
>> following top violators (except the matrix/linalg which Jake may have some
>> changes). So there shouldn't be a problem with formatting these. Is anyone
>> working on any of these classes?
>>
>> Robin
>>  filename l m h number
>>
>> trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java>
>> 0 224 0 224
>>
>> trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java>
>> 0 220 0 220
>>
>> trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java>
>> 0 215 0 215
>>
>> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java>
>> 0 104 0 104
>>
>> trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java>
>> 0 88 0 88
>>
>> trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java>
>> 0 84 0 84
>>
>> trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java>
>> 0 82 0 82
>>
>> trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java>
>> 0 71 0 71
>>
>> trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java>
>> 0 68 0 68
>>
>> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java>
>> 0 57 0 57
>>
>> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java>
>> 0 54 0 54
>>
>> trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/doublealgo/Transform.java>
>> 0 51 0 51
>>
>> trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Algebra.java>

Ok, I'm done wasting time on this issue.  People want to reformat
huge swaths of code, have a blast.

On Sat, May 29, 2010 at 11:17 AM, Sean Owen <[EMAIL PROTECTED]> wrote:

> Agree, which is why I'd rather just nail this once rather than dribble it
> in.
>
> It's reasonable to say you just don't think the formatting and style
> stuff matters, but I find it does, indirectly, from a "broken windows
> policy" perspective. If your code *looks* a bit uneven and
> inconsistent, people have less compunction about checking in more
> uneven code (since it already is) and have a general sense that it's
> alright to check in stuff that's maybe not as completely baked as
> would be ideal -- since it looks like anything goes.
>
> And I don't think we're spending too *much* time thinking about design
> and such. So is it so painful to let someone else touch up, on
> everyone's behalf, the code base? we really should have been checking
> in better code from the get-go.
>
> Turned around... I also don't see the argument against cleaning this
> up. Do you have a patch? fine, we can wait until you're ready check
> in. This is a real no-skin-off-your-nose change so, ?
>
> On Sat, May 29, 2010 at 2:11 PM, Jake Mannix <[EMAIL PROTECTED]>
> wrote:
> > Erggg..... once I again I will state that I strongly prefer Grant's
> > approach.
> >
> > Do findbugs and formatting "errors" actually cause people physical pain?
> >
> > Why does this keep coming up?
> >
> >  -jake
> >
> > ps. no I doubt anyone is working on those files.  Doesn't change my
> > opinion of massive formatting checkins.
> >
> > On Sat, May 29, 2010 at 10:58 AM, Robin Anil <[EMAIL PROTECTED]>
> wrote:
> >
> >> Correct me If I am wrong, I believe there are no conflicts for many of
> the
> >> following top violators (except the matrix/linalg which Jake may have
> some
> >> changes). So there shouldn't be a problem with formatting these. Is
> anyone
> >> working on any of these classes?
> >>
> >> Robin
> >>  filename l m h number
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Bessel.java>
> >> 0 224 0 224
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/engine/RandomSeedTable.java>
> >> 0 220 0 220
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/math/Arithmetic.java>
> >> 0 215 0 215
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Probability.java>
> >> 0 104 0 104
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Fun.java>
> >> 0 88 0 88
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/Beta.java>
> >> 0 84 0 84
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/random/HyperGeometric.java>
> >> 0 82 0 82
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/linalg/Property.java>
> >> 0 71 0 71
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java<file/trunk/math/src/main/java/org/apache/mahout/math/matrix/impl/DenseDoubleMatrix2D.java>
> >> 0 68 0 68
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/quantile/QuantileFinderFactory.java>
> >> 0 57 0 57
> >>
> >>
> trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java<file/trunk/math/src/main/java/org/apache/mahout/math/jet/stat/Gamma.java>

Nobody asked you to spend any time on anything though. Does it mess up a
patch? Say so and nothing would happen until ready. So not sure what other
issue is lurking here but lets discuss if needed rather than feel funny
about it. This should be easy and fun.

On May 29, 2010 2:35 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote:

Ok, I'm done wasting time on this issue.  People want to reformat
huge swaths of code, have a blast.
On Sat, May 29, 2010 at 11:17 AM, Sean Owen <[EMAIL PROTECTED]> wrote:

> Agree, which is why I'd ra...

We've been through it before: making massive formatting
changes can:

  a) break patches.  Biggest reason, not the case here.
But the point is that it sets (grr, continues) a precedent:
what if someone was on vacation and not reading emails,
and we all said, "I'm not touching that module, go ahead
and reformat", and because they were away for the 3-day
period in which the discussion happened, their patches
are totally trashed.  And don't say this is a "one time
thing", because if we decide to change some rule later,
some of the current code may be "in violation" of the
new rule, or if we adopt another project, the first step
is always: see if it works first, then worry about
formatting later.

 b) screw up svn modification history and IDE support
of showing diffs, which trying to track down who changed
something, it basically suddenly becomes "Robin/Sean
did!" as the answer to every file.

And frankly, I just hate having people (even not-me people!)
running around just autoformatting stuff for the sake of it.
It makes it the opposite of "easy and fun" for me.

But as I said, I really don't feel like giving this a "-1"
followed by a big backing-up-of-all-of-my-points as to
"why", so I'll stick with the tried-and-true
passive-aggressive Apache "-0" as my vote on this,
and leave it at that, not really wanting to discuss it
too much further.

  -jake

On Sat, May 29, 2010 at 12:13 PM, Sean Owen <[EMAIL PROTECTED]> wrote:

> Nobody asked you to spend any time on anything though. Does it mess up a
> patch? Say so and nothing would happen until ready. So not sure what other
> issue is lurking here but lets discuss if needed rather than feel funny
> about it. This should be easy and fun.
>
> On May 29, 2010 2:35 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote:
>
> Ok, I'm done wasting time on this issue.  People want to reformat
> huge swaths of code, have a blast.
>
>
> On Sat, May 29, 2010 at 11:17 AM, Sean Owen <[EMAIL PROTECTED]> wrote:
>
> > Agree, which is why I'd ra...
>

Jake,

How about I buy you a beer to convert you to a +0?

(yes, this is a bribe)

On Sat, May 29, 2010 at 12:59 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:

> But as I said, I really don't feel like giving this a "-1"
> followed by a big backing-up-of-all-of-my-points as to
> "why", so I'll stick with the tried-and-true
> passive-aggressive Apache "-0" as my vote on this,
> and leave it at that, not really wanting to discuss it
> too much further.
>

On Sat, May 29, 2010 at 1:01 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> Jake,
>
> How about I buy you a beer to convert you to a +0?
>
> (yes, this is a bribe)
>

An entire beer for but a two-epsilon change in my vote?  That's a pretty
high
BeerPerVote ratio, I better grab that before the market sees how inflated it
is.

I'm actually in mountain view right now, BTW!

  -jake
>
> On Sat, May 29, 2010 at 12:59 PM, Jake Mannix <[EMAIL PROTECTED]>
> wrote:
>
> > But as I said, I really don't feel like giving this a "-1"
> > followed by a big backing-up-of-all-of-my-points as to
> > "why", so I'll stick with the tried-and-true
> > passive-aggressive Apache "-0" as my vote on this,
> > and leave it at that, not really wanting to discuss it
> > too much further.
> >
>

Hey, I objected too!

On May 29, 2010, at 4:01 PM, Ted Dunning wrote:

> Jake,
>
> How about I buy you a beer to convert you to a +0?
>
> (yes, this is a bribe)
>
> On Sat, May 29, 2010 at 12:59 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:
>
>> But as I said, I really don't feel like giving this a "-1"
>> followed by a big backing-up-of-all-of-my-points as to
>> "why", so I'll stick with the tried-and-true
>> passive-aggressive Apache "-0" as my vote on this,
>> and leave it at that, not really wanting to discuss it
>> too much further.
>>

On Sat, May 29, 2010 at 2:14 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:

> Hey, I objected too!
>

See!  I knew the micro-vote market would never sustain epsilon-valued prices
for long!  But the SEC can pry that beer from my cold dead hands, I say!

  -jake

I am sympathetic to Jake's point of view in general, but I think that the
math stuff is a bit of a special case.

I have had two patches recently that could have been affected.  One was
adding test cases and correcting some of the distribution code (a kind angel
committed that already).  Another is beginning of work on stochastic
matrices.

I am happy to rebase any work that I have pending.

On Sat, May 29, 2010 at 12:13 PM, Sean Owen <[EMAIL PROTECTED]> wrote:

> Nobody asked you to spend any time on anything though. Does it mess up a
> patch? Say so and nothing would happen until ready. So not sure what other
> issue is lurking here but lets discuss if needed rather than feel funny
> about it. This should be easy and fun.
>
> On May 29, 2010 2:35 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote:
>
> Ok, I'm done wasting time on this issue.  People want to reformat
> huge swaths of code, have a blast.
>

On Sat, May 29, 2010 at 1:00 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> I am sympathetic to Jake's point of view in general, but I think that the
> math stuff is a bit of a special case.
>

The math (Colt) stuff is a special case, and in fact, is one which will lull
us
into a sense of security by having warnings go away, because it's still way
low on test coverage.  But, we did go an run my nice "auto-deprecator"
ruby script on it, so we at least still have those warnings...

*shrug*  That code still has way more issues than just formatting, it's
done in an entirely different style, was aimed at compiling against, like
jdk1.2, and really needs some care and attention, and maybe possibly
even some *use* at some point!

  -jake
>
> I have had two patches recently that could have been affected.  One was
> adding test cases and correcting some of the distribution code (a kind
> angel
> committed that already).  Another is beginning of work on stochastic
> matrices.
>
> I am happy to rebase any work that I have pending.
>
> On Sat, May 29, 2010 at 12:13 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
>
> > Nobody asked you to spend any time on anything though. Does it mess up a
> > patch? Say so and nothing would happen until ready. So not sure what
> other
> > issue is lurking here but lets discuss if needed rather than feel funny
> > about it. This should be easy and fun.
> >
> > On May 29, 2010 2:35 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote:
> >
> > Ok, I'm done wasting time on this issue.  People want to reformat
> > huge swaths of code, have a blast.
> >
>

On Sat, May 29, 2010 at 1:09 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:

> The math (Colt) stuff is a special case, and in fact, is one which will
> lull
> us
> into a sense of security by having warnings go away, because it's still way
> low on test coverage.  But, we did go an run my nice "auto-deprecator"
> ruby script on it, so we at least still have those warnings...
>

It isn't just lack of test cases leading to deprecations.  I had a use just
now for some of the code and in the process of adding test cases to get rid
of the deprecations found it wasn't quite right.  If dipping into 4 routines
uncovers 1 medium to minor bug, there must be quite a few more of those
lurking.
> *shrug*  That code still has way more issues than just formatting, it's
> done in an entirely different style, was aimed at compiling against, like
> jdk1.2, and really needs some care and attention, and maybe possibly
> even some *use* at some point!
>

Indeed.

I found, as you will recall, a certain number of surprises in the
collections subset.

You might say that we collectively took out a loan at the credibility
bank by incorporating this stuff, deprecations or no, and might be
well-advised to try to find time to write tests and repair problems
(or remove dubious stuff altogether).

On Sat, May 29, 2010 at 4:20 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> On Sat, May 29, 2010 at 1:09 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:
>
>> The math (Colt) stuff is a special case, and in fact, is one which will
>> lull
>> us
>> into a sense of security by having warnings go away, because it's still way
>> low on test coverage.  But, we did go an run my nice "auto-deprecator"
>> ruby script on it, so we at least still have those warnings...
>>
>
> It isn't just lack of test cases leading to deprecations.  I had a use just
> now for some of the code and in the process of adding test cases to get rid
> of the deprecations found it wasn't quite right.  If dipping into 4 routines
> uncovers 1 medium to minor bug, there must be quite a few more of those
> lurking.
>
>
>> *shrug*  That code still has way more issues than just formatting, it's
>> done in an entirely different style, was aimed at compiling against, like
>> jdk1.2, and really needs some care and attention, and maybe possibly
>> even some *use* at some point!
>>
>
> Indeed.
>

On Sat, May 29, 2010 at 1:20 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>
> It isn't just lack of test cases leading to deprecations.  I had a use just
> now for some of the code and in the process of adding test cases to get rid
> of the deprecations found it wasn't quite right.  If dipping into 4
> routines
> uncovers 1 medium to minor bug, there must be quite a few more of those
> lurking.
>

Wouldn't this be all the more reason to leave that code "ugly" so that as
we dig in and use it bit by bit, adding test cases and fixing bugs, we
also "pretty-ify" it?

Following the "broken-window" analogy, don't go fixing a bunch of windows
in a neighborhood where you don't even know if the floorboards on the
abandoned houses are rotten out.  Fix the windows when that particular
house is "move-in-ready".

  -jake
>
>
> > *shrug*  That code still has way more issues than just formatting, it's
> > done in an entirely different style, was aimed at compiling against, like
> > jdk1.2, and really needs some care and attention, and maybe possibly
> > even some *use* at some point!
> >
>
> Indeed.
>

I'd prefer to have a quick big-bang change, if indeed there aren't any
outstanding patches.
(If only to retroactively justify the fact that I just did the same to
core and examples.)
I think this is something we should focus on fixing up now, then going
forward we can actually pay attention to checkstyle warnings.

On Sat, May 29, 2010 at 1:50 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
> There are arguments in both directions. In my view, the ideal is:
>
> 1) declare a target date.
> 2) everyone clears the deck of patches.
> 3) Reformat
>
> Grant's proposal, which goes
>
> 1) have a reason to modify some particular bit
> 2) check in patch
> 3) check in reformat before someone else starts a patch
>
> is not bad, either.
>
>
> On Sat, May 29, 2010 at 1:30 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
>>
>> On May 29, 2010, at 11:11 AM, Robin Anil wrote:
>>
>> > Math module clearly doesn't conform to the style guidelines. Does it
>> > make sense to go and clean it entirely or should we do it for the ones
>> > we use, when we use it?
>> >
>> >
>>
>> I'm not a big fan of massive formatting changes.  It breaks a lot of
>> otherwise good patches.  I usually apply them right as I'm about to commit
>> on the files I have open.
>>
>> -Grant
>

I agree which is why I am not excited by the task of scrubbing the details
but dont mind if someone else does at all. I already had my way with core
and examples which are more interesting. They're now pretty in line with
checkstyle rules.

Better still in math would be to chuck out the pieces we haven't found a use
for and don't suppose there will be a use for soon. Then care about the
rest.  What would happen if I suggest we delete anything still deprecated?

On May 29, 2010 4:25 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote:

On Sat, May 29, 2010 at 1:20 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>
> It isn't just lack o...
Wouldn't this be all the more reason to leave that code "ugly" so that as
we dig in and use it bit by bit, adding test cases and fixing bugs, we
also "pretty-ify" it?

Following the "broken-window" analogy, don't go fixing a bunch of windows
in a neighborhood where you don't even know if the floorboards on the
abandoned houses are rotten out.  Fix the windows when that particular
house is "move-in-ready".

 -jake

>
>
> > *shrug* That code still has way more issues than just formatting, it's
> > done in an ent...

On Sat, May 29, 2010 at 2:12 PM, Sean Owen <[EMAIL PROTECTED]> wrote:

>
> Better still in math would be to chuck out the pieces we haven't found a
> use
> for and don't suppose there will be a use for soon. Then care about the
> rest.  What would happen if I suggest we delete anything still deprecated?
>

-1 on that idea.  We don't currently use the QR decompositions in
there, for example, but it would be really silly to have to re-code them all
over
again as soon as we found we needed it.

  -jake

I'd say this:

I'll go for it if you can go through all of JIRA and assure me there are little to no issues open against it that need to be fixed.  It's not even necessarily the active ones.  Either that or promise to update/fix them once the reformat is done.

I still, however, think it is pointless unless we have a process in place that automatically reformats every commit, as it is bound to be one of those annoying little things that prevents people from contributing b/c they have to have the formatting just right in order to contribute.

-Grant

On May 29, 2010, at 5:22 PM, Jake Mannix wrote:

> On Sat, May 29, 2010 at 2:12 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
>
>>
>> Better still in math would be to chuck out the pieces we haven't found a
>> use
>> for and don't suppose there will be a use for soon. Then care about the
>> rest.  What would happen if I suggest we delete anything still deprecated?
>>
>
> -1 on that idea.  We don't currently use the QR decompositions in
> there, for example, but it would be really silly to have to re-code them all
> over
> again as soon as we found we needed it.
>
>  -jake

I would agree mildly with 80% of the result, grump about 10% and tear hair
about 10%.  I don't know which 10% at the moment.

But it wouldn't hurt for one or more of us to go through and mark up a list
of things we can see a use for.

On Sat, May 29, 2010 at 2:12 PM, Sean Owen <[EMAIL PROTECTED]> wrote:

> What would happen if I suggest we delete anything still deprecated?

I wasn't here when you all picked up Colt, but I wonder if we want to
pick a middle ground between carrying around @deprecated code that no
one feels like testing and deleting it altogether. Work went into IP
clearance and all that. I'd identifying the things that look furthest
from useful and moving them to a separate 'attic', from which they
could be recovered in case someone found a use for them.

By the way, howcome 'taste' has a BitSet distinct from either the JDK
class or the collection BitVector?
On Sun, May 30, 2010 at 12:06 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> I would agree mildly with 80% of the result, grump about 10% and tear hair
> about 10%.  I don't know which 10% at the moment.
>
> But it wouldn't hurt for one or more of us to go through and mark up a list
> of things we can see a use for.
>
> On Sat, May 29, 2010 at 2:12 PM, Sean Owen <[EMAIL PROTECTED]> wrote:
>
>> What would happen if I suggest we delete anything still deprecated?
>

On Sun, May 30, 2010 at 11:03 AM, Benson Margulies
<[EMAIL PROTECTED]> wrote:
> I wasn't here when you all picked up Colt, but I wonder if we want to
> pick a middle ground between carrying around @deprecated code that no
> one feels like testing and deleting it altogether. Work went into IP
> clearance and all that. I'd identifying the things that look furthest
> from useful and moving them to a separate 'attic', from which they
> could be recovered in case someone found a use for them.

(It is always resurrectable from SVN too.)

> By the way, howcome 'taste' has a BitSet distinct from either the JDK
> class or the collection BitVector?

Purely for speed and size -- mostly skipping range checks, cutting out
fields, etc. It mattered enough since it got used so much.

On May 30, 2010, at 11:10 AM, Sean Owen wrote:

> On Sun, May 30, 2010 at 11:03 AM, Benson Margulies
> <[EMAIL PROTECTED]> wrote:
>> I wasn't here when you all picked up Colt, but I wonder if we want to
>> pick a middle ground between carrying around @deprecated code that no
>> one feels like testing and deleting it altogether. Work went into IP
>> clearance and all that. I'd identifying the things that look furthest
>> from useful and moving them to a separate 'attic', from which they
>> could be recovered in case someone found a use for them.
>
> (It is always resurrectable from SVN too.)

A bit harder to find, though.

>
>> By the way, howcome 'taste' has a BitSet distinct from either the JDK
>> class or the collection BitVector?
>
> Purely for speed and size -- mostly skipping range checks, cutting out
> fields, etc. It mattered enough since it got used so much.

Those are the reasons Lucene has one too!

https://issues.apache.org/jira/browse/HADOOP-6668

Check this out. This looks like a clean way to solve this issue in Mahout as
well. If we annotate each package as public stable, private stable, public
unstable, and so on and so forth, and keep only the stable ones in the
javadoc, Users will find the documentations a lot more readable. Plus
developers can keep adding experimental stuff with bad style as long as it
is not marked visible. We can keep separate quality levels for each
visibility. Mahout will always attract experimental code, so instead of
driving it away and waiting for the quality to go up before committing, we
can annotate it at the least quality level and when it improves, we can
change the annotation along with the improvements.

I can help creating a patch like this, if everyone is onboard

Robin

I think that this is fine.  Essentially this is a more fine grained approach
to what we have been doing with deprecated.

The real virtue of this is that it promotes visibility of the known good
stuff and thus exerts a good social pressure.

I do think that we need to push for code quality as quickly as is
reasonable, but definitely at the patch level, we should encourage
contributors to post early versions.

On Tue, Jun 1, 2010 at 11:16 PM, Robin Anil <[EMAIL PROTECTED]> wrote:

> https://issues.apache.org/jira/browse/HADOOP-6668
>
> Check this out. This looks like a clean way to solve this issue in Mahout
> as
> well. If we annotate each package as public stable, private stable, public
> unstable, and so on and so forth, and keep only the stable ones in the
> javadoc, Users will find the documentations a lot more readable. Plus
> developers can keep adding experimental stuff with bad style as long as it
> is not marked visible. We can keep separate quality levels for each
> visibility. Mahout will always attract experimental code, so instead of
> driving it away and waiting for the quality to go up before committing, we
> can annotate it at the least quality level and when it improves, we can
> change the annotation along with the improvements.
>
> I can help creating a patch like this, if everyone is onboard
>
> Robin
>

On Tue Ted Dunning <[EMAIL PROTECTED]> wrote:

> I think that this is fine.  Essentially this is a more fine grained
> approach to what we have been doing with deprecated.

+1 from me as well.

The approach also clearly separates stable, but in future versions no
longer supported code (deprecated) from experimental, but in future
versions better supported code. Should make it easier for the user to
decide which pieces of Mahout to use.

Isabel

That sounds fine to me.

But I sense there's no particular motivation to ever address this stuff -
hearing objections to even style changes.

What is the game plan you envision then? When is it OK to touch any of this?

Honestly the code quality in this project is not yet professional. Its much
better than a lot of projects. But I participate to make code that is better
than anything a professional organization is capable of.

So this sentiment is not the best to hear. This is not amateur hobby code,
it ought to be world class!

On May 29, 2010 5:23 PM, "Jake Mannix" <[EMAIL PROTECTED]> wrote:

On Sat, May 29, 2010 at 2:12 PM, Sean Owen <[EMAIL PROTECTED]> wrote:

>
> Better still in math would...
-1 on that idea.  We don't currently use the QR decompositions in
there, for example, but it would be really silly to have to re-code them all
over
again as soon as we found we needed it.

 -jake

On Sat, May 29, 2010 at 2:35 PM, Sean Owen <[EMAIL PROTECTED]> wrote:

> That sounds fine to me.
>
> But I sense there's no particular motivation to ever address this stuff -
> hearing objections to even style changes.
>
> What is the game plan you envision then? When is it OK to touch any of
> this?
>

"OK"?  It's always ok to *fix* it, I'm just saying it's not terribly helpful
to
"fix" the style errors without fixing the underlying code, and I'm saying
it's
not ok to just remove it because we haven't gotten around to fixing it up
just yet.
> Honestly the code quality in this project is not yet professional.
It's better than the "professional" code I've seen in many companies whose
code I've read or had to use.  It has rough parts which are untended, just
like
codebases, except there are actually far fewer of these in our codebase, and
in fact ours has the benefit of that code not actually being used right now,
unlike corporate environments where the code gets embedded in some system
which is in use and can *never* be removed, leaving its bugs as little
time-bombs.
> Its much
> better than a lot of projects. But I participate to make code that is
> better
> than anything a professional organization is capable of.
>

Great, excellent.
> So this sentiment is not the best to hear. This is not amateur hobby code,
> it ought to be world class!
>

Totally agree.  I just don't agree on a) how to get there, code-wise, and b)
how to get there - motivation-of-contributors/commiters-wise.

  -jake

This is terrible! I went to sleep on this side of the world and people on
the other side have already bartered votes for beer. For being the reason of
the getting a vote call going by mistake, I object this
reflexive behavior and instead propose for a transitive one.
If we are not going to touch (use, format, delete or make api compatible)
many of these deprecated code. Instead, how about marking stuff as
@deprecated. So that it is clear to new developers reading the code that
those module are not to be examined.

Robin