Question Forums

Question Forums

Motivation

In online discussions, people talk past each other. It's a fact of online life. Much moreso in discussions about politics or ideology, but even in friendly discussions, it crops up.

A few years ago I had an idea about how to fix it - or at least ameliorate it.

The idea

What if there was a forum where in order to answer a post, you had to, well, answer it? That is, a post could formally ask questions. Those who wanted to reply to the post would have to answer the questions first.

Software could enforce this rule. It could be much like online polling. The answers could be displayed associated to the replies, and in other ways.

Potential problems

"Have you stopped beating your wife yet?"

Of course the first thing one thinks of is that people are going to abuse this facility by asking questions like "Have you stopped beating your wife yet?". Ie questions that are really statements in disguise, or more innocently, questions that just fail to include the answer the respondent wants.

My proposed solution is for the polling software to automatically add a response option that says that the question is flawed in this particular way.

That solution is a general template for the solution to many of the problems with this idea. Add response options so that the responses to the question are collectively exhaustive. We'd also like for them to be mutually exclusive, but that may be more difficult to arrange.

He says every question is flawed!

The answer to the previous problem suggests the next problem: Some participants might adopt a strategy of just saying that every question is flawed. That's no good. It short-circuits the whole mechanism.

Two basic answers:

• Let's carve up the answer-space better than that.
• Their answers will again be public. A participant who publicly says that "Do you support [candidate]?" is as flawed as "Have you stopped beating your wife yet?" is going to look ridiculous and deservedly so.

He asked too many questions!

Another potential means of abuse: Participants who ask, not a modest few questions, but a boatload of questions. After all, they have a captive audience!

Participants might be just indluging themselves, or might use it as a strategy to block replies.

I'd propose a limit to the number of formal questions a post may ask. There might be some flexibility here; the limit might depend on such factors as:

• How long a participant has been participating
• Whether he is in good standing.
• How much "question-juice" he has stored up - but this has its own problems.
• A strategic tradeoff whereby the replier need only answer any N of the questions. Ask too many questions just takes some control away from the questioner.
  • "Soft limits" on the above, where the replier who answers fewer than N questions still can reply but their reply is automatically modded down.

He just replies in another thread!

Participants might adopt a strategy of circumventing the mechanism by just replying somewhere else.

They'd have to answer the questions there too, but:

• Not if they started a fresh thread
• On answering one post, they might put in their replies to many posts in that single post.
• Or they might congregate on a thread that asks questions more to their liking.

To some extent that problem contains its own solution. If respondents put their answers in strange places, the posts that they "answer" will appear to go unanswered. This generally is not what posters want.

I'd also propose some limitation on people starting new threads. Most forums have that anyways. I don't see right now how anything can be done about the other two problems.

Figuring out a question's exact flaw is too much work!

In the solutions above, I proposed that there be a spectrum of It won't just give one option for "Question is flawed", it will suggest flavors.

But here we have a dilemma. OT1H want participants to be specific about what flaws they claim that a question has. OTOH, we don't want to require participants to do a lot of work taxonomizing the exact flaw of each flawed question they see.

I think a reasonable balance is achievable, but how can we achieve it? Well, I don't think the answer is to predetermine a particular level of detail. Discussion should be more flexible than that. So:

• We'd have a taxonomy of question flaw types.
• Repliers could specify the flaw in as much or as little detail as they chose to.
• Feedback mechanisms would exist, possibly involving challenges to insufficiently detailed objections.

The flip side of questions that assume

Above, questions that assume too much were considered a problem. But that's only half of the picture. Normal, healthy discourse does assume a lot. But in healthy discourse the presuppositions are already believed by all participants. Nobody is trying to sneak presuppositions in.

And the following scenario would be just wrong:

• Participant A asserts position X
• Participant B asks a question that presupposes X
• Participant A then objects that the question is flawed because it assumes X.

I have some ideas about that which involve structuring questions further, but it's late.

How to carve up answer-space?

Other forms of flawed question

• Off topic questions
• Incomprehensible questions
• Questions that assume too much. This is a slightly more general case of what was discussed above.

Further ideas

I have further ideas, but it's late. I will try to post more another day.

Some theory

Why is this a good idea? That is, not the motivation or the mechanics, but the theory behind it. Why should questions in particular be so great? Why should one sentential mood be favored above the others? Let's look at them:

• Questions: Questions are naturally interactive. Which is not to say that they are always really used that way - there are rhetorical questions, and browbeating questions, and so forth. But notice, even those work by superficially appearing to be interactive.
• Statement. Statements are less interactive. They don't naturally leave a place for your interlocutor to respond. That's not to say that people don't answer statements - it happens all the time. It's just to say that statements don't naturally invite it.
• Imperative. The imperative mood ("Do this!") could be viewed as interactive too, but in a different way. You're commanding your interlocutor to do something. A group of people telling each other what to do isn't going to improve improving the quality of communication, nor the tone.

The paradox of existence preferences

The paradox

• Really obvious fact: Most people prefer to live. They prefer to exist over to not exist and they demonstrate this continuously by not committing suicide.
• Adam Ozimek argues that if so, "there is a huge market failure whereby the unborn are unable to contract with their potential parents to pay for life".
• Robin Hanson then proposes (or at least toys with the idea of) solving this market failure, in effect optimizing "who should exist". "Nonexistent people" would in effect pay to exist. He claimed that his proposal was Pareto efficient - that is, it makes everybody better off.
• Most observers seemed to disagree. I liked Carl Shulman's and Wei Dai's answers, and I felt that Robin's calculation of value ignored a person's interest in their own existence.

But we're left with a paradox. Why doesn't the conclusion follow?

• Because we're too squeamish to think about it? I hope not, and I doubt that's it. I'm not, and I doubt the overcomingbias readers whose answers I liked are either.
• Because the proposed solution isn't actually Pareto efficient? Part of the discussion focused on whether it was. I think it's fair to say that under the original assumptions it is, but under other reasonable assumptions it isn't.

"No nontransitive preferences" doesn't extend this far

"Nontransitive preferences" are when your preferences contradict each other. For instance, if you prefer an apple to a banana, an orange to an apple, and banana to an orange, you have nontransitive preferences. An unscrupulous grocer could trade you an apple for a banana plus $.05, an orange for an apple plus $.05, and a banana for an orange plus $.05 and make $.15 from you without improving your situation in any way.

For most purposes, nontransitive preferences are irrational. But maybe this doesn't cover people's preference to exist. If you'll indulge some ontological looseness for a moment, maybe it's entirely reasonable for "nonexistent people" to have little or no preference to exist, but for existing people to have a strong preference to continue to exist.

One could say that what counts is state transitions rather than states. That is, people prefer not to change state from existent to nonexistent (or as we uneducated masses say, to "die") but have no strong preference whether to change state from nonexistent to existent.

I don't think this holds up well. Most people would prefer that, if they die on the operating table, they should be brought back to life if possible. There are exceptions but seem mostly due to poor quality of life due to poor health.

One might counter by claiming that a person who dies on the operating table doesn't really cease to exist, since medicine can resuscitate him. I don't think that rebuttal works. Even if a person could entirely cease to exist and be brought back - think Star Trek transporters - I expect people would again prefer re-existing.

So we really are talking about state preferences, not transition preferences.

Comparison to the Ontological Argument

I think a better answer to the paradox is that it has essentially the same flaw as in the ontological argument. Existence is not a predicate. And existence isn't an asset that one can have in one's portfolio. Nobody can say "I have some assets but I don't have existence".

So the concept of the "nonexistent people" preferring to trade some of their assets for the asset "existence" is incoherent. ISTM this undercuts the reasoning behind Hanson's proposal, and thus solves the paradox.

org2blog again

While I'm thinking about it

Just used my org2blog to upload the last post. Including all the pictures exercised it fairly well. While it's fresh in my mind I have a few comments:

How to use it with pictures

• (Of course) Write a file that includes pictures.
  • Capture the pictures. I find it's convenient if you put them in a sub-directory of your blogging directory
  • Use C-u C-c l to make links to them
• Upload the pictures
  • If you have a Blogger account, you have a Picasa account, or you do if you have ever put a picture in your blog. If you don't, you'll have to set something up.
  • Call gphoto-albums twice. The first time, g-client will have an error. It's due to a missing entity, really an upstream problem so I haven't looked at it.
    • If my acute shortage of round tuits ends, I'll make gphoto-choose-album automatically does this.
  • Upload the photos. Usually gphoto-directory-add-photos is most convenient. For single photos, use gphoto-photo-add.
  • org2blog will automatically remember what remote URL they correspond to.
• Upload the blog entry with M-x org2blog-post

I made gphoto-directory-add-photos easier

Now it picks album names from a list.

Glitch in gphoto

Somewhere in gphoto there was a "bad byte code" glitch. That seems to have been solved by reloading. I'm not sure how serious it is.

