Hi.
I'm experimenting with Renjin interop - in particular, trying to make a
Renjin objects implement core.matrix protocols (as mikera suggested).
I hope to be able to share some draft soon. then ask your opinions about
it.
Hi.
I'm experimenting with Renjin interop - in particular, trying
Chaoya,
I haven't been working on this, and I don't really intend to anytime
soon, there's other work that I must attend to in the immediate time-frame.
- Arthur
On Saturday, June 4, 2016 at 11:51:49 PM UTC-4, Chaoya Li wrote:
>
> Hi I'm interested in Clojure DataFrame implementation. How
Hi I'm interested in Clojure DataFrame implementation. How is this going
now? Are you coding for core.matrix or are you writing a new library from
scratch? How can I join in this project?
在 2016年3月10日星期四 UTC+8上午4:57:31，arthur.ma...@gmail.com写道：
>
> Is there any desire or need for a Clojure
On Friday, 11 March 2016 09:21:09 UTC+8, arthur.ma...@gmail.com wrote:
>
> Renjin and Spark's dataframes are not going to be easily removed from
> their respective codebases, as far as my brief perusal of the source can
> tell. I agree that N-D DataFrames would be a good addition to the
>
On Friday, 11 March 2016 09:09:14 UTC+8, Dragan Djuric wrote:
>
> This is already working well for the array programming APIs (it's easy to
>> mix and match Clojure data structures, Vectorz Java-based arrays, GPU
>> backed arrays in computations).
>>
>
> While we could agree to some extent on
Renjin and Spark's dataframes are not going to be easily removed from their
respective codebases, as far as my brief perusal of the source can tell. I
agree that N-D DataFrames would be a good addition to the ecosystem,
similar to the goals of Python's xarray (xarray.pydata.org). However, it is
>
> This is already working well for the array programming APIs (it's easy to
> mix and match Clojure data structures, Vectorz Java-based arrays, GPU
> backed arrays in computations).
>
While we could agree to some extent on the other parts of your post but the
GPU part is *NOT* true: I
core.matrix maintainer here.
I think it would be great to have more work on dataframe-type support. I
think the right strategy is as follows:
a) Make use of the core.matrix Dataset protocols where possible (or add new
ones)
b) Create implementation(s) for these protocols for whatever back-end
Dan,
That's a huge amount of stats packages available for use assuming we
achieve interop with Renjin's dataframes. I'll look into it as well. My
priorities are to first get something working for $DAYJOB, and then to
build a more generally useful package, and finally add extras such as
Sounds great; and sure thing, will do :-)
The basic idea I had was to implement a bidirectional index mapping names
<-> indices. This requires making sure you keep the index up to date any
time you change the data, but seemed the easiest way forward.
My fork is here:
Chris, thanks for the reply.
It's good to know that I'm not the only one who misses this functionality!
My goal is definitely to be compatible with Incanter and core.matrix, as
they both seem mature, and I will never have the time to implement that
functionality from scratch myself. I'll be
Thank you for raising this question.
By the way, one desired feature for a Clojure dataframe abstraction would
be good interop with Renjin's dataframes.
Renjin is a JVM-based rewrite of (a subset of) R. It offers a large number
of JVM-based statistical libraries. Most of them rely on the
If you're going to do any work in this area, I would highly encourage you
to do in as part of the core.matrix library. That is what Incanter is or
will be using for it's dataset implementation. But it's nice that those
abstractions and implementations be separate from Incanter itself, since
Is there any desire or need for a Clojure DataFrame?
By DataFrame, I mean a structure similar to R's data.frame, and Python's
pandas.DataFrame.
Incanter's DataSet may already be fulfilling this purpose, and if so, I'd
like to know if and how people are using it.
>From quickly researching, I
14 matches
Mail list logo
