Re: [math] Read-only RealVector

[Arne Ploese]

What methods do you need?

Maybe an interface with:
public interface SimpleRealVector {
  double getEntry(int i);
  int getDimension(); 
}
will do? 

Am Donnerstag, den 11.08.2011, 05:36 +0200 schrieb Sébastien Brisard: 
> Hello,
> this is an idea I've had while thinking about Iterative Linear
> Solvers, but I think it is much more general. I don't know whether
> what I'm going to describe is a known pattern, or a very dirty trick I
> should forget about. So any advice would be greatly appreciated.
> 
> For the sake of the argument, let us stick with iterative linear
> solvers. Most of them modify in-place the current estimate of the
> solution, x (which is a RealVector). In view of observing the state of
> the solver during the iterations, I'd like to provide a method
> RealVector getCurrentSolution()
> 
> As modifying the current solution outside the solver would ruin the
> iterations, it is imperative to return a deep copy of x. This can take
> time, if the vector is large. Also, it can be memory consuming. So I
> was wondering: would it be possible to design a ReadOnlyRealVector
> class, which would be final, have a unique constructor
> ReadOnlyRealVector(RealVector v)
> and extend AbstractRealVector
> 
> I would keep a reference to the underlying RealVector used to
> construct the ReadOnlyRealVector, so that any call to a standard
> RealVector method would be delegated to the same method in v. EXCEPT
> when the method in question would normally modify the
> ReadOnlyRealVector, in which case an UnsupportedException would be
> thrown. For example
> 
> v = new RealVector();
> ...
> vro = new ReadOnlyRealVector(v);
> vro.map(f); // Returns v.map(f)
> vro.mapToSelf(f); // Throws an exception
> 
> Note that "Read-Only" does not mean "Immutable", since a modification
> of v would modify vro. This would suit my requirements, but it should
> be made clear in the Javadoc.
> Is it clean code, or should I throw it away?
> In the former case, would a ReadOnly tagging interface make sense?
> 
> Thanks for your comments/corrections,
> Sebastien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Sébastien Brisard]

2011/8/11 Arne Ploese :
> What methods do you need?
>
> Maybe an interface with:
> public interface SimpleRealVector {
>  double getEntry(int i);
>  int getDimension();
> }
> will do?
>
No, I'd like to have *all* methods of the o.a.c.m.linear.RealVector
interface, *except* those which modify the caller object, e.g.
xxxToSelf and setXxx.
My question was actually more general. To make an object unmodifiable,
is it good practice to encapsulate it into another object, with
seamingly the same interface, but unimplemented methods which might
modify the object ? My point would be not to create any new
interface/abstract class.

Below is a quick example (which I hope is not buggy).
Thanks for your advice,
Sébastien

/**/
public abstract class AbstractFoo{
  public abstract double getValue();

  public abstract void setValue(final double x);

  public abstract AbstractFoo add(AbstractFoo bar);

  public void addToSelf(AbstractFoo bar){
setValue(getValue + bar.getValue());
  }
}

/**/
public class  Foo extends AbstractFoo{
  private double value;

  public Foo(final double x){
value = x;
  }

  public double getValue(){
return value;
  }

  public void setValue(final double x){
value = x;
  }

  public AbstractFoo add(AbstractFoo bar){
return new Foo(value + bar.getValue());
  }
}

/**/
public final class FooReadOnly extends AbstractFoo{
  private final Foo foo;

  public FooReadOnly(AbstractFoo foo){
this.foo = foo;

  public double getValue(){
return foo.getValue();
  }

  public void setValue(final double x){
throw new NotImplementedException("read only object");
  }

  public AbstractFoo add(AbstractFoo bar){
return foo.add(bar);
  }

  public void addToSelf(AbstractFoo bar){
throw new NotImplementedException("read only object");
  }
}

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [general] Apache + Meritocracy

[Mark Struberg]

Hi Stefan!

That's great news and even underlines better what Christian already stated: 
committocracy doen't really work out - not socially and not even technically. 
The code in question seems to got moved a few times, so all commit history is 
long time gone.

I'll scan the Ant codebase for similarities and pick the stuff I need if that's 
ok. 

txs and LieGrue,
strub

--- On Thu, 8/11/11, Stefan Bodewig  wrote:

> From: Stefan Bodewig 
> Subject: Re: [general] Apache + Meritocracy
> To: dev@commons.apache.org
> Date: Thursday, August 11, 2011, 1:36 AM
> On 2011-08-11, Mark Struberg wrote:
> 
> > Of course they had the most commits over at the
> codehaus SVN. But they
> > did not say that 70% of the code did originally come
> from Apache
> > Avalon (only found that out after reading Stefan
> Bodewigs @author tags
> > and digged deeper).
> 
> Really?  I never contributed to Avalon.
> 
> The most likely case is this is code originally written for
> Ant, then
> copied to Avalon from where it was copied to Plexus and
> most likely
> Commons as well.  commons-compress' seed as well as
> that of commons-exec
> have taken similar journeys.
> 
> You might want to check against the Ant code base to apply
> the bug fixes
> that have piled up over the 10 years that came after Peter
> Donald copied
> the code to Avalon ;-)
> 
> Stefan
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Arne Ploese]

So you not only want to observe the result, but you want a read only
RealVector.

A "clean" solution would be split RealVector in a base interface, which
not modifies any internal Data and a inherited interface which adds
xxxToSelf and setEnty(...). ??? I think this could lead to some
unforseeable side effects - so maybe some test implementation is
necessary to see whats happen.

Am Donnerstag, den 11.08.2011, 10:08 +0200 schrieb Sébastien Brisard: 
> 2011/8/11 Arne Ploese :
> > What methods do you need?
> >
> > Maybe an interface with:
> > public interface SimpleRealVector {
> >  double getEntry(int i);
> >  int getDimension();
> > }
> > will do?
> >
> No, I'd like to have *all* methods of the o.a.c.m.linear.RealVector
> interface, *except* those which modify the caller object, e.g.
> xxxToSelf and setXxx.
> My question was actually more general. To make an object unmodifiable,
> is it good practice to encapsulate it into another object, with
> seamingly the same interface, but unimplemented methods which might
> modify the object ? My point would be not to create any new
> interface/abstract class.
> 
> Below is a quick example (which I hope is not buggy).
> Thanks for your advice,
> Sébastien
> 
> /**/
> public abstract class AbstractFoo{
>   public abstract double getValue();
> 
>   public abstract void setValue(final double x);
> 
>   public abstract AbstractFoo add(AbstractFoo bar);
> 
>   public void addToSelf(AbstractFoo bar){
> setValue(getValue + bar.getValue());
>   }
> }
> 
> /**/
> public class  Foo extends AbstractFoo{
>   private double value;
> 
>   public Foo(final double x){
> value = x;
>   }
> 
>   public double getValue(){
> return value;
>   }
> 
>   public void setValue(final double x){
> value = x;
>   }
> 
>   public AbstractFoo add(AbstractFoo bar){
> return new Foo(value + bar.getValue());
>   }
> }
> 
> /**/
> public final class FooReadOnly extends AbstractFoo{
>   private final Foo foo;
> 
>   public FooReadOnly(AbstractFoo foo){
> this.foo = foo;
> 
>   public double getValue(){
> return foo.getValue();
>   }
> 
>   public void setValue(final double x){
> throw new NotImplementedException("read only object");
>   }
> 
>   public AbstractFoo add(AbstractFoo bar){
> return foo.add(bar);
>   }
> 
>   public void addToSelf(AbstractFoo bar){
> throw new NotImplementedException("read only object");
>   }
> }
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Sébastien Brisard]

2011/8/11 Arne Ploese :
> So you not only want to observe the result, but you want a read only
> RealVector.
>
That's right. I'm sorry, my first message was not clear, especially if
you did not follow the thread on iterative solvers.
I want to observe the *solver*, and the current state of the solver is
a *RealVector*, which should by no means be modified by the observer.
The safest way to do that would be for the solver to have a method
like
public RealVector getCurrentSolution(){
return x.copy();
}
but that takes both time and memory. So I was thinking of something more like
public RealVector getCurrentSolution(){
return new ReadOnlyRealVector(x);
}
which takes virtually no additional memory (and presumably very little
time). The two advantages of this approach are
* it does not jeopardize the whole hierarchy tree, since you do not
have to create a new interface,
* it is quite general, and could be adopted for any base object (not
only RealVector).
The downside is that some methods throw exceptions, which might be
deemed dirty. I don't really know.
S

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[general] Plexus and Commons code inherited from somewhere else (was Re: [general] Apache + Meritocracy)

[Stefan Bodewig]

On 2011-08-11, Mark Struberg wrote:

> That's great news and even underlines better what Christian already
> stated: committocracy doen't really work out - not socially and not
> even technically.

No argument from my side.

> The code in question seems to got moved a few times, so all commit
> history is long time gone.

> I'll scan the Ant codebase for similarities and pick the stuff I need
> if that's ok.

Sure this is OK, and I'm sure the Ant community would love to get the
bug fixes that have been applied inside of Plexus as well.  This doesn't
have to be a one-way street.

I see this as a general problem with components that started off as
forks from other codebases.  There are quite a few commons projects that
have been seeded by code that originally came from Ant, Avalon, Struts
or other places and at least in the case of Ant the code bases have
diverged.  Ant has always seen itself as sitting at the bottom of the
dependency stack and thus prefered to not have any dependencies at all -
that's why we've never embraced Commons.  On top of that nobody told the
Ant community that their code had been forked and so we could not help
out, but that's water under the bridge.

In the end the same bugs and shortcomings of the same original code base
have been fixed by two or three groups in different ways and it would
certainly be great if we could merge all those collected fixes.  But
honestly I dont know how as the focus of the different dev groups is too
different.

At least for your Plexus replacement you should be able to leverage what
is inside of Commons, though.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [general] Plexus and Commons code inherited from somewhere else (was Re: [general] Apache + Meritocracy)

[Mark Struberg]

Yes, that's the plan. the 'new' plexus-utils FileUtils will for example 
probably be a slim shim over the commons-io counterpart and just route through. 

I now grabbed the Ant SVN codebase and figured that this got imported from CVS 
in 2004...

Happy to report back fixes, but I'm doing almost a blackbox approach for 
getting the plexus stuff back to the ASF. Of course it's ALv1.1 licensed, but 
some folks took the provenience in question...

Our current approach is to write TCK tests for the codehaus plexus classes and 
then implement own versions without looking at the original code. 

LieGrue,
strub


--- On Thu, 8/11/11, Stefan Bodewig  wrote:

> From: Stefan Bodewig 
> Subject: [general] Plexus and Commons code inherited from somewhere else (was 
> Re: [general] Apache + Meritocracy)
> To: dev@commons.apache.org
> Date: Thursday, August 11, 2011, 8:56 AM
> On 2011-08-11, Mark Struberg wrote:
> 
> > That's great news and even underlines better what
> Christian already
> > stated: committocracy doen't really work out - not
> socially and not
> > even technically.
> 
> No argument from my side.
> 
> > The code in question seems to got moved a few times,
> so all commit
> > history is long time gone.
> 
> > I'll scan the Ant codebase for similarities and pick
> the stuff I need
> > if that's ok.
> 
> Sure this is OK, and I'm sure the Ant community would love
> to get the
> bug fixes that have been applied inside of Plexus as
> well.  This doesn't
> have to be a one-way street.
> 
> I see this as a general problem with components that
> started off as
> forks from other codebases.  There are quite a few
> commons projects that
> have been seeded by code that originally came from Ant,
> Avalon, Struts
> or other places and at least in the case of Ant the code
> bases have
> diverged.  Ant has always seen itself as sitting at
> the bottom of the
> dependency stack and thus prefered to not have any
> dependencies at all -
> that's why we've never embraced Commons.  On top of
> that nobody told the
> Ant community that their code had been forked and so we
> could not help
> out, but that's water under the bridge.
> 
> In the end the same bugs and shortcomings of the same
> original code base
> have been fixed by two or three groups in different ways
> and it would
> certainly be great if we could merge all those collected
> fixes.  But
> honestly I dont know how as the focus of the different dev
> groups is too
> different.
> 
> At least for your Plexus replacement you should be able to
> leverage what
> is inside of Commons, though.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]

