[
https://issues.apache.org/jira/browse/MATH-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774695#action_12774695
]
Bill Barker commented on MATH-312:
----------------------------------
The patch could use a lot more JavaDoc comments, but since they are mostly
InheritDoc, I can live with putting them in myself.
What I do have a problem with is generalizing OpenMapRealVector to allow for
different default values then zero. This means that you get different results
(in the sense of equals) if you try and operate with two vectors that have
different default values depending on which is LHS and which is RHS. I would
need a use case to commit that can of worms.
> RealVector interface could use some iterators (dense and sparse) and generic
> map() and collect() methods.
> ---------------------------------------------------------------------------------------------------------
>
> Key: MATH-312
> URL: https://issues.apache.org/jira/browse/MATH-312
> Project: Commons Math
> Issue Type: New Feature
> Affects Versions: 2.0
> Environment: all
> Reporter: Jake Mannix
> Fix For: 2.1
>
> Attachments: MATH-312.patch, MATH-312.patch
>
>
> As discussed on the [math] list, there are other projects out there which
> would love to get a chance to standardize on using commons-math for things
> like linear algebra primitives, as it would build a common base to build
> upon. But to do that, some well-known and used techniques for dealing with
> vectors, for one thing, are missing. Most glaringly is the treatment of
> sparse vectors: giving no Iterator for non-default values means external
> clients lose the advantage of sparseness - only internal methods can skip
> around.
> Extending the RealVector interface with sparse (and dense) iterator methods
> would fix this:
> {code}
> double getDefaultValue();
> Iterator<RealVector.Entry> iterator();
> Iterator<RealVector.Entry> nonDefaultIterator();
> {code}
> but there is another way to deal with vector data as well: instead of passing
> iterators around, and worrying about all the lovely ConcurrentModification
> and unsupported "remove" methods (which aren't the end of the world), we can
> instead expose generic map functions:
> {code}
> RealVector map(UnivariateRealFunction f);
> RealVector mapToSelf(UnivariateRealFunction f);
> {code}
> where RealVector mapToSelf(UnivariateRealFunction), which applies the
> function to the vector's entries (checking whether the function preserves the
> default value up front allows it to chose between the sparse or dense
> iterator), and map just applies mapToSelf to a copy.
> This doesn't exhaust all possible places where Iterators could be used
> helpfully (there's also combining two vectors together via a
> {code}map(BinaryRealFunction, RealVector other){code} which could be
> specialized nonlinear forms of addition or subtraction, and {code}double
> collect(UnivariateRealFunction, BinaryRealFunction){code} which uses the
> iterates over all of the entries, applying the first unary function to each
> entry, and then applying the binary function to combine this value with the
> previous accumulated value - with "pow(2)", and "+" as the two functions, you
> get L2 norm, with "abs()" and "+", you get L1 norm, etc...)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
