org2blog released

org2blog is now released as alpha quality software

It is released as a tarball of:

• Org2blog itself
• Supporting package tinydb
• Diffs to g-client
  • g-client is by T V Raman
• Diffs to org-mode
  • org-mode is by Carsten Dominik, with many additions by others including myself.

To run it you'll also need:

• org-mode
• To patch org-mode
• g-client
• To patch g-client
• Bravery (or an equivalent amount of foolhardiness)

Some short documentation is in org2blog/README.org Basically:

• Have a Blogger account
• M-x gblogger-blog
  • That will give a parse error - T V tells me it's missing an external entity - but it will set up the blog posting url for your blog
• Write a blog post (which I'm doing right now)
• M-x org2blog-post
• And it will appear on Blogger, just like this did (or will).

Summary of changes to g-client

• User-visible changes
  • Some automatic capture of data, by only these interface functions:
    • gphoto-feeds
    • gphoto-photo-add
    • gblogger-blog
    • gblogger-new-entry
  • Changed gphoto-photo-add to ask for an album name from the list of albums, not an album id number.
  • Added a more flexible way of getting authentication: Just customize (new variable) `g-user-auth-function'
  • Hooks
    • `g-app-afterpost-hook' which should be a function taking 2 args:
      • The source filename
      • The remote url
  • gphoto treats non-jpgs
    • Can find them in directories
    • (Forthcoming) Sends the right Content-Type for them.
    • Uses (both emacs-bundled packages) `image' and `image-file' to know about image file types.
  • g-load-defs.el now can be used as a symlink with my-site-start, because it knows its real location.
• Internal additions:
  • Added optional arguments to some interfaces
    • Mostly to pass storers around
      • g-app-send-buffer
      • g-app-view
  • Added internal variables
    • To hold captured data
      • gphoto-album-list
      • gphoto-user-api-location
    • To name new XSL scripts
      • g-xsl-blogpost->url
      • g-xsl-photopost->url
      • g-xsl-feed->albums
    • To hold a buffer-local storer until g-app posts
      • g-app-storer
  • Many commands associated with capturing data
    • gblogger-blog-assign-data
    • gphoto-feeds-assign-data
    • g-app-setup-capture
    • g-util-capture-x
    • g-util-capture
  • Created some convenience functions because I found myself repeating code:
    • g-app-shell-command
    • g-app-build-command
    • g-app-build-storer
    • g-app-setup-posting
    • g-app-succeeded
    • g-display-common
  • Changed g-auth to use customizable variable `g-user-auth-function' for initial authentication.
    • Added g-user-default-auth-function, that variable's default value.

Would have liked real test code

I would have liked to write proper test code for this.

Unfortunately, I basically need an immutable remote site to do it. I contacted Google about this but never heard back from them. That made development more difficult.

Review of Pinocchio, Vampire Slayer

I know it's hard to believe but...

Yes, there is a real book called Pinocchio, Vampire Slayer. Yes, it's about Carlo Collodi's Pinocchio who wanted to be a real boy, and it's not the Disneyfied version. Yes, he slays vampires in the book.

The premise

The premise is just what you probably guessed: Carlo Collodi's Pinocchio is a vampire slayer. He slays vampires with his wooden nose, repeatedly breaking it off to make new stakes.

The familiar characters are there: the Blue Fairy, Master Cherry, the Fox and Cat, the ghost of the cricket. Gepetto however has been killed by vampires before the story begins. (Poor Gepetto; first the shark, now this)

Authors

It's written by Van Jensen. Dusty Higgins both drew it and created the idea. As sole artist, Higgins would ordinarily be "penciller/inker/colorist", but that doesn't seem applicable to the black and white ink style he uses.

What you get

It's 128 black and white pages and essentially no filler. No 8 pages at the end of character drawings, though there is a 1 page bio at the end that covers both Jensen and Higgins.

It begins with a 1-page bow to Collodi's Pinocchio and an irreverent 3-page recap of it, for those who hadn't read the book. I had read it years ago, but the recap was still welcome.

Then it gets to the meat of the book: a noir-style-drawn vampire tale featuring the Real Boy himself.

Impressions

This is a book that doesn't take itself too seriously. That was brought home to me when Master Cherry presents Pinocchio with his newest engine of vampire destruction, The Monsterminator. In a previous draft of this review I quoted the scene, but then I realized the words alone don't do justice to Pinocchio's reaction. It's not overtly silly, it's just something no serious book would have done.

This could easily have been a very dumb book. The noir vampire tale could easily have been played straight, which would have made for a dull, predictable tale. At times it seems about to fall into that trap, but it never quite does. Humor suffuses its pages. Not punchline humor - there are no jokes or gags - just a sense of fun about the kind of book it is.

The art is deliberately somewhat grotesque. The faces are blocky, and typically a quarter of the page area is ink-black. But Dusty Higgins' sense of form is strong. It raises the art from "blah" to "looks nice".

More progress on org2blog

Re-intro

Org2blog is an emacs package that I wrote. It's not quite releasable yet, but there is a tarball available for the brave or foolish. I use it to post this blog, because I like to write my stuff in org-mode.

Recent progress

Maps from local filename to remote URL

org2blog now has a persistent map from local filenames to remote URLs. This is useful when posting links to other blog posts or to images that you have locally, as long as you upload them to Picasa (Google's image hosting)

It automatically captures a remote URL when you post to Blogger. But it doesn't yet capture a remote image URL when you post to Picasa, because that process call runs asynchronously, which is more difficult to capture from.

Captures album lists

g-client knew what photo albums were but couldn't capture a list of existing albums. org2blog can.

Made org's html export neater

In the course of doing this, I made org's html exporting slightly cleaner and better factored. However, this is all done thru a file that's loaded on top of org-html.el.

Again, credit to others

Carsten Dominick

org-mode

T V Raman

gclient, particularly gblogger

Some tricks that Blissymbolics misses

Very short introduction to Blissymbolics

Blissymbolics is a visual language. It consists of stylized ideograms. It looks like this:

• 
• 

Introducing it is not my point, so here endeth the short introduction. For more info see http://www.blissymbolics.us/ or http://www.blissymbolics.org/WebTraining/NewResourceHTMLCSS/index.php

Some neat tricks that Blissymbolics misses

As a conlanger, I noticed a few opportunities that Blissymbolics misses.

Person

Blissymbolics personal pronouns come in the typical 3 flavors, {first, second, and third} person times {singular and plural}. The first, second, and third persons are denoted by the subscripts "1", "2", and "3" respectively.

But why stop at 3? They haven't run out of numerals. How easy it would have been to provide 6 additional placeholder pronouns.

Why would I want such a thing? Consider this ambiguous English phrase from Handel's Messiah:

He trusted in him that he would deliver him; let him deliver him if he
delight in him.

How much less ambiguous it could be if only a fourth-person pronoun were allowed.

Gapping and more expressive relativizers

For relativizers, Blissymbolics has just one symbol (double-quote marks)(Relativizers are words that make a sentential into a restrictive clause with a gap, eg "that" in "The house that Jack built", also "which", "who", "where", "when"). That feels a bit underexpressive.

With such a visual language, it seems easy to indicate the relativized gap explicitly. Perhaps it could build on the previous idea and annotate the personal pronouns and their variants with a reserved symbol. I would suggest "?" but I understand it is already taken by the WH-words, which are almost literal translations of English WH-words.

Connecting verbs to their arguments

I'm not suggesting that little lines must be drawn between each verb and all of its arguments. But with such a visual language, it's too bad there is no provision at all for explicitly indicating the connection of a verb and its arguments. Sometimes that would be convenient.

Classifiers

Blissymbolics has classifiers. The ones they choose seem as if they belong in a philosophical language. The problem with philosophical language classifiers (and other similar regularities) is that when utterances focus on some sub-topic, the classifier gets repeated and repeated. One ends up with monstrosities like:

The medical-vehicle (ambulance) rushed the
medical-heart-bad-situation (heart attack)
medical-person-who-is-acted-on (patient) to the medical-building
(hospital).

I doubt Blissymbolics would accept a less philosophical system of classifiers. So ISTM they need some means of omitting the repeated classifiers. Some possible approaches:

• A means of applying one classifier to a larger grouping, so the repeated classifiers are unneccessary. Maybe along the lines of namespaces.
  • Con: It still makes the topic unnaturally explicit, and now it's intrusive. It's as if doctors had to say "Now I'm going to talk about medical things" before each utterance.
• A use-then-abbreviate system, basically like pronouns. So the previous example might be more like:

The medical-vehicle (ambulance) rushed the it-heart-bad-situation
(heart attack) it-person-who-is-acted-on (patient) to the
it-building (hospital).

That's a little neater, but there ought to be a better way.

Disparate impact

Towards a fair mechanism for dealing with disparate impact

Introduction

On the futarchy discussion list we talk about futarchy, which is a proposal to use decision markets¹ to decide policy, based on a metric called GDP+.

But what if the impact of a proposal isn't spread evenly? Surely² we don't want to enact proposals that, while they benefit the populace³ collectively, have extremely bad consequences to a few.

We could have meta-rules that forbid certain types of proposals. That can curb the worst abuses, but it doesn't solve the problem.

So we want a mechanism that can:

• measure disparate impact honestly.
• tell us what side-payments will flatten the impact

I don't have a solution that I trust, but I do have some interesting approaches towards such a mechanism.

Some general issues

We want a citizen's best strategy to be honest revelation

This almost goes without saying in mechanism design. We want to can show that each citizen's best strategy is to honestly report their best estimate of the proposal's effect on them personally.

There's a free-rider problem

There's a free-rider problem. No citizen individually controls the outcome, so it always behooves him to exaggerate the damage a proposal does to him.

Hard to distinguish 3 different situations of few holdouts

It is hard to distinguish these 3 situations that we would want to treat quite differently:

Sincere objection

A minority of citizens rationally expects to be strongly negatively affected and bids accordingly.

Selection for naysayers

Due to selection effects, those citizens who bid as if they are most strongly negatively affected are those who have most overestimated the bad effects. They may have overestimated by a large amount.

Miscalculating speculators

A few citizens over-report their damages in the hope of a large profit. This is the game chicken. In the N-person game, this situation is dominated by those who play chicken most aggressively.

The first situation is what we want to take into account. For the other two, there are two outcomes, both bad:

• The naysayers or speculators get paid off undeservedly.
• Good proposals sink because of their influence.

General approach: Veto-like mechanism

In the following I'll describe a few potential mechanisms. In each case, the mechanism is intended to augment an overall approval mechanism, such as a decision market.

So the side-payment mechanism will have a veto-like effect:

• If it fails to tell us what the side-payments should be, the proposal is not enacted.
• But if it succeeds, the proposal still needs to pass in the over approval mechanism (perhaps simultaneously).

This gives us some leverage by which to keep speculators and naysayers honest. If they ask for too much, they run the risk of defeating their own windfall.

First idea: Network auctions

My first idea on the topic was to use a network auction. (As in Vickrey_auctions in network routing) It's a good way to figure out appropriate side payments according to relative valuations.

If this problem had the structure of a network auction, it could be solved by a VCG auction. Run the auction, allowing both positive and negative valuations, and if there is a residual positive value,

The problem is, everybody needs to be in the resulting path. So the network is just a line that includes everybody. It lacks competition between different paths.

Second idea: Make competing paths in a network

So maybe we need to create competing paths. My next idea was to map the citizens to nodes in a random network, or randomly in a patterned network. Then find a path thru the network using network auction (as above)

But:

• We are neccessarily using the networks that skip over those most adversely affected.
• It capriciously skips people. The result is more a function of who is skipped than of anything else.
• It's hard to analyze:
  • It's not clear where the path may stop and start
• Negative costs (benefits) don't work well:
  • May result in a long path that unfairly weights the positively affected
  • May result in loops, which makes this mechanism impossible.
• It's underspecified.

Third idea: Use percolation networks instead

So my next idea is to drop the network auction mechanism and use percolation networks instead. Large percolation networks have a nice feature that either they almost certainly allow flow or they almost certainly don't. (This feature proved to be exactly what we don't want, but I'm leaving this in because it illuminates some important thinking about the problem)

We'll specify the network structure as triangular⁴ and map citizens to nodes almost randomly. That is:

• Each row contains a node for each citizen, in random order.
• There are as many columns as there are citizens.

Instead of network auction to determine payments, we:

• Let each citizen C specify a monetary amount payment(C), generally negative, that is the most they would pay to see the proposal pass (This part is the same as network auctions)
• Let each node have a probability of admitting flow that is a function of the respective citizen's payment(C).
  • What specific function? As a first draft, say that the log-odds of the probability is equal to payment(C). That is, the probability is the logistic function of payment(C)
• If a path thru the percolation network is found, the proposal passes and the given side-payments are made.

As stated, this gives entirely the wrong answer. It will say yes essentially whenever more than half⁵ of citizens feel a positive value. We wanted to correct the dynamic in the opposite way.

Sharp-eyed readers will notice that there is a free parameter in there: The baseline zero payment. The same percolation network would give different results if every payment(C) was transformed to payment(C) - X.

But it won't do to just set X such that it makes the total of side-payments zero. Consider the situation of an insincere opposer (IO): The lower a payment(IO) he bid, the better the proposal's chances, because the total payment asked is lower so everyone else's payment(C) - X is higher, giving their nodes a higher probability of allowing flow. So he gets more and does not risk his windfall by lowering the probability of enactment. So payment(IO) should be negative infinity. That's not good.

Fourth idea: Repeatedly subdivide the populace

So instead, let's use the available information to repeatedly split the populace binarily. These subpopulations will settle by side-payments.

So we'll have a series of stages. At each stage:

• A subpopulation Pop is considered. Initially it's the entire populace.
• We use the same set of payment(C) at every stage. Ie, citizens can't change them to react to stages.
• If more than half of payment(C) - average(payment(Pop)) are positive, the proposal passes for Pop and no sidepayments need be made within Pop.
• Otherwise, divide Pop into 2 subpopulations, those whose payment(C) is above the median (PopA), and those below (PopB). Recurse on those subpopulations.
• If both PopA and PopB pass the proposal,
  • the proposal passes for Pop.
  • if the proposal ultimately passes, PopA is to collectively make a sidepayment to PopB, equal to the difference between their median payments times the population size (which is equal, by the way we constructed this)

ISTM this would tend to subdivide until it reached a node of the binary tree at which a significant percentage of Pop demanded unreasonable payments, and would pass at that point in the tree without further subdivision.

But this has the unfortunate property that one overly negative citizen can cause the proposal to immediately pass for the entire population by overstating his payment(C). A miscalculating naysayer or an insincere agent might do that. Yet it gives some leverage against speculators. If they are too aggressive, they'll lose their hoped-for windfall.

Repeatedly subdivide the populace, redux

How can we fix this but keep the leverage? In step 3, instead of choosing X to make the total sidepayments zero, let's choose it to make the quartile payments total zero. Also, step 2 risks entirely ignoring the tails of the distribution. So instead, say:

• If Pop contains only one individual, the proposal passes for him, since he can make no side-payments.
• Otherwise divide Pop into 2 subpopulations, those whose payment(C) is above the median (PopA), and those below (PopB). Recurse on those subpopulations.
• If both PopA and PopB pass the proposal,
  • the proposal passes for Pop
  • superior nodes compute the average as if Pop were replaced by N copies of median(Pop)
  • If the proposal ultimately passes, PopA is to collectively make a sidepayment to PopB, equal to the difference between their median payments times the population size (the sizes of PopA and PopB are equal or differ by just 1, by the way we constructed this)
• Otherwise, with a probability

  P(median(payment(C)) - average(payment(Pop)))
  

  the proposal still passes and no sidepayments will need be made between PopA and PopB.

  • As noted above, the average is a pseudo-average that replaces some subpopulations by their median.

This avoids some of the worst pitfalls. It can't easily be held hostage, because any extreme negative payment(C) will effectively eliminate its own influence. But ISTM it still tends insincerely negative. Everyone wants to be in the negative part of the tree, just not too isolated. It doesn't really leverage the probability of vetoing to encourage reporting positive payments.

Closing remarks

The final proposal solves some problems, but I don't think that it really does the job.

As far as I can see, this topic hasn't been explored before or even proposed as a topic in mechanism design. It could use further research.

Appendix A: What bad things could disparate impact cause?

If proposals with disparate impact can be adopted, these are some bad things that could happen:

Undermeasurement causing enactment

Severe bad consequences to the few would be undermeasured, because their severity would outstrip the ability of the GDP+ metric to measure them or report them. So the proposal looks better than it is and gets enacted.

ISTM it's more of a problem when there's an upside that will be measured normally. For contrast, "blow up the world" has a downside that's hard to measure, but it affects essentially everyone so it's clearly bad.

ISTM the flip side of this situation is less worrisome but still real. By the same token, the GDP+ metric might undermeasure good consequences to a few. In this case, they can voluntarily make sidepayments and and since they need only succeed once they not worry about Extortion of side payments. Still, that minority would probably be subject to co-ordination problems. It would be better if our mechanism managed side-payments in this situation too.

Spiral towards oligarchy

In this problem, the proposal changes or indirectly affects the future franchise, and does so disparately across citizens.

Examples of changing the franchise:

• Shrink the franchise to exclude certain people
• Enlarge the franchise to include more people
• Change how the GDP+ measurement weights welfare across citizens.

So there are people who expect increased control over the GDP+ metric and people who expect decreased. That implies that the change pretty much cancels out in the GDP+ metric. So such proposals might get enacted.

Once the franchise begins changing, it will probably quickly spiral inwards towards oligarchy.

Extortion of side payments

One of the ways that a minority could stop a proposal that would adversely affect them is to promise a side-payment to the others, contingent on the proposal not passing. Since this is a possible move, the others can extort it.

Footnotes:

1 Briefly, decision markets are somewhat like the stock market, but shares do not correspond to any corporation, they correspond to issues and will be redeemed at some future time according to a well-defined measurement carried out at that time.

² "Surely" is a warning sign of a flaw in one's argument, just like "obviously" and of course "of course". So I will flesh out the argument in Appendix A

³ When writing about futarchy, I use many terms that imply that it is to be applied to national governance, such as "populace", "citizens", "enact", "franchise", et al. That doesn't imply that it's the only possible application of futarchy. It's just convenient.

⁴ ie, a 3⁶ regular lattice.

⁵ Because that's the site percolation threshhold of a triangular lattice.