[Ceki Gülcü]

On 11/08/2011 8:13 AM, Henri Yandell wrote:



I was going to say: "That would put Sebb in charge of the ASF!!!", but
then I noticed that after the import of Jena Andy Seaborne appears to
be the top count committer (I know, that doesn't measure size of
commit).  [http://svnsearch.org/svnsearch/repos/ASF/search]


The person with the most commit points is not necessarily in
charge. Sebastian Bazley's vote would carry more weight than Henri
Yandell's or Simone Tripodi's vote, but Henri and Simone voting
together would beat Sebastian's *lone* vote every time. It's basic
arithmetic and I won't insult you with an example containing figures.


I think the problem with this is that it's an extremely arbitrary way
of dealing with failure to find consensus. It's also not very
meritocratic - it's based on what people have done and not what people
are willing to do. The 'prove it in a branch' is more merit-based and
less likely to result in status quo decisions.


Yes, committocracy, i.e. decision making based on a commit point
weighted voting system, does only take into account past
contributions. Future contributions are ignored until such a time
where the future becomes the past.


Yup - . It's a good conversation to have had - great to hear of log4j
2.0 work and to have you still active in the conversation.


Yah, it has been a good discussion. Thanks for your time and input.

--
Ceki

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Monitoring iterative algorithms

[Luc Maisonobe]

Le 11/08/2011 06:14, Phil Steitz a écrit :

On 8/10/11 8:19 PM, Sébastien Brisard wrote:

Hello,
going back to the initial conversation. It seems to me that
formalizing Iterative Algorithms in a general way is very interesting,
but not a realistic target for 3.0 (or probably even 3.1). However, I
would very much like to have a satisfactory working version of linear
iterative solvers. I've already implemented them at work, because I
really need them. Including them in Commons Math seems to me highly
desirable, but if that too is unrealistic, let me know. As I'm doing
this last part in my spare time, I would become available to work on
other, more urgent open issues.
So here is what I propose. For the time being, iterative linear
solvers can live without observers, since I can reverse a previous
argument: convergence checkers can be seen as monitors... so I can
(dirtily) tweak a checker to monitor my solver (this would be a
temporary solution, waiting for something better). Regarding
convergence checkers themselves (the other major issue raised in the
code I have already proposed), I think the Object model is easier to
derive, and something like
StoppingCriterion{
   init(LinearIterativeSolver solver);

   boolean hasConverged(STATE s);
}
should work (will polish it a little bit). Making the stopping
criterion generic would allow later use in e.g. GA (STATE=Population)
and Optimization.

On second (third? fourth?) thoughts, I've realized that
Obervable/Observer would probably not be flexible enough, even for
very simple observers. A real event listener should probably be
preferred. For example, in many iterative solvers, there is an
initialization phase, during which the loop has not started, but the
counter (function evaluations, matrix-vector products) has. So a
different event should probably be fired, depending on whether or not
we are in the main loop.

OK, so, to sum up: I get rid of any Observer/Listener in the existing
code (this will come up later, once Iterative Algorithms at large have
been discussed). I write a generic enough stopping criterion
interface. This could be done rather quickly. Question is: would it be
agreeable to the Commons Math community?


Sounds reasonable to me; though I would personally be fine with
adding some small classes along the lines of what I outlined above
to support events.  They could even be package-scoped if we want to
keep them out of the public API and replace later with more general
constructs used elsewhere in [math].  We are not talking about much
code at all here.

I think if you are careful, you can likely set this up so that you
can continue to add features to the event framework (or even add the
framework itself) and stopping criteria without breaking backward
compatibility in 3.x releases.

I would like to see this in 3.0 if you can get something simple
completed that can be enhanced incrementally in 3.x and possibly
refactored in 4.0.


This seems a good path to go.

Luc



Phil


Best regards,
Sebastien

2011/8/10 Greg Sterijevski:

Luc,

I think we misunderstood each other, in the snippet below, my intention was
to agree with him. Everything Gilles was agreeable and hard to argue
against.

-Greg


Luc


  Not sure what you mean.


  In my opinion, discussions should serve to solve real problems of a

software
library: bugs, design inconsistencies, efficiency improvements (in that
order).




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Luc Maisonobe]

Le 11/08/2011 10:55, Sébastien Brisard a écrit :

2011/8/11 Arne Ploese:

So you not only want to observe the result, but you want a read only
RealVector.


That's right. I'm sorry, my first message was not clear, especially if
you did not follow the thread on iterative solvers.
I want to observe the *solver*, and the current state of the solver is
a *RealVector*, which should by no means be modified by the observer.
The safest way to do that would be for the solver to have a method
like
public RealVector getCurrentSolution(){
 return x.copy();
}
but that takes both time and memory. So I was thinking of something more like
public RealVector getCurrentSolution(){
 return new ReadOnlyRealVector(x);
}
which takes virtually no additional memory (and presumably very little
time). The two advantages of this approach are
* it does not jeopardize the whole hierarchy tree, since you do not
have to create a new interface,
* it is quite general, and could be adopted for any base object (not
only RealVector).
The downside is that some methods throw exceptions, which might be
deemed dirty. I don't really know.


Well, in fact I would very much like to have immutable vectors too. 
Immutability is really a way to simplify implementations. Surprisingly 
it sometimes also decrease time and memory consumption, because 
defensive copies littering user code can be avoided.


Jeopardizing the hierarchy tree is not a problem IMHO.

Luc


S

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [general] Plexus and Commons code inherited from somewhere else

[Stefan Bodewig]

On 2011-08-11, Mark Struberg wrote:

> I now grabbed the Ant SVN codebase and figured that this got imported
> from CVS in 2004...

Most of the exec, io and compress stuff is older.  I wrote the initial
version of the zip package in 2001 and Thomas Haas and Conor MacNeill
did most of the exec things in summer 2000 shortly before Ant 1.1, for
example.

Ant removed @author tags in March 2004 which should give you an idea of
when the split happened.

Let me know if you need help navigating Ant's code.

> Happy to report back fixes, but I'm doing almost a blackbox approach
> for getting the plexus stuff back to the ASF. Of course it's ALv1.1
> licensed, but some folks took the provenience in question...

> Our current approach is to write TCK tests for the codehaus plexus
> classes and then implement own versions without looking at the
> original code.

I'm glad I don't share your problems ;-)

Seriously, I am subscribed to maven-dev and was aware of what you are
doing and your approach likely is the best you can do to support
existing plugins.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Sébastien Brisard]

OK, this I also think would be useful. But my initial question
remains, if the object I want to protect is not a RealVector, what do
you think of my solution ?
Sébastien

PS : the problem is likely to occur when listening to other Iterative
Processes (not only linear solvers). For example, in o.a.c.m.genetics,
has a StoppingCondition.isSatisfied(Population),
and Population.addChromosome() would enable the StoppingCondition to
actually modify the ongoing simulation. Whether it is harmfull, I do
not know, though.
So of course, we could come up with a ImmutablePopulation as well, but
maybe it starts to get complicated?

Sébastien

2011/8/11 Luc Maisonobe :
> Le 11/08/2011 10:55, Sébastien Brisard a écrit :
>>
>> 2011/8/11 Arne Ploese:
>>>
>>> So you not only want to observe the result, but you want a read only
>>> RealVector.
>>>
>> That's right. I'm sorry, my first message was not clear, especially if
>> you did not follow the thread on iterative solvers.
>> I want to observe the *solver*, and the current state of the solver is
>> a *RealVector*, which should by no means be modified by the observer.
>> The safest way to do that would be for the solver to have a method
>> like
>> public RealVector getCurrentSolution(){
>>     return x.copy();
>> }
>> but that takes both time and memory. So I was thinking of something more
>> like
>> public RealVector getCurrentSolution(){
>>     return new ReadOnlyRealVector(x);
>> }
>> which takes virtually no additional memory (and presumably very little
>> time). The two advantages of this approach are
>> * it does not jeopardize the whole hierarchy tree, since you do not
>> have to create a new interface,
>> * it is quite general, and could be adopted for any base object (not
>> only RealVector).
>> The downside is that some methods throw exceptions, which might be
>> deemed dirty. I don't really know.
>
> Well, in fact I would very much like to have immutable vectors too.
> Immutability is really a way to simplify implementations. Surprisingly it
> sometimes also decrease time and memory consumption, because defensive
> copies littering user code can be avoided.
>
> Jeopardizing the hierarchy tree is not a problem IMHO.
>
> Luc
>
>> S
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Sébastien Brisard]

>
> Well, in fact I would very much like to have immutable vectors too.
> Immutability is really a way to simplify implementations. Surprisingly it
> sometimes also decrease time and memory consumption, because defensive
> copies littering user code can be avoided.
>
Luc, I have a silly question. Why do you think immutable vectors would
prevent defensive copy ? Creating an immutable vector from an existing
mutable vector would require a defensive copy, wouldn't it?
Thats the reason why I'm talking about read-only vectors, and not
immutable vectors.
The solver would keep a reference to the underlying (mutable) vector,
so would be able to modify (indirectly) the read-only vector.
The observer would only have a reference to the read-only vector, so
would not be able to modify the underlying vector.

Sébastien

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [general] Plexus and Commons code inherited from somewhere else

[Mark Struberg]

commons-exec is actively maintained by Sigi Goeschl. So at least this is known 
to be in good hands.

The plexus stuff still has @author tags. That's the reason why I learned that 
you have been involved. I know this also has been discussed highly 
controversial, but for such fork scenarios the @author tag is really a great 
thing.

It's currently in the sandbox, so every ASF committer can contribute to it.
We are just touching the surface of getting this stuff back to the ASF. So any 
help is welcome :)

https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge

LieGrue,
strub

--- On Thu, 8/11/11, Stefan Bodewig  wrote:

> From: Stefan Bodewig 
> Subject: Re: [general] Plexus and Commons code inherited from somewhere else
> To: dev@commons.apache.org
> Date: Thursday, August 11, 2011, 9:40 AM
> On 2011-08-11, Mark Struberg wrote:
> 
> > I now grabbed the Ant SVN codebase and figured that
> this got imported
> > from CVS in 2004...
> 
> Most of the exec, io and compress stuff is older.  I
> wrote the initial
> version of the zip package in 2001 and Thomas Haas and
> Conor MacNeill
> did most of the exec things in summer 2000 shortly before
> Ant 1.1, for
> example.
> 
> Ant removed @author tags in March 2004 which should give
> you an idea of
> when the split happened.
> 
> Let me know if you need help navigating Ant's code.
> 
> > Happy to report back fixes, but I'm doing almost a
> blackbox approach
> > for getting the plexus stuff back to the ASF. Of
> course it's ALv1.1
> > licensed, but some folks took the provenience in
> question...
> 
> > Our current approach is to write TCK tests for the
> codehaus plexus
> > classes and then implement own versions without
> looking at the
> > original code.
> 
> I'm glad I don't share your problems ;-)
> 
> Seriously, I am subscribed to maven-dev and was aware of
> what you are
> doing and your approach likely is the best you can do to
> support
> existing plugins.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[sebb]

2011/8/11 Sébastien Brisard :
> OK, this I also think would be useful. But my initial question
> remains, if the object I want to protect is not a RealVector, what do
> you think of my solution ?
> Sébastien

If you create the read-only version by subclassing the writable
version, then you have to ensure that all mutating methods are
overridden.
If a base class is later extended to add a new mutator, the protection is lost.

This can be avoided by using composition, only forwarding safe
methods. However that means the new class is not an instance of the
old class.

Neither is perfect ...

