why no mutable List or immutable Array?

Russ,There is scala.collection.mutable.LinkedList and scala.collection.mutable.DoubleLinkedList.  LinkedList is a mutable single-linked list, just like List is an immutable single-linked list.
Some mutable collections, such as DoubleLinkedList, don't make sense in an immutable form.  Likewise, I think, with immutable collections such as Vector (which is much more complex than an array).
One of my common practices is when I want to return a collection that can't be mutated, but I want to mutable collection for building it and don't want to have to create a copy, I return it using the scala.collection.XXX type instead of a scala.collection.immutable and scala.collection.mutable.  That way the returned value can't be mutated by whomever receives it.  This isn't ideal, but it seems like a reasonable compromise.  I don't know what other people think of this, but it seems to work for me.
Another trick that's handy when dealing with names is to alias the structure on import.  So you can write:import scala.collection.immutable.{ Vector => SVector }
and then refer to it as SVector instead of Vector, or
import scala.collection.{ immutable => im }
and then refer to it as im.Vector.
-Erik

On Sun, Oct 24, 2010 at 7:07 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

The Scala collections are impressive, but I am still a bit confused about why they are the way they are. I'm probably naive on this topic, so please bear with me.

So far, I've used List, Set, Map, Vector, Array, and a few other collection classes. I've noticed that Set and Map have both mutable and immutable versions. In fact, I just verified that the mutable Set has a method called toSet to convert to a mutable Set. Ditto for Map.

I am wondering why the other collection classes are not similar, particularly List and Array. When I want to build up a List, I can use a "var List" or a "val Listbuffer," then convert to a List. Why not have a mutable List that can be converted to an immutable List? Ditto for Array. It seems to me that a Vector is more or less an immutable Array.

Why do I care? Well, one reason is that I appreciate consistency. The other reason is that I wrote my own Vector class, and I don't appreciate the name clash. As an aerospace engineer, the word "vector" has a well-established meaning for me: a physical entity with a direction and a magnitude, as in velocity, force, etc.  I wrote my own Matrix and Vector classes, and I face a minor dilemma. I figured I would not need the Scala Vector class, so I decided to call my class "Vector." Now I realize that I need the Scala Vector class, so I need to either rename my Vector class or rename the Scala Vector class (or use fuller names such as immutable.Vector, which I don't usually like to do). I am leaning toward renaming my class to "Vectr" or something like that to avoid confusion, but the name "Vectr" is nowhere as aesthetically pleasing as "Vector". If Scala had an immutable Array, I wouldn't have to make this compromise.

Russ P.

--
http://RussP.us

--
http://erikengbrecht.blogspot.com/

Thanks, Eric. More below.

On Sun, Oct 24, 2010 at 4:18 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com> wrote:

Russ,There is scala.collection.mutable.LinkedList and scala.collection.mutable.DoubleLinkedList.  LinkedList is a mutable single-linked list, just like List is an immutable single-linked list.

What then is the difference between LinkedList and ListBuffer, and how should one decide which to use in a particular situation? Also, why is LinkedList (or ListBuffer) not just called mutable.List (like mutable.Set)?

 

Some mutable collections, such as DoubleLinkedList, don't make sense in an immutable form.  Likewise, I think, with immutable collections such as Vector (which is much more complex than an array).

Vector may have a more complex *implementation* than Array, but if I am not mistaken, it's main feature beyond List is efficient random indexing. I still don't understand why Scala shouldn't have an immutable Array type with efficient random indexing.

 

One of my common practices is when I want to return a collection that can't be mutated, but I want to mutable collection for building it and don't want to have to create a copy, I return it using the scala.collection.XXX type instead of a scala.collection.immutable and scala.collection.mutable.  That way the returned value can't be mutated by whomever receives it.  This isn't ideal, but it seems like a reasonable compromise.  I don't know what other people think of this, but it seems to work for me.

I'm not sure I understand what you mean here. Would you mind giving an example?

 

Another trick that's handy when dealing with names is to alias the structure on import.  So you can write:import scala.collection.immutable.{ Vector => SVector }

