Saturday, 29 September 2018

Creating the Personas - Imagining the User

Now we arrive at one of the creative aspects of user design. Actually, there is a lot of creativity with user design, and this is one of those aspects: the persona. Basically, this is the creation of a typical user, but not just one typical user, but a whole gamut of them. For instance, let us take the idea of a Stock Trading app. To develop the app we need to know what type of people will be using it. To simply say 'an investor' really doesn't cover everything that we will need to take into consideration. It is sort of like going to a networking event and introducing yourself as 'a computer programmer' or as 'a lawyer' - it says absolutely nothing about your strengths, or what might intrigue a potential client.

So, let us consider some users of this stock market app:
  • The casual investor
  • The broker
  • The day trader
  • The buy and hold investor
  • The bank manager
  • The first time investor
  • The homeless guy that just made a fortune
Okay, there are probably more, but let us look at this list for now. Basically, what we have are a list of people who will not only be using the app, but will be using it for different purposes. The day trader will probably be checking the app every five minutes, while the buy and hold investor might check it daily, or even less often. So, what we need to do is to create personas around these specific individuals, outlining things such as their demographic, their attributes, their domain experience, and their skills. Let pick one, say, the buy and hold investor.

So, first of all, we get a picture and give our persona a name (though we shouldn't base it on a real person as it will taint the process). We then create a description of this person, outlining their general attributes, their knowledge of technology, and any skills that they might have.

Well, where do we get these personas from? Well, remember how we have been talking about usability testing, interviews, and surveys. Well, that is where the personas come from. As we gather information, we get an idea on the various users of our product, and from this information we can then develop an understanding of the types of people who will be using our product. However, let us consider what Greg Bernstein has to say about it:

Now that we know about personas, let us create one, namely Robert, the buy and hold investor:

Robert is 60 years old, and is nearing his retirement age. He has a substantial nest egg which he has invested in a share portfolio. Robert is the state manager of a fast food chain , and while he has an understanding of how business works, he isn't all that up to date with regards to financial products. He regularly uses a computer, since his job requires him to do so, however he only uses it for the basic tasks. He has a laptop that his company has provided, which he also uses as his personal computer. He can use most Office products, as well as simple browsing of the internet. In relation to his investments, he has an idea on how to read financial data, and also how they relate to stock prices, but in many cases he doesn't spend a huge amount of time on it.

Notice how we used a picture. This helps to actually visualise the user that we are creating the app for. Anyway, our next step is to create what is called a 'context scenario', namely a story on how Robert has come to use the app. Now, remember, we are only doing this for one persona, but in reality we will be doing this for all of our personas, and we will be creating profiles for them as well. In fact, with the more research that we do, we might end up combining, or even splitting, personas.

Robert's Share Trade
Robert was in his car driving to the next restaurant that he was inspecting and was listening to the news. The news mentioned that there was a new listing on the stock market, Inghams Chicken. Robert, having knowledge about how popular chicken is in the food industry was quite intrigued and wanted to find out more. He remembered that he had downloaded Stockbuy onto his phone a few days earlier, and decided to check it out. He had already linked it with his trading account, but never had an opportunity to use it. So, he opens the app, and types in Ingham's Chicken. The app produced a screen outlining the stock, and Robert spent some time going over it. He then realised that he could purchase some of the stock on the app, so he went ahead and did so.

These stories, like the one above, basically tell us about how the various personas will use our app. Now, my mistake, being the writer that I am, is to go into a lot of superfluous detail, which we don't need to do. All we need to do is outline how the various personas will use the app, and then work the development of this app around these scenarios. This leads us to the more technical detail which is known as the key-path scenario.

Basically, what we do here is that we take the information from the context scenario and we break it down into a series of steps that the user does, and that the app responds to. This way we are able to develop our app through these scenarios. Once again, they need to be done for all of the scenarios, as this enables us to get an idea of the length and breadth of the app. So, let us consider Roberts stock trade:
  • Robert clicks on the app
  • The app asks for Robert's user name and password
  • Robert enters the information
  • The app confirms that the information is correct and opens the app
  • Robert types 'Ingham's Chickens' into the search bar
  • The app searches the data base and produces all relevant results.
  • Robert presses on Ingham's Chickens
  • The app jumps to the Ingham's Chickens front page
  • Robert peruses the information and presses the finanicals tab
  • The app goes to the stock's financials
  • Robert presses the chart tab
  • The app goes to the chart of the stock price over a year
  • Robert presses five years
  • The app shows the stock price over five years
  • Robert presses on news
  • The app shows various news articles relating to the stock
  • Robert presses on an article
  • The app opens the article in a new screen.
  • Robert reads the article and goes back to the app. He then presses on the buy stock tab
  • The app asks him how many shares he wishes to buy
  • Robert decides to invest a certain amount, so he enters a dollar figure
  • The app converts the dollar figure to a share amount, and asks for a trading password
  • Robert enters his password
  • The app purchases the stock on Robert's behalf.
 So, that is it for personas. Next time we will be looking at prototyping, which is the means of testing the app before the full development takes effect.

Creative Commons License

Creating the Personas - Imagining the User by David Alfred Sarkies is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. This license only applies to the text and any image that is within the public domain. Any images or videos that are the subject of copyright are not covered by this license. Use of these images are for illustrative purposes only are are not intended to assert ownership. If you wish to use this work commercially please feel free to contact me

Sunday, 23 September 2018

The Intricacies of Data Transfer (and some Other Random Stuff)

Okay, CPUs, or the computer's central processing unit, is basically the heart of any computer and they are pretty complex these days. However, the key to understanding computers is to understand how these chips operate. So, let us first look at a diagram of the CPU and see the parts that make up the whole:

Well, that diagram may not say as much as one might expect, so let's unpack it and look at each of the components.

RAM: This is the random access memory. Technically this isn't a part of the CPU, however the modern processors do have memory built into the chips known as Cache (more on that later). This is pretty much where everything is stored, from the data to the instructions.

MAR: The memory address register. Now, whenever you see the word register you can basically assume that this is a short term storage area. In this particular instance, this is where the addresses are stored. Much like the physical address where you live, the address on a computer tells the computer where data, or instructions, are stored in the RAM.

MDR: This is the memory data register, which is where data, or information, is temporarily stored. Basically when data is fetched from the RAM (based on the address in the Memory Address Register), it is temporarily stored here before it is sent into the CPU to be processed. However, once it has been processed, it is sent back here to be stored while the computer searches for the address where it is to be placed in the RAM.

IR: The instruction register is the third register in the CPU, and this is where the instructions that have been pulled from the RAM are stored. Basically the computer checks the instructions, and once it has determined what needs to be done, it performs it by sending it to the Control Unit (if it can be performed, but we will assume that it can be performed).

PC: This is the program counter and is where the computer keeps track of where it is up to in the specific program. It normally holds the address of the next instruction in the program, so that once the current instruction has been completed, it can then use the information in the program counter to move on to the next step and fetch the next instruction.

ACC: The accumulator is basically where the results of any instructions, specifically mathematical functions, are stored before being returned to the MDR to then be placed back into the RAM.

Control Unit: Where the CPU is the heart of the computer, the control unit is the heart of the CPU. This is where instructions are fed to be interpreted and then actioned. The control unit does a lot more than just interpreting instructions, it also actions them.

ALU: The Arithmetic Logic Unit is basically where all of the mathematical calculations are performed. Those adders that we explored in a previous post will actually be found here, but there is actually much more to the ALU than simply adding two numbers together as it is also designed to perform complex calculations such as floating point processes. In older computers there used to be a chip called a Maths Co-processor that was designed to perform these functions, but these days this is incorporated into the CPU.

Clock: The clock rate of the cpu is basically how many instructions can be performed in a given period of time, and the clock basically keeps track of the instruction cycle. In a sense what it does is that it keeps everything moving along.

The Instruction Cycle

Okay, I was bandying around the term 'Instruction Cycle' so it might be an idea to actually explain what it is about. Basically the instruction cycle is known as the 'Fetch - Decode - Execute - Store' cycle and is the basic way the CPU operates. So, the computer checks the address in the Memory Address Register and then fetches whatever data happens to be there. It them places it into the Memory Data Register. The control unit then interprets the data to determine whether it was an instruction, or just plain data (which it would have known from the instruction that had already been execute). Once this is determined, the instruction is then executed before being returned to the RAM.

Let us consider this process - the first instruction is to fetch data from a specific address, which it does. The next instruction requests the computer fetch some more data, which it does. The third instruction tells the computer to add those two pieces of data together, so they are then sent to the ALU, the addition is performed, and then placed back into the accumulator. No further instructions are required, so it is then sent back to the RAM, and the program counter then checks the address of where the next instruction happens to be. That is then pulled into the Memory Data Register, and because it is an instruction it is sent to the instruction register. Unless the instruction happens to be an instruction requiring the program to jump to a different address, the Program counter will store the next address as the location of the next instruction.

And so it goes ...

Now, if you look at the CPU diagram above, you will notice that there is only one way traffic between the CPU and the RAM through the Address register. This is because addresses aren't pulled in from the RAM, but rather sent to the register from any instructions that have been pulled. The instructions will tell the CPU where any relevant data is stored, and as such those addresses will be sent through to the RAM via the Memory Address Register. However, the Memory Data Register has two way traffic, right down to the ALU. This is because data is flowing both ways, out of the RAM, and back into the RAM. Notice also the CPU bus, which connects the registers, the Program Counter, and the Instruction Register. This is because data pulled from the RAM could go to any one of those locations. Notice also that there is two way traffic into the Control unit, but also lines from the control unit to all parts of the CPU, and even the RAM. This is because while the Control unit interprets instructions fed into it by the instruction register, it also needs to interpret data brought in from other areas. Thus, when an instruction tells the CPU to fetch some data, it needs to notify that the next bit of information coming into the Memory Data Register is data, and not an instruction.

Confused yet? Well, so am I and I'm writing this. Maybe this video will help:

Swapping Devices

Okay, we will come back to the CPU a bit later, and now look at the concept of swapping devices. Basically there are three ways of doing so: Hot Swapping, Warm Swapping, and Cold Swapping. Hot swapping is where you can add or remove a device while the computer is actively in use, warm swapping is occurs when the computer, or device, is asleep, and cold swapping is when the computer has to be shut down to replace them.

Now, an example of hot swapping would be the mouse or the keyboard. Honestly, I generally don't like hot swapping things, but if you need to change a mouse, you can simply unplug one, and plug in another.

An example of warm swapping would be an external hard drive. Okay, I know that you can theoretically hot swap them, but really, that is a very, very bad idea. There is a reason why you should unmount a external harddrive before removing it, and that is because it parks the head. If you don't do this, you are actually in danger of destroying your data (I ought to know, it happened to me). However, you can plug them back in without any concern. Other examples would be removing storage devices from inside the computer, such as CD and DVD ROMs.

As for cold swapping, I would suggest a graphics card. In fact, to replace one of them you generally need to completely unplug your computer, open it up, and then put it in when it is powered down. Oh, and replacing the power supply is also another example (though I suspect if you did try hot swapping it, your computer wouldn't be powered on for much longer, and you also run the risk of getting a pretty nasty, death inducing, electric shock).

Serial and Parallel Connections

So, there are two types of cables (well, there are probably more than two 'types' but we are talking about what is termed as bus topography here), and that is serial and parallel. Basically a serial cable is where you have a single cable and the data is sent along the cable sequentially. The parallel cables have multiple cables running side by side, and the data is sent down each of the cables. Now, the USB cables are a classic example of a serial cable, but here is a picture of the old school ribbon cables (which you used to find inside your computers, and some of the older computers, such as mine, still use them):

Here is a diagram of how they are, theoretically, supposed to work:

real arts!!!: Data Transmission!!!
Now, the problem with serial cables is that they were slow, which is why parallel cables were in frequent usage in the past. However, speeds have increased significantly, so parallel cables are no longer as prevalent as they once were. The reason for this is that there tended to be a lot more problems with parallel than serial. For instance, parallel cables were only practical over short distances, the longer the distance the less effective the cable was. Secondly, there was an issue of cross talk, which basically meant that the cables would have the effect of interfering with the cables next to it. This was sorted out by having ground wires. The final problem is that if all of the data didn't arrive at the same time, then there would be delays as the components pretty much played catch up. So, now that serial cables are much faster, the parallel counterparts are pretty much a thing of the past.

It should be noted that even though the cables are a thing of the past, if you actually look at your motherboard, or even inside your CPU (which you pretty much can't because they are so small the buses are measured in nano-metres, which means that you will be able to see didly squat), you will still find parallel connections. This is because the distances involved are so small that syncronisation issues aren't that big of a problem.

Another thing about parallel cables is that they really can't handle higher speeds in the way that serial cables do. Now, this is a little year twelve physics - when you send an electric current down a wire. the current will produce a magnetic field around the wire - this is why you generally don't see houses built underneath those huge transmission towers, it has more to do with the electro-magnetic field that is produced than the towers accidentally falling down (because houses are close enough that if they do fall down, then there is a still a chance that they can fall on the houses).

Now, the faster you send signals along the cable, the greater the magnetic field becomes, and as mentioned above, these fields have a tendency to interfere with the parallel wires. So, when the transmission is sped up, the chance of interference will also increase substantially. 

More on Error Correcting

So, we have already discussed error correcting codes, so now we shall see how this works in reality. As we understand, there are some codes where errors are detected but cannot be corrected, so that is here something called an Automatic Repeat Request (or ARQ) comes in. Basically if the receiver receives a package that is flagged as being in error, this package will be discarded and a negative acknowledgement will be sent back to resend that particular package.

Now, we have something called Stop and Wait ARQ. The diagram below should explain things, but I'll talk you through it as well.

So, what we have here is that a single frame (or package), is sent, and once received, if it is received without error, then an acknowledgement is sent. Once the acknowledgement is received the second frame is sent. Now, if the acknowledgement is not received after a certain period of time the sender will send the frame again. Now, if the frame has already received, it will send an acknowledgement back corresponding to that frame, and discard that frame. Now, this acknowledgement is the key, because if the frame isn't received, then the acknowledgement won't be sent, so the sender does not know whether it has been received or not, so after a period of time it will resend the frame.

Now, notice how it works on 0s and 1s. Everything with computers works on 0s and 1s (well, not quite, but that is getting into the realm of quantum computing, and we won't be going down that road, at least yet). Now, when frame 0 is sent, acknowledgement 1 is sent, which tells the sender to send frame 1. When frame 1 is received, it responds with acknowledgement 0, telling it to send the next frame, which becomes frame 0. Now the acknowledgement tells the sender whether it needs to send the next frame, or the same frame. In the example above, the second acknowledgement was lost, so when the second frame 1 was sent, the sender sent a second acknowledgement 0 because it knew that the first acknowledgement wasn't received.

Finally, let us consider Forward Error Correcting (FEC). Now remember in the previous post we were talking about Hamming Codes and SECDED. Well, this is where forward error correcting comes into play. Basically if the receiver detects an error, it can then attempt to correct that error without having to make a repeat request. It is only when the errors can't be corrected (namely that there are two errors) that the repeat request needs to be made.

Now, there are a few others as well, such as Go-back-N. Here a series of frames are sent, and if one of the frames received has an error, then any subsequent frames that are received are discarded and an negative acknowledgement is sent back regarding the corrupted frame, and the sender repeats the process from that particular frame. Finally, there is the selective repeat, which is similar to Go-back-N, except that only the corrupted frames are resent. So, the receiver only discards corrupted frames, and sends a negative acknowledgement, and the sender then only sends frames where a corrupted acknowledgement was received.
Creative Commons License

The Intricacies of Data Transfer (and some Other Random Stuff) by David Alfred Sarkies is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. This license only applies to the text and any image that is within the public domain. Any images or videos that are the subject of copyright are not covered by this license. Use of these images are for illustrative purposes only are are not intended to assert ownership. If you wish to use this work commercially please feel free to contact me

Saturday, 15 September 2018

the Rijksmuseum - Amsterdam's Louvre pt 1

I guess the problem when it comes to the Rijksmuseum is that I didn't actually walk through it in any particular order, and never really noticed whether there was any particular order until long after I left. However, I should mention that the museum itself is huge. Well, not quite as big as the Louvre (which happens to be the biggest museum in the world) but it is still pretty massive. We didn't actually get to explore all of the Rijksmuseum either, though I'd say that we saw about 90% of the place, and the rest of the 10% we simply rushed through trying to find the way to get to where we wanted to go.

This was actually one of the really annoying things about the Rijksmuseum, and that is that it can be nearly impossible to get around. The museum is sort of divided into two halves, and while you can easily navigate it on the top level, as you go down, it is near impossible to get from one side to the other, and sometimes getting from one floor to the other, even on the side you want to be on, can be a challenge in and of itself - and we even had a map.

However, enough of that, and instead lets explore some of the artworks that I discovered as I wandered through this place taking photos of literally anything and everything, though another problem ended up being that since my phone was running low on juice it was going to be touch and go as to whether I would get to the end before it died. I did have my camera on me, but that is shocking for taking photos of text, and since the memory card I had at the time was minute, the problem there came down to making sure I had enough space on it.

So, I'll start with an artist named Francios Spierling, who was actually famous for weaving tapestries. Belgium actually had a huge textile market during the 15th century, but when the Dutch revolt broke out in the 16th century, and the region was engulfed in war, many of weavers fled to the northern regions of the Netherlands, where they continued to practice their trade. It was here that Spierling rose to fame, who happened to be the son of the mayor of Antwerp, and produced many of the tapestries, a couple of which we shall be looking at.

Spierling was fascinated with the story of the Greek Goddess Diana and many of his tapestries reflect that. This one is called Meleanger and Atalanta. The story goes that Diana (or Artemis as she is known to the Greeks) sent a huge boar to go ravaging the kingdom of Calydon. The king then offered a reward to anybody who would kill the boar, so his daughter (of all people) decided to go and hunt it down. She was sort of successful in finding, and wounding it, but it was Melanger who eventually killed it. Since Melanger was in love with Atalanta, he decided to give it to her as a gift (not something that I would recommend replicating these days and ages).

This tapestry, called Latona and the Lycian peasants, and a fable that basically explains why you shouldn't, well, be a prick. The story goes that the goddess Latona, and her two children, Apollo and Diana, were thirsty so they went and had a drink in a pool. Well, the farmers weren't particularly impressed with that so they decided to stir up the pond and make it extra muddy (and might have done a few other things to it as well). Not surprisingly, Latona wasn't all that impressed, and so she went and turned them into frogs. This is one of the reasons why hospitality is so important in some cultures, because as the Bible suggests, in being hospitable, one might find themselves serving Angels (as was the case with Abraham).

This painting, by Gerard van Nijmegen, is called 'A Mountainous Landscape near Dusseldorf'. It figures an unfarmed view of nature and in a way prefigures the romantic movements of later centuries which seeks to explore nature in its original form. Though it isn't entirely without signs of civilisation, as there appears to be a fortified outpost on the hill, and we also have a wagon train making is way along what appears to be a remarkably unkept road. However, the outpost is actually a ruin, suggesting that nature has this habit of quickly reverting to its normal form.

A painting by Cornelius Saftieven shows the average life in a small town. This painting is called 'Figures before a Village Inn' and here we see ordinary people doing ordinary things. However, it seems as if there is a storm brewing, but people are simply just caught up in their daily activities. For instance an intoxicated man orders more to drink, and notice how we have a friar, who apparently has taken a vow of poverty, ingrossed in a game of cards. This is a ordinary scene that tells us a lot about the ordinary people.

Another village scene, this time by Teniers, and it is known as Peasant Kermis. Here we see a scene of revelry on what appears to be a nice summers day. A couple dance in the middle of the scene, most likely to music, while an older lady assists a man, who might have had a little too much to drink, get back on his feet. Here, nobody is excluded, as the wives have also brought the babies along to join in the festivities. Yet we also notice how the animals are never too far away, and the pigs seem to nuzzle themselves.

This time we have a sculpture by Jan Pieter Van Baurscheit, and is known as Topers, since this is what they are (though I'm not entirely sure what a Toper actually is). This sculpture warns the viewer of the dangers of gluttony, since excessive drinking, not surprisingly, leads to drunkenness, and this undermines the work ethic. These types of characters make appearances in plays of the time, which also made mockery of the character tropes, as a warning to the audience not to follow in their paths. Sometimes, though, I suspect that such warnings go unheaded.

It seems that drinking was a big problem in the Netherlands at the time, but then again that is not at all surprising since the water, particularly in the urban areas, wasn't all that safe to drink. This is something that seems to repeat itself throughout history, though these days our water, at least in some places, is actually quite drinkable. However, the Dutch were always looking for an excuse to have a party, and thus in turn looking for an excuse to have a drink. Okay, while they suggest that parties lasted from about midday well into the night, this doesn't suggest that they were 'big' parties, since some ancient parties would last for at least a week.

This painting by Franz Janz Post is called the View of Olinda, Brazil. It is rather interesting to note that the Dutch did have colonies in Brazil, which they captured from the Portuguese. I guess there are still remnants of that colony on the North coast of South America known as the Guayanas. Here we see what appears to be a ruined cathedral, but the people standing in front suggest that it is still in use. However, notice how at the bottom of the painting we have some uniquely South American creatures, such as the sloth and the anteater.

I probably should have left this till last, since it is the centre piece of the Rijksmuseum, and probably Rembrandt's most famous work. Yes, it's The Night's Watch, a name that was given to the painting much later. It was painted by commission of the Amsterdam Civic Guard, and true to Rembrandt's style, he did something slightly different. Normally such paintings would be painted where the main figures were indoors, but Rembrandt painted them during an action scene. Notice also the little girl, who is apparently the watch's mascot.


The Dutch had a huge colonial empire built entirely on trade. Initially it was to the west, namely to Suriname, the Antilles in the Carribean, and West Africa. Here they would transport numerous commodities not available in Europe and made huge profits in the process. However, later on they engaged in the slave trade between West Africa and the Americas, a trade that was vastly more profitable, particularly since it meant that the ships didn't travel across the Atlantic empty. Of course, the practice absolutely devastated the lands from which the slaves were taken, to a point that the legacy still haunts the region today.

To the East, the Dutch established themselves in Batavia, modern day Jakarta, the capital of Indonesia. From there, they spread throughout Asia, trading, raging war, planting crops, and making huge amounts of profit. Indonesia was known as the 'Spice Islands' for the rare spices that were there. Previously, such spices had to come through the Middle East, forcing Europeans to pay huge mark ups to the Arab and Turkish traders. However, after the Portuguese defeated the Arabs in the Indian Ocean and took control of the route, the Europeans were able to cut out that middle man, and take the profits themselves.

This is a model of a Dutch Merchantman known as the Prins Wilhelm. It first set sail in 1651 and made five trips to Batavia in Indonesia before sinking with no survivors.

This is indicative of the maps drawn by Wilhelm Janzoon Blau in his atlases. The colours on this particular map actually have no meaning whatsoever, and are really only representative of his style. However, his maps are well known for their detail (even if not particularly accurate, but then again he didn't have the luxury of relying upon satellite images). He is also well known for his intricate cartouches, which are also a mainstay of his maps.

Dirk Janzs van Santen was very popular in his time, and he could command a premium for his drawings, such as the one above, which is a reconstruction of the temple mount in Jerusalem. The view is looking to the east, and is the original temple built by Solomon. This drawing was actually taken from a display that had reconstructed the temple that was in Amsterdam at the time.

While there was a lot of hand drawing and painting around this time, woodcut prints were also quite popular. However, the actual colourist usually worked anonymously, generally in the employ of the people producing the prints. However, prints were very popular, particularly since they were somewhat cheaper, though of course, if they were hand-coloured then that was an entirely different story. Some colourists, such as van Santen, did actually make a name for themselves, and were well sort after even though the profession was an highly specialised one as is.

Paintings like this one from Dirzk Hals tend to have a double edged sword. In one sense it is a scene of artiscratic merrymaking (not that there were any aristocrats in the Netherlands at the time - it was a Republic), but in another sense it is a subtle warning against the futility of merrymaking - eating, drinking and the like. We see a monkey sitting, with a chain around his neck, which is representative of the sinful man, who is chained to his wanton desires.

While this looks like the tool box of the painters, it quite possibly isn't. Rather it is what is known as an objet d'art, or decorative art. Basically, it is one of those objects that is so decorated that you actually never use them, like those touristy things you happen to buy in gift shops (though I do drink out of my beer mug I bought in Dusseldorf). While there are bottles in here containing pigments what the purpose of it is to be more decorative, particularly with the various scenes painted inside and out.

Interestingly enough the Netherlands of this period was very much like today. In fact it was not uncommon to find paintings in the homes of the less well to do. Obviously, you wouldn't find paintings of the well known artists, such as the Rembrandts, who generally only adorned the walls of the upper classes. However, painting was still a lucrative business for those who had the skill, though many artists would stick to a specialisation, something that a master like Rembrandt didn't need to do.

This painting, by Adrieen van de Venne is called the Departure of a dignitary from Middelburg. Notice how the ship is being towed out to see by some draft horses, which is another interesting reflection of times past. The person on that ship must have been very important, though we have no idea who it actually was, because it seems that a lot of important people, including the mayor, are standing on the docks watching him leave.

Here we have an interesting piece of religious propaganda by Adrieen van de Venne. The painting is called Fishing for Souls and on the right we have the Catholic Southerners and on the left with have the Protestant Northerners. Here they are both attempting to 'fish' for people to bring into their respective churches. Notice how on the left the sun is shining and the trees are in full bloom, and that the opposite is the case on the right. Another thing to note is that the Protestants seem to be having a lot more success than are the Catholics.

Dutch History

One of the great things about museums like this is that there is a lot of history interwoven between the works of art. For instance, as mentioned earlier, the Dutch and the Spanish were at war, the main reason being that King Phillip of Spain had inherited the Holy Roman Empire. However, while he was an absolutist monarch, you couldn't quite do that with the Holy Roman Empire since they were more a loose collection of independent states. However, he did attempt to do that, and this led to a revolt by the Dutch, a revolt that lasted for years. Eventually they signed a truce, however that didn't stop the internal rivalries and religious power struggles between the Catholics and the Protestants, and between the extremists and the moderates. People were arrested and executed, which only fueled the tensions, and relics belonging to those executed were collected and venerated in remembrance of them.

When peace came about, the Netherlands found itself divided into two. The southern part, which is now known as Belgium (though at the time was known as the Spanish Netherlands) and the northern part became the Netherlands we know today. When the Spanish captured the city of Antwerp many of the inhabitants fled to the north. At the time Belgium was the centre of trade, and the textile industry, and also holds itself out as the birthplace of modern capitalism. As such, as they moved north, a lot of the influences spread there, and that begun what we know as the Dutch Golden Age.

Now we get to see some of the works of the Antwerp painters, and least those who moved north to the Netherlands. This is by Jacob Jordeans and is called Odysseus and Naussica. It is a painting of a scene from the Odyssey where Odysseus, naked and alone, has washed up on the shore of the land of the Phaeceans. The princess Nausica is heading out for her morning frolic in the sea when she is led by the goddess Athena to where Odysseus is lying.

Another work of a story from Classical antiquity, this one by Karel van Mander. This is called the Continence of Scipio, and is a story of clemency which we see throughout the classical world. Here Scipio Africanus, the conquerer of Carthage, handing a beautiful young maiden back to her fiance, even though he had captured her as booty. These scenes are interesting, though is also reflective of the time when religious art was generally not accepted among the extreme protestants of the Netherlands.

Another objet d'art, this one by Johannes Lecker. It is a collection of mythical creatures with a dolphin being ridden by a triton, a creature with the torso of a man, the legs of a horse, and dwells in the sea. On top of the triton is a nereid, a sea spirit from Ancient Greece. No doubt this was never meant to be used, and also shows the movement away from Christian art and towards art of classical mythology.

This is an example of a cabinet that would have been used by an art merchant. The various drawers and trays were used to hold art that the merchant was attempting to sell. The doors could be then closed to allow easy transportation. No doubt this would have been in display in one of the outdoor market stalls. Over time the original contents have since 'disappeared' with only the cabinet remaining.

These two paintings, Democritus on the right, and Heraclitus on the left, form a pair and was painted by Henrick ter Brugghen. These two ancient Greek philosophers exist at the opposite end of the spectrum, with Democritus being a joyful hedonist while Heraclitus is the mournful cynic. Both of them are leaning on a globe, as if to suggest that it does not matter whether you are laughing or crying, the world just continues to stumble along its foolish path to destruction.

We shall finish this part of my exploration of the Rijksmuseum with another mythological work by Brauban, this one called The Chaining of Prometheus. Interestingly Brauben borrowed the style from Caravagio, particularly the sun burnt complextion of Prometheus. This scene is where he is being chained by Vulcan (or Hephaestus, the blacksmith God), and is about to be chained to a rock to have his liver pecked out repeatedly by a vulture.

Creative Commons Licence

the Rijksmuseum - Amsterdam's Louvre pt 1 by David Alfred Sarkies is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.This license only applies to the text and any image that is within the public domain. Any images or videos that are the subject of copyright are not covered by this license. Use of these images are for illustrative purposes only are are not intended to assert ownership. If you wish to use this work commercially please feel free to contact me

Tuesday, 4 September 2018

SECED - Fixing Up the Errors

The thing I've noticed about computer science which is somewhat different from my arts degree, is that things seem to build on the previous topics much more than they did with the social sciences. Okay, history does have this ability to compound, and later authors are influenced by authors that came before them, but it really seems as if this compounding is much more prevalent when it comes to the physical sciences, particularly a practical course such as the one I'm currently doing. The reason I suggest this is because all of that stuff we learnt about Boolean algebra (blame George Boole for that), comes into play here - namely bitmasking and error correcting (and it seems to keep on coming in later subjects as well).

Let's start with bitmasking.

Masking Bits

Actually, I'm not really all that sure as to why they call it bit masking, because what this process is doing is basically changing a bit from one state to another, namely from a 0 to a 1 or vice versa. So, we have three ways of doing it - setting, resetting, and flipping.

Setting: This is changing a bit from a 0 to a 1 and is done using the Or process, and you Or every bit with a zero, with the exception of the one you wish to set, which you Or with a 1. The reason we do this is because we don't want to touch any of the other bits while doing so. In this example, we will set bit 2 to change it from 0 to 1:

Resetting: Basically this is the opposite to setting a bit, namely you are changing it from a 1 to a 0. To do this you basically use the And. Once again, it is the opposite to setting a bit, you And each bit with a 1 with the exception of the one you wish to reset, where you And it with a 0. The reason being is that you don't want to change any of the other bits in doing so. The below tables hopefully will explain this more thoroughly.

Flip: Well, if setting changes a bit from 0 to 1 an resetting changes it from 1 to 0, then flipping does either or (that is from 0 to 1 or 1 to 0), and you do this using the method that pretty much seems like either or, namely Xor, and you Xor the bit with a 1, while Xoring the remainder with a 0. Now, in the example below, I've flipped two of the bangers (I'm not sure why I used that term, but our lecturer did, so I guess it okay), just so you can see how it worked.

So, what then if we need to set some bits, and then reset the rest, well we do that through two processes. Take this example for instance, where we wish to set bits 2 to 4, and the reset the rest. We set the first bits.

And then we reset the rest:

And Why!?!

So, I suspect the question that you are asking is why do we need to know all this. Well, the simple answer is because it is first year computer science. Then there is also the question of how do I know that you are asking the question. Well, you have got this far, and you are still reading so I assume that you have asked the question. Well, now that we have got this out of the way, bitmasking is basically used for correcting errors. Now, we are not talking about that wavy line under the English spelling of a word on an American word processor, but rather when information is passed between components in a computer, or even between computers themselves, sometimes things go wrong, and the computer needs to be able to correct them. If you have a look at some components, sometimes you will see ECC printed on them, meaning that they support error correcting code. Bitmasking is the way that computers correct these errors.

Now, we are only talking about one error here, namely because the computers are apparently so advanced that it is rare for there to be two errors in a code, and pretty much impossible for there to be three (at least when we are talking about the processes inside a computer, passing information between computers is a completely different story). However, the technology we have at the moment is that we can detect and repair a single error, and detect a second error. Computers do this through a process called parity. 

What this means, is that bits, known as parity bits, are inserted at specific points along the data to confirm whether the data that is being sent is correct. The number of bits required is determined using the following code:

Now, this really comes down to trial and error. So, m is the number of bits, and p is the number of parity bits that we might need. So, if the number on the left hand side is greater than or equal to the number on the right hand side, then we have our answer.

I'll leave the rest for you to work out.

So, the way it works, is that it places the parity bits into the code and then sends the code. When the code reaches its destination, it then passes through a checker. If the code is okay, then all is well. However, if it comes out as having an error, it is then passed through a correction algorithm, which uses bit masking, to correct it. The following diagram hopefully helps explain it:

Now, when setting the parity bits, they are placed into the parts of the code that represents powers of 2, ie 1,2,4,8 and so forth, and they cover the parts of the code that will be set to one. As with the example below, we will use the ASCII character P.

If you find this confusing, don't worry, you aren't alone because quite a lot of students were baffled by this. However, if you go back to your binary numbers, you can easily see the pattern. For the first bit, where there is a 1, it is covered, some for the second, and so on.

Now, the way it works is that the parity is set to even or odd. If it is even then when the code reaches the destination there should be an even number of 1s. if there isn't, then obviously there was an error and the code will need to be discarded. The same if the parity is set to odd - if there is an odd number then it is okay, if it is even then it isn't.

So, using an even parity, which means that each of the parity bits must make the bits that they cover even, will be 10100000010. Converting it into hexadecimal, it will be 502.

Now, the next step is how they are detected, and corrected. Each of the parity bits checks to see whether it is an even parity, that is whether it has an even number of 1s. Now, if there is an even number, then it is correct, however, if there is an odd number, then it is incorrect. So, what it does is that it compares the entries to the correct ones and if the parity above is correct, then that one is correct. This is done until the error is isolated. Here we will flip one of the bits to show how it is done:

Hopefully the colours help. So, what we have done is checked each of the rows and made sure that the parity is correct. This is not the case in row P3. So we then check each of the columns. Now, if one of the corresponding rows is correct, it means that the column is correct, so we move on to the next one until we get to a column where the corresponding rows is incorrect. Now, if one of the rows is correct, then the entire column is correct. In the above example, we have narrowed it down to column four, which is where the error lies.

Let us try it with two bits and see what happens:

Oh dear, now we have a bit of a problem. Where is the error? Is it in bit 1, 2, or 3. We know that there is an error, we just don't know where it lies. Is there a solution, other than the fact that we can simply assume that double bit errors are so rare we don't have to worry about them. Well, not quite.

The Magic of SECDED

Well, it isn't all that magical, but what it stands for is Single Error Correction, Double Error Detection. Well, the above one detected more than one error, but it happens to be a little bit more specific than that. It also came down to where I selected the error. If I had selected the error elsewhere, then we might have more than three possibilities. It tells us that there is an error, but not how many, or where. With SECDED, we can detect a double bit error, and correct a single bit error. We do this by adding a further column, called the parity column.

Basically, if the parity column says that there is an error, then it is likely to be a single bit error, and can be corrected as normal. However, if the parity column says that there is no error, but the code that comes across says that there is an error, then the indication is that it is a double bit error. 

Now, the parity covers all of the bits, so setting it to either 0 or 1 depends on whether it will make the overall bits even or odd (something that wasn't of a concern with the original).

Let us look at an example below:

Now, this is slightly different, because we have been told by the parity bit that there is an error, and it could be either in P1 or P4. So, we do a little arithmetic, being P0+P4+P1 = P5, which means the error is in row 5, so we flip it. Now, consider if the error is in bit 11. That would flag the parity bit, P1, P2, and P8. Doing our arithmetic, it would be P0+P1+P2+P8 which is, surprise, surprise, 11. So we flip that.

Now what if there are two errors? Lets try it.

Well, the parity says that everything is okay, but once we get to row P2 we are told that there is an error. It fingers column 2, but I can assure you that this isn't where the error is located. As such, we know that there are two errors, so this is discarded and resent.

How Common?

Well, not very, and not so much with the CPU. However, with the memory it is a little more problematic, so this is why they actually come with error correcting capacity. However, when I say problematic, I really mean very, very unlikely. Though considering how fast computers run these days, they probably happen a lot more often than we expect.

Creative Commons Licence

SECED - Fixing Up the Errors by David Alfred Sarkies is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. This license only applies to the text and any image that is within the public domain. Any images or videos that are the subject of copyright are not covered by this license. Use of these images are for illustrative purposes only are are not intended to assert ownership. If you wish to use this work commercially please feel free to contact me