Hi,
as agreed in this ticket, references to double[] solve(double[]) have
been wiped out from all decomposition solvers.
The same thing should probably be done with solve(double[][]), but
Gilles suggested we should probably wait and see what is going to
happen to the RealMatrix interface (creating
OK, I'm happy to do it.
Sébastien
2011/9/5 Gilles Sadowski :
> Hi Sébastien.
>
>> Gilles,
>> if you're going to do that soon, I'll stop removing methods
>> solve(double[]) from DecompositionSolvers (I've only done Cholesky so
>> far), so that our modifications do not conflict.
>
> If you want, you
On Sep 5, 2011, at 7:41 PM, sebb wrote:
> On 5 September 2011 15:55, Ralph Goers wrote:
>> If you are making changes that affect the site I'd appreciate you also
>> testing vfs as it is a multi-module build.
>
> What command do you use for checking the site?
>
mvn site:stage-deploy -Dstaging
I think tying to sun classes is a bad idea.
Den 6. sep. 2011 05:54 skrev "sebb" følgende:
> On 6 September 2011 04:33, Henri Yandell wrote:
>> On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
>>> On 3 September 2011 05:37, Henri Yandell wrote:
I'm less concerned with the 115 errors, unless they
On 6 September 2011 04:33, Henri Yandell wrote:
> On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
>> On 3 September 2011 05:37, Henri Yandell wrote:
>>> I'm less concerned with the 115 errors, unless they're all as grievous
>>> as the StringUtils one - ie) the method causing trouble is not the
>>> o
On 6 September 2011 04:26, Gary Gregory wrote:
> Can the clirr version be inherited from the parent pom?
Tried that just now.
Has to be defined in reporting section.
That works fine, except it does not appear to be possible to suppress
the report in the component pom - skip does not seem to wor
On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
> On 3 September 2011 05:37, Henri Yandell wrote:
>> I'm less concerned with the 115 errors, unless they're all as grievous
>> as the StringUtils one - ie) the method causing trouble is not the
>> only one broken.
>>
>> If the error happened when callin
Can the clirr version be inherited from the parent pom?
Could we set up the parent such that a component just specifies which version
to compare against? In a property for example.
Gary
On Sep 5, 2011, at 23:23, "s...@apache.org" wrote:
> Author: sebb
> Date: Tue Sep 6 03:22:59 2011
> New R
I am going to play with surefire executions and see how that goes.
Gary
On Sep 3, 2011, at 19:37, Mark Struberg wrote:
> Create a test.jar as attached artifact. Then create a sub module where you
> dependency:unpack this test-jar and run the tests in your new configuration.
> This can also be
On 5 September 2011 15:55, Ralph Goers wrote:
> If you are making changes that affect the site I'd appreciate you also
> testing vfs as it is a multi-module build.
What command do you use for checking the site?
> Ralph
>
> On Sep 5, 2011, at 6:52 AM, sebb wrote:
>
>> On 5 September 2011 10:42,
On 5 September 2011 21:20, sebb wrote:
> On 5 September 2011 19:19, Oliver Heger wrote:
>> Am 05.09.2011 15:52, schrieb sebb:
>>>
>>> On 5 September 2011 10:42, Oliver Heger
>>> wrote:
Am 05.09.2011 02:03, schrieb sebb:
>
> On 4 September 2011 20:07, Oliver Heger
> wrote:
On Mon, Aug 29, 2011 at 9:31 PM, Matt Benson wrote:
> On Mon, Aug 29, 2011 at 2:53 PM, Simone Tripodi
> wrote:
>> Hi all guys,
>> I just fixed the clirr report generation and deployed the chain2 site
>> on my personal ASF space[1], in order we can discuss the patch that
>> Elijah kindly provided.
I did mean to do this several months ago :( - but there were 2/3
Tailer bugs that I meant to have a look at. Anyway, on the basis of
"release (more-)often" then go for it - can always do a bug fix for
Tailer later.
Niall
On Wed, Aug 31, 2011 at 3:31 AM, Gary Gregory wrote:
> Hi All:
>
> I'd like
On Mon, Sep 5, 2011 at 12:21 PM, James Carman
wrote:
> I agree with Paul here. Extending Map (or any other class for that
> matter) when what you really want to do is encapsulate it is silly.
> Is the Context really meant to be used in any place where a Map can be
> used? I would think not.
I a
On Mon, Sep 05, 2011 at 02:35:42PM -0700, Phil Steitz wrote:
> On 9/5/11 2:23 PM, Gilles Sadowski wrote:
> > On Mon, Sep 05, 2011 at 08:12:53PM +0200, Luc Maisonobe wrote:
> >> Le 05/09/2011 15:23, Gilles Sadowski a écrit :
> >>> Hello.
> >> Hi Gilles,
> >>
> >>> There might be a typo in the value
On 9/5/11 2:23 PM, Gilles Sadowski wrote:
> On Mon, Sep 05, 2011 at 08:12:53PM +0200, Luc Maisonobe wrote:
>> Le 05/09/2011 15:23, Gilles Sadowski a écrit :
>>> Hello.
>> Hi Gilles,
>>
>>> There might be a typo in the value for the default singularity threshold
>>> value in class "LUDecompositionIm
On Mon, Sep 05, 2011 at 08:12:53PM +0200, Luc Maisonobe wrote:
> Le 05/09/2011 15:23, Gilles Sadowski a écrit :
> >Hello.
>
> Hi Gilles,
>
> >
> >There might be a typo in the value for the default singularity threshold
> >value in class "LUDecompositionImpl" (at line 37): Was
> > 10E-12
> >the i
> What do you think ?
Sounds good Luc!
Best regards,
Dennis
Van: Luc Maisonobe [luc.maison...@free.fr]
Verzonden: maandag 5 september 2011 21:47
Aan: Commons Developers List
Onderwerp: [math] removing MathUserException
Hello,
Cleaning out the ode packag
> [...]
>
> What do you think ?
+1
[Of course.]
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
I have a couple of proposals for this class:
0) Merge the interface and impl. This is consistent with what we
are doing in some other places where we have only one implementation.
1) Extend this class to actually provide a distribution - i.e.
implement the Distribution interface.
2) make the ke
On 5 September 2011 19:33, Gary Gregory wrote:
> On Mon, Sep 5, 2011 at 2:05 PM, sebb wrote:
>
>> On 5 September 2011 18:27, Gary Gregory wrote:
>> > Or maybe we should push this one out and then update everything in
>> trunk...
>> >
>> > So +1 from me with a note that src/site/xdoc/style/projec
On 9/5/11 12:47 PM, Luc Maisonobe wrote:
> Hello,
>
> Cleaning out the ode package, I have seen that we throw ourselves
> a MathUserException when the max number of allowed evaluations was
> exceeded. I have fixed that in my local copy (not committed yet)
> and used the opportunity to replace the a
On 5 September 2011 19:19, Oliver Heger wrote:
> Am 05.09.2011 15:52, schrieb sebb:
>>
>> On 5 September 2011 10:42, Oliver Heger
>> wrote:
>>>
>>> Am 05.09.2011 02:03, schrieb sebb:
On 4 September 2011 20:07, Oliver Heger
wrote:
>
> Am 02.09.2011 17:08, schrieb sebb AT AS
+1
Sigs, hashes, release contents are good.
Tested build on Apple 1.6.0_26, BlackDown 1.4.2, Sun 1.4.2_19 , Sun
1.5.0_22, Sun 1.6.0_17, rockit 1.4.2, Jrockit 1.5.0, Jrockit 1.6.0
using Ant for the 1.4 jdks and Ubuntu for all but the first test.
Nice work!
Phil
On 9/4/11 12:40 PM, Oliver Heger
Hello,
Cleaning out the ode package, I have seen that we throw ourselves a
MathUserException when the max number of allowed evaluations was
exceeded. I have fixed that in my local copy (not committed yet) and
used the opportunity to replace the ad hoc code by the new Incrementor
class, which
Hi Oliver,
sorry for question, I didn't pay enough attention on JVM compliance
level, sorry :(
+1 for the release:
* build worked
* gpg signatures are ok
* checksums are ok
* documentation site looks good
thanks for the hard work on configuration!
Simo
http://people.apache.org/~simonetripod
Hi Sébastien.
> Gilles,
> if you're going to do that soon, I'll stop removing methods
> solve(double[]) from DecompositionSolvers (I've only done Cholesky so
> far), so that our modifications do not conflict.
If you want, you can do it.
[A JIRA issue has yet to be opened, which you can do too.]
On Mon, Sep 5, 2011 at 2:05 PM, sebb wrote:
> On 5 September 2011 18:27, Gary Gregory wrote:
> > Or maybe we should push this one out and then update everything in
> trunk...
> >
> > So +1 from me with a note that src/site/xdoc/style/project.css should
> have a
> > license header for completness
Am 05.09.2011 15:52, schrieb sebb:
On 5 September 2011 10:42, Oliver Heger wrote:
Am 05.09.2011 02:03, schrieb sebb:
On 4 September 2011 20:07, Oliver Heger
wrote:
Am 02.09.2011 17:08, schrieb sebb AT ASF:
I've updated to the latest versions of all the plugins.
Some of these changes ma
Le 05/09/2011 15:23, Gilles Sadowski a écrit :
Hello.
Hi Gilles,
There might be a typo in the value for the default singularity threshold
value in class "LUDecompositionImpl" (at line 37): Was
10E-12
the intended value, or was it
1e-12
?
It is probably a typo, but the exact value was c
On 5 September 2011 18:27, Gary Gregory wrote:
> Or maybe we should push this one out and then update everything in trunk...
>
> So +1 from me with a note that src/site/xdoc/style/project.css should have a
> license header for completness' sake for the next go around (it's a one
> liner file I kno
Hi Simone,
IIUC Digester 2.x requires JDK 1.5 while this version of Configuration
still targets 1.4. My plan is that the next version will go for 1.5,
then we will of course update the dependencies.
Please see also my response to Gary's mail.
Oliver
Am 04.09.2011 21:52, schrieb Simone Tripo
Hi Gary,
Am 05.09.2011 19:27, schrieb Gary Gregory:
Or maybe we should push this one out and then update everything in trunk...
this was indeed my plan. The last version came out in December 2008, so
a release is overdue.
I hope to be able to work on a version 1.8 afterwards which targets J
Or maybe we should push this one out and then update everything in trunk...
So +1 from me with a note that src/site/xdoc/style/project.css should have a
license header for completness' sake for the next go around (it's a one
liner file I know ;)
Gary
On Sun, Sep 4, 2011 at 4:33 PM, Gary Gregory
Hi Paul,
agreed. I just started indeed a thread vote to accept the new codebase
as /trunk, so we can continue working toward a new releas wich
involves redesigns as well.
I would really appreciate if you and James partecipate in the vote and
could continue co-operate until next release!!!
Have a n
Hi Jochen!
we still haven't because, as emerged in the past discussions, actual
modifications can still be considered acceptable in therms of
retro-compatibility.
Anyway, we are also in the middle of discussions about API redesign,
and breaking the 1.X compatibility, so we will update those metadat
Hi Dennis,
- Mail original -
> Hi Luc,
>
> The FirstOrderDifferentialEquations interface has a method
> computeDerivatives, which also still throws the MathUserException.
> Did you
> forget that one as well, or did you intentionally leave it in?
I forgot it. MathUserException should com
Major versions don't need to keep compatibility. Even if it is
laudable goal to try, I rather have a better designed software and do
30 minutes of upgrading code than keep dragging along old decisions.
On Mon, Sep 5, 2011 at 10:49 AM, Raman Gupta wrote:
> On 09/05/2011 08:51 AM, Simone Tripodi wr
On 09/05/2011 08:51 AM, Simone Tripodi wrote:
> I totally agree with you James, what is needed is just to understand
> if break the 1.X compatibility or not...
> I think that the discussion worths a vote call at that point, WDYT?
> Many thanks in advance, have a nice day!
> Simo
>
> http://people.
On 9/5/11 7:21 AM, Gilles Sadowski wrote:
> On Mon, Sep 05, 2011 at 02:15:30PM +0200, Arne Ploese wrote:
>> To make things clear here some octave (matlab as well) calculation with
>> complex:
>>
>> octave:1> a = Inf + sqrt(-Inf)
>> a = Inf + Infi
>> octave:2> a * a
>> ans = NaN + Infi
>> octave:3>
On 5 September 2011 16:33, Jochen Wiedmann wrote:
> Housework check:
>
> - Has the package name been changed?
> A- Has thae Maven groupId aand/or artifactId been changed?
I'd strongly recommend leaving these changes until just before release
- it's much easier to run Clirr if the package name ha
Housework check:
- Has the package name been changed?
A- Has thae Maven groupId aand/or artifactId been changed?
DAOes t wrote:
> Hi all guys,
> thanks to a user, Elijah Zupancic, that recently submitted CHAIN-53, a
> group of Commons committers started working on that component in a
> branch 2.
my +1
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Sep 5, 2011 at 5:13 PM, Simone Tripodi wrote:
> Hi all guys,
> thanks to a user, Elijah Zupancic, that recently submitted CHAIN-53, a
> group of Commons committers started working on that component in a
> branch
Hi all guys,
thanks to a user, Elijah Zupancic, that recently submitted CHAIN-53, a
group of Commons committers started working on that component in a
branch 2.0[1] to experiment updates and study improvements in order to
push a next release soon.
We are in the middle of discussing about the curren
Gilles,
if you're going to do that soon, I'll stop removing methods
solve(double[]) from DecompositionSolvers (I've only done Cholesky so
far), so that our modifications do not conflict.
Sébastien
2011/9/5 Phil Steitz :
> On 9/5/11 3:43 AM, Gilles Sadowski wrote:
>> Hi.
>>
>> The "...Decompositio
On 9/5/11 3:43 AM, Gilles Sadowski wrote:
> Hi.
>
> The "...Decomposition" interfaces in package "linear" have a unique
> implementation. Should the "...Impl" classes be renamed (removing the
> interfaces)?
+1
Phil
>
>
> Regards,
> Gilles
>
> --
If you are making changes that affect the site I'd appreciate you also testing
vfs as it is a multi-module build.
Ralph
On Sep 5, 2011, at 6:52 AM, sebb wrote:
> On 5 September 2011 10:42, Oliver Heger wrote:
>> Am 05.09.2011 02:03, schrieb sebb:
>>>
>>> On 4 September 2011 20:07, Oliver Hege
On Mon, Sep 05, 2011 at 02:15:30PM +0200, Arne Ploese wrote:
> To make things clear here some octave (matlab as well) calculation with
> complex:
>
> octave:1> a = Inf + sqrt(-Inf)
> a = Inf + Infi
> octave:2> a * a
> ans = NaN + Infi
> octave:3> a = Inf + sqrt(-1)
> a = Inf + 1i
> octave:4> a *
On 5 September 2011 10:42, Oliver Heger wrote:
> Am 05.09.2011 02:03, schrieb sebb:
>>
>> On 4 September 2011 20:07, Oliver Heger
>> wrote:
>>>
>>> Am 02.09.2011 17:08, schrieb sebb AT ASF:
I've updated to the latest versions of all the plugins.
Some of these changes may well
Hello.
There might be a typo in the value for the default singularity threshold
value in class "LUDecompositionImpl" (at line 37): Was
10E-12
the intended value, or was it
1e-12
?
Gilles
-
To unsubscribe, e-mail: dev-unsubscr
Well, if you're going to a 2.x, then I say break it and do it the
right way. Consider that my +1.
On Mon, Sep 5, 2011 at 8:51 AM, Simone Tripodi wrote:
> I totally agree with you James, what is needed is just to understand
> if break the 1.X compatibility or not...
> I think that the discussion
Hi Luc,
The FirstOrderDifferentialEquations interface has a method
computeDerivatives, which also still throws the MathUserException. Did you
forget that one as well, or did you intentionally leave it in?
Best regards,
Dennis
luc.maison...@free.fr wrote:
Hi Dennis,
- Mail original ---
I totally agree with you James, what is needed is just to understand
if break the 1.X compatibility or not...
I think that the discussion worths a vote call at that point, WDYT?
Many thanks in advance, have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon,
To make things clear here some octave (matlab as well) calculation with
complex:
octave:1> a = Inf + sqrt(-Inf)
a = Inf + Infi
octave:2> a * a
ans = NaN + Infi
octave:3> a = Inf + sqrt(-1)
a = Inf + 1i
octave:4> a * a
ans = Inf + Infi
octave:5> a = 1 + sqrt(-Inf)
a =1 + Infi
octave:6> a * a
I agree with Paul here. Extending Map (or any other class for that
matter) when what you really want to do is encapsulate it is silly.
Is the Context really meant to be used in any place where a Map can be
used? I would think not.
On Sun, Sep 4, 2011 at 11:54 PM, Paul Benedict wrote:
> I want t
On 2011-09-05, Emmanuel Bourg wrote:
> That looks interesting. Does it provide a repack mode suitable for
> signing compressed jars?
I assume you mean
,
| Note that packing and unpacking a JAR will in general alter the bytewise
| contents of classfiles in the JAR. This means that packing and
On 2011-09-04, sebb wrote:
> You must have put a lot of thought into this
Well, I was without network access for almost two weeks 8-)
> it would be useful to record these design decisions and investigations
> in the code somewhere. e.g. as package Javadoc.
The current package.html already cont
I was going to ask the same question! (I learn from you, Gilles!).
Sébastien
2011/9/5 Gilles Sadowski :
> Hi.
>
> The "...Decomposition" interfaces in package "linear" have a unique
> implementation. Should the "...Impl" classes be renamed (removing the
> interfaces)?
>
>
> Regards,
> Gilles
>
> -
Sorry answering that late, but I was busy...
So simply I try to write a lib that doing some DSP stuff. I took some
*.m files from the octave signaling package ant converted them to java
(digital filters aka. Butterworth ...) there is a litte bit calculation
needed.
So my problem is: if the com
Hi.
The "...Decomposition" interfaces in package "linear" have a unique
implementation. Should the "...Impl" classes be renamed (removing the
interfaces)?
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache
FYI: 22-SNAPSHOT works with [codec].
Gary
On Mon, Sep 5, 2011 at 5:59 AM, sebb wrote:
> On 5 September 2011 08:50, Jörg Schaible
> wrote:
> > Hi Oliver,
> >
> > Oliver Heger wrote:
> >
> >> Am 02.09.2011 17:08, schrieb sebb AT ASF:
> >>> I've updated to the latest versions of all the plugins.
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
On 5 September 2011 08:50, Jörg Schaible wrote:
> Hi Oliver,
>
> Oliver Heger wrote:
>
>> Am 02.09.2011 17:08, schrieb sebb AT ASF:
>>> I've updated to the latest versions of all the plugins.
>>>
>>> Some of these changes may well cause problems, but the best way to
>>> find this out is for variou
Am 05.09.2011 02:03, schrieb sebb:
On 4 September 2011 20:07, Oliver Heger wrote:
Am 02.09.2011 17:08, schrieb sebb AT ASF:
I've updated to the latest versions of all the plugins.
Some of these changes may well cause problems, but the best way to
find this out is for various people to try us
That looks interesting. Does it provide a repack mode suitable for
signing compressed jars?
Emmanuel Bourg
Le 04/09/2011 08:04, Stefan Bodewig a écrit :
Hi,
I've just committed Converter*Stream implementations for Pack200[1]
which is a bit unusual in several ways.
First of all it will (by d
Hi Paul,
I tend to agree with you since I don't like the Map extension too, the
only concern is just to understand how strict backward compatibility
we want to keep, or if we want almost "redesign" the public APIs.
It is an important choose we have to made in a VOTE, I suggest to
promote first the
Hi Seb,
thanks a lot for your feedbacks!!!
All Clirr errors you can see on the report - except the `retrieve`
added method in the Context interface - are strictly related to
internal data structures/class fields, that were initially made as
protected so, as checkstyle suggested, I reduced the visi
Hi Oliver,
Oliver Heger wrote:
> Am 02.09.2011 17:08, schrieb sebb AT ASF:
>> I've updated to the latest versions of all the plugins.
>>
>> Some of these changes may well cause problems, but the best way to
>> find this out is for various people to try using the POM, so I've
>> uploaded 22-SNAPSH
Hi Dennis,
- Mail original -
> Hi Luc,
>
> question: is there a reason you applied this to StepHandler, but not
> FixedStepHandler?
No, I simply forgot it. I'll fix that. Thanks for reminding me about it.
The proper way to propagate exception (discussed a while ago), is to have user
set
sebb wrote:
> On 4 September 2011 11:23, sebb wrote:
>> On 4 September 2011 10:53, Luc Maisonobe wrote:
>>> Le 04/09/2011 04:57, Phil Steitz a écrit :
Same problem under Linux for parent 21.
>>>
>>> Isn't it related to a problem that arose some weeks ago about the
>>> resource not bein
Hi Sébastien,
thanks for the quick response/commit.
Dennis
Sébastien Brisard wrote:
Thanks Dennis for that! I forgot to commit the changes made to the
DecompositionSolver interface (which explains what it compiled
locally...).
Hope it is now fixed in rev. 1165188.
Sébastien
2011/9/5 Dennis H
Thanks Dennis for that! I forgot to commit the changes made to the
DecompositionSolver interface (which explains what it compiled
locally...).
Hope it is now fixed in rev. 1165188.
Sébastien
2011/9/5 Dennis Hendriks :
> Hi all,
>
> commit 1165155 removed method "solve(double[] b)" from class Solve
72 matches
Mail list logo
