[jira] [Issue Comment Edited] (MATH-761) Improve encapsulation of data in the nested classes of SymmLQ
[
https://issues.apache.org/jira/browse/MATH-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232487#comment-13232487
]
Sébastien Brisard edited comment on MATH-761 at 3/20/12 6:39 AM:
-
In {{r1302298}} and {{r1302785}}
* moved some {{static}} helper methods from {{SymmLQ}} to nested class
{{SymmLQ.State}}
* changed visibility of some {{static}} fields from {{private}} to {{package
protected}} in order to avoid the use of synthetic getters.
was (Author: celestin):
In {{r1302298}}
* moved some {{static}} helper methods from {{SymmLQ}} to nested class
{{SymmLQ.State}}
* changed visibility of some {{static}} fields from {{private}} to
{{protected}} in order to avoid the use of synthetic getters.
Improve encapsulation of data in the nested classes of SymmLQ
-
Key: MATH-761
URL: https://issues.apache.org/jira/browse/MATH-761
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: linear
In order to limit object creation, the current implementation of the
{{SymmLQ}} solver makes heavy use of references accross nested classes in
{{SymmLQ}}. This makes the code difficult to read, and should be modified,
keeping the public API.
--
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-761) Improve encapsulation of data in the nested classes of SymmLQ
[
https://issues.apache.org/jira/browse/MATH-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233273#comment-13233273
]
Sébastien Brisard commented on MATH-761:
In {{r1302788}}, created {{SymmLQ.State.hasConverged()}} in order to avoid
access to private field {{SymmLQ.State.hasConverged}} through synthetic getter.
Improve encapsulation of data in the nested classes of SymmLQ
-
Key: MATH-761
URL: https://issues.apache.org/jira/browse/MATH-761
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: linear
In order to limit object creation, the current implementation of the
{{SymmLQ}} solver makes heavy use of references accross nested classes in
{{SymmLQ}}. This makes the code difficult to read, and should be modified,
keeping the public API.
--
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-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233310#comment-13233310
]
Jochen Wiedmann commented on CODEC-96:
--
I agree with Henri: Document the facts and resolve the issue: Julius, as you
are the assignee, are you ready to do just that? (No need for a patch. You're a
committer, os just go on, if you are.)
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
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-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233362#comment-13233362
]
Sebb commented on CODEC-96:
---
I think it might be possible to move the mutable fields out of the lower level
classes and back into the streaming classes which are the ones that actually
need them.
Whether it is possible to do this in a compatible way, I don't yet know, but
I'd like to give it a try over then next week or so.
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
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-70) Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots per millimeter
Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots per
millimeter
--
Key: SANSELAN-70
URL: https://issues.apache.org/jira/browse/SANSELAN-70
Project: Commons Sanselan
Issue Type: Bug
Components: Format: JPEG
Affects Versions: 0.97
Environment: N/A
Reporter: Tars Joris
The value of physical with DPI is incorrect for JPEG images, which express
their resolution in dots per millimeter.
Two images are attached:
- example_ppi.jpg: Normal image, with resolution specified in dots per inch (72
pixels/in)
- example_ppmm.jpg: Same image, but with resolution specified in dots per
millimeter (2.8 pixels/mm)
When running the attached code, the output is
{code}
example_ppi.jpg
getPhysicalWidthDpi: 72
getPhysicalHeightDpi: 72
example_ppmm.jpg
getPhysicalWidthDpi: 11
getPhysicalHeightDpi: 71
{code}
While you'd expect the value 71 for getPhysicalWidthDpi for the second image.
--
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-70) Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots per millimeter
[
https://issues.apache.org/jira/browse/SANSELAN-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tars Joris updated SANSELAN-70:
---
Attachment: jpeg-dpi.patch.txt
Possible fix to the problem.
Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots
per millimeter
--
Key: SANSELAN-70
URL: https://issues.apache.org/jira/browse/SANSELAN-70
Project: Commons Sanselan
Issue Type: Bug
Components: Format: JPEG
Affects Versions: 0.97
Environment: N/A
Reporter: Tars Joris
Labels: patch
Attachments: Main.java, example_ppi.jpg, example_ppmm.jpg,
jpeg-dpi.patch.txt
The value of physical with DPI is incorrect for JPEG images, which express
their resolution in dots per millimeter.
Two images are attached:
- example_ppi.jpg: Normal image, with resolution specified in dots per inch
(72 pixels/in)
- example_ppmm.jpg: Same image, but with resolution specified in dots per
millimeter (2.8 pixels/mm)
When running the attached code, the output is
{code}
example_ppi.jpg
getPhysicalWidthDpi: 72
getPhysicalHeightDpi: 72
example_ppmm.jpg
getPhysicalWidthDpi: 11
getPhysicalHeightDpi: 71
{code}
While you'd expect the value 71 for getPhysicalWidthDpi for the second image.
--
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-70) Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots per millimeter
[
https://issues.apache.org/jira/browse/SANSELAN-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tars Joris updated SANSELAN-70:
---
Attachment: Main.java
Test code.
Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots
per millimeter
--
Key: SANSELAN-70
URL: https://issues.apache.org/jira/browse/SANSELAN-70
Project: Commons Sanselan
Issue Type: Bug
Components: Format: JPEG
Affects Versions: 0.97
Environment: N/A
Reporter: Tars Joris
Labels: patch
Attachments: Main.java, example_ppi.jpg, example_ppmm.jpg,
jpeg-dpi.patch.txt
The value of physical with DPI is incorrect for JPEG images, which express
their resolution in dots per millimeter.
Two images are attached:
- example_ppi.jpg: Normal image, with resolution specified in dots per inch
(72 pixels/in)
- example_ppmm.jpg: Same image, but with resolution specified in dots per
millimeter (2.8 pixels/mm)
When running the attached code, the output is
{code}
example_ppi.jpg
getPhysicalWidthDpi: 72
getPhysicalHeightDpi: 72
example_ppmm.jpg
getPhysicalWidthDpi: 11
getPhysicalHeightDpi: 71
{code}
While you'd expect the value 71 for getPhysicalWidthDpi for the second image.
--
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-70) Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots per millimeter
[
https://issues.apache.org/jira/browse/SANSELAN-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tars Joris updated SANSELAN-70:
---
Attachment: example_ppmm.jpg
example_ppi.jpg
Not sure about the license, the image was taken from wikipedia under the
Creative Commons Attribution-Share Alike 3.0 Unported license.
Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots
per millimeter
--
Key: SANSELAN-70
URL: https://issues.apache.org/jira/browse/SANSELAN-70
Project: Commons Sanselan
Issue Type: Bug
Components: Format: JPEG
Affects Versions: 0.97
Environment: N/A
Reporter: Tars Joris
Labels: patch
Attachments: Main.java, example_ppi.jpg, example_ppmm.jpg,
jpeg-dpi.patch.txt
The value of physical with DPI is incorrect for JPEG images, which express
their resolution in dots per millimeter.
Two images are attached:
- example_ppi.jpg: Normal image, with resolution specified in dots per inch
(72 pixels/in)
- example_ppmm.jpg: Same image, but with resolution specified in dots per
millimeter (2.8 pixels/mm)
When running the attached code, the output is
{code}
example_ppi.jpg
getPhysicalWidthDpi: 72
getPhysicalHeightDpi: 72
example_ppmm.jpg
getPhysicalWidthDpi: 11
getPhysicalHeightDpi: 71
{code}
While you'd expect the value 71 for getPhysicalWidthDpi for the second image.
--
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] (BEANUTILS-411) BeanUtilsBean.setProperty throws IllegalArgumentException if getter of nested property returns null
BeanUtilsBean.setProperty throws IllegalArgumentException if getter of nested
property returns null
---
Key: BEANUTILS-411
URL: https://issues.apache.org/jira/browse/BEANUTILS-411
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.8.3, 1.8.2, 1.8.1, 1.8.0
Environment: Apache Struts 1.3.10 (latest) uses commons-beanutils 1.8.0
Reporter: Marcus Zander
The issue is like #BEANUTILS-331, BEANUTILS-339 where BeanUtils.populate() -
BeanUtilsBean.setProperty throws an IllegalArgumentException when it should not.
error situation (see attached JUnitTest):
BeanUtilsBean.setProperty(bean,foo.bar, value) with a nested property
foo.bar where bean.getFoo() returns null.
Line 903 (in 1.8.0 -1.8.3) getPropertyUtils().getProperty(target,
resolver.next(name));
returns null (because bean.getFoo() returns null) which is not handled
correctly.
The Exception is thrown in line 963 because target == null.
expected:
SetProperty should silently return like in the case the property does not exist.
background:
BeanUtils.populate(), BeanUtilsBean.setProperty are used by Struts to populate
HTTP-Request-Parameters to form beans (form backing objects). The request sent
by a browser when clicking a input type=image name=imgLink... contains
parameters imgLink.x and imgLink.y. These request parameters should not let
to an error when populating to a bean which has the property imgLink.
The application should be able to process these parameters after bean
populating, which is not possible now because populate fails.
Test case to reproduce:
public class BeanUtilsBeanTest extends TestCase
{
public void testSetProperty()
throws Exception
{
DummyBean testBean = new DummyBean(); // nested==null
BeanUtilsBean instance = new BeanUtilsBean();
/* fails with java.lang.IllegalArgumentException: No bean specified
* Reason: getPropertyUtils().getProperty(target,
resolver.next(name)); returnes null
* because DummyBean.getImgLink() returns null
*/
instance.setProperty(testBean, imgLink.x, 1);
}
public class DummyBean
{
private String imgLink = null; // stays null
public String getImgLink ()
{
return imgLink;
}
public void setImgLink(String imgLink)
{
this.imgLink = imgLink;
}
}
}
suggestion for a fix:
Return after line 903 if getProperty returns null and therefor target becomes
null.
--
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] (NET-455) FTPClient listFiles(FTPFileFilter) can be faster...
FTPClient listFiles(FTPFileFilter) can be faster...
---
Key: NET-455
URL: https://issues.apache.org/jira/browse/NET-455
Project: Commons Net
Issue Type: Improvement
Components: FTP
Affects Versions: 3.0.1
Environment: all
Reporter: Nicolas
Priority: Minor
I tested two ways of sorting files on a remote FTP server with many files (
110 000). Both of these use the FtpFileFilter class (with a test on the
extension filename... very simple).
The first one is the conventionnal = files = ftpClient.listFiles(./,
ftpFileFilter);
It takes about 90 seconds ...
the second one is ... nearly as simple as the first one :
FTPFile [] allFilesListed = ftpClient.listFiles();
files = FTPFileFilterWithExtension.fastFilter(ftpFileFilter, allFilesListed);
The function FTPFileFilterWithExtension.fastFilter() call the same
ftpFileFilter :
public static FTPFile [] fastFilter(FTPFileFilter filter, FTPFile
ftpFileArray []) {
ArrayListFTPFile listOfFTPFiles = new ArrayListFTPFile();
for (FTPFile ftpf : ftpFileArray) {
boolean accepted = filter.accept(ftpf);
if (accepted) {
listOfFTPFiles.add(ftpf);
}
}
FTPFile resultArray [] = new FTPFile[listOfFTPFiles.size()];
return listOfFTPFiles.toArray(resultArray);
}
The second method is EIGHT times faster than the first one ... and I don't
really understand why...
--
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] (IO-311) IOUtils.read(InputStream/Reader) ignores the offset parameter
IOUtils.read(InputStream/Reader) ignores the offset parameter - Key: IO-311 URL: https://issues.apache.org/jira/browse/IO-311 Project: Commons IO Issue Type: Bug Components: Utilities Reporter: Robert Muir Attachments: IO-311.patch IOUtils.read(InputStream input, byte[] buffer, int offset, int length) and read(Reader input, char[] buffer, int offset, int length) don't take the offset parameter into account... -- 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-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234003#comment-13234003
]
Sebb commented on CODEC-96:
---
I've got a prototype which passes all the tests.
Basically I put all the mutable fields in a Context class which is created by
the appropriate stream classes and public methods. This allows the BaseN
classes to be immutable i.e. threadsafe.
Clirr reports several incompatibilities because I moved all the protected
mutable fields into the context.
However, these are protected fields, and are not really intended for use by
external code, so it's very unlikely to cause problems. I did not need to
change the test code (except where it was overriding or testing
package-protected methods), which is a good sign.
See attachment to follow.
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
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] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated CODEC-96:
--
Attachment: CODEC-96.patch
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
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-761) Improve encapsulation of data in the nested classes of SymmLQ
[
https://issues.apache.org/jira/browse/MATH-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234117#comment-13234117
]
Sébastien Brisard commented on MATH-761:
In {{r1303290}}, created
* {{boolean SymmLQ.State.bEqualsNullVector()}},
* {{boolean SymmLQ.State.betaEqualsZero()}}.
Improve encapsulation of data in the nested classes of SymmLQ
-
Key: MATH-761
URL: https://issues.apache.org/jira/browse/MATH-761
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: linear
In order to limit object creation, the current implementation of the
{{SymmLQ}} solver makes heavy use of references accross nested classes in
{{SymmLQ}}. This makes the code difficult to read, and should be modified,
keeping the public API.
--
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
