views:

307

answers:

9

This question was the last straw; and I've been wondering for a long time about it,

Why do people think about "Algorithms" and "Data structures" as about something that can be separated from each other?

I see a lot of evidence that they're separated in programmers' minds.

  • they request "Data Structures & Algorithms" books
  • they refer to "Data Structures" and "Algorithms" as separate university courses
  • they "know Algorithms", but are "weak in Data Structures" (can't find the link, sorry).
  • etc.

In my opinion "Data Structures" are algorithms, since the concept of "Data Structure" is about Algorithms to operate data that go in and out of the structures. But the opinion seems not a mainstream. What do I miss?

Edit: unfortunately, I did not formulate the question well. A separation of data structures and algorithms in programs people write is natural, since, well, the former is data, and the latter is functions (and in semi-functional frameworks like STL it's the core of the whole thing).

But the points above, and the question itself, refers to the way people think, to the way they arrange the knowledge in their heads. This doesn't have to even relate to the code writing.


Here are some links where people separate "algorithms" and "data structures" when they're the same thing:

+1  A: 

I would say it's because functional programming separates what is operated on from the operations themselves. Targets and actions are certainly different, even if they're closely intertwined.

It was object-oriented programming that put data and operations into a single component. Perhaps if OO had come along earlier there would have been one discipline.

duffymo
What about those 5% of people who don't know functional programming, and about the other 90% that don't even know *about it*? How does it explain separation in their minds?
Pavel Shved
I don't think it requires any knowledge of functional programming to realize that there's a distinction between what's done and who it's done to. It's not that subtle.
duffymo
@duffymo, ok, it seems I should edit my question.
Pavel Shved
I'd argue that the percentage of people that don't know functional programming might be higher than 5%. And it looks like the rest of the world simply disagrees with you and doesn't see data structures and algorithms as the same thing.
duffymo
A: 

I agree with you. Both are two sides of one and the same thing.

When talking about data structures, it's always about storing data in a way to optimize certain operations on this data, which leads us to algorithms and complexity.

Developer Art
"Oh we listen to both types of music here, Country AND Western!"
PP
+6  A: 

They are different. Consider graphs, or trees to be more specific. Now, a tree appears to only be a tree. But you can browse it in preorder, inorder or postorder (3 algorithms for one structure).

You can have multiple or only 2 children for one node. The tree can be balanced (like AVL) or contain additional information (like B-tree indexes in data bases). That's different structures. But still you traverse them with the same algorithm.

See it now?

Another point: Algorithms sometimes are and sometimes are not independent from data structures. Certain algorithms have different complexity over different structures (finding paths in graph represented as list or a 2D table).

Konrad Garus
In mathematics, proofs and theorems are different things, but it wouldn't make a lot of sense to have a "proofs" course and a separate "theorems" course. The analogy doesn't necessarily apply with algorithms and data structures - maybe each can sensibly be studied in isolation, my degree is maths, not compsci. But I don't think the fact that you have identified the difference of type explains why they should be studied or considered separately, so doesn't really answer what I think is the main thrust of the question. It just addresses the incorrect statement "data structures are algorithms".
Steve Jessop
I agree with both Konrad and Steve: they are different, of course, but studying either one in isolation is a loss of a time. What good is a balanced-tree if you don't know how to insert / remove elements while maintaining the balanced invariant ?
Matthieu M.
A: 

The two are, of course, closely intertwined. This is why the posts you refer to requests books on both. Not always, though. The core of a sort algorithm, for example, is unchanged no matter what sort of data structure you're working on.

gnud
+1  A: 

People refer to them as different entities because they are. Suppose I want to find an element from a set of data. If I put that data into an array, the array is a data-structure. Once it's in the array, I can use multiple different algorithms to find the element I'm interested in. I could sort the array (with any of multiple sorts) then use a binary search, I could just check each element linearly, etc. The choice of the array as the data structure I would use as opposed to say, a linked list, is not choosing an algorithm.

That said, it is important to understand one to understand the other. If you do not understand algorithms well then it is not obvious what the advantages and disadvantages of different data structures are, and vice versa. As such, it makes sense to teach them simultaneously. They are however different entities.

[Edit] Think about this: If you look at pseudo-code for most algorithms, a data structure isn't specified. You may have a "list" of elements to iterate through etc, but the exact implementation of that list is unimportant to the correctness of the algorithm.

MBennett
+1  A: 

The way I see it is that algorithms are something that work with or on data structures, so there is a difference between the two. A simple data structure is an array, but there are a lot of algorithms that operate on simple arrays, so there has to be a way of separating the two. An array can also represent a tree, and trees are handled with specialized algorithms.

The difference isn't big, because you can't really have one without the other most of the times, but some times you can. Consider the trivial algorithm that determines whether a number is prime - it uses no data structures. Consider the GCD algorithm, also no data structures. You can talk about an algorithm without talking about data structures, but you can't talk about a data structure without talking about algorithms usually. You can talk about a tree, but you'll need algorithms for insertions, removals etc.

I think it's good that there is a distinction because they are, conceptually, different things. An algorithm is a set of steps used for accomplishing a task, while a data structure is something used to store data, the manipulation of said data is done with algorithms.

IVlad
+2  A: 

Algorithms and Data Structures are tightly wound together. Algorithm depends on data structures, if you change either of them, complexity will change considerably. They are not same, but are definitely two sides of the same coin. Selecting a good Data Structure is itself a path towards better algorithm.

For instance, Priority Queues can be implemented using binary heaps and binomial heaps, binary heaps allow peeking at highest priority element in constant time, whereas binomial heaps require O(log N) time for peeking.

So, a particular algorithm works best for that particular data-structure (in a particular context), hence Algorithms and Data Structures go hand-in-hand!

N 1.1
"imagine the difference in complexities for various operations". True O(1) vs. amortised O(1) push. Both true O(1) peek and pop. Stacks don't have any other operations, so I'm struggling to see that this is the best possible example ;-)
Steve Jessop
@Jessop: priority queues? :-)
N 1.1
@nvl, *algorithm* of peeking from binomial heap requires O(log N) time. Not "heap requires", heaps are not executed thus require nothing; big-O estimation is a characteristic of an algorithm.
Pavel Shved
@pavel: i didnt mention it explicity. But the meaning is quite implicit. algorithm complexity is always talked in context of an algorithm, not data-structures alone.
N 1.1
@nvl: excellent example :-) I think it's right to say that binomial heap "requires" that time for peeking. The data structure doesn't store the information in a way which admits a faster algorithm (assuming a typical model of computation).
Steve Jessop
@Jessop: I am still learning data structures and algorithms (student) and trying to improve because i know their selection plays a very important role :).
N 1.1
+1  A: 

They are separate university courses. Typically, the data structures course emphasizes programming and is prerequisite to the algorithms course, which emphasizes mathematical analysis of algorithms. I don't think it's hard to see why many people with an undergraduate education in CS might think of them as separate.

A: 

The title of the book Algorithm + Data Structures = Programs (1975) by none other than Niklaus Wirth suggests that both are essential in writing a program.

ArunSaha