Konrad,
Thanks for hashing this through with me. I thought about it for a
while and I think you're right. When I start working on this project
again, I'm going to implement it so that index order is consistent
across all operations.
-Adler
On May 27, 12:11 pm, Konrad Hinsen wrote:
> On May 2
On May 27, 2009, at 1:03, aperotte wrote:
> I think I understand your point now. You would like the indexing to
> match the implicit dimension order of the nested structure.
Right.
> I was also concerned about storage order because I wanted to at some
> point integrate this datastructure with
Hi Konrad,
I think I understand your point now. You would like the indexing to
match the implicit dimension order of the nested structure.
I was also concerned about storage order because I wanted to at some
point integrate this datastructure with colt or parallel colt and the
incanter library.
On May 26, 2009, at 14:59, aperotte wrote:
> Numpy does things a bit differently, I think in a large part because
> their format is row major. Based on my understanding of the two
> formats, in the multidimensional generalization of row and column
> major the left most and the right most indices
Konrad,
I did some thinking about this and I think what's there is actually
what I intended for it to be. I did expect for (nth data 1) and (nth
m 1) to return similar structures and that was part of the reasoning.
Numpy does things a bit differently, I think in a large part because
their forma
On 26.05.2009, at 00:31, aperotte wrote:
> I don't expect to yield the same results. I would expect (.index m
> (int-array [0 1])) and (-> m (nth 1) (nth 0)) to yield the same
> results. This is because the first is equivalent to taking item 0 in
> the first dimension (always rows) and item 1 i
Oh ok, I think I see where the problem is. There's a mistake/bug in
how I rerepresent the nested array. I represent that array as a 2x3
internally, when it should actually be a 3x2. Which is why I was
thinking the printing was (and still is) backwards.
However, these two statements:
>
Oh ok, I think I see where the problem is. There's a mistake/bug in
how I rerepresent the nested array. I represent that array as a 2x3
internally, when it should actually be a 3x2. Which is why I was
thinking the printing was (and still is) backwards.
However, these two statements:
>
On 25.05.2009, at 21:08, aperotte wrote:
> Say that you're dealing with a structure of x dimensions. In this
> frame, imagine that you have a list of x-1 dimensional objects in a
> list that is as long as the xth dimension. You can cons up these
> things that are n-1 in dimensionality and use n
Hi Konrad,
In writing these functions, I was trying to blend the worlds of lispy
data structure building and more familiar matrix indexing.
I wanted to be able to treat matrices like elements of a list that
could be consed/conjed together to build up data abstractions. This is
necessary to keep
On May 19, 2009, at 14:28, aperotte wrote:
> Let me know if you have any questions or comments!
Indexing:
(def data [[1 2] [3 4] [5 6]])
(def m (PersistentMatrix/create (int-array [1]) true))
-> #
(.index m (int-array [0 1]))
-> 3
(-> m (nth 0) (nth 1))
-> 2
I'd expect the last two expressi
On 21.05.2009, at 15:38, aperotte wrote:
> Though I can't say I've thoroughly tested this, the intended
> functionality is that you provide a nested structure and you specify
> the shape of the units with the first argument.
Ah, I see. I didn't try that at all.
>> 2) Shapes and indices are all
> 1) What is the role of the first argument to PersistentMatrix/create?
> It seems that anything else than (int-array [1]) leads to an error.
Though I can't say I've thoroughly tested this, the intended
functionality is that you provide a nested structure and you specify
the shape of the units
On 19.05.2009, at 14:28, aperotte wrote:
> Let me know if you have any questions or comments!
Two for today:
1) What is the role of the first argument to PersistentMatrix/create?
It seems that anything else than (int-array [1]) leads to an error.
2) Shapes and indices are all int, rather tha
DataCube reminds me of http://timecube.com/
Completely OT, though... or is it?
On May 19, 2009, at 10:18 AM, Konrad Hinsen wrote:
> On May 19, 2009, at 14:28, aperotte wrote:
>
>> I'm glad you got it working. I'll have to look into compiling it
>> with
>> an earlier version of java.
>>
>> I
On May 19, 2009, at 14:28, aperotte wrote:
> I'm glad you got it working. I'll have to look into compiling it with
> an earlier version of java.
>
> I'm actually not using ant for this project just yet. I'm compiling
> with javac.
A working build.xml is attached - feel free to add it!
> I agre
Great!
I'm glad you got it working. I'll have to look into compiling it with
an earlier version of java.
I'm actually not using ant for this project just yet. I'm compiling
with javac.
I agree, it's unfortunate that matrix carries the connotation of 2D.
PersistentNDArray, PersistentDataCube,
On May 18, 2009, at 16:34, Konrad Hinsen wrote:
> understand ant in any way), and I managed to obtain a jar file
> without any compiler error messages, but when I try to import
> persistentmatrix.core into clojure, it fails:
>
> java.lang.NoClassDefFoundError: clojure/lang/Sequential
> (NO_SOURCE
On May 18, 2009, at 15:10, aperotte wrote:
> I was going to attempt to implement the data structure in clojure
> initially, but I wanted to make it as close a cousin to the other data
> structures as possible. I also wanted to easily integrate the use of
> the data structure with other math libr
Thanks for the information Konrad. I haven't had a chance to take a
close look at monads, but you've bumped it much higher on my list of
things to look at.
I was going to attempt to implement the data structure in clojure
initially, but I wanted to make it as close a cousin to the other data
str
On Mon, May 18, 2009 at 10:54 AM, Konrad Hinsen
wrote:
>
> On May 18, 2009, at 11:21, Anand Patil wrote:
>
> > Huh, sounds like just the thing. Security is going to be especially
> > difficult in Clojure, though. For example, say I stuck the array
> > into a ref from within the monad, then carried
On May 18, 2009, at 11:21, Anand Patil wrote:
> Huh, sounds like just the thing. Security is going to be especially
> difficult in Clojure, though. For example, say I stuck the array
> into a ref from within the monad, then carried on overwriting it. A
> consumer who gets the array out of t
On Sun, May 17, 2009 at 1:15 PM, Konrad Hinsen wrote:
>
> On 16.05.2009, at 15:53, aperotte wrote:
>
> > Yes Anand, I'm worried about that. What I think the solution should
> > be is to allow mutability in the implementation of algorithms in the
> > java back end for the reasons you mentioned, bu
On 16.05.2009, at 15:53, aperotte wrote:
> Yes Anand, I'm worried about that. What I think the solution should
> be is to allow mutability in the implementation of algorithms in the
> java back end for the reasons you mentioned, but a clean immutable
> interface on the clojure side. When users
Yes Anand, I'm worried about that. What I think the solution should
be is to allow mutability in the implementation of algorithms in the
java back end for the reasons you mentioned, but a clean immutable
interface on the clojure side. When users are faced with serious
memory limitations, though,
On Sat, May 9, 2009 at 7:09 PM, aperotte wrote:
>
> It shouldn't be a problem to maintain immutability and also perform a
> cross/cartesian product. I'm not sure I understand the problem.
It was a pretty bad example... what I meant was, in scientific computing,
people often have to take a deep
Thanks Adrian,
I have looked at the clojure.set library, but haven't thought about it
significantly with respect to the matrix library. Thanks for the
heads up.
-Adler
On May 6, 11:17 pm, Adrian Cuthbertson
wrote:
> If you haven't seen it yet, the set module (clojure.set) provides a
> basic i
Hey Anand,
Thanks for the feedback!
I would have liked to call the arrays "arrays" but java's arrays make
that name less than ideal. If people think a better name for the
library is persistentarray, I'm not opposed to changing (especially
this early in the game).
It shouldn't be a problem to m
Can't wait to try this out!
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to
clojure+unsubs
If you haven't seen it yet, the set module (clojure.set) provides a
basic implementation of set relational algebra. May be useful for this
work?
See clojure.org data structures and the source for clojure/set.clj in
the clojure source.
Rgds, Adrian.
On Wed, May 6, 2009 at 7:05 PM, Anand Patil
w
On Sat, May 2, 2009 at 11:19 PM, aperotte wrote:
>
> Hello everyone,
>
> I just uploaded some of my work on a new datatype for clojure to a git
> repository.
>
> http://github.com/aperotte/persistentmatrix
>
> A bit of the rationale and motivation for the datatype is described on
> the github pag
It's compatible with other libraries to varying degrees. The internal
data stored in a linear array.
As with most things, we could probably coerce the datatype into
compatibility with any java library, but how efficient things will be
would vary.
It would definitely be great to see integration
On May 3, 2009, at 0:19, aperotte wrote:
> I just uploaded some of my work on a new datatype for clojure to a git
> repository.
>
> http://github.com/aperotte/persistentmatrix
>
> A bit of the rationale and motivation for the datatype is described on
> the github page. I basically wanted to crea
Hello everyone,
I just uploaded some of my work on a new datatype for clojure to a git
repository.
http://github.com/aperotte/persistentmatrix
A bit of the rationale and motivation for the datatype is described on
the github page. I basically wanted to create a datastructure for
manipulating l
34 matches
Mail list logo
