[jira] [Commented] (JEXL-144) Empty array property setting fails
[ https://issues.apache.org/jira/browse/JEXL-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811927#comment-13811927 ] Sebb commented on JEXL-144: --- What about overloaded methods? How does JEXL know which one to choose? Empty array property setting fails -- Key: JEXL-144 URL: https://issues.apache.org/jira/browse/JEXL-144 Project: Commons JEXL Issue Type: Bug Reporter: Woonsan Ko Fix For: 2.1.2, 3.0 Attachments: jexl2-empty-array-patch.txt, jexl3-empty-array-patch.txt Suppose a bean has an array property setter method (e.g, public void setStrarr(String []) ). If I use an expression like this with an empty array, then it fails with the error message, inaccessible or unknown property strarr. // example expression bean.strarr = [ ]; -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1053) QRDecomposition.getSolver() should be able to find pseudo-inverse of non-square matrices
Sean Owen created MATH-1053: --- Summary: QRDecomposition.getSolver() should be able to find pseudo-inverse of non-square matrices Key: MATH-1053 URL: https://issues.apache.org/jira/browse/MATH-1053 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Attachments: MATH-1053.patch I don't have a complete solution to this, so don't commit this as-is, but posting in case someone can get it over the line. If you process a tall m x n matrix (non-square, mn) with QRDecomposition and then call getSolver().getInverse(), you will get DimensionMismatchException. There's not a good reason the QR decomposition can't compute the least-squares solution here. The issue is that it tries to invert A by solving AX = I. The dimension of I has to match the row dimension of A, or m. However it's using the length of the diagonal of R, which is min(m,n), which is n when mn. That patch is simple and is part of the attached patch. It also includes a test case for a tall matrix. However it doesn't work for a fat matrix (mn). There's a test case for that too. It returns an n x m value but the rows for i = m are 0 and are not computed. I'm not sure enough about the shape of the computation to be able to fix it, but it is where it's solving the triangular system Rx = y. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1053) QRDecomposition.getSolver() should be able to find pseudo-inverse of non-square matrices
[ https://issues.apache.org/jira/browse/MATH-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1053: Attachment: MATH-1053.patch QRDecomposition.getSolver() should be able to find pseudo-inverse of non-square matrices Key: MATH-1053 URL: https://issues.apache.org/jira/browse/MATH-1053 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Attachments: MATH-1053.patch I don't have a complete solution to this, so don't commit this as-is, but posting in case someone can get it over the line. If you process a tall m x n matrix (non-square, mn) with QRDecomposition and then call getSolver().getInverse(), you will get DimensionMismatchException. There's not a good reason the QR decomposition can't compute the least-squares solution here. The issue is that it tries to invert A by solving AX = I. The dimension of I has to match the row dimension of A, or m. However it's using the length of the diagonal of R, which is min(m,n), which is n when mn. That patch is simple and is part of the attached patch. It also includes a test case for a tall matrix. However it doesn't work for a fat matrix (mn). There's a test case for that too. It returns an n x m value but the rows for i = m are 0 and are not computed. I'm not sure enough about the shape of the computation to be able to fix it, but it is where it's solving the triangular system Rx = y. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROXY-19) Website: missing Download link
[ https://issues.apache.org/jira/browse/PROXY-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved PROXY-19. -- Resolution: Fixed Added the download link to the menu and published the site. Website: missing Download link Key: PROXY-19 URL: https://issues.apache.org/jira/browse/PROXY-19 Project: Commons Proxy Issue Type: Bug Reporter: Sebb There does not appear to be a download link anyhere on the website -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1054) Standardize x = x op y to x op= y
Sean Owen created MATH-1054: --- Summary: Standardize x = x op y to x op= y Key: MATH-1054 URL: https://issues.apache.org/jira/browse/MATH-1054 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Here's one of a series of proposed small simplification/optimizations across the code base. This can be rejected. The change is to standardize expressions like: x[i] = x[i] + b; to: x[i] += b; ... for any operation that has an 'op=' version. The resulting byte code is very marginally faster since the target is evaluated once; this might matter in a tight loop manipulating a 2D array cell. There's a minor argument that it is simpler code. Since both styles appear in the code now, this would also represent a tiny standardization. The counter-argument is that x += foo might risk being misread more readily as x = foo -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1054) Standardize x = x op y to x op= y
[ https://issues.apache.org/jira/browse/MATH-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1054: Attachment: MATH-1054.patch Standardize x = x op y to x op= y - Key: MATH-1054 URL: https://issues.apache.org/jira/browse/MATH-1054 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Attachments: MATH-1054.patch Here's one of a series of proposed small simplification/optimizations across the code base. This can be rejected. The change is to standardize expressions like: x[i] = x[i] + b; to: x[i] += b; ... for any operation that has an 'op=' version. The resulting byte code is very marginally faster since the target is evaluated once; this might matter in a tight loop manipulating a 2D array cell. There's a minor argument that it is simpler code. Since both styles appear in the code now, this would also represent a tiny standardization. The counter-argument is that x += foo might risk being misread more readily as x = foo -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812066#comment-13812066
]
Oliver Heger commented on BEANUTILS-450:
I see. How do you ensure that the converter registration actually happens
before their use? In the first approach using a static block in an utility
class, was the utility class accessed by all threads before converters were
used? How is this solved in the revised version?
BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7
parallelized class loader
--
Key: BEANUTILS-450
URL: https://issues.apache.org/jira/browse/BEANUTILS-450
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils, ConvertUtils Converters
Affects Versions: 1.7.0
Environment: Java 7u25+, Windows 7 32-bit desktop environments
Reporter: Matthew Hall
Priority: Blocker
From an email I sent to the BeanUtils users mailing list:
We recently tracked a bug in our software that started showing up with Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
meaning that the class loader that handled the registration of our converters
was the same class loader that was in use when ConvertUtilsBean.getInstance()
was invoked. Now, with Java 7, it seems that there is no guarantee that the
class loader that executes the static block containing the Converter
registration is the same one in use when ConvertUtilsBean.getInstance() is
invoked, meaning that our custom Converters are not necessarily available
everywhere they used to be.
I’m writing to the list today to ask three things about this situation:
1. First off, is this the correct explanation for the reason that it seems
we’re not guaranteed to have our custom Converters loaded in Java 7.
2. In order to ensure that a different class loader thread is not in use
when the Converters are registered with ConvertUtils, we’ve moved this
registration from a static class-level block into a user interface setup
method that is executed before the Converters are used.
3. Given that Java 7 introduced parallelized class loading in the base
ClassLoader and that BeanUtilsBean builds instances on a per-classloader
basis, should this issue be raised to the BeanUtils developers?
Below you’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = new MainGUIClass();
mainGui.setup();
mainGui.show();
}
public void setup() {
UIManager.setLookAndFeel(new LookAndFeelClass());
}
public void show() {
((OurLookAndFeelClass) UIManager.getLookAndFeel()).getColor();
}
...
}
public class LookAndFeelClass extends LookAndFeel {
...
public java.awt.Color getColor(String colorString) {
return (java.awt.Color) ConvertUtils.convert(someValidColorString,
java.awt.Color.class);
}
...
}
{code}
In the above example, the cast of the results of ConvertUtils.convert to
Color in LookAndFeelClass.getColor(String) sometimes results in a runtime
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. This appears to be due to the fact that
ConvertUtils.convert() fails over to the built-in String.class Converter if
it cannot find a Converter for the specified class. In production
environments, it was completely unpredictable as to when this would happen
and what would make the problem go away.
The fix we implemented was to move the registration of
OurCustomColorConverter() from the static block inside of UtilitiesClass to
the first line of MainGUIClass.setup(), before the LookAndFeel is loaded.
Will this fix be sufficient, or does it still suffer from the thread issue,
if that is indeed the root cause of the problem?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (MATH-1055) Fix some javadoc errors; add @Deprecated annotations to @deprecated methods
Sean Owen created MATH-1055: --- Summary: Fix some javadoc errors; add @Deprecated annotations to @deprecated methods Key: MATH-1055 URL: https://issues.apache.org/jira/browse/MATH-1055 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Trivial Attachments: MATH-1055.patch And here is another patch touching up some javadoc problems -- missing or outdated references, and along the way, adding @Deprecated annotations to methods javadoc'ed as @deprecated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1054) Standardize x = x op y to x op= y
[
https://issues.apache.org/jira/browse/MATH-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812157#comment-13812157
]
Gilles commented on MATH-1054:
--
Thanks for the work. Unfortunately, the better code now triggers several
errors in the CheckStyle report:
{noformat}
Unnecessary parentheses around assignment right-hand side.
{noformat}
An example is:
{code}
bits |= (((long) next(32)) 0xL);
{code}
Would you care to silence CheckStyle by removing the superfluous pair of
parentheses?
Standardize x = x op y to x op= y
-
Key: MATH-1054
URL: https://issues.apache.org/jira/browse/MATH-1054
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.2
Reporter: Sean Owen
Priority: Minor
Attachments: MATH-1054.patch
Here's one of a series of proposed small simplification/optimizations across
the code base. This can be rejected.
The change is to standardize expressions like:
x[i] = x[i] + b;
to:
x[i] += b;
... for any operation that has an 'op=' version. The resulting byte code is
very marginally faster since the target is evaluated once; this might matter
in a tight loop manipulating a 2D array cell.
There's a minor argument that it is simpler code. Since both styles appear in
the code now, this would also represent a tiny standardization.
The counter-argument is that x += foo might risk being misread more readily
as x = foo
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (MATH-983) Add an overview of all supported real distributions
[ https://issues.apache.org/jira/browse/MATH-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-983. -- Resolution: Fixed Fix Version/s: 3.3 Add an overview of all supported real distributions --- Key: MATH-983 URL: https://issues.apache.org/jira/browse/MATH-983 Project: Commons Math Issue Type: Sub-task Reporter: Thomas Neidhart Priority: Minor Fix For: 3.3 Attachments: RealDistributionComparison.java, distributions.png -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (JEXL-144) Empty array property setting fails
[ https://issues.apache.org/jira/browse/JEXL-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko updated JEXL-144: Attachment: jexl3-empty-array-patch-2.txt jexl2-empty-array-patch-2.txt Hi Sebb, That's a good point! My initial patch just chose the first found one, but I don't think it was quite right. So, I'm uploading new patches (jexl2-empty-array-patch-2.txt for 2.0 branch and jexl3-empty-array-patch-2.txt for trunk), which now fails to find the setter method if there's an ambiguity due to the overloaded setter methods. JEXL can now report the following exception message in that case: 'quux.arr2 = [ ];' unknown, ambiguous or inaccessible property arr2 In summary, JEXL can now set an empty array if there's only one setter method with the property name and array type parameter, but it fails and reports the ambiguity if there are any other overloaded methods. I think this should be fine. Please review those. Cheers, Woonsan Empty array property setting fails -- Key: JEXL-144 URL: https://issues.apache.org/jira/browse/JEXL-144 Project: Commons JEXL Issue Type: Bug Reporter: Woonsan Ko Fix For: 2.1.2, 3.0 Attachments: jexl2-empty-array-patch-2.txt, jexl2-empty-array-patch.txt, jexl3-empty-array-patch-2.txt, jexl3-empty-array-patch.txt Suppose a bean has an array property setter method (e.g, public void setStrarr(String []) ). If I use an expression like this with an empty array, then it fails with the error message, inaccessible or unknown property strarr. // example expression bean.strarr = [ ]; -- This message was sent by Atlassian JIRA (v6.1#6144)