Yeah, I did this sort of thing, but it's not ideal. Some will argue that people who know Scala will know what a Scala Vector is, and good code should be consistent with that convention. If I define my own class called "Vector", it could cause confusion, and the name clash will make it less likely to be adopted by others. I'm sympathetic to that argument, but I am also very reluctant to give up the name "Vector" for my own class. Decisions, decisions!

Russ P.

--
http://RussP.us

It your intent to efficiently build an immutable List, then ListBuffer is probably your best bet.  If you want a linked list structure that you can mutate at well, then LinkedList is probably your best bet.

re: VectorI'm not overly familiar with the implementation of Vector, but I believe it is more a wide tree-like structure as opposed to a simple array, so indexing into it is log_32(n) (IIRC the tree is 32 elements wide).  I bet Rex Kerr has a benchmark lying around where Array completely smashes Vector.  Efficiency tends to be in the eye of the beholder (and highly dependent on what you're doing).
re: returning scala.collection.XXX
My most common example is returning an Array but typing it as scala.collection.Seq (or IndexSeq).  In this case I probably know the exact size, so I just allocate an Array and populate it, but then return it as Seq.  The interface (and implementation) of scala.collection.Seq is essentially identical to scala.immutable.Seq.  So the returned scala.collection.Seq is essentially immutable, unless someone decides to cast it down to its mutable underpinnings.  I also tend to write my algorithms to scala.collection.* classes instead of scala.collection.immutable classes, because the algorithms don't care so long as no one is mutating the collections out from under them.
re: VectorIs your own class a vector in the numerical/mathematical sense (meaning you're doing vector math on it, and efficiency is key) or is it more just a special sequential data structure?
I personally wish people would stop naming general-purpose sequences vectors.  It's kind of like how most "actor" implementations don't actually implement the actor model, only much less arcane.  So if it's a real vector, keep it as Vector.  If not - rename it!
-Erik

On Sun, Oct 24, 2010 at 9:11 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Thanks, Eric. More below.

On Sun, Oct 24, 2010 at 4:18 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com> wrote:

Russ,There is scala.collection.mutable.LinkedList and scala.collection.mutable.DoubleLinkedList.  LinkedList is a mutable single-linked list, just like List is an immutable single-linked list.

What then is the difference between LinkedList and ListBuffer, and how should one decide which to use in a particular situation? Also, why is LinkedList (or ListBuffer) not just called mutable.List (like mutable.Set)?

 

Some mutable collections, such as DoubleLinkedList, don't make sense in an immutable form.  Likewise, I think, with immutable collections such as Vector (which is much more complex than an array).

Vector may have a more complex *implementation* than Array, but if I am not mistaken, it's main feature beyond List is efficient random indexing. I still don't understand why Scala shouldn't have an immutable Array type with efficient random indexing.

 

One of my common practices is when I want to return a collection that can't be mutated, but I want to mutable collection for building it and don't want to have to create a copy, I return it using the scala.collection.XXX type instead of a scala.collection.immutable and scala.collection.mutable.  That way the returned value can't be mutated by whomever receives it.  This isn't ideal, but it seems like a reasonable compromise.  I don't know what other people think of this, but it seems to work for me.

I'm not sure I understand what you mean here. Would you mind giving an example?

 

Another trick that's handy when dealing with names is to alias the structure on import.  So you can write:import scala.collection.immutable.{ Vector => SVector }

Yeah, I did this sort of thing, but it's not ideal. Some will argue that people who know Scala will know what a Scala Vector is, and good code should be consistent with that convention. If I define my own class called "Vector", it could cause confusion, and the name clash will make it less likely to be adopted by others. I'm sympathetic to that argument, but I am also very reluctant to give up the name "Vector" for my own class. Decisions, decisions!

Russ P.

--
http://RussP.us

--
http://erikengbrecht.blogspot.com/

On 25/10/2010, at 12:11 PM, Russ Paielli wrote:

> Yeah, I did this sort of thing, but it's not ideal. Some will argue that people who know Scala will know what a Scala Vector is, and good code should be consistent with that convention. If I define my own class called "Vector", it could cause confusion, and the name clash will make it less likely to be adopted by others. I'm sympathetic to that argument, but I am also very reluctant to give up the name "Vector" for my own class. Decisions, decisions!

If you look at libraries like Scalala (a scala linear algebra library:) then you'll see they have a class called 'Vector' for a 1D tensor. That's pretty standard.

My thought is not that you shouldn't use 'Vector' for a 1D tensor, but that you should think carefully before writing your own. :) Having one good linear algebra library is much more useful than having 10 incomplete ones.

Cheers,

Will :-}

