[jira] [Commented] (MATH-1509) Implement the MiniBatchKMeansClusterer
[ https://issues.apache.org/jira/browse/MATH-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018816#comment-17018816 ] Chen Tao commented on MATH-1509: [~erans] I have change the problem you mentioned. And I sended email to the dev-ML twice, but received nothing(I subscribed the dev-ML and can receive other emails). > Implement the MiniBatchKMeansClusterer > -- > > Key: MATH-1509 > URL: https://issues.apache.org/jira/browse/MATH-1509 > Project: Commons Math > Issue Type: New Feature >Reporter: Chen Tao >Priority: Major > Attachments: compare.png > > > MiniBatchKMeans is a fast clustering algorithm, > which use partial points in initialize cluster centers, and mini batch in > training iterations. > It can finish in few seconds on clustering millions of data, and has few > differences between KMeans. > I have implemented it by Kotlin in my own project, and I'd like to contribute > the code to Apache Commons Math, of course in java. > My implemention is base on Apache Commons Math3, refer to Python > sklearn.cluster.MiniBatchKMeans > Thought test I found it works well on intensive data, significant performance > improvement and return value has few difference to KMeans++, but has many > difference on sparse data. > > Below is the comparation of my implemention and KMeansPlusPlusClusterer > !compare.png! > > I have created a pull request on > [https://github.com/apache/commons-math/pull/117], for reference only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1504) StopWatch: steps feature
[
https://issues.apache.org/jira/browse/LANG-1504?focusedWorklogId=374186=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-374186
]
ASF GitHub Bot logged work on LANG-1504:
Author: ASF GitHub Bot
Created on: 19/Jan/20 03:41
Start Date: 19/Jan/20 03:41
Worklog Time Spent: 10m
Work Description: kinow commented on issue #482: LANG-1504 - Adding steps
feature to StopWatch
URL: https://github.com/apache/commons-lang/pull/482#issuecomment-575963668
Haven't had time to review this change @topera. But
>Note: this is my first try on open source projects, so please sorry if I'm
skipping some important step on the process.
you are doing great, being patient, and trying to express your point :+1:
thanks for that.
It would be great if you fixed the conflicting files in this PR. There are
two files in conflict, see screenshot:
Then wait for Gary's feedback and decide whether to implement your change or
not. But having no conflicts, and the build in Travis passing is
important/useful.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 374186)
Time Spent: 1.5h (was: 1h 20m)
> StopWatch: steps feature
>
>
> Key: LANG-1504
> URL: https://issues.apache.org/jira/browse/LANG-1504
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.time.*
>Reporter: Topera
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Would be great if we could use StopWatch to track times on many places of our
> code.
> I created a new feature called "*steps*".
>
> With this feature we can add label to each step and then get a report with
> time between each step.
>
> Example:
> {code:java}
> final StopWatch watch = new StopWatch();
> watch.step("starting");
> exampleGoSleep();
> watch.step("sleeping");
> exampleGoWalk();
> watch.step("walking ");
> exampleGoDance();
> watch.step("dancing ");
> System.out.println(watch.getStepsReport());
> {code}
> The output would be:
> {noformat}
> [starting] 0ms
> [sleeping] 235ms
> [walking ] 20ms
> [dancing ] 458ms
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] kinow edited a comment on issue #482: LANG-1504 - Adding steps feature to StopWatch
kinow edited a comment on issue #482: LANG-1504 - Adding steps feature to StopWatch URL: https://github.com/apache/commons-lang/pull/482#issuecomment-575963668 Haven't had time to review this change @topera. But >Note: this is my first try on open source projects, so please sorry if I'm skipping some important step on the process. you are doing great, being patient, and trying to express your point :+1: thanks for that. It would be great if you fixed the conflicting files in this PR. There are two files in conflict, see screenshot:  Then wait for Gary's feedback and decide whether to implement your change or not. But having no conflicts, and the build in Travis passing is important/useful. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] kinow commented on issue #482: LANG-1504 - Adding steps feature to StopWatch
kinow commented on issue #482: LANG-1504 - Adding steps feature to StopWatch URL: https://github.com/apache/commons-lang/pull/482#issuecomment-575963668 Haven't had time to review this change @topera. But >Note: this is my first try on open source projects, so please sorry if I'm skipping some important step on the process. you are doing great, being patient, and trying to express your point :+1: thanks for that. It would be great if you fixed the conflicting files in this PR. There are two files in conflict, see screenshot:  This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (LANG-1504) StopWatch: steps feature
[
https://issues.apache.org/jira/browse/LANG-1504?focusedWorklogId=374185=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-374185
]
ASF GitHub Bot logged work on LANG-1504:
Author: ASF GitHub Bot
Created on: 19/Jan/20 03:40
Start Date: 19/Jan/20 03:40
Worklog Time Spent: 10m
Work Description: kinow commented on issue #482: LANG-1504 - Adding steps
feature to StopWatch
URL: https://github.com/apache/commons-lang/pull/482#issuecomment-575963668
Haven't had time to review this change @topera. But
>Note: this is my first try on open source projects, so please sorry if I'm
skipping some important step on the process.
you are doing great, being patient, and trying to express your point :+1:
thanks for that.
It would be great if you fixed the conflicting files in this PR. There are
two files in conflict, see screenshot:
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 374185)
Time Spent: 1h 20m (was: 1h 10m)
> StopWatch: steps feature
>
>
> Key: LANG-1504
> URL: https://issues.apache.org/jira/browse/LANG-1504
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.time.*
>Reporter: Topera
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Would be great if we could use StopWatch to track times on many places of our
> code.
> I created a new feature called "*steps*".
>
> With this feature we can add label to each step and then get a report with
> time between each step.
>
> Example:
> {code:java}
> final StopWatch watch = new StopWatch();
> watch.step("starting");
> exampleGoSleep();
> watch.step("sleeping");
> exampleGoWalk();
> watch.step("walking ");
> exampleGoDance();
> watch.step("dancing ");
> System.out.println(watch.getStepsReport());
> {code}
> The output would be:
> {noformat}
> [starting] 0ms
> [sleeping] 235ms
> [walking ] 20ms
> [dancing ] 458ms
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-71) Investigate Spherical Barycenter Accuracy
[
https://issues.apache.org/jira/browse/GEOMETRY-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018769#comment-17018769
]
Gilles Sadowski commented on GEOMETRY-71:
-
PR #57 merged in commit 9a0b874ad4ccad380e49b92ccad90bc7a634f1d9.
> Investigate Spherical Barycenter Accuracy
> -
>
> Key: GEOMETRY-71
> URL: https://issues.apache.org/jira/browse/GEOMETRY-71
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The current code for computing spherical barycenters in
> {{ConvexArea2S.getBarycenter()}} seems to suffer from floating point accuracy
> issues. The {{ConvexArea2STest.checkBarycenterConsistency()}} method checks
> the consistency of the barycenter computation of a region by splitting the
> region into two sections, computing the area and barycenter of each section,
> and then computing the combined barycenter of the sections by adding the
> barycenter of each scaled by its corresponding area. It is expected that the
> combined barycenter computed in this way should equal the barycenter computed
> for the region as a whole. However, in practice, a large epsilon value is
> needed in the comparison in order for the tests to pass. We need to
> investigate why this is the case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-geometry] asfgit closed pull request #57: GEOMETRY 71: Spherical Barycenter Follow-up
asfgit closed pull request #57: GEOMETRY 71: Spherical Barycenter Follow-up URL: https://github.com/apache/commons-geometry/pull/57 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-geometry] asfgit merged pull request #57: GEOMETRY 71: Spherical Barycenter Follow-up
asfgit merged pull request #57: GEOMETRY 71: Spherical Barycenter Follow-up URL: https://github.com/apache/commons-geometry/pull/57 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (COLLECTIONS-672) There are no List collection with optimized indexOf method.
[ https://issues.apache.org/jira/browse/COLLECTIONS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018766#comment-17018766 ] Chen Guoping edited comment on COLLECTIONS-672 at 1/19/20 2:46 AM: --- Aleksandr Maksymenko Yes, you should. You can commit with a new branch from your master in your github and push a request to the master of apache commons collections . Here is the PRs: https://github.com/apache/commons-collections/pulls was (Author: guoping): Aleksandr Maksymenko Yes, you should. You can commit with a new branch from your master in your github and push a request to the master of apache commons collections . > There are no List collection with optimized indexOf method. > --- > > Key: COLLECTIONS-672 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-672 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Reporter: Aleksandr Maksymenko >Priority: Major > > All known implementations of List are all have O( n ) for indexOf() operation. > Here is my implementation of such List on github which has O(log n) for > indexOf() and contains(): > [https://github.com/masyamandev/indexable-set] > There are two modifications: one implements both List and Set, so it can > contains unique elements, second modification can contains any amount of > unique objects, but it's a bit slower. > It's based on TreeList and provide complexity: > * get by index is O(log n) > * insertion, removing (both by index or by value) are O((log n) * (1 + log > m)) where is amount of elements equals to inserted/removed element. > * insertion, removing are O(log n) if all elements are unique. > * indexOf and lastIndexOf are O(log n). > * contains is O(1) or (log n) depending on Map implementation. > As those collections have complexity similar to TreeSet (at least in cases of > unique elements), overall performance is 20-30% slower due to element > indexing and eliminating some optimizations. However it provides fast indexOf > and contains. > Can I help in porting my code to Apache common Collections library? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1504) StopWatch: steps feature
[
https://issues.apache.org/jira/browse/LANG-1504?focusedWorklogId=374174=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-374174
]
ASF GitHub Bot logged work on LANG-1504:
Author: ASF GitHub Bot
Created on: 19/Jan/20 02:43
Start Date: 19/Jan/20 02:43
Worklog Time Spent: 10m
Work Description: topera commented on issue #482: LANG-1504 - Adding
steps feature to StopWatch
URL: https://github.com/apache/commons-lang/pull/482#issuecomment-575960153
Hello Mr. Gregory,
Thank you for your answer.
I'm also glad that part of my suggestion was already accepted and done on
LANG-1506 (putting labels on the timer)
About your points:
* I agree to use **split** name.
* About **feature creep**, IMHO this is a good feature: with small lines of
code we can make the StopWatch much more useful, mainly to detect performance
bottlenecks on the code.
* Use case: the developer wants to know which operation is slower. He/she
can simply add many split() calls and label then as follow:
```
final StopWatch watch = StopWatch.createStarted();
watch.split("Baking cookies");
...
watch.split("Serving cookies");
...
watch.split("Eating cookies");
...
watch.getSplitReport();
```
The output would be (with or without the percentage indicator)
```
Baking cookies 00:07:00.000 - 70%
Serving 00:01:00.000 - 10%
Eating 00:02:00.000 - 20%
```
If you and other members of the team agrees, I'll proceed with the
implementation.
Note: this is my first try on open source projects, so please sorry if I'm
skipping some important step on the process.
Regards
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 374174)
Time Spent: 1h 10m (was: 1h)
> StopWatch: steps feature
>
>
> Key: LANG-1504
> URL: https://issues.apache.org/jira/browse/LANG-1504
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.time.*
>Reporter: Topera
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Would be great if we could use StopWatch to track times on many places of our
> code.
> I created a new feature called "*steps*".
>
> With this feature we can add label to each step and then get a report with
> time between each step.
>
> Example:
> {code:java}
> final StopWatch watch = new StopWatch();
> watch.step("starting");
> exampleGoSleep();
> watch.step("sleeping");
> exampleGoWalk();
> watch.step("walking ");
> exampleGoDance();
> watch.step("dancing ");
> System.out.println(watch.getStepsReport());
> {code}
> The output would be:
> {noformat}
> [starting] 0ms
> [sleeping] 235ms
> [walking ] 20ms
> [dancing ] 458ms
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] topera commented on issue #482: LANG-1504 - Adding steps feature to StopWatch
topera commented on issue #482: LANG-1504 - Adding steps feature to StopWatch
URL: https://github.com/apache/commons-lang/pull/482#issuecomment-575960153
Hello Mr. Gregory,
Thank you for your answer.
I'm also glad that part of my suggestion was already accepted and done on
LANG-1506 (putting labels on the timer)
About your points:
* I agree to use **split** name.
* About **feature creep**, IMHO this is a good feature: with small lines of
code we can make the StopWatch much more useful, mainly to detect performance
bottlenecks on the code.
* Use case: the developer wants to know which operation is slower. He/she
can simply add many split() calls and label then as follow:
```
final StopWatch watch = StopWatch.createStarted();
watch.split("Baking cookies");
...
watch.split("Serving cookies");
...
watch.split("Eating cookies");
...
watch.getSplitReport();
```
The output would be (with or without the percentage indicator)
```
Baking cookies 00:07:00.000 - 70%
Serving 00:01:00.000 - 10%
Eating 00:02:00.000 - 20%
```
If you and other members of the team agrees, I'll proceed with the
implementation.
Note: this is my first try on open source projects, so please sorry if I'm
skipping some important step on the process.
Regards
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Comment Edited] (COLLECTIONS-672) There are no List collection with optimized indexOf method.
[ https://issues.apache.org/jira/browse/COLLECTIONS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018766#comment-17018766 ] Chen Guoping edited comment on COLLECTIONS-672 at 1/19/20 2:42 AM: --- Aleksandr Maksymenko Yes, you should. You can commit with a new branch from your master in your github and push a request to the master of apache commons collections . was (Author: guoping): Aleksandr Maksymenko Yes, you should. You can commit with a new branch from your master in you github and push a request to the master of apache commons collections . > There are no List collection with optimized indexOf method. > --- > > Key: COLLECTIONS-672 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-672 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Reporter: Aleksandr Maksymenko >Priority: Major > > All known implementations of List are all have O( n ) for indexOf() operation. > Here is my implementation of such List on github which has O(log n) for > indexOf() and contains(): > [https://github.com/masyamandev/indexable-set] > There are two modifications: one implements both List and Set, so it can > contains unique elements, second modification can contains any amount of > unique objects, but it's a bit slower. > It's based on TreeList and provide complexity: > * get by index is O(log n) > * insertion, removing (both by index or by value) are O((log n) * (1 + log > m)) where is amount of elements equals to inserted/removed element. > * insertion, removing are O(log n) if all elements are unique. > * indexOf and lastIndexOf are O(log n). > * contains is O(1) or (log n) depending on Map implementation. > As those collections have complexity similar to TreeSet (at least in cases of > unique elements), overall performance is 20-30% slower due to element > indexing and eliminating some optimizations. However it provides fast indexOf > and contains. > Can I help in porting my code to Apache common Collections library? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-672) There are no List collection with optimized indexOf method.
[ https://issues.apache.org/jira/browse/COLLECTIONS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018766#comment-17018766 ] Chen Guoping commented on COLLECTIONS-672: -- Aleksandr Maksymenko Yes, you should. You can commit with a new branch from your master in you github and push a request to the master of apache commons collections . > There are no List collection with optimized indexOf method. > --- > > Key: COLLECTIONS-672 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-672 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Reporter: Aleksandr Maksymenko >Priority: Major > > All known implementations of List are all have O( n ) for indexOf() operation. > Here is my implementation of such List on github which has O(log n) for > indexOf() and contains(): > [https://github.com/masyamandev/indexable-set] > There are two modifications: one implements both List and Set, so it can > contains unique elements, second modification can contains any amount of > unique objects, but it's a bit slower. > It's based on TreeList and provide complexity: > * get by index is O(log n) > * insertion, removing (both by index or by value) are O((log n) * (1 + log > m)) where is amount of elements equals to inserted/removed element. > * insertion, removing are O(log n) if all elements are unique. > * indexOf and lastIndexOf are O(log n). > * contains is O(1) or (log n) depending on Map implementation. > As those collections have complexity similar to TreeSet (at least in cases of > unique elements), overall performance is 20-30% slower due to element > indexing and eliminating some optimizations. However it provides fast indexOf > and contains. > Can I help in porting my code to Apache common Collections library? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (LANG-1504) StopWatch: steps feature
[
https://issues.apache.org/jira/browse/LANG-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Topera updated LANG-1504:
-
External issue ID: https://issues.apache.org/jira/browse/LANG-1506
Part of this feature was done later on a new task (LANG-1506, by [~ggregory] )
Now we can use label for the timer, but only one label for the entire Timer
"session"
Let's check if this task is still required.
> StopWatch: steps feature
>
>
> Key: LANG-1504
> URL: https://issues.apache.org/jira/browse/LANG-1504
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.time.*
>Reporter: Topera
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Would be great if we could use StopWatch to track times on many places of our
> code.
> I created a new feature called "*steps*".
>
> With this feature we can add label to each step and then get a report with
> time between each step.
>
> Example:
> {code:java}
> final StopWatch watch = new StopWatch();
> watch.step("starting");
> exampleGoSleep();
> watch.step("sleeping");
> exampleGoWalk();
> watch.step("walking ");
> exampleGoDance();
> watch.step("dancing ");
> System.out.println(watch.getStepsReport());
> {code}
> The output would be:
> {noformat}
> [starting] 0ms
> [sleeping] 235ms
> [walking ] 20ms
> [dancing ] 458ms
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-71) Investigate Spherical Barycenter Accuracy
[
https://issues.apache.org/jira/browse/GEOMETRY-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018747#comment-17018747
]
Baljit Singh commented on GEOMETRY-71:
--
Looks good to me!
> Investigate Spherical Barycenter Accuracy
> -
>
> Key: GEOMETRY-71
> URL: https://issues.apache.org/jira/browse/GEOMETRY-71
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The current code for computing spherical barycenters in
> {{ConvexArea2S.getBarycenter()}} seems to suffer from floating point accuracy
> issues. The {{ConvexArea2STest.checkBarycenterConsistency()}} method checks
> the consistency of the barycenter computation of a region by splitting the
> region into two sections, computing the area and barycenter of each section,
> and then computing the combined barycenter of the sections by adding the
> barycenter of each scaled by its corresponding area. It is expected that the
> combined barycenter computed in this way should equal the barycenter computed
> for the region as a whole. However, in practice, a large epsilon value is
> needed in the comparison in order for the tests to pass. We need to
> investigate why this is the case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-80) Rename Transform to AffineTransform
[
https://issues.apache.org/jira/browse/GEOMETRY-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018723#comment-17018723
]
Matt Juntunen commented on GEOMETRY-80:
---
PR is in: https://github.com/apache/commons-geometry/pull/58
This includes changes discussed on the ML.
> Rename Transform to AffineTransform
> ---
>
> Key: GEOMETRY-80
> URL: https://issues.apache.org/jira/browse/GEOMETRY-80
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{Transform}} interface is intended to represent affine transforms only.
> Perhaps, we should then rename this interface to {{AffineTransform}} to
> distinguish it from other transform types (such as projective transforms).
> Pros:
> - Clear, unambiguous name
> - Allows possible use of other transform types later on without naming
> conflicts
> Cons:
> - Name conflicts with {{java.awt.geom.AffineTransform}}
> - I'm not sure if the term "affine" can be used to describe this type of
> transform in spherical space. I've only ever seen it used in discussions
> involving Euclidean space.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEOMETRY-80) Rename Transform to AffineTransform
[
https://issues.apache.org/jira/browse/GEOMETRY-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEOMETRY-80:
---
Labels: pull-request-available (was: )
> Rename Transform to AffineTransform
> ---
>
> Key: GEOMETRY-80
> URL: https://issues.apache.org/jira/browse/GEOMETRY-80
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> The {{Transform}} interface is intended to represent affine transforms only.
> Perhaps, we should then rename this interface to {{AffineTransform}} to
> distinguish it from other transform types (such as projective transforms).
> Pros:
> - Clear, unambiguous name
> - Allows possible use of other transform types later on without naming
> conflicts
> Cons:
> - Name conflicts with {{java.awt.geom.AffineTransform}}
> - I'm not sure if the term "affine" can be used to describe this type of
> transform in spherical space. I've only ever seen it used in discussions
> involving Euclidean space.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-geometry] darkma773r opened a new pull request #58: GEOMETRY-80: Simplify Transform Hierarchy
darkma773r opened a new pull request #58: GEOMETRY-80: Simplify Transform Hierarchy URL: https://github.com/apache/commons-geometry/pull/58 - add inverse() method to Transform interface - rename EuclideanTransform to AffineTransform - remove TransformXD interfaces - add AffineTransformMatrixXD.from(UnaryOperator) factory methods This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (IMAGING-246) Invalid Block Size error prevents handling of block 1084, Macintosh NSPrintInfo
[
https://issues.apache.org/jira/browse/IMAGING-246?focusedWorklogId=374129=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-374129
]
ASF GitHub Bot logged work on IMAGING-246:
--
Author: ASF GitHub Bot
Created on: 18/Jan/20 21:05
Start Date: 18/Jan/20 21:05
Worklog Time Spent: 10m
Work Description: kinow commented on pull request #68: [IMAGING-246] Skip
Photoshop IPTC blocks that are not recommended to be interpreted by parsers in
the specification
URL: https://github.com/apache/commons-imaging/pull/68
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 374129)
Time Spent: 50m (was: 40m)
> Invalid Block Size error prevents handling of block 1084, Macintosh
> NSPrintInfo
> ---
>
> Key: IMAGING-246
> URL: https://issues.apache.org/jira/browse/IMAGING-246
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: Liberty Wollerman
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: FallHarvestKitKat_07610.jpg
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When processing an image created on a Mac with Adobe Photoshop which contains
> embedded metadata having block 1084, an invalid block size error occurs.
> |0x043C|1084|_(Photoshop CS5)_ Macintosh NSPrintInfo. Variable OS specific
> info for Macintosh. NSPrintInfo. It is recommened that you do not interpret
> or use this data.|
>
> Here is some simple test code that replicates what our application is trying
> to do, and recreates the error:
> {code:java}
> import org.apache.commons.imaging.ImageInfo;
> import org.apache.commons.imaging.ImageReadException;
> import org.apache.commons.imaging.Imaging;
> import org.apache.commons.io.FileUtils;
> import java.io.File;
> import java.io.IOException;
> import java.util.Base64;
> public class Main {
> public static void main(String[] args) throws IOException,
> ImageReadException {
> String fileName = "FallHarvestKitKat_07610.jpg";
> ClassLoader classLoader = ClassLoader.getSystemClassLoader();
> File file = new File(classLoader.getResource(fileName).getFile());
> byte[] fileContent = FileUtils.readFileToByteArray(file);
> String encodedString = Base64.getEncoder().encodeToString(fileContent);
> byte[] decodedValue = Base64.getDecoder().decode(encodedString);
> ImageInfo imageInfo = Imaging.getImageInfo(decodedValue);
> }
> }{code}
>
> Here is the resulting error:
> {noformat}
> Exception in thread "main" org.apache.commons.imaging.ImageReadException:
> Invalid Block Size : 89562 > 65504Exception in thread "main"
> org.apache.commons.imaging.ImageReadException: Invalid Block Size : 89562 >
> 65504 at
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parseAllBlocks(IptcParser.java:318)
> at
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:119)
> at
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:112)
> at
>
> org.apache.commons.imaging.formats.jpeg.segments.App13Segment.parsePhotoshopSegment(App13Segment.java:71)
> at
>
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:599)
> at
>
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:318)
> at
>
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:739)
> at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:701) at
> org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:635) at
> Main.getMetaData(Main.java:22) at Main.main(Main.java:17){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IMAGING-246) Invalid Block Size error prevents handling of block 1084, Macintosh NSPrintInfo
[
https://issues.apache.org/jira/browse/IMAGING-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved IMAGING-246.
Resolution: Fixed
> Invalid Block Size error prevents handling of block 1084, Macintosh
> NSPrintInfo
> ---
>
> Key: IMAGING-246
> URL: https://issues.apache.org/jira/browse/IMAGING-246
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha1
>Reporter: Liberty Wollerman
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Attachments: FallHarvestKitKat_07610.jpg
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When processing an image created on a Mac with Adobe Photoshop which contains
> embedded metadata having block 1084, an invalid block size error occurs.
> |0x043C|1084|_(Photoshop CS5)_ Macintosh NSPrintInfo. Variable OS specific
> info for Macintosh. NSPrintInfo. It is recommened that you do not interpret
> or use this data.|
>
> Here is some simple test code that replicates what our application is trying
> to do, and recreates the error:
> {code:java}
> import org.apache.commons.imaging.ImageInfo;
> import org.apache.commons.imaging.ImageReadException;
> import org.apache.commons.imaging.Imaging;
> import org.apache.commons.io.FileUtils;
> import java.io.File;
> import java.io.IOException;
> import java.util.Base64;
> public class Main {
> public static void main(String[] args) throws IOException,
> ImageReadException {
> String fileName = "FallHarvestKitKat_07610.jpg";
> ClassLoader classLoader = ClassLoader.getSystemClassLoader();
> File file = new File(classLoader.getResource(fileName).getFile());
> byte[] fileContent = FileUtils.readFileToByteArray(file);
> String encodedString = Base64.getEncoder().encodeToString(fileContent);
> byte[] decodedValue = Base64.getDecoder().decode(encodedString);
> ImageInfo imageInfo = Imaging.getImageInfo(decodedValue);
> }
> }{code}
>
> Here is the resulting error:
> {noformat}
> Exception in thread "main" org.apache.commons.imaging.ImageReadException:
> Invalid Block Size : 89562 > 65504Exception in thread "main"
> org.apache.commons.imaging.ImageReadException: Invalid Block Size : 89562 >
> 65504 at
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parseAllBlocks(IptcParser.java:318)
> at
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:119)
> at
>
> org.apache.commons.imaging.formats.jpeg.iptc.IptcParser.parsePhotoshopSegment(IptcParser.java:112)
> at
>
> org.apache.commons.imaging.formats.jpeg.segments.App13Segment.parsePhotoshopSegment(App13Segment.java:71)
> at
>
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:599)
> at
>
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:318)
> at
>
> org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:739)
> at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:701) at
> org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:635) at
> Main.getMetaData(Main.java:22) at Main.main(Main.java:17){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] kinow merged pull request #68: [IMAGING-246] Skip Photoshop IPTC blocks that are not recommended to be interpreted by parsers in the specification
kinow merged pull request #68: [IMAGING-246] Skip Photoshop IPTC blocks that are not recommended to be interpreted by parsers in the specification URL: https://github.com/apache/commons-imaging/pull/68 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-collections] kinow commented on issue #83: Initial bloom filter code contribution
kinow commented on issue #83: Initial bloom filter code contribution URL: https://github.com/apache/commons-collections/pull/83#issuecomment-575937004 BTW, almost forgot this one > Perhaps it would make sense to create a SimpleBloomFilter that merges the DynamicHasher and the BitSetBloomFilter and provides methods like the Hadoop Bloom filter. +1 I think that could be simpler, especially for users familiar with existing implementations ([Guava's BloomFilter](https://guava.dev/releases/22.0/api/docs/com/google/common/hash/BloomFilter.html#mightContain-T-) also has a `mightContain(T Object)` method, similar to how Python & Hadoop work) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-csv] garydgregory commented on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames
garydgregory commented on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames URL: https://github.com/apache/commons-csv/pull/43#issuecomment-575934060 @kensixx I kicked off a release vote earlier today. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (COLLECTIONS-672) There are no List collection with optimized indexOf method.
[ https://issues.apache.org/jira/browse/COLLECTIONS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018668#comment-17018668 ] Aleksandr Maksymenko commented on COLLECTIONS-672: -- Can you please describe a little bit how can I do it? I see common collections sources not in GitHub but here: [https://commons.apache.org/proper/commons-collections/scm.html] Should I clone apache repo into my GitHub and make changes there? If so, what should I do next? > There are no List collection with optimized indexOf method. > --- > > Key: COLLECTIONS-672 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-672 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Reporter: Aleksandr Maksymenko >Priority: Major > > All known implementations of List are all have O( n ) for indexOf() operation. > Here is my implementation of such List on github which has O(log n) for > indexOf() and contains(): > [https://github.com/masyamandev/indexable-set] > There are two modifications: one implements both List and Set, so it can > contains unique elements, second modification can contains any amount of > unique objects, but it's a bit slower. > It's based on TreeList and provide complexity: > * get by index is O(log n) > * insertion, removing (both by index or by value) are O((log n) * (1 + log > m)) where is amount of elements equals to inserted/removed element. > * insertion, removing are O(log n) if all elements are unique. > * indexOf and lastIndexOf are O(log n). > * contains is O(1) or (log n) depending on Map implementation. > As those collections have complexity similar to TreeSet (at least in cases of > unique elements), overall performance is 20-30% slower due to element > indexing and eliminating some optimizations. However it provides fast indexOf > and contains. > Can I help in porting my code to Apache common Collections library? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-71) Investigate Spherical Barycenter Accuracy
[
https://issues.apache.org/jira/browse/GEOMETRY-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018601#comment-17018601
]
Matt Juntunen commented on GEOMETRY-71:
---
I just added a follow-up pull request:
https://github.com/apache/commons-geometry/pull/57.
I was able to remove nearly all usages of the {{BARYCENTER_EPS}} value in the
tests, with two exceptions in {{RegionBSPTree2STest}}: one in the computation
of the barycenter of France and the other in the circle test with the very
small radius (0.0001). However, I was able to lower the epsilon value from 1e-2
to 1e-5 so we have a considerably higher level of precision now.
I also updated the barycenter computation in {{RegionBSPTree1S}} to use the
same weighted-barycenter approach as {{RegionBSPTree2S}}. They both now return
null when no _unique_ barycenter exists.
Any objections to closing this issue after this PR is merged?
> Investigate Spherical Barycenter Accuracy
> -
>
> Key: GEOMETRY-71
> URL: https://issues.apache.org/jira/browse/GEOMETRY-71
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The current code for computing spherical barycenters in
> {{ConvexArea2S.getBarycenter()}} seems to suffer from floating point accuracy
> issues. The {{ConvexArea2STest.checkBarycenterConsistency()}} method checks
> the consistency of the barycenter computation of a region by splitting the
> region into two sections, computing the area and barycenter of each section,
> and then computing the combined barycenter of the sections by adding the
> barycenter of each scaled by its corresponding area. It is expected that the
> combined barycenter computed in this way should equal the barycenter computed
> for the region as a whole. However, in practice, a large epsilon value is
> needed in the comparison in order for the tests to pass. We need to
> investigate why this is the case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-geometry] darkma773r opened a new pull request #57: GEOMETRY 71: Spherical Barycenter Follow-up
darkma773r opened a new pull request #57: GEOMETRY 71: Spherical Barycenter Follow-up URL: https://github.com/apache/commons-geometry/pull/57 - adding additional unit tests and documentation for the previously merged spherical barycenter fix - updating RegionBSPTree1S for consistency with RegionBSPTree2S This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-collections] kinow commented on issue #83: Initial bloom filter code contribution
kinow commented on issue #83: Initial bloom filter code contribution URL: https://github.com/apache/commons-collections/pull/83#issuecomment-575885542 Hi @garydgregory Will sync the repository tomorrow morning and try to finish reviewing it (gotta the whole morning to myself, so might be able to finish before noon NZ time). Cheers Bruno This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (TEXT-176) Release Patch 1.8.1
[ https://issues.apache.org/jira/browse/TEXT-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018548#comment-17018548 ] Bruno P. Kinoshita commented on TEXT-176: - Hi [~furkilic] for questions/requests like this, it is better to use the mailing list (users or dev, just use the [text] prefix in your subject). > Release Patch 1.8.1 > --- > > Key: TEXT-176 > URL: https://issues.apache.org/jira/browse/TEXT-176 > Project: Commons Text > Issue Type: Wish >Reporter: Furkan KILIC >Priority: Minor > > Hello > Is it possible to release the patch 1.8.1 as the last release is from > september 2019 and some features/bugfix have been merged since. > Thanks a lot. > Best regards > Furkilic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (TEXT-176) Release Patch 1.8.1
[ https://issues.apache.org/jira/browse/TEXT-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved TEXT-176. - Resolution: Not A Problem > Release Patch 1.8.1 > --- > > Key: TEXT-176 > URL: https://issues.apache.org/jira/browse/TEXT-176 > Project: Commons Text > Issue Type: Wish >Reporter: Furkan KILIC >Priority: Minor > > Hello > Is it possible to release the patch 1.8.1 as the last release is from > september 2019 and some features/bugfix have been merged since. > Thanks a lot. > Best regards > Furkilic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CODEC-264) murmur3.hash128() does not account for unsigned seed argument
[
https://issues.apache.org/jira/browse/CODEC-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018374#comment-17018374
]
Andy Seaborne edited comment on CODEC-264 at 1/18/20 9:27 AM:
--
The v1.14 version of {{hash128(byte[], , int seed)}} does now apply the seed
mask, contrary to the comments.
Line 805
{noformat}
@Deprecated
public static long[] hash128(final byte[] data, final int offset, final int
length, final int seed) {
//
// Note: This fails to apply masking using 0xL to the seed.
//
return hash128x64(data, offset, length, seed);
}
{noformat}
It calls {{hash128x86(byte[],, int seed)}} (exact signature match), not
{{hash128x86(byte[],, long seed)}} (type conversion).
{{hash128x86(byte[],, int seed)}} applies the mask (checked by debugger walk
through in EclipseIDE).
{{hash128(byte[],, int seed)}} should be a call of {{hash128x86(byte[],,
long)}} directly.
I think that casting at the call site will do that:
{noformat}
return hash128x64(data, offset, length, (long)seed);
{noformat}
or for clarity explicitly:
{noformat}
long seedLong = seed; /* unmasked 32->64 bit extension */
return hash128x64(data, offset, length, seedLong);
{noformat}
If the private static work function had a different name, then automatic,
unmasked conversion would have applied.
was (Author: andy.seaborne):
The v1.14 version of {{hash128(byte[], , int seed)}} does now apply the seed
mask, contrary to the comments.
Line 805
{noformat}
@Deprecated
public static long[] hash128(final byte[] data, final int offset, final int
length, final int seed) {
//
// Note: This fails to apply masking using 0xL to the seed.
//
return hash128x64(data, offset, length, seed);
}
{noformat}
It calls {{hash128x86(byte[],, int seed)}} (exact signature match), not
{hash128x86(byte[],, long seed)}} (type conversion).
{{hash128x86(byte[],, int seed)}} applies the mask (checked by debugger walk
through in EclipseIDE).
{{hash128(byte[],, int seed)}} should be a call of {{hash128x86(byte[],,
long)}} directly.
I think that casting at the call site will do that:
{noformat}
return hash128x64(data, offset, length, (long)seed);
{noformat}
or for clarity explicitly:
{noformat}
long seedLong = seed; /* unmasked 32->64 bit extension */
return hash128x64(data, offset, length, seedLong);
{noformat}
If the private static work function had a different name, then automatic,
unmasked conversion would have applied.
> murmur3.hash128() does not account for unsigned seed argument
> -
>
> Key: CODEC-264
> URL: https://issues.apache.org/jira/browse/CODEC-264
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.13
>Reporter: Claude Warren
>Assignee: Alex Herbert
>Priority: Major
> Fix For: 1.14
>
> Attachments: YonikMurmur3Tests.java
>
>
> The original murmur3_x64_128 code used unsigned int for seed arguments.
> Using the equivalent bit patterns in the commons codec version does not yield
> the same results.
> I believe this is because the commons version does not account for sign
> extension etc.
> Yonic Seeley [~yonik] has explains the issue in his implementation
> https://github.com/yonik/java_util/blob/master/src/util/hash/MurmurHash3.java
> He provides a test case to show that his code returns the same answers as the
> original C/C++ code. I modified that test to call the codec version to show
> the error.
> I have attached that test case.
> Given that the original code is in the wild I am uncertain how to fix this
> issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CODEC-264) murmur3.hash128() does not account for unsigned seed argument
[ https://issues.apache.org/jira/browse/CODEC-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018547#comment-17018547 ] Andy Seaborne commented on CODEC-264: - Hi Alex, I've visually inspected the code in git ([commit f5a61f0c|https://github.com/apache/commons-codec/commit/f5a61f0c]) and it looks correct. Thanks / Andy > murmur3.hash128() does not account for unsigned seed argument > - > > Key: CODEC-264 > URL: https://issues.apache.org/jira/browse/CODEC-264 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.13 >Reporter: Claude Warren >Assignee: Alex Herbert >Priority: Major > Fix For: 1.14 > > Attachments: YonikMurmur3Tests.java > > > The original murmur3_x64_128 code used unsigned int for seed arguments. > Using the equivalent bit patterns in the commons codec version does not yield > the same results. > I believe this is because the commons version does not account for sign > extension etc. > Yonic Seeley [~yonik] has explains the issue in his implementation > https://github.com/yonik/java_util/blob/master/src/util/hash/MurmurHash3.java > He provides a test case to show that his code returns the same answers as the > original C/C++ code. I modified that test to call the codec version to show > the error. > I have attached that test case. > Given that the original code is in the wild I am uncertain how to fix this > issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-732) Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()
[
https://issues.apache.org/jira/browse/COLLECTIONS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018537#comment-17018537
]
Bruno P. Kinoshita commented on COLLECTIONS-732:
Just had another look [~Guoping1] , and tested calling super.setValue, and used
your code. It still failed, not with an exception, but an assertion error.
Maybe one of the structures created was not made to be mutated during
iteration, or even mutated at all, not sure. But anyway, IMO, a Javadoc could
be added right away, instead of using the inherited javadoc. Would you be
interested in submitting a PR? Thanks
> Got an UnsupportedOperationException when using
> MultiValuedMap.MapIterator().setValue()
> ---
>
> Key: COLLECTIONS-732
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-732
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Reporter: Chen
>Priority: Major
>
> copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
> {code:java}
> public void testSetValueMapIterator(){
> final ListValuedMap listMap = new
> ArrayListValuedHashMap<>();
> List listA = listMap.get("A");
> listA.addAll(0, Arrays.asList("W", "X", "F"));
> List listB = listMap.get("B");
> listB.addAll(0, Arrays.asList("Q", "Q", "L"));
> assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());
> for(MapIterator iterator = listMap.mapIterator();
> iterator.hasNext(); ){
> iterator.next();
> String value = iterator.getValue();
> if(value == "F"){
> iterator.setValue("B");
> }
> }
> assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
> }
> {code}
> It throws an UnsupportedOperationException when altering
> mapIterator().setValue()。
> I found UnsupportedOperationException is thrown in the code of setValue。So，if
> setValue method is not supported，the Javadoc should comment it。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
