Three easy ways to avoid off-by-one errors in your software

Here's how to avoid one of the commonest software bugs

If you're in the software business you've probably encountered the dreaded 'off-by-one' error.

An off-by-one error often occurs when an iterative loop iterates one time too many or too few. Someone might use "is less than or equal to" where "is less than" should have been used.

It's also easy to forget that a sequence starts at zero rather than one. To put it another way, we sometimes fail to distinguish between a count (how many are there?) and an offset (how far is that from here?)

Ten gaps in eleven posts

These problems aren't unique to programming.

At the time of the last millennium, there was a lot of discussion as to whether it should have been celebrated on 1st January 2000 or 2001.

In debates about the millennium off-by-one errors may not be too serious. In software they can be fatal.

How can you avoid them?

Here are three techniques which help. I'll save the best till last.

Do manual tests

If you've got a bit of code that is looping or indexing, do some manual tests to check it's doing the right thing. If you're using a language with a REPL, like Python, Ruby, Clojure or APL, you can do the test in no time at all.

Test the boundary conditions. What happens if the loop shouldn't be traversed at all, or if the array you're iterating through has no elements?

 

Do automated tests

Even better, use an automated testing framework like junit, pytest or its equivalent for your language.

Make sure you write tests that check normal operation and operation at the boundary.

 

Prevention is better than cure

If you can, use a language construct or language that eliminates the need to loop.

In Java, Python or Ruby you can use a for-loop to operate on each element of an array. In Python or Ruby you can use generators to lazily collect the results of operating on the elements.

Many other languages now have similar features. And of course, in APL it's very rare to need explicit loops.

Want to add together two APL arrays?

Just type a←b+c

and there's not a loop in sight!

 

Loop-free code is safer 

If the idea of writing loop-free code appeals, take a look at my introduction to APL. It's incomplete, but free for the next few days, and if you 'buy' it you'll get free updates as further sections of the book appear.

Get it here.

Learn APL on the $5 Raspberry Pi

APL is one of the most productive programming languages ever invented, and it's available free on all models of the Raspberry Pi.

I've just launched an early access version of an Introductory eBook, and it's free for the next seven days.

You should read this book if you want to
• find out what programming in APL is like
• learn how to use the language effectively
• decide if APL is appropriate for your project
• take part in the Dyalog annual APL problem-solving competition

The fast-paced introductory text will teach you the core of the language in a few short, fun sessions.

Once you've finished the book you'll get links to free resources you can use to master the rest of APL's amazing capabilities.

The book is only 30% complete at present, but if you 'buy' the free version now you'll pay nothing for the book, and you'll get free updates as soon as they are published.

I'll start to increase the price next Sunday, and it will continue to go up as the book nears completion.

So don't wait - click here to get it now!

A new/old approach to Parallel processing

Morten Kromberg of Dyalog APL has just published a video of his keynote from the PLDI 2016 ARRAY Workshop.

It's titled Notation for Parallel Thoughts and it describes some exciting innovations in the field of programming for parallel processing.

More reasons to enter the Dyalog Problem-solving competition

A few weeks ago I mentioned the Dyalog APL annual problem-solving competition.

I've been researching previous contests, and wanted to share my findings.

It's worth entering, even if you don't know APL.

Many of the previous winners learned APL just for the competition. They spent a few days learning the language, and a few more working on the contest problems. Some won top prizes (worth $2000 this year).

It's worth re-entering, even if you entered last year.

Many of the winners had applied before. Some even won prizes in successive years.

It's worth entering wherever you live.

Winners have come from all over the world.

It's worth entering even if you don't win.

I've taken this list of reasons from my forthcoming introduction to APL. (The book should be available in time to help you with your competition entries!)

5 good reasons to learn this powerful language

1. APL is concise and expressive, so you can try out new ideas very quickly.
2. APL is focused on arrays, so it will change the way you think about programming.
3. APL is challenging and fun, so it will stretch your mind.
4. The APL community is full of bright and helpful people, so you will expand your network of contacts.
5. The demand for APL developers exceeds the supply, so knowing APL can help you find a job.

 

Sign up today!

You can find out more about the competition on the Dyalog website.

Sign up today.

Help me with a book title and win a Raspberry Pi model 3!

I need a snappy title for a book.

