Am Mittwoch 24 Juni 2009 18:50:49 schrieb Jason Dusek: > 2009/06/24 Ketil Malde <[email protected]>: > > Bulat Ziganshin <[email protected]> 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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
