[jira] [Work logged] (NUMBERS-119) BigFraction(double) constructor does not treat subnormal numbers correctly
[
https://issues.apache.org/jira/browse/NUMBERS-119?focusedWorklogId=265161&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-265161
]
ASF GitHub Bot logged work on NUMBERS-119:
--
Author: ASF GitHub Bot
Created on: 22/Jun/19 02:32
Start Date: 22/Jun/19 02:32
Worklog Time Spent: 10m
Work Description: Schamschi commented on issue #56: NUMBERS-119: Correct
bug in BigFraction(double) constructor
URL: https://github.com/apache/commons-numbers/pull/56#issuecomment-504619638
Interesting, the code coverage decreased, but not because of the special
case I added for subnormal numbers (this was already covered by a test that
only tested the numerator but not the denominator, which is why the test did
not fail), but because I also made a special case for zero that caused the
denominator of the created fraction to be set to 1 (so that the fraction is
0/1) instead of 2^1075. For some reason, this caused a branch in the method
reduce() not to be executed by tests anymore …
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: 265161)
Time Spent: 0.5h (was: 20m)
> BigFraction(double) constructor does not treat subnormal numbers correctly
> --
>
> Key: NUMBERS-119
> URL: https://issues.apache.org/jira/browse/NUMBERS-119
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The constructor {{BigFraction(double)}} does not take into account the fact
> that, when the biased exponent of a {{double}} value is {{0}} and the
> mantissa is not {{0}} (i.e. when the value represents a subnormal number),
> the actual exponent in effect is not {{-1023}} but {{-1022}} (or, in other
> words, the effective exponent bias is not {{1023}} but {{1022}}).
> The value of the created {{BigFraction}} is therefore not equal to the value
> of the passed {{double}} argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] Schamschi commented on issue #56: NUMBERS-119: Correct bug in BigFraction(double) constructor
Schamschi commented on issue #56: NUMBERS-119: Correct bug in BigFraction(double) constructor URL: https://github.com/apache/commons-numbers/pull/56#issuecomment-504619638 Interesting, the code coverage decreased, but not because of the special case I added for subnormal numbers (this was already covered by a test that only tested the numerator but not the denominator, which is why the test did not fail), but because I also made a special case for zero that caused the denominator of the created fraction to be set to 1 (so that the fraction is 0/1) instead of 2^1075. For some reason, this caused a branch in the method reduce() not to be executed by tests anymore … 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] (NUMBERS-119) BigFraction(double) constructor does not treat subnormal numbers correctly
[
https://issues.apache.org/jira/browse/NUMBERS-119?focusedWorklogId=265154&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-265154
]
ASF GitHub Bot logged work on NUMBERS-119:
--
Author: ASF GitHub Bot
Created on: 22/Jun/19 01:55
Start Date: 22/Jun/19 01:55
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #56: NUMBERS-119: Correct
bug in BigFraction(double) constructor
URL: https://github.com/apache/commons-numbers/pull/56#issuecomment-504617374
[](https://coveralls.io/builds/24142175)
Coverage decreased (-0.03%) to 94.355% when pulling
**f55db5a0bfdb478c6a474f477a867996bbdbe459 on Schamschi:NUMBERS-119** into
**b1daf7ba9b474c2bc480c006cca1816fa401d1a1 on apache:master**.
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: 265154)
Time Spent: 20m (was: 10m)
> BigFraction(double) constructor does not treat subnormal numbers correctly
> --
>
> Key: NUMBERS-119
> URL: https://issues.apache.org/jira/browse/NUMBERS-119
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The constructor {{BigFraction(double)}} does not take into account the fact
> that, when the biased exponent of a {{double}} value is {{0}} and the
> mantissa is not {{0}} (i.e. when the value represents a subnormal number),
> the actual exponent in effect is not {{-1023}} but {{-1022}} (or, in other
> words, the effective exponent bias is not {{1023}} but {{1022}}).
> The value of the created {{BigFraction}} is therefore not equal to the value
> of the passed {{double}} argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] coveralls commented on issue #56: NUMBERS-119: Correct bug in BigFraction(double) constructor
coveralls commented on issue #56: NUMBERS-119: Correct bug in BigFraction(double) constructor URL: https://github.com/apache/commons-numbers/pull/56#issuecomment-504617374 [](https://coveralls.io/builds/24142175) Coverage decreased (-0.03%) to 94.355% when pulling **f55db5a0bfdb478c6a474f477a867996bbdbe459 on Schamschi:NUMBERS-119** into **b1daf7ba9b474c2bc480c006cca1816fa401d1a1 on apache:master**. 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] (NUMBERS-119) BigFraction(double) constructor does not treat subnormal numbers correctly
[
https://issues.apache.org/jira/browse/NUMBERS-119?focusedWorklogId=265151&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-265151
]
ASF GitHub Bot logged work on NUMBERS-119:
--
Author: ASF GitHub Bot
Created on: 22/Jun/19 01:50
Start Date: 22/Jun/19 01:50
Worklog Time Spent: 10m
Work Description: Schamschi commented on pull request #56: NUMBERS-119:
Correct bug in BigFraction(double) constructor
URL: https://github.com/apache/commons-numbers/pull/56
Take care of special exponent bias with subnormal numbers
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: 265151)
Time Spent: 10m
Remaining Estimate: 0h
> BigFraction(double) constructor does not treat subnormal numbers correctly
> --
>
> Key: NUMBERS-119
> URL: https://issues.apache.org/jira/browse/NUMBERS-119
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The constructor {{BigFraction(double)}} does not take into account the fact
> that, when the biased exponent of a {{double}} value is {{0}} and the
> mantissa is not {{0}} (i.e. when the value represents a subnormal number),
> the actual exponent in effect is not {{-1023}} but {{-1022}} (or, in other
> words, the effective exponent bias is not {{1023}} but {{1022}}).
> The value of the created {{BigFraction}} is therefore not equal to the value
> of the passed {{double}} argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] Schamschi opened a new pull request #56: NUMBERS-119: Correct bug in BigFraction(double) constructor
Schamschi opened a new pull request #56: NUMBERS-119: Correct bug in BigFraction(double) constructor URL: https://github.com/apache/commons-numbers/pull/56 Take care of special exponent bias with subnormal numbers 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-119) BigFraction(double) constructor does not treat subnormal numbers correctly
Heinrich Bohne created NUMBERS-119:
--
Summary: BigFraction(double) constructor does not treat subnormal
numbers correctly
Key: NUMBERS-119
URL: https://issues.apache.org/jira/browse/NUMBERS-119
Project: Commons Numbers
Issue Type: Bug
Components: fraction
Affects Versions: 1.0
Reporter: Heinrich Bohne
The constructor {{BigFraction(double)}} does not take into account the fact
that, when the biased exponent of a {{double}} value is {{0}} and the mantissa
is not {{0}} (i.e. when the value represents a subnormal number), the actual
exponent in effect is not {{-1023}} but {{-1022}} (or, in other words, the
effective exponent bias is not {{1023}} but {{1022}}).
The value of the created {{BigFraction}} is therefore not equal to the value of
the passed {{double}} argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1490) Percentile computational accuracy issue
[ https://issues.apache.org/jira/browse/MATH-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16869985#comment-16869985 ] Gilles commented on MATH-1490: -- bq. There is a backward compatibility bug behind it. Could you please be more explicit? What is the expected output? > Percentile computational accuracy issue > --- > > Key: MATH-1490 > URL: https://issues.apache.org/jira/browse/MATH-1490 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.4, 3.4.1, 3.5, 3.6, 3.6.1 > Environment: System: Linux testinglab 4.4.0-131-generic > #157~14.04.1-Ubuntu > Java version "1.8.0_191" > Java(TM) SE Runtime Environment (build 1.8.0_191-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) > > >Reporter: Lingchao Chen >Assignee: Rob Tompkins >Priority: Major > Labels: performance > Attachments: BugDemo.java > > > The percentile method works well on the older versions, e.g., the version > before 3.4. However, when I update commons-math to the newer version, there > produces a computational accuracy issue. There is a backward compatibility > bug behind it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-vfs] garydgregory commented on issue #30: VFS-614 MonitorInputStream should not close the stream in "read"
garydgregory commented on issue #30: VFS-614 MonitorInputStream should not close the stream in "read" URL: https://github.com/apache/commons-vfs/pull/30#issuecomment-504612443 I do not have specific plans for a release but I see that we have a lot of changes pending in changes.xml, so I hope to get around to it in the next couple of weeks. There are other Commons components I'd like to release as well. 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] (LOGGING-166) Log4J2 Wrapper Class
Igor Kriznar created LOGGING-166: Summary: Log4J2 Wrapper Class Key: LOGGING-166 URL: https://issues.apache.org/jira/browse/LOGGING-166 Project: Commons Logging Issue Type: New Feature Reporter: Igor Kriznar Attachments: Log4J2Logger.java Hi, I am contributing wrapper for Log4J 2. Works for me. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1386) Ambiguous method call error when using BooleanUtils.and
[ https://issues.apache.org/jira/browse/LANG-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16869933#comment-16869933 ] Tomáš Mrázek commented on LANG-1386: SO answer does provide easy workaround, but that's no longer true for Java 9 and higher, where Boolean constructor is deprecated. Static alternative Boolean.valueOf() does raise ambiguous errors. We can use deprecated object constructor or primitive constructor. Either way there is no need for keeping both method calls. Autoboxing was introduced in Java 1.5, so removing primitive or object method call for and / xor / or operations would break backwards compatibility for Java 1.4 and lower. > Ambiguous method call error when using BooleanUtils.and > --- > > Key: LANG-1386 > URL: https://issues.apache.org/jira/browse/LANG-1386 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.4 >Reporter: Kapil Koju >Priority: Minor > Attachments: BooleanUtils.and javadoc.png, Wrapper Boolean and.png, > literal boolean and.png, possible use case.png > > > When using `BooleanUtils.and` as per described in the method's javadoc, > ambiguous method call error is thrown. I'm using version 3.4 with Java 8. > Here's a StackOverflow question related to this issue. > [https://stackoverflow.com/q/49252638/1433665] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-csv] garydgregory commented on issue #46: added ignoreQuoteInToken support to ignore quotes in strings
garydgregory commented on issue #46: added ignoreQuoteInToken support to ignore quotes in strings URL: https://github.com/apache/commons-csv/pull/46#issuecomment-504582809 @ranjithrp , You'll need to provide unit tests so we can clearly assess what it is you are trying to achieve. Thank you, Gary 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] coveralls commented on issue #46: added ignoreQuoteInToken support to ignore quotes in strings
coveralls commented on issue #46: added ignoreQuoteInToken support to ignore quotes in strings URL: https://github.com/apache/commons-csv/pull/46#issuecomment-504546849 [](https://coveralls.io/builds/24136490) Coverage decreased (-0.2%) to 92.618% when pulling **ad01ee10977550e226fff4b968b49105fe34170a on ranjithrp:master** into **7754cd4c84299e72043067501d2965f55e7ff769 on apache:master**. 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] coveralls commented on issue #46: added ignoreQuoteInToken support to ignore quotes in strings
coveralls commented on issue #46: added ignoreQuoteInToken support to ignore quotes in strings URL: https://github.com/apache/commons-csv/pull/46#issuecomment-504546824 [](https://coveralls.io/builds/24136490) Coverage decreased (-0.2%) to 92.618% when pulling **ad01ee10977550e226fff4b968b49105fe34170a on ranjithrp:master** into **7754cd4c84299e72043067501d2965f55e7ff769 on apache:master**. 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] ranjithrp opened a new pull request #46: added ignoreQuoteInToken support to ignore quotes in strings
ranjithrp opened a new pull request #46: added ignoreQuoteInToken support to ignore quotes in strings URL: https://github.com/apache/commons-csv/pull/46 added ignoreQuoteInToken support to ignore quotes in strings even when there are few encapsulatedTokens with comma within. This will help in parsing csv values like abc,"xyz" 123 bar,3,11961034,"First author, Second Author" 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] (NUMBERS-118) Reduce code duplication between BigFractionTest and FractionTest
[
https://issues.apache.org/jira/browse/NUMBERS-118?focusedWorklogId=264709&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-264709
]
ASF GitHub Bot logged work on NUMBERS-118:
--
Author: ASF GitHub Bot
Created on: 21/Jun/19 15:08
Start Date: 21/Jun/19 15:08
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #55: [NUMBERS-118] Reduce
code duplication between FractionTest and BigFractionTest
URL: https://github.com/apache/commons-numbers/pull/55#issuecomment-504460753
[](https://coveralls.io/builds/24131605)
Coverage remained the same at 94.381% when pulling
**e3acdf2962b33e89a93d2e0e28fab58b56b738bc on Schamschi:NUMBERS-118** into
**b1daf7ba9b474c2bc480c006cca1816fa401d1a1 on apache:master**.
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: 264709)
Time Spent: 20m (was: 10m)
> Reduce code duplication between BigFractionTest and FractionTest
>
>
> Key: NUMBERS-118
> URL: https://issues.apache.org/jira/browse/NUMBERS-118
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Apparently, the class {{BigFractionTest}} has been created mainly by
> copy-pasting {{FractionTest}}, resulting in a lot of duplicate test cases.
> This code duplication can be mitigated by extracting some of the test cases
> that are used by both classes to a single location.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] coveralls commented on issue #55: [NUMBERS-118] Reduce code duplication between FractionTest and BigFractionTest
coveralls commented on issue #55: [NUMBERS-118] Reduce code duplication between FractionTest and BigFractionTest URL: https://github.com/apache/commons-numbers/pull/55#issuecomment-504460753 [](https://coveralls.io/builds/24131605) Coverage remained the same at 94.381% when pulling **e3acdf2962b33e89a93d2e0e28fab58b56b738bc on Schamschi:NUMBERS-118** into **b1daf7ba9b474c2bc480c006cca1816fa401d1a1 on apache:master**. 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] (NUMBERS-118) Reduce code duplication between BigFractionTest and FractionTest
[
https://issues.apache.org/jira/browse/NUMBERS-118?focusedWorklogId=264652&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-264652
]
ASF GitHub Bot logged work on NUMBERS-118:
--
Author: ASF GitHub Bot
Created on: 21/Jun/19 14:00
Start Date: 21/Jun/19 14:00
Worklog Time Spent: 10m
Work Description: Schamschi commented on pull request #55: [NUMBERS-118]
Reduce code duplication between FractionTest and BigFractionTest
URL: https://github.com/apache/commons-numbers/pull/55
This pull request does _not_ conflict with [PR
#52](https://github.com/apache/commons-numbers/pull/52).
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: 264652)
Time Spent: 10m
Remaining Estimate: 0h
> Reduce code duplication between BigFractionTest and FractionTest
>
>
> Key: NUMBERS-118
> URL: https://issues.apache.org/jira/browse/NUMBERS-118
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Apparently, the class {{BigFractionTest}} has been created mainly by
> copy-pasting {{FractionTest}}, resulting in a lot of duplicate test cases.
> This code duplication can be mitigated by extracting some of the test cases
> that are used by both classes to a single location.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] Schamschi opened a new pull request #55: [NUMBERS-118] Reduce code duplication between FractionTest and BigFractionTest
Schamschi opened a new pull request #55: [NUMBERS-118] Reduce code duplication between FractionTest and BigFractionTest URL: https://github.com/apache/commons-numbers/pull/55 This pull request does _not_ conflict with [PR #52](https://github.com/apache/commons-numbers/pull/52). 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-118) Reduce code duplication between BigFractionTest and FractionTest
Heinrich Bohne created NUMBERS-118:
--
Summary: Reduce code duplication between BigFractionTest and
FractionTest
Key: NUMBERS-118
URL: https://issues.apache.org/jira/browse/NUMBERS-118
Project: Commons Numbers
Issue Type: Improvement
Components: fraction
Affects Versions: 1.0
Reporter: Heinrich Bohne
Apparently, the class {{BigFractionTest}} has been created mainly by
copy-pasting {{FractionTest}}, resulting in a lot of duplicate test cases. This
code duplication can be mitigated by extracting some of the test cases that are
used by both classes to a single location.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (RNG-16) Linear congruential generators
[ https://issues.apache.org/jira/browse/RNG-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16865548#comment-16865548 ] Abhishek Singh Dhadwal edited comment on RNG-16 at 6/21/19 12:34 PM: - Hello, I shall be working on the task at hand. Upon discussion with Gilles and Alex Herbert, following are the details about the plan for implementation of the RNG. There shall be a base abstract class (AbstractLCG) which shall take inputs of a,c,m and the seed and return integer values as required. There shall be a child class (KnuthLewisLCG) which shall extend the aforementioned class with the values of a, c and m referred from [Numerical Recipes |https://en.wikipedia.org/wiki/Linear_congruential_generator#Parameters_in_common_use] The current questions/queries at hand are : * Will it pass the test suite? * Can using modulo 2^32 increase performance (to be tested using JMH) * Comparison between KnuthLewisDirect and the aforementioned child class The github repository where I will be working currently is : [https://github.com/AbhishekSinghDhadwal/commons-rng/tree/lcg] The test values (hexadecimal) obtained as per numerical recipes ( for seed = 0) are as follows : 3c6ef35f 47502932 d1ccf6e9 aaf95334 6252e503 9f2ec686 57fe6c2d a3d95fa8 81fdbee7 94f0af1a The generator should match these values. was (Author: abhi1507): Hello, I shall be working on the task at hand. Upon discussion with Gilles and Alex Herbert, following are the details about the plan for implementation of the RNG. There shall be a base abstract class (AbstractLCG) which shall take inputs of a,c,m and the seed and return integer values as required. There shall be a child class (KnuthLewisLCG) which shall extend the aforementioned class with the values of a, c and m referred from [Numerical Recipes |https://en.wikipedia.org/wiki/Linear_congruential_generator#Parameters_in_common_use] The current questions/queries at hand are : * Will it pass the test suite? * Can using modulo 2^32 increase performance (to be tested using JMH) * Comparison between KnuthLewisDirect and the aforementioned child class The github repository where I will be working currently is : [https://github.com/AbhishekSinghDhadwal/commons-rng] The test values (hexadecimal) obtained as per numerical recipes ( for seed = 0) are as follows : 3c6ef35f 47502932 d1ccf6e9 aaf95334 6252e503 9f2ec686 57fe6c2d a3d95fa8 81fdbee7 94f0af1a The generator should match these values. > Linear congruential generators > -- > > Key: RNG-16 > URL: https://issues.apache.org/jira/browse/RNG-16 > Project: Commons RNG > Issue Type: Sub-task >Reporter: Emmanuel Bourg >Priority: Minor > Labels: gsoc2019 > > This is a RFE for implementing linear congruential generators: > https://en.wikipedia.org/wiki/Linear_congruential_generator > This type of random generator is often used in language runtimes (Borland C, > GCC, Delphi, VB and even Java). Preconfigured generators using the same > parameters as these languages would be convenient for reproducing the same > number sequences in Java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IMAGING-168) IPTC parser should use CodedCharacterSet tag to determine encoding of the IPTC tag values
[ https://issues.apache.org/jira/browse/IMAGING-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16869328#comment-16869328 ] Bruno P. Kinoshita commented on IMAGING-168: Hi [~janArbeit] Just had a look at the pull request, and it was not merged due to pending issues in the current code. Once addressed, I would be keen to review, merge, and include in the next release. The reason for this hiatus, was probably that others got busy with other projects. I was busy trying my best to get a 1.0 release as soon as possible... but it took much longer than I expected due to issues in the code, discussion in the dev-mailing-list about what needed to change, then the need to address the feedback from the mailing list, and finally we had 2 CVE's that blocked the 1.0 release. Now that we have 1.0-alpha1, the next release should be much easier to get out. But sorry for the delay. Let me know if you would be interested in working on this issue and perhaps reviewing that PR or submitting a new one. I am currently overseas in the antipodes, with not much time to work on OSS and a bit of jet-lag. So I probably won't be active writing code for the project until mid-July, but happy to review PR's and reply e-mail/Jira. Bruno > IPTC parser should use CodedCharacterSet tag to determine encoding of the > IPTC tag values > - > > Key: IMAGING-168 > URL: https://issues.apache.org/jira/browse/IMAGING-168 > Project: Commons Imaging > Issue Type: Bug > Components: Format: JPEG >Reporter: sudeep khemka >Priority: Major > Fix For: Review Patch > > Attachments: codedCharacterSet.patch > > > The IPTC CodedCharacterSet tag can be used to specify the encoding of the > IPTC tag values. But the setting is currently ignored. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IMAGING-168) IPTC parser should use CodedCharacterSet tag to determine encoding of the IPTC tag values
[ https://issues.apache.org/jira/browse/IMAGING-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16869290#comment-16869290 ] Jan Wittig commented on IMAGING-168: Looks like there is a solution in the patch, but minor details prevented the pull. Why did this issue freeze two years ago? Can't believe hard coded latin support is ignored for such a long time, where attributes exist defining the encoding... > IPTC parser should use CodedCharacterSet tag to determine encoding of the > IPTC tag values > - > > Key: IMAGING-168 > URL: https://issues.apache.org/jira/browse/IMAGING-168 > Project: Commons Imaging > Issue Type: Bug > Components: Format: JPEG >Reporter: sudeep khemka >Priority: Major > Fix For: Review Patch > > Attachments: codedCharacterSet.patch > > > The IPTC CodedCharacterSet tag can be used to specify the encoding of the > IPTC tag values. But the setting is currently ignored. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