> PS : the problem is likely to occur when listening to other Iterative
> Processes (not only linear solvers). For example, in o.a.c.m.genetics,
> has a StoppingCondition.isSatisfied(Population),
> and Population.addChromosome() would enable the StoppingCondition to
> actually modify the ongoing simulation. Whether it is harmfull, I do
> not know, though.
> So of course, we could come up with a ImmutablePopulation as well, but
> maybe it starts to get complicated?
>
> Sébastien
>
> 2011/8/11 Luc Maisonobe :
>> Le 11/08/2011 10:55, Sébastien Brisard a écrit :
>>>
>>> 2011/8/11 Arne Ploese:

 So you not only want to observe the result, but you want a read only
 RealVector.

>>> That's right. I'm sorry, my first message was not clear, especially if
>>> you did not follow the thread on iterative solvers.
>>> I want to observe the *solver*, and the current state of the solver is
>>> a *RealVector*, which should by no means be modified by the observer.
>>> The safest way to do that would be for the solver to have a method
>>> like
>>> public RealVector getCurrentSolution(){
>>>     return x.copy();
>>> }
>>> but that takes both time and memory. So I was thinking of something more
>>> like
>>> public RealVector getCurrentSolution(){
>>>     return new ReadOnlyRealVector(x);
>>> }
>>> which takes virtually no additional memory (and presumably very little
>>> time). The two advantages of this approach are
>>> * it does not jeopardize the whole hierarchy tree, since you do not
>>> have to create a new interface,
>>> * it is quite general, and could be adopted for any base object (not
>>> only RealVector).
>>> The downside is that some methods throw exceptions, which might be
>>> deemed dirty. I don't really know.
>>
>> Well, in fact I would very much like to have immutable vectors too.
>> Immutability is really a way to simplify implementations. Surprisingly it
>> sometimes also decrease time and memory consumption, because defensive
>> copies littering user code can be avoided.
>>
>> Jeopardizing the hierarchy tree is not a problem IMHO.
>>
>> Luc
>>
>>> S
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Sébastien Brisard]

2011/8/11 sebb :
> 2011/8/11 Sébastien Brisard :
>> OK, this I also think would be useful. But my initial question
>> remains, if the object I want to protect is not a RealVector, what do
>> you think of my solution ?
>> Sébastien
>
> If you create the read-only version by subclassing the writable
> version, then you have to ensure that all mutating methods are
> overridden.
> If a base class is later extended to add a new mutator, the protection is 
> lost.
That's quite true... Didn't think of that. It pretty much ruins it, doesn't it?

Sebastien

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Luc Maisonobe]

Le 11/08/2011 12:24, Sébastien Brisard a écrit :


Well, in fact I would very much like to have immutable vectors too.
Immutability is really a way to simplify implementations. Surprisingly it
sometimes also decrease time and memory consumption, because defensive
copies littering user code can be avoided.


Luc, I have a silly question. Why do you think immutable vectors would
prevent defensive copy ? Creating an immutable vector from an existing
mutable vector would require a defensive copy, wouldn't it?


Yes, of course. What I meant is that when users don't have the choice 
and are forced to use only mutable objects, then in many places they do 
defensive copying, just because they do not even know if some other code 
will attempt to modify the object in place after they have retrieved it. 
So you end up with "B b = a.getB().clone()" to protect the B instance.


When instances are known to be immutable, you don't copy them (and you 
often neither implement Cloneable nor set up copy constructors).



Thats the reason why I'm talking about read-only vectors, and not
immutable vectors.
The solver would keep a reference to the underlying (mutable) vector,
so would be able to modify (indirectly) the read-only vector.
The observer would only have a reference to the read-only vector, so
would not be able to modify the underlying vector.


The problem with this approach is that the observer could not preserve 
the instance across several calls (for example to compare the instance 
from one previous call to the current one). If a specific observer wants 
to do that, then it needs to be able to copy the instance. If the 
observer knows the object is immutable, it will only preserve the reference.


Luc



Sébastien

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Gilles Sadowski]

Hello Sébastien.

> >
> > Well, in fact I would very much like to have immutable vectors too.
> > Immutability is really a way to simplify implementations. Surprisingly it
> > sometimes also decrease time and memory consumption, because defensive
> > copies littering user code can be avoided.
> >
> Luc, I have a silly question. Why do you think immutable vectors would
> prevent defensive copy ? Creating an immutable vector from an existing
> mutable vector would require a defensive copy, wouldn't it?
> Thats the reason why I'm talking about read-only vectors, and not
> immutable vectors.
> The solver would keep a reference to the underlying (mutable) vector,
> so would be able to modify (indirectly) the read-only vector.
> The observer would only have a reference to the read-only vector, so
> would not be able to modify the underlying vector.

I think that you were right to stress the difference between immutable and
read-only.
If I'm not mistaken, in JDK parlance they call the latter "unmodifiable"
(cf. the methods "unmodifiableCollection" and siblings in the standard class
"java.util.Collections").

The idea which you referred to at the beginning of this thread is exactly
what they do: The wrapping class throws "UnsupportedOperationException" from
any "mutating" method.

What Luc said is that when you pass an (already) immutable object, you do not
have to make a copy; a reference is as safe.

I'm not sure whether that would still be true with an unmodifiable
reference. I.e. couldn't it be cast to its underlying modifiable reference?
However that would be on-purpose nasty code, not a mistake on the part of
the checker code.

So, a utility method like
  public static RealVector unmodifiableRealVector(RealVector v)
in class "AbstractRealVector", would fit your need, IMO.


Best,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 30 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 15 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.16 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec

Results :

Tests in error: 
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)

Tests run: 179, Failures: 0, Errors: 1, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 14 seconds
[INFO] Finished at: Thu Aug 11 11:20:38 UTC 2011
[INFO] Final Memory: 24M/58M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml
- Atom: 
http://vmgump.apache.org

Re: [math] Read-only RealVector

[Luc Maisonobe]

Le 11/08/2011 13:10, Sébastien Brisard a écrit :

2011/8/11 sebb:

2011/8/11 Sébastien Brisard:

OK, this I also think would be useful. But my initial question
remains, if the object I want to protect is not a RealVector, what do
you think of my solution ?
Sébastien


If you create the read-only version by subclassing the writable
version, then you have to ensure that all mutating methods are
overridden.
If a base class is later extended to add a new mutator, the protection is lost.

That's quite true... Didn't think of that. It pretty much ruins it, doesn't it?


You can also have a common interface without modification methods, and 
two implementations, an immutable one and a mutable one (I think this is 
how Scala containers are designed).


Luc



Sebastien

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Sébastien Brisard]

>
> You can also have a common interface without modification methods, and two
> implementations, an immutable one and a mutable one (I think this is how
> Scala containers are designed).
>
> Luc
>
That is I suppose the cleanest approach, but within the solver's loop,
I need the current solution to be modifiable, while I need the
solution returned by getSolution() to be read-only. therefore, if I
have those two implementations, I will need a deep copy somewhere, no?
Or would the solver be creating a new (immutable) vector at each
iteration? Maybe this is not so much of an overhead, after all. How
about memory?
On the other hand, referring to your previous message: I actually like
the fact that the observer is responsible for making deep copies. By
default, this minimizes the number of deep-copies.
>>
>> Sebastien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Re: SingularValueDecompositionImpl

[Gilles Sadowski]

> > In the SVD class I notice:
> >
> > FastMath.max(m, n)
> >
> > all over the place. Since these values are known when the constructor is
> > called and are final, would anyone object to making the result a private
> > instance variable?

I see only 2 places: lines 557 and 569.
[In one of them it is "Math.max(m, n)".]


Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Gilles Sadowski]

On Thu, Aug 11, 2011 at 01:16:32PM +0200, Luc Maisonobe wrote:
> Le 11/08/2011 12:24, Sébastien Brisard a écrit :
> >>
> >>Well, in fact I would very much like to have immutable vectors too.
> >>Immutability is really a way to simplify implementations. Surprisingly it
> >>sometimes also decrease time and memory consumption, because defensive
> >>copies littering user code can be avoided.
> >>
> >Luc, I have a silly question. Why do you think immutable vectors would
> >prevent defensive copy ? Creating an immutable vector from an existing
> >mutable vector would require a defensive copy, wouldn't it?
> 
> Yes, of course. What I meant is that when users don't have the
> choice and are forced to use only mutable objects, then in many
> places they do defensive copying, just because they do not even know
> if some other code will attempt to modify the object in place after
> they have retrieved it. So you end up with "B b = a.getB().clone()"
> to protect the B instance.
> 
> When instances are known to be immutable, you don't copy them (and
> you often neither implement Cloneable nor set up copy constructors).
> 
> >Thats the reason why I'm talking about read-only vectors, and not
> >immutable vectors.
> >The solver would keep a reference to the underlying (mutable) vector,
> >so would be able to modify (indirectly) the read-only vector.
> >The observer would only have a reference to the read-only vector, so
> >would not be able to modify the underlying vector.
> 
> The problem with this approach is that the observer could not
> preserve the instance across several calls (for example to compare
> the instance from one previous call to the current one). If a
> specific observer wants to do that, then it needs to be able to copy
> the instance. If the observer knows the object is immutable, it will
> only preserve the reference.

If the vector must be mutable, because it is changed in place as the
algorithm iterates, and if the checker needs to keep older states, it
must copy the current solution passed to it. Thus you don't save
anything (a copy must be made either in the solver or in the checker).

With an immutable vector, you create a new intance at each iteration but you
can pass it directly (no copy) and the checker can keep it (also without
making a copy).


Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] Some ZIP64 Interop Results

[Emmanuel Bourg]

Le 01/08/2011 16:49, Stefan Bodewig a écrit :


All other archives are read correctly by ZipArchiveInputStream, there is
a problem with reading the size of the big entry inside the archive
created by jar, but this clearly is a bug in Java7 and I'm going to
report it against OpenJDK[1] (and may have a workaround, need to think
about it a bit longer).


Just stumbled on this:

http://blogs.oracle.com/xuemingshen/entry/is_zipinput_outputstream_handling_of

Is this a follow up of the issue you spotted?


Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]

[sebb]

On 11 August 2011 10:21, Ceki Gülcü  wrote:
> On 11/08/2011 8:13 AM, Henri Yandell wrote:
>
>
>> I was going to say: "That would put Sebb in charge of the ASF!!!", but
>> then I noticed that after the import of Jena Andy Seaborne appears to
>> be the top count committer (I know, that doesn't measure size of
>> commit).  [http://svnsearch.org/svnsearch/repos/ASF/search]
>
> The person with the most commit points is not necessarily in
> charge. Sebastian Bazley's vote would carry more weight than Henri

Why should my vote carry more weight?

I may have created more SVN revisions than others, but I don't think
that gives my vote any more value.

Apart from the fact that commit count has little bearing on actual
work done, and is not an indicator of quality, there are other ways of
contributing (e.g. mailing list feedback, commit review, release
testing, bug reporting) that I consider equally valuable.

> Yandell's or Simone Tripodi's vote, but Henri and Simone voting
> together would beat Sebastian's *lone* vote every time. It's basic
> arithmetic and I won't insult you with an example containing figures.
>
>> I think the problem with this is that it's an extremely arbitrary way
>> of dealing with failure to find consensus. It's also not very
>> meritocratic - it's based on what people have done and not what people
>> are willing to do. The 'prove it in a branch' is more merit-based and
>> less likely to result in status quo decisions.
>
> Yes, committocracy, i.e. decision making based on a commit point
> weighted voting system, does only take into account past
> contributions. Future contributions are ignored until such a time
> where the future becomes the past.
>
>> Yup - . It's a good conversation to have had - great to hear of log4j
>> 2.0 work and to have you still active in the conversation.
>
> Yah, it has been a good discussion. Thanks for your time and input.
>
> --
> Ceki
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] Some ZIP64 Interop Results

[Stefan Bodewig]

On 2011-08-11, Emmanuel Bourg wrote:

> Le 01/08/2011 16:49, Stefan Bodewig a écrit :