Russ -
Vector also has a precise mathematical meaning, which (unfortunately for you) computer languages have chosen to use above the "physics" one! What I tend to do in these cases, is provide Predef-like type declarationa that can be imported as a package object.

package object physics {    type PVector = russ.Vector    val PVector = russ.Vector}
then import russ.physics._
val v = PVector(speed, dir)

Chris

Date: Sun, 24 Oct 2010 16:07:42 -0700
Subject: [scala-user] why no mutable List or immutable Array?
From: russ [dot] paielli [at] gmail [dot] com
To: scala-user [at] listes [dot] epfl [dot] ch

The Scala collections are impressive, but I am still a bit confused about why they are the way they are. I'm probably naive on this topic, so please bear with me.

So far, I've used List, Set, Map, Vector, Array, and a few other collection classes. I've noticed that Set and Map have both mutable and immutable versions. In fact, I just verified that the mutable Set has a method called toSet to convert to a mutable Set. Ditto for Map.

I am wondering why the other collection classes are not similar, particularly List and Array. When I want to build up a List, I can use a "var List" or a "val Listbuffer," then convert to a List. Why not have a mutable List that can be converted to an immutable List? Ditto for Array. It seems to me that a Vector is more or less an immutable Array.

Why do I care? Well, one reason is that I appreciate consistency. The other reason is that I wrote my own Vector class, and I don't appreciate the name clash. As an aerospace engineer, the word "vector" has a well-established meaning for me: a physical entity with a direction and a magnitude, as in velocity, force, etc.  I wrote my own Matrix and Vector classes, and I face a minor dilemma. I figured I would not need the Scala Vector class, so I decided to call my class "Vector." Now I realize that I need the Scala Vector class, so I need to either rename my Vector class or rename the Scala Vector class (or use fuller names such as immutable.Vector, which I don't usually like to do). I am leaning toward renaming my class to "Vectr" or something like that to avoid confusion, but the name "Vectr" is nowhere as aesthetically pleasing as "Vector". If Scala had an immutable Array, I wouldn't have to make this compromise.

Russ P.

--
http://RussP.us

On Mon, Oct 25, 2010 at 7:34 AM, christopher marshall <oxbow_lakes [at] hotmail [dot] com> wrote:

Russ -
Vector also has a precise mathematical meaning, which (unfortunately for you) computer languages have chosen to use above the "physics" one!

Chris--this doesn't sound right to me at all.  Can you please provide this precise mathematical meaning or otherwise deliver some insight into why this matches the mathematical idea better than the "physics" one (whatever that is--it looks like a subset of the mathematical idea to me, and historically that was how the concept was added to mathematics anyway)?

Vector spaces typically define + and * operations on elements therein, and a given vector space is closed under such operations.  I'm not sure what Vector("Hello!",Some(5)) * Vector("Bye!",None) ought to yield.

  --Rex

Well, Seq, Map and Set are concepts. In fact, note that they are all traits. All of them have abstract methods that need to be implemented.

Vector, Array and List are classes. They are full implementations for one of those traits. Well, not Array, because that's a Java class.

So when one thinks about Seq, one is thinking of a particular interface, and this interface is futher refined by mutable.Seq or immutable.Seq. But List and Vector are classes that implement one particular interface, so they are not replicated between hierarchies. List is a class that implements the immutable.LinearSeq trait, just as LinkedList is a class that implements the mutable.LinearSeq trait.

On Sun, Oct 24, 2010 at 21:07, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

The Scala collections are impressive, but I am still a bit confused about why they are the way they are. I'm probably naive on this topic, so please bear with me.

So far, I've used List, Set, Map, Vector, Array, and a few other collection classes. I've noticed that Set and Map have both mutable and immutable versions. In fact, I just verified that the mutable Set has a method called toSet to convert to a mutable Set. Ditto for Map.

