Comments (8)
I think this is correct. Having looked at the storable and unboxed vectors couple of weeks ago, this is what I read too. If the documentation is improved as a result, it's probably a good idea to explicitly document that the old vector is copied to the new vector, and this is not a 'realloc' type operation. I think I'm not the only one to think grow = realloc.
from vector.
I think the intended semantics are that it may do a realloc, but not guaranteed to, and all the current implementations do the simpler copying semantics because for on heap allocations the cost should be roughly the same.
from vector.
@cartazio If I'm reading you correctly, the correct docs would be:
Even though right now,
grow
will always leave the original mutable vector intact and unmodified, this is behavior that may change in the future, and should not be relied upon. If you need such functionality, you should instead create a new vector and then copy the data from the old vector to the new one.
from vector.
i'm not sure if thats quite true. I'll try to take a look with a few folks at hac_bos this weekend. I believe the motivation for the *grow operations lies in Stream fusion in the case when the stream has unknown size, and any choice in semantics should reflect that.
from vector.
Another perspective: the name grow
is misleading. Mutable vectors are implemented using a bare MutableArray instead of a mutable reference thereof. So they couldn't grow in-place in case realloc needed to move.
https://hackage.haskell.org/package/vector-0.11.0.0/docs/src/Data-Vector-Mutable.html#MVector
To clarify: currently the interface is grow :: Vector -> Int -> IO Vector
but much more sensible would be grow :: Vector -> Int -> IO ()
(types simplified).
There are probably good reasons (which I don't understand) for not using a mutable reference. But since in-place grow can't be supported that way, another suggestion would be to just remove the interface altogether and make another data type (C++ std::vector
style) which can support growing.
from vector.
I don't really know the original intention of grow.
However, there is a notion of growing that does not mutate the original vector, but also does not mean that the new vector can be used without affecting the old one (perhaps only in the 'unsafe' case).
It is the opposite of slicing. When you slice a mutable vector, you just adjust the bounds, but keep the same underlying array, so writes to one can affect (pieces of) the other. In principle, a vector type could over-allocate the underlying mutable array, and allow growing by just adjusting the bounds. Nothing we have does this, but it could be done, and it has the signature of grow.
from vector.
Edit: I just realized the below assumes an implementation which realloc
s in-place.
I'm quite late to the game, but there is at least one other reason why grow
returns a new MVector
reference: It's because the old reference doesn't contain the updated length!
#!/usr/bin/env stack
-- stack --resolver lts-9.6 script --package vector
import Data.Vector.Mutable (IOVector)
import qualified Data.Vector.Mutable as Vector
main = do
v1 <- Vector.new 1
print (Vector.length v1)
v2 <- Vector.grow v1 1
print (Vector.length v1)
print (Vector.length v2)
In other words, this program prints
$ stack grow.hs
1
1
2
That's because instead of modeling the start and end indices in MVector
as mutable variables, too, they are actually regurlar, unboxed Int
s. I suspect the reason for this is that Vector.length
and Vector.slice
and by extension Vector.tail
, etc. should remain pure. Also from the plain perspective of efficiency, unboxed Int
s are probably preferrable to mutable references to boxed Int
s. So, if there were mutable struct fields (there was some HIW talk about that), we should seriously consider using them here.
There's another perspective to this: We can't allow a shrink
operation or negative arguments to grow
, as that would invalidate all old references which still store the old length.
TLDR; Even if the implementation used realloc
, we still need to return a new reference from grow
and make sure that we don't use the old one any more.
from vector.
Anyone involved in this issue cares to review a PR that clarifies those grow
semantics, feel free to comment: #360
It only took 6 and a half years to get to and 30 min to implement 😃
from vector.
Related Issues (20)
- High level documentation? HOT 1
- overlaps for Data.Vector.Mutable behaves oddly for empty vectors HOT 2
- Performance issues with `foldl'` and large tuples HOT 3
- Add a variant unfoldrExactN, returning the resulting generator HOT 3
- Vector tests take more than 4GB memory to build HOT 3
- `Data.Vector.Fusion.Bundle.Size.Size` fields are not strict HOT 1
- Why is `Data.Vector.Generic.New.New` not a newtype? HOT 2
- Question: Is there a reason why `Unbox a => Maybe (Unbox a)` doesn't exist? HOT 1
- Is `vector` susceptible to the same fusion problems as `text`? HOT 2
- Improve compilation time HOT 3
- Split generic tests into separate package HOT 5
- Tests fail when built against QuickCheck-2.14.3 HOT 2
- New version vector 0.14? HOT 11
- Support `primitive-0.9` HOT 1
- Semantics and implementation of move for SoA vectors
- API using Applicative (traverse et.al.)
- Add total counterparts to partial functions, such as `head`. HOT 25
- catMaybes HOT 2
- Add strict boxed vectors HOT 12
- Data.Vector.Generic.New.unstream (and others) can't be specialized HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vector.