>> All other archives are read correctly by ZipArchiveInputStream, there is
>> a problem with reading the size of the big entry inside the archive
>> created by jar, but this clearly is a bug in Java7 and I'm going to
>> report it against OpenJDK[1] (and may have a workaround, need to think
>> about it a bit longer).

> Just stumbled on this:

> http://blogs.oracle.com/xuemingshen/entry/is_zipinput_outputstream_handling_of

> Is this a follow up of the issue you spotted?

Looks like it, yes.  I opened
 which was
available until two days ago and no longer is - and I was never notified
of any status change.

The content of the blog article and PKWARE's response is quite differet
from what the InfoZIP implementation does and what the comments inside
the source tree of InfoZIP call "industry interpretation".  I have
reported this as well.

I don't really care much as I know our ZIPs are considered valid by all
ZIP imeplementations I have checked (didn't check PKZIP, though) except
for jar that I'm going to re-access.  And our code consumes archives
created by all those implementations including jar.

Maybe I should write a blog post of my own 8-)

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]

[Paul Benedict]

I agree with sebb. I prefer an organization where everyone gets one
vote. This is obviously not the only way an organization can run, but
I like neither having a diminished or overwhelming power with my vote.
The best part of having only +1 is that you can't use your merit to
strong-arm decisions over anyone -- you have to build consensus using
reason. If you can't convince your team, the idea isn't worth doing no
matter how much more voting power you wish you had. I find this
especially equitable since there can be a split of people who do the
work (committers) and vote (PMC). There are some who commit only and
can't vote, others do commit and vote, and others who just vote. Being
on a PMC myself, I am happy my vote is equal to every one else on the
committee.

On Thu, Aug 11, 2011 at 7:00 AM, sebb  wrote:
> Why should my vote carry more weight?
>
> I may have created more SVN revisions than others, but I don't think
> that gives my vote any more value.
>
> Apart from the fact that commit count has little bearing on actual
> work done, and is not an indicator of quality, there are other ways of
> contributing (e.g. mailing list feedback, commit review, release
> testing, bug reporting) that I consider equally valuable.
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [general] Plexus and Commons code inherited from somewhere else

[Stefan Bodewig]

On 2011-08-11, Mark Struberg wrote:

> commons-exec is actively maintained by Sigi Goeschl. So at least this
> is known to be in good hands.

I didn't mean to imply it wasn't - or any of the other code that was
forked wasn't properly maintained.

> It's currently in the sandbox, so every ASF committer can contribute
> to it.  We are just touching the surface of getting this stuff back to
> the ASF. So any help is welcome :)

> https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge

I know, but my plate is currently more than full, sorry.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[compress] How to deal with long running test? Maven Profile?

[Stefan Bodewig]

Hi,

currently I've set the Zip64SupportTest to @Ignore because - even if you
dont have the integration test archives around - it simply takes too
long to run every time.

Using the pretty decent notebook $work has given to me the whole test
takes 45 minutes of heavy I/O load and the machine is more or less
unusable during that time.

But then again I surely want to run the tests every now and then and
adding/removing the @Ignore is cumbersome so I thought a profile was the
correct approach.


No, I'm not a mvn expert, have never been, will never be.  I don't use
mvn for anything but Compress and RAT and most things I know I have
learnt by fighting against mvn in Gump - and this is more than I ever
wanted to learn 8-)


My first attempt was to naively exclude the test in the "normal" plugins
section inside the POM and add a profile that defines the surefire
plugin without the excludes.  Excluding works fine but even if I
activate the profile the test remains excluded (I guess I can't undo a
configuration via a profile).

I suspect I'm taking an approach that is completly wrong to begin with
and that many of you around here know exactly what needs to be done.

Please enlighten me.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] How to deal with long running test? Maven Profile?

[sebb]

On 11 August 2011 15:44, Stefan Bodewig  wrote:
> Hi,
>
> currently I've set the Zip64SupportTest to @Ignore because - even if you
> dont have the integration test archives around - it simply takes too
> long to run every time.
>
> Using the pretty decent notebook $work has given to me the whole test
> takes 45 minutes of heavy I/O load and the machine is more or less
> unusable during that time.
>
> But then again I surely want to run the tests every now and then and
> adding/removing the @Ignore is cumbersome so I thought a profile was the
> correct approach.
>
> 
> No, I'm not a mvn expert, have never been, will never be.  I don't use
> mvn for anything but Compress and RAT and most things I know I have
> learnt by fighting against mvn in Gump - and this is more than I ever
> wanted to learn 8-)
> 
>
> My first attempt was to naively exclude the test in the "normal" plugins
> section inside the POM and add a profile that defines the surefire
> plugin without the excludes.  Excluding works fine but even if I
> activate the profile the test remains excluded (I guess I can't undo a
> configuration via a profile).
>
> I suspect I'm taking an approach that is completly wrong to begin with
> and that many of you around here know exactly what needs to be done.
>
> Please enlighten me.

Not tried this, but looks to be what you want:

http://stackoverflow.com/questions/1689242/conditionally-ignoring-tests-in-junit-4

> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] How to deal with long running test? Maven Profile?

[Mark Struberg]

A common pattern is to introduce an own 'run-its' profile which configures 
surefire to pickup those tests.

It's just not good to have tests which in summary takes longer than 3 minutes 
to run. This usually leads to developers using -Dmaven.test.skip=true which is 
kind of counter productive...

LieGrue,
strub

--- On Thu, 8/11/11, Stefan Bodewig  wrote:

> From: Stefan Bodewig 
> Subject: [compress] How to deal with long running test?  Maven Profile?
> To: dev@commons.apache.org
> Date: Thursday, August 11, 2011, 2:44 PM
> Hi,
> 
> currently I've set the Zip64SupportTest to @Ignore because
> - even if you
> dont have the integration test archives around - it simply
> takes too
> long to run every time.
> 
> Using the pretty decent notebook $work has given to me the
> whole test
> takes 45 minutes of heavy I/O load and the machine is more
> or less
> unusable during that time.
> 
> But then again I surely want to run the tests every now and
> then and
> adding/removing the @Ignore is cumbersome so I thought a
> profile was the
> correct approach.
> 
> 
> No, I'm not a mvn expert, have never been, will never
> be.  I don't use
> mvn for anything but Compress and RAT and most things I
> know I have
> learnt by fighting against mvn in Gump - and this is more
> than I ever
> wanted to learn 8-)
> 
> 
> My first attempt was to naively exclude the test in the
> "normal" plugins
> section inside the POM and add a profile that defines the
> surefire
> plugin without the excludes.  Excluding works fine but
> even if I
> activate the profile the test remains excluded (I guess I
> can't undo a
> configuration via a profile).
> 
> I suspect I'm taking an approach that is completly wrong to
> begin with
> and that many of you around here know exactly what needs to
> be done.
> 
> Please enlighten me.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] How to deal with long running test? Maven Profile?

[Stefan Bodewig]

On 2011-08-11, Mark Struberg wrote:

> A common pattern is to introduce an own 'run-its' profile which
> configures surefire to pickup those tests.

How? 8-)

Do I put the test into a separate directory and tell surefire inside the
profile to look into that other dir?

> It's just not good to have tests which in summary takes longer than 3
> minutes to run. This usually leads to developers using
> -Dmaven.test.skip=true which is kind of counter productive...

Absolutely, that why I want to move them to a separate profile.

If you want to test reading of an archive of more than 4GB then you
simply have no choice but to wait for the data to be read - and the
writing tests are even worse, at least on my box.  It simply takes a few
minutes just to move the data from or to the disk.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] How to deal with long running test? Maven Profile?

[Stefan Bodewig]

On 2011-08-11, sebb wrote:

> Not tried this, but looks to be what you want:

> http://stackoverflow.com/questions/1689242/conditionally-ignoring-tests-in-junit-4

I know Assume, even use it inside the test to skip all tests that
require the interop archives when those files are not present.

For this to work I'd need to have a way to know the mvn profile was
active while running the JUnit test.  Hmm, a system property could work.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] How to deal with long running test? Maven Profile?

[sebb]

On 11 August 2011 16:32, Stefan Bodewig  wrote:
> On 2011-08-11, sebb wrote:
>
>> Not tried this, but looks to be what you want:
>
>> http://stackoverflow.com/questions/1689242/conditionally-ignoring-tests-in-junit-4
>
> I know Assume, even use it inside the test to skip all tests that
> require the interop archives when those files are not present.
>
> For this to work I'd need to have a way to know the mvn profile was
> active while running the JUnit test.  Hmm, a system property could work.

Yes, sorry, realised after posting that I'd left that bit out...

> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] How to deal with long running test? Maven Profile?

[Mark Struberg]

usually the maven-surefire-plugin will only pickup classes with the pattern 
*Test.java.
You can rename the longrunning Tests to *IT.java and configure the 
surefireplugin to additionally pickup those test classes only in the run-its 
profile.

   
 
   **/*Test.java
   **/*IT.java
 

LieGrue,
strub

--- On Thu, 8/11/11, Stefan Bodewig  wrote:

> From: Stefan Bodewig 
> Subject: Re: [compress] How to deal with long running test?  Maven Profile?
> To: dev@commons.apache.org
> Date: Thursday, August 11, 2011, 3:29 PM
> On 2011-08-11, Mark Struberg wrote:
> 
> > A common pattern is to introduce an own 'run-its'
> profile which
> > configures surefire to pickup those tests.
> 
> How? 8-)
> 
> Do I put the test into a separate directory and tell
> surefire inside the
> profile to look into that other dir?
> 
> > It's just not good to have tests which in summary
> takes longer than 3
> > minutes to run. This usually leads to developers
> using
> > -Dmaven.test.skip=true which is kind of counter
> productive...
> 
> Absolutely, that why I want to move them to a separate
> profile.
> 
> If you want to test reading of an archive of more than 4GB
> then you
> simply have no choice but to wait for the data to be read -
> and the
> writing tests are even worse, at least on my box.  It
> simply takes a few
> minutes just to move the data from or to the disk.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[JCS] Call for JCS Logo, was:Deployed Maven2 site

[Thomas Vandahl]

On 11.08.11 00:00, sebb wrote:
> Only missing item is a logo for the component.

Well, then, I hereby declare the contest open. Your contributions are
welcome. :-)

Bye, Thomas.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[JCS] Generics problem, looking for advice

[Thomas Vandahl]

Hi folks,

this special generics case is beyond my skills. Please see
org.apache.jcs.utils.struct.DoubleLinkedList. The DoubleLinkedListNode
needs to be generified. However I was not able to find a solution that
makes the compiler happy.

Any suggestions how to solve this?

Bye, Thomas.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Arne Ploese]

Am Donnerstag, den 11.08.2011, 10:55 +0200 schrieb Sébastien Brisard: 
> 2011/8/11 Arne Ploese :
> > So you not only want to observe the result, but you want a read only
> > RealVector.
> >
> That's right. I'm sorry, my first message was not clear, especially if
> you did not follow the thread on iterative solvers.
> I want to observe the *solver*, and the current state of the solver is
> a *RealVector*, which should by no means be modified by the observer.
> The safest way to do that would be for the solver to have a method
> like
> public RealVector getCurrentSolution(){
> return x.copy();
> }
> but that takes both time and memory. So I was thinking of something more like
> public RealVector getCurrentSolution(){
> return new ReadOnlyRealVector(x);
> }
> which takes virtually no additional memory (and presumably very little
> time). The two advantages of this approach are
> * it does not jeopardize the whole hierarchy tree, since you do not
> have to create a new interface,
That is true, but you dont get a compile time error if you pass the
instance by accident to somewhere and that one tries to do an xxxToSelf,
which will result in a RuntimeError - not a very clean solution ... more
a hot fix. Having an interface would clear state what you can do and
what not.
> * it is quite general, and could be adopted for any base object (not
> only RealVector).
> The downside is that some methods throw exceptions, which might be
> deemed dirty. I don't really know.
> S



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[codec] getting the bmpm code out there

[Matthew Pocock]

