[ https://issues.apache.org/jira/browse/MAHOUT-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15770725#comment-15770725 ]
ASF GitHub Bot commented on MAHOUT-1895:
----------------------------------------
Github user dlyubimov commented on the issue:
https://github.com/apache/mahout/pull/262
@rawkintrevo there are really two reasons to want toArray(). One is to have its contracts (I guess it is what you are appealing to when you say you want to wrtie summaries etc.) and one is because Array is common part of somebody else's contract.
On reason one, the refute is simple because Vector does all Array contract does, i.e., it has random access contract with exact the same scala signature. Actually it has much more, including things like pretty print that are useful for summaries.
On reason two, it is a more valid case. However, i found that one much more often wants avoid copying memory anyway and that optional array() is much more desired in all of my usecases. It is true i am an algorithm developer and so my use cases are skewed that way. One example would be repackaging of dense matrices and vectors we had in VCL integration. that's what we wanted there -- the optionally supported non-copying array() method. but we did not want a copying method at all since we were repackaging it into native memory anyway. So were some similar other cases.
I am sure you can provide a specific case where you want toArray(), which i suspect might be the motivation where you have to use some other 3rd party contract and then it might be a better shaped argument if you give us some concrete examples of that 3rd party contract you've encountered a need to use.
yes. This is an alternative i would need.
exposing non-copying collection.Map implementation makes sense for RandomAccessSparseVector and whatever other implementations that adhere to Map's promise of O(1) lookup. For Sequential i don't see it as appropriate non-copying for the same very reason -- it violates O(1) contract promise.
In general it has occured to me that I am somehwat more ready to consider toMap, toSeq (and even toArray) that implement correspondent Scala collections because it is consistent with strict Scala collection contract use (i.e., admittance of a copying contract) as long as it is available in Scala only. Regardless, implementation must consider individual underlying structure for the copying efficiency. I.e., it has to use non-default element iterators where appropriate (just like we do with VCL adapting).
But i happen to want implementing collection.Map for random access and optional array() for DenseVector more than the copying contracts.
Post by Trevor Grant (JIRA)Add convenience methods for converting Vectors to Scala types
-------------------------------------------------------------
Key: MAHOUT-1895
URL: https://issues.apache.org/jira/browse/MAHOUT-1895
Project: Mahout
Issue Type: Bug
Affects Versions: 0.12.2
Reporter: Trevor Grant
Assignee: Trevor Grant
Priority: Minor
Fix For: 0.13.0
While dense and sparse vectors may be created from `TraversableOnce[Double]` such as `Array[Double]` and `TraversableOnce[(Int, AnyVal)]` such as `Map[Int,Double]` respectively. Converting back into this format is somewhat tedious. We should add convenience methods to take care of this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)