I am wondering why the other collection classes are not similar, particularly List and Array. When I want to build up a List, I can use a "var List" or a "val Listbuffer," then convert to a List. Why not have a mutable List that can be converted to an immutable List? Ditto for Array. It seems to me that a Vector is more or less an immutable Array.

Why do I care? Well, one reason is that I appreciate consistency. The other reason is that I wrote my own Vector class, and I don't appreciate the name clash. As an aerospace engineer, the word "vector" has a well-established meaning for me: a physical entity with a direction and a magnitude, as in velocity, force, etc.  I wrote my own Matrix and Vector classes, and I face a minor dilemma. I figured I would not need the Scala Vector class, so I decided to call my class "Vector." Now I realize that I need the Scala Vector class, so I need to either rename my Vector class or rename the Scala Vector class (or use fuller names such as immutable.Vector, which I don't usually like to do). I am leaning toward renaming my class to "Vectr" or something like that to avoid confusion, but the name "Vectr" is nowhere as aesthetically pleasing as "Vector". If Scala had an immutable Array, I wouldn't have to make this compromise.

Russ P.

--
http://RussP.us

--
Daniel C. Sobral

I travel to the future all the time.

I just looked up "vector" on dictionary.com, and they don't distinguish between a mathematical and a physical meaning of the word -- but they do give a biological definition!

The word has quite a few meanings. First and foremost, there are physical or geometric vectors such as velocity or force, which have a direction and a magnitude -- arrows in space. Then you have algebraic vectors, which are typically used to represent physical vectors in a particular coordinate system as a list of physical scalars. That algebraic representation is not unique, of course. It depends on the coordinate system, and there are an infinite number of possible cartesian coordinate systems, plus an infinite number of other possible nonlinear coordinate systems, including polar or cylindrical coordinate coordinate systems. So for any physical or geometric vector, an infinite possible number of algebraic vector representations.

Then you have "state vectors." A state vector is an algebraic vector that combines two or more algebraic vectors into a single vector. For example, the position and velocity of an aircraft can form a state vector with six elements. Or you could add acceleration and get nine. State vectors are used in state estimation and control theory, which is a major field of study and research. Kalman Filters for advanced navigation systems can have upwards of 20 elements.

The Scala Vector could be used to implement an algebraic vector, but I'm not sure it would be wise. In my own basic Vector class, I used an Array, but that's mutable. Maybe a Scala Vector would be good for an immutable algebraic vector, but it seems to be designed to hold a huge number of elements, so it just doesn't seem appropriate.

Russ P.

On Mon, Oct 25, 2010 at 7:37 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

On Mon, Oct 25, 2010 at 7:34 AM, christopher marshall <oxbow_lakes [at] hotmail [dot] com> wrote:

Russ -
Vector also has a precise mathematical meaning, which (unfortunately for you) computer languages have chosen to use above the "physics" one!

Chris--this doesn't sound right to me at all.  Can you please provide this precise mathematical meaning or otherwise deliver some insight into why this matches the mathematical idea better than the "physics" one (whatever that is--it looks like a subset of the mathematical idea to me, and historically that was how the concept was added to mathematics anyway)?

Vector spaces typically define + and * operations on elements therein, and a given vector space is closed under such operations.  I'm not sure what Vector("Hello!",Some(5)) * Vector("Bye!",None) ought to yield.

  --Rex

--
http://RussP.us

> I figured I would not need the Scala Vector class,
> so I decided to call my class "Vector."
> Now I realize that I need the Scala Vector class,
> so I need to either rename my Vector class or
> rename the Scala Vector class (or use fuller
> names such as immutable.Vector, which I don't
> usually like to do). I am leaning toward renaming
> my class to "Vectr" or something like that to
> avoid confusion, but the name "Vectr" is nowhere
> as aesthetically pleasing as "Vector".
> If Scala had an immutable Array,
> I wouldn't have to make this compromise.

Did you consider renaming Scala's Vector class with an import?

Defining your own Vector class should shadow the one from Predef (afair) and
then doing an "import scala.immutable.{Vector => ScalaVector}" should work.

Would that be enough?

Greetings,

Simon