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
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
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))
- #PersistentMatrix
[[1, 2]
[3, 4]
[5, 6]]
(.index m (int-array [0 1]))
- 3
(- m (nth 0) (nth 1))
-
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 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 nth
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 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 in
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 int,
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
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
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 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 agree,
On Sun, May 17, 2009 at 1:15 PM, Konrad Hinsen konrad.hin...@laposte.netwrote:
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
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 the
On Mon, May 18, 2009 at 10:54 AM, Konrad Hinsen
konrad.hin...@laposte.netwrote:
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
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
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
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,
On Sat, May 9, 2009 at 7:09 PM, aperotte apero...@gmail.com 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
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
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 adrian.cuthbert...@gmail.com
wrote:
If you haven't seen it yet, the set module
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
On Sat, May 2, 2009 at 11:19 PM, aperotte apero...@gmail.com 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
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 create a
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
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
28 matches
Mail list logo