Hi,

As those of you who've been following the CODEC-125 ticket will know, with
Greg's help I've got a port of the beider morse phonetic
matching (bmpm) algorithm in as a string encoder. As far as I can tell, it's
ready for people to use and abuse. It ideally needs more test-case words,
but to the best of my knowledge it doesn't have any horrendous bugs or
performance issues.

The discussion on the ticket started to stray off bmpm and on to policy for
releases and changing APIs, and Sebb said we should discuss it on the list.
So, here we are.

Ideally, I'd like there to be a release of commons-codec some time soon so
that users can start to try out bmpm right away, and so that we can start
the process of adding it to the list of supported indexing methods in solr.
What do people think?

Matthew

-- 
Dr Matthew Pocock
Visitor, School of Computing Science, Newcastle University
mailto: turingatemyhams...@gmail.com
gchat: turingatemyhams...@gmail.com
msn: matthew_poc...@yahoo.co.uk
irc.freenode.net: drdozer
tel: (0191) 2566550
mob: +447535664143

Re: [math] Read-only RealVector

[Luc Maisonobe]

Le 11/08/2011 13:29, Sébastien Brisard a écrit :


You can also have a common interface without modification methods, and two
implementations, an immutable one and a mutable one (I think this is how
Scala containers are designed).

Luc


That is I suppose the cleanest approach, but within the solver's loop,
I need the current solution to be modifiable, while I need the
solution returned by getSolution() to be read-only. therefore, if I
have those two implementations, I will need a deep copy somewhere, no?
Or would the solver be creating a new (immutable) vector at each
iteration? Maybe this is not so much of an overhead, after all. How
about memory?


Perhaps a top level immutable class and a derived mutable class would 
avoid copying. Internally, the algorithm would know its instance is 
mutable, but it would not advertise it outside and the signature would 
only return the immutable class.


This is however neither really clean nor foolproof. Users may think the 
reference they get is immutable for everyone, so they could store a 
reference, but as the algorithm may change it under the hood, it would 
break users assumptions.


Concerning memory, I would say that with modern computer, copying a few 
megabytes is really not a problem. This does not scale up to gigabytes 
or terabytes. In these cases, I guess we can rely only on documentation 
and warn users that they get a reference to internal objects and that 
they should *never* change them. The only thing we can do to improve 
this is adding a read-only wrapper as you suggested (I think) some 
messages ago.


There is no perfect solution.

Luc


On the other hand, referring to your previous message: I actually like
the fact that the observer is responsible for making deep copies. By
default, this minimizes the number of deep-copies.


Sebastien

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] getting the bmpm code out there

[sebb]

On 11 August 2011 19:38, Matthew Pocock  wrote:
> Hi,
>
> As those of you who've been following the CODEC-125 ticket will know, with
> Greg's help I've got a port of the beider morse phonetic
> matching (bmpm) algorithm in as a string encoder. As far as I can tell, it's
> ready for people to use and abuse. It ideally needs more test-case words,
> but to the best of my knowledge it doesn't have any horrendous bugs or
> performance issues.
>
> The discussion on the ticket started to stray off bmpm and on to policy for
> releases and changing APIs, and Sebb said we should discuss it on the list.
> So, here we are.
>
> Ideally, I'd like there to be a release of commons-codec some time soon so
> that users can start to try out bmpm right away, and so that we can start
> the process of adding it to the list of supported indexing methods in solr.
> What do people think?

The reason I raised the issue was that the API seems to be currently
in a state of flux.

Most Commons components strive for binary compatibility between releases.
Where this cannot be achieved, normally this requires a change of
package name and Maven id (as well as major version bump).
This is to avoid the jar hell that can occur where two or more other
pieces of code require different versions of the API, and where it's
not possible to update all references to the changed code at once.

In this case, because the BMPM code is new, it might be possible to
relax the requirement somewhat, so long as the code API is documented
as being unstable.

If we do have to change BMPM in a way that is not binary compatible,
then all code that uses the BMPM classes will need to be updated.
This should be much less of an issue than if (say) the Base64 classes
were changed, as there should not be many external classes that use
BMPM in a given application.


> Matthew
>
> --
> Dr Matthew Pocock
> Visitor, School of Computing Science, Newcastle University
> mailto: turingatemyhams...@gmail.com
> gchat: turingatemyhams...@gmail.com
> msn: matthew_poc...@yahoo.co.uk
> irc.freenode.net: drdozer
> tel: (0191) 2566550
> mob: +447535664143
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] getting the bmpm code out there

[Matthew Pocock]

Hi Sebb,


> The reason I raised the issue was that the API seems to be currently
> in a state of flux.
>

The BMPM code has not appeared in a previous release. It is a discrete
addition that doesn't alter any existing code, and as far as I know,
currently no 3rd party code relies upon it. Right now on trunk, it is a
StringEncoder.


> In this case, because the BMPM code is new, it might be possible to
> relax the requirement somewhat, so long as the code API is documented
> as being unstable.
>

I've no problem with marking it as new or unstable or whatever the right
word is. While it extends StringEncoder, the API is stable. Although there
may be more flux with the finer details of the string you get out for the
string you put in as we fix bugs and update the rule tables, this shouldn't
alter how clients (users of the API) call this code, only the quality of the
results they get back.


>
> If we do have to change BMPM in a way that is not binary compatible,
> then all code that uses the BMPM classes will need to be updated.
>

Understood. I think this only becomes an issue if/when Encoder becomes
generified, and at that point clearly we need a big version bump, with all
the associated changes, and all encoders and their clients would be equally
affected.

Does that help, or have I further muddied the waters?

Matthew

-- 
Dr Matthew Pocock
Visitor, School of Computing Science, Newcastle University
mailto: turingatemyhams...@gmail.com
gchat: turingatemyhams...@gmail.com
msn: matthew_poc...@yahoo.co.uk
irc.freenode.net: drdozer
tel: (0191) 2566550
mob: +447535664143

Re: [codec] getting the bmpm code out there

[Gary Gregory]

Hello All!

Topic 1: Housekeeping: package name and POM.

The next codec release out of trunk will be major release labeled 2.0,
the current release is 1.5.

In trunk, I've removed deprecated methods and the project now requires
Java 5. This means 2.0 will not be a drop-in binary compatible release
for 1.5.

I'd like to confirm or deny that this means the package name will
change to o.a.c.codec2 and that the POM groupId will have to change
from commons-codec to org.apache.commons. 2.0 and 1.5 would be able to
live side by side.

I'd like to get this out of the way first hence topic 1.


Topic 2: Beider-Morse (BM) Encoder API
https://issues.apache.org/jira/browse/CODEC-125

BM is a new codec for 2.0.

The encode API returns a set of encodings.

In trunk, this is currently a String in the format "s1|s2|s3".

I think this is not the best design, a set should be a Set, in this
case, an ordered set. Or, a List. Generally, it should be a Collection
of Strings.

There was concern with call sites that generically use a [codec]
Encoder with the signature "Object encoder(Object)" and call
toString() on the result.

If we set the API to "CharSequence encode(Set)" or
"String encode(Set)", doing a toString() on a HashSet will
yield a usable String similar as to what trunk does now. For example,
for a HashSet of Strings "a", "b" and "c", HashSet.toString() returns
"[a, b, c]" which no worse than "a|b|c" IMO. At least it is a
documented and stable format.


Topic 3: Generics

This will be in a separate thread but I'd like to get this in 2.0
because this will likely break the API and I only want to break things
once and not have to do a codec3 for generics.

Thank you all,
Gary

On Thu, Aug 11, 2011 at 2:38 PM, Matthew Pocock
 wrote:
> Hi,
>
> As those of you who've been following the CODEC-125 ticket will know, with
> Greg's help I've got a port of the beider morse phonetic
> matching (bmpm) algorithm in as a string encoder. As far as I can tell, it's
> ready for people to use and abuse. It ideally needs more test-case words,
> but to the best of my knowledge it doesn't have any horrendous bugs or
> performance issues.
>
> The discussion on the ticket started to stray off bmpm and on to policy for
> releases and changing APIs, and Sebb said we should discuss it on the list.
> So, here we are.
>
> Ideally, I'd like there to be a release of commons-codec some time soon so
> that users can start to try out bmpm right away, and so that we can start
> the process of adding it to the list of supported indexing methods in solr.
> What do people think?
>
> Matthew
>
> --
> Dr Matthew Pocock
> Visitor, School of Computing Science, Newcastle University
> mailto: turingatemyhams...@gmail.com
> gchat: turingatemyhams...@gmail.com
> msn: matthew_poc...@yahoo.co.uk
> irc.freenode.net: drdozer
> tel: (0191) 2566550
> mob: +447535664143
>



-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Phil Steitz]

On 8/11/11 4:22 AM, Gilles Sadowski wrote:
> Hello Sébastien.
>
>>> Well, in fact I would very much like to have immutable vectors too.
>>> Immutability is really a way to simplify implementations. Surprisingly it
>>> sometimes also decrease time and memory consumption, because defensive
>>> copies littering user code can be avoided.
>>>
>> Luc, I have a silly question. Why do you think immutable vectors would
>> prevent defensive copy ? Creating an immutable vector from an existing
>> mutable vector would require a defensive copy, wouldn't it?
>> Thats the reason why I'm talking about read-only vectors, and not
>> immutable vectors.
>> The solver would keep a reference to the underlying (mutable) vector,
>> so would be able to modify (indirectly) the read-only vector.
>> The observer would only have a reference to the read-only vector, so
>> would not be able to modify the underlying vector.
> I think that you were right to stress the difference between immutable and
> read-only.
> If I'm not mistaken, in JDK parlance they call the latter "unmodifiable"
> (cf. the methods "unmodifiableCollection" and siblings in the standard class
> "java.util.Collections").
>
> The idea which you referred to at the beginning of this thread is exactly
> what they do: The wrapping class throws "UnsupportedOperationException" from
> any "mutating" method.
>
> What Luc said is that when you pass an (already) immutable object, you do not
> have to make a copy; a reference is as safe.
>
> I'm not sure whether that would still be true with an unmodifiable
> reference. I.e. couldn't it be cast to its underlying modifiable reference?
> However that would be on-purpose nasty code, not a mistake on the part of
> the checker code.
>
> So, a utility method like
>   public static RealVector unmodifiableRealVector(RealVector v)
> in class "AbstractRealVector", would fit your need, IMO.

+1 - looks to me like what is needed is an unmodifiable view,
exactly like what the UnmodifiableCollections provide.   What is
returned in the methods analogous to the above in
Collections.unModifiableXxx are instances of private static inner
classes that decorate the actual parameter and delegate, throwing
UnsupportedOperationExceptions for mutators.  See either
[collections] or the Harmony code [1] for examples.

Phil

[1] http://s.apache.org/XJ4
>
>
> Best,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] getting the bmpm code out there

[sebb]

On 11 August 2011 20:56, Gary Gregory  wrote:
> Hello All!
>
> Topic 1: Housekeeping: package name and POM.
>
> The next codec release out of trunk will be major release labeled 2.0,
> the current release is 1.5.
>
> In trunk, I've removed deprecated methods and the project now requires
> Java 5. This means 2.0 will not be a drop-in binary compatible release
> for 1.5.
>
> I'd like to confirm or deny that this means the package name will
> change to o.a.c.codec2 and that the POM groupId will have to change
> from commons-codec to org.apache.commons. 2.0 and 1.5 would be able to
> live side by side.

Yes, the name changes are necessary to avoid problems with incompatible jars.

