Patrick Roberts's Blog

Speech Interface over Cordless Phones

This circuit, connected to my sound card and a set of cordless phones, seems to be the cheapest way to talk with my computer wirelessly around the house.

The design is mostly from http://www.grynx.com/projects/build-your-own-chat-cord/ Improvements are welcome. The parts, especially the line isolation transformer, can be scavenged from a cordless phone. My local Goodwill sells them for $5. The microphone and speaker connections, at the right, are to those jacks in a sound card.

The 9V can come from a battery. That worked for me until I experimented with leaving a muted speakerphone on for hours. Now I use a 9V power supply. It caused a hum on the phones, but the capacitor and the resistor (the left one) filter it well enough.

I'm using a digital cordless phone but there's still noise. What are the likely causes? Wires too long? Lack of shielding?

Have you tried alternatives?

Bluetooth: Seems inconvenient to screw the ear piece into my ear every time I want to talk. Phones have speakerphone modes. Range? (I gather there are two classes of Bluetooth devices with different ranges.)
Walkie-talkies: I imagine these would have great range. Is there a common model that can be easily connected to a sound card? Would the computer have to press a button when it wants to talk?
Skype phones: More expensive. Is there a standard API?
Wired microphones & speakers in each room: Nice but expensive. Still would want a phone for the yard.
Robot that follows you around: Ideal, since it can carry sensors to know when to interrupt you, but very expensive. Phones would still be a good redundancy.
Any option missing?

Unfortunately, phones give the computer no easy way to indicate that it wants to talk. It could ring the phone, but that's a more complicated circuit - and annoying. Instead, when my computer has something it wants me to hear, it shows messages on the TVs.

Assembly Line Syntax

It's often convenient to imagine a process as a tree-shaped (or graph-shaped) assembly line. Inputs flow in through the leaves and are transformed, filtered or reduced where branches join. This well represents lazy-functional programming. Say one wants the words from a line-delimited file, excluding acronyms, then converted to lower case and stored in a set for quick lookup. Compare syntaxes...

English:

Get every line in file words.
Skip empty lines.
Strip white space.
Filter out words that have every letter capitalized.
Covert each word to lowercase.
Add to the set.

Procedural:

words = set()
for line in file('words'):
    line = line.strip()
    if line and not line.isupper():
        words.add(line.lower())

Variables describe edges in a graph, connecting parts of code, but without being obvious to the eye. Names are boring to create and are often misspelled.

Lazy-functional using standard Python:

set(imap(str.lower, ifilterfalse(lambda w: w.isupper(), ifilter(None, imap(str.strip, file('words'))))))

Lazy using a Python iterator comprehension:

set(line.strip().lower() for line in file('words') if line.strip() and not line.isupper())

This wastes time on a second strip() call.

Lazy-functional mixed with a Python iterator comprehension:

set(line.lower() for line in ifilter(None, imap(str.strip, file('words'))) if not line.isupper())

This eliminates the second strip() call but has a confusing mix of syntaxes. The data flow repeatedly changes direction.

Prefix syntax - that of Lisp, Python, C, etc. - is backwards: the functions called later must precede those called earlier. One has to say what comes last first, like saying: "Eat a sandwich; make a sandwich; buy groceries." The words are spelled left to right but the sentence is right to left.

Consider this Python syntax hack to write lazy-functional code like an assembly line.

Lazy-functional using pipes.py:

file('words') | pmethod('strip') | pfilter | pnfilter(methodcaller('isupper')) | pmethod('lower') | pset

This isn't shorter, but allows sequences of operations to be written naturally from left to right, without nested and distant parenthesis.

pmethod() eases mapping using a method of the objects to be mapped, making this version more general because it works if the strings are a mix of str and unicode instances. methodcaller() similarly eases filtering.

Presumably, this would be better in Lisp, using its read macros, but this abuse of __ror__ hasn't caused problems yet.

Does anyone know of a practical language that takes this idea seriously?

Objects are Exclusive Types

There is a common dichotomy between objects and types.

Object: Unique, objective, existing thing.
Examples: Socrates, the Sun, one's self.

Type: A bundle of attributes that may match zero or more objects.
Examples: man, star, yellow.

Similar distinctions appear in the assumptions of major systems of philosophy, logic, and computer programming.

An object is only a type that one expects to have no more than one match at once. That is why minds believe objects exist. For example, if one believes in the Sun, and he believes the Sun is in the eastern sky, then he assumes the Sun is not in the western sky. That seems trivial only because this type of inference is constantly relied on.

Objects are unprovable. There could be a duplicate of any object. One would believe there is only one thing in the Universe with all those attributes, but his mistaken idea of an object is really a type. One can be certain that a type is a type but not that an object is an object. Beliefs in objects are routinely wrong and must be revised; beliefs in types are useless at worst.

Axioms are to formal systems as rules are to a game. It seems unwise to afford an axiom to the idea of objects when the Universe may contain none or when beliefs in them may be useless.

Natural languages, containing nouns and definite articles, encourage the useful presumption of objects.

It is immensely beneficial to minimize axioms. Those remaining represent deeper patterns, giving greater leverage. For example, in a computer program, reducing axioms eases increasing reliability and speed. Also, fewer axioms with the same power are likely to be more expressive: simpler parts can form more combinations.

In first-order logic, the similar distinction between things and predicates limits expressiveness. In it, statements about predicates, such as, "yellow is a color", cannot be made without resorting to a trick like reification. When objects are eliminated, saying "yellow is a color" is no different than saying "the Sun is yellow".

