[
https://issues.apache.org/jira/browse/MAHOUT-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982714#comment-13982714
]
Dmitriy Lyubimov commented on MAHOUT-1500:
------------------------------------------
bq. These statements are both explicit and implicit and include in paraphrased
form:
bq. A comment about a "performance bug" means that h2o can't implement the
Matrix API
bq. The reference to a "performance bug" does not imply that the operations do
not work and, indeed, their availability might be handy during initial
implementation of algorithms.
Paraphrasing me means admitting i did not say that. I am well aware that these
APIs in question are _naively_ supported. When a person takes an iterator
(regardless of what one iterates over) it is expected as a general rule that
would be a O(n) iteration. Using it for O(1) is not a general rule (in fact, i
don't know example of that over entire current codebase).
So thus we established two things here:
(1) abstraction is not useful for general rule. O(n)
(2) abstraction may be useful for non-general rule O(1).
So according to general rule, this abstraction is not useful. Saying that
general rule can be overturned by special case is a fallacy in retorics called
"special pleading", i.e. arguing against general rule based on an exception.
bq. entire section (C) in his comments is essentially vacuous since it is
based entirely on false premises
Proposal (C) actually stated the proposal (implement optimizer plugin for h20)
and also argumentation why it may be difficult. I am not sure what is moot --
the proposal, or why it is unfeasible. Either way, it is based on my discussion
with h20 team and their own admittance(including dev list) that programming
model is not where it needs be. If they know that these goodies are provided as
primitives they never stated so. I was actually very hopeful and positive about
it in the beginning that there were. You are the first person on record on the
topic that advertises H20 as rich programming model. If so, that's wonderful, i
would be happy to re-examine my proposal C myself. That said, i already
admitted I should not be considered an expert on the exact set of capabilities
there. My point with proposal (C) was that giving physical layer translation
for h20 things is viewed as more consistent integration path, but not so much
why it is unfeasible.
bq. The emotional tenor of Dmitriy Lyubimov's comments are exactly what is
encouraging the h2o work to be done a bit apart. It simply isn't efficient to
have to answer so many off-topic points whenever any reports on work in
progress are given.
I think this has been the off-topic here.
Calling my comments "emotional" or "non-technical", or _loosely_ paraphrasing
me.
It is also a well known rhetorical fallacy -- attacking opponent's character or
expertise with hope he or she would go into defending it while distracting from
the actual issue at hand. Which allows to mount even further similar attacks.
But it wouldn't matter even if I ate children for dinner, discussion of my
character (or expertise) is totally irrelevant to this Jira or strength
argumentation of whomever. Rhethorics would argue this actually makes your
position look weaker, making people think the rest of your argumentation base
is weaker than it is.
Anyway, I just wanted to make it clear that I don't see it as reasonable to use
my name as any sort of pretext to do (or not to do) things as opposed that they
are normally done in Apache. I am also willing to make it easier since I will
not return to this jira and will not vote negatively on it.
Actually quite opposite, i have always had and will encourage to bring things
more forward for people to look at, not being clear on intent was what has been
causing so much confusion about this all in the first place.
> H2O integration
> ---------------
>
> Key: MAHOUT-1500
> URL: https://issues.apache.org/jira/browse/MAHOUT-1500
> Project: Mahout
> Issue Type: Improvement
> Reporter: Anand Avati
> Fix For: 1.0
>
>
> Integration with h2o (github.com/0xdata/h2o) in order to exploit its high
> performance computational abilities.
> Start with providing implementations of AbstractMatrix and AbstractVector,
> and more as we make progress.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
