haskell / vector

An efficient implementation of Int-indexed arrays (both mutable and immutable), with a powerful loop optimisation framework .

The vector package

An efficient implementation of Int-indexed arrays (both mutable and immutable), with a powerful loop optimisation framework.

See vector on Hackage for more information.

vector's Issues

add Vector (a,b) -> (Vector a, Vector b) et al to Unboxed Vector and MVector

I'd like this for Unboxed Vectors and MVector

roughly

Unbox (a,b) =>Vector (a,b) -> (Vector a,Vector b)
Unbox (a,b) => (Vector a,Vector b) -> Vector (a,b)
Unbox (a,b) => (MVector s a,MVector s b) -> MVector s (a,b)
Unbox (a,b) =>MVector (a,b) -> (MVector a,MVector b)

should do this for (,)...(,,,) and Complex at least

Test-suite fails

 sum: [Failed]
*** Failed! Falsifiable (after 6 tests): 
fromList [-2.85685358419018,0.9288729747988657,33.51582034523111,18.079680881481565,-4.872267803281682]
(used seed -931204248)
  product: [Failed]
*** Failed! Falsifiable (after 6 tests): 
fromList [12.798552827341206,-4.694175866482457,-3.27888675478366]
(used seed -330711891)

http://hydra.nixos.org/build/15860082/nixlog/1/raw

The x86_64 box seems to have tested it fine.

Why not add index counterparts to monadic loops in Data.Vector.Unboxed? (imapM, ifoldrM etc.)

I've found that I need these functions often a lot in practice,. For Data.Vector there functionality can easily be achieved by using sequence or sequence_. However for Data.Vector.Unboxed there's currently no solution except either to implement the loops manually, which is very un-idiomatic, or to convert to Data.Vector. Is it possible that functions like imapM_, ifoldr etc. be provided, for Data.Vector.Unboxed at least?

Cannot catch uninitialized-element exception

• Tested with GHC-7.8.4 on vector 0.10.12.2 and 0.10.12.3

import qualified Data.Vector.Mutable as V
import Control.Exception
arr <- V.new 1000 :: IO (IOVector Int)

try $ V.read arr 0 :: IO (Either SomeException Int)
-- res throws Right *** Exception: Data.Vector.Mutable: uninitialised element

V.read arr 0 `catch` (\ (_ :: SomeException) -> return 3) :: IO Int
-- throws *** Exception: Data.Vector.Mutable: uninitialised element

Is this a bug? If not, how can I catch such an exception?

zipR?

It is my understanding that:

scanr f x0 $ zip xs ys

will not fuse, since unstream will not fuse with streamR. However, we can write an analogous zipRWith:

zipRWith f xs ys = unstreamR (Stream.zipWith f (streamR xs) (streamR ys))

Would this be useful?

Add insertion functions

I doubt these are needed too terribly often, but it might make sense to add them anyway—the usual Vector API doesn't seem to offer any way to implement them efficiently.

1. insertBeforeFirst :: (a -> Bool) -> a -> Vector a -> Vector a
2. insertAfterLast :: (a -> Bool) -> a -> Vector a -> Vector a
3. insertAt :: Int -> a -> Vector a -> Vector a

I've written two fusing versions of (essentially) insertBeforeFirst in an answer on StackOverflow; insertAt should be particularly simple.

add Immutable type family

type family Mutable is injective, but ghc doesn't know this. The inverse could be called

type family Immutable (m :: * -> * -> *) :: * -> *
type instance Immutable MVector = Vector -- for all the Storable, Unboxed etc.

If we instead had

unsafeFreeze :: (Immutable (Mutable v) ~ v, PrimMonad m, Vector v a)
  => Mutable v (PrimState m) a -> m (v a)

This function can then be written and the intermediate immutable vector type will not be ambiguous:

f v = convert `fmap` unsafeFreeze v

`new` (mutable unboxed vector) hands the user uninitialized memory

I don't think it should be the default behavior in a managed language to provide access to uninitialized memory. Aside from potential security issues, it also means that computations using mutable unboxed vectors in ST are nondeterministic. At the very least, this behavior should be clearly documented!

