On Friday, June 19, 2015 at 11:17:02 PM UTC+2, Christopher Small wrote: > > I see now Dragan; you're concerned not about whether easily implementing > and swapping in/out implementations of core.matrix is possible, but whether > it can be done while maintaining the performance characteristics of > Neanderthal, yes? That did not come through in your earlier comments in > this thread. >
This, with the addition that for *any* library, not only Neanderthal, there would be many leaking abstractions. It is easy to define common function/method names and parameters, but there are many things that just flow through the API regardless, and taming this is the hardest part of any API. > > Certainly, performance is one of those things that can leak in an > abstraction. But I'd like to echo Matt's enquiry: If you think a unified > API might be possible but that core.matrix isn't it, I think we'd all love > to hear what you think it's missing and/or what would would need to be > rearchitected in order for it to fit the bill. > For an unified API, if it is at all feasible, I think there is one place it should be looked at first: BLAS 1, 2, 3 and LAPACK. This is THE de facto standard for matrix computations for dense and banded matrices. Sparse APIs are not that uniform, bat in that space, also, there is a lot of previous work. So, what's wrong with BLAS/LAPACK that core.matrix choose not to follow it and arbitrarily invent (in my opinion) unintuitive and complicated API? I am genuinely interested, maybe I don't see something that other people do. In my opinion, the best way to create a standard API is to grow it from successful implementations, instead of writing it first, and then shoehorning the implementations to fit it. > > As for any sort of "responsibility" to implement core.matrix, I don't > think anyone is arguing you have such a responsibility, and I hope our > _pleading_ hasn't come across as such. We are simply impressed with your > work, and would like to take advantage of it, but also see a "drawback" you > don't: at present Neanderthal is less interoperable with many existing > tools, and "trying it out" on an existing project would require a rewrite > (as would migrating away from it if we weren't happy). > > Certainly, a third party library implementing core.matrix with Neanderthal > is a possibility, but I'm a bit worried that a) it would add extra burden > keeping things in sync and feel a little second class; and more importantly > b) it might be easier to maintain more of the performance benefits if it's > directly integrating (I could imagine less indirection this way, but could > be totally wrong). So let me ask you this: > > Assuming a) someone forks Neanderthal and makes a core.matrix > implementation with close performance parity to the direct Neanderthal API > and/or b) folks working on core.matrix are able to address some of your > issues with the core.matrix architecture, would you consider a merge? > a) I would rather see the core.matrix interoperability as an additional separate project first, and when/if it shows its value, and there is a person willing to maintain that part of the code, consider adding it to Neanderthal. I wouldn't see it as a second rate, and no fork is needed because of Clojure's extend-type/extend-protocol mechanism. b) I am not sure about what's exactly "wrong" with core.matrix. Maybe nothing is wrong. The first thing that I am interested in is what do core.matrix team think is wrong with BLAS/LAPACK in the first place to be able to form an opinion in that regard. Best Wishes, Dragan > > With gratitude > > Chris > > > > On Fri, Jun 19, 2015 at 1:45 PM, Matt Revelle <mrev...@gmail.com > <javascript:>> wrote: > >> On Friday, June 19, 2015 at 4:57:32 AM UTC-4, Dragan Djuric wrote: >>> >>> I do not even claim that an unified api is not possible. I think that to >>> some extent it is. I just doubt in core.matrix eligibility for THE api in >>> numerical computing. For it makes easy things easy and hard things >>> impossible. >> >> >> Are you saying you don't believe core.matrix should be _the_ abstract API >> for matrices/arrays in Clojure? If so, what are your concerns? Feel free to >> point to me a previous post if it's already been stated. It also sounds >> like you're alluding to the thread in the Numerical Clojure group about a >> broad "numerical computing lib" for complex numbers and various math >> functions, but I'm not following how that matters here. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojure/dFPOOw8pSGI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
