Friday, November 28, 2025

A bad week for computers

On Sunday, I accompanied my wife to Tel Aviv so that we could sort out some of the inheritance problems arising from my brother in law's will. We had to go to an address in Yaffo (southern Tel Aviv), so unthinkingly we took the train to Tel Aviv, got off at the first station and took a taxi to our destination. It was a long ride. When we finished our business, I saw that the Tel Aviv metro ran very close to where we were, so I checked the route and saw that it would take us to the central train station. When the train came, we alighted and looked for a device where we could clock our travel cards, but we couldn't find one. As both of us can travel on public transport for free, we weren't too bothered. After a stop or two, the train went underground and after a few more stops we arrived at our destination: just like being abroad! There were automatic ticket machines there, but they wouldn't let us out. We explained to the guard who came to check what was happening; she explained that at overground stops, the machines are in the 'bus' shelters; we simply hadn't looked there (this would be like in Italy). As we don't have to pay for the trip, there was no penalty, but someone before us who also didn't 'stamp his card' was charged with a fine.

Reading text messages on our phones, we discovered that there was a major electicity blackout in our area after a pole had caught fire. There was an urgent problem with Priority that had to be fixed so I had no choice but to call the network manager and talk him through the correction that needed to be made. Later I discovered that instead of writing an equals sign (=) in a condition, I had written an unequals sign (<>)! A small difference with a major effect! 

The power came back on at around 16:30, which is when I discovered that my XP computer refused to boot. I assumed that the power supply had gone. The next evening, I took that computer along with my mobile to our local repairman: the mobile worked fine, but its fan would frequently get stuck, thus causing the computer to overheat. There was also a problem with the lid. In the mean time, I used the computer that I have from work for my daily activities: this is fine for working, but I don't have that many books or much music on it. 

After a few broken communications, the repairman told me that the XP computer was completely dead; apart from the power supply, there were several capacitors that had blown. "It's OK", I told him, "I have a reserve computer here for exactly this contingency. Can you move the disks from the old computer to this reserve one?" "Send me a photo of the computer's board", he replied. I did so, only to be told that several of the capacitors on this computer also were dubious. This morning I connected the computer to the peripherals, but it too would not boot. It's a real problem to find a board that is old enough to support XP these days. If the repairman doesn't find one, maybe I'll use a more modern computer and try to build a virtual machine that at least will support Delphi 7. I don't know what I'll do about music.

I picked up the mobile an hour or so ago. It has a completely new case which on one hand is good, but on the other hand, I've lost a USB port. There are now only two which are on the left hand side, making life problematic for the mouse. I'm using an extension cable at the moment.

The work computer could not access emails sent to my home computer, whereas my mobile computer can. There were a few blog entries than needed to be uploaded into the blog manager, but the HTML code that the modern version of Outlook creates is not good for the blog manager. After a bit of experiment, I discovered that I can input the HTML code: almost nothing gets entered into the blog manager, but then I can copy the HTML code directly from blogger and everything is fine.

I discovered during the week that I could not connect via Anydesk to the OP's server; problematic as I had been sent an email about a problem whose source was oblique. Eventually I swapped messages with someone there who has a certain amount of technical nous: I saw that the clock on the server was showing some date in 2040. After he corrected the date, I was able to connect to that computer. There were several entries in one table that had completely wrong dates - this was the source of the problem. I hand corrected those entries and now everything more or less seems to be ok there. 

I don't think that there'll be a Prolog blog this week. I'll try and bring the code up in Delphi 10 Seattle that I have on this mobile; it should be fine, but there may be a required change in syntax here or there. Programs created by this version are about 10 times larger than under Delphi 7 and I find the programming environment to be very cluttered.

This day in blog history:

Blog #Date TitleTags
31328/11/2010Sumptuous Sunday 2Cooking
109428/11/2017Research proposal accepted!DBA
118828/11/2018Executing a program and waiting for it to finishProgramming, Delphi

Sunday, November 23, 2025

Prolog vs SQL

Whilst writing the final sentences of my previous blog about how something would be easier to do in SQL, I started thinking about the representation of data in Prolog. It started by my adding a fact, cd ('Liege and Lief', 'Fairport Convention'). If I queried which Fairport cds were in the database, then only one cd (Liege and Lief) would be found, and if I queried which Fairport cds are owned by somebody in the database, then again only one cd (Unhalfbricking) would be found. As CoPilot puts it, Right now, your database only knows about owns/2 facts, and the embedded terms like cd(Title,Artist) or book(Title,Author) are just data structures inside those facts. If you want to query them directly, you need a mechanism that “lifts” those embedded terms into their own predicate space.

In SQL, there would be a table of cds and a separate table of ownership whose primary key would be a composite of a person and a cd. Other data such as date of purchase can be added. Relational databases have the key property that every datum is stored only once, and if that datum is needed elsewhere, then it is referred to (that's the 'relational' part).

But Prolog isn't like that and I have to remember that it's not a relational database. If I own a copy of 'Unhalfbricking' and Yossi does as well, then the two clauses about the cd are not the same, although they should unify. I wonder whether it would be possible to have facts like cd (Key, Title, Artist), so that 'Unhalfbricking' could be stored as cd (1, 'Unhalfbricking', 'Fairport Convention). Then there could be  clauses such as owns (noam, 1) and owns (yossi, 1). But I suspect that the concept of an SQL join does not exist in Prolog.

So what can I do to query both a list of cds and to show who owns what? There are various solutions to this, either by writing a rule in Prolog that stores embedded clauses as facts in their own right, or even adding the necessary code to the parser. This is a bit irregular but possible. As they say, it'll be a righteous hack. I did add the necessary code but added a global flag to prevent this, should the user so desire. When adding such a fact to the database, it should be checked that it doesn't already exist; Prolog has no problem with duplicate facts but it tends to ruin solutions.



This day in blog history:

Blog #Date TitleTags
30923/11/2010The gravy boatCooking
31023/11/2010Copper socks 2Health, Copper
109323/11/2017Two more people have passed awayObituary
186423/11/2024Management email problemsProgramming, Delphi, Email, Threads