After more than two decades of happy programming in Prolog (and only a few less years in Assembly Language) it seems natural (or even inevitable!) to create a Blog about all this.
I hope to include in this blog as much source-code as possible, with meticulous emphasis on detail, depth, deep analysis and useful tips.
Unfortunately Prolog compilers -even today- have a great number of differences between them, despite the existence of the (so-called) “ISO-Prolog standard“. Very popular, useful and effective Prolog compilers (such as Visual Prolog) have either departed completely from ISO-orthodoxy (adopting features that violate it) or else they tend to provide many features and new commands that don’t exist in any other rival (Prolog compiler).
The latter is true even among “Edinburgh compatible” ISO-Prolog implementations (both commercial and free or open-source); not even one of them is without such extra features. So, if you have moved from one Prolog compiler to another (in your quest for A.I. Coder’s Enlightenment) you know how tedious and troublesome it can be to convert code originally written for one compiler, for successful running in another Prolog compiler (or CLP, or Mercury, Life… and several other languages, Logic Programming cousins of Prolog).
E.g. both SWI-Prolog (one of the best Open Source implementations) and LPA Win-Prolog (one of the most beautiful commercial implementations) implement a respectable ISO-Prolog standard, but both of them include other features (not required by the ISO-specification) that are unique to each one of then, as well as extremely attractive. (Sometimes I wonder how can I cope without then). These superb features are uniquely implemented in only one of them, at a time. (Unfortunately, you can’t use both…)
Finally, this blog is not just about Prolog and A.I. but also about Assembly Language programming (unless I end up… starting a new blog dedicated for Assembler). In my many years of experience in Prolog programming, I have often stumbled on problems of speed. Oh yes, even today, in certain types of CPU-speed-intensive applications. Apart from the usual algorithmic optimisations, only Pure Assembly Language can offer serious speed improvements (typically of at least one order of magnitude).
Serious massive data-mining tasks, do require a lot of Assembly Language optimisations, even today (at a time where today’s CPU speeds are mature and quite phenomenal). This was also the topic of a paper I presented, at the ALP Visual Prolog programming conference in Portugal (in April 2006 – click here to read the paper – about “Assemby Language Optimisations of Prolog”).
Hello
I am implementing Simulated Annealing on domination problem in graph theory using C . I found your video about TSP with LP prolog interesting. Is there any way that I can use my sours code (.C file) in LP prolog environment to generate such a graphical presentation?
Thanx
Asmaa
Hi asmaa,
The code is not exactly ‘C’, it is mostly optimised Assembly Language, _some_ functions in ‘C’ (around 10% of the code) with a framework driving all this code (before being called by LPA Prolog as a DLL)… which was writen in Visual Prolog 5.1 !
(Note: Visual Prolog 5.* is now a “legacy language”, circa 1998/1999, although probably also the fastest Prolog compiler PDC ever made).
So… even if I sent you all the code, in 3 hi-level languages (LPA Prolog/PDC Prolog/’C') and 2 Assemblers (MASM and TASM), you’d probably have a hard time linking it all up!
What remains, is the _possibility_ (I am thinking about…) of sending the DLL, which has only few functions, callable by other languages (usually LPA Prolog, but also any languages with a standard “stdcall” calling convention).
Well, I’ve written an e-mail to Clive Spencer, sales manager of LPA Ltd., a few days ago, offering to LPA this DLL _free_ of charge (in gratitude for the professional LPA Prolog compiler they’ve been giving me, also free of charge, in the last 10 years or so)…
…which means that I _must_ get Clive Spencer’s reply before giving my DLL to someone else ! -and they’re still thinking about it, NOT in… haste, at all !
In any case, one way or the other, even if LPA decides to keep the DLL as an additional feature of their compiler, my best guess is that it will become available for free downloads, as part of future shareware versions of their compiler.
BTW. the new LPA Win-Prolog 4.91, is due for release, in MAY 2011. And it keeps this small (but magnificent) company… VERY busy, these days, with NO free time to think about… Greeks (like me) bearing gifts!
Watch THIS page, for LPA Prolog 4.91
http://www.lpa.co.uk/ind_new.htm
(where version 4.91 is NOT mentioned YET, since they never announce future plans ahead of time; always only announcing work ALREADY released).
Sorry for the long babble, but I felt the need to explain _why_ I am _temporarily_ NOT giving away the tsp-DLL…
To cut a long story short, in the next few days (perhaps up to a month) one way or the other, there will be good news. I certainly plan to release my DLL as free software (but not as source-code).
P.S. For a long time (2 years or so) I had believed this tsp-DLL to be worthy of selling, not giving away, but… [1] there are other TSP solvers of great quality and speed, e.g. Concorde; so, nobody is likely to pay for a tsp-solver that cannot be TESTED and COMPARED with other solvers... and [2] I’ve moved on to other projects, much more important AND commercially valuable, e.g. my solver for MULTIPLE traveling salesmen / “Team of technicians”, used by ONLY one company, exclusively and experimentally, at this stage.