Naturally some applications need uninitialized arrays. I would suggest repurposing the name unsafeNew for this (the current unsafeNew is silly—I can't imagine any application for skipping the bounds check of an allocation), or using a new name like newUninitialized.

The same comments apply to grow and unsafeGrow.

For comparison, the array package has a newArray with an extra argument which is used as the initial value of every entry of the new mutable array, and a newArray_ which (for unboxed arrays) produces an uninitialized array when used in IO, and an array initialized to a fixed value (depending on the type) when used in ST.

Vector.Unboxed doesn't export constructors, but Unboxed.Mutable does

I think they should both be exported (or at least I dont see any good reason not to export them)

Add unfoldM for vectors

We have this for Stream - should we also have monadic unfolds for the various Vector types? My use case is SDL.pollEvent :: IO (Maybe Event), and I would like to poll for all events into a Vector Event. Unless I misunderstand something, using an unfold would be the most efficient way to do this.

Edit: I should note that I'd love to learn how to provide a pull request for this. If a maintainer agrees we should have this functionality, I will investigate how to make it so.

Add Minimal annotations to Vector typeclasses

the core type classes seem to lack the minimal annotations that ghc 7.8 now supports. Seems worth adding! I'll try to make some time to add that this weekend

checkIndex has an extra branch

checkIndex is defined like this:

checkIndex :: String -> Int -> Checks -> String -> Int -> Int -> a -> a
{-# INLINE checkIndex #-}
checkIndex file line kind loc i n x = check file line kind loc (checkIndex_msg i n) (i >= 0 && i<n) x

If I'm not very much mistaken, that short-circuit && leads to this producing an extra (useless) conditional jump (it does so in other, similar code). This can be avoided by using a different comparison operator:

checkIndex :: String -> Int -> Checks -> String -> Int -> Int -> a -> a
{-# INLINE checkIndex #-}
checkIndex file line kind loc i n x = check file line kind loc (checkIndex_msg i n) ((fromIntegral i::Word)<(fromIntegral n::Word)) x

unstreamM is not exported

We are trying to write a scanlM and scanrM for vector, but to do so it seems that we need unstreamM, which exists in Generic.hs but isn't exported. Is there a reason why it isn't?

add -wall to default build and have it be warning free, possibly HPC too

the bug in EnumFromTo specialization could have been caught by -wall, but currently theres no adherence to wall friendly discipline

https://gist.github.com/cartazio/11150584 lists a lot of the issues in the 0.10 branch, similar results apply in master

we should also probably add some program coverage checking to the test suite runs.

add generic traverse method, a la Data.Traversable

Unboxed vectors can't be Traversable due to the Unbox constraint on the element type, but it would be very useful if there were an analogous generic traverse method:

traverse :: (Applicative f, Vector v a, Vector v b) => (a -> f b) -> v a -> f (v b)

Even better would be if it were efficient, i.e., didn't just convert to and from lists (like the Traversable instance for boxed vectors does) -- but I'm not sure if this is even possible.

sequence comes close, except that it requires Monad m and Vector v (m a), which will typically not hold for unboxed vectors.

Semantics of grow/unsafeGrow

I'd like to clarify the semantics of grow and unsafeGrow, and hopefully update the documentation appropriately. From looking at the code for boxed, unboxed, and storable vectors, it seems that in all cases, grow/unsafeGrow will create a new mutable vector and leave the original mutable vector unchanged. The upshot would be that it would be valid to modify the original vector without affecting the new vector, and vice-versa. Two questions:

1. Have I misread the code, and in fact that's not the way the current three vector types work?
2. Do we want to codify this contract in the documentation as a promise for future behavior?

Broken GeneralizedNewtypeDeriving in ghc 7.8

Some of my code is broken with the newest version of ghc (7.8.2).

I'm using GeneralizedNewtypeDeriving to deriving instances of Data.Vector.Unbox using the following:

data VoxelPos     = VoxelPos
                    {-# UNPACK #-} !Int
                    {-# UNPACK #-} !Int
                    {-# UNPACK #-} !Int
                  deriving (Show, Eq, Ord)

newtype FacePos = FacePos VoxelPos deriving ( Eq, Hashable, NFData, G.Vector U.Vector, M.MVector U.MVector, U.Unbox)

where VoxelPos have manual rolled instances using (Int, Int, Int):

newtype instance U.MVector s VoxelPos = MV_VoxelPos (U.MVector s (Int, Int, Int))
newtype instance U.Vector    VoxelPos = V_VoxelPos  (U.Vector    (Int, Int, Int))
instance U.Unbox VoxelPos
instance M.MVector U.MVector VoxelPos where
  basicLength (MV_VoxelPos v) ...
  ...

and this was working with the previous versions of ghc. But after upgrading ghc, I get the following error:

Could not coerce from ‘U.MVector s (Int, Int, Int)’ to ‘U.MVector
                                                              s FacePos’
      because the second type argument of ‘U.MVector’ has role Nominal,
      but the arguments ‘(Int, Int, Int)’ and ‘FacePos’ differ
      arising from the coercion of the method ‘M.basicLength’ from type
                   ‘forall s. U.MVector s VoxelPos -> Int’ to type
                   ‘forall s. U.MVector s FacePos -> Int’
    Possible fix:
      use a standalone 'deriving instance' declaration,
        so you can specify the instance context yourself
    When deriving the instance for (M.MVector U.MVector FacePos)
which, I think, is because of addition of roles. I know that roles improves safety when using GeneralizedNewtypeDeriving which is, of course, really good!

What are the possible solutions to solve this?
It seems necessary to enforce the role of MVector, something like this:

type role MVector _ representational

Maintainance `vector-0.10.12` release (AMP fix)

It may be beneficial to have a vector-0.10.12 release fixing the AMP warnings, as that's all that's currently needed in order to be able to build vector == 0.10.* w/ GHC HEAD. This would make the transition smoother w/ GHC 7.10 and packages still relying on vector == 0.10.*

The following change is all that's currently needed:

diff --git a/Data/Vector/Fusion/Util.hs b/Data/Vector/Fusion/Util.hs
index c84abbb..1b6d5ed 100644
--- a/Data/Vector/Fusion/Util.hs
+++ b/Data/Vector/Fusion/Util.hs
@@ -22,6 +22,10 @@ newtype Id a = Id { unId :: a }
 instance Functor Id where
   fmap f (Id x) = Id (f x)

+instance Applicative Id where
+  pure = Id
+  Id f <*> Id x = Id (f x)
+
 instance Monad Id where
   return     = Id
   Id x >>= f = f x
@@ -32,6 +36,10 @@ data Box a = Box { unBox :: a }
 instance Functor Box where
   fmap f (Box x) = Box (f x)

+instance Applicative Box where
+  pure = Box
+  Box f <*> Box x = Box (f x)
+
 instance Monad Box where
   return      = Box
   Box x >>= f = f x

/cc @EdwardK

Failure in fusion leads to very inefficient code

With GHC 7.8.3, the following program is compiled into code that manipulates Streams at runtime.

module Foo where

import qualified Data.Vector.Unboxed as U

foo :: U.Vector Int -> U.Vector Int -> U.Vector Int
foo x y = U.map loop $ if U.null x then y else x

loop :: Int -> Int
loop x0 = go x0
  where
    go 0 = 0
    go x = 1 + go (x-1)
{-# INLINE loop #-}

For this problem to happen, loop doesn't have to be exactly this function, and it doesn't have to be recursive either. It just needs to be large enough that GHC doesn't automatically inline it.

A work-around is to replace the INLINE pragma for loop with INLINE[0].

vector 0.10.9 does not follow the PVP

The newly released 0.10.9 version of vector removes the Data.Vector.Fusion.Stream module (and perhaps there are some other breaking changes), without bumping the major version number. This will cause massive breakage, e.g. lens-3.9.1 no longer builds (see ekmett/lens#336).

This is fundamental enough that probably the right thing to do is to delete this from Hackage, or perhaps use the new blacklisting feature of Hackage 2 once the switchover is complete.

change in show instance in vector 0.10 vs 0.11

in vector 0.10 and previous major versions

show was

-- | Generic definition of 'Prelude.showsPrec'
showsPrec :: (Vector v a, Show a) => Int -> v a -> ShowS
{-# INLINE showsPrec #-}
showsPrec p v = showParen (p > 10) $ showString "fromList " . shows (toList v)

its now

-- | Generic definition of 'Prelude.showsPrec'
showsPrec :: (Vector v a, Show a) => Int -> v a -> ShowS
{-# INLINE showsPrec #-}
showsPrec _ = shows . toList

granted, this makes the associated read instance a bit easier, but was this a deliberate change or something that no one noticed till now?

(i noticed it just now because it broke some tests in my hblas test suite)

@dolio @hvr @ekmett

should mutable vectors provide Data,Generic and Show instances?

Just noticed that we dont provide those, but I dont see any reason why we couldnt. At least Show!

thoughts?

Add fmap/coerce rule(s)

GHC.Base has a rule to rewrite map coerce to coerce. This rule is valid and beneficial for any valid Functor instance, and should be added for the vector types.

Is it possible to allow returning a different Vector type?

Currently the functions in Data.Vector.Generic always returns the same type of vector as the input. Is it possible to change it to return vectors of a different type? E.g., map over a Storable vector, returning a Vector.Vector, since the result of the map isn't Storable.

In other words, change the signature of

map :: (Vector v a, Vector v b) => (a -> b) -> v a -> v b

to

map :: (Vector vi a, Vector vo b) => (a -> b) -> vi a -> vo b

test suite doesnt type check (at least in 7.8)

I also dont think anyones tried to run it in a while....

i'll cook up a strawman pull request that fixes it.

integer overflow when creating unboxed vectors

With mutable vectors, you can read and write arbitrary memory with supposedly safe operations:

import qualified Data.Vector.Unboxed.Mutable as UM

main = do
  v <- UM.new (2^61 + 5) :: IO (UM.IOVector Double) -- chosen so that sizeof(double) * (2^61 + 5) will overflow
  UM.write v (2^59) 0 -- segfault

The immutable vector version is probably not exploitable for doing anything but causing a segmentation fault, since it writes to the newly-allocated buffer in order right away. But still, it should report an out-of-memory condition instead (as it does if you replace the size with something less than 2^61).

import qualified Data.Vector.Unboxed as U

main = (U.replicate (2^61 + 5) 0 :: U.Vector Double) `seq` return () -- segfault

integer overflow when concatenating vectors

With -O, fusion kicks in and the computed total length of the final result is 0; then we start writing to it...

{-# OPTIONS_GHC -O #-}

import qualified Data.Vector as V

main = (V.replicate (2^62) 0 V.++ V.replicate (2^62) 0 V.++
        V.replicate (2^62) 0 V.++ V.replicate (2^62) 0 :: V.Vector Int)
       `seq` return () -- segfault

The element type is immaterial.

Alignment isn't respected in Data.Vector.Storable.

I have a type where the alignment of the type is greater than 8 bytes. When I create a vector, using fromList for example, I find that the alignment isn't respected.

I'm using version 0.10.12.2.

Unboxed can be slower than Storable?

I guess this this isn't as much of a bug as a question: aren't Storable vectors supposed to be slower than Unboxed ones? But on smaller vectors Unboxed seems to be faster. Here is testing dot product on various sized vectors of different types.

   benchmarking dot prod (3)/List
   time                 295.8 ns   (294.3 ns .. 297.0 ns)
                        0.998 R²   (0.996 R² .. 0.999 R²)
   mean                 297.0 ns   (295.4 ns .. 299.2 ns)
   std dev              6.471 ns   (5.110 ns .. 8.581 ns)
   variance introduced by outliers: 29% (moderately inflated)

   benchmarking dot prod (3)/Vector
   time                 28.65 ns   (28.34 ns .. 29.02 ns)
                        0.999 R²   (0.999 R² .. 0.999 R²)
   mean                 28.88 ns   (28.64 ns .. 29.20 ns)
   std dev              922.6 ps   (786.9 ps .. 1.116 ns)
   variance introduced by outliers: 52% (severely inflated)

   benchmarking dot prod (3)/Unboxed
   time                 21.98 ns   (21.65 ns .. 22.38 ns)
                        0.998 R²   (0.997 R² .. 0.999 R²)
   mean                 22.15 ns   (21.91 ns .. 22.49 ns)
   std dev              1.024 ns   (829.9 ps .. 1.481 ns)
   variance introduced by outliers: 70% (severely inflated)

   benchmarking dot prod (3)/Storable
   time                 19.15 ns   (18.57 ns .. 19.86 ns)
                        0.994 R²   (0.991 R² .. 0.999 R²)
   mean                 18.74 ns   (18.45 ns .. 19.21 ns)
   std dev              1.210 ns   (812.3 ps .. 1.722 ns)
   variance introduced by outliers: 82% (severely inflated)


   benchmarking dot prod (3000)/List
   time                 208.7 μs   (208.2 μs .. 209.5 μs)
                        1.000 R²   (0.999 R² .. 1.000 R²)
   mean                 212.6 μs   (211.0 μs .. 214.6 μs)
   std dev              5.999 μs   (4.316 μs .. 8.052 μs)
   variance introduced by outliers: 23% (moderately inflated)

   benchmarking dot prod (3000)/Vector
   time                 8.013 μs   (7.984 μs .. 8.045 μs)
                        1.000 R²   (1.000 R² .. 1.000 R²)
   mean                 8.037 μs   (8.010 μs .. 8.071 μs)
   std dev              106.7 ns   (84.60 ns .. 138.4 ns)
   variance introduced by outliers: 10% (moderately inflated)

   benchmarking dot prod (3000)/Unboxed
   time                 2.186 μs   (2.163 μs .. 2.214 μs)
                        0.999 R²   (0.999 R² .. 1.000 R²)
   mean                 2.175 μs   (2.167 μs .. 2.188 μs)
   std dev              35.22 ns   (23.59 ns .. 54.02 ns)
   variance introduced by outliers: 16% (moderately inflated)

   benchmarking dot prod (3000)/Storable
   time                 2.261 μs   (2.208 μs .. 2.307 μs)
                        0.998 R²   (0.997 R² .. 1.000 R²)
   mean                 2.215 μs   (2.201 μs .. 2.234 μs)
   std dev              56.60 ns   (33.79 ns .. 86.74 ns)
   variance introduced by outliers: 32% (moderately inflated)

https://gist.github.com/yongqli/c5de8d2d6a4f0ed3523a

latest deepseq and GHC HEAD's vector are not compatible

HC [stage 2] libraries/vector/dist-install/build/Data/Vector/Storable/Mutable.o

libraries/vector/Data/Vector/Primitive/Mutable.hs:78:10:
    No instance for (GHC.Generics.Generic (MVector s a))
      arising from a use of ‘Control.DeepSeq.$gdmrnf’
    In the expression: Control.DeepSeq.$gdmrnf
    In an equation for ‘rnf’: rnf = Control.DeepSeq.$gdmrnf
    In the instance declaration for ‘NFData (MVector s a)’
make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Primitive/Mutable.o] Error 1

This happened with GHC HEAD just now...

Can we please have a new release?

It seems that my commit (fa96a33) from April 7, 2014 is still not live. Could we have a new release please?

Also, could the releases please be tagged in the git repo so we know which code has been released.

Simulating mapAccumR is slow

We've been simulating mapAccumR with something like (not tested):

mapAccumR' f acc xs =
  map snd $ scanr' (\(acc, y) -> f acc) (acc, undefined) xs

In testing this is 6x slower for Storable vectors vs Unboxed vectors -- it seems that the intermediate vector is not optimized away. I'm guessing that with Unboxed, the vector representing the first part of the tuple is simply dropped, while for Storable it has to copy the first part of the intermediate list.

Any idea how to make it faster?

replace macrollogy in test suite with constraint kinds

https://github.com/haskell/vector/blob/master/tests/Tests/Vector.hs#L27-L34

#define COMMON_CONTEXT(a, v) \
VANILLA_CONTEXT(a, v), VECTOR_CONTEXT(a, v)
#define VANILLA_CONTEXT(a, v) \
Eq a, Show a, Arbitrary a, CoArbitrary a, TestData a, Model a ~ a, EqTest a ~ Property
#define VECTOR_CONTEXT(a, v) \
Eq (v a), Show (v a), Arbitrary (v a), CoArbitrary (v a), TestData (v a), Model (v a) ~ [a], EqTest (v a) ~ Property, V.Vector v a

vile stuff, lets kill it!

figure out allowing mutable vectors to handle monad stacks

possibly by eg a breaking change to the api for 0.11 (or more likely 0.12) that either
a) uses Monad-ST or
b) rethinks PrmMonad and the primitive package

I think this should be on the table for 0.12, though its something that should be contemplated for 0.11

How to make Rewrite Rules Fire

After trying a simple test, I noticed some strange performance results from stylistic changes to the code.

For example,

{-# LANGUAGE FlexibleContexts #-}

import Control.DeepSeq
import Data.Int
import qualified Data.Vector.Unboxed as U

{-# INLINE f #-}
f :: U.Vector Int64 -> U.Vector Int64 -> U.Vector Int64
f = U.zipWith (+) -- version 1
--f x = U.zipWith (+) x -- version 2
--f x = (U.zipWith (+) x) . id -- version 3
--f x y = U.zipWith (+) x y -- version 4

main = do
  let iters = 100
      dim = 221184
      y = U.replicate dim 0 :: U.Vector Int64
  let ans = iterate (f y) y !! iters
  putStr $ (show $ U.foldl1' (+) ans)

Versions 1 and 2 run in 1.6 seconds, while versions 3 and 4 run in 0.09 seconds (with vector-0.10.9.1 and GHC 7.6.2). According to this answer, this problem is because the first two versions use Generic vector code rather than low-level imperative code.

Is there anything that a user can do to ensure the best vector code is used without more or less guessing at a style that will make the rule fire (I'm thinking pragmas, compiler flags, any other hints, intuition about why style "x" is a bad choice, etc)?

Not in scope: type constructor or class `Applicative'

As seen on any of these jobs: https://travis-ci.org/yi-editor/yi/builds/37713731

Vector analog of peekArray

In Foreign.Marshal.Array there exists the function peekArray :: Storable a => Int -> Ptr a -> IO [a]

Would it be sensible to add peekVector :: Storable a => Int -> Ptr a -> IO (Vector a) to this package?

Support for Safe Haskell

Hello,

would it be possible to add support for Safe Haskell? I imagine that a lot of the library is Safe, or at least Trustworthy, but none of the modules appear to be marked as such.

-Iavor

Don't include fromList in Show instance

I think we shouldn't include fromList in the output of the Show instance and instead mirror the output for lists. Reasons:

• With the new OverloadedLists extension the list literal syntax is valid for creating vectors.
• The fromList part exists to allow programmers to copy the output back into the REPL to create a new vector. This doesn't actually work as the modules are typically imported qualified.
• The fromList part is noise that makes the output harder to read e.g. when two vectors are nested.

Like constructN, but with map

I'm trying to build a new vector with constructN, but there isn't a easy way to take an input vector. I would like a function like constructMap, that takes a function and an input vector. The function is given access to the parts of the output vector already built and an element from the input vector. Is there an easy and efficient to way to do this that I'm missing?

Does not build on profiled GHC 7.8.4

Just got GHC 7.8.4 with profiling. Removed ~/.cabal and ~/.ghc, then only cabal update and cabal install.

$ cabal --version
cabal-install version 1.22.0.0
using version 1.22.0.0 of the Cabal library

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4

There is no difference b/w usual install or installing inside a sandbox, it fails with the following error.

$ mkdir tmp-vectors-7.8.4-2
$ cd tmp-vectors-7.8.4-2
$ cabal sandbox init
Writing a default package environment file to
/home/kgadek/tmp-vectors-7.8.4-2/cabal.sandbox.config
Creating a new sandbox at /home/kgadek/tmp-vectors-7.8.4-2/.cabal-sandbox

$ cabal update
Downloading the latest package list from hackage.haskell.org
cabal install vector

$ cabal install vector
Resolving dependencies...
Downloading primitive-0.5.4.0...
Configuring primitive-0.5.4.0...
Building primitive-0.5.4.0...
Preprocessing library primitive-0.5.4.0...
[ 1 of 10] Compiling Data.Primitive.Internal.Compat ( Data/Primitive/Internal/Compat.hs, dist/dist-sandbox-a39fb984/build/Data/Primitive/Internal/Compat.o )
[ 2 of 10] Compiling Data.Primitive.MachDeps ( Data/Primitive/MachDeps.hs, dist/dist-sandbox-a39fb984/build/Data/Primitive/MachDeps.o )
[ 3 of 10] Compiling Data.Primitive.Internal.Operations ( Data/Primitive/Internal/Operations.hs, dist/dist-sandbox-a39fb984/build/Data/Primitive/Internal/Operations.o )
[ 4 of 10] Compiling Control.Monad.Primitive ( Control/Monad/Primitive.hs, dist/dist-sandbox-a39fb984/build/Control/Monad/Primitive.o )
[ 5 of 10] Compiling Data.Primitive.Types ( Data/Primitive/Types.hs, dist/dist-sandbox-a39fb984/build/Data/Primitive/Types.o )
[ 6 of 10] Compiling Data.Primitive.Array ( Data/Primitive/Array.hs, dist/dist-sandbox-a39fb984/build/Data/Primitive/Array.o )

Data/Primitive/Array.hs:32:1: Warning:
    The import of ‘Control.Monad.ST’ is redundant
      except perhaps to import instances from ‘Control.Monad.ST’
    To import instances alone, use: import Control.Monad.ST()
[ 7 of 10] Compiling Data.Primitive.ByteArray ( Data/Primitive/ByteArray.hs, dist/dist-sandbox-a39fb984/build/Data/Primitive/ByteArray.o )
[ 8 of 10] Compiling Data.Primitive.Addr ( Data/Primitive/Addr.hs, dist/dist-sandbox-a39fb984/build/Data/Primitive/Addr.o )
[ 9 of 10] Compiling Data.Primitive   ( Data/Primitive.hs, dist/dist-sandbox-a39fb984/build/Data/Primitive.o )
[10 of 10] Compiling Data.Primitive.MutVar ( Data/Primitive/MutVar.hs, dist/dist-sandbox-a39fb984/build/Data/Primitive/MutVar.o )
In-place registering primitive-0.5.4.0...
Creating package registration file: /tmp/pkgConf-primitive-0.5.415608.0
Installing library in
/home/kgadek/tmp-vectors-7.8.4-2/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/primitive-0.5.4.0
Registering primitive-0.5.4.0...
Installed primitive-0.5.4.0
Downloading vector-0.10.12.2...
Configuring vector-0.10.12.2...
Building vector-0.10.12.2...
Preprocessing library vector-0.10.12.2...
[ 1 of 19] Compiling Data.Vector.Storable.Internal ( Data/Vector/Storable/Internal.hs, dist/dist-sandbox-a39fb984/build/Data/Vector/Storable/Internal.o )
[ 2 of 19] Compiling Data.Vector.Fusion.Util ( Data/Vector/Fusion/Util.hs, dist/dist-sandbox-a39fb984/build/Data/Vector/Fusion/Util.o )
[ 3 of 19] Compiling Data.Vector.Fusion.Stream.Size ( Data/Vector/Fusion/Stream/Size.hs, dist/dist-sandbox-a39fb984/build/Data/Vector/Fusion/Stream/Size.o )

Data/Vector/Fusion/Stream/Size.hs:25:10: Warning:
    No explicit implementation for
      ‘*’, ‘abs’, and ‘signum’
    In the instance declaration for ‘Num Size’
[ 4 of 19] Compiling Data.Vector.Internal.Check ( Data/Vector/Internal/Check.hs, dist/dist-sandbox-a39fb984/build/Data/Vector/Internal/Check.o )
[ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/dist-sandbox-a39fb984/build/Data/Vector/Fusion/Stream/Monadic.o )
ghc: You can't call hscCompileCoreExpr in a profiled compiler
Failed to install vector-0.10.12.2
cabal: Error: some packages failed to install:
vector-0.10.12.2 failed during the building phase. The exception was:
ExitFailure 1

ghc-pkg outside of sandbox:

/home/kgadek/.ghc-7.8.4/lib/ghc-7.8.4/package.conf.d:
    Cabal-1.18.1.5
    array-0.5.0.0
    base-4.7.0.2
    bin-package-db-0.0.0.0
    binary-0.7.1.0
    rts-1.0
    bytestring-0.10.4.0
    containers-0.5.5.1
    deepseq-1.3.0.2
    directory-1.2.1.0
    filepath-1.3.0.2
    (ghc-7.8.4)
    ghc-prim-0.3.1.0
    haskeline-0.7.1.2
    (haskell2010-1.1.2.0)
    (haskell98-2.0.0.3)
    hoopl-3.10.0.1
    hpc-0.6.0.1
    integer-gmp-0.5.1.0
    old-locale-1.0.0.6
    old-time-1.1.0.2
    pretty-1.1.1.1
    process-1.2.0.0
    template-haskell-2.9.0.0
    terminfo-0.4.0.0
    time-1.4.2
    transformers-0.3.0.0
    unix-2.7.0.1
    xhtml-3000.2.1

/home/kgadek/.ghc/x86_64-linux-7.8.4/package.conf.d:
    Cabal-1.22.0.0
    HTTP-4000.2.19
    mtl-2.2.1
    network-2.6.0.2
    network-uri-2.6.0.1
    parsec-3.1.8
    primitive-0.5.4.0
    random-1.1
    stm-2.4.4
    text-1.2.0.4
    transformers-0.4.2.0
    zlib-0.5.4.2

quickcheck propertiy failure for primitive Data.Vector.Primitive.Vector (Double): enumFromTo

Data.Vector.Primitive.Vector (Double):
enumFromTo: [Failed]
*** Failed! Falsifiable (after 14 tests and 2 shrinks):
0.0
-0.30329992720198007
(used seed 2780156450814293372)

Add OverloadedLists support

The next GHC version will ship with OverloadedLists, which will make creating vector literals much nicer.

Issue with blaze-html

I'm not sure if its a Vector issue or a blaze-html one, but there is something weird.
Basically I'm trying to convert a vector to html.
If I use Vector.mapM_ or Vector.forM_ it compiles but blows up , if I convert the vector to a list and use mapM_, everything is fine.
I assume that Vector.forM_ should be functionally equivalent to forM_.V.toList but it's not (therefore I think it's a Data.Vector problem ;-))

Here is a way to reproduce problem:

 {-# LANGUAGE OverloadedStrings #-}
  module Main where

  import Control.Monad (forM_)
  import qualified Data.ByteString.Lazy as BL
  import qualified Data.Vector as V

  import qualified Text.Blaze.Html5 as H
  import qualified Text.Blaze.Html.Renderer.String as R


  v :: V.Vector Int
  v = V.fromList [1..10]

  html :: H.Html
  html = V.forM_ v H.toHtml

  vForM_ = forM_ . V.toList

  html' :: H.Html
  html' = vForM_ v H.toHtml

 main = do
     putStrLn  $     R.renderHtml html'
     putStrLn "^ ok"
     putStr  $     R.renderHtml html
     putStrLn "^ ok"

add more helper utilities for the .Mutable modules in Vector

the .Mutable modules are currently a bit impoverished. could use some more utilities

Type errors when building with GHC 7.9.x

FYI, the GHC 7.9.x snapshot fails to compile Vector because of several type errors. A complete build log is available at http://hydra.cryp.to/build/52039/nixlog/1/raw.

Documentation for contructN and constructrN

Hello, that's just a minor point and easily corrected but the documentation for constructN in Data/Vector.hs say :

-- > constructN 3 f = let a = f <> ; b = f <a> ; c = f <a,b> in f <a,b,c>

since f result is an element, I think you meant :

-- > constructN 3 f = let a = f <> ; b = f <a> ; c = f <a,b> in <a,b,c>

Same deal with constructrN.

V.enumFromTo is only fast for Int, not Word32

In https://groups.google.com/d/msg/haskell-cafe/Ms4sKZBwTtw/55CFywSytBQJ I benchmark different alternatives to forM_ [1..n] to each other.

When looking at V.forM_ (V.enumFromTo 1 n), we noticed that this gets only optimised away to a fast loop when using Vector Int. With Vector Word32, it's 5 times slower.

What @JohnLato thinks about this:

Ahh, you made me look at the core again. I think this is related to your observation about V.enumFromTo being the same as V.fromList. With Word32 the generated core shows that this goes via a list representation instead of a nice loop. Which makes me suspect there's some RULE that applies to Stream.enumFromTo that is firing in the first case but not the second. And if I build both versions with -ddump-rule-firings, indeed I see that the Int version has

Rule fired: enumFromTo [Stream]

With nothing comparable for the Word32 version. I'd imagine if you grep for that in the Vector sources, you'd find something interesting.

It would be great if somebody familiar with the vector library could check out whether there are indeed RULES missing for types like Word32.

Tackling the test suite todo list.

I would happily implement everything on the todo list from the test suite if someone thinks they can find the time to review and merge the code once I'm done and everything is ok. So, if you think it's worthwhile, is someone willing to review my code if I go ahead with this ?

last doesn't always fuse?

It seems that last doesn't completely fuse away?

import Linear
benchLast :: Int -> M44 Double
benchLast n =
  G.last $ VU.replicate n (pure 0)

benchLast2 :: Int -> M44 Double
benchLast2 n =
  (G.! (n-1)) $ VU.replicate n (pure 0)

With n = 2000000, I see
benchmarking benchmarks/last
time 3.345 ms (3.321 ms .. 3.369 ms)
benchmarking benchmarks/last2
time 482.2 μs (475.0 μs .. 494.2 μs)

I had to use M44 from Linear to make the difference more noticeable.