You're viewing a single thread.
It's a dynamically-sized list of objects of the same type stored contiguously in memory.
It's like a fancy list.
So is a wedding gift registry.
No, this is Patrick!
It's a dynamically-sized list of objects of the same type stored contiguously in memory.
dynamically-sized: The size of it can change as needed.
list: It stores multiple things together.
object: A bit of programmer defined data.
of the same type: all the objects in the list are defined the same way
stored contigiously in memory: if you think of memory as a bookshelf then all the objects on the list would be stored right next to each other on the bookshelf rather than spread across the bookshelf.
Dynamically sized but stored contiguously makes the systems performance engineer in me weep. If the lists get big, the kernel is going to do so much churn.
Contiguous storage is very fast in terms of iteration though often offsetting the cost of allocation
Modern CPUs are also extremely efficient at dealing with contiguous data structures. Branch prediction and caching get to shine on them.
Avoiding memory access or helping CPU access it all upfront switches physical domain of computation.
Which is why you should:
- Preallocate the vector if you can guesstimate the size
- Use a vector library that won't reallocate the entire vector on every single addition (like Rust, whose
Vecdoubles in size every time it runs out of space)
Memory is fairly cheap. Allocation time not so much.
matlab likes to pick the smallest available spot in memory to store a list, so for loops that increase the size of a matrix it's recommended to preallocate the space using a matrix full of zeros!
Is that churn or chum? (RN or M)
Churm
Many things like each other lined up in a row, and you can take some away or put more in.
It's how you want an array to work.
No, it's an n-tuple with certain algebraic properties.
This is such an understated but useful description in this context. It's also how I understood algebra for applied matrix computation.
I was just coming down from THC when I wrote this, so I'm extra jazzed you liked it. 😁
Edit: also, love the username.
Its the algebraic properties that are important, not all vectors are n-tuples, eg the set of polynomials of degree less than n.
You need a basis to coordinate a vector, you can work with vectors without doing that and just deal with the algebraic properties. The coordinate representation is dependent on the basis chosen and isn't fundamental to the vector. So calling them n-tuples isn't technically correct.
You can turn them into a set of coordinates if you have a basis, but the fact that you can do that is because of the algebraic properties so it's those properties which define what a vector is.
I think a better example to show how vectors don't necessarily need to be what people conceptualize as n-tuples would have been the real numbers. (Of course, these can be considered 1-tuples, but the same can be said of any arbitrary set element that is not itself a tuple with more entries.) A cooler example would have been R[x] (the ring of real-valued polynomials of a single variable) especially since an isomorphic ring using n-tuples would be a more cumbersome representation of the algebra.
So an ArrayList?
No. ArrayList is thread safe and implements the collections API. Vector doesn't. Though if you're using Java, there's almost no instance where you would want to use a Vector instead of ArrayList.
ArrayList isn't thread-safe, though...
Thread safe as in it raises an exception instead of breaking your list.
Only if one thread modifies it while another one is iterating over it, if two threads try to modify the list at once there isn't any kind of synchronization and it really could break your list.
For everything else, there's
Collections.synchronizedList(new ArrayList<>())