gphoto-read-album

I'm not sure what TV Raman planned with this function. It doesn't look like it would work, and I've never used it. However, I fixed what looks like a scoping error that always gave me some byte-compilation bugs. No guarantee from me that it works.

org export can't naturally flow text & pictures

Not a major failing, since it's not really meant as a page designer. But I'd have liked to flow the text around the pictures, and I couldn't without writing the HTML by hand.

Windbelts

Windbelts

What a windbelt is

A windbelt is an alternative energy source invented by Shawn Frayne. It uses the principle of aeroelastic flutter. Basically it recovers power from a string that vibrates in the wind, like an Aeolian harp.

See also here

Promising

• They are cheap. That's undeniable. Less than $10 for the parts for a working model.
• It works. He's selling them¹ and they generate power. There are videos.
• Less moving parts than a windmill. That's "less", not "fewer". It's got as many moving parts - more if there are multiple strings. But they don't move as much. You could hold your finger an inch away from the moving part and not get smacked by it.
• Scalable? Apparently a 10 meter version is in the works.
• Efficient? Shawn claims that a windbelt generates 10 to 30 times as much power as a microturbine under certain conditions; it makes 40 milliwatts in 10-mph breeze.

  That's promising, and it suits his plan of marketing it in the third world. But for more conventional use, I'm left with questions:

  • 10 mph is a low speed for conventional windmills. They get better at higher wind speeds. How does the efficiency compare at higher wind speeds?
  • At higher wind speeds, microturbines are not the most efficient means. One would want to at least compare against conventional windmills.
• Noisy? Actually, no. According to Shawn's site, the windbelt is actually fairly quiet.

Could it be made a little more efficient?

Two ideas:

• (Not by me. A commenter on Youtube suggested it first AFAIK)

  Put the generator at or near the center of the string, where it is exposed to more vibration.

  Or if it's difficult to give it a stiff platform there, at least put it somewhat away from the end, which is the part of a string that vibrates the least.

• Generate power from the whole range of transverse modes. It appears to me from the demonstration that windbelt is only generating power from one transverse vibration mode. But a string has a whole family of transverse vibration modes, effectively doubling the opportunity for power generation.

  Addendum: I see that more advanced versions do essentially that:

Where might it be used

Shawn basically talks about using it in third world countries that can't afford windmills. But I think one could aim higher than that.

In place of conventional windmills

Could they be used instead of conventional windmills? There are two reasons that make me think maybe:

• NIMBY. After the Ted Kennedy / Narragansett Bay brouhaha, it looks like conventional windmills aren't politically easy (Don't ask me why, I thought they were scenic). Might windbelts be a little easier on the view?
• Cross-section. A conventional windmill goes to heroic lengths to sweep its working surface over a large cross-section, but even so, a lot of the wind goes thru it without ever coming near the windmill's working surface. For a windbelt with (say) 2 meters between strings, the air is never more than 1 meter from the working surface.

On suspension bridges

In particular, vertically on suspension bridges. It's a great location:

• The physical support is already there.
• The electrical infrastructure is partly there - they are wired for road lighting and other electrical use.
• There's a huge cross-section exposed to the wind.

On tall buildings

There is a lot of wind around tall buildings. They block the wind so it is all funnelled around them. It's actually a big problem, and can suck windows out and make it uncomfortable for pedestrians to walk nearby.

It's a problem many people have tried to solve, and tried to generate power from. But with conventional windmills, it's not easy. Where can you safely swing the blades? If you duct the wind to a turbine or similar, you waste a lot of power and it's noisy.

But a windbelt doesn't have that problem. And once again, having the physical and electrical support already in place is nice.

Footnotes:

¹ Individually, not mass produced. See his FAQ.

First notes on implementing EMSIP

Implementing EMSIP in Scheme

What

These are my older notes on implementing EMSIP in Scheme. They give a flavor of my thinking, warts and all.

There's a fair bit of rethinking in here, and many parts are just obsolete.

Some ideas

Iterate over a sequence of characters

This allows all the lazy reading we could want.

The iterated proc mostly just checks for magic characters

Or more carefully, for attention-string followed by any magic character, and for non-empty attention-strings, also wraps characters in a different way that other parts recognize.

It builds a lazy structure as follows:

A left bracket

• Calls the respective reader. That's one of 3 predetermined readers, which mutate into the actual readers.
• Feeds the current reader the return value of the new reader as an object. Since Scheme supports lazy evaluation, this can be done without order-of-evaluation problems.

