Categories
software

Numerical Step Function in Python

The classic range() (and in 2.* series, xrange()) is useful for getting an iterator of numbers. Its full signature is: range(start, stop[, step]).

So you can do, e.g., range(5, 10) = [5, 6, 7, 8, 9].

Or you can do, e.g., range(6, 13, 3) = [6, 9, 12].

But as far as I know there’s not an easy, built-in way to iterate over a range-like set of integers defined both by the range and a number of parts desired.

An example: you want five evenly-distributed numbers starting with 1 and ending with 10. So something like [3, 5, 6, 8, 10].

In my case, I had two similar use-cases. The first was the example above: a semi-arbitrary set of values in a range. I didn’t need to strictly include the endpoints in the values, but wanted a decent distribution of the values between start and end.

The second case was a little different, in that I wanted the range to always include the ends (it was a case of covering a whole range), but I also wanted to know how much each “step” over the range amounted to.

In the naïve version of this case, you don’t need the magnitude, as you could cheat and throw an extra piece in to account for slight differences (e.g., 11 / 3 => 1, 4, 7, 10 with the last piece being 10 through 11).

But there’s a nice way to evenly distribute the extra pieces: using rounding of the fractional value to distribute the extras.

Example:

10 / 4 = 2.5
0 * 2.5 = 0.0
1 * 2.5 = 2.5; round(2.5) = 2
2 * 2.5 = 5.0
3 * 2.5 = 7.5; round(7.5) = 8
[0, 2, 5, 8]

(In Python, round(number[, ndigits]) of n.5 goes to the even side (when using ndigits=0 or with a single argument).)

In this case, the caller could buffer the previous value and calculate the gap/step itself, but this is Python, so we might as well give it a mode to get that itself.

Without further ado, this is what I came up with:

def equal_parts(start, end, parts, include_step=False):
    part_size = (end - start) / float(parts)
    for i in range(parts):
        part = start + round(part_size * i)
        step = start + round(part_size * (i + 1)) - part
        if include_step:
            yield (part, step)
        else:
            yield chunk

It’s messier than it needs to be, due to its dual-use nature. It’s arguably cleaner to have a second function that would handle the include_step=False case:

def equal_parts_only(start, end, parts):
    for part, step in equal_parts(start, end, parts):
        yield step + part

That function would remove the conditional business at the end of the original equal_parts:

def equal_parts(start, end, parts):
    part_size = (end - start) / float(parts)
    for i in range(parts):
        part = start + round(part_size * i)
        step = start + round(part_size * (i + 1)) - part
        yield (part, step)

In the stepless version, it’s got another nice property: what if you do equal_parts(0, 10, 11)? You get: [1, 2, 3, 4, 5, 5, 6, 7, 8, 9, 10]. That’s a nice property: getting more parts than integers in the range.

I wrote a GIMP plugin to create stepped (or random) gaussian blurs on an image. The stepless version lets me create the set of blur levels, while the step-including version lets me properly select (mostly-)even parts of the image.

Here’s an image that used this plugin containing a dual use of this function: Sample image of gaussian blur in sections

If anyone wants a copy of the plugin, let me know and I’ll put it on Github or such.

Categories
software

Future Software

Occasionally you read interesting ideas for the future of software. Here are a few to ponder.

docopt

docopt is basically a domain-specific language. The language is the standard Usage output of a command-line program. By simply documenting a program’s usage, it aims to provide the functionality of parsing the program’s invocation.

This is a great step forward in finding ways to reduce duplicated effort in an elegant way. Before, you might programmatically add or modify the argument handler, and that might generate the Usage. But it was still tedious, as it required keeping what was a messy bit of code as clean as you could. Messy because you had to do a lot of thinking about the basic form of your command line API, and then translate it to code.

Instead, with docopt you should be able to purely focus on the form of the Usage.

I think that this will be a common theme for future computing, without relying on more complex systems like SOAP.

Why do we need modules at all?

Erlang.org: Erlang-Questions: 24 May 2011: Joe Armstrong: Why do we need modules at all? was an interesting post I remember reading a few years back. It questions the basic assumption of building software hierarchically and statically.

This is akin to the age-old (at least since birth of UNIX) desire to have programming be a set of pipes thrown together at will, with the elegance and wisdom of a seasoned hacker behind it.

