[GitHub] [commons-compress] coveralls commented on pull request #232: Bump org.apache.felix.framework from 7.0.1 to 7.0.3
coveralls commented on pull request #232: URL: https://github.com/apache/commons-compress/pull/232#issuecomment-987553569 [](https://coveralls.io/builds/44807497) Coverage decreased (-0.01%) to 86.332% when pulling **8224b1b6291e94c4045dbabe89a9d8556e28bf89 on dependabot/maven/org.apache.felix-org.apache.felix.framework-7.0.3** into **c8a14ef085a21b276233d4bab09d0d044b01e15d on 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] dependabot[bot] opened a new pull request #232: Bump org.apache.felix.framework from 7.0.1 to 7.0.3
dependabot[bot] opened a new pull request #232: URL: https://github.com/apache/commons-compress/pull/232 Bumps org.apache.felix.framework from 7.0.1 to 7.0.3. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (COMPRESS-596) Mistake in Common Archival Logic code example
[
https://issues.apache.org/jira/browse/COMPRESS-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454360#comment-17454360
]
Peter Lee commented on COMPRESS-596:
Hi [~tamas.mucs]
Thank you for your reporting.
No dought the "out" is not defined here. IMO it should be "o" instead of "out".
Even through the "finish()" is called within "close()", we always explicit call
the "finish()". We did this in our tests, and I want to make it be consistent
here.
And I think "o" is reachable here. :)
> Mistake in Common Archival Logic code example
> -
>
> Key: COMPRESS-596
> URL: https://issues.apache.org/jira/browse/COMPRESS-596
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Tamas Mucs
>Priority: Minor
> Labels: compress, docuentation
>
> There is an error on the documentation on page
> [https://commons.apache.org/proper/commons-compress/examples.html|https://commons.apache.org/proper/commons-compress/examples.html.]
> in section "Common Archival Logic "
> Currently the example code looks like this:
> {code:java}
> Collection filesToArchive = ...
> try (ArchiveOutputStream o = ... create the stream for your format ...) {
> for (File f : filesToArchive) {
> // maybe skip directories for formats like AR that don't store
> directories
> ArchiveEntry entry = o.createArchiveEntry(f, entryName(f));
> // potentially add more flags to entry
> o.putArchiveEntry(entry);
> if (f.isFile()) {
> try (InputStream i = Files.newInputStream(f.toPath())) {
> IOUtils.copy(i, o);
> }
> }
> o.closeArchiveEntry();
> }
> out.finish();
> } {code}
> The variable "out" is not defined anywhere. Supposedly it is the variable "o"
> of type ArchiveOutputStream. However it might be redundant to call "finish()"
> since try-with-resources will implicitly call it via the close() method. Also
> "o" is not reachable in that context.
>
> Proposed solution: remove "out".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-bcel] dependabot[bot] closed pull request #106: Bump biz.aQute.bndlib from 5.3.0 to 6.0.0
dependabot[bot] closed pull request #106: URL: https://github.com/apache/commons-bcel/pull/106 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-bcel] dependabot[bot] opened a new pull request #111: Bump biz.aQute.bndlib from 5.3.0 to 6.1.0
dependabot[bot] opened a new pull request #111: URL: https://github.com/apache/commons-bcel/pull/111 Bumps [biz.aQute.bndlib](https://github.com/bndtools/bnd) from 5.3.0 to 6.1.0. Release notes Sourced from https://github.com/bndtools/bnd/releases;>biz.aQute.bndlib's releases. Bnd/Bndtools 6.1.0 See https://github.com/bndtools/bnd/wiki/Changes-in-6.1.0;>Release Notes. Bnd/Bndtools 6.0.0 See https://github.com/bndtools/bnd/wiki/Changes-in-6.0.0;>Release Notes. Commits See full diff in https://github.com/bndtools/bnd/commits/6.1.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-bcel] dependabot[bot] commented on pull request #106: Bump biz.aQute.bndlib from 5.3.0 to 6.0.0
dependabot[bot] commented on pull request #106: URL: https://github.com/apache/commons-bcel/pull/106#issuecomment-987114116 Superseded by #111. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NUMBERS-177) Scaled complementary error function
[
https://issues.apache.org/jira/browse/NUMBERS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454141#comment-17454141
]
Alex Herbert commented on NUMBERS-177:
--
I have investigated various ways to compute the scaled complementary error
function. Reference values were computed using the Boost erfc function
evaluated at 128-bit precision when z was within the range of that function
(z<100). The function was updated to remove scaling down by exp(-z*z) to output
the rational function approximation for erfcx(z). Above this value erfcx was
evaluated using the continued fraction for the upper incomplete gamma function
(see [Erfc eq 3|https://mathworld.wolfram.com/Erfc.html]):
{noformat}
erfcx(z) = exp(z*z) * erfc(z)
erfc(z) = Gamma(0.5, z*z) / sqrt(pi)
{noformat}
The current rational function approximation for erfc is valid for the range [4,
28]. Above this value the approximation has increasingly large errors.
I tried a few variations of different continued fractions for erfc. The best of
these was the same upper incomplete gamma function evaluated using 64-bit
precision. However this continued fraction requires a variable number of
iterations to converge (up to 8 for z ~ 28). Attempts to explicitly evaluate
the nth convergent with various number of terms did not provide good error
across the entire range for z [28, 6.71e7].
This paper presents a rational function that is suitable for use up to the
limit:
{noformat}
"Rational Chebyshev approximations for the error function"
by W. J. Cody, Math. Comp., 1969, PP. 631-638.{noformat}
There is a FORTRAN implementation in [SpecFun
erf|https://www.netlib.org/specfun/erf]. I obtained the paper which has the
constants valid for evaluation up to long double precision which was useful for
testing.
I tested the various implementations using random input arguments in the
applicable range. The values were sampled uniformly from the range using the
IEEE 754 64-bit representation of the min and max to sample long values within
the range and then mapped back to a double. Due to the binary representation of
a floating-point number using base 2 this has a limiting distribution of a
log-uniform distribution. When plotted using a log 2 scale the points are
approximately uniform.
The range was split into bins and the maximum and RMS ulp error recorded for
each bin. The following results all used 1e9 points split into 1 bins.
h2. Erfcx
I have tested the rational function provided by Boost and Cody over the
applicable range. It is important to note that the range is split and evaluated
with different rational functions:
||Implementation||Range||
|Boost|[0.5, 1.5], [1.5, 2.5], [2.5, 4.5], [4.5, 28]|
|Cody|[0.5, 4], [4, 6.71e7]|
Here is the max error over the range covered by erfc:
!erfcx.medium.png!
Note:
* The Boost function has clear evidence of the minimax approximation with the
wave form of the error.
* The Cody function is more consistent at z > 4 but the single Cody function
for z < 4 is not as good as the Boost functions at z < 4. Clearly this region
is difficult to evaluate with a single function. The region contains points at
which erfcx(z) = 0.5 (z ~ 0.7689) and also where exp(-z*z) = z (z ~ 0.6529).
* The Boost function error at z ~ 33 is starting to increase rapidly.
There are breaks in the max error line at certain points. This is most evident
for z > 4. This occurs when the value of the function erfcx (which gets smaller
as z increases) moves to the next power of two representation. Thus the
precision of the expected result doubles and the max error measured in absolute
distance is suddenly twice the error when expressed relative to the ULP of a
double.
For reference I have used the constants provided by Cody and evaluated the
function for z in [0.5, 4] using a long double (64-bit mantissa). The max error
is < 0.5 ULP. Thus the function is correct but it is subject to error when
evaluated using double precision. The function tested uses 8 terms for each
polynomial to compute P and Q for the result P/Q. Cody provides rational
approximations using fewer terms with a lower theoretical error bound that is
still sufficient for double precision. I tried these and the results were worse.
At larger z the Boost function is not a good approximation. It has clearly been
optimised for use with z < 28. Here is a plot of the max error for the Cody
function against the continued fraction evaluation.
!erfcx.large.png!
The Cody function maintains good accuracy up to the limit of 6.71e7. It can be
evaluated without iteration of a continued fraction algorithm so will have a
performance gain over using a continued fraction.
h2. Effect on Erfc
The Cody function is suitable for erfcx. I applied the same test to erfc. This
is a simple scaling by exp(-z*z).
!erfc.png!
The results are as expected. At z < 4 the Boost function works better. At z > 4
[jira] [Commented] (POOL-403) GenericKeyedObjectPool getNumActive and getNumIdle Javadoc do not match behaviour
[ https://issues.apache.org/jira/browse/POOL-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454139#comment-17454139 ] Phil Steitz commented on POOL-403: -- This is being picked up from the KeyedObjectPool interface javadoc. I am not sure this is actually a bug. In GKOP, this information is *always* available and it correctly returns 0 when it should. The interface spec allows alternative implementations to return -1 when the info is not available. > GenericKeyedObjectPool getNumActive and getNumIdle Javadoc do not match > behaviour > - > > Key: POOL-403 > URL: https://issues.apache.org/jira/browse/POOL-403 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.11.1 >Reporter: KON-SUN-TACK >Priority: Minor > > In GenericKeyedObjectPool Javadoc, getNumActive(K key) and getNumIdle(K key) > states: > "Returns a negative value if this information is not available." > But it seems they actually return 0 instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (LANG-1172) LocaleUtils.toLocale does not handle extensions
[
https://issues.apache.org/jira/browse/LANG-1172?focusedWorklogId=691221=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-691221
]
ASF GitHub Bot logged work on LANG-1172:
Author: ASF GitHub Bot
Created on: 06/Dec/21 16:58
Start Date: 06/Dec/21 16:58
Worklog Time Spent: 10m
Work Description: c-w commented on a change in pull request #766:
URL: https://github.com/apache/commons-lang/pull/766#discussion_r763190834
##
File path: src/main/java/org/apache/commons/lang3/LocaleUtils.java
##
@@ -248,7 +250,9 @@ private static Locale parseLocale(final String str) {
return new Locale(str);
}
-final String[] segments = str.split("_", -1);
+final String[] segments = str.indexOf(DASH) != -1
+? str.split(String.valueOf(DASH), -1)
Review comment:
All the unit tests still pass with the comparison swapped. I made the
change in 0319d84d1. It's probably the right thing to optimize for the previous
delimiter as that'll be the vast majority of use-cases.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 691221)
Time Spent: 2h 50m (was: 2h 40m)
> LocaleUtils.toLocale does not handle extensions
> ---
>
> Key: LANG-1172
> URL: https://issues.apache.org/jira/browse/LANG-1172
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: David Buhler
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The {{toLocale()}} method is unable to handle locale strings that have custom
> extensions that are completely valid according to the [BCP47
> spec|https://tools.ietf.org/html/bcp47#section-4]. Oracle documentation for
> sub tag extensions can be [found
> here|https://docs.oracle.com/javase/tutorial/i18n/locale/extensions.html].
> An example locale string with a custom extension might be {{fr-CA-x-nb}}.
> This issue seems to have been introduced with ticket LANG-915.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-lang] c-w commented on a change in pull request #766: LANG-1172: Support dash as a delimiter in locales
c-w commented on a change in pull request #766:
URL: https://github.com/apache/commons-lang/pull/766#discussion_r763190834
##
File path: src/main/java/org/apache/commons/lang3/LocaleUtils.java
##
@@ -248,7 +250,9 @@ private static Locale parseLocale(final String str) {
return new Locale(str);
}
-final String[] segments = str.split("_", -1);
+final String[] segments = str.indexOf(DASH) != -1
+? str.split(String.valueOf(DASH), -1)
Review comment:
All the unit tests still pass with the comparison swapped. I made the
change in 0319d84d1. It's probably the right thing to optimize for the previous
delimiter as that'll be the vast majority of use-cases.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (LANG-1172) LocaleUtils.toLocale does not handle extensions
[
https://issues.apache.org/jira/browse/LANG-1172?focusedWorklogId=691219=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-691219
]
ASF GitHub Bot logged work on LANG-1172:
Author: ASF GitHub Bot
Created on: 06/Dec/21 16:54
Start Date: 06/Dec/21 16:54
Worklog Time Spent: 10m
Work Description: c-w commented on a change in pull request #766:
URL: https://github.com/apache/commons-lang/pull/766#discussion_r763190834
##
File path: src/main/java/org/apache/commons/lang3/LocaleUtils.java
##
@@ -248,7 +250,9 @@ private static Locale parseLocale(final String str) {
return new Locale(str);
}
-final String[] segments = str.split("_", -1);
+final String[] segments = str.indexOf(DASH) != -1
+? str.split(String.valueOf(DASH), -1)
Review comment:
All the unit tests still pass with the comparison swapped. I made the
change in 0319d84d1. It's probably the right thing to do to optimize for the
previous delimiter as that'll be the vast majority of use-cases.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 691219)
Time Spent: 2h 40m (was: 2.5h)
> LocaleUtils.toLocale does not handle extensions
> ---
>
> Key: LANG-1172
> URL: https://issues.apache.org/jira/browse/LANG-1172
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: David Buhler
>Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> The {{toLocale()}} method is unable to handle locale strings that have custom
> extensions that are completely valid according to the [BCP47
> spec|https://tools.ietf.org/html/bcp47#section-4]. Oracle documentation for
> sub tag extensions can be [found
> here|https://docs.oracle.com/javase/tutorial/i18n/locale/extensions.html].
> An example locale string with a custom extension might be {{fr-CA-x-nb}}.
> This issue seems to have been introduced with ticket LANG-915.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-lang] c-w commented on a change in pull request #766: LANG-1172: Support dash as a delimiter in locales
c-w commented on a change in pull request #766:
URL: https://github.com/apache/commons-lang/pull/766#discussion_r763190834
##
File path: src/main/java/org/apache/commons/lang3/LocaleUtils.java
##
@@ -248,7 +250,9 @@ private static Locale parseLocale(final String str) {
return new Locale(str);
}
-final String[] segments = str.split("_", -1);
+final String[] segments = str.indexOf(DASH) != -1
+? str.split(String.valueOf(DASH), -1)
Review comment:
All the unit tests still pass with the comparison swapped. I made the
change in 0319d84d1. It's probably the right thing to do to optimize for the
previous delimiter as that'll be the vast majority of use-cases.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (LANG-1172) LocaleUtils.toLocale does not handle extensions
[
https://issues.apache.org/jira/browse/LANG-1172?focusedWorklogId=691211=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-691211
]
ASF GitHub Bot logged work on LANG-1172:
Author: ASF GitHub Bot
Created on: 06/Dec/21 16:50
Start Date: 06/Dec/21 16:50
Worklog Time Spent: 10m
Work Description: c-w commented on a change in pull request #766:
URL: https://github.com/apache/commons-lang/pull/766#discussion_r763186990
##
File path: src/main/java/org/apache/commons/lang3/LocaleUtils.java
##
@@ -248,7 +250,9 @@ private static Locale parseLocale(final String str) {
return new Locale(str);
}
-final String[] segments = str.split("_", -1);
+final String[] segments = str.indexOf(DASH) != -1
+? str.split(String.valueOf(DASH), -1)
Review comment:
It's been a while since I wrote this code, but I don't think so. Should
be possible to switch them around without issues.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 691211)
Time Spent: 2.5h (was: 2h 20m)
> LocaleUtils.toLocale does not handle extensions
> ---
>
> Key: LANG-1172
> URL: https://issues.apache.org/jira/browse/LANG-1172
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: David Buhler
>Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The {{toLocale()}} method is unable to handle locale strings that have custom
> extensions that are completely valid according to the [BCP47
> spec|https://tools.ietf.org/html/bcp47#section-4]. Oracle documentation for
> sub tag extensions can be [found
> here|https://docs.oracle.com/javase/tutorial/i18n/locale/extensions.html].
> An example locale string with a custom extension might be {{fr-CA-x-nb}}.
> This issue seems to have been introduced with ticket LANG-915.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-lang] c-w commented on a change in pull request #766: LANG-1172: Support dash as a delimiter in locales
c-w commented on a change in pull request #766:
URL: https://github.com/apache/commons-lang/pull/766#discussion_r763186990
##
File path: src/main/java/org/apache/commons/lang3/LocaleUtils.java
##
@@ -248,7 +250,9 @@ private static Locale parseLocale(final String str) {
return new Locale(str);
}
-final String[] segments = str.split("_", -1);
+final String[] segments = str.indexOf(DASH) != -1
+? str.split(String.valueOf(DASH), -1)
Review comment:
It's been a while since I wrote this code, but I don't think so. Should
be possible to switch them around without issues.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (NUMBERS-177) Scaled complementary error function
[
https://issues.apache.org/jira/browse/NUMBERS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert updated NUMBERS-177:
-
Attachment: expn.png
> Scaled complementary error function
> ---
>
> Key: NUMBERS-177
> URL: https://issues.apache.org/jira/browse/NUMBERS-177
> Project: Commons Numbers
> Issue Type: New Feature
> Components: gamma
>Affects Versions: 1.1
>Reporter: Alex Herbert
>Priority: Minor
> Fix For: 1.1
>
> Attachments: erfc.png, erfcx.large.png, erfcx.medium.png, expn.png
>
>
> Add a scaled complementary error function:
> {noformat}
> erfcx(x) = exp(x^2) * erfc(x)
> {noformat}
> For small x this can use the current rational function approximations for erf
> or erfc and remove the scaling down by exp(-x^2). For large x this can use
> the [continued fraction expansion of
> erfc|https://en.wikipedia.org/wiki/Error_function#Continued_fraction_expansion]
> and remove the scaling by e^-z:
> {noformat}
> z1
> erfc z = e^-z^2 -
> sqrt(pi)z^2 + 1/2
>---
>1 + 1
>---
>z^2 + 3/2
> -
> 1 + 2
> -
> z^2 + ...
> {noformat}
> At very large x the rational function cannot be evaluated as {{z^2 + 0.5 ~
> z^2}} and the following approximation can be used:
> {noformat}
> 1 1
> erfcx z = * -
> sqrt(pi) z
> {noformat}
> This occurs at 2^26 or approximately 6.71e7.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (NUMBERS-177) Scaled complementary error function
[
https://issues.apache.org/jira/browse/NUMBERS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert updated NUMBERS-177:
-
Attachment: erfc.png
> Scaled complementary error function
> ---
>
> Key: NUMBERS-177
> URL: https://issues.apache.org/jira/browse/NUMBERS-177
> Project: Commons Numbers
> Issue Type: New Feature
> Components: gamma
>Affects Versions: 1.1
>Reporter: Alex Herbert
>Priority: Minor
> Fix For: 1.1
>
> Attachments: erfc.png, erfcx.large.png, erfcx.medium.png, expn.png
>
>
> Add a scaled complementary error function:
> {noformat}
> erfcx(x) = exp(x^2) * erfc(x)
> {noformat}
> For small x this can use the current rational function approximations for erf
> or erfc and remove the scaling down by exp(-x^2). For large x this can use
> the [continued fraction expansion of
> erfc|https://en.wikipedia.org/wiki/Error_function#Continued_fraction_expansion]
> and remove the scaling by e^-z:
> {noformat}
> z1
> erfc z = e^-z^2 -
> sqrt(pi)z^2 + 1/2
>---
>1 + 1
>---
>z^2 + 3/2
> -
> 1 + 2
> -
> z^2 + ...
> {noformat}
> At very large x the rational function cannot be evaluated as {{z^2 + 0.5 ~
> z^2}} and the following approximation can be used:
> {noformat}
> 1 1
> erfcx z = * -
> sqrt(pi) z
> {noformat}
> This occurs at 2^26 or approximately 6.71e7.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (NUMBERS-177) Scaled complementary error function
[
https://issues.apache.org/jira/browse/NUMBERS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert updated NUMBERS-177:
-
Attachment: erfcx.medium.png
> Scaled complementary error function
> ---
>
> Key: NUMBERS-177
> URL: https://issues.apache.org/jira/browse/NUMBERS-177
> Project: Commons Numbers
> Issue Type: New Feature
> Components: gamma
>Affects Versions: 1.1
>Reporter: Alex Herbert
>Priority: Minor
> Fix For: 1.1
>
> Attachments: erfcx.large.png, erfcx.medium.png
>
>
> Add a scaled complementary error function:
> {noformat}
> erfcx(x) = exp(x^2) * erfc(x)
> {noformat}
> For small x this can use the current rational function approximations for erf
> or erfc and remove the scaling down by exp(-x^2). For large x this can use
> the [continued fraction expansion of
> erfc|https://en.wikipedia.org/wiki/Error_function#Continued_fraction_expansion]
> and remove the scaling by e^-z:
> {noformat}
> z1
> erfc z = e^-z^2 -
> sqrt(pi)z^2 + 1/2
>---
>1 + 1
>---
>z^2 + 3/2
> -
> 1 + 2
> -
> z^2 + ...
> {noformat}
> At very large x the rational function cannot be evaluated as {{z^2 + 0.5 ~
> z^2}} and the following approximation can be used:
> {noformat}
> 1 1
> erfcx z = * -
> sqrt(pi) z
> {noformat}
> This occurs at 2^26 or approximately 6.71e7.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (NUMBERS-177) Scaled complementary error function
[
https://issues.apache.org/jira/browse/NUMBERS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert updated NUMBERS-177:
-
Attachment: erfcx.large.png
> Scaled complementary error function
> ---
>
> Key: NUMBERS-177
> URL: https://issues.apache.org/jira/browse/NUMBERS-177
> Project: Commons Numbers
> Issue Type: New Feature
> Components: gamma
>Affects Versions: 1.1
>Reporter: Alex Herbert
>Priority: Minor
> Fix For: 1.1
>
> Attachments: erfcx.large.png, erfcx.medium.png
>
>
> Add a scaled complementary error function:
> {noformat}
> erfcx(x) = exp(x^2) * erfc(x)
> {noformat}
> For small x this can use the current rational function approximations for erf
> or erfc and remove the scaling down by exp(-x^2). For large x this can use
> the [continued fraction expansion of
> erfc|https://en.wikipedia.org/wiki/Error_function#Continued_fraction_expansion]
> and remove the scaling by e^-z:
> {noformat}
> z1
> erfc z = e^-z^2 -
> sqrt(pi)z^2 + 1/2
>---
>1 + 1
>---
>z^2 + 3/2
> -
> 1 + 2
> -
> z^2 + ...
> {noformat}
> At very large x the rational function cannot be evaluated as {{z^2 + 0.5 ~
> z^2}} and the following approximation can be used:
> {noformat}
> 1 1
> erfcx z = * -
> sqrt(pi) z
> {noformat}
> This occurs at 2^26 or approximately 6.71e7.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (POOL-403) GenericKeyedObjectPool getNumActive and getNumIdle Javadoc do not match behaviour
[ https://issues.apache.org/jira/browse/POOL-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454114#comment-17454114 ] Gary D. Gregory commented on POOL-403: -- Feel free to provide a PR on GitHub keeping in mind that we have the interface and implementations. > GenericKeyedObjectPool getNumActive and getNumIdle Javadoc do not match > behaviour > - > > Key: POOL-403 > URL: https://issues.apache.org/jira/browse/POOL-403 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.11.1 >Reporter: KON-SUN-TACK >Priority: Minor > > In GenericKeyedObjectPool Javadoc, getNumActive(K key) and getNumIdle(K key) > states: > "Returns a negative value if this information is not available." > But it seems they actually return 0 instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (LANG-1172) LocaleUtils.toLocale does not handle extensions
[
https://issues.apache.org/jira/browse/LANG-1172?focusedWorklogId=691146=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-691146
]
ASF GitHub Bot logged work on LANG-1172:
Author: ASF GitHub Bot
Created on: 06/Dec/21 15:59
Start Date: 06/Dec/21 15:59
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #766:
URL: https://github.com/apache/commons-lang/pull/766#discussion_r763142047
##
File path: src/main/java/org/apache/commons/lang3/LocaleUtils.java
##
@@ -248,7 +250,9 @@ private static Locale parseLocale(final String str) {
return new Locale(str);
}
-final String[] segments = str.split("_", -1);
+final String[] segments = str.indexOf(DASH) != -1
+? str.split(String.valueOf(DASH), -1)
Review comment:
Does it matter that dash is tested before underscore?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 691146)
Time Spent: 2h 20m (was: 2h 10m)
> LocaleUtils.toLocale does not handle extensions
> ---
>
> Key: LANG-1172
> URL: https://issues.apache.org/jira/browse/LANG-1172
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: David Buhler
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> The {{toLocale()}} method is unable to handle locale strings that have custom
> extensions that are completely valid according to the [BCP47
> spec|https://tools.ietf.org/html/bcp47#section-4]. Oracle documentation for
> sub tag extensions can be [found
> here|https://docs.oracle.com/javase/tutorial/i18n/locale/extensions.html].
> An example locale string with a custom extension might be {{fr-CA-x-nb}}.
> This issue seems to have been introduced with ticket LANG-915.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-lang] garydgregory commented on a change in pull request #766: LANG-1172: Support dash as a delimiter in locales
garydgregory commented on a change in pull request #766:
URL: https://github.com/apache/commons-lang/pull/766#discussion_r763142047
##
File path: src/main/java/org/apache/commons/lang3/LocaleUtils.java
##
@@ -248,7 +250,9 @@ private static Locale parseLocale(final String str) {
return new Locale(str);
}
-final String[] segments = str.split("_", -1);
+final String[] segments = str.indexOf(DASH) != -1
+? str.split(String.valueOf(DASH), -1)
Review comment:
Does it matter that dash is tested before underscore?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (LANG-1172) LocaleUtils.toLocale does not handle extensions
[
https://issues.apache.org/jira/browse/LANG-1172?focusedWorklogId=691115=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-691115
]
ASF GitHub Bot logged work on LANG-1172:
Author: ASF GitHub Bot
Created on: 06/Dec/21 15:26
Start Date: 06/Dec/21 15:26
Worklog Time Spent: 10m
Work Description: c-w commented on pull request #766:
URL: https://github.com/apache/commons-lang/pull/766#issuecomment-986881732
@kinow Given that the change is backwards compatible I'd say introducing a
new method would be more confusing as the developer would have to know/remember
to pick the correct function.
@garydgregory Any thoughts or other comments on the PR?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 691115)
Time Spent: 2h 10m (was: 2h)
> LocaleUtils.toLocale does not handle extensions
> ---
>
> Key: LANG-1172
> URL: https://issues.apache.org/jira/browse/LANG-1172
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: David Buhler
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> The {{toLocale()}} method is unable to handle locale strings that have custom
> extensions that are completely valid according to the [BCP47
> spec|https://tools.ietf.org/html/bcp47#section-4]. Oracle documentation for
> sub tag extensions can be [found
> here|https://docs.oracle.com/javase/tutorial/i18n/locale/extensions.html].
> An example locale string with a custom extension might be {{fr-CA-x-nb}}.
> This issue seems to have been introduced with ticket LANG-915.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-lang] c-w commented on pull request #766: LANG-1172: Support dash as a delimiter in locales
c-w commented on pull request #766: URL: https://github.com/apache/commons-lang/pull/766#issuecomment-986881732 @kinow Given that the change is backwards compatible I'd say introducing a new method would be more confusing as the developer would have to know/remember to pick the correct function. @garydgregory Any thoughts or other comments on the PR? -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (VFS-742) Add org.apache.commons.vfs2.FileContent.isEmpty()
[
https://issues.apache.org/jira/browse/VFS-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed VFS-742.
---
Fix Version/s: 2.5.0
Resolution: Fixed
Done way back in release 2.5.0.
> Add org.apache.commons.vfs2.FileContent.isEmpty()
> -
>
> Key: VFS-742
> URL: https://issues.apache.org/jira/browse/VFS-742
> Project: Commons VFS
> Issue Type: New Feature
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.5.0
>
>
> Add {{org.apache.commons.vfs2.FileContent.isEmpty()}} as a default method
> calling {{getSize()}}.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (VFS-762) Replace Configuration XML With Annotations on Providers
[ https://issues.apache.org/jira/browse/VFS-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453990#comment-17453990 ] Gary D. Gregory commented on VFS-762: - We should probably replace the current mechanism to use the Java Service Loader. > Replace Configuration XML With Annotations on Providers > --- > > Key: VFS-762 > URL: https://issues.apache.org/jira/browse/VFS-762 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (VFS-763) Move HDFS File System Into Its Own Maven Module
[ https://issues.apache.org/jira/browse/VFS-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453988#comment-17453988 ] Gary D. Gregory commented on VFS-763: - Sounds reasonable. > Move HDFS File System Into Its Own Maven Module > --- > > Key: VFS-763 > URL: https://issues.apache.org/jira/browse/VFS-763 > Project: Commons VFS > Issue Type: Wish >Reporter: David Mollitor >Priority: Minor > > HDFS has a lot of dependencies. Move it to its own VFS module so that it can > more optionally included. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (VFS-707) Update Apache HttpClient from 4.5.7 to 4.5.8
[ https://issues.apache.org/jira/browse/VFS-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed VFS-707. --- Resolution: Fixed Done a long time ago. > Update Apache HttpClient from 4.5.7 to 4.5.8 > > > Key: VFS-707 > URL: https://issues.apache.org/jira/browse/VFS-707 > Project: Commons VFS > Issue Type: Improvement >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory >Priority: Major > > Update Apache HttpClient from 4.5.7 to 4.5.8. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (VFS-700) Some tests fail on Java 11 and above
[
https://issues.apache.org/jira/browse/VFS-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed VFS-700.
---
Resolution: Fixed
Fixed a long time ago.
> Some tests fail on Java 11 and above
>
>
> Key: VFS-700
> URL: https://issues.apache.org/jira/browse/VFS-700
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Gary D. Gregory
>Priority: Major
>
> Some tests fail on Java 11 and above: https://travis-ci.org/apache/commons-vfs
> {noformat}
> Tests in error:
>
> AbstractFtpsProviderTestCase$FtpProviderTestSuite>AbstractTestSuite.run:137->setUp:153->AbstractTestSuite.setUp:166
> » FileSystem
>
> AbstractFtpsProviderTestCase$FtpProviderTestSuite>AbstractTestSuite.run:137->setUp:153->AbstractTestSuite.setUp:166
> » FileSystem
> MultipleConnectionTestCase.testConnectRoot:55->resolveRoot:49 » FileSystem
> Cou...
> MultipleConnectionTestCase.testUnderlyingConnect:65 » SSL Unsupported or
> unrec...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (VFS-717) Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.
[ https://issues.apache.org/jira/browse/VFS-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed VFS-717. --- Resolution: Fixed Done a long time ago. > Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. > > > Key: VFS-717 > URL: https://issues.apache.org/jira/browse/VFS-717 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Gary D. Gregory >Priority: Major > > Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. -- This message was sent by Atlassian Jira (v8.20.1#820001)
