Hello Eugene,
Thursday, February 26, 2009, 10:28:13 PM, you wrote:
Thanks, I'll have a look at these. Treating unboxed stuff
polymorphically is anyways very interesting and would be good to use
in collections API that has been recently discussed (and which I
occasionally try to continue
I'm exactly basing on them, but they don't have at least these things:
- Monad-mutable collections like MArray
- Instances of something like Assoc for arrays (arrays are
collections in some sense, after all)
- Treatment for unboxed types (I don't know yet, whether it is
needed; but why do
Hello Eugene,
Friday, February 27, 2009, 4:42:03 PM, you wrote:
I'm exactly basing on them, but they don't have at least these things:
them means Edison or Collections typeclasses?
- Treatment for unboxed types (I don't know yet, whether it is
needed; but why do STUArrays have special
2009/2/27 Bulat Ziganshin bulat.zigans...@gmail.com:
Hello Eugene,
Friday, February 27, 2009, 4:42:03 PM, you wrote:
I'm exactly basing on them, but they don't have at least these things:
them means Edison or Collections typeclasses?
The EdisonAPI.
- Treatment for unboxed types (I don't
I'm still learning haskell, so I may be missing something pretty
obvious, but isn't this the kind of thing that the diff array types
were created for.
http://en.wikibooks.org/wiki/Haskell/Hierarchical_libraries/Arrays#DiffArray_.28module_Data.Array.Diff.29
-Keith
On Thu, Feb 26, 2009 at
It is, but they are still too slow. STArrays rock the world.
2009/2/28 Keith Sheppard keiths...@gmail.com:
I'm still learning haskell, so I may be missing something pretty
obvious, but isn't this the kind of thing that the diff array types
were created for.
Eugene Kirpichov wrote:
You need to use STUArray. The Data.Array
completely-immutable-and-boxed arrays are ok only for tasks where you
build an array once and don't modify it, and where you need array
elements to be lazy.
The // operation creates a copy of the whole array with one element
Daniel Fischer wrote:
Am Donnerstag, 26. Februar 2009 14:53 schrieb Daniel Kraft:
Hi,
I seem to be a little stuck with incremental array updates... I've got
an array of few (some thousand) integers, but have to do a calculation
where I incrementally build up the array. For sake of
STUArray is really a bit tricky to get used with: especially, if you
do something wrong, the type errors will be rather dreadful.
However, if you do everything right, it's OK and you sometimes even
don't need to write the types at all.
There are a couple of examples here
Ross Paterson wrote:
On Thu, Feb 26, 2009 at 02:53:42PM +0100, Daniel Kraft wrote:
I seem to be a little stuck with incremental array updates... I've got
an array of few (some thousand) integers, but have to do a calculation
where I incrementally build up the array. For sake of simplicity,
On Thu, Feb 26, 2009 at 05:31:34PM +0100, Daniel Kraft wrote:
Well, my main problem was the lazy evaluation...
No, your main problem was that you were creating 100,000 arrays,
each only a little different from the one before.
For this example program... yes of course :) I'm trying to do so
Ross Paterson wrote:
On Thu, Feb 26, 2009 at 05:31:34PM +0100, Daniel Kraft wrote:
Well, my main problem was the lazy evaluation...
No, your main problem was that you were creating 100,000 arrays,
each only a little different from the one before.
Here I have to disagree (in my particular
Hello Daniel,
Thursday, February 26, 2009, 9:27:10 PM, you wrote:
It was about this: I needed to generate all possibilities for some
combinations and each of those had a numeric property, say from 1 to
1; I then had to count how many of the possibilities were of a given
category. So I
On Thu, Feb 26, 2009 at 07:27:10PM +0100, Daniel Kraft wrote:
It was about this: I needed to generate all possibilities for some
combinations and each of those had a numeric property, say from 1 to
1; I then had to count how many of the possibilities were of a given
category. So I
On Thu, Feb 26, 2009 at 06:45:27PM +, Ross Paterson wrote:
Yes, bucketing problems like this are a common case that the standard
functions cannot handle. Perhaps the libraries need a canned solution.
Stratch that -- as Bulat points out, accumArray is such a canned solution.
On Thu, Feb 26, 2009 at 09:36:17PM +0300, Bulat Ziganshin wrote:
Thursday, February 26, 2009, 9:27:10 PM, you wrote:
It was about this: I needed to generate all possibilities for some
combinations and each of those had a numeric property, say from 1 to
1; I then had to count how many
Hello Ross,
Thursday, February 26, 2009, 9:54:23 PM, you wrote:
the same loop using STArray, but accumArray provide you pure API for
such computations
And accumArray can also be used with UArray if laziness is a problem.
to be exact, for Array, STArray used internally
for
Hello Eugene,
Thursday, February 26, 2009, 5:32:14 PM, you wrote:
look at http://haskell.org/haskellwiki/Library/ArrayRef
it contains reimplementation of arrays library according to OlegSimon idea:
- Unboxed arrays now can be used in polymorphic functions, they are defined
for every element
Hello,
Thanks, I'll have a look at these. Treating unboxed stuff
polymorphically is anyways very interesting and would be good to use
in collections API that has been recently discussed (and which I
occasionally try to continue inventing with scarce success :-/ ).
2009/2/26 Bulat Ziganshin
19 matches
Mail list logo
