Until now. Enter JSNote (Javascript Note). It works pretty much the same way that BibTeX does with LaTeX. You maintain a list of references in a separate file, and in your material you cite those references by means of calling a javascript function. For example;

// Filename /downloads/references.js
addRef ({name : "john",
year : "2012",
volume : "17",
author : "Charles Dodgeson",
title : "Obtuse Works of Mathematics in 'Alice in WonderLand'",
});
addRef ({name : "boehm_1",
year : "2006",
month: "May",
conference: "ICSE '06",
author : "Barry Boehm",
publisher: "ACM",
title : "A View of 20th and 21st Century Software Engineering",
});

And then, in your HTML you pull the jsnote.js script in, as well as your list of references and use them like so:

<script src="/downloads/jsnote.js"></script>
<script src="/downloads/references.js"></script>
<p>I now will reference Boehms article<script>cite ("boehm_1")</script>and then reference Johns article like this<script>cite ("john")</script></p>

<heading3>References</heading3>
<script>printRefs()</script>

The practical result is that the citations are all printed properly. The above example looks like this. Note that the list of references in reference.js works exactly like it would in BibTeX, namely that you can put the arguments in any order, or even leave some of them out if you don’t want them displayed. As long as each reference in the references list has a name, jsnote will be able to cite and display all the information you gave when adding it as a reference.

Literate Programming Is Not Dead Yet.

Get jsnote.js
Get a sample references file

For example, I’m writing code in ECL to call out to a few C libraries (that I’ve written myself). Valgrind is incompatible with ECL. In fact, it might just be incompatible with any GC-language. Whatever. I still need to keep accounting of my memory during testing.

Hence, I wrote this little replacement/wrapper for malloc. It stores all allocated memory as a list of blocks internally. It stores the filename, function and line number and the amount of memory that was allocated by each invocation of xmalloc. Usage is fairly standard:

int *foo = XMALLOC (sizeof *foo);
...
XMALLOC_FREE (foo);

Easy? You can look through the header for all the options (how to dump the list of blocks allocated, some general statistics on allocation, etc). Also, this can be turned off while the program is running, and normal malloc() is then used.

Enjoy.

Download the the xmalloc library

So, having “fixed” the compilation problems by means of removing the pcmcia functionality, I offer the updated drivers to the world. This iBurst USB modem driver will work under Ubuntu, Debian, Mint, Redhat, CentOS, slackware or anything else that has a linux kernel 2.6 and above (including kernel 3.0). Download it here.

Note that this is self-extracting script, so before running it make sure that it has execute permissions set. Please let me know if this does not work by emailing me the output of the executable. If it does work, then you can thank me in your will (of course, if you don’t own much, then just leave a comment here thanking me:)

Download iBurst USB Modem Linux driver

You can get a nice overview of the short stories over here at smashwords. Feel free to read, review and rate. They are free, after all, although this state of affairs is not going to last if I can manage to keep up the pace for another four  months.

Why four months? Well, in about four months I figure I’ll have enough to put together a collection into a single book, which will then go on sale. At the moment though, if you like science-fiction, OR, wicked mind-games, OR short humour, OR Zombie apocalypse tales, then head on over to the smashwords site, and read, review, rate.

I’m open to suggestions, by the way, so feel free to email me about any of the short stories.

The ovum is released  roughly 14 days into the womens monthly cycle. The sperm cells can survive for between 3 and 5 days. The ovum will be viable for only 24 hours (or less). Hence, intercourse must occur before ovulation, and ovulation must occur before the sperm cells all die.

Hence the fertile period  (the best time to make love in order to conceive a child) is during those 4- 6 days (sperm cells will survive for 3 – 5 days, and you can still make love on the 4th – 6th day when the ovum is descending the fallopian tube). It’s pretty easy to mark these days off on a calendar.

What most woman don’t realise is that not all fertile days are equally likely to result in a boy or a girl baby. Making love on certain days is more likely to result in a boy baby, and making love on other days is more likely to result in a girl baby. This is due to two particular characteristics of the sperm cells. For a more thorough explanation please see this document over here.

