On Thu, Nov 25, 2010 at 4:29 PM, Rahul Akolkar rahul.akol...@gmail.comwrote:
On Thu, Nov 25, 2010 at 3:44 PM, Tim O'Brien tobr...@discursive.com
wrote:
On Nov 25, 2010, at 2:29 PM, Peter Lin wool...@gmail.com wrote:
even though I haven't been active in jmeter in a while, I am still a
Al Chou wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
I had planned to submit my Complex classes as part of the iniital
submission and I have been tearing this stuff apart and putting it back
together again for the past several weeks,adding layers of abstraction
and then tearing them away
--- robert burrell donkin [EMAIL PROTECTED] wrote:
On Wednesday, June 4, 2003, at 01:26 AM, Phil Steitz wrote:
robert burrell donkin wrote:
snip
the second is that we're going to need to audit our implementations
against copyrighted ones. (i'm hoping that some better qualified folks
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Robert,
Finally, To clarify, my specific reasons for nomination concern the fact
that a large amount of energy pushing this component forwards is
coming from Phil, being he initially proposed the project, isn't it
unfair to exclude him
Here is a *proposed* ordering for the task list, with a little commentary
added.
One thing that I want to make *very* clear up front, is that I *never* intended
the task list or the items listed in the scope section of the proposal to be
definitive. All that is definitive are the guiding
Brent Worden wrote:
and unit tests. While things like rootfinding for
non-differentiable functions
may eventually have a place and may benefit from algorithms that
someone can
claim copyright ownership of, if no one else does it before I get
to it, I will
translate my simple newton's method
J.Pietschmann wrote:
Brent Worden wrote:
In the chi-square patch, I created a root finding utility class. I
used the
bisection method to provide a default mechanism for computing inverse
CDFs.
It's driven by a simple Function interface. Check it out and see if it's
something you can use or
Al Chou wrote:
--- Shapira, Yoav [EMAIL PROTECTED] wrote:
Howdy,
4. Thinking of the developers who will use this stuff, I feel like we
need a way to insulate them from having to think about rootfinding
strategy choice. As Al has pointed out, we are not (at least yet ;-))
in the AI business, so
Brent Worden wrote:
J.Pietschmann [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Phil Steitz wrote:
Can you provide a math reference desribing this?
H.M.Antia: Num. Methods for Scientists and Engineers.
I have been referring
to Atkinson and I am having a hard time following
Al Chou wrote:
--- [EMAIL PROTECTED] wrote:
On Fri, 30 May 2003 20:14:23 +0200, J.Pietschmann wrote:
Brent Worden wrote:
I agree. The this looks like a very solid framework. One
suggestion I
would like to make, is instead of a both a firstDirevative and
secondDerivate method to evaluate the
It occurs to me now that we might be able to support an alternative
bean-oriented interface for rootfinding by using bean introspection.
Using BeanUtils' MethodUtils and PropertyUtils, we should be able to
support solving bean equations, roughly as as in the following example:
double breakEven
Our ant build (and hence nightly) is currently broken, since we have
added dependencies on commons-beanutils, bringing along collections and
logging. I personally have moved to maven entirely, but I thought we
had agreed early on that we would maintain the ability to build from
ant. Also,
Craig R. McClanahan wrote:
On Sun, 1 Jun 2003, Phil Steitz wrote:
Date: Sun, 01 Jun 2003 09:14:56 -0700
From: Phil Steitz [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: [math] maven magic and build.xml
Ant are not using maven and
the generated build.xml needs to get junit.
It does, but the generated build.xml grabs it as well.
-Mark
Phil Steitz wrote:
Our ant build (and hence nightly) is currently broken, since we have
added dependencies on commons-beanutils, bringing along collections
Here is a draft that I was preparing to submit as a patch to
developer.xml; but given that some of the content may be controversial,
I thought it best to post to the list first for discussion. This is
just a start. I just wanted to get something out there to build on. I
will submit as a
[EMAIL PROTECTED] wrote:
mdiggory2003/06/01 22:09:41
jakarta-commons-sandbox/math/target/test-classes - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Aren't
Tim O'Brien wrote:
Gamma.java specifically mentioned that is was based on Numerical
Recipes in C which is not available under a license compatible with the
ASL. All code currently in [math] which depends on Gamma.java has been
removed. If it can be shown that this code does not violate the
Brent Worden wrote:
Gamma.java specifically mentioned that is was based on Numerical
Recipes in C which is not available under a license compatible with the
ASL.
What is specifically mentioned was is based on the formulas and
descriptions found in NR and it clearly states in
--- robert burrell donkin [EMAIL PROTECTED] wrote:
hi tim
let me begin by saying that i think you did the right thing and handled
things pretty well. i hope that brent will appreciate that commons-math
is still just ramping up and we're probably going to have to discuss and
sort things
[EMAIL PROTECTED] wrote:
My current work on Certified values exposes a limitation in calculating
Variance in UnivariateImpl.
In the following case where this example data is used to induce roundoff
error:
public double getVariance() {
double variance = Double.NaN;
if( n == 1 ) {
[EMAIL PROTECTED] wrote:
Phil Steitz wrote:
Since xbar = sum/n, the change has no impact on the which sums are
computed or squared. Instead of (sum/n)*(sum/n)*n your change just
computes sum**2/n. The difference is that you are a) eliminating one
division by n and one multiplication by n
Phil Steitz wrote:
[EMAIL PROTECTED] wrote:
Phil Steitz wrote:
Since xbar = sum/n, the change has no impact on the which sums are
computed or squared. Instead of (sum/n)*(sum/n)*n your change just
computes sum**2/n. The difference is that you are a) eliminating one
division by n and one
Al Chou wrote:
--- [EMAIL PROTECTED] wrote:
Phil Steitz wrote:
Phil Steitz wrote:
[EMAIL PROTECTED] wrote:
Phil Steitz wrote:
Since xbar = sum/n, the change has no impact on the which sums are
computed or squared. Instead of (sum/n)*(sum/n)*n your change just
computes sum**2/n
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Phil Steitz wrote:
Al Chou wrote:
Uh, did we drop the idea of using the corrected two-pass algorithm
for the
variance in the non-rolling case? I excerpted that thread below.
I was going to mention that. The discussion above
robert burrell donkin wrote:
On Tuesday, June 3, 2003, at 12:41 AM, Phil Steitz wrote:
--- robert burrell donkin [EMAIL PROTECTED] wrote:
snip
it seems to me that brent is assuring us that he went back to the
mathematical basis of the algorithm and started from that. a clean
implementation
--- Al Chou [EMAIL PROTECTED] wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
Al Chou wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
Al Chou wrote:
Uh, did we drop the idea of using the corrected two-pass algorithm for
the
variance in the non-rolling case? I excerpted
--- Al Chou [EMAIL PROTECTED] wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Al Chou wrote:
OK, I hope the article we want is available online, given that it's
pretty
old.
Strangely, it's actually the recent stuff that is not available. JSTOR
has
American
Al Chou wrote:
[deletia]**2
* Improve numerical accuracy of Univariate and BivariateRegression
statistical
computations. Encapsulate basic double[] |- double mean, variance, min, max
computations using improved formulas and add these to MathUtils. (probably
should add float[], int[], long[]
* Improve numerical accuracy of Univariate and BivariateRegression
statistical
computations. Encapsulate basic double[] |- double mean, variance, min, max
computations using improved formulas and add these to MathUtils. (probably
should add float[], int[], long[] versions as well.) Then refactor
I think that Al Chou should be added to the list of contributors to
commons-math. Al has provided useful patches and great suggestions for
improvement and advice on implementation strategies.
Tim/Mark/Robert: if you agree, can one of you update project.xml? I was
going to submit a patch, but
Check out procedure sum.2 and var.2 in
http://www.stanford.edu/~glynn/PDF/0208.pdf
The first looks like Brent's suggestion for a corrected mean
computation, with no memory required. The additional computational cost
that I complained about is docuemented to be 3x the flops cost of the
direct
Al Chou wrote:
--- Will Stranathan [EMAIL PROTECTED] wrote:
Has there been any discussion about the possibility of adding some work to
Commons somewhere for common financial functions? I don't know if this
necessarily falls in the scope of the Math project, or if I would need to
submit a
Brent Worden wrote:
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: [math] proposed ordering for task list, scope of initial
release
Here is a *proposed* ordering for the task list, with a little commentary
Al Chou wrote:
--- Al Chou [EMAIL PROTECTED] wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
[deletia]
OK, long-winded disclaimer aside, here is how I see the task list ordered:
[deletia]
* Framework and implementation strategie(s) for finding roots or
real-valued
functions of one (real
Brent Worden wrote:
-Original Message-
* t-test statistic needs to be added and we should probably add
the capability
of actually performing t- and chi-square tests at fixed
significance levels
(.1, .05, .01, .001). -- This is virtually done, just need to
define a nice,
convenient
--- O'brien, Tim [EMAIL PROTECTED] wrote:
Sorry, I've been away for a few days, I'm back.
Will, I think this code
would be really valuable (I'd like to use it myself), we should add it
to a contrib source tree...
On Tue, 2003-06-10 at 08:24, Phil Steitz wrote:
Al Chou wrote
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Al Chou wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
Simple methods like isPositive, isNegative, etc. can be used to make
boolean expressions more human readable. I'm willing to build those two
on top of sign (I'm so generous
Mark R. Diggory wrote:
Phil Steitz wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I disagree. We need it ourselves, unless we want to duplicate code
between
UnivariateImpl and AbstractStoreUnivariate. Also, I personally and I
am sure
many other users would like simple array-based
Brent Worden wrote:
-Original Message-
From: Al Chou [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 10, 2003 2:14 PM
To: Jakarta Commons Developers List
Subject: Re: [math] proposed ordering for task list, scope of initial
release
--- Phil Steitz [EMAIL PROTECTED] wrote:
Brent Worden wrote
Brent Worden wrote:
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 10, 2003 3:04 PM
To: Jakarta Commons Developers List
Subject: Re: [math] proposed ordering for task list, scope of initial
release
Phil Steitz wrote:
My philosophy
Brent Worden wrote:
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 10, 2003 3:06 PM
To: Jakarta Commons Developers List
Subject: Re: [math] proposed ordering for task list, scope of initial
release
Al Chou wrote:
Finally, having used the Pietschmann
Mark R. Diggory wrote:
I've always been using Eclipse/Ant to build the project. In which case
JUnit is already present on the classpath for Ant (Either that or adding
it was just so damn simple I forgot I did it). I was just testing Ant
outside of Eclipse from the command line and I noticed
Al Chou wrote:
Date: Wed, 04 Jun 2003 21:05:14 -0700
From: Phil Steitz [EMAIL PROTECTED]
Subject: [math] more improvement to storage free mean, variance computation
Check out procedure sum.2 and var.2 in
http://www.stanford.edu/~glynn/PDF/0208.pdf
The first looks like Brent's suggestion
Al Chou wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
Al Chou wrote:
Date: Wed, 04 Jun 2003 21:05:14 -0700
From: Phil Steitz [EMAIL PROTECTED]
Subject: [math] more improvement to storage free mean, variance computation
Check out procedure sum.2 and var.2 in
http://www.stanford.edu/~glynn/PDF
I am dutifully cleaning up the CheckStyle warnings in my code and I am
hesitating to remove @throws IllegalArgumentException, which CheckStyle
currently complains about. I am a little ambivalent about this. There
is a property (checkstyle.javadoc.checkUnusedThrows) that we can set to
make it
Brent Worden wrote:
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 14, 2003 4:21 PM
To: Jakarta Commons Developers List
Subject: [math] @throws IllegalArgumentException
I am dutifully cleaning up the CheckStyle warnings in my code and I am
hesitating
--- Al Chou [EMAIL PROTECTED] wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
Here is an updated version. I will try to submit a patch to the
task.xml reflecting this before I leave this AM, but I am running out of
time...
* Improve numerical accuracy of Univariate
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Phil Steitz wrote:
I would be open to merging special with analysis, or making it a
subpackage.
I agree on the package structure, I'm a little hesitant to suggest
placing special and analysis together right now until its clearer what
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Al Chou wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I appear to occasionally get JUnit test failures from ValueServer and
RandomData Tests. This would appear to be because the mean sampled
values can sometimes deviate from the
--- Craig R. McClanahan [EMAIL PROTECTED] wrote:
On Sat, 14 Jun 2003, David Graham wrote:
Date: Sat, 14 Jun 2003 17:02:35 -0600
From: David Graham [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [math] @throws
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I've got a design decision to make that I'd like to get others opinion
on. Currently, the strategy in UnivariateImpl is to calculate the
rudimentary building blocks of the statistics and then calculate the
statistics in the getters (getVariance,
I would like to request that these changes be rolled back. I would like to
keep UnivariateImpl separate and lightweight, with improved updating formulas
and good array-based computations when the window in finite. I see the full
stored versions (as I thought Tim did when he defined them) as
of GNU Emacs. :-)
Thats a good thing, since I am stranded with only my work Windoz laptop that I
do not seem to have anything like root on. Until Thurs., I will not be able
to submit any patches.
Tim
On Sun, 15 Jun 2003, J.Pietschmann wrote:
Phil Steitz wrote:
I would also like
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I've roughed out the beginnings of StatUtils (based on implementations
found in AbstractStoreUnivariate). I will add this if all seem to agree
on its usage.
+1 for this approach, rolling back previous changes and having
AbstractStoreUnivariate
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Hi all,
As this is now a sensitive subject, I'm not going to commit this until I
receive +/- input from the group. Please review the following
UnivariateImpl and submit your opinion, This version of UnivariateImpl
no longer extends
We need to get test cases committed for StatUtils before adding/modififying
anything else. I am OK with what has been a added; but we need to comply with
our stated guidelines, which require test cases for all committed code.
StatUtils needs its own test cases.
--- [EMAIL PROTECTED] wrote:
.
RandomData, all of the distributions stuff) that are used by other things, but
all include direct test cases. The basic principle is very simple -- every
method needs to be tested.
Phil
-Mark
Phil Steitz wrote:
We need to get test cases committed for StatUtils before adding/modififying
More nitpicking. I don't see that multiplying top and bottom by
values.length
makes things better. In fact, it could reduce precision by inflating the
magnitude of the first term before subtracting from it and dividing it.
hmm, good points. this may be an example of where
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Thanks for entertaining my sometimes naive questioning,
J.Pietschmann wrote:
Mark R. Diggory wrote:
(1) Does it seem logical that when working with n (or
values.length) to use Math.pow(n, x), as positive integers, the risk
is actually
--- Al Chou [EMAIL PROTECTED] wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
--- Tim O'Brien [EMAIL PROTECTED] wrote:
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
We all agree that the optimized double[]|- double computations should be
reused. The problem with the above is that you
--- David Graham [EMAIL PROTECTED] wrote:
Maybe I'm unique, but
sometimes I find that Java (as well as other languages) gets in my way
rather
than letting me solve the problem at hand in a natural way.
You're not alone in that belief. I've heard several people comment about
how
I keep reminding myself, we are the developers, there is always room for
refactoring in the future. If there becomes a clear hindrance with the
use of static methods, then we can refactor them into a class that needs
to be instantiated. This is not too difficult to accomplish.
Not for us,
Mark R. Diggory wrote:
Phil,
Should we move TestStatistic/Impl up into the stat package?
-M.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I would say yes. I would also like to
Mark R. Diggory wrote:
Phil Steitz wrote:
I would not add these to Univariate. I understand your desire to keep
them implemented in UnivariateImpl, but I do not want to force
implementation of these statistics in the Univariate interface.
I also understand your interest in being able
Al Chou wrote:
I finally decided that cubic spline would be my first attempt at implementing
interpolation, partly because of the difficulty of finding an alternative
reference to NR for the Stoer Bulirsch rational function method, partly
because I started to have doubts about the desirability of
Again, I've got the refactorings in place on my checkout, I want to make
sure all developers are prepared and aware before I commit these changes.
Thanks for the heads up and thanks for doing this. I have changes in progress
to TestStatistic (adding t- and chi-square p-value
Phil Steitz wrote:
Here are the remaining open tasks. I think we are getting close to the
time when we can develop a release plan. I will submit a patch to
Bugzilla updating tasks.xml, but I wanted to post the open tasks and my
own short term plan.
* RealMatrixImpl is missing one method
Tim O'Brien wrote:
What about this possibility. we could easily have DoubleArray return a
reference to the internalStorageArray. I know this would violate
encapsulation, but if we expose the interal array, the start and end index
then there is no need to copy the contents of the array.
(2) Considerations
a.) Is consistent library design important?Can all these models
interace effectively? Are all these different design models required? Is
there a single design model that can span the entire library?
IMHO, the most important considerations are 1) how easy the library will
be
I am unable to build commons-math after the recent commits to the
analysis package. MathException and MathConfigurationException are used
by the added classes and these classes appear to be missing from CVS.
Has anyone successfully built and tested this package? Am I missing
something?
There don't seem to be any nighlies after 6/5 in
http://cvs.apache.org/builds/jakarta-commons/nightly/
Am I looking in the wrong place?
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Mark R. Diggory wrote:
Yes, sorry about that, I had missed adding those in the last patch.
Thanks. Works for me now. What do you think about SinFunction? Do we
really need that in /java? It is only used in unit tests.
Phil
Al Chou wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
Does staticness preclude extensibility? I assume final-ity would, but we
didn't declare any methods final, AFAIK.
Strictly speaking, no; but static methods do not support polymorphism
and inheritance in the way that instance methods do
I have taken a stab at an outline for the User Guide. I have started
writing the first three sections (overview, statistics and data
generation). The structure more or less follows the package structure
and the intent is to focus on how to do things rather than how the code
is organized.
J.Pietschmann wrote:
Mark R. Diggory wrote:
Further comments:
1 Now there are two root finding frameworks in place. I think this should
be unified.
I agree. My preference would be to eliminate the original
RootFinding.java and refactor the distribution inversion methods to use
the new
The changed subject line is a pun that I hope none will find insulting -
sort of a little math joke. Abstract nonsense is the term that some
mathematicians (including some who love the stuff) use to refer to
category theory, the birthplace of the functor concept. To conserve
bandwidth, I am
Brent Worden wrote:
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 11:08 PM
To: Jakarta Commons Developers List
Subject: [math] abstact nonsense was Re: [math][functor] More Design
Concerns
The changed subject line is a pun that I hope none
robert burrell donkin wrote:
i'm away from now until sunday at my sister's wedding. it's unlikely
i'll be able to get up to date in time to submit something for the
newsletter.
would someone like to volunteer to compose something about math for the
news letter?
- robert
I will volunteer for
it.
Sincerely,
-- Tetsuya ([EMAIL PROTECTED])
-
On Fri, 04 Jul 2003 00:33:04 -0700
(Subject: Re: [math] anyone want to volunteer to file an entry for the newsletter?)
Phil Steitz [EMAIL PROTECTED] wrote:
robert burrell donkin wrote
I have a couple of problems with the recent commits to stat and util.
First, the testAddElementRolling test case in FixedDoubleArrayTest will not
compile, since it is trying to access what is now a private field in
FixedDoubleArray (internalArray). The changes to FixedDoubleArray should be
rolled
I have started work extending the distribution framework to accomodate
discrete probablity distributions so that we can provide binomial,
hypergeometric and poisson probabilities and I want to get others' (esp.
Brent's) opinions on the following plan:
1. Add DiscreteDistribution and
Henri Yandell wrote:
(Repeating myself from the previous occasion)
Our t's are dotted and our i's are crossed, so we'd like to make a
release of Commons Lang 2.0.
[x] +epsilon (whatever my vote counts) I support Commons Lang 2.0
[ ] +0 Huh? Sure, let me sleep.
[ ] -0 Lang?
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
This adds
significant overhead and I do not see the value in it. The cost of the
additional stack operations/object creations is significant. I ran tests
comparing the previous version that does direct computations using the
double[]
Sorry, last reply got sent before I was done with it. Pls disregard and try
this
This adds
significant overhead and I do not see the value in it. The cost of the
additional stack operations/object creations is significant. I ran tests
comparing the previous version that does
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Well, I for one would prefer to have the simple computational methods in
one
place. I would support making the class require instantiation, however,
i.e.
making the methods non-static.
Yes, but again is a question of having big flat
Also, can we now discuss dropping author tags?
+1 for me at least -- i.e., I am OK dropping all of my @author tags.
Phil
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
Brent Worden wrote
Another reason for this is performance. The storageless Univariate
implementation is a compute all or nothing design. Because of this, every
time a new statistic is added to the interface, the extra computation needed
to compute the new statistic slows down the computation of
--- Anton Tagunov [EMAIL PROTECTED] wrote:
Hello, Phil and All the [math] Developers!
1.
PS Univariate can always be extended -- statistics can be added to the base
PS interface...
Oh, no.. I feel terribly sorry to break in, but this is
probably going to cause us users some troubles..
Henri Yandell wrote:
If people could take a look at
http://www.apache.org/~bayard/commons-lang-2.0-rc1/
and complain about whatever is not right.
The attached patch (against current HEAD) fixes some trivial typos in
STATUS.html.
Phil
Index: STATUS.html
An alternative to all of the boolean-valued isXXX, isNotXXX methods might be to
introduce an integer-valued classification method to return the rank of a
string according to the ordering
nullwhitespace only (but positive length) non-trivial.
The syntax would be less natural (maybe to the
I have been going through NumberUtils code and tests to make sure that
handling of nulls is documented (and tested) correctly. I notice that
createNumber returns null for null (need to add a javadoc comment for
this); whereas createFloat, et al will throw NPEs on null. Shouldn't
these behave the
Currently, StringUtils.indexOfAny(str, searchStrings) returns 0 if
searchStrings contains , but we return -1 if it contains null. Is
this the way we want it to work? We should add javadoc in any case.
One more thing. I really like the examples in the javadoc, but in some
cases they might be
Phil Steitz wrote:
Currently, StringUtils.indexOfAny(str, searchStrings) returns 0 if
searchStrings contains , but we return -1 if it contains null. Is
this the way we want it to work? We should add javadoc in any case.
One more thing. I really like the examples in the javadoc, but in some
Stephen Colebourne wrote:
Well I'm done.
- StringUtils and other classes are sorted with respect to null handling
(absorbing as many as possible).
- IsEmpty/IsBlank is coded and present. And highlighted in release notes.
- Javadoc code examples have been put into most StringUtils methods. There
--- Juozas Baliuka [EMAIL PROTECTED] wrote:
Forget it please.
Try to solve it at home, fix it or remove crap from production . I do not
think commons commiters want or need to support crap.
I am not a commons committer, but as a user, I would humbly suggest that server
products may need to
Currently,
StringUtils.sliceRemainder(foo, b) =
= StringUtils.sliceFirst(foo, b),
but StringUtils.sliceRemainder(foo, b) = foo.
Is this the intended behavior?
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
://issues.apache.org/bugzilla/show_bug.cgi?id=21797
that documents current behavior with examples and test cases.
Phil
- Original Message -
From: Phil Steitz [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, July 22, 2003 5:50 AM
Subject: [lang
- Original Message -
From: Phil Steitz [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, July 22, 2003 3:30 PM
Subject: Re: [lang] StringUtils.sliceFirstRemainder behavior
Stephen Colebourne wrote:
I think I would expect:
StringUtils.slice(foo, b) = foo
[EMAIL PROTECTED] wrote:
from:Phil Steitz [EMAIL PROTECTED]
I assume you also agree that all slice functions should fix , null, i.e.,
slice[Xxx](null, *) = null,
slice[Xxx](, *) =
Yes, these seem like the simple cases.
Stephen
OK. Unless there are objections or someone else commits
--- Stephen Colebourne [EMAIL PROTECTED] wrote:
has anybody got anything outstanding?
Stephen
I have been working on some additional/improved unit tests for
StringEscapeUtils and CharSetUtils (I notice that there are no unit tests for
CharSetUtils.translate and there is a small javadoc
1 - 100 of 1441 matches
Mail list logo
