[jira] [Commented] (TEXT-25) Add a duration parser
[ https://issues.apache.org/jira/browse/TEXT-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15968003#comment-15968003 ] Amey Jadiye commented on TEXT-25: - Cool, i'm started working on this new features, will keep you posted. btw, any plan of merge this in master and release date ? > Add a duration parser > - > > Key: TEXT-25 > URL: https://issues.apache.org/jira/browse/TEXT-25 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.1 > > > Duration parses interpret text such as *2 hours, 1 mn and 22sec*. > Examples exist, such as https://github.com/jchampemont/gunip, written in > Javaby Jean Champémont, inspired by https://github.com/domchristie/juration > (JavaScript). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-25) Add a duration parser
[ https://issues.apache.org/jira/browse/TEXT-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966464#comment-15966464 ] Amey Jadiye commented on TEXT-25: - Hi [~kinow] Is this merged to TEXT code ? if not let me know show stopper things and i can complete that, after that I wish to add few more matrix like numbers and amount (money) Ex. 1k stringyfy - one thousand. parse - 1000 $1k - stringyfy - one thousand doller parse - $1,000 > Add a duration parser > - > > Key: TEXT-25 > URL: https://issues.apache.org/jira/browse/TEXT-25 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.1 > > > Duration parses interpret text such as *2 hours, 1 mn and 22sec*. > Examples exist, such as https://github.com/jchampemont/gunip, written in > Javaby Jean Champémont, inspired by https://github.com/domchristie/juration > (JavaScript). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (TEXT-25) Add a duration parser
[ https://issues.apache.org/jira/browse/TEXT-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15968003#comment-15968003 ] Amey Jadiye edited comment on TEXT-25 at 4/14/17 8:24 PM: -- Cool, i'm starting work on this new features, will keep you posted. btw, any plan of merge this in master and release date ? was (Author: ameyjadiye): Cool, i'm started working on this new features, will keep you posted. btw, any plan of merge this in master and release date ? > Add a duration parser > - > > Key: TEXT-25 > URL: https://issues.apache.org/jira/browse/TEXT-25 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.1 > > > Duration parses interpret text such as *2 hours, 1 mn and 22sec*. > Examples exist, such as https://github.com/jchampemont/gunip, written in > Javaby Jean Champémont, inspired by https://github.com/domchristie/juration > (JavaScript). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16078527#comment-16078527
]
Amey Jadiye commented on TEXT-97:
-
In that case we have {{.selectFrom()}} API, All I'm expecting is to have
different API available in different situations, I understand that only
{{.selectFrom()}} is enough but others provide more flexibility to existing API.
Few and selected characters : {{.selectFrom(char ... chars)}} // like "I need
just few special chars"
Single range : {{.withinRange(int min , int max)}} //like "I want only numeric"
Multiple ranges : {{.withinRange(final char[] ... pairs)}} //like "I want
alphanumeric"
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-47) WordUtils.capitalize() can't handle 1:M conversions
[
https://issues.apache.org/jira/browse/TEXT-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16086076#comment-16086076
]
Amey Jadiye commented on TEXT-47:
-
I don't see even java have solution for this ? can we just create map and
lookup from it whenever these kind of char comes for conversion ?
> WordUtils.capitalize() can't handle 1:M conversions
> ---
>
> Key: TEXT-47
> URL: https://issues.apache.org/jira/browse/TEXT-47
> Project: Commons Text
> Issue Type: Bug
>Reporter: Duncan Jones
> Fix For: 1.x
>
>
> Some case conversions are not 1:1, for instance the German letter ß, which is
> normally capitalised to 'SS'.
> {code:java}
> // Failing test
> assertEquals("SS", WordUtils.capitalize("\u00DF"));
> {code}
> If we were using upper case and not title case, a solution such as the
> following would work:
> {code:java}
> public static String capitalize(final String str, final char... delimiters) {
> final int delimLen = delimiters == null ? -1 : delimiters.length;
> if (StringUtils.isEmpty(str) || delimLen == 0) {
> return str;
> }
> final StringBuffer buffer = new StringBuffer(str.length());
> final char[] chars = str.toCharArray();
> boolean capitalizeNext = true;
> for (int i = 0; i < chars.length; i++) {
> final char ch = chars[i];
> if (isDelimiter(ch, delimiters)) {
> capitalizeNext = true;
> buffer.append(ch);
> } else if (capitalizeNext) {
> // Use ENGLISH locale to be backwards compatible with previous
> releases, which
> // used Character.toUpperCase()
> buffer.append(String.valueOf(ch).toUpperCase(Locale.ENGLISH));
> capitalizeNext = false;
> } else {
> buffer.append(ch);
> }
> }
> return buffer.toString();
> }
> {code}
> ... but as we use title case, we can't use the String class to convert for us.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DAEMON-370) Remove all the @author tags as per guidelines.
[ https://issues.apache.org/jira/browse/DAEMON-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079695#comment-16079695 ] Amey Jadiye commented on DAEMON-370: [~garydgregory], never mind, moved them to developer section, plz take look at PR https://github.com/apache/commons-daemon/pull/2 > Remove all the @author tags as per guidelines. > -- > > Key: DAEMON-370 > URL: https://issues.apache.org/jira/browse/DAEMON-370 > Project: Commons Daemon > Issue Type: Task >Reporter: Amey Jadiye > > SSIA -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DAEMON-370) Remove all the @author tags as per guidelines.
[
https://issues.apache.org/jira/browse/DAEMON-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079690#comment-16079690
]
Amey Jadiye commented on DAEMON-370:
Hi [~garydgregory],
Almost all authors are present in pom.xml except below two, where should I move
them Developers OR Contributors ?
{code}
@author Pier Fumagalli
@author Nick Griffiths (nicobre...@gmail.com)
{code}
> Remove all the @author tags as per guidelines.
> --
>
> Key: DAEMON-370
> URL: https://issues.apache.org/jira/browse/DAEMON-370
> Project: Commons Daemon
> Issue Type: Task
>Reporter: Amey Jadiye
>
> SSIA
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DAEMON-370) Remove all the @author tags as per guidelines.
[ https://issues.apache.org/jira/browse/DAEMON-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079713#comment-16079713 ] Amey Jadiye commented on DAEMON-370: actually I found Pier In ASF member list so places him in developers while Nick is in contributors section. I think we are good with it now. > Remove all the @author tags as per guidelines. > -- > > Key: DAEMON-370 > URL: https://issues.apache.org/jira/browse/DAEMON-370 > Project: Commons Daemon > Issue Type: Task >Reporter: Amey Jadiye > > SSIA -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DAEMON-370) Remove all the @author tags as per guidelines.
Amey Jadiye created DAEMON-370: -- Summary: Remove all the @author tags as per guidelines. Key: DAEMON-370 URL: https://issues.apache.org/jira/browse/DAEMON-370 Project: Commons Daemon Issue Type: Task Reporter: Amey Jadiye SSIA -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DAEMON-369) Fix and improve general stuff around processes and quality.
Amey Jadiye created DAEMON-369: -- Summary: Fix and improve general stuff around processes and quality. Key: DAEMON-369 URL: https://issues.apache.org/jira/browse/DAEMON-369 Project: Commons Daemon Issue Type: Task Reporter: Amey Jadiye Goal of this JIRA is to improve process of coding, build, release, tests, quality etc ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (DAEMON-370) Move attributions from @author in Javadocs to POM
[ https://issues.apache.org/jira/browse/DAEMON-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amey Jadiye closed DAEMON-370. -- Code Merged to Repository. > Move attributions from @author in Javadocs to POM > - > > Key: DAEMON-370 > URL: https://issues.apache.org/jira/browse/DAEMON-370 > Project: Commons Daemon > Issue Type: Task >Reporter: Amey Jadiye > Fix For: 1.1 > > > SSIA. @authors should be moved to the POM. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079025#comment-16079025
]
Amey Jadiye commented on TEXT-96:
-
[~greenth] Thinking of adding some simple and easy to use tools/methods in 2.x
release.
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (NUMBERS-47) Rename LanczosApproximation.java relative to what exactly its doing.
Amey Jadiye created NUMBERS-47:
--
Summary: Rename LanczosApproximation.java relative to what exactly
its doing.
Key: NUMBERS-47
URL: https://issues.apache.org/jira/browse/NUMBERS-47
Project: Commons Numbers
Issue Type: Task
Reporter: Amey Jadiye
{{LanczosApproximation.java}} class which is actually doing only a part
calculations of Lanczos Approximation algorithm, that should be renamed to some
logical name based on what its doing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-79) Investigate adding string search algorithms
[ https://issues.apache.org/jira/browse/TEXT-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16093415#comment-16093415 ] Amey Jadiye commented on TEXT-79: - [~kinow], can you please check above links if they are possible usecases *OR* if you save some time and find across apache ? > Investigate adding string search algorithms > --- > > Key: TEXT-79 > URL: https://issues.apache.org/jira/browse/TEXT-79 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: algorithm, help-wanted, text > Fix For: 1.x > > > There are a few [string searching > algorithms|https://en.wikipedia.org/wiki/String_searching_algorithm] (e.g. > Rabin Karp) that do not have an implementation in commons yet. > Would be interesting to check if any other ASF projects use any of these or > others (e.g. Lucene, Solr, Tika, etc) and see if they could be implemented in > [text]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values
[
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16095134#comment-16095134
]
Amey Jadiye commented on TEXT-74:
-
found the bug, you owe me a treat ! [~arendvr.com] ;) . give me some time I
will raise PR with fix, I want to refactor the code as {{private int
substitute(final StrBuilder buf, final int offset, final int length,
List priorVariables) }} method is very big and have bug as well.
> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
> Labels: features
> Fix For: 1.x
>
>
> StrSubstitutor replaces variables in values. And currently there's no way to
> turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some
> of the replacement values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$".
> This is annoying. Especially as I use one template with variables as a value
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values
[
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16095134#comment-16095134
]
Amey Jadiye edited comment on TEXT-74 at 7/20/17 6:13 PM:
--
found the bug, you owe me a treat ! [~arendvr.com] ;) . give me some time I
will raise PR with fix, I want to refactor the code as below method is very
big and have bug as well.
bq. private int substitute(final StrBuilder buf, final int offset, final int
length, List priorVariables) }}
was (Author: ameyjadiye):
found the bug, you owe me a treat ! [~arendvr.com] ;) . give me some time I
will raise PR with fix, I want to refactor the code as {{private int
substitute(final StrBuilder buf, final int offset, final int length,
List priorVariables) }} method is very big and have bug as well.
> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
> Labels: features
> Fix For: 1.x
>
>
> StrSubstitutor replaces variables in values. And currently there's no way to
> turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some
> of the replacement values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$".
> This is annoying. Especially as I use one template with variables as a value
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070339#comment-16070339
]
Amey Jadiye commented on TEXT-96:
-
{{RandomStringGenerator}} is certainly better and flexible in terms of your
desired output and I don't know what was motivation behind deprecating
{{RandomStringUtils}} and giving away simple API's. but at some point those
simple things should be accommodated somewhere in {{RandomStringGenerator}}
*or* at least should provide more examples in Javadocs. *or* helper utilities
should me present somewhere which will bring back usefulness of
{{RandomStringUtils}} to -> {{RandomStringGenerator}}
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070462#comment-16070462
]
Amey Jadiye commented on TEXT-96:
-
*Yes*, For scope of this JIRA I strongly believe that. what Mr. [~greenth] want
can be accommodated easily with flexibility of the API.
Ex. for
*.randomNumeric()*
{code}
char [][] ranges = {{'0','9'}};
RandomStringGenerator generator = new
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}
*.randomAlphabetic()*
{code}
char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
RandomStringGenerator generator = new
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}
*.randomAlphanumeric()*
{code}
char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
RandomStringGenerator generator = new
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070970#comment-16070970
]
Amey Jadiye commented on TEXT-96:
-
I want to keep both, i dont see any harm in that :)
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amey Jadiye updated TEXT-97:
Fix Version/s: 1.2
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
Amey Jadiye created TEXT-97:
---
Summary: RandomStringGenerator should be able to pass multiple
ranges to .withinRange()
Key: TEXT-97
URL: https://issues.apache.org/jira/browse/TEXT-97
Project: Commons Text
Issue Type: Improvement
Reporter: Amey Jadiye
Users should have ability to pass multiple ranges to generate desired output.
Ex. For
*.randomNumeric()*
{code}
char [][] ranges = {{'0','9'}};
RandomStringGenerator generator = new
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}
*.randomAlphabetic()*
{code}
char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
RandomStringGenerator generator = new
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}
*.randomAlphanumeric()*
{code}
char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
RandomStringGenerator generator = new
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071290#comment-16071290
]
Amey Jadiye commented on TEXT-96:
-
I have submitted PR for accepting multiple pairs, now the questions is can we
make it more simpler and strait forward like giving direct methods like
_randomNumeric(), randomAlphabetic(), randomAlphanumeric()_ ?
TEXT-97 will able to do the task but not so simpler as Mr [~greenth] expect,
i'm +0 on this front. that is I'm Ok to add those method but Ok as well if we
don't add as TEXT-97 can do that.
> Convenience methods needed for RandomStringGenerator
>
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point
> is in the first place so then trying to get our automation testers to use the
> new API to implement random alphanumeric character generation would be
> difficult.
> I therefore suggest that commons-text should have a copy of
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or
> alternatively convenience static methods for the common use cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071334#comment-16071334
]
Amey Jadiye commented on TEXT-97:
-
Hi,
Primary motivation to write this method was to have single API which will
return random string with given multiple ranges, writing helper method is ok
but not as nice as having single line code giving you output.
Thanks for inputs you gave for mote Validation Cases I can put those to PR.
* Checking input is exact N*2
* Lenght check
* Will think some more before commit
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071366#comment-16071366
]
Amey Jadiye commented on TEXT-97:
-
Agree, usual use cases are numeric, alphabetic and alphanumeric and we can have
those robust methods as well since they are very handy but those should call
{{.withinRange(char[] ...)}} that's what I expect. so if someone in future
would needs another range like "I want alphanumeric plus special char" will
eventually use this API. {code}{{'!','-'},{'0','9'},{'A','Z'},{'a','z'}}{code}
http://www.asciitbl.com/_site_media/ascii/ascii-table-landscape.jpg
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071550#comment-16071550
]
Amey Jadiye commented on TEXT-97:
-
Hmm, lets have extra opinions.
[~chtompki], [~britter], [~brunodepau...@yahoo.com.br], what do you think ?
> RandomStringGenerator should be able to pass multiple ranges to .withinRange()
> --
>
> Key: TEXT-97
> URL: https://issues.apache.org/jira/browse/TEXT-97
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Amey Jadiye
> Fix For: 1.2
>
>
> Users should have ability to pass multiple ranges to generate desired output.
> Ex. For
> *.randomNumeric()*
> {code}
> char [][] ranges = {{'0','9'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphabetic()*
> {code}
> char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
> *.randomAlphanumeric()*
> {code}
> char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}};
> RandomStringGenerator generator = new
> RandomStringGenerator.Builder().withinRange(ranges).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-79) Investigate adding string search algorithms
[ https://issues.apache.org/jira/browse/TEXT-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16065269#comment-16065269 ] Amey Jadiye commented on TEXT-79: - some of the possible use cases. * https://ignite.apache.org/releases/mobile/org/apache/ignite/cache/query/TextQuery.html * https://asterixdb.apache.org/docs/0.9.0/aql/fulltext.html * https://jena.apache.org/documentation/larq/ * http://hadoop.apache.org/docs/r3.0.0-alpha3/api/org/apache/hadoop/io/Text.html --find method > Investigate adding string search algorithms > --- > > Key: TEXT-79 > URL: https://issues.apache.org/jira/browse/TEXT-79 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: algorithm, help-wanted, text > Fix For: 1.x > > > There are a few [string searching > algorithms|https://en.wikipedia.org/wiki/String_searching_algorithm] (e.g. > Rabin Karp) that do not have an implementation in commons yet. > Would be interesting to check if any other ASF projects use any of these or > others (e.g. Lucene, Solr, Tika, etc) and see if they could be implemented in > [text]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074754#comment-16074754
]
Amey Jadiye commented on NUMBERS-38:
Sounds good! Thanks [~erans]
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
> Attachments: NUMBERS-38.patch
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-55) Move WordUtils off on to its own branch
[ https://issues.apache.org/jira/browse/TEXT-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993517#comment-15993517 ] Amey Jadiye commented on TEXT-55: - pushing this back to master for release 1.1 > Move WordUtils off on to its own branch > --- > > Key: TEXT-55 > URL: https://issues.apache.org/jira/browse/TEXT-55 > Project: Commons Text > Issue Type: Task >Reporter: Rob Tompkins >Assignee: Rob Tompkins > Fix For: 1.0 > > > Create a branch for WordUtils and delete from master. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-39) WordUtils should use toXxxxCase(int) rather than toXxxxCase(char)
[ https://issues.apache.org/jira/browse/TEXT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995402#comment-15995402 ] Amey Jadiye commented on TEXT-39: - Hi Folks, this jira is marked for 1.1 release, any update on this ? since WordUtils is back in commons text do we need to still implement this? let me know the details and i can push this change, else close JIRA. > WordUtils should use toXxxxCase(int) rather than toXxxxCase(char) > - > > Key: TEXT-39 > URL: https://issues.apache.org/jira/browse/TEXT-39 > Project: Commons Text > Issue Type: Improvement >Reporter: Sebb > Fix For: 1.1 > > > The Javadoc for Character#toTitleCase(char) recommends using > Character#toTitleCase(int) instead. This method was added in Java 1.5 which > is perhaps is why it was not used originally; maybe we should use it now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-41) WordUtils.abbreviate support
[ https://issues.apache.org/jira/browse/TEXT-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995505#comment-15995505 ] Amey Jadiye commented on TEXT-41: - Hi All, This was pending since long (2012), created pull request based on patch submitted, let me know if any further action required on this ? https://github.com/apache/commons-text/pull/38 > WordUtils.abbreviate support > > > Key: TEXT-41 > URL: https://issues.apache.org/jira/browse/TEXT-41 > Project: Commons Text > Issue Type: New Feature >Reporter: Mirek Hankus > Fix For: 1.1 > > Attachments: LANG-766.patch > > > Commons Lang 2.x has method WordUtils.abbreviate(java.lang.String str, int > lower, int upper, java.lang.String appendToEnd), which > # operates on words not Strings as StringUtils.abbreviate > # it allows to specify what shoud be appended to string > (StringUtils.abbreviate always appends "...") > In 3.0 there is no such method, but it was very usefull. please add support > for WordUtils.abbreviate -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-39) WordUtils should use toXxxxCase(int) rather than toXxxxCase(char)
[ https://issues.apache.org/jira/browse/TEXT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15995522#comment-15995522 ] Amey Jadiye commented on TEXT-39: - Thanks [~pascalschumacher] for confirmation, working on it. > WordUtils should use toXxxxCase(int) rather than toXxxxCase(char) > - > > Key: TEXT-39 > URL: https://issues.apache.org/jira/browse/TEXT-39 > Project: Commons Text > Issue Type: Improvement >Reporter: Sebb > Fix For: 1.1 > > > The Javadoc for Character#toTitleCase(char) recommends using > Character#toTitleCase(int) instead. This method was added in Java 1.5 which > is perhaps is why it was not used originally; maybe we should use it now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-25) Add a duration parser
[
https://issues.apache.org/jira/browse/TEXT-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16006816#comment-16006816
]
Amey Jadiye commented on TEXT-25:
-
[~kinow], i'm braking the task in smaller parts here, lets start with
internationalisation, the implementation Jean have is pretty straight forward,
assign the Strings to particulate unit and you are done, so example for second
unit you give different titles of different language in a row (which can be
made configurable)
Ex.
* Seconds in English
* Secondes in French
* Segundos in Portuguese
* Secondi in Italian
and that's it,
{code:java}
public DurationParser() {
super(Unit.UnitsBuilder.baseUnit( "s", "sec",
"second","Seconds","Secondes","Segundos","Secondi")
.addUnit(60 , "m(?!s)", "min", "minute")
.addUnit(60 * 60 , "h", "hr", "hour")
.addUnit(60 * 60 * 24 , "d", "dy", "day")
.addUnit(60 * 60 * 24 * 7 , "w", "wk", "week")
.addUnit(2628000 , "mth", "mo", "mon", "month")
.addUnit(31536000 , "y", "yr", "year")
.build()
);
}
{code}
I want to know what else you are expecting here ?
> Add a duration parser
> -
>
> Key: TEXT-25
> URL: https://issues.apache.org/jira/browse/TEXT-25
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.1
>
>
> Duration parses interpret text such as *2 hours, 1 mn and 22sec*.
> Examples exist, such as https://github.com/jchampemont/gunip, written in
> Javaby Jean Champémont, inspired by https://github.com/domchristie/juration
> (JavaScript).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-37) Angle class
[
https://issues.apache.org/jira/browse/NUMBERS-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16006855#comment-16006855
]
Amey Jadiye commented on NUMBERS-37:
I like the idea also If you want to modularize the things in commons number I
would prefer core should have very core part of numbers which is already
mentioned in Commons Math now here angle is the part of geometry so the package
should be mentioned on top like
``` package org.apache.commons.numbers.geometry.core;```
``` package org.apache.commons.numbers.calculus.core;```
``` package org.apache.commons.numbers.algebra.core;```
``` package org.apache.commons.numbers.trigonometry.core;```
IMO PlaneAngle should be part of geometry.
> Angle class
> ---
>
> Key: NUMBERS-37
> URL: https://issues.apache.org/jira/browse/NUMBERS-37
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api
> Fix For: 1.0
>
> Attachments: PlaneAngle.java
>
>
> How about adding (to module {{commons-numbers-core}}) a class representing
> the "angle" concept (see attached file)?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (NUMBERS-37) Angle class
[
https://issues.apache.org/jira/browse/NUMBERS-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16006855#comment-16006855
]
Amey Jadiye edited comment on NUMBERS-37 at 5/11/17 5:38 PM:
-
I like the idea also If you want to modularize the things in commons number I
would prefer core should have very core part of numbers which is already
mentioned in Commons Math. Now here angle is the part of geometry so the
package should be mentioned on top like
{code:java}
package org.apache.commons.numbers.geometry.core;
package org.apache.commons.numbers.calculus.core;
package org.apache.commons.numbers.algebra.core;
package org.apache.commons.numbers.trigonometry.core;
{code}
IMO PlaneAngle should be part of geometry.
was (Author: ameyjadiye):
I like the idea also If you want to modularize the things in commons number I
would prefer core should have very core part of numbers which is already
mentioned in Commons Math now here angle is the part of geometry so the package
should be mentioned on top like
``` package org.apache.commons.numbers.geometry.core;```
``` package org.apache.commons.numbers.calculus.core;```
``` package org.apache.commons.numbers.algebra.core;```
``` package org.apache.commons.numbers.trigonometry.core;```
IMO PlaneAngle should be part of geometry.
> Angle class
> ---
>
> Key: NUMBERS-37
> URL: https://issues.apache.org/jira/browse/NUMBERS-37
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api
> Fix For: 1.0
>
> Attachments: PlaneAngle.java
>
>
> How about adding (to module {{commons-numbers-core}}) a class representing
> the "angle" concept (see attached file)?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TEXT-41) WordUtils.abbreviate support
[ https://issues.apache.org/jira/browse/TEXT-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002966#comment-16002966 ] Amey Jadiye commented on TEXT-41: - Hi [~chtompki], as PR already merged can we mark this to resolved ? > WordUtils.abbreviate support > > > Key: TEXT-41 > URL: https://issues.apache.org/jira/browse/TEXT-41 > Project: Commons Text > Issue Type: New Feature >Reporter: Mirek Hankus >Assignee: Rob Tompkins > Fix For: 1.1 > > Attachments: LANG-766.patch > > > Commons Lang 2.x has method WordUtils.abbreviate(java.lang.String str, int > lower, int upper, java.lang.String appendToEnd), which > # operates on words not Strings as StringUtils.abbreviate > # it allows to specify what shoud be appended to string > (StringUtils.abbreviate always appends "...") > In 3.0 there is no such method, but it was very usefull. please add support > for WordUtils.abbreviate -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (NUMBERS-37) Angle class
[
https://issues.apache.org/jira/browse/NUMBERS-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amey Jadiye updated NUMBERS-37:
---
Comment: was deleted
(was: I like the idea also If you want to modularize the things in commons
number I would prefer core should have very core part of numbers which is
already mentioned in Commons Math. Now here angle is the part of geometry so
the package should be mentioned on top like
{code:java}
package org.apache.commons.numbers.geometry.core;
package org.apache.commons.numbers.calculus.core;
package org.apache.commons.numbers.algebra.core;
package org.apache.commons.numbers.trigonometry.core;
{code}
IMO PlaneAngle should be part of geometry.)
> Angle class
> ---
>
> Key: NUMBERS-37
> URL: https://issues.apache.org/jira/browse/NUMBERS-37
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api
> Fix For: 1.0
>
> Attachments: PlaneAngle.java
>
>
> How about adding (to module {{commons-numbers-core}}) a class representing
> the "angle" concept (see attached file)?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046828#comment-16046828
]
Amey Jadiye commented on TEXT-88:
-
agreed, its a obvious bug looking at code.
{code:java}
public static String capitalizeFully(String str, final char... delimiters) {
final int delimLen = delimiters == null ? -1 : delimiters.length;
if (StringUtils.isEmpty(str) || delimLen == 0) { // BUG IS HERE, if
length is 0 , returning str as it is.
return str;
}
str = str.toLowerCase();
return capitalize(str, delimiters);
}
{code}
FIX :
{code:java}
public static String capitalizeFully(String str, final char... delimiters) {
final int delimLen = delimiters == null ? -1 : delimiters.length;
if (StringUtils.isEmpty(str)) {
return str;
}
if (delimLen == 0){
return capitalize(str.toLowerCase(), null);
}
str = str.toLowerCase();
return capitalize(str, delimiters);
}
{code}
> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
> Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have
> been capitalized resulting in the output {{I am fine}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (LANG-1340) Add IBM Java 8 CI checks for Commons Lang
Amey Jadiye created LANG-1340: - Summary: Add IBM Java 8 CI checks for Commons Lang Key: LANG-1340 URL: https://issues.apache.org/jira/browse/LANG-1340 Project: Commons Lang Issue Type: Improvement Reporter: Amey Jadiye -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-79) Investigate adding string search algorithms
[ https://issues.apache.org/jira/browse/TEXT-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16058078#comment-16058078 ] Amey Jadiye commented on TEXT-79: - Hi [~kinow] Lucene don't use the string search algorithms, how it works explained in below stackoverflow question. https://stackoverflow.com/questions/2208649/string-matching-algorithms-used-by-lucene I personally feel that we should have string search API in Commons Text, I will be glad to provide the PR. > Investigate adding string search algorithms > --- > > Key: TEXT-79 > URL: https://issues.apache.org/jira/browse/TEXT-79 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: algorithm, help-wanted, text > Fix For: 1.x > > > There are a few [string searching > algorithms|https://en.wikipedia.org/wiki/String_searching_algorithm] (e.g. > Rabin Karp) that do not have an implementation in commons yet. > Would be interesting to check if any other ASF projects use any of these or > others (e.g. Lucene, Solr, Tika, etc) and see if they could be implemented in > [text]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters
[ https://issues.apache.org/jira/browse/TEXT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059748#comment-16059748 ] Amey Jadiye commented on TEXT-93: - Hi [~pascalschumacher] Though your code is generating expected output this seems workaround to achieve Random String from given characters and user have to do lot of work himself. I'm in favour of having simple API given by [~erans] to which I can pass char array or char list and it will return Random String. what do you think ? > RandomStringGenerator accepts a list of valid characters > > > Key: TEXT-93 > URL: https://issues.apache.org/jira/browse/TEXT-93 > Project: Commons Text > Issue Type: Wish >Reporter: Wilson MacGyver > > implement a "selectFrom" feature: > RandomStringGenerator gen = new RandomStringGenerator.Builder() > .selectFrom(charArray) > .build(); > so we can pass a list of valid characters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters
[
https://issues.apache.org/jira/browse/TEXT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16060473#comment-16060473
]
Amey Jadiye commented on TEXT-93:
-
Agreed with name change.
For suggested varargs we should have one more overloaded method so there will
be total below 3 methods
{code}
selectFromList(List)
selectFrom(char[])
selectFrom(Character ... )
{code}
> RandomStringGenerator accepts a list of valid characters
>
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
> Issue Type: Wish
>Reporter: Wilson MacGyver
>
> implement a "selectFrom" feature:
> RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters
[ https://issues.apache.org/jira/browse/TEXT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16061412#comment-16061412 ] Amey Jadiye commented on TEXT-93: - Committed all the changes we discussed to PR. > RandomStringGenerator accepts a list of valid characters > > > Key: TEXT-93 > URL: https://issues.apache.org/jira/browse/TEXT-93 > Project: Commons Text > Issue Type: Wish >Reporter: Wilson MacGyver > > implement a "selectFrom" feature: > RandomStringGenerator gen = new RandomStringGenerator.Builder() > .selectFrom(charArray) > .build(); > so we can pass a list of valid characters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters
[ https://issues.apache.org/jira/browse/TEXT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16061773#comment-16061773 ] Amey Jadiye commented on TEXT-93: - Hi Gilles, That method is removed all together as per previous discussion, you are looking some past commit., Now we are having only selectFrom method with varargs. > RandomStringGenerator accepts a list of valid characters > > > Key: TEXT-93 > URL: https://issues.apache.org/jira/browse/TEXT-93 > Project: Commons Text > Issue Type: Wish >Reporter: Wilson MacGyver > > implement a "selectFrom" feature: > RandomStringGenerator gen = new RandomStringGenerator.Builder() > .selectFrom(charArray) > .build(); > so we can pass a list of valid characters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters
[ https://issues.apache.org/jira/browse/TEXT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16061880#comment-16061880 ] Amey Jadiye commented on TEXT-93: - Well, Yes nowadays programmers prefer List over arrays and it's convineant too, but I'm not biased towards either decision to have that method or not as far as we have another method to perform task for us. [~pascalschumacher] and [~wmacgyver] what do you think ? > RandomStringGenerator accepts a list of valid characters > > > Key: TEXT-93 > URL: https://issues.apache.org/jira/browse/TEXT-93 > Project: Commons Text > Issue Type: Wish >Reporter: Wilson MacGyver > > implement a "selectFrom" feature: > RandomStringGenerator gen = new RandomStringGenerator.Builder() > .selectFrom(charArray) > .build(); > so we can pass a list of valid characters -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TEXT-83) Deprecate CsvTranslators from from commons text in favor of Commons CSV
[ https://issues.apache.org/jira/browse/TEXT-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amey Jadiye updated TEXT-83: Description: Deprecate CsvTranslators from from commons text in favor of Commons CSV > Deprecate CsvTranslators from from commons text in favor of Commons CSV > --- > > Key: TEXT-83 > URL: https://issues.apache.org/jira/browse/TEXT-83 > Project: Commons Text > Issue Type: Task >Reporter: Amey Jadiye >Priority: Minor > Fix For: 1.x > > > Deprecate CsvTranslators from from commons text in favor of Commons CSV -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TEXT-83) Deprecate CsvTranslators from from commons text in favor of Commons CSV
Amey Jadiye created TEXT-83: --- Summary: Deprecate CsvTranslators from from commons text in favor of Commons CSV Key: TEXT-83 URL: https://issues.apache.org/jira/browse/TEXT-83 Project: Commons Text Issue Type: Task Reporter: Amey Jadiye Priority: Minor Fix For: 1.x -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-83) Deprecate CsvTranslators from from commons text in favor of Commons CSV
[ https://issues.apache.org/jira/browse/TEXT-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16022969#comment-16022969 ] Amey Jadiye commented on TEXT-83: - [~ggregory] [~chtompki], shall we move CsvTranslators to Commons CSV as well ? > Deprecate CsvTranslators from from commons text in favor of Commons CSV > --- > > Key: TEXT-83 > URL: https://issues.apache.org/jira/browse/TEXT-83 > Project: Commons Text > Issue Type: Task >Reporter: Amey Jadiye >Priority: Minor > Fix For: 1.x > > > Deprecate CsvTranslators from from commons text in favor of Commons CSV -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-77) Add code to check if a given string is a palindrome
[ https://issues.apache.org/jira/browse/TEXT-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026594#comment-16026594 ] Amey Jadiye commented on TEXT-77: - I think StringUtils would be better place for this method, good to have method in toolbox, in future another wrapper on top of this method can create specific and more complex usage of palindrome. > Add code to check if a given string is a palindrome > --- > > Key: TEXT-77 > URL: https://issues.apache.org/jira/browse/TEXT-77 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: easy, help-wanted, text > Fix For: 1.x > > > I had a look at > [lang|https://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html] > and > [text|https://commons.apache.org/proper/commons-text/javadocs/api-release/index.html] > API's, but could not locate a class/method for > [palindromes|https://en.wikipedia.org/wiki/Palindrome]. > Ideally, it would support words or sentences such as "racecar" and "step on > no pets". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036031#comment-16036031
]
Amey Jadiye commented on NUMBERS-38:
Ah, got it. will put some coverage around that, Thanks.
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035990#comment-16035990
]
Amey Jadiye commented on NUMBERS-38:
Hi,
I can see one test class here, do we expect more test cases here ?
https://github.com/apache/commons-numbers/blob/d79edb264f71db3e88779efe2681fa8c48310c3c/commons-numbers-gamma/src/test/java/org/apache/commons/numbers/gamma/LanczosApproximationTest.java
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036041#comment-16036041
]
Amey Jadiye commented on NUMBERS-38:
PR is raised, please have a look
https://github.com/apache/commons-numbers/pull/5
Thanks,
Amey
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036254#comment-16036254
]
Amey Jadiye commented on NUMBERS-38:
Hi [~erans]
My initial thoughts was the formula given in code itself is the marker to test
and is perfectly written (as present in apache's project), your comment forced
me to verify everything from roots which ended up me reading lots of papers and
watching youtube on Gamma functions and approximations _(including great
interview of [Cornelius Lanczos|https://www.youtube.com/watch?v=avSHHi9QCjA])_
and finally I found our Code is Buggy generating wrong values for inputs :(
There are the some references I cross verified the test input/outputs _(both
produce same result and our code produce something else)_
- [https://rosettacode.org/wiki/Gamma_function#Java]
- [https://en.wikipedia.org/wiki/Lanczos_approximation] (_this is python but
generates same outputs_)
I saw coefficient are take from (which are standard anyway), no matter which
set you take results are approx same.
- [https://mrob.com/pub/ries/lanczos-gamma.html]
For more cross verification there is online gamma calculator which also gives
same result.
- [http://www.efunda.com/math/gamma/findgamma.cfm]
All that I said, our code need to be fixed and it should generate
{{gamma(z)=(n-1)!}} (n minus one factorial) values.
let me know your thoughts.
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036264#comment-16036264
]
Amey Jadiye commented on NUMBERS-38:
Hi [~erans],
I think all that you copied from commons math is correct just need better
refactoring of code, as of now partial logic is present in {{Gamma.java}} and
{{LanczosApproximation.java}} and they both generate correct output, that said
I just went through all repository of commons-number and found that code is
being called from {{Gamma.java}} _(which I see is very abstract term/class)_
for *Gamma functions* and Lanczos Approximation as well as Stirling
Approximation _(not present in repo, we can code this and will be and
addition)_ are extension to Gamma so their full logic should be in their own
class.
I Gamma we are generating values with basic logic if {{n <= 20}} else we
calculate it with LanczosApproximation, all we can do is to put full logic in
{{LanczosApproximation.java}} and just call it, at this point Test-cases on
LanczosApproximation doesn't make sense.
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036289#comment-16036289
]
Amey Jadiye commented on NUMBERS-38:
bq. I'm now confused as to what the problem is.
Sorry for confusion, there is no bug in output as whole class but I strongly
feel there is incorrect design _(which I called bug)_.
bq. The refactoring was based on the simple premise that each building block is
defined in its own class.
I think that's what not present in code, leading me to generated incorrect
output verses expected according to class. (*misnomer*)
bq. If the output of Gamma is buggy, please file a JIRA report and then create
a corresponding unit test.
No need to raise as bug, but yes different JIRA should be there for
refactoring it correctly.
bq. Why couldn't you generate a list of reference output values, from any of
the codes you've found.
reference functions given are as whole, I can generate by breaking that code
but that's incorrect.
Please review attached patch, you will be more clear on my views.
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
> Attachments: NUMBERS-38.patch
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amey Jadiye updated NUMBERS-38:
---
Attachment: NUMBERS-38.patch
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
> Attachments: NUMBERS-38.patch
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-43) Remove "round(float)" methods?
[
https://issues.apache.org/jira/browse/NUMBERS-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048329#comment-16048329
]
Amey Jadiye commented on NUMBERS-43:
here.
{code}
public static float round(float x, int scale, int roundingMethod) {
final float sign = Math.copySign(1f, x);
final float factor = (float) Math.pow(10.0f, scale) * sign;
return (float) roundUnscaled(x * factor, sign, roundingMethod) /
factor; // its calling method which return double.
}
{code}
bq. The point here is rather whether anyone would be using {{float}}s for
computations nowadays.
I think now people are using BigDecimal rather than float and double to _(at
least in finance)_, so should be good to deprecate at this point or completely
remove, your call.
> Remove "round(float)" methods?
> --
>
> Key: NUMBERS-43
> URL: https://issues.apache.org/jira/browse/NUMBERS-43
> Project: Commons Numbers
> Issue Type: Wish
>Reporter: Gilles
> Labels: api, float
> Fix For: 1.0
>
>
> In class {{Precision}}, there are methods for rounding {{float}} values, e.g.
> {code:java}
> public static float round(float x, int scale, int roundingMethod) { /* ... */
> }
> {code}
> Is there any use for supporting specific handling of floats (in these times
> where memory is not a scarce resources anymore)?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048366#comment-16048366
]
Amey Jadiye commented on TEXT-88:
-
[~s...@apache.org] +1 , will push those fix to same PR.
> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
> Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have
> been capitalized resulting in the output {{I am fine}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NUMBERS-43) Remove "round(float)" methods?
[
https://issues.apache.org/jira/browse/NUMBERS-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048297#comment-16048297
]
Amey Jadiye commented on NUMBERS-43:
Ah, didn't know we have overloaded method for same, just saw the code and at
some point its anyway calling method which return double typecasting to float,
+1 to remove this method also its siblings.
> Remove "round(float)" methods?
> --
>
> Key: NUMBERS-43
> URL: https://issues.apache.org/jira/browse/NUMBERS-43
> Project: Commons Numbers
> Issue Type: Wish
>Reporter: Gilles
> Labels: api, float
> Fix For: 1.0
>
>
> In class {{Precision}}, there are methods for rounding {{float}} values, e.g.
> {code:java}
> public static float round(float x, int scale, int roundingMethod) { /* ... */
> }
> {code}
> Is there any use for supporting specific handling of floats (in these times
> where memory is not a scarce resources anymore)?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (NUMBERS-44) IndexOutOfRangeException(int) not thrown in ComplexUtils
Amey Jadiye created NUMBERS-44: -- Summary: IndexOutOfRangeException(int) not thrown in ComplexUtils Key: NUMBERS-44 URL: https://issues.apache.org/jira/browse/NUMBERS-44 Project: Commons Numbers Issue Type: Bug Reporter: Amey Jadiye -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050853#comment-16050853
]
Amey Jadiye commented on TEXT-88:
-
Hmm, we can arrange code so behaviour will desired for those 2-3 methods but
throwing Exceptions is not good idea IMHO, exceptions should be handled in
utility methods.
Also if we go with your logic the below methods should be changed and throw
NPE? I think they are doing well in {{StringUtils}}.
{code}
StringUtils.equals("abc", null) = false
StringUtils.isEmpty(null) = true
StringUtils.isBlank(null) = true
StringUtils.isNotBlank(null) = false
StringUtils.isAnyBlank(null, "foo") = true
StringUtils.isNoneBlank(null, "foo") = false
StringUtils.isNoneBlank(null, null) = false
StringUtils.strip(null, *) = null
.
.
.
// many more
{code}
> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
> Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have
> been capitalized resulting in the output {{I am fine}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-83) Deprecate CsvTranslators from from commons text in favor of Commons CSV
[ https://issues.apache.org/jira/browse/TEXT-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16045670#comment-16045670 ] Amey Jadiye commented on TEXT-83: - any suggestion and action we should go with ?, I just made documentation pointing to Commons-csv for now. > Deprecate CsvTranslators from from commons text in favor of Commons CSV > --- > > Key: TEXT-83 > URL: https://issues.apache.org/jira/browse/TEXT-83 > Project: Commons Text > Issue Type: Task >Reporter: Amey Jadiye >Priority: Minor > Fix For: 1.x > > > Deprecate CsvTranslators from from commons text in favor of Commons CSV -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048828#comment-16048828
]
Amey Jadiye commented on TEXT-88:
-
[~gilles] the behavior you are looking as bug , I see it as feature ;-), IMO
rather throwing NPE we should handle situation and reply appropriately and
that's how many method works in Commons Text , mentioning behavior in Javadoc
of each method is good enough to tell users how it will work.
> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
> Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have
> been capitalized resulting in the output {{I am fine}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NUMBERS-43) Remove "round(float)" methods?
[
https://issues.apache.org/jira/browse/NUMBERS-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048123#comment-16048123
]
Amey Jadiye commented on NUMBERS-43:
In financial institutes sometimes we might want to round of numbers at certain
lengths of number so i think we should keep it.
> Remove "round(float)" methods?
> --
>
> Key: NUMBERS-43
> URL: https://issues.apache.org/jira/browse/NUMBERS-43
> Project: Commons Numbers
> Issue Type: Wish
>Reporter: Gilles
> Labels: api, float
> Fix For: 1.0
>
>
> In class {{Precision}}, there are methods for rounding {{float}} values, e.g.
> {code:java}
> public static float round(float x, int scale, int roundingMethod) { /* ... */
> }
> {code}
> Is there any use for supporting specific handling of floats (in these times
> where memory is not a scarce resources anymore)?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048828#comment-16048828
]
Amey Jadiye edited comment on TEXT-88 at 6/14/17 9:26 AM:
--
[~erans] the behavior you are looking as bug , I see it as feature ;-), IMO
rather throwing NPE we should handle situation and reply appropriately and
that's how many method works in Commons Text , mentioning behavior in Javadoc
of each method is good enough to tell users how it will work.
was (Author: ameyjadiye):
[~gilles] the behavior you are looking as bug , I see it as feature ;-), IMO
rather throwing NPE we should handle situation and reply appropriately and
that's how many method works in Commons Text , mentioning behavior in Javadoc
of each method is good enough to tell users how it will work.
> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
> Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have
> been capitalized resulting in the output {{I am fine}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048107#comment-16048107
]
Amey Jadiye commented on TEXT-88:
-
Hi [~arunvinud],
I think the output passing nothing *or* null *or* empty char array should be
same because the reason given by [~s...@apache.org] that if nothing is passed
white space should be the default delimiter, reason being we are working for
WordUtils and not StringUtils, Thinking with little broader use of WordUtils,
words are always separated by spaces and with given PR we are getting same
output.
{code:java}
WordUtils.capitalizeFully("i am fine") --> I Am Fine
WordUtils.capitalizeFully("i am fine", null) --> I Am Fine
WordUtils.capitalizeFully("i am fine", new char[]{}) --> I Am Fine
{code}
I understand your concern about to consider empty char array should be
considered as no delimiter but as name suggest *capitalizeFully* is made for
capitalising all words in sentence so _no delimiter = null_, if we want to
capitalise just first char of whole sentence we should have different method
with appropriate name.
> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
> Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have
> been capitalized resulting in the output {{I am fine}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-39) WordUtils should use toXxxxCase(int) rather than toXxxxCase(char)
[ https://issues.apache.org/jira/browse/TEXT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998903#comment-15998903 ] Amey Jadiye commented on TEXT-39: - [~pascalschumacher], I have submitted PR please verify https://github.com/apache/commons-text/pull/39 > WordUtils should use toXxxxCase(int) rather than toXxxxCase(char) > - > > Key: TEXT-39 > URL: https://issues.apache.org/jira/browse/TEXT-39 > Project: Commons Text > Issue Type: Improvement >Reporter: Sebb > Fix For: 1.1 > > > The Javadoc for Character#toTitleCase(char) recommends using > Character#toTitleCase(int) instead. This method was added in Java 1.5 which > is perhaps is why it was not used originally; maybe we should use it now. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037408#comment-16037408
]
Amey Jadiye commented on NUMBERS-38:
Hi [~erans]
bq. It is still not clear to me what is the benefit of moving those lines ...
Let me try to put this way .. Gamma is nothing but advanced factorial function
with advantages like we can have factorial of whole numbers as well as
factional. Now [Gamma function| https://en.wikipedia.org/wiki/Gamma_function]
which is having general formula {{Gamma( x ) = integral( t^(x-1) e^(-t), t = 0
.. infinity)}} and Lanczos approximation / Stirling's approximation /Spouge's
Approximation *is a* gamma function so they should be extend Gamma.
Exact algorithm and formulas here :
- [Lanczo's Approximation|https://en.wikipedia.org/wiki/Lanczos_approximation]
- [Stirling's
Approximation|https://en.wikipedia.org/wiki/Stirling%27s_approximation]
- [Spouge's
Approximation|https://en.wikipedia.org/wiki/Spouge%27s_approximation]
Why to refactor code is because basic gamma computes not so accurate values so
someone who need quick computation without precision can choose it, while
someone who need precision overs cost of performance _(Lanczos approximation is
accurate so its slow)_ can choose which algorithm they want which is not
possible right now.
I'm proposing something like:
{quote}
Gamma gammaFun = new Gamma(); gammaFun.value( x );
Gamma gammaFun = new LanczosGamma(); gammaFun.value( x );
Gamma gammaFun = new StirlingsGamma(); gammaFun.value( x );
Gamma gammaFun = new SpougesGamma(); gammaFun.value( x );
{quote}
as the class name suggestion {{LanczosApproximation}} it should execute full
_Lanczos Algoritham_ but we are just computing coefficients in that class which
is incorrect, so just refactoring is needed which wont break any dependency of
this class anywhere.
All that said, will do 2 things now.
# I will propose this to commons-dev mailing list and lets see what others are
thinking about this ?
# I will change the PR code and will make test cases just to test what
coefficients are we generating with against 2 codes I found on internet._(which
is you are suggesting)_
So if proposal fails we will have test cases anyway for existing code *or* if
proposal passes will create other JIRA and modify test cases according to
different algorithms.
let me know your thoughts?
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
> Attachments: NUMBERS-38.patch
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036254#comment-16036254
]
Amey Jadiye edited comment on NUMBERS-38 at 6/5/17 7:02 PM:
Hi [~erans]
My initial thoughts was the formula given in code itself is the marker to test
and is perfectly written (as present in apache's project), your comment forced
me to verify everything from roots which ended up me reading lots of papers and
watching youtube on Gamma functions and approximations _(including great
interview of [Cornelius Lanczos|https://www.youtube.com/watch?v=avSHHi9QCjA])_
and finally I found our Code is Buggy generating wrong values for inputs :(
_(design bug not code!)_
There are the some references I cross verified the test input/outputs _(both
produce same result and our code produce something else)_
- [https://rosettacode.org/wiki/Gamma_function#Java]
- [https://en.wikipedia.org/wiki/Lanczos_approximation] (_this is python but
generates same outputs_)
I saw coefficient are take from (which are standard anyway), no matter which
set you take results are approx same.
- [https://mrob.com/pub/ries/lanczos-gamma.html]
For more cross verification there is online gamma calculator which also gives
same result.
- [http://www.efunda.com/math/gamma/findgamma.cfm]
All that I said, our code need to be fixed and it should generate
{{gamma(z)=(n-1)!}} (n minus one factorial) values.
let me know your thoughts.
was (Author: ameyjadiye):
Hi [~erans]
My initial thoughts was the formula given in code itself is the marker to test
and is perfectly written (as present in apache's project), your comment forced
me to verify everything from roots which ended up me reading lots of papers and
watching youtube on Gamma functions and approximations _(including great
interview of [Cornelius Lanczos|https://www.youtube.com/watch?v=avSHHi9QCjA])_
and finally I found our Code is Buggy generating wrong values for inputs :(
There are the some references I cross verified the test input/outputs _(both
produce same result and our code produce something else)_
- [https://rosettacode.org/wiki/Gamma_function#Java]
- [https://en.wikipedia.org/wiki/Lanczos_approximation] (_this is python but
generates same outputs_)
I saw coefficient are take from (which are standard anyway), no matter which
set you take results are approx same.
- [https://mrob.com/pub/ries/lanczos-gamma.html]
For more cross verification there is online gamma calculator which also gives
same result.
- [http://www.efunda.com/math/gamma/findgamma.cfm]
All that I said, our code need to be fixed and it should generate
{{gamma(z)=(n-1)!}} (n minus one factorial) values.
let me know your thoughts.
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
> Attachments: NUMBERS-38.patch
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-38) No unit tests for "LanczosApproximation" class
[
https://issues.apache.org/jira/browse/NUMBERS-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039506#comment-16039506
]
Amey Jadiye commented on NUMBERS-38:
Hello [~erans],
I have submitted code for your review, now latest test case only going to test
values generated by {{LanczosApproximation.java}} against code given
[Here|https://rosettacode.org/wiki/Gamma_function#Java] which was scope of this
jira and we can merge and close it.
My intent is modifying code with no breaks anywhere, I've reviewed the code in
{{GammaDistribution}} we might need to change it if we go with my approach,
and anyway we are segregating Math and Numbers so we are in that flow to change
it little more.
Lets see what others are thinking, for now we can close this ticket as it have
completed its purpose.
> No unit tests for "LanczosApproximation" class
> --
>
> Key: NUMBERS-38
> URL: https://issues.apache.org/jira/browse/NUMBERS-38
> Project: Commons Numbers
> Issue Type: Test
>Reporter: Gilles
> Labels: unit-test
> Fix For: 1.0
>
> Attachments: NUMBERS-38.patch
>
>
> The computation of the {{LanczosApproximation}} (package
> {{o.a.c.numbers.gamma}} in module {{commons-numbers-gamma}}) function is not
> checked by unit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (LANG-1340) Add IBM Java 8 CI checks for Commons Lang
[ https://issues.apache.org/jira/browse/LANG-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amey Jadiye closed LANG-1340. - Resolution: Unresolved > Add IBM Java 8 CI checks for Commons Lang > - > > Key: LANG-1340 > URL: https://issues.apache.org/jira/browse/LANG-1340 > Project: Commons Lang > Issue Type: Improvement >Reporter: Amey Jadiye > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TEXT-101) Move RandomStringUtils to Commons-text
[ https://issues.apache.org/jira/browse/TEXT-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amey Jadiye closed TEXT-101. Resolution: Won't Do > Move RandomStringUtils to Commons-text > -- > > Key: TEXT-101 > URL: https://issues.apache.org/jira/browse/TEXT-101 > Project: Commons Text > Issue Type: Task >Reporter: Amey Jadiye > Fix For: 1.2 > > > This task contains not just moving but , > 1. Keep RandomStringUtils deprecated in commons-lang. > 2. Move RandomStringUtils class to commons-text. > 3. Remove all existing code from methods of RandomStringUtils and call our > brand new RandomStringGenerator in them. to return respective values i.e. > randomNumeric, randomAlphabetic, randomAlphanumeric etc -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TEXT-101) Move RandomStringUtils to Commons-text
Amey Jadiye created TEXT-101: Summary: Move RandomStringUtils to Commons-text Key: TEXT-101 URL: https://issues.apache.org/jira/browse/TEXT-101 Project: Commons Text Issue Type: Task Reporter: Amey Jadiye This task contains not just moving but , 1. Keep RandomStringUtils deprecated in commons-lang. 2. Move RandomStringUtils class to commons-text. 3. Remove all existing code from methods of RandomStringUtils and call our brand new RandomStringGenerator in them. to return respective values i.e. randomNumeric, randomAlphabetic, randomAlphanumeric etc -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TEXT-101) Move RandomStringUtils to Commons-text
[ https://issues.apache.org/jira/browse/TEXT-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amey Jadiye updated TEXT-101: - Fix Version/s: 1.2 > Move RandomStringUtils to Commons-text > -- > > Key: TEXT-101 > URL: https://issues.apache.org/jira/browse/TEXT-101 > Project: Commons Text > Issue Type: Task >Reporter: Amey Jadiye > Fix For: 1.2 > > > This task contains not just moving but , > 1. Keep RandomStringUtils deprecated in commons-lang. > 2. Move RandomStringUtils class to commons-text. > 3. Remove all existing code from methods of RandomStringUtils and call our > brand new RandomStringGenerator in them. to return respective values i.e. > randomNumeric, randomAlphabetic, randomAlphanumeric etc -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NUMBERS-50) Clean checkstyle for Complex
[ https://issues.apache.org/jira/browse/NUMBERS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16275413#comment-16275413 ] Amey Jadiye commented on NUMBERS-50: I'm sorry for being not descriptive, the only issues I found was in *target* of the complex other suppressions are valid and copied from commons text. so I would say there is no valid issues which are suppressed. > Clean checkstyle for Complex > > > Key: NUMBERS-50 > URL: https://issues.apache.org/jira/browse/NUMBERS-50 > Project: Commons Numbers > Issue Type: Bug >Reporter: Eric Barnhill >Priority: Trivial > > Clean up trailing whitespaces and other checkstyle violations in > commons-numbers-complex -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NUMBERS-50) Clean checkstyle for Complex
[
https://issues.apache.org/jira/browse/NUMBERS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16276012#comment-16276012
]
Amey Jadiye commented on NUMBERS-50:
bq. Do you mean in directory commons-numbers-complex/target?
Yes, I was checking checkstyle error for only complex for now, for limitting
scope of this jira.
bq. When I call mvn site, CheckStyle does not report anything there! How do you
call the report generation in order to get a different result?
I have changed two lines in pom.xml
{{truetrue}}
not sure if you also did this on your local machine? I'm simply executing
{{mvn clean verify checkstyle:check}} here. afer this change I can't call {{mvn
site}} thats also failing. below is the short snip with reason. after adding
target to suppression I'm able to build complex clean.
{code}
[INFO] --- maven-checkstyle-plugin:2.17:check (default-cli) @
commons-numbers-complex ---
[INFO] There is 1 error reported by Checkstyle 6.11.2 with
/home/amey/work/opensource/apache/commons/commons-numbers/commons-numbers-complex/../src/main/resources/checkstyle/checkstyle.xml
ruleset.
[ERROR] target/maven-archiver/pom.properties:[1] (header) Header: Missing a
header - not enough lines in file.
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 34.253 s
[INFO] Finished at: 2017-12-03T22:28:15+05:30
[INFO] Final Memory: 37M/453M
[INFO]
{code}
bq. I rather think that we should heed the suggestions from CheckStyle unless
there is a good reason.
Agreed, removed all except target and generated source which is important here,
we dont really target included in checkstyle checks ,I think.
bq. also tend to think that failing the build because of picky rules (like
trailing whitespace) may not be pleasant when developing.
I think enfourcing those rules are good, that cleans the code while developing
it self , atleast I'm in favour of it.
bq. here was a discussion about mandating that contributors should run a
specific command (with options that would then fail the build, namely if
CheckStyle is not happy) before submitting a pull request. But I don't recall
that it has been done.
Yes, I did that in commons-text and its working like charm, enforceing that
makes code clean before merge to trunk. will do that for commons-numbers after
we finish with all the cleanup activities which includes pmd, checkstyle,
findbug, rat etc ...
> Clean checkstyle for Complex
>
>
> Key: NUMBERS-50
> URL: https://issues.apache.org/jira/browse/NUMBERS-50
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Eric Barnhill
>Priority: Trivial
>
> Clean up trailing whitespaces and other checkstyle violations in
> commons-numbers-complex
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NUMBERS-50) Clean checkstyle for Complex
[
https://issues.apache.org/jira/browse/NUMBERS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16302320#comment-16302320
]
Amey Jadiye commented on NUMBERS-50:
bq. No, but it is not necessary to explicitly "suppress" it since running mvn
clean site does not report any error.
This looks very strange to me, curious how {{mvn clean verify}} is failing but
now {{mvn clean site}}
bq. Anyways, it looks like this report can be resolved since as of today there
is no checkstyle violations in the module commons-numbers-complex
hmm, I also feel to close this. one more option is to change the subject and
extend the scope to solve all the checkstyle errors.
> Clean checkstyle for Complex
>
>
> Key: NUMBERS-50
> URL: https://issues.apache.org/jira/browse/NUMBERS-50
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Eric Barnhill
>Priority: Trivial
>
> Clean up trailing whitespaces and other checkstyle violations in
> commons-numbers-complex
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SANDBOX-509) Convert commons-graph Multi Module Maven Project
[ https://issues.apache.org/jira/browse/SANDBOX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amey Jadiye updated SANDBOX-509: Issue Type: Improvement (was: Bug) > Convert commons-graph Multi Module Maven Project > > > Key: SANDBOX-509 > URL: https://issues.apache.org/jira/browse/SANDBOX-509 > Project: Commons Sandbox > Issue Type: Improvement > Components: Graph >Reporter: Amey Jadiye >Priority: Major > > In order to make a further push towards making commons-graph graduate to > proper it's important to make graph multi-module maven project. > based on the common functionality of classes we have to categorize them and > make modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SANDBOX-510) Unit tests failures in recently migrated "Commons Graph"
[ https://issues.apache.org/jira/browse/SANDBOX-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134820#comment-17134820 ] Amey Jadiye commented on SANDBOX-510: - I have tried fixing it with PR [https://github.com/apache/commons-graph/pull/3] please review. > Unit tests failures in recently migrated "Commons Graph" > > > Key: SANDBOX-510 > URL: https://issues.apache.org/jira/browse/SANDBOX-510 > Project: Commons Sandbox > Issue Type: Task > Components: Graph >Reporter: Gilles Sadowski >Priority: Major > Labels: unit-test > > Code has not been worked on for more than 7 years. > A recent spike of interest entailed a move to a [git > repository|https://gitbox.apache.org/repos/asf?p=commons-graph.git]. > [A few unit tests > fail|https://travis-ci.org/github/apache/commons-graph/builds/697810911]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SANDBOX-510) Unit tests failures in recently migrated "Commons Graph"
[
https://issues.apache.org/jira/browse/SANDBOX-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134838#comment-17134838
]
Amey Jadiye commented on SANDBOX-510:
-
{quote}
The error in testSudoku disappears when changing this line to
private Set colors = createColorsList( 13 );
Caveat: I have no idea whether this is the correct fix.
{quote}
Yes, because the greedy algorithm is not so optimized that it will use exactly
9 colors in sudoku, it's able to resolve problem with 13 though.
The backtracking algorithm is optimized to fix sudoku problem with exactly 9
colors, which is expected.
> Unit tests failures in recently migrated "Commons Graph"
>
>
> Key: SANDBOX-510
> URL: https://issues.apache.org/jira/browse/SANDBOX-510
> Project: Commons Sandbox
> Issue Type: Task
> Components: Graph
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: unit-test
>
> Code has not been worked on for more than 7 years.
> A recent spike of interest entailed a move to a [git
> repository|https://gitbox.apache.org/repos/asf?p=commons-graph.git].
> [A few unit tests
> fail|https://travis-ci.org/github/apache/commons-graph/builds/697810911].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SANDBOX-509) Convert commons-graph Multi Module Maven Project
[ https://issues.apache.org/jira/browse/SANDBOX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134848#comment-17134848 ] Amey Jadiye commented on SANDBOX-509: - [~erans], I have this Jira already created for modularization. I will push my changes against it. > Convert commons-graph Multi Module Maven Project > > > Key: SANDBOX-509 > URL: https://issues.apache.org/jira/browse/SANDBOX-509 > Project: Commons Sandbox > Issue Type: Improvement > Components: Graph >Reporter: Amey Jadiye >Priority: Major > > In order to make a further push towards making commons-graph graduate to > proper it's important to make graph multi-module maven project. > based on the common functionality of classes we have to categorize them and > make modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