A right bracket

• (Not immediately needed) Check for bracket agreement; error if bracket does not agree with initial bracket.
• Terminates the current reader's input
  • And (as above) terminates the current read scope.

???

The comma is not special here, it's just treated specially by 2 of the built-in readers.

???

(Not immediately needed) For a non-magic character following a non-empty attention-string, feed it to the current reader as a semi-magic char.

Any other character

Feed it to the current reader as a simple char.

Mode of iteration

We can't just loop thru the characters, because different conditions apply at different points, and these conditions are hierarchical.

Instead, we are reading with specific state data, and sometimes recursing into another call that "uses up" a stretch of characters.

So each call would:

• Take the initial stream
• Take the state data
• Return the remaining stream
• Return the object that was read

So this call corresponds to a nested reader. It gets or immediately sets up a reader and uses that reader for its whole (non-nested) scope.

And we use this by:

• When we call a new reader,
  • Give it state data
    • probably including the new reader
  • replace the stream with its promised return
  • Use its object return as the value to feed to the current reader.

To make the laziness work wrt the end-bracket termination, we'll pass the current continuation, and the iterator never stops, it just calls that continuation.

We also want to fill the list in a natural way. That suggests that rather than iterating as such, we are filling a list and making further promises.

Argument structure of the built-in readers

• Takes a lazy stream
  • Element types can be, all distinct:
    • simple character
    • (Not immediately needed) semi-magic character
    • object, as returned by some other reader.
    • A promise which may be any of the above
    • A discriminated promise, which knows which type it is but not what it is.
    • And (not formally an element) end-of-list.
• May also take further arguments, all objects:
  • Usually, as when reading a list, takes the next object as a promise
    • Must allow an indication of termination, possibly #f.
    • When possible, should treat that object as opaque; don't force it as a promise. That's not always possible, which is why that object would be an argument.
• Returns an object

Flow control

Let them be promises.

Let both object and stream be promises.

• Order of evaluation
  

  Wall-clock order of evaluation of a nested call:

  • Call nested emsip-read
  • Nested emsip-read formally returns
  • Current read goes on to the remainder of the read (but may not have the stream)
  • Current read forces the stream
  • Nested emsip-read tries to finish
  • Nested emsip-read finishes stream, makes it available
  • Nested emsip-read may ask for some or all of current read's remainder of the read (often just the first object)
  • Current read, certainly now knowing stream, reads further,

Pass xformers around.

The returned object becomes a chain of promised xformers.

What nested read returns

Of course its final state of the stream. But what else to return is conflicted:

• OT1H, wants to return the object, letting reader treat it any way that it likes as it builds its ultimate returned object.
• OTOH, wants to call an xformer on the object and a tail object.

We could let it return either, and reader can use it as an xformer if that's appropriate. So reader must know what it's getting. And reader must supply itself an xformer when none is provided.

Or return a tagged thing, arbitrary tag that other readers should understand.

Or predefine some tags, so it can be `xformer' or `object'. And every reader tells us which it supplies - really, we pass it thru.

It is up to readers to be suitably lazy and to call xformers.

Optimization: Skipping forward

Sometimes we'd like to can skip past characters we know aren't relevant. Some cases:

• Non-magic characters, skip to the repective closing bracket. This reader's value remains just a promise and may yet be forced.
• General skip-past-chars as dictated by reader, but of course still never skipping past magic characters.
  • So the other is a special case of this.

How to communicate it? Partly just by not forcing reads. Perhaps also as a read parameter.

Rethink: May need to allow more nested levels

The simple one that only sees comma as separator. This will be built by `emsip-make-list-reader'. One xformer only applies at single level here. This is basically for "repeat". But there are 2 levels in our basic reader: Objects and characters. Or we could just accumulate characters into lists. What's not nice is that the 2 levels are entangled with each other. Maybe intercept just comma and magicify it, then have really 2 levels. Init the inner xformer with `list->string'. Does the outer level (a) LEANING_TOWARDS pass in a false end, or (b) NOT_CHOSEN act after the inner level passes on something? And it would make an object, as any other level does. But dual levels is just what I hoped to avoid here.

Perhaps reader would tell upper level about separators?

But it's really alternating string-constitutent and non-string-constitutent.

So very likely a new design: Push-down layers which always include the brackets. But comma is just a separator. It pops (like an end bracket), but higher level immediately pushes another. And hopefully the basic readers won't need anything more than that and sequence (which also pushes and makes non-match pop).