> I'd like to get this out of the way first hence topic 1.
>
>
> Topic 2: Beider-Morse (BM) Encoder API
> https://issues.apache.org/jira/browse/CODEC-125
>
> BM is a new codec for 2.0.
>
> The encode API returns a set of encodings.
>
> In trunk, this is currently a String in the format "s1|s2|s3".
>
> I think this is not the best design, a set should be a Set, in this
> case, an ordered set. Or, a List. Generally, it should be a Collection
> of Strings.
>
> There was concern with call sites that generically use a [codec]
> Encoder with the signature "Object encoder(Object)" and call
> toString() on the result.
>
> If we set the API to "CharSequence encode(Set)" or
> "String encode(Set)", doing a toString() on a HashSet will
> yield a usable String similar as to what trunk does now. For example,
> for a HashSet of Strings "a", "b" and "c", HashSet.toString() returns
> "[a, b, c]" which no worse than "a|b|c" IMO. At least it is a
> documented and stable format.

+1

> Topic 3: Generics
>
> This will be in a separate thread but I'd like to get this in 2.0
> because this will likely break the API and I only want to break things
> once and not have to do a codec3 for generics.

+1.

> Thank you all,
> Gary
>
> On Thu, Aug 11, 2011 at 2:38 PM, Matthew Pocock
>  wrote:
>> Hi,
>>
>> As those of you who've been following the CODEC-125 ticket will know, with
>> Greg's help I've got a port of the beider morse phonetic
>> matching (bmpm) algorithm in as a string encoder. As far as I can tell, it's
>> ready for people to use and abuse. It ideally needs more test-case words,
>> but to the best of my knowledge it doesn't have any horrendous bugs or
>> performance issues.
>>
>> The discussion on the ticket started to stray off bmpm and on to policy for
>> releases and changing APIs, and Sebb said we should discuss it on the list.
>> So, here we are.
>>
>> Ideally, I'd like there to be a release of commons-codec some time soon so
>> that users can start to try out bmpm right away, and so that we can start
>> the process of adding it to the list of supported indexing methods in solr.
>> What do people think?
>>
>> Matthew
>>
>> --
>> Dr Matthew Pocock
>> Visitor, School of Computing Science, Newcastle University
>> mailto: turingatemyhams...@gmail.com
>> gchat: turingatemyhams...@gmail.com
>> msn: matthew_poc...@yahoo.co.uk
>> irc.freenode.net: drdozer
>> tel: (0191) 2566550
>> mob: +447535664143
>>
>
>
>
> --
> Thank you,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] getting the bmpm code out there

[sebb]

On 11 August 2011 20:55, Matthew Pocock  wrote:
> Hi Sebb,
>
>
>> The reason I raised the issue was that the API seems to be currently
>> in a state of flux.
>>
>
> The BMPM code has not appeared in a previous release. It is a discrete
> addition that doesn't alter any existing code, and as far as I know,
> currently no 3rd party code relies upon it. Right now on trunk, it is a
> StringEncoder.

OK

>
>> In this case, because the BMPM code is new, it might be possible to
>> relax the requirement somewhat, so long as the code API is documented
>> as being unstable.
>>
>
> I've no problem with marking it as new or unstable or whatever the right
> word is. While it extends StringEncoder, the API is stable. Although there
> may be more flux with the finer details of the string you get out for the
> string you put in as we fix bugs and update the rule tables, this shouldn't
> alter how clients (users of the API) call this code, only the quality of the
> results they get back.

OK, that won't affect binary compat.

>
>>
>> If we do have to change BMPM in a way that is not binary compatible,
>> then all code that uses the BMPM classes will need to be updated.
>>
>
> Understood. I think this only becomes an issue if/when Encoder becomes
> generified, and at that point clearly we need a big version bump, with all
> the associated changes, and all encoders and their clients would be equally
> affected.

Indeed.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] getting the bmpm code out there

[Gary Gregory]

On Thu, Aug 11, 2011 at 4:10 PM, sebb  wrote:
> On 11 August 2011 20:56, Gary Gregory  wrote:
>> Hello All!
>>
>> Topic 1: Housekeeping: package name and POM.
>>
>> The next codec release out of trunk will be major release labeled 2.0,
>> the current release is 1.5.
>>
>> In trunk, I've removed deprecated methods and the project now requires
>> Java 5. This means 2.0 will not be a drop-in binary compatible release
>> for 1.5.
>>
>> I'd like to confirm or deny that this means the package name will
>> change to o.a.c.codec2 and that the POM groupId will have to change
>> from commons-codec to org.apache.commons. 2.0 and 1.5 would be able to
>> live side by side.
>
> Yes, the name changes are necessary to avoid problems with incompatible jars.

Ok, I'll do that tonight.

Gary

>
>> I'd like to get this out of the way first hence topic 1.
>>
>>
>> Topic 2: Beider-Morse (BM) Encoder API
>> https://issues.apache.org/jira/browse/CODEC-125
>>
>> BM is a new codec for 2.0.
>>
>> The encode API returns a set of encodings.
>>
>> In trunk, this is currently a String in the format "s1|s2|s3".
>>
>> I think this is not the best design, a set should be a Set, in this
>> case, an ordered set. Or, a List. Generally, it should be a Collection
>> of Strings.
>>
>> There was concern with call sites that generically use a [codec]
>> Encoder with the signature "Object encoder(Object)" and call
>> toString() on the result.
>>
>> If we set the API to "CharSequence encode(Set)" or
>> "String encode(Set)", doing a toString() on a HashSet will
>> yield a usable String similar as to what trunk does now. For example,
>> for a HashSet of Strings "a", "b" and "c", HashSet.toString() returns
>> "[a, b, c]" which no worse than "a|b|c" IMO. At least it is a
>> documented and stable format.
>
> +1
>
>> Topic 3: Generics
>>
>> This will be in a separate thread but I'd like to get this in 2.0
>> because this will likely break the API and I only want to break things
>> once and not have to do a codec3 for generics.
>
> +1.
>
>> Thank you all,
>> Gary
>>
>> On Thu, Aug 11, 2011 at 2:38 PM, Matthew Pocock
>>  wrote:
>>> Hi,
>>>
>>> As those of you who've been following the CODEC-125 ticket will know, with
>>> Greg's help I've got a port of the beider morse phonetic
>>> matching (bmpm) algorithm in as a string encoder. As far as I can tell, it's
>>> ready for people to use and abuse. It ideally needs more test-case words,
>>> but to the best of my knowledge it doesn't have any horrendous bugs or
>>> performance issues.
>>>
>>> The discussion on the ticket started to stray off bmpm and on to policy for
>>> releases and changing APIs, and Sebb said we should discuss it on the list.
>>> So, here we are.
>>>
>>> Ideally, I'd like there to be a release of commons-codec some time soon so
>>> that users can start to try out bmpm right away, and so that we can start
>>> the process of adding it to the list of supported indexing methods in solr.
>>> What do people think?
>>>
>>> Matthew
>>>
>>> --
>>> Dr Matthew Pocock
>>> Visitor, School of Computing Science, Newcastle University
>>> mailto: turingatemyhams...@gmail.com
>>> gchat: turingatemyhams...@gmail.com
>>> msn: matthew_poc...@yahoo.co.uk
>>> irc.freenode.net: drdozer
>>> tel: (0191) 2566550
>>> mob: +447535664143
>>>
>>
>>
>>
>> --
>> Thank you,
>> Gary
>>
>> http://garygregory.wordpress.com/
>> http://garygregory.com/
>> http://people.apache.org/~ggregory/
>> http://twitter.com/GaryGregory
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>



-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[math] Numerical derivatives in Commons Math

[Fran Lattanzio]

Hello,

I have a proposal for a numerical derivatives framework for Commons
Math. I'd like to add the ability to take any UnivariateRealFunction
and produce another function that represents it's derivative for an
arbitrary order. Basically, I'm saying add a factory-like interface
that looks something like the following:

public interface UniverateNumericalDeriver {
 public UnivariateRealFunction derive(UnivariateRealFunction f, int derivOrder);
}

For an initial implementation of this interface, I propose using
finite differences - either central, forward, or backward. Computing
the finite difference coefficients, for any derivative order and any
error order, is a relatively trivial linear algebra problem. The user
will simply choose an error order and difference type when setting up
an FD univariate deriver - everything else will happen automagically.
You can compute the FD coefficients once the user invokes the function
in the interface above (might be expensive), and determine an
appropriate stencil width when they call evaluate(double) on the
function returned by the aformentioned method - for example, if the
user has asked for the nth derivative, we simply use the nth root of
the machine epsilon/double ulp for the stencil width. It would also be
pretty easy to let the user control this (which might be desirable in
some cases). Wikipedia has decent article on FDs of all flavors:
http://en.wikipedia.org/wiki/Finite_difference

There are, of course, many other univariate numerical derivative
schemes that could be added in the future - using Fourier transforms,
Barak's adaptive degree polynomial method, etc. These could be added
later. We could also add the ability to numerically differentiate at
single point using an arbitrary or user-defined grid (rather than an
automatically generated one, like above). Barak's method and Fornberg
finite difference coefficients could be used in this case:
http://pubs.acs.org/doi/abs/10.1021/ac00113a006
http://amath.colorado.edu/faculty/fornberg/Docs/MathComp_88_FD_formulas.pdf

It would also make sense to add vectorial and matrix-flavored versions
of interface above. These interfaces would be slightly more complex,
but nothing too crazy. Again, the initial implementation would be
finite differences. This would also be really easy to implement, since
multivariate FD coefficients are nothing more than an outer product of
their univariate cousins. The Wikipedia article also has some good
introductory material on multivariate FDs.

Cheers,
Fran.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[lang] Error in 2.0 to 3.0 Clirr report

[Gary Gregory]

Hi All:

The 2.0 to 3.0 Clirr report here:

https://commons.apache.org/lang/lang2-lang3-clirr-report.html

lists that all classes added are in the .lang. package instead of the
.lang3. package.

Cheers,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Re: SingularValueDecompositionImpl

[Greg Sterijevski]

At least three with some code I checked in last night. The point is that
there is no reason to replicate the same thing over and over again.

-Greg

On Thu, Aug 11, 2011 at 6:33 AM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:

> > > In the SVD class I notice:
> > >
> > > FastMath.max(m, n)
> > >
> > > all over the place. Since these values are known when the constructor
> is
> > > called and are final, would anyone object to making the result a
> private
> > > instance variable?
>
> I see only 2 places: lines 557 and 569.
> [In one of them it is "Math.max(m, n)".]
>
>
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [math] Numerical derivatives in Commons Math

[Luc Maisonobe]

Le 11/08/2011 23:27, Fran Lattanzio a écrit :

Hello,


Hi Fran,



I have a proposal for a numerical derivatives framework for Commons
Math. I'd like to add the ability to take any UnivariateRealFunction
and produce another function that represents it's derivative for an
arbitrary order. Basically, I'm saying add a factory-like interface
that looks something like the following:

public interface UniverateNumericalDeriver {
  public UnivariateRealFunction derive(UnivariateRealFunction f, int 
derivOrder);
}


This sound interesting. did you have a look at Commons Nabla 
UnivariateDifferentiator interface and its implementations ?


Luc



For an initial implementation of this interface, I propose using
finite differences - either central, forward, or backward. Computing
the finite difference coefficients, for any derivative order and any
error order, is a relatively trivial linear algebra problem. The user
will simply choose an error order and difference type when setting up
an FD univariate deriver - everything else will happen automagically.
You can compute the FD coefficients once the user invokes the function
in the interface above (might be expensive), and determine an
appropriate stencil width when they call evaluate(double) on the
function returned by the aformentioned method - for example, if the
user has asked for the nth derivative, we simply use the nth root of
the machine epsilon/double ulp for the stencil width. It would also be
pretty easy to let the user control this (which might be desirable in
some cases). Wikipedia has decent article on FDs of all flavors:
http://en.wikipedia.org/wiki/Finite_difference

There are, of course, many other univariate numerical derivative
schemes that could be added in the future - using Fourier transforms,
Barak's adaptive degree polynomial method, etc. These could be added
later. We could also add the ability to numerically differentiate at
single point using an arbitrary or user-defined grid (rather than an
automatically generated one, like above). Barak's method and Fornberg
finite difference coefficients could be used in this case:
http://pubs.acs.org/doi/abs/10.1021/ac00113a006
http://amath.colorado.edu/faculty/fornberg/Docs/MathComp_88_FD_formulas.pdf

