Thursday, March 30, 2017

Hope, not optimism. Science Magazine: A Roadmap for rapid decarbonization

Hope is definitely not the same thing as optimism. It is not the conviction that something will turn out well but the certainty that something makes sense, regardless of how it turns out.
—Vaclav Havel
This is a profoundly important distinction. We can be hopeful, even when pessimistic.

Endless debates about whether we "should" be optimistic or pessimistic are useless. They suggest no action. Bozo optimism is rampant these days, but we can (must) ignore such nonsense.

Otoh, hope (focusing on what makes sense) is all important. Once we have a proper plan we can start to make that plan come to pass. This will be far from easy: there are powerful forces committed to folly. The alternative is despair, the notion that no plan makes sense.

The paper,  "A roadmap for rapid decarbonization", Science 24 March 2017, page 1269, is a perfect example of hope in action.  It lays out a reasonable plan for dealing with global warming.  It (rightly) ignores the myriad obstacles that such a reasonable plan will face.  It focuses exclusively on what should happen, and ignores fruitless speculation about what will happen.  This is a superior model for public policy and superb paper: powerful, concise and hard hitting.

Edward

Thursday, March 23, 2017

Leo 5.5 final released

Leo 5.5 is now available on SourceForge and on GitHub.
Leo is an IDE, outliner and PIM, as described here.
Simulating Leo's features in Vim, Emacs or Eclipse is possible, just as it is possible to simulate Python in assembly language...
The highlights of Leo 5.5
  • Syntax coloring is 20x faster than before.
    The "big-text" hack is no longer needed.
  • Leo's importers are now line/token oriented, allowing them
    to handle languages like javascript more robustly.
  • New perl and javascript importers.
  • Pylint now runs in the background.
  • Pyflakes can optionally check each file as it is written.
  • Greatly simplified argument-handling for interactive commands.
  • Documented how to do Test-Driven Development in Leo.
Links

Friday, March 17, 2017

Leo 5.5b1 released

Leo 5.5b1 is now available on SourceForge and on GitHub. Leo is an IDE, outliner and PIM, as described here.

Simulating Leo's features in Vim, Emacs or Eclipse is possible, just as it is possible to simulate Python in assembly language...

The highlights of Leo 5.5
  • Syntax coloring is 20x faster than before.
    The "big-text" hack is no longer needed.
  • Leo's importers are now line/token oriented, allowing them
    to handle languages like javascript more robustly.
  • New perl and javascript importers.
  • Pylint now runs in the background.
  • Pyflakes can optionally check each file as it is written.
  • Greatly simplified argument-handling for interactive commands.
  • Documented how to do Test-Driven Development in Leo.
Links

Saturday, October 22, 2016

Leo 5.4-final released

Leo 5.4 is now available on SourceForge and on GitHub.

Leo is an IDE, outliner and PIM, as described here.

Simulating Leo's features in Vim, Emacs or Eclipse is possible, just as it is possible to simulate Python in assembly language...

The highlights of Leo 5.4
  • Added clone-find commands, a new way to use Leo.
  • The clone-find and tag-all-children commands unify clones and tags.
  • The new pyflakes and flake8 make it possible to check files from within Leo.
  • Added importers for freemind, mindjet, json and coffeescript files.
  • Rewrote the javascript importer.
  • Imported files can optionally contain section references.
  • The viewrendered plugin supports @pyplot nodes.
  • Improved the mod_http plugin.
  • @chapter trees need no longer be children of @chapters nodes.
  • All known bugs have been fixed.
Links

Thursday, October 20, 2016

Leo 5.4-b1 released

Leo 5.4-b1 is now available on SourceForge. Leo is an IDE, a PIM and and an outliner.
The highlights of Leo 5.4
  • Added clone-find commands, a new way to use Leo.
  • The clone-find and tag-all-children commands unify clones and tags.
  • The new pyflakes and flake8 make it possible to check files from within Leo.
  • Added importers for freemind, mindjet, json and coffeescript files.
  • Rewrote the javascript importer. It can optionally generate section references.
  • Imported files can optionally contain section references.
  • The viewrendered plugin supports @pyplot nodes.
  • Improved the mod_http plugin.
  • @chapter trees need no longer be children of @chapters nodes.
  • All known bugs have been fixed.
Leo is:
  • A fully-featured IDE, with Emacs-like commands.
  • An outliner. Everything in Leo is an outline.
  • A Personal Information Manager.
  • A browser with a memory.
  • A powerful scripting environment.
  • A tool for studying other people's code.
  • Extensible via a simple plugin architecture.
  • A tool that plays well with IPython, vim and xemacs.
  • Written in 100% pure Python
  • Compatible with Python 2.6 and above or Python 3.0 and above.
  • A tool with an inspiring and active community.
