By definition algorithms are independent from the medium they run on. E.g. I use Excel tables to play with data structures and to do some move/shuffling/marking experiments before implementing an algorithm in a programming language.
What tools and techniques do you use to design and simulate the function of an algorithm? How do you use drawing programs? A special specification language?
I guess it depends on the complexity of the algorithm.
Quite often I'll actually draw a quick sketch of a flowchart on some paper. There are some excellent diagramming tools available, but I still haven't found one that is as quick as a good old fashioned sketch on a piece of paper.
Other than that, I often end up throwing together a really 'quick and dirty' mock up of the algorithm in a VB.NET windows forms or console application. With some of the more recent features like LINQ-to-SQL, you can even put together prototypes that rely on database access in a very short space of time.
I dont use a tool as such, but often I will rough out an algorithm in a high level scripting langauge such as groovy before implementing it in Java.
I find that with higher level scripting langauges you dont have to worry so much about the language and you can more focus on the algorithm. Then when you have proven the algorithm, you can port it a more restrictive language.
I usually sketch it out on paper, then try a quick implementation in Common Lisp and test it on the REPL.
I normally use a whiteboard (I have one at work and two at home) to sketch out the rough algorithm, and for trying out a very small instance of a problem. If I need to code it up I write a prototype in Python.
I normally only use a drawing program when I need to write formal specification documents. These normally show a higher level design than algorithms though, like using Visio for UML diagrams.
Algorithms are independent of language, true. But any medium you use is a language, period. Using Excel means you're using the excel "language" (rows, columns, cells, etc.) to express some of your algorithm. Maybe not the complete, finished product, but you've expressed it in Excel.
UML diagrams are a language for expressing an algorithm. A sketch on paper is a language for expression. It's hard to separate the platonic ideal algorithm from all concrete representations. No matter what you do, you're expressing it in some language.
The trick is to separate the algorithm from specific language features and limitations.
Any "informal" notation will help do this. English (or other natural language), mathematics, diagrams, etc., are all candidates for expressing an algorithm in a language that's free from implementation quirks and problems.
I start with an overview in English. Plain text, not even MS-Word or something where formatting is a distractor.
For really complex things, a little supplemental mathematics helps put formal assertions around the state of the program.
Also, UML diagrams help. I use Argo UML -- cheap and effective.
For more on this topic, you want to read about formal verification systems.
By definition algorithms are independent from the medium they run on.
What definition is that? Who made it? And did they know about leaky abstraction?
Good algorithms must often know about the platform they're using. If that weren't true, programs would be automatically parallelizable for the GPU, and could be effortlessly rewritten to work on quantum computers.
That said, many fundamental algorithms are indeed platform-agnostic. Oddly, I actually feel most comfortable using C++ to fiddle around with algorithms. However, when doing this I heavily rely on a high level of abstractions so I don't play around with pointers or the likes. On the other hand, the STL actually offers a quite rich toolkit to play around with algorithms.
And, same as Bill, I use my whiteboard quite a lot. I actually have a 1m * 2m whiteboard in my living room. Creepy. ;-)
I generally hack something out in Python which implements the algorithm. I'll completely ignore any sane coding guidelines - for example, I won't create classes to store my data, but I'll just create larger and larger tuples to contain all my info and to represent an 'object'. This is just to get a working version of the algorithm as fast as possible. Once I understand it, I'll implement it in a more sane way in the target language.