It would also make sense to add vectorial and matrix-flavored versions
of interface above. These interfaces would be slightly more complex,
but nothing too crazy. Again, the initial implementation would be
finite differences. This would also be really easy to implement, since
multivariate FD coefficients are nothing more than an outer product of
their univariate cousins. The Wikipedia article also has some good
introductory material on multivariate FDs.

Cheers,
Fran.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Numerical derivatives in Commons Math

[Patrick Meyer]

I like the idea of adding this feature. What about an abstract class 
that implements DifferentiableMultivariateRealFunction and provides the 
method for partialDerivative (). People could then override the 
partialDerivative method if they have an analytic derivative.


Here's some code that I'm happy to contribute to Commons-math. It 
computes the derivative by the central difference meathod and the 
Hessian by finite difference. I can add this to JIRA when it's there.


/**
 * Numerically compute gradient by the central difference method. 
Override this method

 * when the analytic gradient is available.
 *
 *
 * @param x
 * @return
 */
public double[] derivativeAt(double[] x){
int n = x.length;
double[] grd = new double[n];
double[] u = Arrays.copyOfRange(x, 0, x.length);
double f1 = 0.0;
double f2 = 0.0;
double stepSize = 0.0001;

for(int i=0;istepSize = Math.sqrt(EPSILON)*(Math.abs(x[i])+1.0);//from 
SAS manual on nlp procedure

u[i] = x[i] + stepSize;
f1 = valueAt(u);
u[i] = x[i] - stepSize;
f2 = valueAt(u);
grd[i] = (f1-f2)/(2.0*stepSize);
}
return grd;
}

/**
 * Numerically compute Hessian using a finite difference method. 
Override this

 * method when the analytic Hessian is available.
 *
 * @param x
 * @return
 */
public double[][] hessianAt(double[] x){
int n = x.length;
double[][] hessian = new double[n][n];
double[] gradientAtXpls = null;
double[] gradientAtX = derivativeAt(x);
double xtemp = 0.0;
double stepSize = 0.0001;

for(int j=0;jstepSize = Math.sqrt(EPSILON)*(Math.abs(x[j])+1.0);//from 
SAS manual on nlp procedure

xtemp = x[j];
x[j] = xtemp + stepSize;
double [] x_copy = Arrays.copyOfRange(x, 0, x.length);
gradientAtXpls = derivativeAt(x_copy);
x[j] = xtemp;
for(int i=0;ihessian[i][j] = 
(gradientAtXpls[i]-gradientAtX[i])/stepSize;

}
}
return hessian;
}


On 8/11/2011 5:36 PM, Luc Maisonobe wrote:

Le 11/08/2011 23:27, Fran Lattanzio a écrit :

Hello,


Hi Fran,



I have a proposal for a numerical derivatives framework for Commons
Math. I'd like to add the ability to take any UnivariateRealFunction
and produce another function that represents it's derivative for an
arbitrary order. Basically, I'm saying add a factory-like interface
that looks something like the following:

public interface UniverateNumericalDeriver {
  public UnivariateRealFunction derive(UnivariateRealFunction f, int 
derivOrder);

}


This sound interesting. did you have a look at Commons Nabla 
UnivariateDifferentiator interface and its implementations ?


Luc



For an initial implementation of this interface, I propose using
finite differences - either central, forward, or backward. Computing
the finite difference coefficients, for any derivative order and any
error order, is a relatively trivial linear algebra problem. The user
will simply choose an error order and difference type when setting up
an FD univariate deriver - everything else will happen automagically.
You can compute the FD coefficients once the user invokes the function
in the interface above (might be expensive), and determine an
appropriate stencil width when they call evaluate(double) on the
function returned by the aformentioned method - for example, if the
user has asked for the nth derivative, we simply use the nth root of
the machine epsilon/double ulp for the stencil width. It would also be
pretty easy to let the user control this (which might be desirable in
some cases). Wikipedia has decent article on FDs of all flavors:
http://en.wikipedia.org/wiki/Finite_difference

There are, of course, many other univariate numerical derivative
schemes that could be added in the future - using Fourier transforms,
Barak's adaptive degree polynomial method, etc. These could be added
later. We could also add the ability to numerically differentiate at
single point using an arbitrary or user-defined grid (rather than an
automatically generated one, like above). Barak's method and Fornberg
finite difference coefficients could be used in this case:
http://pubs.acs.org/doi/abs/10.1021/ac00113a006
http://amath.colorado.edu/faculty/fornberg/Docs/MathComp_88_FD_formulas.pdf 



It would also make sense to add vectorial and matrix-flavored versions
of interface above. These interfaces would be slightly more complex,
but nothing too crazy. Again, the initial implementation would be
finite differences. This would also be really easy to implement, since
multivariate FD coefficients are nothing more than an outer product of
their univariate cousins. The Wikipedia article also has some good
introductory material on multivariate FDs.

Cheers,
Fran.

-

Re: [codec] getting the bmpm code out there

[Gary Gregory]

On Thu, Aug 11, 2011 at 4:10 PM, sebb  wrote:
> On 11 August 2011 20:56, Gary Gregory  wrote:
>> Hello All!
>>
>> Topic 1: Housekeeping: package name and POM.
>>
>> The next codec release out of trunk will be major release labeled 2.0,
>> the current release is 1.5.
>>
>> In trunk, I've removed deprecated methods and the project now requires
>> Java 5. This means 2.0 will not be a drop-in binary compatible release
>> for 1.5.
>>
>> I'd like to confirm or deny that this means the package name will
>> change to o.a.c.codec2 and that the POM groupId will have to change
>> from commons-codec to org.apache.commons. 2.0 and 1.5 would be able to
>> live side by side.
>
> Yes, the name changes are necessary to avoid problems with incompatible jars.
>
>> I'd like to get this out of the way first hence topic 1.
>>
>>
>> Topic 2: Beider-Morse (BM) Encoder API
>> https://issues.apache.org/jira/browse/CODEC-125
>>
>> BM is a new codec for 2.0.
>>
>> The encode API returns a set of encodings.
>>
>> In trunk, this is currently a String in the format "s1|s2|s3".
>>
>> I think this is not the best design, a set should be a Set, in this
>> case, an ordered set. Or, a List. Generally, it should be a Collection
>> of Strings.
>>
>> There was concern with call sites that generically use a [codec]
>> Encoder with the signature "Object encoder(Object)" and call
>> toString() on the result.
>>
>> If we set the API to "CharSequence encode(Set)" or
>> "String encode(Set)", doing a toString() on a HashSet will
>> yield a usable String similar as to what trunk does now. For example,
>> for a HashSet of Strings "a", "b" and "c", HashSet.toString() returns
>> "[a, b, c]" which no worse than "a|b|c" IMO. At least it is a
>> documented and stable format.
>
> +1
>
>> Topic 3: Generics
>>
>> This will be in a separate thread but I'd like to get this in 2.0
>> because this will likely break the API and I only want to break things
>> once and not have to do a codec3 for generics.
>
> +1.

I'll work on a generified codec2 over the next couple of days and
present what that looks like, maybe in a branch, or a patch.

Gary

>
>> Thank you all,
>> Gary
>>
>> On Thu, Aug 11, 2011 at 2:38 PM, Matthew Pocock
>>  wrote:
>>> Hi,
>>>
>>> As those of you who've been following the CODEC-125 ticket will know, with
>>> Greg's help I've got a port of the beider morse phonetic
>>> matching (bmpm) algorithm in as a string encoder. As far as I can tell, it's
>>> ready for people to use and abuse. It ideally needs more test-case words,
>>> but to the best of my knowledge it doesn't have any horrendous bugs or
>>> performance issues.
>>>
>>> The discussion on the ticket started to stray off bmpm and on to policy for
>>> releases and changing APIs, and Sebb said we should discuss it on the list.
>>> So, here we are.
>>>
>>> Ideally, I'd like there to be a release of commons-codec some time soon so
>>> that users can start to try out bmpm right away, and so that we can start
>>> the process of adding it to the list of supported indexing methods in solr.
>>> What do people think?
>>>
>>> Matthew
>>>
>>> --
>>> Dr Matthew Pocock
>>> Visitor, School of Computing Science, Newcastle University
>>> mailto: turingatemyhams...@gmail.com
>>> gchat: turingatemyhams...@gmail.com
>>> msn: matthew_poc...@yahoo.co.uk
>>> irc.freenode.net: drdozer
>>> tel: (0191) 2566550
>>> mob: +447535664143
>>>
>>
>>
>>
>> --
>> Thank you,
>> Gary
>>
>> http://garygregory.wordpress.com/
>> http://garygregory.com/
>> http://people.apache.org/~ggregory/
>> http://twitter.com/GaryGregory
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>



-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Numerical derivatives in Commons Math

[Bruce A Johnson]

I'd be quite interested in seeing Numerical Derivatives in CM.  There are some 
interesting ideas about Numerical Differentiation here:

http://www.holoborodko.com/pavel/numerical-methods/

Bruce


On Aug 11, 2011, at 6:30 PM, Patrick Meyer wrote:

> I like the idea of adding this feature. What about an abstract class that 
> implements DifferentiableMultivariateRealFunction and provides the method for 
> partialDerivative (). People could then override the partialDerivative method 
> if they have an analytic derivative.
> 
> Here's some code that I'm happy to contribute to Commons-math. It computes 
> the derivative by the central difference meathod and the Hessian by finite 
> difference. I can add this to JIRA when it's there.
> 
> /**
> * Numerically compute gradient by the central difference method. Override 
> this method
> * when the analytic gradient is available.
> *
> *
> * @param x
> * @return
> */
>public double[] derivativeAt(double[] x){
>int n = x.length;
>double[] grd = new double[n];
>double[] u = Arrays.copyOfRange(x, 0, x.length);
>double f1 = 0.0;
>double f2 = 0.0;
>double stepSize = 0.0001;
> 
>for(int i=0;istepSize = Math.sqrt(EPSILON)*(Math.abs(x[i])+1.0);//from SAS 
> manual on nlp procedure
>u[i] = x[i] + stepSize;
>f1 = valueAt(u);
>u[i] = x[i] - stepSize;
>f2 = valueAt(u);
>grd[i] = (f1-f2)/(2.0*stepSize);
>}
>return grd;
>}
> 
>/**
> * Numerically compute Hessian using a finite difference method. Override 
> this
> * method when the analytic Hessian is available.
> *
> * @param x
> * @return
> */
>public double[][] hessianAt(double[] x){
>int n = x.length;
>double[][] hessian = new double[n][n];
>double[] gradientAtXpls = null;
>double[] gradientAtX = derivativeAt(x);
>double xtemp = 0.0;
>double stepSize = 0.0001;
> 
>for(int j=0;jstepSize = Math.sqrt(EPSILON)*(Math.abs(x[j])+1.0);//from SAS 
> manual on nlp procedure
>xtemp = x[j];
>x[j] = xtemp + stepSize;
>double [] x_copy = Arrays.copyOfRange(x, 0, x.length);
>gradientAtXpls = derivativeAt(x_copy);
>x[j] = xtemp;
>for(int i=0;ihessian[i][j] = (gradientAtXpls[i]-gradientAtX[i])/stepSize;
>}
>}
>return hessian;
>}
> 
> 
> On 8/11/2011 5:36 PM, Luc Maisonobe wrote:
>> Le 11/08/2011 23:27, Fran Lattanzio a écrit :
>>> Hello,
>> 
>> Hi Fran,
>> 
>>> 
>>> I have a proposal for a numerical derivatives framework for Commons
>>> Math. I'd like to add the ability to take any UnivariateRealFunction
>>> and produce another function that represents it's derivative for an
>>> arbitrary order. Basically, I'm saying add a factory-like interface
>>> that looks something like the following:
>>> 
>>> public interface UniverateNumericalDeriver {
>>>  public UnivariateRealFunction derive(UnivariateRealFunction f, int 
>>> derivOrder);
>>> }
>> 
>> This sound interesting. did you have a look at Commons Nabla 
>> UnivariateDifferentiator interface and its implementations ?
>> 
>> Luc
>> 
>>> 
>>> For an initial implementation of this interface, I propose using
>>> finite differences - either central, forward, or backward. Computing
>>> the finite difference coefficients, for any derivative order and any
>>> error order, is a relatively trivial linear algebra problem. The user
>>> will simply choose an error order and difference type when setting up
>>> an FD univariate deriver - everything else will happen automagically.
>>> You can compute the FD coefficients once the user invokes the function
>>> in the interface above (might be expensive), and determine an
>>> appropriate stencil width when they call evaluate(double) on the
>>> function returned by the aformentioned method - for example, if the
>>> user has asked for the nth derivative, we simply use the nth root of
>>> the machine epsilon/double ulp for the stencil width. It would also be
>>> pretty easy to let the user control this (which might be desirable in
>>> some cases). Wikipedia has decent article on FDs of all flavors:
>>> http://en.wikipedia.org/wiki/Finite_difference
>>> 
>>> There are, of course, many other univariate numerical derivative
>>> schemes that could be added in the future - using Fourier transforms,
>>> Barak's adaptive degree polynomial method, etc. These could be added
>>> later. We could also add the ability to numerically differentiate at
>>> single point using an arbitrary or user-defined grid (rather than an
>>> automatically generated one, like above). Barak's method and Fornberg
>>> finite difference coefficients could be used in this case:
>>> http://pubs.acs.org/doi/abs/10.1021/ac00113a006
>>> http://amath.colorado.edu/faculty/fornberg/Docs/MathComp_88_FD_formulas.p