What it really seems to suggest though is a move toward a way to let computers program themselves. The desire to let evolution play a key and direct role in how a computing system operates. If some given function is replaced by a more efficient function, all software depending can be faster. If you have some chain of functions A->B->...->ZZ, and someone writes a better chain, the whole can be replaced.

We already get some of this with packages/modules and dynamic linking, so the question (short-/mid-term) is really whether a kind of function-level alternative would replace modules/packages, or work alongside them.

Why do we need GUIs at all?

This is a spin on the previous. It’s the basic question of whether larger elements of the GUI can be easily reused. At present the basic unit of the GUI is the widget. The widget is some semi-small piece of the GUI, like a button or a text input.

If you want a more complex GUI, it’s a matter of assembling widgets together. This is equally true for a native application as it is for a webpage or web application.

Reuse is dependent upon some human brain recognizing the opportunity, and wiring the whole thing up for reuse. That’s opposed to something like the hypothetical functions database above, which in theory would have enough metadata to be able to say, “takes in a list, outputs a sorted list, stable, memory use, complexity.”

But if you can do it with functions (which seems likely enough), you can do it with larger pieces, including GUIs. So you can have a GUI that’s designed separately from the consuming code, and it can say, “presents a list, allows reordering, sorting, adding, deleting,” and you might specify some constraints on the adding/editing portion, so it could select another GUI component (“unique (name, number) pair”, or “unique name, non-unique number pair”, or whatever).

The initial versions of this can probably be written off of docopt, where by the same magic of parsing Usage a GUI could be created for any command line API. This is a project I’ve been meaning to work on, but haven’t done it yet.

Common theme

The common idea is reducing duplication of work, increasing productivity, removing friction to create. Making the computer figure out more of the work. Automating more. Instead of having to spend so much time doing analysis of tradeoffs and pondering why something broke when it shouldn’t, we should be building more.

That leads to the last one: moving away from pure-text programming. That doesn’t mean we write it out to binary; the text layer can persist. But it does mean that to some extent we stop doing everything as text. We can already extract interaction diagrams from text, but we currently do the editing in text and only get the diagrams when we want a conceptual view.

It will take some time before we see these last sorts of changes take place. But it’s likely that they will, if for no other reason than the benefits are there. I’d rather write the Usage once and know everything was wired up for me, just like I’d rather not muck about with every last bit of CSS and markup every time I want to add something to an application.

And as fun as it is to find the extra comma and find out that I wrote it correctly except for that typo, I’d rather that footgun go away entirely.

Categories
society

Learning to Compute

Some well-known person in the software community wrote about why, I don’t know, mere mortals?, shouldn’t learn to write software.

To be honest I didn’t read it. Any time someone says that I shouldn’t do something for any non-scientific or non-moral reason, I add another check to the column for “this maybe should be done.”

I skimmed several of the thoughtful rebuttals on other blogs, and think their general consensus is valuable, which is basically, “yes, you should learn to write software, because it’s awesome.”

Anyway, this isn’t about whether you should or shouldn’t, can or can’t, will or won’t. This is about doing the actual bit that’s being discussed abstractly.

Let’s assume for the sake of argument that you are using Firefox and viewing this site in the browser. Let’s assume it’s on a non-mobile Operating System with a keyboard and other fancy stuff like a screen.

Let’s assume you were to press the key combination Ctrl+Shift+K (Hey! Wait a damn minute there. Don’t press stuff without finding out what it does!) or go to the Firefox menu, to Web Developer and then to Web Console (which is what the key command before does).

You should now see some slick little bit of chrome fall out of the sky above the website.

You should see that it has a text input area at the bottom. Click there. Type something like, alert("Boo!"); and press Enter. Stop! Why are you typing stuff in before you know what it does?

Okay, to be fair, I type stuff in without knowing exactly what it will do, and aside from some wizards, most people who write software do this. But we know almost exactly, and we’ve got experience: think of it like cooking. A master chef can imagine how a recipe will taste just by reading it. Experience works like that, though even the experienced can be mistaken.

So before you type something, you should stop and think about what it might do, and what you want it to do. alert, that might make lights flash and buzzers sound. But it has those parentheses around the quoted bit.