So, lets say you want a girl baby – how do you know which day will be the best to conceive a girl? Well, you can either use the Conception Fertility Calendar which will mark off the days that are better for conceiving a girl, and mark off those days that are better for conceiving a boy, or you can do the calculation manually and mark it off on a calendar yourself. Let me demonstrate.

First, figure out when your ovulation is due to occur. This is generally 14 days from the end of your cycle, so measure your cycles to get an accurate number (not all woman have a 28 day cycle), add that to the start date of your period and then subtract 14 days from that.

For example, if your cycle length is 26 days, and your period starts on the 2nd of the month, then add 26 to the 2nd, and you get 28th, then subtract 14 days from that, and you get the 14th of the month.

Now that you know when your ovulation will occur, you need to figure out when the fertile period starts. The start of the fertile period is simply the day of ovulation minus the lifespan of the sperm cells. So, if we assume that sperm cells will last for 3 days, then the start of the fertile period is … “the 14th (the day of ovulation) minus 3 days (the lifespan of the sperm cells)”, which works out to the 11th of the month.

This means that if you made love on the 11th, with a sperm lifespan of 3 days, they’ll all be dead  at the end of the day on the 13th, there will be no more sperm cells left on the 14th when the ovum is viable, therefore we have to add one more day so that the start of the fertile period works out to be the 12th.

To determine which of the days are better for a girl (or a boy) is a little more complicated:

• Do integer division on the fertile period by 2. In our case it is 4 (the total number of days you are fertile for) divided by 2, which is 2 with no remainder. Hence the first two days of the fertile period are better for a girl and the final two days are better for a boy.
• The above won’t work if the fertile period is an odd number – for example if the fertile period is 5, the results of the integer division is 2 with a remainder of 0.5. In this case mark the first two days of your calendar as fertile for a girl, the day after those as fertile for both boy or girl and the final two days as fertile for a boy.
• To determine the sperm lifespan, or to work out more accurately when ovulation will occur, I have some tips that you can follow.

Is all of that too much work to get a baby of the sex you want? I expect it is, but good news is here in the form of an Android application I wrote called (unsurprisingly) “The Conception Helper”.

For the price of a happy meal ($3.99) you can simply purchase an application for your cellphone that will do all this for you (and do it more accurately as well). I’ve written the Conception Helper for Android phones and tablets. Simply use it as directed and it will display a calendar for you each month with the relevant days indicated on it.

Further, even if you do not start it at all (after setting your start of period), when the relevant days come along,  it will warn you. No need to trust your memory to look at it at all. See the Conception Website  for more details.

And, there is also no need to take my word for it – there is a trial version that will work for 30 days – after 30 days you’ll have to pony up the cash to buy a copy, or simply redownload it to your phone again.

Download it, try it before you buy it, and if you are happy with it, then and only then spend your money on it. In the meantime, you can read the manual and see just how effective Conception can be.

The point of this, presumably, is to encourage African developers to develop for Android. The biggest motivation to do something is money, so participants are allowed to enter paid apps into the challange (under “Eligibility”). Sadly, it seems that the organisers of ADC spend very little time with the Google Checkout team, because Google checkout does not support many of the countries that are eligible for ADC/Africa, and there is no other way to get paid for apps in Google marketplace.

While I know that, sometimes, in large companies its a case of “the right hand not knowing what the left hand is doing”, in this case it seems even the left hand has only a very hazy notion as well. I’m working on porting my application to iPhone. Of course, the longer it takes for Google to get this working, the larger the number of ADC apps that get ported. It could be a case of Google simply giving app developers motivation to come up with a good concept that then goes to iPhone because the concept could not be sold for Android.

Heads up to Google: those devs that came up with a new, nifty and/or novel app will certainly not make it freely available for Android (not even as trial) if they can make it for money for iPhone. Making a trial version for Android simply means putting a good idea out there that some iPhone dev is going to implement on iPhone. To keep the first-mover advantage of a novel concept, the dev has to be the first one with the app. If it is so novel and nice, people would buy it from elsewhere.

Of course, its always possible that Apple also won’t allow devs from South Africa to sell applications either – with Apple you don’t get this information until after you pay their $99 fee, so if anyone knows if South African developers are allowed paid apps in Apples App Store, let me know.

