[jira] [Commented] (LANG-790) Null safe Navigation in ObjectUtils
[ https://issues.apache.org/jira/browse/LANG-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232191#comment-13232191 ] Gokul Nanthakumar C commented on LANG-790: -- Thanks Gary for your valuable input and time. Javascript in Java, cool, but I like to have an option in Java, As I commented earlier, if that is the choice I can use any JVM languages to achieve this, we can use Groovy to achieve this and many more. You may choose to call it is as Interpreter, but for me it is just an utility method for easy navigation. Private method support not necessarily required as we can not access them any way in normal way. Null safe Navigation in ObjectUtils --- Key: LANG-790 URL: https://issues.apache.org/jira/browse/LANG-790 Project: Commons Lang Issue Type: New Feature Reporter: Gokul Nanthakumar C Adding a method for null safe navigation of objects will be very helpful. for example a method like ObjectUtils.getValue(Object obj, String path, String defaultValue); ex :ObjectUtils.getValue(myObject, x.y.z, default); it will navigate in the myObject like myObject.getX().getY().getZ(), if any thing in the path is null (x,y or z), it will return the default value. It will be really useful, it is like null safe navigation in groovy. -- 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] (IO-305) New copy() method in IOUtils that takes additional offset, length and buffersize arguments
[ https://issues.apache.org/jira/browse/IO-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232219#comment-13232219 ] Manoj Mokashi commented on IO-305: -- I tested copying a 500MB tar archive with diffent buffersizes, and it does make a difference. e.g. buffersize = time in millis: 4096=129954,*16=71734,*64=91328 4096=120406,*16=80219,*64=69687 btw, accessing buffer.length inside the loop seems to affect performance for bigger lengths. As seen in the 1st statistics, the *64 method actually takes longer than *16. In the 2nd set i have used a buffersize var outside the loop as its constant. I guess the results will vary as per avail memory, OS, disk types etc. But it does make a difference to specify buffer size. wrt IO-308, i agree that passing a buffer would be even better. New copy() method in IOUtils that takes additional offset, length and buffersize arguments -- Key: IO-305 URL: https://issues.apache.org/jira/browse/IO-305 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: Manoj Mokashi Priority: Minor Fix For: 2.2 Attachments: IOUtils.java, IOUtilsTest.java /** * Copy from input to output stream * @param is : input stream * @param os : output stream * @param offset : number of bytes to skip from input before copying * -ve values are ignored * @param len : number of bytes to copy. -1 means all * @param bufferSize : buffer size to use for copying * @throws IOException */ public static void copy( InputStream is, OutputStream os, int offset, int len, int bufferSize) throws IOException -- 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] [Closed] (MATH-735) Improvements to linear iterative solvers
[
https://issues.apache.org/jira/browse/MATH-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-735.
--
Fixed in 3.0.
Improvements to linear iterative solvers
Key: MATH-735
URL: https://issues.apache.org/jira/browse/MATH-735
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: event, linear, solver
Before we release version 3.0, I would like to perform some changes to the
general framework for linear iterative solvers.
# Remove interface {{InvertibleRealLinearOperator}}: this was only proposed
for handling preconditioners. Let {{M}} be this preconditioner. In the course
of the iterations, only matrix-vector products of the form {{M^(-1) . y}} are
needed, never direct products {{M . x}}. So it's just as simple to provide
{{M^(-1)}} as a standard {{RealLinearOperator}}, rather than {{M}} as an
{{InvertibleRealLinearOperator}}. This removes a little bit of clutter in the
class hierarchy.
# {{o.a.c.m.util.IterationEvent}} should at the very least have a method to
get the current iteration number. Overwise, I find myself keeping track of
the number of times
{{o.a.c.m.util.IterationManager.fireIterationPerformedEvent(IterationEvent)}}
is called, which is both ugly and painfull.
# {{o.a.c.m.util.linear.IterativeLinearSolverEvent}} should have a method to
access the norm of the residual. I was reluctant to specify such a method in
the interface at the start, because I was not sure any iterative solver
provides an updated estimate of this quantity at each iteration. In fact,
I've realized that most (if not all) solvers do, and it's quite nice to be
able to access this value while monitoring the progress of the inversion
(through {{o.a.c.m.utils.IterationListener}}). Otherwise, one has to compute
{{b - A . x}} inside the listener, which *doubles* the cost of each iteration!
# {{o.a.c.m.util.linear.IterativeLinearSolverEvent}} should have a method to
access the residual (the vector itself, not only its norm). I'm not sure
*all* solvers can do that, so this should be an optional feature, which might
be useful. I see two different possible implementations
## specify {{RealVector
o.a.c.m.util.linear.IterativeLinearSolverEvent.getResidual()}} as an optional
feature (potentially throwing {{UnsupportedOperationException}}), together
with a method {{boolean
o.a.c.m.util.linear.IterativeLinearSolverEvent.providesResidual()}}. I think
some of us do not like {{UnsupportedOperationException}}, but this would be
similar to what was done in
{{RealLinearOperator.operateTranspose(RealVector)}}.
## create a new interface {{RealVector
o.a.c.m.util.linear.IterativeLinearSolverWithResidualEvent}}. This is similar
to what is done currently, see {{o.a.c.m.linear.ProvidesResidual}}.
I would love to have some feedback on the last point.
--
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] [Closed] (MATH-743) Use enums in package transform
[
https://issues.apache.org/jira/browse/MATH-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-743.
--
Fixed in 3.0.
Use enums in package transform
--
Key: MATH-743
URL: https://issues.apache.org/jira/browse/MATH-743
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: api-change, enum, transform
Fix For: 3.0
As discussed on the mailing-list, enums could be used in the package
{{transform}}
# An enumeration {{FORWARD, INVERSE}} will be created to specify whether the
inverse transform is to be computed. This will replace the pair
{{transform}}/{{inverseTransform}}
# An enumeration {{STANDARD, ORTHOGONAL}} will be introduced (where relevant)
in each transform class, in order to specify the normalization that should be
used. Then the factory methods {{create()}}/{{createOrthogonal()}} will be
replaced by a parameter passed to the constructor, which will be made public.
--
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] [Closed] (MATH-711) Merge xxxDistribution and xxxDistributionImpl in package distribution
[
https://issues.apache.org/jira/browse/MATH-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-711.
--
Fixed in 3.0.
Merge xxxDistribution and xxxDistributionImpl in package distribution
-
Key: MATH-711
URL: https://issues.apache.org/jira/browse/MATH-711
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
This ticket follows the general trend aiming at removing unnecessary
interfaces. In this package, the concerned interfaces are
(/) {{BetaDistribution}}: done in r1205739
(/) {{BinomialDistribution}}: done in r1205963
(/) {{CauchyDistribution}}: done in r1206053
(/) {{ChiSquaredDistribution}}: done in r1206060
(/) {{ExponentialDistribution}}: done in r1206399
(/) {{FDistribution}}: done in r1206399
(/) {{GammaDistribution}}: done in r1206399
(/) {{HypergeometricDistribution}}: done in r1206406
(/) {{KolmogorovSmirnovDistribution}}: done in r1206425
(/) {{NormalDistribution}}: done in r1206421
(/) {{PascalDistribution}}: done in r1206421
(/) {{PoissonDistribution}}: done in r1206434
(/) {{TDistribution}}: done in r1206434
(/) {{WeibullDistribution}}: done in r1206434
(/) {{ZipfDistribution}}: done in r1206451
Corresponding implementations {{xxxDistributionImpl}} will be renamed
{{xxxDistribution}}.
--
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] [Closed] (MATH-715) PascalDistribution returns wrong values of mean and variance
[
https://issues.apache.org/jira/browse/MATH-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-715.
--
Fixed in 3.0.
PascalDistribution returns wrong values of mean and variance
Key: MATH-715
URL: https://issues.apache.org/jira/browse/MATH-715
Project: Commons Math
Issue Type: Bug
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Fix For: 3.0
The header of the Javadoc states that the random variable (say X) being
represented by this {{o.a.c.m.distribution.PascalDistribution}} is the number
of *failures*. The current Javadoc is slightly confusing, because it refers
to the Wikipedia website, where the opposite convention is adopted (X is the
number of *successes*) : different formulas therefore apply for the mean and
variance of X. The javadoc should be made clearer, for example by inclusion
of full formulas. Also the parameters differing from the Wikipedia reference
should not have the same name
* {{p}} is the probability of success in both cases: OK,
* {{r}} is the number of failures in Wikipedia, but the number of successes
in CM. This could be renamed (say) {{s}}.
Finally, with the current notations of CM, the mean of X is given by
{{mean(X) = r * (1 - p) / p}}, while the currently implemented formula is {{r
* p / (1 - p)}}, which is actually the formula corresponding to the Wikipedia
convention.
The following piece of code shows that the current implementation is faulty
{code:java}
public class PascalDistributionDemo {
public static void main(String[] args) {
final int r = 10;
final double p = 0.2;
final int numTerms = 1000;
final PascalDistribution distribution = new PascalDistribution(r, p);
double mean = 0.;
for (int k = numTerms - 1; k = 0; k--) {
mean += k * distribution.probability(k);
}
// The following prints 40.12
System.out.println(Estimate of the mean = + mean);
// The following prints 2.5
System.out.println(CM implementation = +
distribution.getNumericalMean());
// The following prints 2.5
System.out.println(r * p / (1 - p) = + (r * p / (1 - p)));
// The following prints 40.0
System.out.println(r * (1 - p) / p = + (r * (1 - p) / p));
}
}
{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] [Closed] (MATH-673) FieldLUDecomposition.Solver is missing appropriate testing
[ https://issues.apache.org/jira/browse/MATH-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard closed MATH-673. -- Fixed in 3.0. FieldLUDecomposition.Solver is missing appropriate testing -- Key: MATH-673 URL: https://issues.apache.org/jira/browse/MATH-673 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Fix For: 3.0 I could not find any unit test for this class. -- 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] [Closed] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard closed MATH-699. -- Fixed in 3.0. inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Fix For: 3.0 Attachments: AbstractContinuousDistributionTest.java, inv-cum-new-impl.zip This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- 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] [Closed] (MATH-659) Remove solve(double[][]) from DecompositionSolver
[
https://issues.apache.org/jira/browse/MATH-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-659.
--
Fixed in 3.0.
Remove solve(double[][]) from DecompositionSolver
-
Key: MATH-659
URL: https://issues.apache.org/jira/browse/MATH-659
Project: Commons Math
Issue Type: Task
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Trivial
Labels: linear
Fix For: 3.0
Following MATH-653, where {{double[]}} were removed from {{RealVector}}, and
{{double[] solve(double[])}} was removed from {{DecompositionSolver}}, the
method {{double[][] solve(double[][])}} should be removed from
{{DecompositionSolver}}. {{RealMatrix solve(RealMatrix)}} should be called
instead.
--
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] [Closed] (MATH-684) Add method multiply(int) to FieldElement
[ https://issues.apache.org/jira/browse/MATH-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Brisard closed MATH-684. -- Fixed in 3.0. Add method multiply(int) to FieldElement Key: MATH-684 URL: https://issues.apache.org/jira/browse/MATH-684 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Sébastien Brisard As discussed on the ML. n * x := x + x + ... + x (n times) is always meaningful. -- 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] [Closed] (MATH-662) DecompositionSolver: merging unique ...Impl classes with their interface
[
https://issues.apache.org/jira/browse/MATH-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-662.
--
Fixed in 3.0.
DecompositionSolver: merging unique ...Impl classes with their interface
--
Key: MATH-662
URL: https://issues.apache.org/jira/browse/MATH-662
Project: Commons Math
Issue Type: Task
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Trivial
Labels: linear
From the ML
{quote}
Hi.
The ...Decomposition interfaces in package linear have a unique
implementation. Should the ...Impl classes be renamed (removing the
interfaces)?
Regards,
Gilles
{quote}
--
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] [Closed] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-646.
--
Fixed in 3.0.
Unmodifiable views of RealVector
Key: MATH-646
URL: https://issues.apache.org/jira/browse/MATH-646
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, vector
Attachments: MATH-646.patch, MATH-646.patch
The issue has been discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rnuazmgpnot...@mail.gmail.com].
Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
I chose not to nest it in {{AbstractRealVector}} because it would make the
corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
Maybe you'd like it to be {{private}} as well? A static method is provided in
{{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
{{RealVector}}.
Tests are also provided. Since iterating through different implementations of
{{RealVector}} is actually different, a test is provided for
{{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
{{OpenMapRealVector}}. These tests both derive from the same abstract test
class. Hope everything works fine.
--
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] [Closed] (MATH-633) AbstractRealMatrix extends RealLinearOperator
[
https://issues.apache.org/jira/browse/MATH-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-633.
--
Fixed in 3.0.
AbstractRealMatrix extends RealLinearOperator
-
Key: MATH-633
URL: https://issues.apache.org/jira/browse/MATH-633
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Minor
Fix For: 3.0
This proposal has already been discussed on the
[forum|http://mail-archives.apache.org/mod_mbox/commons-dev/201107.mbox/4e1bc61e.8090...@m4x.org].
Since the issues raised by the implementation of {{RealLinearOperator}} are
now solved, I propose to add {{extends RealLinearOperator}} to the
declaration of {{AbstractRealMatrix}}. As far as I know, this no longer
raises any error.
--
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] [Closed] (MATH-669) UnivariateRealIntegrator throws ConvergenceException
[
https://issues.apache.org/jira/browse/MATH-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-669.
--
Fixed in 3.0.
UnivariateRealIntegrator throws ConvergenceException
Key: MATH-669
URL: https://issues.apache.org/jira/browse/MATH-669
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Minor
Fix For: 3.0
{{ConvergenceException}} is a checked exception, which goes against the
developer's guide. It occurs in the {{throws}} clause of some methods in
package o.a.c.m.analysis.integration. It seems that these occurences are
remnants from previous versions, where exceptions were probably checked. This
exception is actually never thrown : it is safe to remove it from the
{{throws}} clause.
--
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] [Closed] (MATH-686) Add methods negate() / reciprocal() to the FieldElement interface
[
https://issues.apache.org/jira/browse/MATH-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-686.
--
Fixed in 3.0.
Add methods negate() / reciprocal() to the FieldElement interface
-
Key: MATH-686
URL: https://issues.apache.org/jira/browse/MATH-686
Project: Commons Math
Issue Type: New Feature
Reporter: Sébastien Brisard
Priority: Trivial
Fix For: 3.0
As discussed on the mailing list, it is proposed to add two methods to the
{{FieldElement}} interface
* {{negate()}} : returns the additive inverse of {{this}} element.
* {{reciprocal()}} : returns the multiplicative inverse of {{this}} element.
Several name couples have been proposed by Phil
# {{negate}}, {{invert}}
# {{opposite}}, {{reciprocal}}
# {{additiveInverse}}, {{multiplicativeInverse}}
Looking at the classes implementing this interface in the core CM library, we
find that
* {{Complex}}, {{Dfp}}, {{BigFraction}} and {{Fraction}} already have a
{{negate()}} method.
* Besides, {{BigFraction}} and {{Fraction}} already have a {{reciprocal()}}
method.
So the best naming option would seem to be (for the time being) a mixture of
what Phil proposed. I realize it's not completely satisfactory because one is
a noun and one a verb. Do we want to have good grammar, or preserve what's
already implemented? I tend to favour the first option (consistently change
the name of existing methods).
--
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] [Closed] (MATH-661) Simplify interface FieldDecompositionSolver
[
https://issues.apache.org/jira/browse/MATH-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard closed MATH-661.
--
Fixed in 3.0.
Simplify interface FieldDecompositionSolver
---
Key: MATH-661
URL: https://issues.apache.org/jira/browse/MATH-661
Project: Commons Math
Issue Type: Task
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Trivial
Labels: linear
In accordance with MATH-660, {{T[] FieldDecompositionSolver.solve(T[] b)}}
should be removed.
--
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] [Created] (SANSELAN-68) Incorrect reading Physical Width/Height Dpi and Physical Width/Height from TIFF files
Incorrect reading Physical Width/Height Dpi and Physical Width/Height from TIFF
files
-
Key: SANSELAN-68
URL: https://issues.apache.org/jira/browse/SANSELAN-68
Project: Commons Sanselan
Issue Type: Bug
Components: Format: TIFF
Affects Versions: 1.0, 1.1, 1.x
Reporter: VVD
Width: 3509
Physical Width Dpi: 4650
Physical Width Inch: 1169.667
Height: 2481
Physical Height Dpi: 4650
Physical Height Inch: 827.00024
{code}
TiffImageParser.java (196):
-case 3: // Meter
-unitsPerInch = 0.0254;
+case 3: // Centimeter
+unitsPerInch = 2.54;
(c) http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
TiffImageParser.java (218):
-physicalWidthDpi = (int) (XResolutionPixelsPerUnit /
unitsPerInch);
+physicalWidthDpi = (int) Math.round(XResolutionPixelsPerUnit *
unitsPerInch);
TiffImageParser.java (226):
-physicalHeightDpi = (int) (YResolutionPixelsPerUnit /
unitsPerInch);
+physicalHeightDpi = (int) Math.round(YResolutionPixelsPerUnit
* unitsPerInch);
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
May be need to patch writing of tiff image too - don't know.
P.S. GIMP show values: 300,000, 300,000, 11,697, 8,270.
--
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] (IO-295) FileUtils.isSymlinks misses symlink folders
[ https://issues.apache.org/jira/browse/IO-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232280#comment-13232280 ] Sebb commented on IO-295: - It's far from ideal using a command shell for this, but if it is the only way it might be worth it. The class FileSystemUtils currently uses the same approach for getting the system free space, so if it is necessary to use a shell, we can re-use the process code from that class. FileUtils.isSymlinks misses symlink folders --- Key: IO-295 URL: https://issues.apache.org/jira/browse/IO-295 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Environment: Windows 7 64 bit, Oracle Java 7 Reporter: Ron Gross Attachments: IO-295.patch I created a symlink folder via mklink. Then, while debugging, I noticed that FileUtils.isSymlink() returns false on this directory, while Java 7's Files.isSymbolicLink() returns true. -- 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] (CODEC-132) BeiderMorseEncoder OOM issues
[ https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232322#comment-13232322 ] Thomas Neidhart commented on CODEC-132: --- Applied a minor change due to the referred test in lucene: use a LinkedHashSet instead of a HashSet to make ordering of phonemes deterministic BeiderMorseEncoder OOM issues - Key: CODEC-132 URL: https://issues.apache.org/jira/browse/CODEC-132 Project: Commons Codec Issue Type: Bug Affects Versions: 1.6 Reporter: Robert Muir Fix For: 1.7 Attachments: CODEC-132.patch, CODEC-132_test.patch In Lucene/Solr, we integrated this encoder into the latest release. Our tests use a variety of random strings, and we have recent jenkins failures from some input streams (of length = 10), using huge amounts of memory (e.g. 64MB), resulting in OOM. I've created a test case (length is 30 here) that will OOM with -Xmx256M. I haven't dug into this much as to what's causing it, but I suspect there might be a bug revolving around certain punctuation characters: we didn't see this happening until we beefed up our random string generation to start producing html-like strings. -- 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] (CODEC-132) BeiderMorseEncoder OOM issues
[ https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232323#comment-13232323 ] Gary D. Gregory commented on CODEC-132: --- What is the performance impact of this change? BeiderMorseEncoder OOM issues - Key: CODEC-132 URL: https://issues.apache.org/jira/browse/CODEC-132 Project: Commons Codec Issue Type: Bug Affects Versions: 1.6 Reporter: Robert Muir Fix For: 1.7 Attachments: CODEC-132.patch, CODEC-132_test.patch In Lucene/Solr, we integrated this encoder into the latest release. Our tests use a variety of random strings, and we have recent jenkins failures from some input streams (of length = 10), using huge amounts of memory (e.g. 64MB), resulting in OOM. I've created a test case (length is 30 here) that will OOM with -Xmx256M. I haven't dug into this much as to what's causing it, but I suspect there might be a bug revolving around certain punctuation characters: we didn't see this happening until we beefed up our random string generation to start producing html-like strings. -- 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] (CODEC-132) BeiderMorseEncoder OOM issues
[
https://issues.apache.org/jira/browse/CODEC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232327#comment-13232327
]
Thomas Neidhart commented on CODEC-132:
---
I have tested it with junit-benchmarks and my results are as follows:
With HashSet:
{noformat}
BeiderMorseEncoderTest.testAllChars: [measured 10 out of 15 rounds, threads: 1
(sequential)]
round: 2.85 [+- 0.01], round.gc: 0.00 [+- 0.00], GC.calls: 1213, GC.time:
0.29, time.total: 43.66, time.warmup: 15.20, time.bench: 28.45
BeiderMorseEncoderTest.testAsciiEncodeNotEmpty1Letter: [measured 10 out of 15
rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 1, GC.time: 0.00,
time.total: 0.06, time.warmup: 0.02, time.bench: 0.04
BeiderMorseEncoderTest.testAsciiEncodeNotEmpty2Letters: [measured 10 out of 15
rounds, threads: 1 (sequential)]
round: 0.18 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 72, GC.time: 0.02,
time.total: 2.79, time.warmup: 0.98, time.bench: 1.82
BeiderMorseEncoderTest.testEncodeAtzNotEmpty: [measured 10 out of 15 rounds,
threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.02, time.warmup: 0.01, time.bench: 0.01
BeiderMorseEncoderTest.testEncodeGna: [measured 10 out of 15 rounds, threads: 1
(sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testInvalidLangIllegalArgumentException: [measured 10
out of 15 rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testInvalidLangIllegalStateException: [measured 10 out
of 15 rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testInvalidLanguageIllegalArgumentException: [measured
10 out of 15 rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testLongestEnglishSurname: [measured 10 out of 15
rounds, threads: 1 (sequential)]
round: 0.01 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 1, GC.time: 0.00,
time.total: 0.10, time.warmup: 0.04, time.bench: 0.07
BeiderMorseEncoderTest.testNegativeIndexForRuleMatchIndexOutOfBoundsException:
[measured 10 out of 15 rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testOOM: [measured 10 out of 15 rounds, threads: 1
(sequential)]
round: 0.01 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 2, GC.time: 0.00,
time.total: 0.12, time.warmup: 0.04, time.bench: 0.08
BeiderMorseEncoderTest.testSetConcat: [measured 10 out of 15 rounds, threads: 1
(sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testSetNameTypeAsh: [measured 10 out of 15 rounds,
threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testSetRuleTypeExact: [measured 10 out of 15 rounds,
threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testSetRuleTypeToRulesIllegalArgumentException:
[measured 10 out of 15 rounds, threads: 1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testSpeedCheck: [measured 10 out of 15 rounds, threads:
1 (sequential)]
round: 0.41 [+- 0.01], round.gc: 0.00 [+- 0.00], GC.calls: 91, GC.time: 0.04,
time.total: 6.13, time.warmup: 2.04, time.bench: 4.09
BeiderMorseEncoderTest.testSpeedCheck2: [measured 10 out of 15 rounds, threads:
1 (sequential)]
round: 0.28 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 48, GC.time: 0.01,
time.total: 4.14, time.warmup: 1.38, time.bench: 2.76
BeiderMorseEncoderTest.testSpeedCheck3: [measured 10 out of 15 rounds, threads:
1 (sequential)]
round: 0.54 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 140, GC.time: 0.05,
time.total: 8.09, time.warmup: 2.69, time.bench: 5.39
BeiderMorseEncoderTest.testEncodeEmpty: [measured 10 out of 15 rounds, threads:
1 (sequential)]
round: 0.00 [+- 0.00], round.gc: 0.00 [+- 0.00], GC.calls: 0, GC.time: 0.00,
time.total: 0.00, time.warmup: 0.00, time.bench: 0.00
BeiderMorseEncoderTest.testEncodeNull: [measured 10 out of 15 rounds, threads:
1
[jira] [Commented] (CODEC-130) Base64InputStream.skip skips underlying stream, not output
[
https://issues.apache.org/jira/browse/CODEC-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232340#comment-13232340
]
Gary D. Gregory commented on CODEC-130:
---
Ok, I see. If the BaseNCodecInputStream class is going to be changed, you need:
- A test for Base64CodecInputStream (which you provided)
- A test for Base32CodecInputStream (missing)
- 100% code (I hope) coverage of the new skip method in BaseNCodecInputStream
Base64InputStream.skip skips underlying stream, not output
--
Key: CODEC-130
URL: https://issues.apache.org/jira/browse/CODEC-130
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.5
Reporter: James Pickering
Priority: Minor
Attachments: base64snippet.java
Base64InputStream.skip() skips within underlying stream, leading to
unexpected behaviour.
The following code will reproduce the issue:
@Test
public void testSkip() throws Throwable {
InputStream ins =
new
ByteArrayInputStream(.getBytes(ISO-8859-1));//should decode to
{0, 0, 0, 255, 255, 255}
Base64InputStream instance = new Base64InputStream(ins);
assertEquals(3L, instance.skip(3L)); //should skip 3 decoded characters,
or 4 encoded characters
assertEquals(255, instance.read()); //Currently returns 3, as it is
decoding A/, not //
}
The following code, if added to Base64InputStream, or (BaseNCodecInputStream
in the dev build) would resolve the issue:
@Override
public long skip(long n) throws IOException {
//delegate to read()
long bytesRead = 0;
while ((bytesRead n) (read() != -1)) {
bytesRead++;
}
return bytesRead;
}
More efficient code may be possible.
--
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] [Updated] (IO-295) FileUtils.isSymlinks misses symlink folders
[ https://issues.apache.org/jira/browse/IO-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcos Vinícius da Silva updated IO-295: Attachment: IO-295-1.patch A new patch. Moved the shell execution code to a new package protected class ExecUtils. FileUtils.isSymlinks misses symlink folders --- Key: IO-295 URL: https://issues.apache.org/jira/browse/IO-295 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Environment: Windows 7 64 bit, Oracle Java 7 Reporter: Ron Gross Attachments: IO-295-1.patch, IO-295.patch I created a symlink folder via mklink. Then, while debugging, I noticed that FileUtils.isSymlink() returns false on this directory, while Java 7's Files.isSymbolicLink() returns true. -- 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] [Closed] (CONFIGURATION-472) SubnodeConfigurations returned by XMLConfiguration should convert added nodes to XML nodes.
[ https://issues.apache.org/jira/browse/CONFIGURATION-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raimund Klein closed CONFIGURATION-472. --- Resolution: Cannot Reproduce Hello Oliver, Sorry for the late response. I haven't had any time to look into this again, maybe it was a misuse on my side after all. Since I haven't been working on the project I encountered the behavior in for months, this issue might as well be closed. SubnodeConfigurations returned by XMLConfiguration should convert added nodes to XML nodes. --- Key: CONFIGURATION-472 URL: https://issues.apache.org/jira/browse/CONFIGURATION-472 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.7 Reporter: Raimund Klein Priority: Minor Problem description: XMLConfiguration's configuration(s)At return regular SubnodeConfigurations which can't really be used for adding nodes as these won't be converted into XMLConfiguration's internal XMLNodes. More precisely, when using the SubnodeConfiguration for adding, accesses to the main XMLConfiguration can run into ClassCastExceptions later on. Workaround: Add the created nodes directly to the main XMLConfiguration (e.g. with the appropriate XPath), as this configuration's add methods convert these into the internal form. Proposed Solution: Let XMLConfiguration's configuration(s)At methods return a subclass of SubnodeConfiguration whose add methods will perform the same node conversion. Consequently, this new class' SubnodeConfigurations returned by configuration(s)At should be instances of the very same class. -- 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] [Created] (SANSELAN-69) Incorrect reading Physical Width/Height Inch from PNG files
Incorrect reading Physical Width/Height Inch from PNG files
---
Key: SANSELAN-69
URL: https://issues.apache.org/jira/browse/SANSELAN-69
Project: Commons Sanselan
Issue Type: Bug
Components: Format: PNG
Affects Versions: 0.97, 1.0, 1.1, 1.x
Reporter: VVD
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 1052697.9
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 744298.5
{code}
PngImageParser.java (620):
PhysicalWidthInch = (float) ((double) Width
-* (double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch);
PhysicalWidthInch = (float) ((double) Width
+/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch));
PngImageParser.java (625):
PhysicalHeightInch = (float) ((double) Height
-* (double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch);
PhysicalHeightInch = (float) ((double) Height
+/ ((double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch));
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
--
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] [Updated] (SANSELAN-69) Incorrect reading Physical Width/Height Inch from PNG files
[
https://issues.apache.org/jira/browse/SANSELAN-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
VVD updated SANSELAN-69:
Description:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 1052697.9
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 744298.5
{code}
PngImageParser.java (620):
PhysicalWidthInch = (float) ((double) Width
-* (double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch);
+/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch));
PngImageParser.java (625):
PhysicalHeightInch = (float) ((double) Height
-* (double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch);
+/ ((double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch));
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
was:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 1052697.9
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 744298.5
{code}
PngImageParser.java (620):
PhysicalWidthInch = (float) ((double) Width
-* (double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch);
PhysicalWidthInch = (float) ((double) Width
+/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch));
PngImageParser.java (625):
PhysicalHeightInch = (float) ((double) Height
-* (double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch);
PhysicalHeightInch = (float) ((double) Height
+/ ((double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch));
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
Incorrect reading Physical Width/Height Inch from PNG files
---
Key: SANSELAN-69
URL: https://issues.apache.org/jira/browse/SANSELAN-69
Project: Commons Sanselan
Issue Type: Bug
Components: Format: PNG
Affects Versions: 0.97, 1.0, 1.1, 1.x
Reporter: VVD
Labels: patch
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 1052697.9
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 744298.5
{code}
PngImageParser.java (620):
PhysicalWidthInch = (float) ((double) Width
-* (double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch);
+/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch));
PngImageParser.java (625):
PhysicalHeightInch = (float) ((double) Height
-* (double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch);
+/ ((double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch));
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
--
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] (SANSELAN-66) Sanselan can't render 48 bit pixel Tiff image (bit per samples ={16,16,16})
[
https://issues.apache.org/jira/browse/SANSELAN-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232424#comment-13232424
]
Piyush Kapoor commented on SANSELAN-66:
---
Thanks for committing my patch
Sanselan can't render 48 bit pixel Tiff image (bit per samples ={16,16,16})
---
Key: SANSELAN-66
URL: https://issues.apache.org/jira/browse/SANSELAN-66
Project: Commons Sanselan
Issue Type: Bug
Components: Format: TIFF
Environment: Windows 7 64 bit
Reporter: Piyush Kapoor
Labels: patch
Fix For: 1.0
Attachments: BinaryFileParser.java.patch, tiffimage.patch
Original Estimate: 1h
Remaining Estimate: 1h
We have a very large Tiff image tha uses 16 bits for each pixel (bits per
sample total = 48) . The class
org.apache.commons.sanselan.common.Bitinputstream didn't have support for
Endianness of the Tiff format . I added that support in the patch and image
worked absolutely fine.
The image is very large . If you want i can upload it (140 mb).Otherwise here
is the patch.
--
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
