Are there some kind of mature No-three-in-line problem algorithm in popular languages ( such as Java, C#, Ruby, JavaScript etc) ?
Thanks.
I know it's not direct answer, but if you like to draw complete graph (I don't know your application), you might be interested in checkout out graphviz programming library, or their theory references.
Related
Brief Description
I have a college work where I have to implement a graph library (I'll have to give a presentation about this work later)
The basic idea is to write all the code of the data structures and their algorithms from scratch, using the tools provided by some programming language, like C/C++, Java, Python, doesn't really matter which one of them I'll pick at first.
But I should not use any built-in graph libraries in the language: the goal of the work is to make the students learn how these algorithms work. There are some test cases which my program will be later submitted to.
It is not really necessary but, if you wanna take a look, here is the homework assignment: http://pastebin.com/GdtvMTMR (I used Control-C Control-V plus google translate from a LaTeX text, this is why the formatting is poor).
The Question
So, my question is: which programming language would be more time efficient to implement this library?
It doesn't really matter if the language is functional, structured or object oriented. My priority is time efficiency and performance.
The better language is the one you know more.
But if you're looking for some performance, take a look at compiled languages with optimisations. Keep in mind that the code you write is the major component responsible in final performance, the language itself cant do miracles.
A more low level language give to you controls but requires deeply knowledge of the language and the machine you're running your code, so it's a tradeoff.
By a personal choose I would recommend C/C++ to implement a graph library. I've already done this in the past and I used vanilla ANSI C and the performance was awesome.
The one you feel more passionate about and feel more comfortable coding with.
This way you will rock your project.
Myself would pick Java.
Does anyone have source code implementing this algorithm for finding cycles, preferably in a modern statically-typed language like SML, OCaml, Haskell, F#, Scala?
The following is a Java implementation of the algorithm you need:
https://github.com/1123/johnson. Java running on the JVM, you can also use it from Scala.
I struggled on this too, I came up with this page that lists some implementations for Johnson algorithm (the one looking for elementary circuits) in Java and OCaml. The author of the blog post fixed some issues in the original implementations, on the same page I linked before there are also the fixed versions of both implementations.
You can find it here as part of jgrapht implementation.
Will C++ and Boost Graph Library work for you?
I am developing a ruby program that should be able to draw a genogram on a web page.
I am therefore looking for an algorithm for drawing a genogram or a similar tree-structure.
I prefer an algorithm in ruby but also other languages will do or some references explaning the principles behind such an algorithm
A recursive algorithm in c++ has been published here but it is not documented in a way that allows me to use it.
Any help about how to implement a genogram would be much apriciated
AFAIK, the canonical work on rendering trees is "Drawing Dynamic Trees" by Sven Moen. You should be able to find the paper or an implementation of his polyline algorithm with a bit of googling.
You could also have a look at Graphviz as that can handle trees as well as arbitrary graphs.
if i like Ruby a lot, is there a reason I should learn another language now, such as Lua or Erlang?
New programming languages, much like spoken languages, can open up new perspectives. Learning new languages -- especially ones rather different from what you're used to (and Erlang will probably fit that bill) -- can teach you a lot of different things you didn't even know you didn't know about programming. So yes, I think you absolutely should, even if you just learn enough to tinker with it and get a feel for the new language.
Learning a functional language in particular can be extremely beneficial. Becoming familiar with the functional style of programming is a surefire step toward becoming a better programmer. Lisp (or its derivatives) in particular is a good language to study. Here's a list of past thread on SO that might offer you some insight along these lines:
Why do people think functional programming will catch on?
What’s a good Functional language to learn?
Benefits of learning scheme?
Leaving aside the (excellent) general reasons to want to learn another language, if you like Ruby a lot you might want to
Learn Smalltalk, which is a language very, very similar to Ruby but in purer form.
Learn a language that is very, very different—say something that is based on algebraic data types and functions rather than objects and methods, and something with a static type system rather than a dynamic type system—but something that, like Ruby, will support powerful methods of program composition and generic programming. Good candidates would include Standard ML and Haskell.
Learn a language that is very, very different—say something that makes you control every bit, address, and word in memory—something that forces you to understand and take control of the hardware. In other words, learn C.
Regarding the other languages you mention,
Lua is small and very elegantly designed and implemented. That may appeal to the Rubyist in you. But unlike Ruby it does not impose much of a worldview; it is more of a collection of piece parts. I would suggest you're more likely to appreciate and enjoy Lua after you've worked in three or four other languages first.
Erlang is interesting, but I have a gut feel it's either too different (purely functional, distributed) or not different enough (dynamic type system). But if it appeals to you, go for it.
On the other hand, there's something to be said for really knowing a language well. You'll be able to do a lot more with in-depth knowledge of a single language than you will with surface knowledge of a dozen.
If you like Ruby a lot you should definitely learn another language... one without sigils if possible.
Seems to me that a professional learns the tools he needs to use. Frameworks, containers, languages, all are fair game. I started out in Pascal, went to C and then C++. Then converted to Java. These days its mostly Java with a lot of Javascript and some PHP. Easy enough right? Well, I also need to learn Bash scripting and Perl. Never mind all the other crap I need to get on top of (if you say you understand all of web authentication I will call you a liar). There's a lot of stuff out there. Jump in. Be willing to try different things.
I always enjoy learning new languages for the mere challenge of it. It keeps my brain fit. I've also found it makes for good job interview fodder to be able to say "I'm flexible. I'm adaptable to whatever your needs may be in the future. And I can prove it with my long list of languages."
My main language is PHP. I am a script language fan, nevertheless I have dived into C#, Java, Python, Ruby and even OO JavaScript books to find new mechanisms, ways of thinking. I have found pretty many stunts in Java for example, that I could implement in my all day work. So learning or just studying new languages can widen your perspective.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Following up on my previous question on the enduring properties of a book on algorithms, see here, now I would like to ask the community what language would you use to write the examples of such a reference book.
I will probably not use MMIX (!) to write the examples of the book, but at the same time, I think just pseudo-code would be less interesting than examples in a real language.
Still, I'd also like the book to be a resource for researchers as well. What could be the choice of the community? Why?
Answer: I knew this was a tough question and that there would be several different answers. Notice that answers cover the whole range from Assembly/MMIX(!!) to Python and pseudo-code. The votes and the arguments compel me to choose Uri's sensible answer, with one caveat: my pseudo-code will be as close to C as I possibly can (without going into platform specific issues, of course), and I will possibly discuss better implementations in side notes (As all of us know, mathematically proving the algorithm works is far, far from the problems of implementing it).
The book is on algorithms in a particular domain, not on the mathematics of algorithms in general (much smarter people have done and will do much better than me on general algorithms). As such, one thing I consider would add value to such a book is the repository of the algorithms, which I will definitely put online in a companion website (maybe in a couple of languages, if I find the time).
Thanks for all the answers. I sometimes feel I should put everybody who answers as co-authors. :)
A good book on algorithms should be written in psueod-code a-la-CLR...
In my experience, most books that go into language-specific examplse end up looking more like undergraduate textbook than like a serious reference or learning books. In addition, most languages are fairly clunky when dealing with collections (esp. C++ and Java, even with generics). Between all the details, too much is lost. You're also immediately eliminating a lot of your potential audience.
The only advantage to language specific books is that if you were writing a textbook, the publisher could attach a CD and add 50$ to the MSRP.
It's easier for me to understand an algorithm from (readable) pseudocode. If I can't figure out how to implement it in my language with my own collections, I'm in trouble anyway.
You could add to every pseudocode listing a note about implementation details for specific languages (e.g., use a TreeSet in Java for best performance, etc.)
You could also maintain a separate website for the book (good idea anyway) where you'll have actual implementations in different languages. No need to kill trees with long printouts.
Use a real programming language -- never a psuedo one. Readers are very suspicious
of psuedo code , readers like real programming languages. The trap with psuedo languages is that you can define code concepts that the reader cannot impliment in their language of choice
A real programming language has a number of advantages :
1) you can test your code, hopefuly proving your code correct !
2) you can export that code into a published format for insertion in your book,
ensuring that anybody following your code would be looking
at actual executable code.
3) you would not have to defend you psuedo code.
The choice of language is obvously subjective, but I think that almost any modern language
could be used, but I'd recommend one that has 'least overheads' in terms of quick understanding. And perferably one that the reader can get a compiler/interpreter.
If you'd like to use C, then perhaps you should check out D. An improved C.
For example, Ruby is of this ilk if you keep you code 'simple',
Java is not ( too many support libraries required),
in an earlier time Pascal would be a candidate.
BTW: I dont use Ruby now, as I currently use Smalltalk & REBOL, but I would not use
either of those languages in a book. Your book would go straight to the remainder bin !
I would avoid anything that abstracts the core 'mechanics' of any particular algorithm
There is a tremendous benefit in Knuth's rendering of the algorithms in an assembly level language. It forces the reader to carefully consider exactly what is going on in the silicon when we code algorithms in some higher level language. Especially for systems programmers, this kind of understanding can't be gotten any other way.
Knuth's new MMIX is ideal: consider it an assembly level pseudo-code.
My ideal textbook would have algorithms written in pseudocode and MMIX, so that we can see the algorithm in both its pretty and gory-complex forms. Pseudo-code should be preferred to "real languages", because it sidesteps pointless "you should have used this language not that language" battles. At this stage, pseudocode needs no defending -- the best extant algorithms textbooks use either pseudocode or in Knuth's case a kind of assembly pseudocode.
The choice is not going to be able to please everyone.
Robert Sedgewick has written his "Algorithms in..." books in multiple languages. I had the C version for a course and bought the C++ version when I started working with C++ at work.
You can't escape language features (even pseudo language features).
To try to please as many people as possible you could choose two languages, say one functional and one not. It could help illustrate motivations in algorithm choice.
C style is often used because many languages use a very similar style so most programmers understand it without explanation. Further, examples can be run on any machine with a C compiler - which is nearly every machine.
However, higher level concepts often require the use of more recent technologies and techniques - OO, functional programming, etc.
These are often expressed in the language that has the required features. Java, C#, Erlang, Ada, etc - most good programmers will grasp what is going on with just a little explanation.
But C is very nearly a universal foundation - you really can't go wrong if you adopt a C style for examples.
-Adam
I would not use any specific language. Use a pseudo-language that will be clear to most anyone who has done a little programming. Usually these books use something close to the C style, but that is not a rule. I know that you mention that you do not want to use pseudo code, but that will allow you to reach a broader audience.
I would use something that lets you express exactly the idea behind the algorithm.
Haskell is quite neat, but I think that with algorithms that work with state, it can get in your way, and you would be more occupied with the language than with the algorithm.
I wouldn't use C or its descendants (C++, C#, Java ...) because they will get in your way when your algorithms are more "functional" in nature. Again, you would be more occupied with the language than with the algorithm. I would feel very uncomfortable if I had to work without higher order functions.
So, basically, I would use a multi-paradigm language that you are comfortable with, and with which you feel confident that you can express the algorithms without diving into language specifics.
My personal choice would be something like Common Lisp, but perhaps Python or Scala is workable, too.
Python's a good choice all around. It's very readable, even if you haven't programmed in it before. Plus, it's a lot less verbose than some other common language choices.