Readers forcing downwards

The previous item demonstrates that readers may want to immediately start a nested read. That gives opaques still a chance to organize strings rather than having pieces embedded in them. Do this before end-brackets - repeat-readers do expect to go to a second level first. But they shouldn't eat the forthcoming char

Repeat-readers do this. Separating repeat-readers don't have a way to return zero elements, nor should they.

Checking for matching brackets

Built-ins simply know the end-bracket char they expect. Readers probably shouldn't set up their own end-char expectations, and even if they did, they are passed their starting char which suffices to figure out the end char.

So there's nothing special to be done when starting a nested read.

Maybe something special to be done when ending one. That's most neatly done by passing the final char to `afterwards', the termination communication function.

Raise error when `emsip-object-stream-force1' gets empty stream? No.

Do not raise error when `emsip-object-stream-force1' gets an empty stream, because this condition might occur in innocent places such as a forced tail after a comment.

I may rethink that, though.

How to return the state of the stream

In normal use, `emsip-object-stream-force1' returns all the info it needs to. It returns a stream with the car forced, and the tail promise knows the state of the input stream.

But when it hits an end-bracket which ends the output stream, or hits the end of the input stream, it needs to communicate the new state of the input stream. We can no longer use the return value to communicate it, because that has to be the null stream.

Would be nice to have:

• This manages bracket-match checking
• This gives error when it is not set up, corresponding to a read that popped past the top level.

Possible approaches:

• Call a continuation of something in the caller. emsip-object-stream-force1 would call it just when it hit an end, passing the new state of the input stream.

  The problem is that we need control to exit this call by its normal route so that the output stream gets assigned its right (forced) value.

• Return two values, where the first is the output stream and the second one (usually redundant) is the input stream.

  It's also difficult or impossible to ensure that the calls we're interested in gets the values. In many cases there are other callers, usually delayed intermediate calls.

  And it's ugly to always return a value that usually isn't used and is usually redundant to another value.

• Set a boxed value to the new state of the input stream.

  That's clumsy for the caller to set up.

• Call a function that sets the value.

I will be posting some notes about EMSIP

I will be posting some notes about EMSIP

For the past few days, I've been sketching an implementation of EMSIP. EMSIP is my idea of how s-expressions could be extended without losing their well-behavedness.

It is a reference implementation and it's not ready for use yet. It's really just a sketch at this point. I haven't written the testing code, and I don't consider code "really written" until it passes tests.

Ordinarily I would write the tests first and write code afterwards. The design phase would overlap with test-writing. But in this case functionality was not the only thing that interested me. I was as interested in making an elegant, minimal design as I was in functionality. So instead of writing tests first, I sketched the code and re-examined it until it seemed as elegant and minimal as was reasonably possible.

I think I largely succeeded in my goal. The code even surprised me with its elegance at a few points.

Why EMSIP?

Why EMSIP is a good thing

EMSIP is my idea of how s-expressions could be extended without losing their well-behavedness.

Common Lisp reader macros read arbitrary stretches of text. They only need stop when the macro decides it has read enough. It need not respect bracketing. But without reliable bracketing, s-expressions become a lot less predictable, and therefore a lot harder for tools to handle. So Common Lisp reader macros destroy the well-behavedness of s-expressions.

There are several ways you can think about a solution:

• Just don't expect tools to handle arbitrary reader macros. So now your tools can't fully read your code. Bad idea.
• Don't use any extensions? Impractical.
• Put all of the intelligence that your reader macros have into every one of your tools. There's no portable or reliable way of doing this.
• Use a different system of s-expressions. But Scheme macros have the same problem.

EMSIP offers a solution. EMSIP always respects bracketing. A bracket always means a nesting operation, except for one special case. And even that case is very mild: In special scopes, there is an attention string and only brackets immediately preceded by that attention string "count".

Further (minor) deficiencies of s-expressions

EMSIP offers even more regularity. Although normal, non-reader-macro'd s-expressions are fairly well behaved, they have lots of exceptional cases. For instance:

• The lowly string literal, eg "abc". It doesn't have start and end brackets, it has one unibracket that both starts and ends it.
• Quoting and backquoting. They aren't standalone s-expressions, they want to alter the meaning of the s-expression that follows them.
• Exceptional symbols such as `&optional' in formals lists. They don't want to be symbols in a list. Like quoting, they want to alter the meaning of what follows them.

EMSIP will make all of that more regular.