On Fri, 19 Jul 2013 01:10:23 +0100, sebb wrote:
Unfortunately the change to package_info.java has uncovered a bug in
the incremental compiler:
https://jira.codehaus.org/browse/MCOMPILER-205
This slows up retesting.
Two possible workrounds:
- exclude the package_info.java files from compilati
Unfortunately the change to package_info.java has uncovered a bug in
the incremental compiler:
https://jira.codehaus.org/browse/MCOMPILER-205
This slows up retesting.
Two possible workrounds:
- exclude the package_info.java files from compilation
- add something to the files so that the compil
On 7/18/13 4:34 PM, sebb wrote:
> On 19 July 2013 00:08, Phil Steitz wrote:
>> I should have done this in MATH-1006. Any objections to my just
>> adding a element to site.xml to bring in the MathJax js so we
>> can use LaTeX expressions in the User Guide (and elsewhere if we
>> like) in the site
On 19 July 2013 00:08, Phil Steitz wrote:
> I should have done this in MATH-1006. Any objections to my just
> adding a element to site.xml to bring in the MathJax js so we
> can use LaTeX expressions in the User Guide (and elsewhere if we
> like) in the site? I have tested this and it seems to
I should have done this in MATH-1006. Any objections to my just
adding a element to site.xml to bring in the MathJax js so we
can use LaTeX expressions in the User Guide (and elsewhere if we
like) in the site? I have tested this and it seems to work. I will
update the programmer's guide to add
[...]
[1] So that the usefulness of getting results of all tests with the
same
basename is retained when refactoring.
Bad premise; the tests don't have to be renamed.
So it does not matter if the default is true or false.
I didn't get what the trade-off is. If there is none, then ever
On 07/18/2013 10:48 PM, Ajo Fod wrote:
> Hello folks,
>
> There is a lot of work in API design. However, Konstantin's point is that
> it takes a lot of effort to convince Gilles of any alternatives. API design
> issues should really be second to functionality. This idea seems to be lost
> in conve
On 18 July 2013 22:15, Gilles wrote:
> On Thu, 18 Jul 2013 20:35:53 +0100, sebb wrote:
>>
>> On 18 July 2013 20:06, Gilles wrote:
>>>
>>> On Thu, 18 Jul 2013 16:19:10 +0100, sebb wrote:
Some MATH unit tests take a long time to run.
One example is CMAESOptimizerTest, which
On 7/18/13 2:15 PM, Gilles wrote:
> On Thu, 18 Jul 2013 20:35:53 +0100, sebb wrote:
>> On 18 July 2013 20:06, Gilles wrote:
>>> On Thu, 18 Jul 2013 16:19:10 +0100, sebb wrote:
Some MATH unit tests take a long time to run.
One example is CMAESOptimizerTest, which is run twice -
On 07/18/2013 09:29 PM, sebb wrote:
> On 18 July 2013 19:54, Gilles wrote:
>> Hi.
>>
>>
>> On Thu, 18 Jul 2013 19:02:34 +0100, sebb wrote:
>>>
>>> On 18 July 2013 17:56, Mark Thomas wrote:
sebb wrote:
> The MATH code base currently generates hundreds of boxing warnings.
>
On 7/18/13 1:48 PM, Ajo Fod wrote:
> Hello folks,
>
> There is a lot of work in API design. However, Konstantin's point is that
> it takes a lot of effort to convince Gilles of any alternatives. API design
> issues should really be second to functionality. This idea seems to be lost
> in conversati
On Thu, 18 Jul 2013 20:35:53 +0100, sebb wrote:
On 18 July 2013 20:06, Gilles wrote:
On Thu, 18 Jul 2013 16:19:10 +0100, sebb wrote:
Some MATH unit tests take a long time to run.
One example is CMAESOptimizerTest, which is run twice - once for
the
deprecated code and once for the new code.
[...]
Maybe I'm missing something but: Isn't auto-boxing supposed to
be a feature?
Yes, of course, but the feature is not without its drawbacks as I
already mentioned.
- conversion overhead
- unexpected NPE when unboxing
- ambiguous remove() behaviour
For example:
x=1
list.remove(x);
Does that
Hello folks,
There is a lot of work in API design. However, Konstantin's point is that
it takes a lot of effort to convince Gilles of any alternatives. API design
issues should really be second to functionality. This idea seems to be lost
in conversations.
I agree with Gilles that providing tests
On 18 July 2013 20:42, Phil Steitz wrote:
> On 7/18/13 12:29 PM, sebb wrote:
>> On 18 July 2013 19:54, Gilles wrote:
>>> Hi.
>>>
>>>
>>> On Thu, 18 Jul 2013 19:02:34 +0100, sebb wrote:
On 18 July 2013 17:56, Mark Thomas wrote:
> sebb wrote:
>
>> The MATH code base currently gen
On 7/18/13 12:29 PM, sebb wrote:
> On 18 July 2013 19:54, Gilles wrote:
>> Hi.
>>
>>
>> On Thu, 18 Jul 2013 19:02:34 +0100, sebb wrote:
>>> On 18 July 2013 17:56, Mark Thomas wrote:
sebb wrote:
> The MATH code base currently generates hundreds of boxing warnings.
> Many, if not
On 18 July 2013 20:06, Gilles wrote:
> On Thu, 18 Jul 2013 16:19:10 +0100, sebb wrote:
>>
>> Some MATH unit tests take a long time to run.
>>
>> One example is CMAESOptimizerTest, which is run twice - once for the
>> deprecated code and once for the new code.
>>
>> Would it make sense to exclude t
On 18 July 2013 19:54, Gilles wrote:
> Hi.
>
>
> On Thu, 18 Jul 2013 19:02:34 +0100, sebb wrote:
>>
>> On 18 July 2013 17:56, Mark Thomas wrote:
>>>
>>> sebb wrote:
>>>
The MATH code base currently generates hundreds of boxing warnings.
Many, if not most, are perfectly OK.
For exa
On Thu, 18 Jul 2013 16:19:10 +0100, sebb wrote:
Some MATH unit tests take a long time to run.
One example is CMAESOptimizerTest, which is run twice - once for the
deprecated code and once for the new code.
Would it make sense to exclude the long-running tests of deprecated
classes by default?
Hi.
On Thu, 18 Jul 2013 19:02:34 +0100, sebb wrote:
On 18 July 2013 17:56, Mark Thomas wrote:
sebb wrote:
The MATH code base currently generates hundreds of boxing warnings.
Many, if not most, are perfectly OK.
For example, conversion of int and long to Number when throwing
various Exceptio
On 18 July 2013 17:56, Mark Thomas wrote:
> sebb wrote:
>
>>The MATH code base currently generates hundreds of boxing warnings.
>>Many, if not most, are perfectly OK.
>>For example, conversion of int and long to Number when throwing
>>various Exceptions.
>>
>>However, buried amongst the valid use
VFS 2.0 has been released for a long time, it is version 2.1 that is
pending release (but no release date is known ATM).
If you are coding to the VFS 1 API, you will need to change imports to use
VFS 2.
Gary
On Thu, Jul 18, 2013 at 11:55 AM, Ryan McKinley wrote:
> I am building an indexing ap
As an outsider listening to these discussions, it seems like:
a) *IF* there are problems with the current arrangement of packages, APIs, or
whatever, then a constructive approach would be for the one who sees such
problems to take the time to not just criticize and point out "flaws", but to
dig
sebb wrote:
>The MATH code base currently generates hundreds of boxing warnings.
>Many, if not most, are perfectly OK.
>For example, conversion of int and long to Number when throwing
>various Exceptions.
>
>However, buried amongst the valid uses there may well be some code
>that is buggy - e.g.
The MATH code base currently generates hundreds of boxing warnings.
Many, if not most, are perfectly OK.
For example, conversion of int and long to Number when throwing
various Exceptions.
However, buried amongst the valid uses there may well be some code
that is buggy - e.g. it uses Long when it
On Thu, 18 Jul 2013 11:47:03 -0400, Konstantin Berlin wrote:
I appreciate the comment. I would like to help, but currently my
schedule is full. Maybe towards the end of the year.
I think the first approach should be do no harm. The optimization
package keeps getting refactored every few months w
My vote was not directed toward the technical merits of the optimization
package. I am not an expert on optimization and I trust you in this regard.
My vote was a comment on the usability of the API. I find it to be
increasing difficult to use.
Maybe I have missed some refactoring, but why all
I am building an indexing application that scans a file system using VFS2
and indexes with lucene.
After running for a long while, it eats up all the memory and often hits
OOME -- when I look at the heap dump, 75% of all memory usage is from
SoftRefFilesCache. I plan to switch to LRUFilesCache, b
I appreciate the comment. I would like to help, but currently my schedule is
full. Maybe towards the end of the year.
I think the first approach should be do no harm. The optimization package keeps
getting refactored every few months without much thinking involved. We had the
discuss previously
Some MATH unit tests take a long time to run.
One example is CMAESOptimizerTest, which is run twice - once for the
deprecated code and once for the new code.
Would it make sense to exclude the long-running tests of deprecated
classes by default?
Or maybe all the tests of deprecated classes shoul
On 18 July 2013 02:07, Phil Steitz wrote:
> On 7/17/13 5:48 PM, sebb wrote:
>> On 18 July 2013 00:52, Phil Steitz wrote:
>>> On 7/17/13 4:08 PM, sebb wrote:
On 17 July 2013 23:42, wrote:
> Author: psteitz
> Date: Wed Jul 17 22:42:07 2013
> New Revision: 1504314
>
> URL:
You have done a pretty good job in making the optimization package
non-sensical to user.
+1
Check your facts ("svn log", JIRA, this ML), please: All modifications
were done in plain sight, and responded to identified problems which
I cared to solve.
I do not deny that it could have raised iss
On 7/18/13 7:12 AM, Patrick Meyer wrote:
>> You have done a pretty good job in making the optimization package
> non-sensical to user.
>
> +1
We have definitely struggled with the design of the optimization
package. It would be great if we could get to a stable API for 4.0
onwards. If you guys a
>You have done a pretty good job in making the optimization package
non-sensical to user.
+1
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi,
Bringing up points with you never leads anywhere since you refuse accept that
your proposal might have issues, and as a last result you always bring out the
"Examples Benchmarks" red herring, since it has nothing to do with the logical
problems of your proposal. Since you work on commons pr
On Thu, 18 Jul 2013 09:16:46 -0400, Konstantin Berlin wrote:
Hi,
I have two points on this
1) See issue MATH-1009
This is not directly related to my question (about cleanup of
_existing_ code); it should thus be discussed in another thread.
2) If LM was always better there would be no Guass
Hi,
I have two points on this
1) See issue MATH-1009
2) If LM was always better there would be no GuassNewton. Clearly this is not
the case.
LM is a mixture between GN and steepest descent, so it is only faster for
"tougher" functions. In case of strictly convex function GN should be a good
am
37 matches
Mail list logo
