[jira] Commented: (MATH-500) Remove ConvergingAlgoritm interface and ConvergingAlgoritmImpl class
[
https://issues.apache.org/jira/browse/MATH-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985575#action_12985575
]
Gilles commented on MATH-500:
-
ConvergingAlgoritmImpl deprecated in MATH_2_X (revision 1062691).
Remove ConvergingAlgoritm interface and ConvergingAlgoritmImpl class
-
Key: MATH-500
URL: https://issues.apache.org/jira/browse/MATH-500
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Assignee: Gilles
Priority: Minor
Fix For: 3.0
Those types are only used by {{UnivariateRealIntegrator}} and
{{UnivariateRealIntegratorImpl}} within the package {{analysis.integration}}.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-624) SystemUtils.getJavaVersionAsFloat throws StringIndexOutOfBoundsException on Android runtime/Dalvik VM
[
https://issues.apache.org/jira/browse/LANG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985581#action_12985581
]
Joerg Schaible commented on LANG-624:
-
The only problem that remains then is for Android, because IIRC it used to
return something like 0.9 as specification version. Where are the Android guys
to affirm my 2nd hand knowledge? Question is what isJavaAtLeast should do in
this platform, because someone who uses c-l will probably expect that his check
will succeed for Java 5 also on Android.
SystemUtils.getJavaVersionAsFloat throws StringIndexOutOfBoundsException on
Android runtime/Dalvik VM
-
Key: LANG-624
URL: https://issues.apache.org/jira/browse/LANG-624
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 2.5
Reporter: Travis Truman
Fix For: 3.0
Attachments: AndriodJavaVersion.png
Can be replicated in the Android emulator quite easily.
Stack trace:
{noformat}
at
org.apache.commons.lang.builder.ToStringBuilder.clinit(ToStringBuilder.java:98)
E/AndroidRuntime( 1681): ... 17 more
E/AndroidRuntime( 1681): Caused by: java.lang.ExceptionInInitializerError
E/AndroidRuntime( 1681): at
org.apache.commons.lang.builder.ToStringStyle$MultiLineToStringStyle.init(ToStringStyle.java:2276)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.builder.ToStringStyle.clinit(ToStringStyle.java:94)
E/AndroidRuntime( 1681): ... 18 more
E/AndroidRuntime( 1681): Caused by: java.lang.StringIndexOutOfBoundsException
E/AndroidRuntime( 1681): at java.lang.String.substring(String.java:1571)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1153)
E/AndroidRuntime( 1681): at
org.apache.commons.lang.SystemUtils.clinit(SystemUtils.java:818)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-501) Refactor package analysis.integration
Refactor package analysis.integration --- Key: MATH-501 URL: https://issues.apache.org/jira/browse/MATH-501 Project: Commons Math Issue Type: Improvement Reporter: Gilles Assignee: Gilles Priority: Minor Fix For: 3.0 This package should be refactored similarly to what has been done in package analysis.solvers: avoid protected fields, remove unnecessary state variable result and associated method, remove deprecated code, use new exceptions... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-493) FastMath min and max fail with (Infinity,-Infinity) and (0,0, -0.0)
[ https://issues.apache.org/jira/browse/MATH-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved MATH-493. --- Resolution: Fixed Fixed by using the Harmony code. Note: this appears to be at least as quick as StrictMath on Sun Java 1.6 in a crude test FastMath min and max fail with (Infinity,-Infinity) and (0,0, -0.0) --- Key: MATH-493 URL: https://issues.apache.org/jira/browse/MATH-493 Project: Commons Math Issue Type: Bug Reporter: Sebb Fix For: 2.2, 3.0 FastMath min and max fail with (Infinity,-Infinity) and (0,0, -0.0): min(float 0.0, float -0.0) expected -0.0 actual 0.0 min(float Infinity, float -Infinity) expected -Infinity actual NaN max(float 0.0, float -0.0) expected 0.0 actual -0.0 max(float Infinity, float -Infinity) expected Infinity actual NaN Similarly for the double versions. The Infinity failures are because the code uses Float.isNaN(a + b) which gives NaN when +/1- Infinity are added together. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-493) FastMath min and max fail with (Infinity,-Infinity) and (0,0, -0.0)
[ https://issues.apache.org/jira/browse/MATH-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-493: -- Affects Version/s: 3.0 2.2 FastMath min and max fail with (Infinity,-Infinity) and (0,0, -0.0) --- Key: MATH-493 URL: https://issues.apache.org/jira/browse/MATH-493 Project: Commons Math Issue Type: Bug Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 FastMath min and max fail with (Infinity,-Infinity) and (0,0, -0.0): min(float 0.0, float -0.0) expected -0.0 actual 0.0 min(float Infinity, float -Infinity) expected -Infinity actual NaN max(float 0.0, float -0.0) expected 0.0 actual -0.0 max(float Infinity, float -Infinity) expected Infinity actual NaN Similarly for the double versions. The Infinity failures are because the code uses Float.isNaN(a + b) which gives NaN when +/1- Infinity are added together. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-478) FastMath is not an exact replacement for StrictMath
[ https://issues.apache.org/jira/browse/MATH-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-478: -- Affects Version/s: 3.0 2.2 Fix Version/s: 3.0 2.2 FastMath is not an exact replacement for StrictMath --- Key: MATH-478 URL: https://issues.apache.org/jira/browse/MATH-478 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 FastMath Javadoc says: Faster, more accurate, portable alternative to StrictMath. However, it does not implement the following StrictMath methods: hypot(double, double) IEEEremainder(double, double) Nor the following, though it probably should: signum(float) ulp(float) FastMath implements the following additional methods: acosh(double) asinh(double) atanh(double) nextAfter(double, double) nextUp(double) I think this should be documented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-483) FastMath does not handle all special cases correctly
[ https://issues.apache.org/jira/browse/MATH-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-483: -- Affects Version/s: (was: 2.1) 2.2 FastMath does not handle all special cases correctly Key: MATH-483 URL: https://issues.apache.org/jira/browse/MATH-483 Project: Commons Math Issue Type: Bug Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 Attachments: MATH-483-generic.patch, MATH-483.patch FastMath has some issues with special cases such as +0.0 and -0.0. Here are the double cases so far found: abs(-0.0) expected:0.0 but was:-0.0 signum(-0.0) expected:-0.0 but was:0.0 asin(-0.0) expected:-0.0 but was:0.0 atan(-0.0) expected:-0.0 but was:0.0 log10(-0.0) expected:-Infinity but was:NaN toDegrees(-0.0) expected:-0.0 but was:0.0 toRadians(-0.0) expected:-0.0 but was:0.0 ulp(-Infinity) expected:Infinity but was:NaN And float cases: abs(-0.0) expected:0.0 but was:-0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-480) ulp in FastMath
[ https://issues.apache.org/jira/browse/MATH-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-480: -- Affects Version/s: 3.0 2.2 ulp in FastMath --- Key: MATH-480 URL: https://issues.apache.org/jira/browse/MATH-480 Project: Commons Math Issue Type: Bug Affects Versions: 2.2, 3.0 Reporter: Gilles Fix For: 2.2, 3.0 Attachments: MATH-480.patch When the argument is infinite, method ulp in FastMath produces NaN (whereas Math gives Infinity). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-496) Create FastMath copySign methods
[ https://issues.apache.org/jira/browse/MATH-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-496: -- Affects Version/s: 3.0 2.2 Create FastMath copySign methods Key: MATH-496 URL: https://issues.apache.org/jira/browse/MATH-496 Project: Commons Math Issue Type: Sub-task Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 The copySIgn methods are simple to implement and will be useful in preserving signs in calculations with FastMath. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-472) FastMath needs ulp(float)
[ https://issues.apache.org/jira/browse/MATH-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-472: -- Affects Version/s: 3.0 2.2 FastMath needs ulp(float) - Key: MATH-472 URL: https://issues.apache.org/jira/browse/MATH-472 Project: Commons Math Issue Type: Bug Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 FastMath needs ulp(float), because ulp((double)float) does not generate the correct results. Test case and patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-497) Create FastMath .getExponent methods
[ https://issues.apache.org/jira/browse/MATH-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-497: -- Affects Version/s: 3.0 2.2 Fix Version/s: 3.0 Create FastMath .getExponent methods Key: MATH-497 URL: https://issues.apache.org/jira/browse/MATH-497 Project: Commons Math Issue Type: Sub-task Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 getExponent - returns the unbiased exponent used in the representation of a floating point number -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-498) Create FastMath .scalb methods
[ https://issues.apache.org/jira/browse/MATH-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-498: -- Affects Version/s: 3.0 2.2 Fix Version/s: 3.0 Create FastMath .scalb methods -- Key: MATH-498 URL: https://issues.apache.org/jira/browse/MATH-498 Project: Commons Math Issue Type: Sub-task Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 scalb(n,m) = n * 2**m -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-476) [MATH] FastMath code contains 'magic' numbers, e.g. (-)4503599627370496.0
[ https://issues.apache.org/jira/browse/MATH-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-476: -- Affects Version/s: 3.0 2.2 [MATH] FastMath code contains 'magic' numbers, e.g. (-)4503599627370496.0 - Key: MATH-476 URL: https://issues.apache.org/jira/browse/MATH-476 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2, 3.0 Reporter: Sebb Priority: Minor The FastMath class contains quite a few 'magic' numbers, not all of which are explained/documented. For example, how is the number (-)4503599627370496.0 calculated? IMO, all magic numbers should be replaced by constants with a descriptive name and explanatory Javadoc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-482) FastMath.max(50.0f, -50.0f) = -50.0f; should be +50.0f
[ https://issues.apache.org/jira/browse/MATH-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-482: -- Affects Version/s: 3.0 2.2 FastMath.max(50.0f, -50.0f) = -50.0f; should be +50.0f --- Key: MATH-482 URL: https://issues.apache.org/jira/browse/MATH-482 Project: Commons Math Issue Type: Bug Affects Versions: 2.2, 3.0 Reporter: Sebb Assignee: Sebb Fix For: 2.2, 3.0 FastMath.max(50.0f, -50.0f) = -50.0f; should be +50.0f. This is because the wrong variable is returned. The bug was not detected by the test case testMinMaxFloat() because that has a bug too - it tests doubles, not floats. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-477) FastMath Javadoc should show which methods actually use java.lang.Math internally
[ https://issues.apache.org/jira/browse/MATH-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-477: -- Affects Version/s: 3.0 2.2 FastMath Javadoc should show which methods actually use java.lang.Math internally - Key: MATH-477 URL: https://issues.apache.org/jira/browse/MATH-477 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2, 3.0 Reporter: Sebb It would be useful to know which FastMath methods use the default implementation, as there's no point expecting any performance improvement from those. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-489) FastMath acos fails when input abs value is less than about 5.7851920321187236E-300 - returns NaN
[
https://issues.apache.org/jira/browse/MATH-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated MATH-489:
--
Affects Version/s: 3.0
2.2
FastMath acos fails when input abs value is less than about
5.7851920321187236E-300 - returns NaN
-
Key: MATH-489
URL: https://issues.apache.org/jira/browse/MATH-489
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2, 3.0
Reporter: Sebb
Fix For: 2.2, 3.0
FastMath acos fails when input absolute value is less than about
5.7851920321187236E-300
It returns NaN instead of an expected value close to PI/2.0
This appears to be due to the following code:
{code}
// Compute ratio r = y/x
double r = y/x;
temp = r * 1073741824.0;
{code}
r and temp can become infinite or Nan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-477) FastMath Javadoc should show which methods actually use java.lang.Math internally
[ https://issues.apache.org/jira/browse/MATH-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved MATH-477. --- Resolution: Fixed Fix Version/s: 3.0 2.2 FastMath Javadoc should show which methods actually use java.lang.Math internally - Key: MATH-477 URL: https://issues.apache.org/jira/browse/MATH-477 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 It would be useful to know which FastMath methods use the default implementation, as there's no point expecting any performance improvement from those. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-95) Base64: optionally allow strict parsing of base64 strings
[ https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985673#action_12985673 ] Adam Rabung commented on CODEC-95: -- Why not just make it the default behavior? Would an error be a violation of the base64 spec? I have a hard time imagining a scenario where I'd say I'm glad the parsing library ignored that erroneous data and didn't tell me. Base64: optionally allow strict parsing of base64 strings - Key: CODEC-95 URL: https://issues.apache.org/jira/browse/CODEC-95 Project: Commons Codec Issue Type: Improvement Affects Versions: 1.4 Reporter: Adam Rabung Priority: Minor Attachments: strictMode.zip Currently, Codec skips base64 characters that are outside of the encode table. I realize this is perfectly to spec, but I wonder if other users might appreciate a strict mode that throws an exception when one of these illegal characters are encountered. For example, I would love an exception to be thrown here: new Base64().decode(!@#$ iHaveIllegalCharsAtBeginningAndEnd %^)); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-478) FastMath is not an exact replacement for StrictMath
[ https://issues.apache.org/jira/browse/MATH-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved MATH-478. --- Resolution: Fixed All now implemented (or delegated) FastMath is not an exact replacement for StrictMath --- Key: MATH-478 URL: https://issues.apache.org/jira/browse/MATH-478 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 FastMath Javadoc says: Faster, more accurate, portable alternative to StrictMath. However, it does not implement the following StrictMath methods: hypot(double, double) IEEEremainder(double, double) Nor the following, though it probably should: signum(float) ulp(float) FastMath implements the following additional methods: acosh(double) asinh(double) atanh(double) nextAfter(double, double) nextUp(double) I think this should be documented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-95) Base64: optionally allow strict parsing of base64 strings
[ https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985836#action_12985836 ] Julius Davies commented on CODEC-95: This jar is surprisingly popular, and I think a lot of our users would be quite surprised if it started throwing exceptions in places where it hasn't thrown an exception in 8 years. [Look how much trouble we got into for accidentally adding \r\n to some outputs: CODEC-89 !!!] I will add a new static method, Base64.isStringBase64(String base64), shortly. If you create RejectingInputStream.java and add that as a patch, people could also do this: myStream = new Base64InputStream(new RejectingInputStream(myStream)); Base64: optionally allow strict parsing of base64 strings - Key: CODEC-95 URL: https://issues.apache.org/jira/browse/CODEC-95 Project: Commons Codec Issue Type: Improvement Affects Versions: 1.4 Reporter: Adam Rabung Priority: Minor Attachments: strictMode.zip Currently, Codec skips base64 characters that are outside of the encode table. I realize this is perfectly to spec, but I wonder if other users might appreciate a strict mode that throws an exception when one of these illegal characters are encountered. For example, I would love an exception to be thrown here: new Base64().decode(!@#$ iHaveIllegalCharsAtBeginningAndEnd %^)); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-95) Base64: optionally allow strict parsing of base64 strings
[ https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985855#action_12985855 ] Julius Davies commented on CODEC-95: Oh, +1 to Stephen Colebourne's comment. Wish I'd thought of that! Base64: optionally allow strict parsing of base64 strings - Key: CODEC-95 URL: https://issues.apache.org/jira/browse/CODEC-95 Project: Commons Codec Issue Type: Improvement Affects Versions: 1.4 Reporter: Adam Rabung Priority: Minor Attachments: strictMode.zip Currently, Codec skips base64 characters that are outside of the encode table. I realize this is perfectly to spec, but I wonder if other users might appreciate a strict mode that throws an exception when one of these illegal characters are encountered. For example, I would love an exception to be thrown here: new Base64().decode(!@#$ iHaveIllegalCharsAtBeginningAndEnd %^)); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-95) Base64: optionally allow strict parsing of base64 strings
[ https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985860#action_12985860 ] Gary Gregory commented on CODEC-95: --- +1 to Base64StrictInputStream Base64: optionally allow strict parsing of base64 strings - Key: CODEC-95 URL: https://issues.apache.org/jira/browse/CODEC-95 Project: Commons Codec Issue Type: Improvement Affects Versions: 1.4 Reporter: Adam Rabung Priority: Minor Attachments: strictMode.zip Currently, Codec skips base64 characters that are outside of the encode table. I realize this is perfectly to spec, but I wonder if other users might appreciate a strict mode that throws an exception when one of these illegal characters are encountered. For example, I would love an exception to be thrown here: new Base64().decode(!@#$ iHaveIllegalCharsAtBeginningAndEnd %^)); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-502) FastMath scalb() does not handle large magnitude exponents correctly
FastMath scalb() does not handle large magnitude exponents correctly Key: MATH-502 URL: https://issues.apache.org/jira/browse/MATH-502 Project: Commons Math Issue Type: Bug Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 scalb does not handle MAX_VALUE exponents properly: double scalb(-1.7976931348623157E308, 2147483647) expected -Infinity actual -8.988465674311579E307 entries [6, 5] double scalb(1.7976931348623157E308, 2147483647) expected Infinity actual 8.988465674311579E307 entries [7, 5] double scalb(-1.1102230246251565E-16, 2147483647) expected -Infinity actual -5.551115123125783E-17 entries [8, 5] double scalb(1.1102230246251565E-16, 2147483647) expected Infinity actual 5.551115123125783E-17 entries [9, 5] double scalb(-2.2250738585072014E-308, 2147483647) expected -Infinity actual -0.0 entries [10, 5] double scalb(2.2250738585072014E-308, 2147483647) expected Infinity actual 0.0 entries [11, 5] float scalb(3.4028235E38, 2147483647) expected Infinity actual 1.7014117E38 entries [7, 5] float scalb(-3.4028235E38, 2147483647) expected -Infinity actual -1.7014117E38 entries [9, 5] It looks as though the problem is with the calculation of the scaledExponent - for large values, this can wrap round, so some of the checks against its value may give misleading results. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-502) FastMath scalb() does not handle large magnitude exponents correctly
[ https://issues.apache.org/jira/browse/MATH-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-502. Resolution: Fixed fixed in subversion repository as of r1062928 for trunk and r1062929 for branch 2.X FastMath scalb() does not handle large magnitude exponents correctly Key: MATH-502 URL: https://issues.apache.org/jira/browse/MATH-502 Project: Commons Math Issue Type: Bug Affects Versions: 2.2, 3.0 Reporter: Sebb Fix For: 2.2, 3.0 scalb does not handle MAX_VALUE exponents properly: double scalb(-1.7976931348623157E308, 2147483647) expected -Infinity actual -8.988465674311579E307 entries [6, 5] double scalb(1.7976931348623157E308, 2147483647) expected Infinity actual 8.988465674311579E307 entries [7, 5] double scalb(-1.1102230246251565E-16, 2147483647) expected -Infinity actual -5.551115123125783E-17 entries [8, 5] double scalb(1.1102230246251565E-16, 2147483647) expected Infinity actual 5.551115123125783E-17 entries [9, 5] double scalb(-2.2250738585072014E-308, 2147483647) expected -Infinity actual -0.0 entries [10, 5] double scalb(2.2250738585072014E-308, 2147483647) expected Infinity actual 0.0 entries [11, 5] float scalb(3.4028235E38, 2147483647) expected Infinity actual 1.7014117E38 entries [7, 5] float scalb(-3.4028235E38, 2147483647) expected -Infinity actual -1.7014117E38 entries [9, 5] It looks as though the problem is with the calculation of the scaledExponent - for large values, this can wrap round, so some of the checks against its value may give misleading results. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CODEC-110) Add a String version of Base64.isArrayByteBase64()
[ https://issues.apache.org/jira/browse/CODEC-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julius Davies updated CODEC-110: Description: Add a String version of Base64.isArrayByteBase64(). Right now we just have a byte[] version. We'll call it: Base64.isStringBase64(). was:Add a String version of Base64.isBase64(). Right now we just have a byte version. Summary: Add a String version of Base64.isArrayByteBase64() (was: Add a String version of Base64.isBase64()) Add a String version of Base64.isArrayByteBase64() -- Key: CODEC-110 URL: https://issues.apache.org/jira/browse/CODEC-110 Project: Commons Codec Issue Type: New Feature Reporter: Julius Davies Assignee: Julius Davies Priority: Trivial Fix For: 1.5 Add a String version of Base64.isArrayByteBase64(). Right now we just have a byte[] version. We'll call it: Base64.isStringBase64(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CODEC-110) Add a String version of Base64.isArrayByteBase64()
[ https://issues.apache.org/jira/browse/CODEC-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julius Davies updated CODEC-110: Attachment: codec-110-junit-and-impl.patch Here's the patch, including JUnit test. Since isArrayByteBase64() blows up on NULL are decided to let this one also blow up, to maintain consistency. Add a String version of Base64.isArrayByteBase64() -- Key: CODEC-110 URL: https://issues.apache.org/jira/browse/CODEC-110 Project: Commons Codec Issue Type: New Feature Reporter: Julius Davies Assignee: Julius Davies Priority: Trivial Fix For: 1.5 Attachments: codec-110-junit-and-impl.patch Add a String version of Base64.isArrayByteBase64(). Right now we just have a byte[] version. We'll call it: Base64.isStringBase64(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CODEC-110) Add a String version of Base64.isArrayByteBase64()
[ https://issues.apache.org/jira/browse/CODEC-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julius Davies resolved CODEC-110. - Resolution: Fixed Add a String version of Base64.isArrayByteBase64() -- Key: CODEC-110 URL: https://issues.apache.org/jira/browse/CODEC-110 Project: Commons Codec Issue Type: New Feature Reporter: Julius Davies Assignee: Julius Davies Priority: Trivial Fix For: 1.5 Attachments: codec-110-junit-and-impl.patch Add a String version of Base64.isArrayByteBase64(). Right now we just have a byte[] version. We'll call it: Base64.isStringBase64(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CODEC-99) Base64.encodeBase64String() shouldn't chunk
[
https://issues.apache.org/jira/browse/CODEC-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julius Davies updated CODEC-99:
---
Attachment: codec-99-javadoc.patch
Oops, I forgot to update the Javadoc. Thanks, Sebb, for pointing that out!
Base64.encodeBase64String() shouldn't chunk
---
Key: CODEC-99
URL: https://issues.apache.org/jira/browse/CODEC-99
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Julius Davies
Fix For: 1.5
Attachments: codec-99-javadoc.patch, codec-99-test-fixes.patch,
codec-99-tests.patch, codec-99.patch
Base64.encodeBase64String() shouldn't chunk.
Change this:
{code}
public static String encodeBase64String(byte[] binaryData) {
return StringUtils.newStringUtf8(encodeBase64(binaryData, true));
}
{code}
To this:
{code}
public static String encodeBase64String(byte[] binaryData) {
return StringUtils.newStringUtf8(encodeBase64(binaryData, false));
}
{code}
This will fix the following tests ggregory added a few minutes ago:
//assertEquals(Zg==,
Base64.encodeBase64String(StringUtils.getBytesUtf8(f)));
//assertEquals(Zm8=,
Base64.encodeBase64String(StringUtils.getBytesUtf8(fo)));
//assertEquals(Zm9v,
Base64.encodeBase64String(StringUtils.getBytesUtf8(foo)));
//assertEquals(Zm9vYg==,
Base64.encodeBase64String(StringUtils.getBytesUtf8(foob)));
//assertEquals(Zm9vYmE=,
Base64.encodeBase64String(StringUtils.getBytesUtf8(fooba)));
//assertEquals(Zm9vYmFy,
Base64.encodeBase64String(StringUtils.getBytesUtf8(foobar)));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-88) Base32 encoder
[ https://issues.apache.org/jira/browse/CODEC-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12986170#action_12986170 ] Julius Davies commented on CODEC-88: If we get it from here it's Public Domain (ASL 2.0 compatible) and not LGPL: http://bitcollider.cvs.sourceforge.net/viewvc/bitcollider/jbitcollider/plugins/org.bitpedia.collider.core/src/org/bitpedia/util/Base32.java?revision=1.2content-type=text/plain As a co-author, Gordon Mohr, Co-Founder of Bitzi, has the authority to declare this code as public domain: http://xavvy.com/ I think we should leave the Bitzi attribution public domain declaration @author tags in place if we take this code. Also, I could not locate any unit tests for this code. Base32 encoder -- Key: CODEC-88 URL: https://issues.apache.org/jira/browse/CODEC-88 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.x Reporter: Eric Olander Priority: Minor Attachments: Base32.java Any chance of getting Base32 encoding support along the lines of the existing Base64 encoder? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-110) Add a String version of Base64.isArrayByteBase64()
[ https://issues.apache.org/jira/browse/CODEC-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12986173#action_12986173 ] Gary Gregory commented on CODEC-110: Since this is a new method, I plan on renaming it to isBase64(String). There is no sense in having the type of the input parameter in the name. This mirrors nicely the isBase64(byte) method. IMO the other isTypeNameBase64 methods should be deprecated in favor of typeless names. This is OO after all. Add a String version of Base64.isArrayByteBase64() -- Key: CODEC-110 URL: https://issues.apache.org/jira/browse/CODEC-110 Project: Commons Codec Issue Type: New Feature Reporter: Julius Davies Assignee: Julius Davies Priority: Trivial Fix For: 1.5 Attachments: codec-110-junit-and-impl.patch Add a String version of Base64.isArrayByteBase64(). Right now we just have a byte[] version. We'll call it: Base64.isStringBase64(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