Re: [lang] Error in 2.0 to 3.0 Clirr report

[Henri Yandell]

Modify manually to fix :)

I don't think we'll need to make a new one, that shows 2.6->3.0 and
after that will be generated.

Hen

On Thu, Aug 11, 2011 at 2:28 PM, Gary Gregory  wrote:
> Hi All:
>
> The 2.0 to 3.0 Clirr report here:
>
> https://commons.apache.org/lang/lang2-lang3-clirr-report.html
>
> lists that all classes added are in the .lang. package instead of the
> .lang3. package.
>
> Cheers,
> Gary
>
> http://garygregory.wordpress.com/
> http://garygregory.com/
> http://people.apache.org/~ggregory/
> http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Sébastien Brisard]

Hi,
it's clear I think that there is no really fool-proof solution, but
that's OK I think. The idea would be to avoid accidental modifications
which could be catastrophic. But nothing could prevent an evil
programmer to do its evil job. I like what was earlier pointed out:
Javadoc should be very detailed on these issues.
About having a really immutable vector, it's of course a desirable
feature, but thinking about it, it would be nice to be able to combine
both immutable vectors and mutable vectors. Question is: should the
result be mutable or immutable ? Example
immutale.add(mutable), and the converse mutable.add(immutable). Should
the results be mutable? immutable?
Following the approach in UmmodifiableCollections is probably what
I'll do, except if you like the following (VERY simple) approach
better. Instead of having a method
RealVector getSolution()
how about specifying
RealVector getSolution(boolean deep)
if deep is true, it returns a deep copy, if not it MIGHT (but the
contract of the method does not make it compulsory) return a shallow
copy. The Javadoc should clearly state that if deep is true, then the
user should not modify the returned vector.
Looking forward to hearing what you think,
Sebastien


2011/8/11 Phil Steitz :
> On 8/11/11 4:22 AM, Gilles Sadowski wrote:
>> Hello Sébastien.
>>
 Well, in fact I would very much like to have immutable vectors too.
 Immutability is really a way to simplify implementations. Surprisingly it
 sometimes also decrease time and memory consumption, because defensive
 copies littering user code can be avoided.

>>> Luc, I have a silly question. Why do you think immutable vectors would
>>> prevent defensive copy ? Creating an immutable vector from an existing
>>> mutable vector would require a defensive copy, wouldn't it?
>>> Thats the reason why I'm talking about read-only vectors, and not
>>> immutable vectors.
>>> The solver would keep a reference to the underlying (mutable) vector,
>>> so would be able to modify (indirectly) the read-only vector.
>>> The observer would only have a reference to the read-only vector, so
>>> would not be able to modify the underlying vector.
>> I think that you were right to stress the difference between immutable and
>> read-only.
>> If I'm not mistaken, in JDK parlance they call the latter "unmodifiable"
>> (cf. the methods "unmodifiableCollection" and siblings in the standard class
>> "java.util.Collections").
>>
>> The idea which you referred to at the beginning of this thread is exactly
>> what they do: The wrapping class throws "UnsupportedOperationException" from
>> any "mutating" method.
>>
>> What Luc said is that when you pass an (already) immutable object, you do not
>> have to make a copy; a reference is as safe.
>>
>> I'm not sure whether that would still be true with an unmodifiable
>> reference. I.e. couldn't it be cast to its underlying modifiable reference?
>> However that would be on-purpose nasty code, not a mistake on the part of
>> the checker code.
>>
>> So, a utility method like
>>   public static RealVector unmodifiableRealVector(RealVector v)
>> in class "AbstractRealVector", would fit your need, IMO.
>
> +1 - looks to me like what is needed is an unmodifiable view,
> exactly like what the UnmodifiableCollections provide.   What is
> returned in the methods analogous to the above in
> Collections.unModifiableXxx are instances of private static inner
> classes that decorate the actual parameter and delegate, throwing
> UnsupportedOperationExceptions for mutators.  See either
> [collections] or the Harmony code [1] for examples.
>
> Phil
>
> [1] http://s.apache.org/XJ4
>>
>>
>> Best,
>> Gilles
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] How to deal with long running test? Maven Profile?

[Stefan Bodewig]

On 2011-08-11, Mark Struberg wrote:

> usually the maven-surefire-plugin will only pickup classes with the pattern 
> *Test.java.
> You can rename the longrunning Tests to *IT.java and configure the
> surefireplugin to additionally pickup those test classes only in the
> run-its profile.

>
>  
>**/*Test.java
>**/*IT.java
>  

Ah yes, thank you, I knew there must be a simple way.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Read-only RealVector

[Phil Steitz]

On 8/11/11 8:41 PM, Sébastien Brisard wrote:
> Hi,
> it's clear I think that there is no really fool-proof solution, but
> that's OK I think. The idea would be to avoid accidental modifications
> which could be catastrophic. But nothing could prevent an evil
> programmer to do its evil job. I like what was earlier pointed out:
> Javadoc should be very detailed on these issues.
> About having a really immutable vector, it's of course a desirable
> feature, but thinking about it, it would be nice to be able to combine
> both immutable vectors and mutable vectors. Question is: should the
> result be mutable or immutable ? Example
> immutale.add(mutable), and the converse mutable.add(immutable). Should
> the results be mutable? immutable?
> Following the approach in UmmodifiableCollections is probably what
> I'll do, except if you like the following (VERY simple) approach
> better. Instead of having a method
> RealVector getSolution()
> how about specifying
> RealVector getSolution(boolean deep)
> if deep is true, it returns a deep copy, if not it MIGHT (but the
> contract of the method does not make it compulsory) return a shallow
> copy. The Javadoc should clearly state that if deep is true, then the
> user should not modify the returned vector.
> Looking forward to hearing what you think,

I see Gilles' suggestion to add
public static RealVector unmodifiableRealVector(RealVector v) to
AbstractRealVector as a valuable addition, independent of this use
case, and similarly for matrices, implemented using the decorator
pattern the way that Harmony, [collections] and I assume the JDK
does it. So I would vote for that approach and to in general have
getSolution() methods return either copies or unmodifiable views of
results. In this case, I would keep it simple and just have
getSolution return an unmodifiable view (documented in javadoc, of
course).  Note that AbstractRealVector has a copy method and as long
as (the private inner class) UnmodifiableRealVector delegates that
method through, users will be able to create modifiable copies
themselves if they need to.

Phil
> Sebastien
>
>
> 2011/8/11 Phil Steitz :
>> On 8/11/11 4:22 AM, Gilles Sadowski wrote:
>>> Hello Sébastien.
>>>
> Well, in fact I would very much like to have immutable vectors too.
> Immutability is really a way to simplify implementations. Surprisingly it
> sometimes also decrease time and memory consumption, because defensive
> copies littering user code can be avoided.
>
 Luc, I have a silly question. Why do you think immutable vectors would
 prevent defensive copy ? Creating an immutable vector from an existing
 mutable vector would require a defensive copy, wouldn't it?
 Thats the reason why I'm talking about read-only vectors, and not
 immutable vectors.
 The solver would keep a reference to the underlying (mutable) vector,
 so would be able to modify (indirectly) the read-only vector.
 The observer would only have a reference to the read-only vector, so
 would not be able to modify the underlying vector.
>>> I think that you were right to stress the difference between immutable and
>>> read-only.
>>> If I'm not mistaken, in JDK parlance they call the latter "unmodifiable"
>>> (cf. the methods "unmodifiableCollection" and siblings in the standard class
>>> "java.util.Collections").
>>>
>>> The idea which you referred to at the beginning of this thread is exactly
>>> what they do: The wrapping class throws "UnsupportedOperationException" from
>>> any "mutating" method.
>>>
>>> What Luc said is that when you pass an (already) immutable object, you do 
>>> not
>>> have to make a copy; a reference is as safe.
>>>
>>> I'm not sure whether that would still be true with an unmodifiable
>>> reference. I.e. couldn't it be cast to its underlying modifiable reference?
>>> However that would be on-purpose nasty code, not a mistake on the part of
>>> the checker code.
>>>
>>> So, a utility method like
>>>   public static RealVector unmodifiableRealVector(RealVector v)
>>> in class "AbstractRealVector", would fit your need, IMO.
>> +1 - looks to me like what is needed is an unmodifiable view,
>> exactly like what the UnmodifiableCollections provide.   What is
>> returned in the methods analogous to the above in
>> Collections.unModifiableXxx are instances of private static inner
>> classes that decorate the actual parameter and delegate, throwing
>> UnsupportedOperationExceptions for mutators.  See either
>> [collections] or the Harmony code [1] for examples.
>>
>> Phil
>>
>> [1] http://s.apache.org/XJ4
>>>
>>> Best,
>>> Gilles
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional comm

Re: [math] Read-only RealVector

[Sébastien Brisard]

I'm sorry. Coming up to work, I've realized that my previous
suggestion was silly.
>
> Instead of having a method
> RealVector getSolution()
> how about specifying
> RealVector getSolution(boolean deep)
> if deep is true, it returns a deep copy, if not it MIGHT (but the
> contract of the method does not make it compulsory) return a shallow
> copy. The Javadoc should clearly state that if deep is true, then the
> user should not modify the returned vector.
>

I'd like to withdraw it and not waste your time with that. Sorry again.
I can submit some code regarding unmodifiableRealVector(RealVector v)
very soon, I hope.
Best regards for now,
Sebastien

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Numerical derivatives in Commons Math

[Sébastien Brisard]

As Patrick suggested, this approach should really be extended to
multivariate functions. To cite but one example, I recently attended a
conf where Pr. Prevost (Princeton) talked about non-linear finite
elements calcs. The long standing approach had always been to
implement the analytical expressions tangent stiffness (which is
nothing but a jacobian matrix). He argued strongly against it for at
least two reasons
  - it is error-prone,
  - most of the time, the expressions are so complex that their
evaluation is just as time-consuming as a numerical derivative.
So, having some robust algorithms for multidimensional functions
already implemented in CM would in my view be invaluable.
Sébastien

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[jcs] groupId

[Stefan Bodewig]

Hi,

while looking through the Gump setup for JCS I realized the artifactId
inside the POM had been changed to commons-jcs while the groupId still
is org.apache.jcs.  Does it make sense to keep the old groupId when
you change the artifactId anyway?

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org