[jira] Updated: (MATH-157) Add support for SVD.
[ http://issues.apache.org/jira/browse/MATH-157?page=all ] Remi Arntzen updated MATH-157: -- Attachment: svd2.tar.gz Now it works perfectly (At least according to how I think it should work). However it is not to your specifications, e.g. I do the eigenvector calculation on the larger of U and V and then use the property M*v_i=q_i*u_i and M^T*u_i=q_i*v_i. While I continue to learn more about the properties of the SVD I will refine it as I go along, but right now I have to get ready for school. Add support for SVD. Key: MATH-157 URL: http://issues.apache.org/jira/browse/MATH-157 Project: Commons Math Issue Type: New Feature Reporter: Tyler Ward Attachments: svd.tar.gz, svd2.tar.gz SVD is probably the most important feature in any linear algebra package, though also one of the more difficult. In general, SVD is needed because very often real systems end up being singular (which can be handled by QR), or nearly singular (which can't). A good example is a nonlinear root finder. Often the jacobian will be nearly singular, but it is VERY rare for it to be exactly singular. Consequently, LU or QR produces really bad results, because they are dominated by rounding error. What is needed is a way to throw out the insignificant parts of the solution, and take what improvements we can get. That is what SVD provides. The colt SVD algorithm has a serious infinite loop bug, caused primarily by Double.NaN in the inputs, but also by underflow and overflow, which really can't be prevented. If worried about patents and such, SVD can be derrived from first principals very easily with the acceptance of two postulates. 1) That an SVD always exists. 2) That Jacobi reduction works. Both are very basic results from linear algebra, available in nearly any text book. Once that's accepted, then the rest of the algorithm falls into place in a very simple manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-157) Add support for SVD.
[ http://issues.apache.org/jira/browse/MATH-157?page=comments#action_12446759 ] Remi Arntzen commented on MATH-157: --- now I see your comments... sigh Add support for SVD. Key: MATH-157 URL: http://issues.apache.org/jira/browse/MATH-157 Project: Commons Math Issue Type: New Feature Reporter: Tyler Ward Attachments: svd.tar.gz, svd2.tar.gz SVD is probably the most important feature in any linear algebra package, though also one of the more difficult. In general, SVD is needed because very often real systems end up being singular (which can be handled by QR), or nearly singular (which can't). A good example is a nonlinear root finder. Often the jacobian will be nearly singular, but it is VERY rare for it to be exactly singular. Consequently, LU or QR produces really bad results, because they are dominated by rounding error. What is needed is a way to throw out the insignificant parts of the solution, and take what improvements we can get. That is what SVD provides. The colt SVD algorithm has a serious infinite loop bug, caused primarily by Double.NaN in the inputs, but also by underflow and overflow, which really can't be prevented. If worried about patents and such, SVD can be derrived from first principals very easily with the acceptance of two postulates. 1) That an SVD always exists. 2) That Jacobi reduction works. Both are very basic results from linear algebra, available in nearly any text book. Once that's accepted, then the rest of the algorithm falls into place in a very simple manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-157) Add support for SVD.
[ http://issues.apache.org/jira/browse/MATH-157?page=comments#action_12446407 ] Remi Arntzen commented on MATH-157: --- You know you can invert that matrix (it's orthogonal, so just take the transpose), and you can also invert the S matrix (it's diagonal, invert each value on the diagonal), so just invert those two and multiply through the original matrix to get the other orthogonal matrix however when the original matrix is not square that method fails to apply. the inverse of a non-square matrix does not exist, and as such you can not simply take the transpose of each matrix product as they are not of equal size. (although this method does work splendidly on square matrices) It just seems like you're kindof going in the wrong direction I'd say I'm literally going in the wrong direction, some of the vectors seem to be randomly inverted, and as I've said earlier I have never had any formal training on this subject (just rudimentary high school training). I'm basically coding as I am learning. Add support for SVD. Key: MATH-157 URL: http://issues.apache.org/jira/browse/MATH-157 Project: Commons Math Issue Type: New Feature Reporter: Tyler Ward Attachments: svd.tar.gz SVD is probably the most important feature in any linear algebra package, though also one of the more difficult. In general, SVD is needed because very often real systems end up being singular (which can be handled by QR), or nearly singular (which can't). A good example is a nonlinear root finder. Often the jacobian will be nearly singular, but it is VERY rare for it to be exactly singular. Consequently, LU or QR produces really bad results, because they are dominated by rounding error. What is needed is a way to throw out the insignificant parts of the solution, and take what improvements we can get. That is what SVD provides. The colt SVD algorithm has a serious infinite loop bug, caused primarily by Double.NaN in the inputs, but also by underflow and overflow, which really can't be prevented. If worried about patents and such, SVD can be derrived from first principals very easily with the acceptance of two postulates. 1) That an SVD always exists. 2) That Jacobi reduction works. Both are very basic results from linear algebra, available in nearly any text book. Once that's accepted, then the rest of the algorithm falls into place in a very simple manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-157) Add support for SVD.
[ http://issues.apache.org/jira/browse/MATH-157?page=all ] Remi Arntzen updated MATH-157: -- Attachment: svd.tar.gz This is just a preliminary implementation. Seeing as how I have not taken a course in linear algebra as of yet, I would appreciate having some test cases to verify my code against. In particular any special cases involved in the algorithm, e.g. singular square non-square, as far as I can tell my method should work on all matrix inputs, but no guarantees. My method involves finding the eigen values by using the QR algorithm, taking the square roots of these values and placing them along the diagonal of Σ. Then I compute the eigen vectors of mTm and mmT by computing the null space of these matrices ( with the difference of the Identity*eigen value), and in calculating the null space I used the reduced row echelon form via the Gaussian algorithm. This is just a start, still needs provide more documentation, and test cases. Add support for SVD. Key: MATH-157 URL: http://issues.apache.org/jira/browse/MATH-157 Project: Commons Math Issue Type: New Feature Reporter: Tyler Ward Attachments: svd.tar.gz SVD is probably the most important feature in any linear algebra package, though also one of the more difficult. In general, SVD is needed because very often real systems end up being singular (which can be handled by QR), or nearly singular (which can't). A good example is a nonlinear root finder. Often the jacobian will be nearly singular, but it is VERY rare for it to be exactly singular. Consequently, LU or QR produces really bad results, because they are dominated by rounding error. What is needed is a way to throw out the insignificant parts of the solution, and take what improvements we can get. That is what SVD provides. The colt SVD algorithm has a serious infinite loop bug, caused primarily by Double.NaN in the inputs, but also by underflow and overflow, which really can't be prevented. If worried about patents and such, SVD can be derrived from first principals very easily with the acceptance of two postulates. 1) That an SVD always exists. 2) That Jacobi reduction works. Both are very basic results from linear algebra, available in nearly any text book. Once that's accepted, then the rest of the algorithm falls into place in a very simple manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MATH-159) Inverse Error Function
Inverse Error Function -- Key: MATH-159 URL: http://issues.apache.org/jira/browse/MATH-159 Project: Commons Math Issue Type: New Feature Affects Versions: Nightly Builds Reporter: Remi Arntzen Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-159) Inverse Error Function
[ http://issues.apache.org/jira/browse/MATH-159?page=all ] Remi Arntzen updated MATH-159: -- Attachment: erf.diff Quick fix: there may be a better way that I am not aware of. Inverse Error Function -- Key: MATH-159 URL: http://issues.apache.org/jira/browse/MATH-159 Project: Commons Math Issue Type: New Feature Affects Versions: Nightly Builds Reporter: Remi Arntzen Priority: Minor Attachments: erf.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-159) Inverse Error Function
[ http://issues.apache.org/jira/browse/MATH-159?page=all ] Remi Arntzen updated MATH-159: -- Attachment: erf.diff Same as previous except with an additional missing parenthesis. If you know how to remove the previous erf.diff you can go ahead and remove it. Inverse Error Function -- Key: MATH-159 URL: http://issues.apache.org/jira/browse/MATH-159 Project: Commons Math Issue Type: New Feature Affects Versions: Nightly Builds Reporter: Remi Arntzen Priority: Minor Attachments: erf.diff, erf.diff, norm.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-159) Inverse Error Function
[ http://issues.apache.org/jira/browse/MATH-159?page=all ] Remi Arntzen updated MATH-159: -- Attachment: norm.diff The normal distribution can use this inverse erf for better performance. Inverse Error Function -- Key: MATH-159 URL: http://issues.apache.org/jira/browse/MATH-159 Project: Commons Math Issue Type: New Feature Affects Versions: Nightly Builds Reporter: Remi Arntzen Priority: Minor Attachments: erf.diff, erf.diff, norm.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CODEC-8) REQ: Streaming codecs
[
http://issues.apache.org/jira/browse/CODEC-8?page=comments#action_12430897 ]
Remi Arntzen commented on CODEC-8:
--
As far as I can tell the ws-common-utils Base64 streams are only output streams
for encoding and decoding.
What I was referring to by an output stream capable of encoding and decoding,
was basically the java.util.zip.DeflaterInputStream,
java.util.zip.InflaterInputStream and java.util.zip.DeflaterOutputStreams,
java.util.zip.InflaterOutputStream classes.
REQ: Streaming codecs
-
Key: CODEC-8
URL: http://issues.apache.org/jira/browse/CODEC-8
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.2
Environment: Operating System: All
Platform: All
Reporter: Sergei S. Ivanov
I would really appreciate if, for example, Base64 encoder could operate on
streams. One reason is that it's much easier to attach ByteArrayInputStream to
an array of bytes that to copy a byte array into a stream. The other reason is
greater flexibility, given by the streams.
I'd suggest creating a pair of new interfaces:
public interface StreamingDecoder implements Decoder {
public void decode(InputStream in, OutputStream out) throws
DecoderException;
}
public interface StreamingEncoder implements Encoder {
public void encode(InputStream in, OutputStream out) throws
EncoderException;
}
Base64 and Hex will then be able to implement these interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-8) REQ: Streaming codecs
[ http://issues.apache.org/jira/browse/CODEC-8?page=all ]
Remi Arntzen updated CODEC-8:
-
Attachment: Base64.diff
Adding a Writer and Reader class that can handle additional character sets as
is done in the ws-commons-util might be nice as well.
REQ: Streaming codecs
-
Key: CODEC-8
URL: http://issues.apache.org/jira/browse/CODEC-8
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.2
Environment: Operating System: All
Platform: All
Reporter: Sergei S. Ivanov
Attachments: Base64.diff
I would really appreciate if, for example, Base64 encoder could operate on
streams. One reason is that it's much easier to attach ByteArrayInputStream to
an array of bytes that to copy a byte array into a stream. The other reason is
greater flexibility, given by the streams.
I'd suggest creating a pair of new interfaces:
public interface StreamingDecoder implements Decoder {
public void decode(InputStream in, OutputStream out) throws
DecoderException;
}
public interface StreamingEncoder implements Encoder {
public void encode(InputStream in, OutputStream out) throws
EncoderException;
}
Base64 and Hex will then be able to implement these interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CODEC-36) [codec] Support of Base 64 Encoding with URL and Filename Safe Alphabet
[ http://issues.apache.org/jira/browse/CODEC-36?page=comments#action_12430905 ] Remi Arntzen commented on CODEC-36: --- I created a patch for CODEC-8, which has yet to be completely resolved and agreed upon, that includes support for the URL and filename safe alphabet. [codec] Support of Base 64 Encoding with URL and Filename Safe Alphabet --- Key: CODEC-36 URL: http://issues.apache.org/jira/browse/CODEC-36 Project: Commons Codec Issue Type: Improvement Environment: Operating System: other Platform: All Reporter: Alain Gilbert Priority: Minor Fix For: 1.4 The default Base64 alphabet is not safe to use for URL query parameters since the '+' character is converted to a ' ' (space) when the parameter value is retrieved from the request (ServeltRequest.getParameter(String) and .getParameterValues(String)). It is possible to post-process the result of Base64.encodeBase64 but I would rather prefer to specify an alternate alphabet or call another method. Refer to http://www.ietf.org/rfc/rfc3548.txt section 4 for more information. Regards, Alain Gilbert -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CODEC-8) REQ: Streaming codecs
[
http://issues.apache.org/jira/browse/CODEC-8?page=comments#action_12430774 ]
Remi Arntzen commented on CODEC-8:
--
My mistake
REQ: Streaming codecs
-
Key: CODEC-8
URL: http://issues.apache.org/jira/browse/CODEC-8
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.2
Environment: Operating System: All
Platform: All
Reporter: Sergei S. Ivanov
I would really appreciate if, for example, Base64 encoder could operate on
streams. One reason is that it's much easier to attach ByteArrayInputStream to
an array of bytes that to copy a byte array into a stream. The other reason is
greater flexibility, given by the streams.
I'd suggest creating a pair of new interfaces:
public interface StreamingDecoder implements Decoder {
public void decode(InputStream in, OutputStream out) throws
DecoderException;
}
public interface StreamingEncoder implements Encoder {
public void encode(InputStream in, OutputStream out) throws
EncoderException;
}
Base64 and Hex will then be able to implement these interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CODEC-8) REQ: Streaming codecs
[
http://issues.apache.org/jira/browse/CODEC-8?page=comments#action_12430816 ]
Remi Arntzen commented on CODEC-8:
--
I have nothing against the StreamingDecoder interface, however the Base64
implemented input stream and output stream should be publicly accessible as
well. In this circumstance I would implement each stream as a public inner
class so that the Base64 streams would be initialized via new
Base64.InputStream(...) and new Base64.OutputStream(...) respectively, and
the simpler static utility methods could still be accessed as they are.
Should the output stream be capable of encoding and decoding, or just encoding?
Output streams are most often used for encoding and input streams for decoding
data.
REQ: Streaming codecs
-
Key: CODEC-8
URL: http://issues.apache.org/jira/browse/CODEC-8
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.2
Environment: Operating System: All
Platform: All
Reporter: Sergei S. Ivanov
I would really appreciate if, for example, Base64 encoder could operate on
streams. One reason is that it's much easier to attach ByteArrayInputStream to
an array of bytes that to copy a byte array into a stream. The other reason is
greater flexibility, given by the streams.
I'd suggest creating a pair of new interfaces:
public interface StreamingDecoder implements Decoder {
public void decode(InputStream in, OutputStream out) throws
DecoderException;
}
public interface StreamingEncoder implements Encoder {
public void encode(InputStream in, OutputStream out) throws
EncoderException;
}
Base64 and Hex will then be able to implement these interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-155) Number Base Conversion
[ http://issues.apache.org/jira/browse/MATH-155?page=comments#action_12429080 ] Remi Arntzen commented on MATH-155: --- One system of radix conversion that is not currently supported by the base Java library's and the Commons is radix conversion for floating point numbers. Hexadecimal support for floating point numbers is given by Double.toHexString(double), however support for additional floating point radix's could be helpful/entertaining. Number Base Conversion -- Key: MATH-155 URL: http://issues.apache.org/jira/browse/MATH-155 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Final Environment: NA Reporter: Chetan Assigned To: James Carman I think a maths package without a base conversion utility is quite incomplete. Would request you to include this feature in the package for the next release. From a user's perspective I would like to have a library that goes beyond the usual binary,octal,hexadecimal conversions. Would really be helpful if the library is very generic so as to support convert(Base from,Base to) calls. Pls let me know what you feel about this.Currently i am on the lookout for a base conversion class etc but haven't managed to hit upon anything that serves my purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-153) RandomDataImpl nextInt(int, int) nextLong(long, long)
[ http://issues.apache.org/jira/browse/MATH-153?page=all ] Remi Arntzen updated MATH-153: -- Attachment: Test.diff RandomDataImpl nextInt(int, int) nextLong(long, long) - Key: MATH-153 URL: http://issues.apache.org/jira/browse/MATH-153 Project: Commons Math Issue Type: Bug Affects Versions: Nightly Builds, 1.1 Final Reporter: Remi Arntzen Priority: Critical Fix For: 1.2 Final Attachments: diff.txt, Test.diff RandomDataImpl.nextInt(Integer.MIN_VALUE, Integer.MAX_VALUE) suffers from overflow errors. change return lower + (int) (rand.nextDouble() * (upper - lower + 1)); to return (int) (lower + (long) (rand.nextDouble()*((long) upper - lower + 1))); additional checks must be made for the nextlong(long, long) method. At first I thought about using MathUtils.subAndCheck(long, long) but there is only an int version avalible, and the problem is that subAndCheck internaly uses long values to check for overflow just as my previous channge proposes. The only thing I can think of is using a BigInteger to check for the number of bits required to express the difference. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-154) MathUtils addAndCheck and subAndCheck for long values
[
http://issues.apache.org/jira/browse/MATH-154?page=comments#action_12425314 ]
Remi Arntzen commented on MATH-154:
---
a better implementation:
long addAndCheck(long a, long b) {
long max = Math.max(a, b);
long min = Math.min(a, b);
long sum = a + b;
String overflow = Overflow: add;
if (max == 0 || min == 0) (
return sum;
} else if (max 0 min 0) {
if (Long.MAX_VALUE - max min) {
throw new RuntimeException(overflow);
}
} else if (max 0 min 0) {
if (Long.MIN_VALUE - min max) {
throw new RuntimeException(overflow);
}
} else {
return sum;
}
}
long subAndCheck(long a, long b) {
long max = Math.max(a, b);
long min = Math.min(a, b);
long diff = a - b;
String overflow = Overflow: add;
if (max == 0 || min == 0) {
return diff;
} else if (max 0 min 0) {
if (max == a) {
if (max - Long.MAX_VALUE min) {
throw new RuntimeException(overflow);
}
} else if (max == b) {
if (min - Long.MIN_VALUE max) {
throw new RuntimeException(overflow);
}
}
} else {
return sum;
}
}
MathUtils addAndCheck and subAndCheck for long values
-
Key: MATH-154
URL: http://issues.apache.org/jira/browse/MATH-154
Project: Commons Math
Issue Type: Improvement
Affects Versions: Nightly Builds, 1.1 Final
Reporter: Remi Arntzen
public static long addAndCheck(long x, long y) {
BigInteger s = BigInteger.valueOf(x).add(BigInteger.valueOf(y);
if (s.bitLength() + 1 Long.SIZE) {
throw new ArithmeticException(overflow: add);
}
return s.longValue();
}
public static long subAndCheck(long x, long y) {
BigInteger s = BigInteger.valueOf(x).subtract(BigInteger.valueOf(y));
if (s.bitLength() + 1 Long.SIZE) {
throw new ArithmeticException(overflow: add);
}
return s.longValue();
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CODEC-8) REQ: Streaming codecs
[
http://issues.apache.org/jira/browse/CODEC-8?page=comments#action_12424787 ]
Remi Arntzen commented on CODEC-8:
--
Resolution: Won't Fix
Why won't this be fixed. This is a basic feature that demands further
consideration.
REQ: Streaming codecs
-
Key: CODEC-8
URL: http://issues.apache.org/jira/browse/CODEC-8
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.2
Environment: Operating System: All
Platform: All
Reporter: Sergei S. Ivanov
I would really appreciate if, for example, Base64 encoder could operate on
streams. One reason is that it's much easier to attach ByteArrayInputStream to
an array of bytes that to copy a byte array into a stream. The other reason is
greater flexibility, given by the streams.
I'd suggest creating a pair of new interfaces:
public interface StreamingDecoder implements Decoder {
public void decode(InputStream in, OutputStream out) throws
DecoderException;
}
public interface StreamingEncoder implements Encoder {
public void encode(InputStream in, OutputStream out) throws
EncoderException;
}
Base64 and Hex will then be able to implement these interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-152) Add MultiDimentional Support for FastFourier
[ http://issues.apache.org/jira/browse/MATH-152?page=all ] Remi Arntzen updated MATH-152: -- Attachment: fftTest.java.diff Add MultiDimentional Support for FastFourier Key: MATH-152 URL: http://issues.apache.org/jira/browse/MATH-152 Project: Commons Math Issue Type: New Feature Affects Versions: Nightly Builds Reporter: Remi Arntzen Attachments: diff.txt, fftTest.java.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-152) Add MultiDimentional Support for FastFourier
[ http://issues.apache.org/jira/browse/MATH-152?page=all ] Remi Arntzen updated MATH-152: -- Attachment: fft.java.diff for some reason my diff application shows a change to the entire file, but all that is needed is the two additional methods mdfft and it's private version along with the private inner-class. This overrides the previous attachment diff.txt Add MultiDimentional Support for FastFourier Key: MATH-152 URL: http://issues.apache.org/jira/browse/MATH-152 Project: Commons Math Issue Type: New Feature Affects Versions: Nightly Builds Reporter: Remi Arntzen Attachments: diff.txt, fft.java.diff, fftTest.java.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MATH-153) RandomDataImpl nextInt(int, int) nextLong(long, long)
RandomDataImpl nextInt(int, int) nextLong(long, long) - Key: MATH-153 URL: http://issues.apache.org/jira/browse/MATH-153 Project: Commons Math Issue Type: Bug Affects Versions: Nightly Builds, 1.1 Final Reporter: Remi Arntzen Priority: Critical RandomDataImpl.nextInt(Integer.MIN_VALUE, Integer.MAX_VALUE) suffers from overflow errors. change return lower + (int) (rand.nextDouble() * (upper - lower + 1)); to return (int) (lower + (long) (rand.nextDouble()*((long) upper - lower + 1))); additional checks must be made for the nextlong(long, long) method. At first I thought about using MathUtils.subAndCheck(long, long) but there is only an int version avalible, and the problem is that subAndCheck internaly uses long values to check for overflow just as my previous channge proposes. The only thing I can think of is using a BigInteger to check for the number of bits required to express the difference. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MATH-154) MathUtils addAndCheck and subAndCheck for long values
MathUtils addAndCheck and subAndCheck for long values
-
Key: MATH-154
URL: http://issues.apache.org/jira/browse/MATH-154
Project: Commons Math
Issue Type: Improvement
Affects Versions: Nightly Builds, 1.1 Final
Reporter: Remi Arntzen
public static long addAndCheck(long x, long y) {
BigInteger s = BigInteger.valueOf(x).add(BigInteger.valueOf(y);
if (s.bitLength() + 1 Long.SIZE) {
throw new ArithmeticException(overflow: add);
}
return s.longValue();
}
public static long subAndCheck(long x, long y) {
BigInteger s = BigInteger.valueOf(x).subtract(BigInteger.valueOf(y));
if (s.bitLength() + 1 Long.SIZE) {
throw new ArithmeticException(overflow: add);
}
return s.longValue();
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-153) RandomDataImpl nextInt(int, int) nextLong(long, long)
[
http://issues.apache.org/jira/browse/MATH-153?page=comments#action_12424472 ]
Remi Arntzen commented on MATH-153:
---
once Math-154 (MathUtils addAndCheck and subAndCheck for long values)
is commited nextLong(long, long) could become
public long nextLong(long lower, long upper) {
if (lower = upper) {
throw new IllegalArgumentException(
upper bound must be lower bound);
}
RandomGenerator rand = getRan();
boolean overFlow = false;
try {
MathUtils.subAndCheck(upper, lower);
} catch (ArithmeticException thrown) {
overFlow = true;
}
long returnValue;
if (upper - lower == Long.MAX_VALUE) {
//upper - lower + 1 = Long.MAX_VALUE + 1 = *overflow error*;
overFlow = true;
}
if (!overFlow) {
returnValue = lower + (long) (rand.nextDouble() * (upper -
lower + 1)
);
} else {
returnValue = rand.nextLong();
while (returnValue upper || returnValue lower) {
returnValue = rand.nextLong();
}
}
return returnValue;
}
RandomDataImpl nextInt(int, int) nextLong(long, long)
-
Key: MATH-153
URL: http://issues.apache.org/jira/browse/MATH-153
Project: Commons Math
Issue Type: Bug
Affects Versions: Nightly Builds, 1.1 Final
Reporter: Remi Arntzen
Priority: Critical
RandomDataImpl.nextInt(Integer.MIN_VALUE, Integer.MAX_VALUE) suffers from
overflow errors.
change
return lower + (int) (rand.nextDouble() * (upper - lower + 1));
to
return (int) (lower + (long) (rand.nextDouble()*((long) upper - lower + 1)));
additional checks must be made for the nextlong(long, long) method.
At first I thought about using MathUtils.subAndCheck(long, long) but there is
only an int version avalible, and the problem is that subAndCheck internaly
uses long values to check for overflow just as my previous channge proposes.
The only thing I can think of is using a BigInteger to check for the number
of bits required to express the difference.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MATH-152) Add MultiDimentional Support for FastFourier
Add MultiDimentional Support for FastFourier Key: MATH-152 URL: http://issues.apache.org/jira/browse/MATH-152 Project: Commons Math Issue Type: New Feature Affects Versions: Nightly Builds Reporter: Remi Arntzen -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MATH-152) Add MultiDimentional Support for FastFourier
[ http://issues.apache.org/jira/browse/MATH-152?page=all ] Remi Arntzen updated MATH-152: -- Attachment: diff.txt No documentation or test cases yet. Add MultiDimentional Support for FastFourier Key: MATH-152 URL: http://issues.apache.org/jira/browse/MATH-152 Project: Commons Math Issue Type: New Feature Affects Versions: Nightly Builds Reporter: Remi Arntzen Attachments: diff.txt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
