[
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.
> Thanks for the comments @dlyubimov . Do you mean we should add a method
to expose this for dense implementations?
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.
> 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)
