[jira] [Created] (SANSELAN-62) Bit depth wrongly calculated in GIFFimageparser
Bit depth wrongly calculated in GIFFimageparser --- Key: SANSELAN-62 URL: https://issues.apache.org/jira/browse/SANSELAN-62 Project: Commons Sanselan Issue Type: Bug Components: Format: GIF Reporter: Piyush Kapoor Priority: Minor File : GifImahgeParser.java Formula used for calculating Bits per pixel is wrong . It should be int BitsPerPixel = (bhi.colorResolution + 1) ; instead of int BitsPerPixel = (bhi.colorResolution + 1) * 3; -- 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] (DBCP-376) Thread safety issue
[
https://issues.apache.org/jira/browse/DBCP-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191864#comment-13191864
]
Dave Oxley commented on DBCP-376:
-
I've just recreated the same issue with snapshots of dbcp2 and pool2. Here is
the output:
{noformat}
Loading JDBC driver:
JDBC driver loaded succesfully
INFO - checkpointClose start
INFO - checkpointClose end
CLOSING DOWN CONNECTION AS IT COULD NOT BE RETURNED TO THE POOL
java.sql.SQLException: PooledConnection was reused, withoutits previous
Connection being closed.
at
org.apache.commons.dbcp2.cpdsadapter.PooledConnectionImpl.getConnection(PooledConnectionImpl.java:184)
at
org.apache.commons.dbcp2.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:778)
at
org.apache.commons.dbcp2.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:685)
at com.daveoxley.dbcpbug.App$TestThread.run(App.java:143)
at java.lang.Thread.run(Thread.java:662)
CLOSING DOWN CONNECTION AS IT COULD NOT BE RETURNED TO THE POOL
CLOSING DOWN CONNECTION AS IT COULD NOT BE RETURNED TO THE POOL
java.sql.SQLException: Attempted to use PooledConnection after closed() was
called.
at
org.apache.commons.dbcp2.cpdsadapter.PooledConnectionImpl.assertOpen(PooledConnectionImpl.java:167)
at
org.apache.commons.dbcp2.cpdsadapter.PooledConnectionImpl.getConnection(PooledConnectionImpl.java:179)
at
org.apache.commons.dbcp2.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:778)
at
org.apache.commons.dbcp2.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:685)
at com.daveoxley.dbcpbug.App$TestThread.run(App.java:143)
at java.lang.Thread.run(Thread.java:662)
{noformat}
> Thread safety issue
> ---
>
> Key: DBCP-376
> URL: https://issues.apache.org/jira/browse/DBCP-376
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Dave Oxley
>Priority: Critical
> Attachments: dbcp_bug.tar.gz
>
>
> Under high load commons-dbcp (or commons-pool) exhibits thread safety issues
> and begins throwing various exceptions. I don't yet know the cause of the
> issue but it looks like a connection maybe handed out to multiple threads
> concurrently. Here's a few examples of the exceptions we are getting:
> {noformat}
> jvm 1| Caused by: java.sql.SQLException: Attempted to use
> PooledConnection after closed() was called.
> jvm 1| at
> org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl.assertOpen(PooledConnectionImpl.java:163)
> jvm 1| at
> org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl.getConnection(PooledConnectionImpl.java:174)
> jvm 1| at
> org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:768)
> jvm 1| at
> org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:676)
> jvm 1| at
> uk.co.webessence.kernel.database.DriverAdapterConnectionPool.acquireConnection(DriverAdapterConnectionPool.java:101)
> jvm 1| ... 94 more
> {noformat}
> {noformat}
> jvm 1| Caused by: java.sql.SQLException: PooledConnection was reused,
> withoutits previous Connection being closed.
> jvm 1| at
> org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl.getConnection(PooledConnectionImpl.java:179)
> jvm 1| at
> org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:768)
> jvm 1| at
> org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:676)
> jvm 1| at
> uk.co.webessence.kernel.database.DriverAdapterConnectionPool.acquireConnection(DriverAdapterConnectionPool.java:101)
> jvm 1| ... 77 more
> {noformat}
> {noformat}
> jvm 1| Caused by: java.sql.SQLException: Invalid state, the ResultSet
> object is closed.
> jvm 1| at
> net.sourceforge.jtds.jdbc.JtdsResultSet.checkOpen(JtdsResultSet.java:299)
> jvm 1| at
> net.sourceforge.jtds.jdbc.JtdsResultSet.getColumn(JtdsResultSet.java:273)
> jvm 1| at
> net.sourceforge.jtds.jdbc.JtdsResultSet.getObject(JtdsResultSet.java:840)
> jvm 1| at
> org.apache.commons.dbcp.DelegatingResultSet.getObject(DelegatingResultSet.java:325)
> jvm 1| at
> uk.co.webessence.kernel.persistence.Preloader.getDataArray(Preloader.java:428)
> jvm 1| at
> uk.co.webessence.kernel.persistence.Preloader.processSingleRow(Preloader.java:175)
> jvm 1| at
> uk.co.webessence.kernel.persistence.PersistenceHandler.processRecordReload(PersistenceHandler.java:471)
> jvm 1| at
> uk.co.webessence.kernel.persistence.PersistenceHandler$1.d
[jira] [Updated] (JCS-87) Migrate to build with Maven 3.0
[ https://issues.apache.org/jira/browse/JCS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diego Rivera updated JCS-87: Attachment: pom.xml Updated pom.xml which permits proper building and execution of tests with Maven 3 (probably also Maven 2). Please verify that nothing was left out, and that all tests (unit, performance, integration, etc) pass. I tried it on my end and they seemed to work (except the aforementioned exception). > Migrate to build with Maven 3.0 > --- > > Key: JCS-87 > URL: https://issues.apache.org/jira/browse/JCS-87 > Project: Commons JCS > Issue Type: Improvement >Affects Versions: jcs-1.3 >Reporter: Diego Rivera > Attachments: pom.xml > > Original Estimate: 72h > Remaining Estimate: 72h > > Evidently, the documentation clearly states that Maven 1.x is the only > supported mechanism to build JCS. However, this is very dated and it > wouldn't be a bad idea to update the build process to more modern/current > standards. > I've tried to do this, and have run into a few snags wrt tests - I get many > unit tests failures in what I expect should have been trivial tests: > Failed tests: > testIndexedDiskCache4(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheSameRegionConcurrentUnitTest$4): > expected: but was: > > testIndexedDiskCache5(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheSameRegionConcurrentUnitTest$5): > expected: but was: > > testIndexedDiskCache1(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheNoMemoryUnitTest$1): > expected: but was: > > testIndexedDiskCache3(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheNoMemoryUnitTest$3): > expected: but was: > > testIndexedDiskCache2(org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheNoMemoryUnitTest$2): > expected: but was: > > testBlockDiskCache1(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$1): > Wrong value for key [0:key] expected: but > was: > > testBlockDiskCache2(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$2): > Wrong value for key [1000:key] expected: 1000-blockRegion4> but was: > > testBlockDiskCache3(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$3): > Wrong value for key [2000:key] expected: 2000-blockRegion4> but was: > > testBlockDiskCache4(org.apache.jcs.auxiliary.disk.block.BlockDiskCacheSameRegionConcurrentUnitTest$4): > Wrong value for key [2200:key] expected: 2200-blockRegion4> but was: > > testExpireInBackground(org.apache.jcs.auxiliary.disk.jdbc.JDBCDiskCacheShrinkUnitTest): > Removed key should be null: 0:key > > testSpoolEvent(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest): > The number of ELEMENT_EVENT_SPOOLED_DISK_AVAILABLE events [0] does not equal > the number expected [2] > > testSpoolNoDiskEvent(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest): > The number of ELEMENT_EVENT_SPOOLED_DISK_NOT_AVAILABLE events [19002] does > not equal the number expected. > > testSpoolNotAllowedEvent(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest): > The number of ELEMENT_EVENT_SPOOLED_NOT_ALLOWED events [0] does not equal > the number expected. > > testSpoolNotAllowedEventOnItem(org.apache.jcs.engine.control.event.SimpleEventHandlingUnitTest): > The number of ELEMENT_EVENT_SPOOLED_NOT_ALLOWED events [0] does not equal > the number expected. > > testUpdateConfig(org.apache.jcs.engine.control.CompositeCacheDiskUsageUnitTest): > expected:<1> but was:<0> > testSystemPropertyUsage(org.apache.jcs.engine.SystemPropertyUsageUnitTest): > System property value is not reflected expected:<1000> but was:<6789> > testLoadFromCCF(org.apache.jcs.engine.memory.mru.MRUMemoryCacheUnitTest): > Cache name should have MRU in it. > > testGetStatsThroughHub(org.apache.jcs.engine.memory.mru.MRUMemoryCacheUnitTest): > Should have 200 puts > > testDefaultConfigUndefinedPool(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest): > expected:<150> but was:<151> > > testNonExistentConfigFile(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest): > expected:<150> but was:<151> > > testWaitPolicyConfig(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest): > Max is wrong expected:<150> but was:<11> > testNoBoundary(org.apache.jcs.utils.threadpool.ThreadPoolManagerUnitTest): > Should have a linked queue and not a bounded buffer. > > testSystemPropertyInValueDelimeter(org.apache.jcs.access.SystemPropetyUnitTest): > We should have used the system property for the memory size expected:<1234> > but was:<6789> > Tests in error: > > test(org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPFilterRemoveHashCodeUnitTest): > Socket is null, cannot connect to localhost:1110 >
[jira] [Updated] (JCS-88) Block cache fails to validate a cache file on startup when it contains elements with more than 2 blocks.
[
https://issues.apache.org/jira/browse/JCS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Rivera updated JCS-88:
Comment: was deleted
(was: diff -ruN
/home/diego/Desktop/jcs-1.3/src/test/org/apache/jcs/auxiliary/disk/block/BlockDiskUnitTest.java
src/test/org/apache/jcs/auxiliary/disk/block/BlockDiskUnitTest.java
---
/home/diego/Desktop/jcs-1.3/src/test/org/apache/jcs/auxiliary/disk/block/BlockDiskUnitTest.java
2007-05-30 12:23:53.0 -0600
+++ src/test/org/apache/jcs/auxiliary/disk/block/BlockDiskUnitTest.java
2012-01-23 17:06:10.983067430 -0600
@@ -20,6 +20,7 @@
*/
import java.io.File;
+import java.util.Random;
import junit.framework.TestCase;
@@ -217,14 +218,20 @@
int bytes = getBytesForBlocksOfByteArrays( disk.getBlockSizeBytes(),
numBlocksPerElement );
int numElements = 100;
+Random r = new Random(System.currentTimeMillis());
for ( int i = 0; i < numElements; i++ )
{
-int[] blocks = disk.write( new byte[bytes] );
+ byte[] src = new byte[bytes];
+ r.nextBytes(src); // Ensure we don't just write zeros out
+int[] blocks = disk.write( src );
byte[] result = (byte[]) disk.read( blocks );
// VERIFY
-assertEquals( "Wrong item retured.", new byte[bytes].length,
result.length );
+assertEquals( "Wrong item length retured.", src.length,
result.length );
assertEquals( "Wrong number of blocks returned.",
numBlocksPerElement, blocks.length );
+for (int j = 0 ; j < src.length ; j++) {
+ assertEquals( "Mismatch at offset " + j + " in attempt # " + (i
+ 1), src[j], result[j] );
+}
}
System.out.println( "testWriteAndReadMultipleMultiBlockElement_setSize
" + disk );
assertEquals( "Wrong number of elements.", numBlocksPerElement *
numElements, disk.getNumberOfBlocks() );
)
> Block cache fails to validate a cache file on startup when it contains
> elements with more than 2 blocks.
>
>
> Key: JCS-88
> URL: https://issues.apache.org/jira/browse/JCS-88
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-1.3
>Reporter: Diego Rivera
> Attachments: jcs-1.3a-JCS-87-patch.patch
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The arithmetic for calculating block sizes is wrong. The code adds a term
> that shouldn't be considered at that point. For each block that needs to be
> written, the size of the block is currently calculated as:
> int chunkSize = Math.min( totalUsed + maxChunkSize, totalBytes - totalUsed )
> The term "totalUsed" should not be added to maxChunkSize, since the intent is
> to construct a chunk that's either as big as is allowed (maxChunkSize) or as
> big as the remaining bytes (totalBytes - totalUsed). Thus, the correct
> calculation should be:
> int chunkSize = Math.min( maxChunkSize, totalBytes - totalUsed )
> The problem occurs in
> src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java, line 196, inside
> byte[][] getBlockChunks(byte[] complete, int numBlocksNeeded).
> A patch has been devised and will be submitted as a comment (since
> attachments aren't possible at this point). I still need to take the time to
> devise a unit test for this since the existing unit test passed without issue.
--
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] (JCS-88) Block cache fails to validate a cache file on startup when it contains elements with more than 2 blocks.
[ https://issues.apache.org/jira/browse/JCS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diego Rivera updated JCS-88: Attachment: jcs-1.3a-JCS-87-patch.patch This patch applies to JCS 1.3, and fixes the issue completely. An updated unit test is included which both exposes the problem and confirms the fix. > Block cache fails to validate a cache file on startup when it contains > elements with more than 2 blocks. > > > Key: JCS-88 > URL: https://issues.apache.org/jira/browse/JCS-88 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-1.3 >Reporter: Diego Rivera > Attachments: jcs-1.3a-JCS-87-patch.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > The arithmetic for calculating block sizes is wrong. The code adds a term > that shouldn't be considered at that point. For each block that needs to be > written, the size of the block is currently calculated as: > int chunkSize = Math.min( totalUsed + maxChunkSize, totalBytes - totalUsed ) > The term "totalUsed" should not be added to maxChunkSize, since the intent is > to construct a chunk that's either as big as is allowed (maxChunkSize) or as > big as the remaining bytes (totalBytes - totalUsed). Thus, the correct > calculation should be: > int chunkSize = Math.min( maxChunkSize, totalBytes - totalUsed ) > The problem occurs in > src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java, line 196, inside > byte[][] getBlockChunks(byte[] complete, int numBlocksNeeded). > A patch has been devised and will be submitted as a comment (since > attachments aren't possible at this point). I still need to take the time to > devise a unit test for this since the existing unit test passed without issue. -- 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] (JCS-88) Block cache fails to validate a cache file on startup when it contains elements with more than 2 blocks.
[
https://issues.apache.org/jira/browse/JCS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Rivera updated JCS-88:
Comment: was deleted
(was: diff -ruN
jcs-1.3/src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java
jcs-1.3.new/src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java
--- jcs-1.3/src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java
2007-05-30 12:23:53.0 -0600
+++ jcs-1.3.new/src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java
2012-01-23 14:33:07.437164316 -0600
@@ -193,7 +193,7 @@
{
// use the max that can be written to a block or whatever is
left in the original
// array
-int chunkSize = Math.min( totalUsed + maxChunkSize, totalBytes
- totalUsed );
+int chunkSize = Math.min( maxChunkSize, totalBytes - totalUsed
);
byte[] chunk = new byte[chunkSize];
// copy from the used position to the chunk size on the
complete array to the chunk
// array.)
> Block cache fails to validate a cache file on startup when it contains
> elements with more than 2 blocks.
>
>
> Key: JCS-88
> URL: https://issues.apache.org/jira/browse/JCS-88
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-1.3
>Reporter: Diego Rivera
> Attachments: jcs-1.3a-JCS-87-patch.patch
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The arithmetic for calculating block sizes is wrong. The code adds a term
> that shouldn't be considered at that point. For each block that needs to be
> written, the size of the block is currently calculated as:
> int chunkSize = Math.min( totalUsed + maxChunkSize, totalBytes - totalUsed )
> The term "totalUsed" should not be added to maxChunkSize, since the intent is
> to construct a chunk that's either as big as is allowed (maxChunkSize) or as
> big as the remaining bytes (totalBytes - totalUsed). Thus, the correct
> calculation should be:
> int chunkSize = Math.min( maxChunkSize, totalBytes - totalUsed )
> The problem occurs in
> src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java, line 196, inside
> byte[][] getBlockChunks(byte[] complete, int numBlocksNeeded).
> A patch has been devised and will be submitted as a comment (since
> attachments aren't possible at this point). I still need to take the time to
> devise a unit test for this since the existing unit test passed without issue.
--
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-575) Exceptions in genetics package or not consistent with the rest of [math]
[ https://issues.apache.org/jira/browse/MATH-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191602#comment-13191602 ] Gilles commented on MATH-575: - Thanks for working on this, but before you do start to make modifications, please assign the issue to yourself! For the changes themselves, I don't agree with the creation of those many localized messages: We have been trying to rationalize and reduce the number of those, by removing duplicates and combining several ones to convey the full explanation of the problem. See my reply to the commit message. > Exceptions in genetics package or not consistent with the rest of [math] > > > Key: MATH-575 > URL: https://issues.apache.org/jira/browse/MATH-575 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.0, 2.1, 2.2 >Reporter: Phil Steitz >Priority: Minor > Fix For: 3.0 > > > InvalidRepresentationException is checked and non-localized. This exception > should be placed in the [math] hierarchy. The AbstractListChromosome > constructor also throws a non-localised IAE, which should be replaced by an > appropriate [math] exception. -- 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] (JCS-88) Block cache fails to validate a cache file on startup when it contains elements with more than 2 blocks.
[
https://issues.apache.org/jira/browse/JCS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191596#comment-13191596
]
Diego Rivera commented on JCS-88:
-
diff -ruN
/home/diego/Desktop/jcs-1.3/src/test/org/apache/jcs/auxiliary/disk/block/BlockDiskUnitTest.java
src/test/org/apache/jcs/auxiliary/disk/block/BlockDiskUnitTest.java
---
/home/diego/Desktop/jcs-1.3/src/test/org/apache/jcs/auxiliary/disk/block/BlockDiskUnitTest.java
2007-05-30 12:23:53.0 -0600
+++ src/test/org/apache/jcs/auxiliary/disk/block/BlockDiskUnitTest.java
2012-01-23 17:06:10.983067430 -0600
@@ -20,6 +20,7 @@
*/
import java.io.File;
+import java.util.Random;
import junit.framework.TestCase;
@@ -217,14 +218,20 @@
int bytes = getBytesForBlocksOfByteArrays( disk.getBlockSizeBytes(),
numBlocksPerElement );
int numElements = 100;
+Random r = new Random(System.currentTimeMillis());
for ( int i = 0; i < numElements; i++ )
{
-int[] blocks = disk.write( new byte[bytes] );
+ byte[] src = new byte[bytes];
+ r.nextBytes(src); // Ensure we don't just write zeros out
+int[] blocks = disk.write( src );
byte[] result = (byte[]) disk.read( blocks );
// VERIFY
-assertEquals( "Wrong item retured.", new byte[bytes].length,
result.length );
+assertEquals( "Wrong item length retured.", src.length,
result.length );
assertEquals( "Wrong number of blocks returned.",
numBlocksPerElement, blocks.length );
+for (int j = 0 ; j < src.length ; j++) {
+ assertEquals( "Mismatch at offset " + j + " in attempt # " + (i
+ 1), src[j], result[j] );
+}
}
System.out.println( "testWriteAndReadMultipleMultiBlockElement_setSize
" + disk );
assertEquals( "Wrong number of elements.", numBlocksPerElement *
numElements, disk.getNumberOfBlocks() );
> Block cache fails to validate a cache file on startup when it contains
> elements with more than 2 blocks.
>
>
> Key: JCS-88
> URL: https://issues.apache.org/jira/browse/JCS-88
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-1.3
>Reporter: Diego Rivera
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The arithmetic for calculating block sizes is wrong. The code adds a term
> that shouldn't be considered at that point. For each block that needs to be
> written, the size of the block is currently calculated as:
> int chunkSize = Math.min( totalUsed + maxChunkSize, totalBytes - totalUsed )
> The term "totalUsed" should not be added to maxChunkSize, since the intent is
> to construct a chunk that's either as big as is allowed (maxChunkSize) or as
> big as the remaining bytes (totalBytes - totalUsed). Thus, the correct
> calculation should be:
> int chunkSize = Math.min( maxChunkSize, totalBytes - totalUsed )
> The problem occurs in
> src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java, line 196, inside
> byte[][] getBlockChunks(byte[] complete, int numBlocksNeeded).
> A patch has been devised and will be submitted as a comment (since
> attachments aren't possible at this point). I still need to take the time to
> devise a unit test for this since the existing unit test passed without issue.
--
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] (SANDBOX-355) Provide Flow algorithms
[
https://issues.apache.org/jira/browse/SANDBOX-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claudio Squarcella updated SANDBOX-355:
---
Attachment: SANDBOX-355_FordFulkersonImplementationAndTest.patch
Hi,
find attached an implementation for the algorithm of Ford and Fulkerson to find
the max flow in a network.
The implementation is split between a main class {{FordFulkerson}} which
provides two public methods (one for generic weights, the other for {{Integer}}
weights) and an auxiliary class {{FlowNetworkHandler}} which does the dirty
job.
I also implemented a test using [this
example|http://en.wikipedia.org/wiki/Ford%E2%80%93Fulkerson_algorithm#Integral_example]
and it runs just fine.
I am available for clarifications and comments.
Ciao,
Claudio
> Provide Flow algorithms
> ---
>
> Key: SANDBOX-355
> URL: https://issues.apache.org/jira/browse/SANDBOX-355
> Project: Commons Sandbox
> Issue Type: New Feature
> Components: Graph
>Reporter: Simone Tripodi
> Attachments: SANDBOX-355_FordFulkersonImplementationAndTest.patch
>
>
> right now the {{org.apache.commons.graph.flow}} package contains an empty
> implementation of
> [Ford-Fulkerson|http://en.wikipedia.org/wiki/Ford%E2%80%93Fulkerson_algorithm]'s
> algorithm, that needs to be filled.
> Other algorithms that work on resolving Flow-related problems, are welcome.
--
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-575) Exceptions in genetics package or not consistent with the rest of [math]
[ https://issues.apache.org/jira/browse/MATH-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191560#comment-13191560 ] Thomas Neidhart commented on MATH-575: -- Phil started to work on this issue in r1135025. In r1235038 additional cleanups have been performed: - add localized messages for all exceptions - add @throws to javadoc where appropriate - add final to method parameters What is missing: - Phil mentioned that InvalidRepresentationException should be placed into [math], although I am not sure why, as it is not used outside the genetics package - add more custom exception classes specific to the genetics package (optional). By now mostly MathIllegalArgumentException or other appropriate ones have been used. > Exceptions in genetics package or not consistent with the rest of [math] > > > Key: MATH-575 > URL: https://issues.apache.org/jira/browse/MATH-575 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.0, 2.1, 2.2 >Reporter: Phil Steitz >Priority: Minor > Fix For: 3.0 > > > InvalidRepresentationException is checked and non-localized. This exception > should be placed in the [math] hierarchy. The AbstractListChromosome > constructor also throws a non-localised IAE, which should be replaced by an > appropriate [math] exception. -- 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] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191513#comment-13191513 ] Simone Tripodi commented on SANDBOX-362: Terrific :) I have already applied your patch, see [r1235012|https://svn.apache.org/viewvc?view=revision&revision=1235012], thanks for contributing!!! > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: ArgumentTest.zip, > SANDBOX-362-RefactoringOfArgumentTest.txt > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * TypeUtils -- 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] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191495#comment-13191495 ] Benedikt Ritter edited comment on SANDBOX-362 at 1/23/12 9:43 PM: -- Based on a discussion we had on the mailing list about best practices for unit tests, I refactored ArgumentTest and added test methods for getParamaters(Argument... args). Here is a summary of what I changed: * separated long methods into very small methods: each primitive type has it's own test methods * defined fields for every primitive type, to make sure that assertions do not accedential fail because wrong values get compared * created separate test methods instead of wrapping failure cases inside try/catch-blocks * Added tests methods that test against TestBean.class Please let me know, what you think about the changes! was (Author: britter): Based on a discussion we had on the mailing list about best practices for unit tests, I refactored ArgumentTest and added test methods for getParamaters(Argument... args). Here is a summary of what I changed: * separated long methods into very small methods: each primitive type has it's own test methods * defined fields for every primitive type, to make sure that assertions do not accedential fail because wrong values get compared * Added tests methods that test against TestBean.class Please let me know, what you think about the changes! > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: ArgumentTest.zip, > SANDBOX-362-RefactoringOfArgumentTest.txt > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * TypeUtils -- 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] (SANDBOX-367) Move base implementations from test to main
[
https://issues.apache.org/jira/browse/SANDBOX-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-367.
Resolution: Fixed
Assignee: Simone Tripodi
Can you bet this was something I already had in mind? Providing basic
implementations for users that just need extending, is IMHO comfortable.
Patch applied, see
[r1235005|https://svn.apache.org/viewvc?view=revision&revision=1235005].
Thanks once again!
> Move base implementations from test to main
> ---
>
> Key: SANDBOX-367
> URL: https://issues.apache.org/jira/browse/SANDBOX-367
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Assignee: Simone Tripodi
>Priority: Trivial
> Labels: graph, implementations, main, model, test
> Attachments: MoveBaseImplementationsFromTestToMain.patch,
> SANDBOX-367_MoveBaseImplementationsFromTestToMain.patch
>
>
> Hi,
> very tiny patch to move default implementations from test (in package
> {{model}}: {{BaseLabeledEdge}}, {{BaseLabeledWeightedEdge}} and
> {{BaseLabeledVertex}}) to main. Needed for other implementations that require
> manipulation of input graphs -- e.g. the upcoming Ford-Fulkerson ;)
--
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] (SANDBOX-362) Create basic unit tests for all classes
[ https://issues.apache.org/jira/browse/SANDBOX-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated SANDBOX-362: Attachment: SANDBOX-362-RefactoringOfArgumentTest.txt Based on a discussion we had on the mailing list about best practices for unit tests, I refactored ArgumentTest and added test methods for getParamaters(Argument... args). Here is a summary of what I changed: * separated long methods into very small methods: each primitive type has it's own test methods * defined fields for every primitive type, to make sure that assertions do not accedential fail because wrong values get compared * Added tests methods that test against TestBean.class Please let me know, what you think about the changes! > Create basic unit tests for all classes > --- > > Key: SANDBOX-362 > URL: https://issues.apache.org/jira/browse/SANDBOX-362 > Project: Commons Sandbox > Issue Type: Test > Components: BeanUtils2 >Affects Versions: Nightly Builds >Reporter: Benedikt Ritter > Attachments: ArgumentTest.zip, > SANDBOX-362-RefactoringOfArgumentTest.txt > > > Back up all existing implementations with unit tests: > * Argument > * Assertions > * BeanUtils > * DefaultBeanAccessor > * DefaultClassAccessor > * MethodRegistry > * TypeUtils -- 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] (SANDBOX-367) Move base implementations from test to main
[
https://issues.apache.org/jira/browse/SANDBOX-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claudio Squarcella updated SANDBOX-367:
---
Attachment: SANDBOX-367_MoveBaseImplementationsFromTestToMain.patch
oops, just realized the patch doesn't include new file adds. I am attaching a
new one, which btw has a better name :)
Claudio
> Move base implementations from test to main
> ---
>
> Key: SANDBOX-367
> URL: https://issues.apache.org/jira/browse/SANDBOX-367
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Priority: Trivial
> Labels: graph, implementations, main, model, test
> Attachments: MoveBaseImplementationsFromTestToMain.patch,
> SANDBOX-367_MoveBaseImplementationsFromTestToMain.patch
>
>
> Hi,
> very tiny patch to move default implementations from test (in package
> {{model}}: {{BaseLabeledEdge}}, {{BaseLabeledWeightedEdge}} and
> {{BaseLabeledVertex}}) to main. Needed for other implementations that require
> manipulation of input graphs -- e.g. the upcoming Ford-Fulkerson ;)
--
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] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191473#comment-13191473
]
Matt Benson commented on FUNCTOR-10:
hmm, that was actually supposed to be
{{org.apache.commons.functor.\_lang3.\_\_Validate}}
> throw NullPointerException for illegal null values
> --
>
> Key: FUNCTOR-10
> URL: https://issues.apache.org/jira/browse/FUNCTOR-10
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Matt Benson
>
> for better alignment with JSE, {{[lang]}}, etc. Currently
> {{IllegalArgumentException}} is thrown.
> Per http://markmail.org/message/ythw55yad5lrvqrj
--
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] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191468#comment-13191468
]
Matt Benson commented on FUNCTOR-10:
Yes; I would imagine that the IDEs would be fine to import if a user actually
tried referencing the classes by these (albeit lightly) obfuscated names, but
why would the user do this? We've accomplished the goal of protecting the user
from accidentally importing these. It might be nice to make the relocator
pluggable for the shade plugin, to make this easier, but I think at Commons
we've gone long enough reinventing the wheel in every component just to avoid
dependencies. Jar shading gives us the best of both worlds.
> throw NullPointerException for illegal null values
> --
>
> Key: FUNCTOR-10
> URL: https://issues.apache.org/jira/browse/FUNCTOR-10
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Matt Benson
>
> for better alignment with JSE, {{[lang]}}, etc. Currently
> {{IllegalArgumentException}} is thrown.
> Per http://markmail.org/message/ythw55yad5lrvqrj
--
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] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191462#comment-13191462
]
Simone Tripodi commented on FUNCTOR-10:
---
nice to hear the trick worked! The nicer thing is IMHO that names are still
valid Java identifier parts, but not all IDEs are good on recognizing them :P
Standard Eclipse, for example, doesn't resolve the Guice shaded internals,
while Sonatype's MavenIDE (an Eclipse mod) does.
> throw NullPointerException for illegal null values
> --
>
> Key: FUNCTOR-10
> URL: https://issues.apache.org/jira/browse/FUNCTOR-10
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Matt Benson
>
> for better alignment with JSE, {{[lang]}}, etc. Currently
> {{IllegalArgumentException}} is thrown.
> Per http://markmail.org/message/ythw55yad5lrvqrj
--
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] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved FUNCTOR-10.
Resolution: Fixed
Committed revision 1234990.
> throw NullPointerException for illegal null values
> --
>
> Key: FUNCTOR-10
> URL: https://issues.apache.org/jira/browse/FUNCTOR-10
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Matt Benson
>
> for better alignment with JSE, {{[lang]}}, etc. Currently
> {{IllegalArgumentException}} is thrown.
> Per http://markmail.org/message/ythw55yad5lrvqrj
--
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] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191456#comment-13191456
]
Matt Benson commented on FUNCTOR-10:
Thanks for the hint, Simo! Naming e.g. {{org.apache.commons.lang3.Validate}}
to {{org.apache.commons.functor._lang3.__Validate}} and confirmed that the
resulting jar is fully functional.
> throw NullPointerException for illegal null values
> --
>
> Key: FUNCTOR-10
> URL: https://issues.apache.org/jira/browse/FUNCTOR-10
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Matt Benson
>
> for better alignment with JSE, {{[lang]}}, etc. Currently
> {{IllegalArgumentException}} is thrown.
> Per http://markmail.org/message/ythw55yad5lrvqrj
--
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] (JCS-88) Block cache fails to validate a cache file on startup when it contains elements with more than 2 blocks.
Block cache fails to validate a cache file on startup when it contains elements with more than 2 blocks. Key: JCS-88 URL: https://issues.apache.org/jira/browse/JCS-88 Project: Commons JCS Issue Type: Bug Affects Versions: jcs-1.3 Reporter: Diego Rivera The arithmetic for calculating block sizes is wrong. The code adds a term that shouldn't be considered at that point. For each block that needs to be written, the size of the block is currently calculated as: int chunkSize = Math.min( totalUsed + maxChunkSize, totalBytes - totalUsed ) The term "totalUsed" should not be added to maxChunkSize, since the intent is to construct a chunk that's either as big as is allowed (maxChunkSize) or as big as the remaining bytes (totalBytes - totalUsed). Thus, the correct calculation should be: int chunkSize = Math.min( maxChunkSize, totalBytes - totalUsed ) The problem occurs in src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java, line 196, inside byte[][] getBlockChunks(byte[] complete, int numBlocksNeeded). A patch has been devised and will be submitted as a comment (since attachments aren't possible at this point). I still need to take the time to devise a unit test for this since the existing unit test passed without issue. -- 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] (JCS-88) Block cache fails to validate a cache file on startup when it contains elements with more than 2 blocks.
[
https://issues.apache.org/jira/browse/JCS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191439#comment-13191439
]
Diego Rivera commented on JCS-88:
-
diff -ruN jcs-1.3/src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java
jcs-1.3.new/src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java
--- jcs-1.3/src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java
2007-05-30 12:23:53.0 -0600
+++ jcs-1.3.new/src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java
2012-01-23 14:33:07.437164316 -0600
@@ -193,7 +193,7 @@
{
// use the max that can be written to a block or whatever is
left in the original
// array
-int chunkSize = Math.min( totalUsed + maxChunkSize, totalBytes
- totalUsed );
+int chunkSize = Math.min( maxChunkSize, totalBytes - totalUsed
);
byte[] chunk = new byte[chunkSize];
// copy from the used position to the chunk size on the
complete array to the chunk
// array.
> Block cache fails to validate a cache file on startup when it contains
> elements with more than 2 blocks.
>
>
> Key: JCS-88
> URL: https://issues.apache.org/jira/browse/JCS-88
> Project: Commons JCS
> Issue Type: Bug
>Affects Versions: jcs-1.3
>Reporter: Diego Rivera
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The arithmetic for calculating block sizes is wrong. The code adds a term
> that shouldn't be considered at that point. For each block that needs to be
> written, the size of the block is currently calculated as:
> int chunkSize = Math.min( totalUsed + maxChunkSize, totalBytes - totalUsed )
> The term "totalUsed" should not be added to maxChunkSize, since the intent is
> to construct a chunk that's either as big as is allowed (maxChunkSize) or as
> big as the remaining bytes (totalBytes - totalUsed). Thus, the correct
> calculation should be:
> int chunkSize = Math.min( maxChunkSize, totalBytes - totalUsed )
> The problem occurs in
> src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java, line 196, inside
> byte[][] getBlockChunks(byte[] complete, int numBlocksNeeded).
> A patch has been devised and will be submitted as a comment (since
> attachments aren't possible at this point). I still need to take the time to
> devise a unit test for this since the existing unit test passed without issue.
--
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] (LANG-786) StringUtils equals() relies on undefined behavior
[
https://issues.apache.org/jira/browse/LANG-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved LANG-786.
--
Resolution: Fixed
Hi, Daniel, and thanks for your contribution! Notwithstanding the obvious
potential for arguments about OO design and method overloading, I have reworked
your patch so that {{String-String}} comparisons are still handled in the body
of the basic {{equals(CharSequence, CharSequence)}} method; thus no exception
is needed in {{StringUtilsTest#testStringUtilsCharSequenceContract()}}.
Specifically I have retained your {{StringUtilsEqualsIndexOfTest}} improvements.
{{Committed revision 1234915.}}
> StringUtils equals() relies on undefined behavior
> -
>
> Key: LANG-786
> URL: https://issues.apache.org/jira/browse/LANG-786
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.x
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Fedora 15 AMD64
>Reporter: Daniel Trebbien
> Labels: StringUtils
> Attachments: equals.patch
>
>
> Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the
> JavaDoc block has contained the following note:
> {quote}
> This interface does not refine the general contracts of the equals and
> hashCode methods. The result of comparing two objects that implement
> CharSequence is therefore, in general, undefined. Each object may be
> implemented by a different class, and there is no guarantee that each class
> will be capable of testing its instances for equality with those of the other.
> {quote}
> When the signature of the StringUtils equals() method was changed from
> {{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in
> R920543, the implementation still relied on calling
> CharSequence#equals(Object) even though, in general, the result is undefined.
> One example where {{equals(Object)}} returns {{false}} even though, as
> CharSequences, two objects represent equal sequences is when one object is an
> instance of {{javax.lang.model.element.Name}} and the other object is a
> String.
--
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-732) Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x improvement). Preserved public API 100%. Removed unnecessary use of instance variables and i
[ https://issues.apache.org/jira/browse/MATH-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191248#comment-13191248 ] Kurt Ostfeld commented on MATH-732: --- Thank you so much, Sebastien! I signed the ICLA and it's filed. > Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x > improvement). Preserved public API 100%. Removed unnecessary use of instance > variables and instance state. > > > Key: MATH-732 > URL: https://issues.apache.org/jira/browse/MATH-732 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Kurt Ostfeld > Labels: api, perfomance > Fix For: 3.0 > > Attachments: DFTPerformanceWithPatch.png, > DFTPerformanceWithoutPatch.png, FastFourierTransformer.java.diff, > FastFourierTransformer.java.diff, FastFourierTransformerTest.java.diff, > FastFourierTransformerTest.java.diff, Main.java > > > I wrote my own Discrete Fourier Transform function in Java and ran some > benchmarks and found that it ran dramatically faster than the Apache library > implementation. This is a pretty straight forward implementation of the > standard Cooley Tukey algorithm that I read out of a textbook. This passes > all the Apache library test cases plus several I had written on my own. I > created a source code library patch that preserves the public API completely > while changing the internal implementation to achieve the performance > improvement. > In addition to the performance issue, I suggest that Discrete Fourier > Transform functionality be provided as stateless pure functions (in Java this > would be implemented with static methods) just like most other math > functions. As-is, the library requires the user to instantiate a Transformer > instance which maintains instance state, which is an unecessary complexity > for a pure math function. I held off on this change since it would change the > public API and affect existing code. However, I see similar backward > compatability breaking API changes are already in the FastFourierTransformer > class in the 3.0 code base. -- 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] (MATH-732) Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x improvement). Preserved public API 100%. Removed unnecessary use of instance variables and ins
[ https://issues.apache.org/jira/browse/MATH-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kurt Ostfeld updated MATH-732: -- Attachment: Main.java Simple benchmark program that I used to generate results. > Major Speed Improvement to 1D Discrete Fourier Transform (approximately 5x-9x > improvement). Preserved public API 100%. Removed unnecessary use of instance > variables and instance state. > > > Key: MATH-732 > URL: https://issues.apache.org/jira/browse/MATH-732 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Kurt Ostfeld > Labels: api, perfomance > Fix For: 3.0 > > Attachments: DFTPerformanceWithPatch.png, > DFTPerformanceWithoutPatch.png, FastFourierTransformer.java.diff, > FastFourierTransformer.java.diff, FastFourierTransformerTest.java.diff, > FastFourierTransformerTest.java.diff, Main.java > > > I wrote my own Discrete Fourier Transform function in Java and ran some > benchmarks and found that it ran dramatically faster than the Apache library > implementation. This is a pretty straight forward implementation of the > standard Cooley Tukey algorithm that I read out of a textbook. This passes > all the Apache library test cases plus several I had written on my own. I > created a source code library patch that preserves the public API completely > while changing the internal implementation to achieve the performance > improvement. > In addition to the performance issue, I suggest that Discrete Fourier > Transform functionality be provided as stateless pure functions (in Java this > would be implemented with static methods) just like most other math > functions. As-is, the library requires the user to instantiate a Transformer > instance which maintains instance state, which is an unecessary complexity > for a pure math function. I held off on this change since it would change the > public API and affect existing code. However, I see similar backward > compatability breaking API changes are already in the FastFourierTransformer > class in the 3.0 code base. -- 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-707) Naming confusion
[
https://issues.apache.org/jira/browse/MATH-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191149#comment-13191149
]
Gilles commented on MATH-707:
-
bq. The same changes must still be performed in package "solvers".
Done in revision 1234784.
> Naming confusion
>
>
> Key: MATH-707
> URL: https://issues.apache.org/jira/browse/MATH-707
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Labels: api-change
> Fix For: 3.0
>
>
> This issue was raised in [this
> thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the "dev" ML.
> It proposes to consistently name classes/interfaces that refer to number
> types (e.g. "Real", "Complex", ...) and structure (e.g. "Scalar",
> "Vectorial", ...), with "Real" and "Scalar" components in names being assumed
> (thus, not to be included in the name).
> For example, for the "Univariate..." interfaces (in package "analysis"), the
> proposal is to operate the following renaming:
> * {{UnivariateRealFunction}} -> {{UnivariateFunction}}
> * {{UnivariateRealVectorialFunction}} -> {{UnivariateVectorFunction}}
> * {{UnivariateMatrixFunction}} -> {{UnivariateMatrixFunction}}
> Similar changes are in order in the package "optimization" (where "Real" is
> sometimes included in the name and sometimes not, or used instead of
> "Scalar").
--
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] (SANDBOX-367) Move base implementations from test to main
Move base implementations from test to main
---
Key: SANDBOX-367
URL: https://issues.apache.org/jira/browse/SANDBOX-367
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Claudio Squarcella
Priority: Trivial
Attachments: MoveBaseImplementationsFromTestToMain.patch
Hi,
very tiny patch to move default implementations from test (in package
{{model}}: {{BaseLabeledEdge}}, {{BaseLabeledWeightedEdge}} and
{{BaseLabeledVertex}}) to main. Needed for other implementations that require
manipulation of input graphs -- e.g. the upcoming Ford-Fulkerson ;)
--
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] (SANDBOX-367) Move base implementations from test to main
[
https://issues.apache.org/jira/browse/SANDBOX-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claudio Squarcella updated SANDBOX-367:
---
Attachment: MoveBaseImplementationsFromTestToMain.patch
> Move base implementations from test to main
> ---
>
> Key: SANDBOX-367
> URL: https://issues.apache.org/jira/browse/SANDBOX-367
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Priority: Trivial
> Labels: graph, implementations, main, model, test
> Attachments: MoveBaseImplementationsFromTestToMain.patch
>
>
> Hi,
> very tiny patch to move default implementations from test (in package
> {{model}}: {{BaseLabeledEdge}}, {{BaseLabeledWeightedEdge}} and
> {{BaseLabeledVertex}}) to main. Needed for other implementations that require
> manipulation of input graphs -- e.g. the upcoming Ford-Fulkerson ;)
--
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-707) Naming confusion
[
https://issues.apache.org/jira/browse/MATH-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191122#comment-13191122
]
Gilles commented on MATH-707:
-
The same changes must still be performed in package "solvers".
> Naming confusion
>
>
> Key: MATH-707
> URL: https://issues.apache.org/jira/browse/MATH-707
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Labels: api-change
> Fix For: 3.0
>
>
> This issue was raised in [this
> thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the "dev" ML.
> It proposes to consistently name classes/interfaces that refer to number
> types (e.g. "Real", "Complex", ...) and structure (e.g. "Scalar",
> "Vectorial", ...), with "Real" and "Scalar" components in names being assumed
> (thus, not to be included in the name).
> For example, for the "Univariate..." interfaces (in package "analysis"), the
> proposal is to operate the following renaming:
> * {{UnivariateRealFunction}} -> {{UnivariateFunction}}
> * {{UnivariateRealVectorialFunction}} -> {{UnivariateVectorFunction}}
> * {{UnivariateMatrixFunction}} -> {{UnivariateMatrixFunction}}
> Similar changes are in order in the package "optimization" (where "Real" is
> sometimes included in the name and sometimes not, or used instead of
> "Scalar").
--
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] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191119#comment-13191119
]
Simone Tripodi commented on FUNCTOR-10:
---
We could shade the {{Validate}} class by renaming it in a way some IDEs (i.e.
Eclipse) is not able to resolve; Google Guice's folks use to do it by shading
the classes with {{$}} as first class name char, it would look like:
{{org.apache.commons.lang.$Validate}}
> throw NullPointerException for illegal null values
> --
>
> Key: FUNCTOR-10
> URL: https://issues.apache.org/jira/browse/FUNCTOR-10
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Matt Benson
>
> for better alignment with JSE, {{[lang]}}, etc. Currently
> {{IllegalArgumentException}} is thrown.
> Per http://markmail.org/message/ythw55yad5lrvqrj
--
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] (MATH-708) Add method "representableDelta" in class "Precision"
[ https://issues.apache.org/jira/browse/MATH-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-708. - Resolution: Fixed > Add method "representableDelta" in class "Precision" > > > Key: MATH-708 > URL: https://issues.apache.org/jira/browse/MATH-708 > Project: Commons Math > Issue Type: New Feature >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Fix For: 3.0 > > > Cf. [this > post|http://www.mail-archive.com/dev@commons.apache.org/msg26683.html] on the > "dev" ML. -- 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] (MATH-719) Strange deprecations in API
[ https://issues.apache.org/jira/browse/MATH-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-719. - Resolution: Later It is unlikely that we can come up with a new design before the release of v3.0. This must be thoroughly discussed first on the "dev" ML, together with other matrix interface issues. > Strange deprecations in API > --- > > Key: MATH-719 > URL: https://issues.apache.org/jira/browse/MATH-719 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.0, 2.1, 2.2 >Reporter: Peter Bloem >Priority: Minor > Labels: api-change, deprecated > > Sorry if this doesn't belong here. I couldn't find any sort of mailing list > or other feedback mechanism on the website. > RealMatrix has some very odd deprecations. In particular inverse(), > getDeterminant() and isSingular(). The last has the message: > bq. Deprecated. as of release 2.0, replaced by the boolean negation of new > LUDecompositionImpl(m).getSolver().isNonSingular() > That's an implementation, not an interface. The whole point of having an > interface is that > * I can query whether a matrix is singular withou having to know about > LUDecompositions > * You guys can change the implementation of isSingular() if something better > pops up without us guys having to change our code. > I'm not using these methods now, because they're deprecated, but I've > basically recreated them in as static methods in a utility class. Wouldn't it > be much better to just put code from the deprecation message into the method > and remove the deprecation? -- 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-721) building common-math on Solaris SPARC gives "error: floating point number too small"
[
https://issues.apache.org/jira/browse/MATH-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191117#comment-13191117
]
Gilles commented on MATH-721:
-
Any follow-ups on this issue?
> building common-math on Solaris SPARC gives "error: floating point number too
> small"
>
>
> Key: MATH-721
> URL: https://issues.apache.org/jira/browse/MATH-721
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Build environment is:
> mvn --version
> Apache Maven 3.0.3 (rNON-CANONICAL_2011-10-13_22-23_builder; 2011-10-13
> 22:23:49+0200)
> Maven home: /usr/local/share/maven-3.0.3
> Java version: 1.7.0-internal, vendor: Oracle Corporation
> Java home: /usr/local/share/jdk1.7.0_1/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "sunos", version: "5.10", arch: "sparc", family: "unix"
>Reporter: Jörg Prante
>
> It seems the assumption in MathUtils.java
> /** Safe minimum, such that 1 / SAFE_MIN does not overflow.
> * In IEEE 754 arithmetic, this is also the smallest normalized
> * number 2-1022.
> */
> public static final double SAFE_MIN = 0x1.0p-1022;
> does not work on my openjdk 1.7.0_1 on Solaris SPARC, because I get the
> following build error:
> [INFO] Compiling 457 source files to
> /opt/builder/projects/commons-math-2.2-src/target/classes
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/main/java/org/apache/commons/math/util/MathUtils.java:[42,42]
> error: floating point number too small
> [INFO] 1error
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> and also in the tests I encounter the error when parsing floating point
> constants
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.1:testCompile
> (default-testCompile) on project commons-math: Compilation failure:
> Compilation failure:
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/util/FastMathTest.java:[1050,69]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/util/FastMathTest.java:[1055,28]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/util/FastMathTest.java:[1055,69]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/util/FastMathTest.java:[1056,28]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/util/FastMathTest.java:[1062,70]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/util/FastMathTest.java:[1063,70]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/util/FastMathTest.java:[1068,70]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/util/FastMathTest.java:[1069,70]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/optimization/general/LevenbergMarquardtOptimizerTest.java:[503,51]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/optimization/general/LevenbergMarquardtOptimizerTest.java:[503,66]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/estimation/LevenbergMarquardtEstimatorTest.java:[583,52]
> error: floating point number too small
> [ERROR]
> [ERROR]
> /opt/builder/projects/commons-math-2.2-src/src/test/java/org/apache/commons/math/estimation/LevenbergMarquardtEstimatorTest.java:[585,52]
> error: floating point number too small
> I suggest using java.lang.Double.MIN_NORMAL for a platform normalized minimal
> floating point value.
> A quick program for printing Double.MIN_NORMAL gives the following result.
> class test {
>public static void main(String[] args) {
>System.out.println("min float = " + Double.MIN_NORMAL );
>}
> }
> java test
> min float
[jira] [Updated] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-725:
Fix Version/s: 3.0
> use initialized static final arrays, instead of initializing it in
> constructors
> ---
>
> Key: MATH-725
> URL: https://issues.apache.org/jira/browse/MATH-725
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Eldar Agalarov
>Priority: Minor
> Fix For: 3.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
> these arrays are unmodifiable, so we can replace this arrays initialization
> block
> final int w = 32;
> final int r = (k + w - 1) / w;
> this.v = new int[r];
> this.index = 0;
>
> // precompute indirection index tables. These tables are used for
> optimizing access
> // they allow saving computations like "(j + r - 2) % r" with costly
> modulo operations
> iRm1 = new int[r];
> iRm2 = new int[r];
> i1 = new int[r];
> i2 = new int[r];
> i3 = new int[r];
> for (int j = 0; j < r; ++j) {
> iRm1[j] = (j + r - 1) % r;
> iRm2[j] = (j + r - 2) % r;
> i1[j] = (j + m1) % r;
> i2[j] = (j + m2) % r;
> i3[j] = (j + m3) % r;
> }
> with inline initialized static final arrays.
> This is much better and faster implementation, freed from unnecessary costly
> calculations (such as %).
> Another solution: leave as is, but make all these arrays static.
--
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] (MATH-460) Levy Distribution
[ https://issues.apache.org/jira/browse/MATH-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-460: Fix Version/s: (was: 3.0) 3.1 > Levy Distribution > - > > Key: MATH-460 > URL: https://issues.apache.org/jira/browse/MATH-460 > Project: Commons Math > Issue Type: New Feature >Reporter: Pavel Ryzhov >Priority: Minor > Fix For: 3.1 > > Attachments: levy_math_460.patch > > > Pretty straightforward implementation of Levy Distribution (not Levy > alpha-stable) according to http://en.wikipedia.org/wiki/Lévy_distribution. -- 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-473) Frequency: new option: NON-sorted
[ https://issues.apache.org/jira/browse/MATH-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191114#comment-13191114 ] Gilles commented on MATH-473: - Hello Dan. Same suggestion as for MATH-474; could you please add unit tests? Thanks. > Frequency: new option: NON-sorted > - > > Key: MATH-473 > URL: https://issues.apache.org/jira/browse/MATH-473 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.0, 1.1, 1.2, 2.0, 2.1 >Reporter: Dan Checkoway > Fix For: 3.0 > > Attachments: MATH-473.patch > > > I have a request for enhancement on org.apache.commons.math.stat.Frequency. > I would like to be able to specify that the the backing map NOT be sorted. > Right now it uses TreeMap. I would like to have the option of specifying > that sorting is not important, and would in fact hinder performance, and a > plain old HashMap should be used instead. > i.e. constructor such as: > public Frequency(boolean sorted); > If sorted is true, use a TreeMap. If sorted is false, use a HashMap. Is > this feasible? I'd be happy to contribute a patch if that would help. -- 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-474) Frequency: new method: merge(Frequency)
[ https://issues.apache.org/jira/browse/MATH-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191113#comment-13191113 ] Gilles commented on MATH-474: - Hello Dan. Really sorry for the (long!) delay in examining your contribution. I've noticed that the patch does not provide unit tests; could you please add some? Thanks. > Frequency: new method: merge(Frequency) > --- > > Key: MATH-474 > URL: https://issues.apache.org/jira/browse/MATH-474 > Project: Commons Math > Issue Type: Improvement >Reporter: Dan Checkoway > Fix For: 3.0 > > Attachments: MATH-474.patch > > > I'd like to propose an enhancement to org.apache.commons.math.stat.Frequency. > I need to "merge" multiple Frequency objects, and it would be great if > Frequency had inherent support for this, such as: > public void merge(Frequency other); > public void merge(Collection others); > I'd be happy to submit a patch if that would help... -- 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] (MATH-610) [patch] objects that use compareTo should have equals as well
[ https://issues.apache.org/jira/browse/MATH-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-610: Affects Version/s: (was: 3.0) Fix Version/s: (was: 3.0) 3.1 > [patch] objects that use compareTo should have equals as well > - > > Key: MATH-610 > URL: https://issues.apache.org/jira/browse/MATH-610 > Project: Commons Math > Issue Type: Improvement >Reporter: Dave Brosius >Priority: Trivial > Fix For: 3.1 > > Attachments: equals.diff > > > NaturalRanking implements compareTo. Code that implements compareTo should > also implement equals, and those that implement equals should implement > hashCode. This patch does this. -- 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] (MATH-602) Inverse condition number
[ https://issues.apache.org/jira/browse/MATH-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-602: Fix Version/s: (was: 3.0) 3.1 > Inverse condition number > > > Key: MATH-602 > URL: https://issues.apache.org/jira/browse/MATH-602 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 2.2 > Environment: All >Reporter: greg sterijevski >Priority: Minor > Labels: Condition, Inverse, Number > Fix For: 3.1 > > Attachments: svdinvcond, tstsvd > > Original Estimate: 1h > Remaining Estimate: 1h > > In SingularValueDecompositionImpl, the condition number is given as the ratio > of the largest singular value to the smallest singular value. While this is > the correct calculation, because of concerns over rank deficiency, > researchers have traditionally used the inverse of the condition number as a > more stable indicator of rank deficiency. -- 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] (MATH-607) Current Multiple Regression Object does calculations with all data incore. There are non incore techniques which would be useful with large datasets.
[ https://issues.apache.org/jira/browse/MATH-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-607: Fix Version/s: (was: 3.0) 3.1 > Current Multiple Regression Object does calculations with all data incore. > There are non incore techniques which would be useful with large datasets. > - > > Key: MATH-607 > URL: https://issues.apache.org/jira/browse/MATH-607 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 > Environment: Java >Reporter: greg sterijevski > Labels: Gentleman's, QR, Regression, Updating, decomposition, > lemma > Fix For: 3.1 > > Attachments: RegressResults2, millerreg, millerreg_take2, > millerregtest, regres_change1, updating_reg_cut2, updating_reg_ifaces > > Original Estimate: 840h > Remaining Estimate: 840h > > The current multiple regression class does a QR decomposition on the complete > data set. This necessitates the loading incore of the complete dataset. For > large datasets, or large datasets and a requirement to do datamining or > stepwise regression this is not practical. There are techniques which form > the normal equations on the fly, as well as ones which form the QR > decomposition on an update basis. I am proposing, first, the specification of > an "UpdatingLinearRegression" interface which defines basic functionality all > such techniques must fulfill. > Related to this 'updating' regression, the results of running a regression on > some subset of the data should be encapsulated in an immutable object. This > is to ensure that subsequent additions of observations do not corrupt or > render inconsistent parameter estimates. I am calling this interface > "RegressionResults". > Once the community has reached a consensus on the interface, work on the > concrete implementation of these techniques will take place. > Thanks, > -Greg -- 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] (MATH-665) QRDecomposition does not have a singularity threshold
[ https://issues.apache.org/jira/browse/MATH-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-665. - Resolution: Fixed A threshold setting has been provided (defaulting to "zero" so as to retain the previous behaviour) as part of MATH-664 (r1230509). > QRDecomposition does not have a singularity threshold > - > > Key: MATH-665 > URL: https://issues.apache.org/jira/browse/MATH-665 > Project: Commons Math > Issue Type: Bug >Reporter: Phil Steitz > Fix For: 3.0 > > > QRDecompositionImpl tests elements of rDiag for exact equality to 0 in > checking singularity. A singularity threshold should be defined for this > class and used in the singularity test. -- 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] (FUNCTOR-10) throw NullPointerException for illegal null values
[
https://issues.apache.org/jira/browse/FUNCTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190940#comment-13190940
]
Emmanuel Bourg commented on FUNCTOR-10:
---
I tend to think that convenience for the end user is more important than
convenience for the developer. In this case the code saved by the Validate
class is marginal, I would rather code the null check manually.
> throw NullPointerException for illegal null values
> --
>
> Key: FUNCTOR-10
> URL: https://issues.apache.org/jira/browse/FUNCTOR-10
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Matt Benson
>
> for better alignment with JSE, {{[lang]}}, etc. Currently
> {{IllegalArgumentException}} is thrown.
> Per http://markmail.org/message/ythw55yad5lrvqrj
--
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