I implemented the dynamic array by simply storing an array of void pointers, and only storing pointers to elements (a pointer to void can point to anything), hence this lets me have a dynamic array that can store elements of anything, even elements of different types (although this is a bad idea – unreadable code is not the goal!). You can download the code that implements this as a library.

The “array” is simply a struct like so:

struct rsarray_t {
   size_t alloc_len;   /* Store the number of allocations */
   size_t used_len;   /* Store the of cells we have thus far used */
   void **data;        /* The actual array of void pointers */
};

There are no new_array or create_array functions that the user must call. All the user has to call to append a pointer onto the end of the array is rsarray_ins_tail(array, element), where element is the new pointer to be appended to array, which is of type struct rsarray_t*.

If array is NULL, then an array is created and returned with element as the first and only element of the array (which is why there is no need for an “array_create” function). If array is not NULL, then the element is appended to the array using realloc if there is not enough space to store another element. Usage is dead-easy:

struct rsarray_t *array;
int a =0, b = 1, c = 2;
array = rsarray_ins_tail (NULL, &a);
array = rsarray_ins_tail (array, &b);
array = rsarray_ins_tail (array, &c);
/* array now contains pointers to a, b and c */

You may not always want to store many references to the variable, though. For example, at this point in the code we may need to modify the values of a, b and c and we don’t want those modifications to take effect on the values already stored in the array. To this end, I provide a function rsa_dup, which will make a duplicate of any object passed to it (with the size of the object specified by the user). The above code can then be written as:

int a = 0, b = 1, c = 2;
array = rsarray_ins_tail (NULL, rsa_dup (&a, sizeof a));
array = rsarray_ins_tail (array, rsa_dup (&b, sizeof b));
array = rsarray_ins_tail (array, rsa_dup (&c, sizeof c));
/* array now contains copies of a, b and c */
a = 42; /* Element 0 of array is still 0 */
/* Change the value of b */
*(int *)array->array[1] = 43;

The above is still a little dirty. The duplication of the variable in the insertion is bound to lead to problems, and the verbose semantics of accessing an element (seen in the last line) is simply unreadable. They can both be fixed with macros:

/* unsafe macro, 'x' should not have side-effects */
#define RSA_INS_TAIL(a,x) \
   rsarray_ins_tail (a, rsa_dup (&x, sizeof x))
#define RSA_INDEX(a,i,t)   \
   *(t *)a->data[i]
...
int a = 0, b = 1, c = 2;
array = RSA_INS_TAIL (NULL, a);
array = RSA_INS_TAIL (array, b);
array = RSA_INS_TAIL (array, c);
/* array now contains copies of a, b and c */
a = 42; /* Element 0 of array is still 0 */
/* Access the second element i.e. array[1] */
RSA_INDEX (array, 1, int) = 43;

All well and good, how do we iterate? Easy, again.

/* unsafe macro, 'x' should not have side-effects */
#define RSA_INS_TAIL(a,x) \
   rsarray_ins_tail (a, rsa_dup (&x, sizeof x))
#define RSA_INDEX(a,i,t)   \
   *(t *)a->data[i]
#define RSA_LENGTH(a)    \
   a->used_len
...
struct rsarray_t *array = NULL;
int i;
/* Insert ten elements into array */
for (i=0; i<10; i++) {
   array = RSA_INS_TAIL (array, i);
}
/* Change all the values stored in the array */
for (i=0; i<RSA_LENGTH; i++) {
    RSA_INDEX (array, i, int) = 42 + i;
}

Freeing is as simple as freeing each element (because you are certain that there are no other references to it – the memory was allocated when we appended elements using rsa_dup, so no other code should be sharing the pointer), so we can simply iterate over the array and free each of the void*. In fact, since iteration over the array is a common occurrence, we can just go ahead and create a function to do it for us, so that we never have to write the actual loop:

void rsarray_iterate (rsarray_t *a, void (*f) (void *))
{
   size_t i;
   for (i=0; iused_len; i++) {
      f (a->data[i]);
   }
}
...
struct rsarray_t * array = NULL;
[... here we append to the array ...]
/* Now we free each element */
rsarray_iterate (array, free);
/* Free the array that held all the elements */
free (array->array);
/* Free the structure that held the array */
free (array);