The book is an introduction to the Dyalog implementation of theAPL programming language.

The book is aimed primarily at people learning it on the Raspberry Pi.

APL runs on all models of the Pi, including the £4/$5 Pi zero shown on the right.

You can download a copy of Dyalog APL for the Pi here.

If you submit a title as a comment, if you are the first to submit it, and if I use it, I will send you a Raspberry Pi model 3 complete with a power supply and an SD card.

No royalties, though, and you will need to find a monitor, keyboard and mouse.

If you have a Pi already I will send one to the beneficiary of your choice.

Pi3B - Image (c) the Raspberry Pi Foundation

The book is not yet complete but it should be available in early access format on Leanpub in a few days time.

Have a go - post your title below.

ANNSER - A Neural Network Simulator for Education and Research

I've just launched ANNSER on GitHub.

ANNSER stands for A Neural Network Simulator for Education and Research.

It is licensed under the MIT license, so it can be used for both Open Source and Commercial projects.

ANNSER is just a GitHub skeleton at the moment. I have some unreleased code which I will be committing over the next few days.

I'm hoping that ANNSER will eventually offer the same set of features as established ANN libraries like TensorFlow, Caffe and Torch, and I would like to see a GUI interface to the ANNSER DSL.

ANNSER will be implemented in Dyalog APL. The GUI will probably be implemented in JavaScript and run in a browser. All the code will run on the Raspberry Pi family, though you will be able to use other platforms if you wish.

There's a huge amount of work to complete the project but we should have a useful Iteration 1 within a few weeks.

Why APL?

I have several reasons for choosing APL as the main implementation language.

1. It's my favourite language. I love Python, and I've used it since the last millennium, but I find APL more expressive, performant and productive.
2. With APL you can run serious networks on the $5 Raspberry Pi zero. This makes it very attractive for educational users.
3. APL was created as a language for exposition.
4. APL is unrivalled in its handling of arrays, and ANN algorithms are naturally expressed as operations on arrays.

Consider the following code fragments. Each creates a random input vector, creates a matrix of random weights and then calculates the output of a sigmoid neuron.

Python version

import random
from math import exp


def random_vector(cols):
    return list([random.random() for i in range(cols)])

def random_vov(rows, cols):
    return list([random_vector(cols) for j in range(rows)])

def dot_product(v1, v2):
    return sum((a*b) for (a,b) in zip(v1, v2))

def inner_product(vov, v2):
    return list([dot_product(v1, v2) for v1 in vov])

def sigmoid(x):
    return 1.0/(1.0+exp(-x))

def sigmoid_neuron(vov, v2):
    return list([sigmoid(x) for x in inner_product(vov, v2)])


mat = random_vov(3, 4)
vec = random_vector(4)
print sigmoid_neuron(mat, vec)

numpy version

from numpy.ma import exp
from numpy.random import random
from numpy import array, inner


def random_vector(cols):
    return array([random() for i in range(cols)])


def random_mat(rows, cols):
    return array([random_vector(cols) for j in range(rows)])


def sigmoid(m, v):
    return 1,0+1.0/(1.0+exp(-inner(m,v)))

mat = random_mat(300, 400)
vec = random_vector(400)
s = sigmoid(mat, vec)

APL

mat ← 0.01×?3 4⍴100
vec ← 0.01×?4⍴100  
sn  ← {÷1+*-⍺+.×⍵}
mat sn vec

I know which I prefer :)

Contributing

If you think you might be interested in joining the ANNSER project, comment below or ping me at romilly dot cocking at gmail dot com

Mapping Kent Beck's Mind :)

If you don't work in Software you may never have heard of Kent Beck but he's had a huge influence on the way we test and write code.

Yesterday Kent posted a fascinating list on Facebook. He shared some of the key ideas that guide his thinking.

The post is interesting, and stimulating, but it's a wall of text. I love reading, but I also like to think visually, so I started to mind map what he wrote.

It's slowly growing.

The map source (made with Freeplane) and images are now on GitHub.

Kent suggested that this might be the basis of a workshop:

Seems like this could turn into a workshop pretty easily. Spend three days mapping your current ideas, figuring out the holes you want to fill, what you want to eliminate.

Three days sounds a lot, but maybe we could do a shorter version via a google hangout. Anyone interested? If so, please comment.