Leo's unique features:
  • Always-present, persistent, outline structure.
  • Leo's underlying data is a Directed Acyclic Graph.
  • Clones create multiple views of an outline.
  • A simple, powerful, outline-oriented Python API.
  • Scripts and programs can be composed from outlines.
  • Importers convert flat text into outlines.
  • Scripts have full access to all of Leo's sources.
  • Commands that act on outline structure.
    Example: the rst3 command converts outlines to reStructuredText.
  • @test and @suite scripts create unit tests automatically.
  • @button scripts apply scripts to outline data.
  • Outline-oriented directives.
Simulating these features in vim, Emacs or Eclipse is possible, just as it is possible to simulate Python in assembly language...
Links

Wednesday, September 14, 2016

A blunder in Bill McKibben's "A World at War" in the New Republic

Bill McKibben's piece A World at War in the New Republic is a call to arms against climate change.  The stakes are indeed as high as he makes them out to be.

Alas, McKibben misstates what it will take to reduce CO2 from the atmosphere.  In fact, the situation is far more serious than he implies.

The following quote contains a blunder:
But would the Stanford plan be enough to slow global warming? Yes, says [Mark Z.] Jacobson: If we move quickly enough to meet the goal of 80 percent clean power by 2030, then the world’s carbon dioxide levels would fall below the relative safety of 350 parts per million by the end of the century.
This is a completely wrong.  It results from bathtub problem mistake.  Reducing the rate at which water flows into a bathtub does not lower the level of the water! CO2 is removed from the atmosphere by weathering of rock, and that process takes at least thousands of years. See this page for more.

We won't get even to 400 ppm unless we learn how to remove CO2 from the atmosphere.  That can be done, but it would take a huge amount of green energy.  Only governments could fund such a project. It's not going to happen with climate deniers in control.

Edward

Thursday, July 7, 2016

An open letter to Science magazine

The research article, The social dilemma of autonomous vehicles and the accompanying perspective,  Our driverless dilemma do not deserve publication in a prestigious scientific journal. Real world scenarios are tests of sensors and anti-lock brakes, not moral algorithms.

The perspective starts out "Suppose that a driverless car is headed toward five pedestrians. It can stay on course and kill them or swerve into a concrete wall, killing its passenger." This scenario assumes that the driverless car (DC) has been caught unawares by the pedestrians! Either the DC has either malfunctioned, or it was cruising at an unsafe speed.

Crucially, the authors never explain how such scenarios could arise. In all real situations, slamming on the brakes and sounding the horn would be the appropriate response. Doing otherwise increases the risk to pedestrians and other vehicles and exposes the manufacturers of the DC to lawsuits.

These articles founder on a simple question. If the putative moral dilemma exists, it should already have happened. Why aren't human drivers worried?

Both articles assume that DC's could be "programmed" to deal with non-existent ethical dilemmas. In fact, DC's will likely use neural networks that mimic best driving practice. Bizarre driving behavior will not arise from such neural networks.

For years to come, these articles are likely to give unjustified comfort to insurance companies threatened by autonomous vehicles.

Edward K. Ream

P.S. The picture accompanying the perspective shows how silly these scenarios are:

Unless the foreground DC has malfunctioned, it will be applying maximum brakes. The speed limit for this two-lane road is probably less than 50 mph, so given the implied reaction time (no visual obstructions!), the car should easily stop before hitting the children. The car may even have stopped already.

Swerving into the guard rail will decrease the DC's maneuverability, increase the chances of careening into the background DC and increase the chances of hitting the children. In no way is swerving left or right a reasonable choice. If the foreground DC simply brakes, the children have maximum chance of avoiding the car, either by getting close to the guard rail or by jumping over it, or even by turning and running away. Swerving may fatally confuse the children. 

P.P.S. The technology behind DC's will almost certainly involve communication between DC's. So the foreground DC, having the better sight lines, will warn the background DC to brake.

P.P.P.S. The Trolley Problem thought experiment, and variants such as presented in these papers, ignore two crucial factors: urgency and uncertainty. There is no time to compute Rube Goldberg responses, and there is no way to know the outcome of bizarre behavior.

Here, the thought experiment results in obvious nonsense. You could call it a reductio ad adsurdem. It seems that these kinds of thought experiments have limited applicability.

EKR