Because this isn’t rare either, we can put the above 3 lines into a function call (for example) rsarray_free (). Of course, once you’ve got that, you can use the resizable array to implement a host of other data structures. You can download the code that does this over here.

It was written about 8 years ago, and I’ve been using it every since (dynamic arrays are more useful than you think!). I go a lot further in the download above, as the download is actually written as a library, and uses the dynamic array as a basis to implement growable arrays, stacks and queues. Check the download for example usage, further avenues to explore, for example creating a ring-buffer, or implementing copy-construction so that composite datatypes consisting of pointers are sensibly copied when an insertion is made.

There are two types of gambling games:

1. Those that, even after the game has started, allows the player make decisions.
2. Those that, after the game has started, doesn’t allow the player any further decisions.

An example of the latter are slot machines – once you put your money in and hit the button, no further decisions from you can influence the outcome. Roulette is like this as well: once the dealer announces “no more bets”, you can only watch and hope that you will win.

An example of the former are games like poker, where even after you start the game, you can decide to draw more cards, bet more money or simply give up and lose whatever you already bet. Blackjack is also an example of a game that lets the player steer the outcome slightly – after you start the game, further actions taken by the player  can cause a win or loss.

Enter Blackjack

I’m not going to give a full treatment of the rules of blackjack (which, at any rate, differ from casino to casino) nor the theory behind it in a tiny blog post. I’m just going to point out that there are some actions that the player should take in certain conditions that provide the best possible chance that the player will win.

As an example, lets say the dealers face-up card is a five, and the players two cards are a pair of aces. In this situation, the best odds for the player are to split the aces. Or if the dealers face-up card is a nine while the player has an ace and an eight, then the best course of action would be for the player to stand.^[1]

The rules are simple (although they differ slightly based on what the different casinos allow), but they are horribly difficult to remember, especially when the test involves going to a casino and playing for money! Luckily, your blogging friend has some assistance in this regard. I’ve written a simple online blackjack training program. You play blackjack, and it tells you whenever you make a choice that is sub-optimal.

Unlike other blackjack programs which even do your counting for you, this program tries to make you do all your own work, hence you should be prepared once you hit the casino for real.

Note that it is still slightly incomplete – I need to implement “splitting” – but the advice is given, and the game maintains a bankroll for the player, and the player can hit/stand/double/surrender. As usual, let me know if this is useful to you; it’s hardly worth my time to implement the “splitting” if no one is using this program.

^[1]Note that I’m ignoring the issue of insurance. Insurance is a suckers bet, and should be only taken if you have been keeping accurate count of the cards going past. But if you’ve been keeping accurate count of the cards going past, you won’t need the insurance anyway. So don’t take it. Ever.

Hence, in South Africa, our prisons are run by the department of Correctional Services (note the emphasis!), and not by the department of Revenge Meted Out Services. Most other countries follow something similar – the idea behind law and justice is to make society safer for everyone, and not to simply punish criminals, nor to use the system as a means of revenge. This brings to the fore the question “Is capital punishment a significant enough deterrent to capital crimes?”. In other words, does having and handing out the death penalty frighten criminals into not becoming criminals?

There are basically two sides to this (I’m only going to mention both, not argue them):

1. The death penalty does reduce crime.
2. The death penalty has no effect on crime.

A number of arguments in support of either side eventually makes it way around the papers (via the “letters to the editor” section), with the most visible ones being:

1. Criminals are afraid to commit crime if they think they will be killed if caught, hence crime rates drop.
2. Criminals think they won’t get caught (which is why they commit in the first place), hence have no fear of the death penalty.
3. A person who is terminated by the state would not get another opportunity to kill again.
4. A death penalty may actually raise the number of actual murders, as then criminals will have to ensure that all witnesses (for example a rape victim) are killed. With no death penalty a witness or two may survive.
5. Criminals are more likely to snitch on their accomplices when caught if there is a possibility that their sentence would be reduced from “death” to “life imprisonment”.