Objects should not be axiomatic. They should be the fluctuating implications of a web of learned types and inferences. The goal is an algorithm for the creation and destruction of object beliefs. Presumably, a system to represent all the knowledge of a general intelligence must contain beliefs and beliefs about associations between beliefs. It's likely that the function of objects can be expressed in terms of negative associations between types.

Thoughts?

Fancy wxPython Exception Handler

My wxsupportwiz.py module has made it easy to solve most of the bugs that users have found in egoClip. I guess it resembles Mozilla's Quality Feedback Agent, except it doesn't catch crashes in Python extensions, but those are rare.

When an exception goes uncaught, it pops up a little window asking the user if it's okay to send error information to your website. Then it POSTs to your CGI script almost anything you could want about the error:

exception type
traceback
program version
Windows version
date
current directory
local variables
and it's easy to add more.

In egoClip's case, the CGI presently just e-mails me everything. The CGI could also match the error details to a set of solutions and output the URL to a page of instructions that the module will popup in the user's webbrowser.

To hook it up, just:

import wxsupportwiz
wxsupportwiz.wxAddExceptHook('http://egofile.com/naughty_users.php')

As usual, let me know if you find this useful or if you have suggestions.

Responsive User Interfaces II

In my previous entry, I devised a cheap trick for improving the overall responsiveness of egoClip. I've since noticed the irony of trying to accelerate a program by inserting a delay. I also noticed that it doesn't make for a perfectly live search field, but it's at least wickedly easy to use and beats the typical behavior of always blocking the UI thread until the work's done.

One conspicuous flaw is the requirement of a magic number: the length of the delay. Mainly this means it will fail when your computer's gummy.

I think the deep solution is not to write the program in this style:

Oh, the user wants me to do X, then I'll do that right now and ignore everything until I'm finished.

But instead to write it entirely this way:

Oh, the user wants me to do X, then I'll make a note to later do X after I've done all more urgent work and if the user hasn't since asked me to do something that would erase all of X's effects.

So in egoClip, if I want to show a news item when the user double clicks on a headline, I might hook it up using:

headline_list_ctrl.Bind(wx.EVT_LIST_ITEM_ACTIVATED,
                        lambda e: queue.put(lambda i=e.GetIndex(): show_item(i),
                                            priority='high',
                                            affects=['shown item']))

The priority is high because the user is sitting there waiting for it. The affects list gives the queue the information it needs to remove overridden pending jobs.

This is a complex kind of queue, and it has to be thread-safe. Is there Python code for one of these? If not, I'll soon write it myself. Either way, stay tuned for code.

Responsive User Interfaces

For the egoClip project, I aim to make the UI completely responsive. (By responsive, I mean that the UI never locks up and provides at least partial results ASAP, not that every operation is completed instantaneously.) I've used what I imagine is the standard/obvious approach:

One big background thread that handles all slow tasks (mainly database work).
Fed by a prioritized queue of jobs to do.
And an idle event handler that gently does whatever work has to be done from the UI thread.

Yesterday, a customer pointed out that in egoClip, when focused on the news item list control, if you hold down an arrow key to swiftly step through the items, it just leaps to an item when you release the key. The problem seemed to be that the time to show an item's text was greater than the key repeat rate. You could have a similar problem with a live search field.

So I wrote a little wxPython function that makes it easy to delay responding to the user's actions until they finish or pause. Here's the open-sourced code from egoClip: wxtimers.py. Example usage:

from wxtimers import wxDoLater

def event_handler(what_the_user_wants):
    wxDoLater(0.5, lambda: show(what_the_user_wants))

So if within half a second, the user asks you to show something else, the original do-later will be cancelled and the new one will start.

The module also contains my trivial convenience subclass of wxTimer.

wxSetting Python Module

I might be qualified to say something useful about Python because I seem to be one of the few who has built a consumer Windows application with it and has started selling some copies.

The program's named egoClip (was less imaginatively named the NewsRanker until I noticed that Topix trademarked NewsRank; presumably they're playing on Google's PageRank and don't simply have it in for me). It's an RSS aggregator that learns to sort your news by how interesting it thinks you'll find them. Think Bayes meets RSS. Many others have had this idea, but hardly anyone seems to have done anything about it.

Anyway, since code beats prose, here's some open-sourced code from egoClip: wxsetting.py. Example usage:

from wxsetting import *

def font_change(new_value):
    [use the new font size]

app.settings = wxSettings(
    first_use = wxSetting(default=True),
    font_size = wxSetting(default=12, handler=font_change),
    )

# and then from your prefs code, you could go ...
font_size_ctrl.Bind(wx.EVT_SLIDER, lambda e: setattr(settings, 'font_size', e.GetInt()))

Mainly, the point is that when you initialize your application, you define this bag of settings with defaults and optional functions to be called when the setting is changed. Then you can, e.g., pass this to your preferences dialog code and it can change settings without having to know what has to be done as a result. No doubt it's messy and there's much room for improvement, but if you find it useful or have suggestions, let me know.

Now that I've reviewed the module, I'm reminded that I originally wanted to use descriptors so I wouldn't have to put all the settings in a wxSettings bag to handle assignment, but couldn't because before wxPython 2.5, the frame and app classes weren't derived from object. I can change that now, though it's not so bad having all settings alone inside one object.