Maybe it creates some kind of alert using that quoted part.

Go ahead and try it.

Right! A happy little alert box pops up with the text Boo!.

So why does that work? Think of it like cooking, again. The baker doesn’t just reach into the oven and pull out a pie. Each piece had to be made, including the pie tin (which was beyond the scope of the baker’s activity). In this case, think of the alert() bit as the pie tin. The makers of the browser gave you the pie tin and said, “fill it with what you need to fill it.”

If you think about it, the parentheses almost look like a pie tin. Are you hungry yet?

So let’s do something a bit simpler this time. Just type 1 + 1 and press Enter. Right, good thought, we have to ask what it might do. Well, if I wrote it down on paper and handed it to you, what would you probably say? Yes, you would say, “two.” That’s what the console will say back to you:

[13:25:34.419] 1 + 1
[13:25:34.423] 2

That bit there is taken directly from the console. If you select lines in it and then copy them, it puts the fancy timestamps in front. Those help you understand the behavior of more complex programs by letting you know what times the output corresponded to, how long things took (by seeing the difference in the times), etc.

Okay, one more thing to try for today. Start typing document, but just the d at first. Notice it gives you a handy drop-down of possible matches. You can use the up and down cursor keys to go through that list, or click on one with the mouse. If you keep typing, once it has a plausible match it will ghost-in the rest of the word for you. Once that happens, you can press the Tab button to complete the word.

Once you have document, put a . after it, and then type getElementById. You may have noticed that there were other getElement* bits, and some other things too. I hope you noticed, that’s the main skill to work on as a programmer: seeing all the details and wondering why.

Later on, if you want to keep learning about programming, you might go back to the web console (Ctrl+Shift+K) and just start typing things (don’t press Enter, just type say, c and see what pops up in the list). Ask yourself what they might do, and then use a search engine to ask the web what they actually do.

Okay, back on track: document.getElementById(???) What do we need to replace the ??? with? You’ll see the so-called “CamelCase” names in software a bit, so get used to mentally putting spaces in: get Element By Id. Right, if we hand it the Id, it will hand us the Element.

Let’s use one I know: site-title. That’s the id for the HTML element containing the blog title up top. So let’s do something with that.

We can do this two different ways. One way is to store the element we get back, and then speak about that, the other way is to do it directly.

The first way is to give the Element a name. To do this we can type var titleElement = document.getElementById('site-title'); and press Enter. We type var first, because we want it to be a regular variable. This has to do with scoping rules, which I won’t discuss here, but you will learn about if you keep growing your skill.

Once we have it as a variable named titleElement (you could name it something else if you prefer), we can use the name to reference that Element.

Now we can type titleElement.style.backgroundColor = "black"; and press Enter. The style part means that you want to access the Element‘s style properties. The style.backgroundColor means you want to access the background color of the Element. And we’re setting it to the named color black.

Scroll up to the top and look at the result. The background around the blog title is now black!

It doesn’t look right, of course. The background was more of a white, so let’s try changing it back.

Press the up arrow, and it will show you the last thing you typed. You can navigate the input history in the console using the up and down keys.

Change black to white and press enter again. Oops, it’s not quite white, either. What do we type to get it back the way it was?!

Let’s set it back the way it was, but let’s do it the other way I mentioned before: type document.getElementById('site-title').style.backgroundColor = "inherit"; and press Enter. Here we aren’t bothering to store the Element in a variable. We’re using it directly from the return of getElementById(). And we’re setting the color to inherit, which means “whatever the parent value is.”

The rules for Cascading Style Sheets are something you can learn about later, but you can think of it like cooking again. By default, a BLT sandwich has bacon, lettuce, and tomato. If someone wants a special one, then maybe its bltSandwich.style.bread = "pita", but normally it’s just whole-wheat. inherit just means, “whatever it would be for the environment it’s in.” (It means inherit the value from the parent, because elements in HTML are in a tree structure).

The main thing is that the color is back to normal!

That’s enough for now. You can close the console by clicking the x in the corner of it, or by pressing Ctrl+Shift+K again. If you make a live change while learning (live changes are those that you make to a webpage directly, such as by the Web Console), and you don’t know how to undo it, simply reloading the page should get you back to the default state.