Now I’m pretty certain that murderers don’t typically complete a course in statistics, so I decided to look it up for myself. Luckily, there are some countries that have and routinely hand out the death penalty, and some countries that don’t. So if there was a relationship between handing out the death penalty and crime rates (whether a positive or a negative one), we should be able to tell.^[1]

In other words, the list of the safest countries should contain more death-penalty countries in the list, than a list of most dangerous countries if the death penalty were to make the society safer. The corollary (that the list of countries that hand out the death penalty should contain more countries that are safer) is a topic for a new blog post sometime next week.

So, we know what to expect: that the list of safest countries should contain less death-penalty-countries, and that the list of most dangerous countries should contain fewer death-penalty-countries. Lets actually check the both lists and see.

Note that I got the data on homicide rates from here, and the list of countries that hand out death-penalty sentences from over here

Lets start by looking at top ten the countries with the highest rates of crime. Lets check how many of them have the death penalty.

It seems, of the most dangerous countries, that four of them hand out the death penalty, and six of them don’t.

How about the top ten safest countries (i.e. those with the least crime)? How many of them have the death penalty?

Hmm … it seems that this weeks  question is answered – the death penalty makes no difference to the top ten most dangerous or safest countries.

But is this actually truly reflective of reality for those countries that are not in the extremes? Perhaps we should rather check all the countries to see, on average, which are safer to live in – the death-penalty-countries or the non-death-penalty countries.

Check back next week for the answer to the question “On average, do the countries with more crime hand out the death penalty? Is there a relationship between the crime rate and capital punishment?”

(To Be Continued …)

Footnotes
[1] As the death penalty is only handed out for actual murder, I use the word “crime” to mean “homicide”. Not even the most ardent death penalty supporter would expect the death penalty to be handed out for shoplifting, hence there is no need to look at shoplifting statistics to see if they correlate with death penalty.

See the preliminary data gathered.

Many of the torrents being uploaded to popular sites are actually fake. Very many of the comments by the users of such sites express anger and dismay that there are people out there who seed fake torrents (ironic, since these same users are infringing copyright by downloading the torrent).

For the most part, as far as I can tell when surfing the torrent search sites (purely in the spirit of scientific enquiry, you understand), the fakes are simply files that can be read with only a single video player, and the fake videos display nothing but a message informing the viewer where the video player can be purchased. In other words, the torrents are spam, but you can’t tell that until you’ve exhausted your entire bandwidth downloading this fake file.

As there is a financial incentive for these companies to keep their torrents highly visible, it’s obvious that they are the ones seeding the fakes, hence you see the latest Hollywood movie for download with approximately 13000 seeds and a few thousand leeches, you assume that the torrent must be legit because:

1. Surely there cannot be 13000 people are are seeding a fake file, and,
2. Even if 13000 people are silly enough to do this, surely the few thousand leeches must mean that the torrent is legit.

Sadly that is not the case – a botnet can easily exceed 13000 computers, and the spammers behind this obviously know that they need to leech off the seeders or else the downloaders will get suspicious. Hence the spammers will both seed and leech at the same time. If this is the case, then they obviously will prefer to leech as little as possible to save what they can of their bandwidth to allow their victims to download.

Since I figured that they would have a set percentage of their botnet as leeches, I gathered a little data from isohunt – see the above-mentioned pdf file for the actual data. My conclusions?

1. With the exception of a single torrent, all of the negatively rated torrents (i.e. the fakes) had leeches that were not more than 28% of the seeders.
2. With the exception of a single torrent, all of the positively rated torrents (i.e. legit torrents) had leeches that were not less than 30% of the seeders.

The outliers are statistically expected – some of the fakes will have actual people downloading (taking the percentage of leeches higher) while some of the legit torrents will have more people downloading than seeding anyway (taking the percentage down).

So, in order to determine a torrents legitimacy for seeds of 10k or more, you can rely on the percentage of leeches as being roughly indicative of it’s legitimacy. In other words, any torrent which has a ratio of seeders:leechers that is around  10:3 is probably a fake.

I also note that the sample size (98 torrents ordered by number of seeds) is a little small, while the sampling (all from the Video/Movie category) is not random at all to draw firm conclusions from. The only really safe conclusion one should draw from this result is that it indicates that further research might be useful.