[jira] [Commented] (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185447#comment-13185447 ] Henri Yandell commented on LANG-462: Not sure if you have any time to add that to your patch, but I think that would be great :) > FastDateFormat supports parse > - > > Key: LANG-462 > URL: https://issues.apache.org/jira/browse/LANG-462 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Franz Wong > Fix For: 3.x > > Attachments: DateParser.patch, LANG-462-FormatCache.patch, > LANG-462-Hen.patch, UseFormatCache.patch, lang462.patch, > with_updated_tests.patch > > > Currently FastDateFormat only supports formatting the ISO8601 time zone, > however, it doesn't support parsing such string to Date. -- 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-356) Generic weight types and algorithms implementations based on wighted graphes
[
https://issues.apache.org/jira/browse/SANDBOX-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185317#comment-13185317
]
Claudio Squarcella commented on SANDBOX-356:
_of course_ i am :D
> Generic weight types and algorithms implementations based on wighted graphes
>
>
> Key: SANDBOX-356
> URL: https://issues.apache.org/jira/browse/SANDBOX-356
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Assignee: Simone Tripodi
> Labels: generic, graph, shortestpath, type, weight
> Attachments: GenericWeightTypeAlsoForAStar.patch,
> GenericWeightTypesAndUpdatedShortestPathImplementations.patch,
> SANDBOX-356_GenericWeightTypesForSpanningTreeAlgorithms.patch
>
>
> Hello,
> with this issue I propose quite a major improvement to the current version of
> Apache Commons Graph, aimed at introducing generic types for weights (edge
> weights, vertex weights, etc) and decoupling related properties and
> operations using external classes. The proposed changes reflect observations
> and proposals that have been evaluated on the dev mailing list, particularly
> in the thread with title "On graph weight type(s)".
> A new top level package {{weight}} contains a hierarchy of interfaces
> representing different "families" of weights with their properties and
> operations: {{Zero}}, {{Semigroup}}, {{Monoid}}, {{OrderedMonoid}}. These
> interfaces are meant to be specified as input by different algorithms
> depending on the properties needed: e.g. some only require an ordering on the
> weights, some apply operations, etc. A subpackage called {{primitive}}
> contains two implementations, {{DoubleWeight}} and {{IntegerWeight}},
> respectively wrapping properties and operations on weights of type {{Double}}
> and {{Integer}}.
> In addition, some of the implementations in the package {{shortestpath}} have
> been updated to take advantage of the new generic weight types. In particular
> each of the three classes {{Dijkstra}}, {{BellmannFord}} and
> {{FloydWarshall}} now has two public methods: a generic one (working with any
> kind of weight, provided an {{OrderedMonoid}}) and a "shortcut" for weights
> of type {{Double}}, which is basically identical to the current signature.
> Other classes in the package were subject to minor changes to support the
> improvements. As an exception, {{AStar}} is still tied to {{Double}} weights
> for now: as a future step that could also use generic weights (but it needs
> more thinking for the heuristics).
> Further, in order to handle generic weight types, I got rid of
> {{Double.POSITIVE_INFINITY}} as a way to represent unreachability between two
> endpoints in a graph and replaced it with related boolean methods.
> Finally, all the tests were updated for compatibility with the new
> signatures, and they all run smoothly.
> I hope this patch meets the approval of other developers/users. I am
> available for discussion and clarification.
> Ciao,
> Claudio
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-286) FastByteArray*Stream implementations to replace syncronized JDK ByteArray*Stream
[ https://issues.apache.org/jira/browse/IO-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Loy updated IO-286: Attachment: FastByteArrayOutputStream_commons-io[2].patch > FastByteArray*Stream implementations to replace syncronized JDK > ByteArray*Stream > > > Key: IO-286 > URL: https://issues.apache.org/jira/browse/IO-286 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Paul Loy >Priority: Minor > Labels: streams, synchronized > Attachments: FastByteArrayOutputStream_commons-io.patch, > FastByteArrayOutputStream_commons-io[2].patch > > Original Estimate: 24h > Remaining Estimate: 24h > > In CASSANDRA-2820 I reintoduced the FastByteArrayInputStream and > FastByteArrayOutputStream to cassandra. These steams are un-synchronized > versions of the Apache Harmony ByteArrayInputStream and ByteArrayOutputStream > respectively. > During my own testing of the streams I found a big difference in the > performance of the standard JDK BA*S steams and the FBA*S streams on most > JREs. Then cassandra load testing also showed an up to 10% improvement in > cassandra performance using these streams. > Then Thrift has TByteArrayOutputStream which contains a way to get the > underlying byte[] buffer without a deep copy that would probably be a good > further enhancement. > Patch to follow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-286) FastByteArray*Stream implementations to replace syncronized JDK ByteArray*Stream
[ https://issues.apache.org/jira/browse/IO-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185315#comment-13185315 ] Paul Loy commented on IO-286: - Comments on the patch: * added FastByteArrayOutputStream (and corresponding unit test) * added to javadoc of ByteArrayOutputStream to suggest the Fast version when thread safety is not an issue * I decided not to make ByteArrayOutputStream extend FastByteArrayOutputStream - adding only the synchronization - as this would slow that implementation down by traversing the stack. Also note I noticed that the patch I just uploaded is wrong. New one to follow in a few seconds. > FastByteArray*Stream implementations to replace syncronized JDK > ByteArray*Stream > > > Key: IO-286 > URL: https://issues.apache.org/jira/browse/IO-286 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Paul Loy >Priority: Minor > Labels: streams, synchronized > Attachments: FastByteArrayOutputStream_commons-io.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > In CASSANDRA-2820 I reintoduced the FastByteArrayInputStream and > FastByteArrayOutputStream to cassandra. These steams are un-synchronized > versions of the Apache Harmony ByteArrayInputStream and ByteArrayOutputStream > respectively. > During my own testing of the streams I found a big difference in the > performance of the standard JDK BA*S steams and the FBA*S streams on most > JREs. Then cassandra load testing also showed an up to 10% improvement in > cassandra performance using these streams. > Then Thrift has TByteArrayOutputStream which contains a way to get the > underlying byte[] buffer without a deep copy that would probably be a good > further enhancement. > Patch to follow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-286) FastByteArray*Stream implementations to replace syncronized JDK ByteArray*Stream
[ https://issues.apache.org/jira/browse/IO-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Loy updated IO-286: Attachment: FastByteArrayOutputStream_commons-io.patch adding patch I promised many moons ago! > FastByteArray*Stream implementations to replace syncronized JDK > ByteArray*Stream > > > Key: IO-286 > URL: https://issues.apache.org/jira/browse/IO-286 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Paul Loy >Priority: Minor > Labels: streams, synchronized > Attachments: FastByteArrayOutputStream_commons-io.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > In CASSANDRA-2820 I reintoduced the FastByteArrayInputStream and > FastByteArrayOutputStream to cassandra. These steams are un-synchronized > versions of the Apache Harmony ByteArrayInputStream and ByteArrayOutputStream > respectively. > During my own testing of the streams I found a big difference in the > performance of the standard JDK BA*S steams and the FBA*S streams on most > JREs. Then cassandra load testing also showed an up to 10% improvement in > cassandra performance using these streams. > Then Thrift has TByteArrayOutputStream which contains a way to get the > underlying byte[] buffer without a deep copy that would probably be a good > further enhancement. > Patch to follow. -- 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=13185174#comment-13185174
]
Sébastien Brisard commented on MATH-732:
Thanks Kurt! Such a speed-up is obviously most welcome. As you might have
noticed (MATH-677), we are in the middle of cleaning-up the interface for fast
transforms. I'm currently working on the tests, which were a bit slim
previously. So now is a good time to include your proposal. I will look into
it, and try to reproduce your results. Please allow for some time, though!
As for having all flavours of {{transform()}} static. This would indeed be nice
not to have to instantiate {{FastFourierTransformer}}. However, this would mean
that
* the type (standard, unitary) of transform to be performed should be specified
through the call to {{transform()}}
* it would not be possible to specify the {{transform()}} methods in a common
interface (see {{RealTransformer}}). Whether it really matters, I'm not sure.
For the time being, could you please make sure you sign the
[ICLA|http://apache.org/licenses/#clas] (if you haven't already)?
> 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
>
>
> 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: FastFourierTransformerTest.java.diff FastFourierTransformer.java.diff This is a reupload of the exact same patch files. Last time, I didn't notice the ASF license option. This time, it's properly selected. > 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 > > > 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: DFTPerformanceWithPatch.png DFTPerformanceWithoutPatch.png These benchmarks were run on my laptop and averaged over ten trials. The benchmark code used the current and unchanged public API to the 3.0 FastFourierTransformer class. > 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, > FastFourierTransformerTest.java.diff > > > 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] [Created] (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
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 Fix For: 3.0 Attachments: FastFourierTransformer.java.diff, FastFourierTransformerTest.java.diff 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: FastFourierTransformerTest.java.diff FastFourierTransformer.java.diff > 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: FastFourierTransformer.java.diff, > FastFourierTransformerTest.java.diff > > > 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] (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185089#comment-13185089 ] Charles Honton commented on LANG-462: - The reason to keep separate would be to prevent code clutter. Also, if you only want parse or only want format, why pay the price of initializing the other portion of code. I was thinking of creating a new class, FastDatePrinter, which contains the current FastDateFormat code. Then, fill FastDateFormat with delegation to the FastDatePrinter and FastDateParser classes. > FastDateFormat supports parse > - > > Key: LANG-462 > URL: https://issues.apache.org/jira/browse/LANG-462 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Franz Wong > Fix For: 3.x > > Attachments: DateParser.patch, LANG-462-FormatCache.patch, > LANG-462-Hen.patch, UseFormatCache.patch, lang462.patch, > with_updated_tests.patch > > > Currently FastDateFormat only supports formatting the ISO8601 time zone, > however, it doesn't support parsing such string to Date. -- 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-664) Replace "LUDecompostionImpl" with "QRDecompositionImpl" in "AbstractLeastSquaresOptimizer"
[
https://issues.apache.org/jira/browse/MATH-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184963#comment-13184963
]
Gilles commented on MATH-664:
-
When changing from "LUDecomposition" to "QRDecomposition" in
"AbstractLeastSquares", one unit test fails: Method "testNonInvertible" does
not throw the expected exception; i.e. "getCovariances()" completes
successfully and returns:
{noformat}
-1.6604945575270566E14 1.6604945575270566E14 5.534981858423523E13
1.6604945575270566E14 -1.6604945575270544E14 -5.534981858423523E13
5.534981858423521E13 -5.53498185842352E13-1.84499395280784E13
{noformat}
Numerical problem? Perhaps the default should not be zero...
> Replace "LUDecompostionImpl" with "QRDecompositionImpl" in
> "AbstractLeastSquaresOptimizer"
> --
>
> Key: MATH-664
> URL: https://issues.apache.org/jira/browse/MATH-664
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> In some cases, the "getCovariances()" method throws a
> "SingularMatrixException". This can be avoided by using "QR" instead of "LU"
> decomposition.
--
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-664) Replace "LUDecompostionImpl" with "QRDecompositionImpl" in "AbstractLeastSquaresOptimizer"
[ https://issues.apache.org/jira/browse/MATH-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184925#comment-13184925 ] Gilles commented on MATH-664: - bq. add a user-defined threshold [in "QRDecomposition"]. Done in revision 1230509. > Replace "LUDecompostionImpl" with "QRDecompositionImpl" in > "AbstractLeastSquaresOptimizer" > -- > > Key: MATH-664 > URL: https://issues.apache.org/jira/browse/MATH-664 > Project: Commons Math > Issue Type: Improvement >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Fix For: 3.0 > > > In some cases, the "getCovariances()" method throws a > "SingularMatrixException". This can be avoided by using "QR" instead of "LU" > decomposition. -- 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] (LANG-784) Strange behavior on StringUtils.difference
[
https://issues.apache.org/jira/browse/LANG-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184871#comment-13184871
]
Sebb commented on LANG-784:
---
Or the Javadoc should be fixed.
The first sentence is misleading as can be taken to imply that the method is
symmetric.
However, the method currently behaves more like arithmetical difference, which
is not symmetric.
Are there any use cases where the non-symmetric behaviour is useful?
If we are not sure, then one could add a symmetricDifference method.
> Strange behavior on StringUtils.difference
> --
>
> Key: LANG-784
> URL: https://issues.apache.org/jira/browse/LANG-784
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.0.1
>Reporter: Arnaud BRUNET
>Priority: Minor
>
> Hi,
> The behavior of the method StringUtils.difference () behaves in a
> non-intuitive (explain in the javadoc).
> StringUtils.difference ("abc", "") returns "" as intuitively expected to be
> "abc".
> Is it possible to change this behavior ?
> Regards,
> Arnaud
--
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-356) Generic weight types and algorithms implementations based on wighted graphes
[
https://issues.apache.org/jira/browse/SANDBOX-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-356.
Resolution: Fixed
Thanks Claudio for moving this topic forward!
There are "just a couple" of open issues on [graph], I don't know if you are
pleased to work on them... :P
> Generic weight types and algorithms implementations based on wighted graphes
>
>
> Key: SANDBOX-356
> URL: https://issues.apache.org/jira/browse/SANDBOX-356
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Assignee: Simone Tripodi
> Labels: generic, graph, shortestpath, type, weight
> Attachments: GenericWeightTypeAlsoForAStar.patch,
> GenericWeightTypesAndUpdatedShortestPathImplementations.patch,
> SANDBOX-356_GenericWeightTypesForSpanningTreeAlgorithms.patch
>
>
> Hello,
> with this issue I propose quite a major improvement to the current version of
> Apache Commons Graph, aimed at introducing generic types for weights (edge
> weights, vertex weights, etc) and decoupling related properties and
> operations using external classes. The proposed changes reflect observations
> and proposals that have been evaluated on the dev mailing list, particularly
> in the thread with title "On graph weight type(s)".
> A new top level package {{weight}} contains a hierarchy of interfaces
> representing different "families" of weights with their properties and
> operations: {{Zero}}, {{Semigroup}}, {{Monoid}}, {{OrderedMonoid}}. These
> interfaces are meant to be specified as input by different algorithms
> depending on the properties needed: e.g. some only require an ordering on the
> weights, some apply operations, etc. A subpackage called {{primitive}}
> contains two implementations, {{DoubleWeight}} and {{IntegerWeight}},
> respectively wrapping properties and operations on weights of type {{Double}}
> and {{Integer}}.
> In addition, some of the implementations in the package {{shortestpath}} have
> been updated to take advantage of the new generic weight types. In particular
> each of the three classes {{Dijkstra}}, {{BellmannFord}} and
> {{FloydWarshall}} now has two public methods: a generic one (working with any
> kind of weight, provided an {{OrderedMonoid}}) and a "shortcut" for weights
> of type {{Double}}, which is basically identical to the current signature.
> Other classes in the package were subject to minor changes to support the
> improvements. As an exception, {{AStar}} is still tied to {{Double}} weights
> for now: as a future step that could also use generic weights (but it needs
> more thinking for the heuristics).
> Further, in order to handle generic weight types, I got rid of
> {{Double.POSITIVE_INFINITY}} as a way to represent unreachability between two
> endpoints in a graph and replaced it with related boolean methods.
> Finally, all the tests were updated for compatibility with the new
> signatures, and they all run smoothly.
> I hope this patch meets the approval of other developers/users. I am
> available for discussion and clarification.
> Ciao,
> Claudio
--
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] (LANG-755) DateFormatUtils.format manipulates Calendar behaviour
[
https://issues.apache.org/jira/browse/LANG-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-755:
---
Fix Version/s: 3.2
We should definitely javadoc this. I'm not sure we can do much else. It'd be
good to test on the latest JDK to see if it's been fixed.
Setting a 3.2 fixversion for the javadoc as it seems like a very non-intrusive
change.
> DateFormatUtils.format manipulates Calendar behaviour
> -
>
> Key: LANG-755
> URL: https://issues.apache.org/jira/browse/LANG-755
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Reporter: hans-jürgen kozik
>Priority: Minor
> Fix For: 3.2
>
>
> {code}
> @Test
> public void testClearCalendar() {
> Calendar cal = Calendar.getInstance();
> cal.clear(Calendar.MINUTE);
> System.out.println(cal.isSet(Calendar.MINUTE)); //false
> System.out.println(DateFormatUtils.ISO_DATETIME_FORMAT.format(cal));
> System.out.println(cal.isSet(Calendar.MINUTE)); //true
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-784) Strange behavior on StringUtils.difference
[
https://issues.apache.org/jira/browse/LANG-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184807#comment-13184807
]
Henri Yandell commented on LANG-784:
I agreed with Arnaud that this is odd. Primarily because of the following:
System.err.println(StringUtils.difference("abc", "ab"));
This results in an empty String. That's just useless :) The answer is "c" and
not empty String. Easy to fix by swapping the parameters based on length so
that the longer parameter is always second.
API-wise, I wouldn't want to change if it was only the example that Arnaud
lists, but if any related content returns a non-intuitive reply it seems to me
that the method is buggy and should be fixed.
> Strange behavior on StringUtils.difference
> --
>
> Key: LANG-784
> URL: https://issues.apache.org/jira/browse/LANG-784
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.0.1
>Reporter: Arnaud BRUNET
>Priority: Minor
>
> Hi,
> The behavior of the method StringUtils.difference () behaves in a
> non-intuitive (explain in the javadoc).
> StringUtils.difference ("abc", "") returns "" as intuitively expected to be
> "abc".
> Is it possible to change this behavior ?
> Regards,
> Arnaud
--
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] (LANG-781) Null-Check to variable Object parameters - ObjectUtils.isAnyNull
[ https://issues.apache.org/jira/browse/LANG-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184803#comment-13184803 ] Henri Yandell commented on LANG-781: Both sound valuable. Matt - simplest is to add the code and run CLIRR :) We should use a different JIRA item for the Validate.noNullElements(...). > Null-Check to variable Object parameters - ObjectUtils.isAnyNull > > > Key: LANG-781 > URL: https://issues.apache.org/jira/browse/LANG-781 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 3.1 >Reporter: Sandro Lehmann >Priority: Minor > Labels: patch > Attachments: ObjectUtils.java.patch, ObjectUtilsTest.java.patch > > > Sometimes it would be very comfortable, to test a few objects to null. > Instead of writing if(obj1==null || obj2==null || ...), using a method like > isAnyNull(obj1, obj2, ...) would be much better. -- 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] (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184797#comment-13184797 ] Henri Yandell commented on LANG-462: Thanks Charles, that fixes the tests :) Except for the odd failing locales that you noted as System.outs. Going back to your very early question - any thoughts on whether there are any reasons why it couldn't be in FastDateFormat? > FastDateFormat supports parse > - > > Key: LANG-462 > URL: https://issues.apache.org/jira/browse/LANG-462 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Franz Wong > Fix For: 3.x > > Attachments: DateParser.patch, LANG-462-FormatCache.patch, > LANG-462-Hen.patch, UseFormatCache.patch, lang462.patch, > with_updated_tests.patch > > > Currently FastDateFormat only supports formatting the ISO8601 time zone, > however, it doesn't support parsing such string to Date. -- 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
