[jira] [Commented] (GEOMETRY-29) Plane API cleanup
[
https://issues.apache.org/jira/browse/GEOMETRY-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843580#comment-16843580
]
Matt Juntunen commented on GEOMETRY-29:
---
[~erans], can you please merge this PR? I'm going to need to use it very soon.
> Plane API cleanup
> -
>
> Key: GEOMETRY-29
> URL: https://issues.apache.org/jira/browse/GEOMETRY-29
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> The following changes should be made to the
> {{o.a.c.g.euclidean.threed.Plane}} class:
> * make the class immutable
> * use well-named factory methods instead of constructor overloads
> * provide a factory method to create a plane with user-supplied {{u}} and
> {{v}} axes. The current implementation allows the normal to be provided but
> chooses its own planar axes (see {{setFrame}}).
> * add {{equals}}, {{hashCode}}, and {{toString}} methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843579#comment-16843579 ] Dave Moten commented on CSV-239: Can I suggest that you make an immutable list (using Collections.unmodifiableList) in CSVParser and return that same object every call to getHeaderNames. Saves allocations due the defensive copy. > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843577#comment-16843577 ] Dave Moten commented on CSV-239: Ah, you've added a getCSVParser method. I'd just call it getParser for readability. > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843566#comment-16843566 ] Gary Gregory commented on CSV-239: -- In retrospect, I should have done this in a branch. Please see git master for the redo. > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843556#comment-16843556 ] Dave Moten commented on CSV-239: Yes, I think the reference back to CSVParser is a good idea. > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843538#comment-16843538 ] Gary Gregory edited comment on CSV-239 at 5/19/19 8:44 PM: --- Alternatively, we could add getHeaderNames() to CSVParser and drop it completely from CSVRecord. That would make the information available, just not on each record. Thoughts? There is no hard-core process. For contributors, it is nicer for us to get contributions through GitHub. We could also replace both headerMap and headerNames with a pointer back to the parser. was (Author: garydgregory): Alternatively, we could add getHeaderNames() to CSVParser and drop it completely from CSVRecord. That would make the information available, just not on each record. Thoughts? There is no hard-core process. For contributors, it is nicer for us to get contributions through GitHub. > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-99) Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
[
https://issues.apache.org/jira/browse/NUMBERS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843542#comment-16843542
]
Gilles commented on NUMBERS-99:
---
bq. code in the test class was already not following the guidelines you
mentioned here, and should therefore be rewritten?
Yes.
Refactoring primarily focused on making modules; but tests were ported with
minimal changes.
bq. I tried to follow the style of the other tests
Sure, but this class is quite old (in "Commons Math"); and the standard has
risen ;-). Better follow [this test
class|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-quaternion/src/test/java/org/apache/commons/numbers/quaternion/QuaternionTest.java],
for example.
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
>
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843538#comment-16843538 ] Gary Gregory commented on CSV-239: -- Alternatively, we could add getHeaderNames() to CSVParser and drop it completely from CSVRecord. That would make the information available, just not on each record. Thoughts? There is no hard-core process. For contributors, it is nicer for us to get contributions through GitHub. > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843536#comment-16843536 ] Dave Moten commented on CSV-239: Thanks! I see headerNames is created once in CVSParser and a field added to CVSRecord. The additional field in CVSRecord will have an effect on allocation pressure (e.g when parsing a very big file). Given that getHeaderNames returns a copy anyway perhaps you could build it on demand from the mapping object? Also you don't need to sort because you already have the position of the columns. Just fill an array according to the position in the map. I also see the change in createHeaders of a LinkedHashMap to a TreeSet and the return of a LinkedHashMap copy in CVSRecord.toMap. if this is an attempt to make the entries iterable in column order it doesn't work! TreeSets order on key value (header name) for starters. Btw, would be easier to review if in a PR on GitHub repo. Is that not normal practice for this project? > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COMPRESS-485) Reproducible Builds: keep entries order when gathering ScatterZipOutputStream content in ParallelScatterZipCreator
[ https://issues.apache.org/jira/browse/COMPRESS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated COMPRESS-485: --- Fix Version/s: 1.19 > Reproducible Builds: keep entries order when gathering ScatterZipOutputStream > content in ParallelScatterZipCreator > -- > > Key: COMPRESS-485 > URL: https://issues.apache.org/jira/browse/COMPRESS-485 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.18 >Reporter: Hervé Boutemy >Priority: Major > Fix For: 1.19 > > Time Spent: 2h > Remaining Estimate: 0h > > currently, zip files created using ParallelScatterZipCreator have random > order. > This is causing issues when trying to do Reproducible Builds with Maven > MNG-6276 > Studying ParallelScatterZipCreator, entries are kept sorted in memory in > futures list: instead of writing each full scatter in sequence, iterating > over futures should permit to write each zip entry in original order, without > changing the API or any performance of the gathering process -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CSV-239) Cannot get headers in column order from CSVRecord
[
https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843448#comment-16843448
]
Gary Gregory edited comment on CSV-239 at 5/19/19 2:28 PM:
---
Please see git master or a SNAPSHOT
(https://repository.apache.org/content/repositories/snapshots/) for the new
method {{org.apache.commons.csv.CSVRecord.getHeaderNames()}}.
was (Author: garydgregory):
Please see git master or a SNAPSHOT for the new method
{{org.apache.commons.csv.CSVRecord.getHeaderNames()}}.
> Cannot get headers in column order from CSVRecord
> -
>
> Key: CSV-239
> URL: https://issues.apache.org/jira/browse/CSV-239
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.6
>Reporter: Dave Moten
>Priority: Minor
>
> I have a use case where I read many lines from an arbitrary csv file with a
> given CSVFormat as List, transform that list and then want to
> write the transformed list to another file.
> When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the
> headers from the first line are available in the CSVRecord object via the
> CSVRecord.toMap object but their column positions are not (the iteration of
> the returned map does not reflect column order). Consequently I cannot write
> a header line in the correct order to the output csv file (which I do when
> the first CSVRecord is to be written).
> Another option would be to be to ensure that the CSVPrinter object writes the
> header on the first call to CSVPrinter.printRecord but we should also be able
> to cover the user case where we are writing to a non-csv format and we still
> want to write the headers in the correct order.
> My preference at minimum is that the headers with column order are available
> from CSVRecord (after all the data to supply this is already present in
> CVSRecord). The addition of a method `getHeaders` returning a `List`
> would do the job. I'm happy to submit a PR if desired.
> I've marked this as of minor importance but I think it's a pretty important
> flaw in the library at the moment that prevents event the simplest of
> round-trip (read then write) scenarios when the headers are read from the
> file rather than known up-front.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[
https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843448#comment-16843448
]
Gary Gregory commented on CSV-239:
--
Please see git master or a SNAPSHOT for the new method
{{org.apache.commons.csv.CSVRecord.getHeaderNames()}}.
> Cannot get headers in column order from CSVRecord
> -
>
> Key: CSV-239
> URL: https://issues.apache.org/jira/browse/CSV-239
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.6
>Reporter: Dave Moten
>Priority: Minor
>
> I have a use case where I read many lines from an arbitrary csv file with a
> given CSVFormat as List, transform that list and then want to
> write the transformed list to another file.
> When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the
> headers from the first line are available in the CSVRecord object via the
> CSVRecord.toMap object but their column positions are not (the iteration of
> the returned map does not reflect column order). Consequently I cannot write
> a header line in the correct order to the output csv file (which I do when
> the first CSVRecord is to be written).
> Another option would be to be to ensure that the CSVPrinter object writes the
> header on the first call to CSVPrinter.printRecord but we should also be able
> to cover the user case where we are writing to a non-csv format and we still
> want to write the headers in the correct order.
> My preference at minimum is that the headers with column order are available
> from CSVRecord (after all the data to supply this is already present in
> CVSRecord). The addition of a method `getHeaders` returning a `List`
> would do the job. I'm happy to submit a PR if desired.
> I've marked this as of minor importance but I think it's a pretty important
> flaw in the library at the moment that prevents event the simplest of
> round-trip (read then write) scenarios when the headers are read from the
> file rather than known up-front.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-99) Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
[
https://issues.apache.org/jira/browse/NUMBERS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843441#comment-16843441
]
Heinrich Bohne commented on NUMBERS-99:
---
Regarding your point about multiple test methods: Do you mean the fact that
{{FractionTest.testAdd()}} now tests both {{Fraction.add(Fraction)}} and
{{Fraction.add(int)}}, and that it would be more appropriate to create a
separate test method for {{Fraction.add(int)}}? The reason I didn't do it this
way was that the method {{FractionTest.testAdd()}} already contained a section
where {{Fraction.add(int)}} was tested among all the other tests of
{{Fraction.add(Fraction)}}, so I thought the test would belong there.
The same applies to the test where an exception is expected. I tried to follow
the style of the other tests where an exception is expected (which are present
in abundance, and they all swallow the exception without the test method being
annotated as you describe). So if I understand you correctly, the code in the
test class was already not following the guidelines you mentioned here, and
should therefore be rewritten?
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
>
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-99) Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
[
https://issues.apache.org/jira/browse/NUMBERS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843419#comment-16843419
]
Gilles commented on NUMBERS-99:
---
Thanks for the contribution.
However, with new contributions, we try to improve readability; a.o. things,
unit test methods should strive to focus on single checks. I.e. if several
conditions must be checked for, say, the "add" method, multiple test methods
should be defined: {{testAdd1()}}, {{testAdd2()}}, ...
And those where an exception is expected to be thrown should be annotated:
{code:java}
@Test(expected=SomeException.class)
{code}
rather than having an explicit {{catch}} in the test method.
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
>
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (NUMBERS-99) Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
[
https://issues.apache.org/jira/browse/NUMBERS-99?focusedWorklogId=244657=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-244657
]
ASF GitHub Bot logged work on NUMBERS-99:
-
Author: ASF GitHub Bot
Created on: 19/May/19 12:36
Start Date: 19/May/19 12:36
Worklog Time Spent: 10m
Work Description: Schamschi commented on pull request #34: [NUMBERS-99]
Implement integer overflow checks
URL: https://github.com/apache/commons-numbers/pull/34
Guard Fraction.add(int) and Fraction.subtract(int) against integer overflow
and add some unit tests.
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: 244657)
Time Spent: 10m
Remaining Estimate: 0h
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
>
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] Schamschi opened a new pull request #34: [NUMBERS-99] Implement integer overflow checks
Schamschi opened a new pull request #34: [NUMBERS-99] Implement integer overflow checks URL: https://github.com/apache/commons-numbers/pull/34 Guard Fraction.add(int) and Fraction.subtract(int) against integer overflow and add some unit tests. 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] [Created] (NUMBERS-99) Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
Heinrich Bohne created NUMBERS-99:
-
Summary: Fraction.add(int) and Fraction.subtract(int) ignore risk
of integer overflow
Key: NUMBERS-99
URL: https://issues.apache.org/jira/browse/NUMBERS-99
Project: Commons Numbers
Issue Type: Bug
Components: fraction
Reporter: Heinrich Bohne
The methods {{add(int)}} and {{subtract(int)}} in the class
{{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ + 1)/2,
so the numerator overflows an {{int}}, but when calculated with
{{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
