Bulat Ziganshin writes:

...

array ((0,0),(65535,65535)) [((0,0),*** Exception: Error in array index

i think that it may be a bit too large for internal Int indicies:

Aren't you asking for a 4G element array here, so with a 32bit wraparound the array will be some multiple of 4GB, and be truncated (silently, of course) down to zero, as per Int(32) behavior. So in effect, you have a zero-length underlying array, but the array implementation still keeps track of the real indices and tries to print some contents. (Correct?) See also: http://hackage.haskell.org/trac/ghc/ticket/2120 Since array dereferencing are now checked against the underlying array instead of the real indices, you get this kind of inconsistency. It is greatly surprising to me that this has not been fixed. As long as 'unsafeAt' gives you the speed without the safety, I don't think the default dereferencing shouldn't sacrifice helpful error messages and predicability. -k -- If I haven't seen further, it is by standing in the footprints of giants

Am Mittwoch 24 Juni 2009 18:50:49 schrieb Jason Dusek:

2009/06/24 Ketil Malde :

...

Bulat Ziganshin writes:

...

...

    array ((0,0),(65535,65535)) [((0,0),*** Exception: Error in array index

i think that it may be a bit too large for internal Int indicies:

Aren't you asking for a 4G element array here, so with a 32bit wraparound the array will be some multiple of 4GB

It's a bit array. It'd be 512MiB.

...

So in effect, you have a zero-length underlying array, but the array implementation still keeps track of the real indices and tries to print some contents.  (Correct?)

I don't quite understand your reasoning here.

The 'length' of the array, as in 'number of elements' is calculated by multiplying the lengths in each dimension sz = rangeSize d1 * rangeSize d2 rangeSize (0,65535) = 2^16 (2^16)^2 = 2^32 2^32 :: Int = 0 on 32-bit systems I don't know if that's how it's implemented, but that's the reasoning leading to an array of size 0.

...

Since array dereferencing are now checked against the underlying array instead of the real indices, you get this kind of inconsistency.  It is greatly surprising to me that this has not been fixed.

As long as 'unsafeAt' gives you the speed without the safety, I don't think the default dereferencing shouldn't sacrifice helpful error messages and predicability.

This arrangement would make me LOL if it weren't my own project...

-- Jason Dusek

Hello Jason, Wednesday, June 24, 2009, 9:51:59 PM, you wrote:

It's too bad that indexes are `Int` instead of `Word` under

actually, it doesn't matter too much except for Bools. 2gb array is a way too much for most 32-bit systems, in particular, in windows 32-bit program cannot alloc memory block larger than 2gb -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Jason, Wednesday, June 24, 2009, 10:15:14 PM, you wrote:

...

particular, in windows 32-bit program cannot alloc memory block larger than 2gb

But on everything but Windows...

well, people never thought about such things until they really get into using 4gb RAM with 32-bit systems :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Jason Dusek wrote:

Why is `Int` used in so many places where it is semantically wrong? Not just here but also in list indexing... Indices/offsets can only be positive and I can't see any good reason to waste half the address space -- yet we encounter this problem over and over again.

I think history is the biggest culprit. Haskell98 doesn't ship with Nat and Natural types, so Int and Integer are used instead. And then the Word* types come around for bit bashing. Another big culprit is that this is one of the places where Haskell gives a nod to performance. Many Prelude functions like take, drop, and (!!) should accept any Natural. Failing that, they should accept Integer and do the right thing for negatives. But most of the time an Int is sufficient, and that's what they take; this increases CPU performance, but more importantly it increases programmer performance since they don't need to write All Those Conversion Functions(tm). Though programmer performance suffers when an unbounded type is actually required, or when negatives aren't handled correctly. The haskell' committee is considering adding a Nat or Natural type, so history may eventually be corrected. However, in order to deal with them in an, er, natural way the numeric typeclass hierarchy needs fixing. At the very least we'd want to separate (+) and (*) from (-), negate, abs, and signum so that we have a class for Nat and Natural that doesn't have partial functions. A safe version of (-) would be nice, though it's an open question whether x-(x+y) should be 0 or Nothing[1]. It's also unclear what should happen to fromInteger: do we have fromNatural be a subfunction of it, or do we desugar negative literals with negate and fromNatural and drop fromInteger entirely? [1] My vote would be for Nothing so that we don't loose the information about whether the two operands are equal. Though this has the unfortunate side effect of requiring more plumbing. We could always offer both variants, so that clients who use subtraction and equality comparisons together frequently can use the Maybe version and those who want the other mathematical function can use it instead. -- Live well, ~wren

Hello Claus, Thursday, June 25, 2009, 11:50:12 AM, you wrote:

PS. You could, of course, rebase your array indices to make use of the negatives, so the address space isn't wasted, just made difficult to use.

no, he can't - internally indexes are always counted from 0, so array cannot have more than 2g-1 elements i think the best he can do is to write his own ArraOfBool implementation with Word indices -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com