[jira] [Commented] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253283#comment-13253283
]
Sebb commented on NET-458:
--
Looks like the problem is caused by trying to split a string containing only
space(s)
MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
---
Key: NET-458
URL: https://issues.apache.org/jira/browse/NET-458
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1, 3.1
Environment: zOS
Reporter: Denis Molony
Line 360 in MVSFTPEntryParser.parseSimpleEntry :
String name = entry.split( )[0];
gives an ArrayIndexOutOfBoundsException: 0
It appears to be caused by a partitioned dataset whose members only contain
names. No other details (creation date, file type etc).
This is the method, if it helps:
{code}
private boolean parseSimpleEntry(FTPFile file, String entry) {
if (entry != null entry.length() 0) {
file.setRawListing(entry);
String name = entry.split( )[0]; // --- error occurs here
file.setName(name);
file.setType(FTPFile.FILE_TYPE);
return true;
}
return false;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253285#comment-13253285
]
Denis Molony commented on NET-458:
--
The PDS contains many members, but all of them appear to have unreadable names
(unprintable characters?). There is no other member information available, so
that part of the string is definitely blank.
MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
---
Key: NET-458
URL: https://issues.apache.org/jira/browse/NET-458
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1, 3.1
Environment: zOS
Reporter: Denis Molony
Line 360 in MVSFTPEntryParser.parseSimpleEntry :
String name = entry.split( )[0];
gives an ArrayIndexOutOfBoundsException: 0
It appears to be caused by a partitioned dataset whose members only contain
names. No other details (creation date, file type etc).
This is the method, if it helps:
{code}
private boolean parseSimpleEntry(FTPFile file, String entry) {
if (entry != null entry.length() 0) {
file.setRawListing(entry);
String name = entry.split( )[0]; // --- error occurs here
file.setName(name);
file.setType(FTPFile.FILE_TYPE);
return true;
}
return false;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253294#comment-13253294
]
Denis Molony commented on NET-458:
--
Thanks, that fixed it.
MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
---
Key: NET-458
URL: https://issues.apache.org/jira/browse/NET-458
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1, 3.1
Environment: zOS
Reporter: Denis Molony
Line 360 in MVSFTPEntryParser.parseSimpleEntry :
String name = entry.split( )[0];
gives an ArrayIndexOutOfBoundsException: 0
It appears to be caused by a partitioned dataset whose members only contain
names. No other details (creation date, file type etc).
This is the method, if it helps:
{code}
private boolean parseSimpleEntry(FTPFile file, String entry) {
if (entry != null entry.length() 0) {
file.setRawListing(entry);
String name = entry.split( )[0]; // --- error occurs here
file.setName(name);
file.setType(FTPFile.FILE_TYPE);
return true;
}
return false;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-718) inverseCumulativeProbability of BinomialDistribution returns wrong value for large trials.
[
https://issues.apache.org/jira/browse/MATH-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253360#comment-13253360
]
Thomas Neidhart commented on MATH-718:
--
The problem Christian described wrt the PascalDistribution is a simple integer
overflow in the class itself:
{noformat}
public double cumulativeProbability(int x) {
double ret;
if (x 0) {
ret = 0.0;
} else {
ret = Beta.regularizedBeta(probabilityOfSuccess,
numberOfSuccesses, x + 1);
}
return ret;
}
{noformat}
when x = Integer.MAX_VALUE, adding 1 to it will result in an overflow. As the
parameter of regularizedBeta is anyway a double, it should be cast to
long/double before the addition.
inverseCumulativeProbability of BinomialDistribution returns wrong value for
large trials.
--
Key: MATH-718
URL: https://issues.apache.org/jira/browse/MATH-718
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2, 3.0
Reporter: Yuji Uchiyama
Assignee: Sébastien Brisard
Fix For: 3.1, 4.0
The inverseCumulativeProbability method of the BinomialDistributionImpl class
returns wrong value for large trials. Following code will be reproduce the
problem.
{{System.out.println(new BinomialDistributionImpl(100,
0.5).inverseCumulativeProbability(0.5));}}
This returns 499525, though it should be 49.
I'm not sure how it should be fixed, but the cause is that the
cumulativeProbability method returns Infinity, not NaN. As the result the
checkedCumulativeProbability method doesn't work as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-718) inverseCumulativeProbability of BinomialDistribution returns wrong value for large trials.
[
https://issues.apache.org/jira/browse/MATH-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253360#comment-13253360
]
Thomas Neidhart edited comment on MATH-718 at 4/13/12 1:22 PM:
---
The problem Christian described wrt the PascalDistribution is a simple integer
overflow in the class itself:
{noformat}
public double cumulativeProbability(int x) {
double ret;
if (x 0) {
ret = 0.0;
} else {
ret = Beta.regularizedBeta(probabilityOfSuccess,
numberOfSuccesses, x + 1);
}
return ret;
}
{noformat}
when x = Integer.MAX_VALUE, adding 1 to it will result in an overflow. As the
parameter of regularizedBeta is anyway a double, it should be cast to
long/double before the addition.
Edit: Similar things happen btw also in other Distribution implementations, so
it should be fixed also there, e.g. BinomialDistribution
was (Author: tn):
The problem Christian described wrt the PascalDistribution is a simple
integer overflow in the class itself:
{noformat}
public double cumulativeProbability(int x) {
double ret;
if (x 0) {
ret = 0.0;
} else {
ret = Beta.regularizedBeta(probabilityOfSuccess,
numberOfSuccesses, x + 1);
}
return ret;
}
{noformat}
when x = Integer.MAX_VALUE, adding 1 to it will result in an overflow. As the
parameter of regularizedBeta is anyway a double, it should be cast to
long/double before the addition.
inverseCumulativeProbability of BinomialDistribution returns wrong value for
large trials.
--
Key: MATH-718
URL: https://issues.apache.org/jira/browse/MATH-718
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2, 3.0
Reporter: Yuji Uchiyama
Assignee: Sébastien Brisard
Fix For: 3.1, 4.0
The inverseCumulativeProbability method of the BinomialDistributionImpl class
returns wrong value for large trials. Following code will be reproduce the
problem.
{{System.out.println(new BinomialDistributionImpl(100,
0.5).inverseCumulativeProbability(0.5));}}
This returns 499525, though it should be 49.
I'm not sure how it should be fixed, but the cause is that the
cumulativeProbability method returns Infinity, not NaN. As the result the
checkedCumulativeProbability method doesn't work as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-740) Some FastMath functions are slow
[
https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253415#comment-13253415
]
Thomas Neidhart commented on MATH-740:
--
I am a bit puzzled, does anybody have an idea why Math is faster than
StrictMath, although internally, Math.log10 just calls StrictMath.log10?
{noformat}
Name StrictMath FastMath Math Runs=1000 Java 1.6.0_20
(1.6.0_20-b02) Java HotSpot(TM) Server VM (16.3-b01)
log10 981.0161 1.6377 23 0.2427
{noformat}
From Math.java:
{noformat}
public static double log10(double a) {
return StrictMath.log10(a); // default impl. delegates to StrictMath
}
{noformat}
Some FastMath functions are slow
--
Key: MATH-740
URL: https://issues.apache.org/jira/browse/MATH-740
Project: Commons Math
Issue Type: Wish
Reporter: Gilles
Priority: Minor
Fix For: 3.1
From the two benchmarks we currently have in FastMathTestPerfomance, we
have that the following functions are much slower in FastMath than in
either Math or StrictMath (the performance *loss*, for each of the
benchmarks, is given in parentheses):
* log10 (46%, 36%)
* log1p (68%, 112%)
* tan (11%, 61%)
* atan (26%, 125%)
* atan2 (44%, 40%)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-740) Some FastMath functions are slow
[ https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253421#comment-13253421 ] Ismael Juma commented on MATH-740: -- Thomas, you cannot trust what you see in java.lang.Math. Many of those methods are HotSpot intrinsics and consist of optimised assembly code. Examples are sin, cos, tan, exp, log, sqrt, atan2 and so on. Some FastMath functions are slow -- Key: MATH-740 URL: https://issues.apache.org/jira/browse/MATH-740 Project: Commons Math Issue Type: Wish Reporter: Gilles Priority: Minor Fix For: 3.1 From the two benchmarks we currently have in FastMathTestPerfomance, we have that the following functions are much slower in FastMath than in either Math or StrictMath (the performance *loss*, for each of the benchmarks, is given in parentheses): * log10 (46%, 36%) * log1p (68%, 112%) * tan (11%, 61%) * atan (26%, 125%) * atan2 (44%, 40%) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-627) superfluously null check of SparseIterator.next()
[
https://issues.apache.org/jira/browse/MATH-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253536#comment-13253536
]
Arne Plöse commented on MATH-627:
-
Sorry for beeing sloppy...
If you look at ArrayRealVector you will find this construct:
{code}
while (it.hasNext() (e = it.next()) != null) {...}
{code}
the same can also be found in RealVector
superfluously null check of SparseIterator.next()
-
Key: MATH-627
URL: https://issues.apache.org/jira/browse/MATH-627
Project: Commons Math
Issue Type: Improvement
Reporter: Arne Plöse
Priority: Minor
Fix For: 3.1
Looking at the implementation of SparseIterator in
OpenMapRealVector.OpenMapSparseIterator there is no chance that the entry
return by next() is ever null - so there is no need to chek this in nearly
every loop?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-72) Incorrect reading TIFF file
[
https://issues.apache.org/jira/browse/SANSELAN-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic resolved SANSELAN-72.
--
Resolution: Fixed
Fix Version/s: 1.0
The problem with the grey background was that Sanselan was using the worst
possible algorithm described in Section 9.1 of the PNG spec. I've changed it to
use the best one as of commit 1325915.
Both issues are now gone - resolving fixed.
Incorrect reading TIFF file
---
Key: SANSELAN-72
URL: https://issues.apache.org/jira/browse/SANSELAN-72
Project: Commons Sanselan
Issue Type: Bug
Components: Format: PNG, Format: TIFF
Affects Versions: 1.x
Reporter: VVD
Fix For: 1.0
Attachments: in.png, in.tif, out-png-IM.png, out-tif.png
I found 2 bugs.
I have tif file in.tif.
1. After convert it to png (bmp, tga, etc) by Sanselan it getting horizontal
lines.
{code}
Sanselan.writeImage(Sanselan.getBufferedImage(new File(in.tif)), new
File(out-tif.png), ImageFormat.IMAGE_FORMAT_PNG, null);
{code}
gwenview, eog, kolourpaint, gimp, etc show in.tif without lines and out.png
with lines.
For example 1st line at ~860 points from top and in full width of picture.
2. After convert it to png by convert utility from ImageMagic, and then
convert it to png (bmp, tga, etc) by Sanselan it became gray - all white
pixels become gray.
{code}$ convert in.tif in.png{code}
{code}
Sanselan.writeImage(Sanselan.getBufferedImage(new File(in.png)), new
File(out-png-IM.png), ImageFormat.IMAGE_FORMAT_PNG, null);
{code}
gwenview, eog, kolourpaint, gimp, etc show in.png as black and white, but
out-png-IM.png as black and gray.
I'll attach all 4 files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
