Bry and Hanner and I took the car through the wash today.
I've always loved it since I was small: I was fascinated with the whirling brushes, the track that drags your car; every part of the squeaky clean, shiny automated washing process.
So we laughed at the whooshing brushes and we bonded and the car was cleaned. Then I ran over a dead rabbit on the way out.
20 June 2010
9 June 2010
Transcribed some Silly Wizards banter
Andy Stewart: "Thanks very much indeed. Och well, you're not as tough as you thought!
I'm gonna sing you a maybe a different kind of a song. It's not really a love song as such, maybe it is, I dunno."
John Cunningham: "It's kinda, it's like a lust song."
Andy Stewart: "That was Johnny Cunningham there. You'll eh... you'll hear a lot more of him before the night is out, no doubt.
The song we're gonna sing you right now is, eh, a song from the North of Ireland, and it tells the story about how a young girl decides one day she's gonna go out on a nice, well, one evening infact, she's gonna go out on a nice summers evening and take a walk, down beside the river Bann.
And um, the first time I heard this song, I thought to myself: now, if this woman has heard any of the other five hundred songs that are all called 'The Banks of the Bann', and she's still going down there, then she's out of her mind, because there's always some young cad there. You know sorta cutting around and there's always a bit of misbehaviour (well, quite a lot of misbehaviour actually) and tears and recriminations and maybe a kid involved somewhere or...
It's an age old story but distressing nonetheless. You know, that's how all these songs tend to go and I just couldn't help thinking: there's tonnes of space, you can go anywhere you... you don't have to go down there. It's just not worth it."
Transcribed from the video: Silly Wizards Live - Willie Archer and the Banks of the Bann
I'm gonna sing you a maybe a different kind of a song. It's not really a love song as such, maybe it is, I dunno."
John Cunningham: "It's kinda, it's like a lust song."
Andy Stewart: "That was Johnny Cunningham there. You'll eh... you'll hear a lot more of him before the night is out, no doubt.
The song we're gonna sing you right now is, eh, a song from the North of Ireland, and it tells the story about how a young girl decides one day she's gonna go out on a nice, well, one evening infact, she's gonna go out on a nice summers evening and take a walk, down beside the river Bann.
And um, the first time I heard this song, I thought to myself: now, if this woman has heard any of the other five hundred songs that are all called 'The Banks of the Bann', and she's still going down there, then she's out of her mind, because there's always some young cad there. You know sorta cutting around and there's always a bit of misbehaviour (well, quite a lot of misbehaviour actually) and tears and recriminations and maybe a kid involved somewhere or...
It's an age old story but distressing nonetheless. You know, that's how all these songs tend to go and I just couldn't help thinking: there's tonnes of space, you can go anywhere you... you don't have to go down there. It's just not worth it."
Transcribed from the video: Silly Wizards Live - Willie Archer and the Banks of the Bann
28 May 2010
A circular ring of electrodes with a power gradient facing North
Lepht wants to know where North is. However, instead of buying a compass, she's decided to turn herself into one. What sort of self-respecting transhumanist wouldn't?
I have some tcheuchter friends who claim to always know the direction of North, but that may just be because they've never left the Moray coast.
This post starts with some further ideas for making Lepht's invention run smoothly, and ends with edited comments from Lephts original post, in order to provide a record for them. If you have no freaking idea what I'm talking about, then it may be an idea to start reading from below the horizontal rule. Otherwise: onwards!
If you are going to have some sort of gradient, it may be wise to write a small program which would allow you to see graphically the power output at each electrode.
Otherwise, you might end up with all sorts of problems. For example, using my solution you might find that too many electrodes are powered on, which doesn't really indicate north very well. You might want to vary the steepness of the parabola by multiplying the quadratic term by a constant. The effect of this would be that electrodes further from North may receive more or less power.
Writing a small program would allow you to experiment with the variables, until you find something nice, a comfortable time before lots of blood is involved.
That's my thoughts at least.
The rest of this post is derived from comments on Lepht's blog, though it isn't a rip-off - I wanted to summarise the thoughts we had so far in its own blog post, so that anyone who wanted to see what we were thinking could do so without looking through comments.
Lepht proposed the following Microcontroller code:
while (poweron)
get north direction from compass module;
cast to a degree out of 360;
figure out which electrode's "domain" that number falls into;
activate that electrode;
However Max had an idea for improvement:
"the whole thing could be a lot better if you could get it to produce a gradient of current between electrodes, so that when north is between two electrodes, you have both firing at half power instead of the signal snapping to one of them."
My comment was a proposed solution:
The sort of function we might use may be a quadratic with a parabolic graph.
y = P - (x - n)^2
Here P is the maximum power, n is north's angle round the leg, and x is the electrodes angle round the leg. y is the power of the electrode at position x.
This graph has a maximum at (n, P) which is what we're looking for.
That then might be a suitable function. y is the power of an electrode at the angle x round your leg. Or in (untested) C
I have some tcheuchter friends who claim to always know the direction of North, but that may just be because they've never left the Moray coast.
This post starts with some further ideas for making Lepht's invention run smoothly, and ends with edited comments from Lephts original post, in order to provide a record for them. If you have no freaking idea what I'm talking about, then it may be an idea to start reading from below the horizontal rule. Otherwise: onwards!
If you are going to have some sort of gradient, it may be wise to write a small program which would allow you to see graphically the power output at each electrode.
Otherwise, you might end up with all sorts of problems. For example, using my solution you might find that too many electrodes are powered on, which doesn't really indicate north very well. You might want to vary the steepness of the parabola by multiplying the quadratic term by a constant. The effect of this would be that electrodes further from North may receive more or less power.
Writing a small program would allow you to experiment with the variables, until you find something nice, a comfortable time before lots of blood is involved.
That's my thoughts at least.
The rest of this post is derived from comments on Lepht's blog, though it isn't a rip-off - I wanted to summarise the thoughts we had so far in its own blog post, so that anyone who wanted to see what we were thinking could do so without looking through comments.
Lepht proposed the following Microcontroller code:
while (poweron)
get north direction from compass module;
cast to a degree out of 360;
figure out which electrode's "domain" that number falls into;
activate that electrode;
However Max had an idea for improvement:
"the whole thing could be a lot better if you could get it to produce a gradient of current between electrodes, so that when north is between two electrodes, you have both firing at half power instead of the signal snapping to one of them."
My comment was a proposed solution:
The sort of function we might use may be a quadratic with a parabolic graph.
y = P - (x - n)^2
Here P is the maximum power, n is north's angle round the leg, and x is the electrodes angle round the leg. y is the power of the electrode at position x.
This graph has a maximum at (n, P) which is what we're looking for.
That then might be a suitable function. y is the power of an electrode at the angle x round your leg. Or in (untested) C
/* Return the power of an electrode at the angle round your leg 'theta', given that the direction North is at the angle round your leg 'north', and the max power to be emitted by an electrode is 'power' */
float electrode_power(float theta, float north, float power)
{
return power - (theta - north)^2;
}
float electrode_power(float theta, float north, float power)
{
return power - (theta - north)^2;
}
8 April 2010
Agilish programming and haskell type classes
I'm drinking a lovely bottle of wine. So time to write a little about a little programming technique.
By agilish I'm referring to no specific agile development platforms, but to the general idea of "Shall we plan everything out first? Bloody hell no, let's get cracking! Also lets value individuals over processes and stuff *hic*".
An important aspect of some agile development methodologies is to immediately implement what the customer things is most important: these styles encourage the developers simply to work out what the most important feature is (features being stuff the customer can actually see doing something useful, 'seeing' being the important thing), implement it and then repeat: for small projects this is good!
However the relative lack of planning can cause problems:
So say you're an object oriented programmer implementing a GUI library, one feature after another. This is a class that you might provide for a widget*:
class Widget:
Hi! I'm a class providing a widget. Clicking me executes method clicked!
method add:
Hello there, this is what happens when I'm added to the window!
method clicked:
Hello there, I'm what clicking me does!
* if you don't study design patterns that is, but this is beside my point
And then you implement some GUI programs until you realize you need to be able to remove widgets for another particular program, so you alter your code:
class Widget:
Hi! I'm a class providing a widget. Clicking me executes method cliked!
method add:
Hello there, this is what happens when I'm added to the window!
method clicked:
Hello there, I'm what clicking me does!
method remove:
Hello there, I've been removed!
To do this they modified existing code which you may also introduce errors into the previously good code (like cliked). Even a syntactic error wastes development time.
I mentioned design patterns above: relying on the work of others (especially for basic examples like this) is very important, but you're always going to encounter new problems, or even old ones you don't recognize. What you need to do is have a more supportive paradigm for your 'add features one at a time when they are directly required!' style of coding. Enter type classes.
First, for the uninitiated, a little explanation. Type classes describe a selection of functions which can be performed on a data type. They are a little like java interfaces, except they can contain code. Similarly, they are like C++ virtual classes, but Haskell, not being an object oriented language has no receiver.
Importantly, unlike Java interfaces, you can declare a Haskell data type to be an instance of a type class without having to alter the file containing the new instance.
Here is a definition of a simple, one function, type class
class Eq foo where
(==) :: foo -> foo -> Bool
This describes the class Eq (I call it Equality). The class has one parameter, foo. It provides one function (==) which takes two foos and 'returns' a a boolean True or False. The brackets surround (==) to show it is an infix function: eg 1 == 2, rather than (== 1 2).
I am not intending to write a Haskell tutorial; there are many good books and tutorials available; I'm just trying to provide enough information so uninformed readers might see the benefits of programming in this style, not necessarily in Haskell.
So! A style I prefer to use with type classes is to implement only one feature with each type class. For example, compared with the above we might get
class AddableWidget w where
-- Hello, I'm a widget that can be added
add_widget :: w -> IO () -- IO () indicates an input output may be performed during the function, the () shows that there is no result 'returned'.
-- I've been added to the GUI!
class ClickableWidget w where
-- Hello, I'm a widget that can be clicked
clicked :: (Int, Int) -> w -> IO ()
-- I've been clicked
You can keep these as part of one module, and then if you realize you need to remove your widgets then in another module you may add:
class RemoveableWidget w where
-- Hello, I'm a widget that can be removed
remove :: w -> IO ()
-- I've been removed
So you don't have to alter your existing code. That is something difficult to do with traditional strongly typed classes (difficult at least, without a bit of forethought which I am assuming has not taken place ;)
Not so difficult in ruby and smalltalk, with their open classes, however the differences between untyped and strongly typed languages are a whole other kettle of fish.
Maybe tomorrow I might provide an example of how to perform this with a strongly typed object oriented language.
Delve was meant to answer that question.... whenever will I get round to finishing it.
By agilish I'm referring to no specific agile development platforms, but to the general idea of "Shall we plan everything out first? Bloody hell no, let's get cracking! Also lets value individuals over processes and stuff *hic*".
An important aspect of some agile development methodologies is to immediately implement what the customer things is most important: these styles encourage the developers simply to work out what the most important feature is (features being stuff the customer can actually see doing something useful, 'seeing' being the important thing), implement it and then repeat: for small projects this is good!
However the relative lack of planning can cause problems:
So say you're an object oriented programmer implementing a GUI library, one feature after another. This is a class that you might provide for a widget*:
class Widget:
Hi! I'm a class providing a widget. Clicking me executes method clicked!
method add:
Hello there, this is what happens when I'm added to the window!
method clicked:
Hello there, I'm what clicking me does!
* if you don't study design patterns that is, but this is beside my point
And then you implement some GUI programs until you realize you need to be able to remove widgets for another particular program, so you alter your code:
class Widget:
Hi! I'm a class providing a widget. Clicking me executes method cliked!
method add:
Hello there, this is what happens when I'm added to the window!
method clicked:
Hello there, I'm what clicking me does!
method remove:
Hello there, I've been removed!
To do this they modified existing code which you may also introduce errors into the previously good code (like cliked). Even a syntactic error wastes development time.
I mentioned design patterns above: relying on the work of others (especially for basic examples like this) is very important, but you're always going to encounter new problems, or even old ones you don't recognize. What you need to do is have a more supportive paradigm for your 'add features one at a time when they are directly required!' style of coding. Enter type classes.
First, for the uninitiated, a little explanation. Type classes describe a selection of functions which can be performed on a data type. They are a little like java interfaces, except they can contain code. Similarly, they are like C++ virtual classes, but Haskell, not being an object oriented language has no receiver.
Importantly, unlike Java interfaces, you can declare a Haskell data type to be an instance of a type class without having to alter the file containing the new instance.
Here is a definition of a simple, one function, type class
class Eq foo where
(==) :: foo -> foo -> Bool
This describes the class Eq (I call it Equality). The class has one parameter, foo. It provides one function (==) which takes two foos and 'returns' a a boolean True or False. The brackets surround (==) to show it is an infix function: eg 1 == 2, rather than (== 1 2).
I am not intending to write a Haskell tutorial; there are many good books and tutorials available; I'm just trying to provide enough information so uninformed readers might see the benefits of programming in this style, not necessarily in Haskell.
So! A style I prefer to use with type classes is to implement only one feature with each type class. For example, compared with the above we might get
class AddableWidget w where
-- Hello, I'm a widget that can be added
add_widget :: w -> IO () -- IO () indicates an input output may be performed during the function, the () shows that there is no result 'returned'.
-- I've been added to the GUI!
class ClickableWidget w where
-- Hello, I'm a widget that can be clicked
clicked :: (Int, Int) -> w -> IO ()
-- I've been clicked
You can keep these as part of one module, and then if you realize you need to remove your widgets then in another module you may add:
class RemoveableWidget w where
-- Hello, I'm a widget that can be removed
remove :: w -> IO ()
-- I've been removed
So you don't have to alter your existing code. That is something difficult to do with traditional strongly typed classes (difficult at least, without a bit of forethought which I am assuming has not taken place ;)
Not so difficult in ruby and smalltalk, with their open classes, however the differences between untyped and strongly typed languages are a whole other kettle of fish.
Maybe tomorrow I might provide an example of how to perform this with a strongly typed object oriented language.
Delve was meant to answer that question.... whenever will I get round to finishing it.
4 April 2010
Increased university admission and utlitarianism: Why I really don't give two craps
Inspired by the the political probing of our beloved scumbaggav
On University degrees and utilitarianism: Utilitarianism demands that people be qualified to perform jobs, benefiting everyone, right?
Well, with the exception of engineering, most degrees are not vocational: they do not lead directly into a job.
For example this is a 'graduate' software engineering job, it demands a 2:2 degree (doesn't mention which subject) but ALSO commercial experience developing .NET languages. You must have more than just a degree to get this job.
Many other jobs are much more specific, some don't even require a degree but vast knowledge of a specific problem domain.
For one, I think being learned is important, and I'd be extremely happy if 50% of people could understand the weird comp sci or maths I tend to drone on about when pished.
However, asking me to care about increased Uni entrance is like asking me to care about the personal development of complete strangers. It's like asking me to care about a complete stranger studying Tai Chi. "Good on you bud! Wait, who are you?"
And we still can't find a fucking roofer for the workshop! I certainly don't have the roofing skills or tools, neither do any of my (pointedly) academic friends.
The best thing labour have done in terms of education is to boost the resources of vocational training places, like Moray college. They have a whole new technical building now where people can become mechanics and sparkies, which is good for the person with the skills, 'cus now they have a good job (likely to lead to being self-employed) and also their skills are actually useful to everyone else.
Clearly good for all.
PS: Ahhh, rants on one small issue
On University degrees and utilitarianism: Utilitarianism demands that people be qualified to perform jobs, benefiting everyone, right?
Well, with the exception of engineering, most degrees are not vocational: they do not lead directly into a job.
For example this is a 'graduate' software engineering job, it demands a 2:2 degree (doesn't mention which subject) but ALSO commercial experience developing .NET languages. You must have more than just a degree to get this job.
Many other jobs are much more specific, some don't even require a degree but vast knowledge of a specific problem domain.
For one, I think being learned is important, and I'd be extremely happy if 50% of people could understand the weird comp sci or maths I tend to drone on about when pished.
However, asking me to care about increased Uni entrance is like asking me to care about the personal development of complete strangers. It's like asking me to care about a complete stranger studying Tai Chi. "Good on you bud! Wait, who are you?"
And we still can't find a fucking roofer for the workshop! I certainly don't have the roofing skills or tools, neither do any of my (pointedly) academic friends.
The best thing labour have done in terms of education is to boost the resources of vocational training places, like Moray college. They have a whole new technical building now where people can become mechanics and sparkies, which is good for the person with the skills, 'cus now they have a good job (likely to lead to being self-employed) and also their skills are actually useful to everyone else.
Clearly good for all.
PS: Ahhh, rants on one small issue
18 March 2010
Religion must be stopped.
I'm starting the think religion is a major threat to our freedom in the UK. We no longer have free speech to criticize someone the grounds of their religions beliefs. To say someone is wrong for believing these dangerous superstitions which, (considering Al-qaeda...) is the source of terrorism and current fear, is religious intolerance and a 'hate crime'.
Obviously the government is ignorant of the real problem - that people still possess these ignorant and fatal beliefs. Christianity, Islam, Hinduism et al should hence be boycotted. I need to start printing leaflets and campaigning against the missionary scum who spread their lies, starting with the alpha course who attempt to corrupt students at Aberdeen university.
Obviously the government is ignorant of the real problem - that people still possess these ignorant and fatal beliefs. Christianity, Islam, Hinduism et al should hence be boycotted. I need to start printing leaflets and campaigning against the missionary scum who spread their lies, starting with the alpha course who attempt to corrupt students at Aberdeen university.
2 March 2010
dead server
My server is dead; my hosts, linuxvps.org are no more!
Someone tracked me down on facebook to ask about the Kolmogorov programming language; which surprised me!
Someone tracked me down on facebook to ask about the Kolmogorov programming language; which surprised me!
Subscribe to:
Posts (Atom)