2016-01-31

自動ドア

電子工作で作りたいものを思い付いたのでとりあえずメモ。

自宅に引き戸があるのだが、これを自動ドアにする。

・機械的に開く仕組みを作る
 端的に言えば、ラジコンカーが作れればよい。
 しかも一軸方向のみの移動なので前進と後退だけである。
 測距計をつけておけば自分の位置も取得できる。

・制御
 WiFiかBluetoothにつなげればスマートフォンやPCのアプリで
 操作可能になる。画面のスライダーで引き戸が動かせたらクールだ。
 扉にタッチセンサを付けたり、お店の自動ドアのように測距モジュールを
 天井に設置するんでもよい。
 「すべてがFになる」の真賀田研究所では人間を静電容量をもった
 物体として検出するという設定だったが、同じような仕組みでセンサを
 作れないだろうか。
 これなんかどうだろう。最大で24インチと書かれている。


同じような話だが、自宅には開き戸が2つある。
引き戸に比べると開き戸は自動ドア化が難しい。
蝶番に何か仕込めないだろうか。

出入口に関しては施錠システムを作りたい。
既にスマートロックとしていろいろと商品化はされているが
まだまだ実用的ではなさそうだ。

言語変化

30年後の日本語はどの程度変わっているだろうか。

Wikipediaの「」の項を参照すると、
奈良時代には「お」と「を」で音韻にも明確な区別があったものが、
平安時代に入り混用が始まるとある。
詳しくは当該項目に譲るが、発音自体はどちらも「wo」だったり
どちらも「o」だったりと時代によっていろいろで、
戦後に現代仮名遣いに移行した際に、「お・を」もほとんどが統一されたが、
助詞の「は」「へ」「を」については使用頻度の高さのため残されたようだ。
「こんにちは」を「こんにちわ」と書くのと同じように、
「東京から青森えの最終列車わたくさんの乗客お乗せて出発した」
のように変化していくだろうか。
現代人からみると「てにをは」の類はパッと見た時の目印になるため、
それが「てにおわ」になってしまうと読みづらくてしょうがないが、
これは現代仮名遣いに変わった時も同様だったはずなので
慣れの問題でどうにでもなるだろう。
しかし日本語の自然言語処理がますます難しくなる。
その前に英語のように空白で単語あるいは文節を区切るような文化が
浸透しない限りは置き換えは難しいだろう。

発音の点では、「wo」が「o」になったのと同じく、「wa」が「a」になることで
「わ」行が消え去るという可能性はないだろうか。
「わたしはね」→「あたしゃね」のように、一度口をすぼめる必要がある「wa」の
音では「w」が落ちやすい。
「すみません」が「すいません」の変化も「m」の子音を経由するという
手間の省略だから構造としては同じだろう。
イ音便、促音便、撥音便等も発音のしやすさからの変化だが、
「歩きて」→「歩いて」→「歩うて(歩ーて)」
「酔ひて」→「酔って」→「酔おて(酔ーて)」
「進みて」→「進んで」→「進うて(進ーて)」
のように、さらに簡略化される可能性もあるだろう(関西弁に近い)。

どんどん口元が緩くても済むように発音が変化していっているんだろうか。
そう考えると、どちらかというと聞き手側よりは話し手側の利便性によって
言語表記が変化していくのかもしれない。
だとすれば、発声機構が機械化されると言語の変化の仕方もまた変化するだろう。
口を動かす代わりにタイピングをするんであれば打鍵の手間に応じて
言語は変化するだろうし、信号のようなものを直接生成するのであれば、
信号の波の形状によって脱落する子音や統合される母音が出てくるのかもしれない。

まあ、30歳年上の人と対して違う言語をしゃべってはいないし、
30年では身体の機械化が進むとも思わないので、そこまでの変化はないだろうし、
寿命が延びるに従って話者の入れ替わりが緩慢になるため、
変化のスパンはどんどん長くなっていく。

150年くらい先の日本語は聞いてみたい。

音声合成

Raspberry PiやArduinoみたいなシングルボードコンピュータを
使って何かつくろうかと思っているが、たいていのことは
スマートフォンでもできるのであまりいい用途が思いつかない。

とりあえず、合成音声の出力はしたいなーと思い、
いろいろと探してみると、フリーでもよさそうなものが出てくる。

rospeex
 NICTが開発しているらしい。
 杉浦孔明さんという方が関わっているようで、
 http://rospeex.ucri.jgn-x.jp/nauth_json/jsServices/VoiceTraSS
 にPOSTすると合成されたデータが返ってくるようだ(デモ)。
 Python + クラウド音声合成 で高品質なアニメ声読み上げを参考に
 スクリプトを起こしてみるとうまくいった。
 pythonではpyaudioを使うとwavの再生もでき、再生部分も含めるとこんな感じになる。
 アニメ声なのが、場面によってはやや使いづらい。

# -*- coding: utf-8 -*-
import sys
import base64
import urllib2
import json
import wave
import time
import pyaudio

tts_url ='http://rospeex.ucri.jgn-x.jp/nauth_json/jsServices/VoiceTraSS'

if __name__=='__main__':
        message = sys.argv[1]

        # command
        tts_command = { 'method':'speak',
        'params':['1.1',
        {'language':'ja','text':message,'voiceType':"*",'audioType':"audio/x-wav"}]}

        obj_command = json.dumps(tts_command)
        req = urllib2.Request(tts_url, obj_command)
        received = urllib2.urlopen(req).read()

        # extract wav file
        obj_received = json.loads(received)
        tmp = obj_received['result']['audio'] # extract result->audio
        speech = base64.decodestring(tmp.encode('utf-8'))

        f = open ("tmp.wav",'wb')
        f.write(speech)
        f.close

        w = wave.open("tmp.wav",'rb')
        p = pyaudio.PyAudio()
        def callback(in_data, frame_count, time_info, status):
            data = w.readframes(frame_count)
            return (data, pyaudio.paContinue)
        stream = p.open(format=p.get_format_from_width(w.getsampwidth()),
                    channels=w.getnchannels(),
                    rate=w.getframerate(),
                    output=True,
                    stream_callback=callback)
        stream.start_stream()
        while stream.is_active():
            time.sleep(0.1)
        stream.stop_stream()
        stream.close()

VoiceTextAPI
 こちらはHOYAが開発していて、無料登録するとAPIが使える。
 いろいろな言語のライブラリが用意されていたので、
 golangのものを使ってみた。github/yosssi/go-voicetext
 VoiceTextAPIのバックエンドにもgolangが使われているらしい(スライド)。
 ファイルに書かれた内容を句読点等で区切りながら読み上げるサンプル。
 splitの実装は句読点を残すために場当たり的実装になっているので要注意。
 合成音声の出来はかなりいい感じである。
 最近はARM用のパッケージもgolang公式で配布されるようになったので
 Raspberry Piなんかでも動かせるのだろう。

package main

import (
    "bufio"
    "fmt"
    "os"
    "os/exec"
    "strings"
    "time"
    "unicode/utf8"

    "github.com/yosssi/go-voicetext"
)

const (
    APIKEY = "0000000000000" // 無料登録して取得したAPIキー
)

func main() {
    c := voicetext.NewClient(APIKEY, nil)

    var message string
    var cmd *exec.Cmd
    var period bool

    var scanner *bufio.Scanner
    if len(os.Args) >= 2 {
        f, err := os.Open(os.Args[1])
        if err != nil {
            os.Exit(1)
        }
        scanner = bufio.NewScanner(f)
    } else {
        scanner = bufio.NewScanner(os.Stdin)
    }
    isBreak := func(r rune) bool {
        switch r {
        case '、', '。', ',', '.', '「':
            return true
        default:
            return false
        }
    }
    split := func(data []byte, atEOF bool) (advance int, token []byte, err error) {
        start := 0
        for width := 0; start < len(data); start += width {
            var r rune
            r, width = utf8.DecodeRune(data[start:])
            if !isBreak(r) {
                break
            }
        }
        for width, i := 0, start; i < len(data); i+= width {
            var r rune
            r, width = utf8.DecodeRune(data[i:])
            if isBreak(r) {
                return i + width, data[start:i+3], nil
            }
        }
        if atEOF && len(data) > start {
            return len(data), data[start:], nil
        }
        return start, nil, nil

    }
    scanner.Split(split)
    for scanner.Scan() {
        message = scanner.Text()
        result, err := c.TTS(message, &voicetext.TTSOptions{
            Speaker: voicetext.SpeakerHikari,
            Pitch:   80,
            Speed:   115,
            Volume:  150,
        })
        if err != nil {
            os.Exit(1)
        }
        if result.ErrMsg != nil {
            fmt.Println(result.ErrMsg)
            os.Exit(1)
        }
        if cmd != nil {
            cmd.Wait()
            os.Remove("tmp.wav")
            if period {
                time.Sleep(1000*time.Millisecond)
            } else {
                time.Sleep(400*time.Millisecond)
            }
        }
        if strings.HasSuffix(message, "。") || strings.HasSuffix(message, ".") {
            period = true
        } else {
            period = false
        }
        f, err := os.Create("tmp.wav")
        if err != nil {
            os.Exit(1)
        }
        defer f.Close()
        if _, err := f.Write(result.Sound); err != nil {
            os.Exit(1)
        }
        cmd = exec.Command("aplay", "tmp.wav")
        err = cmd.Start()
        if err != nil {
            os.Exit(1)
        }
    }
    if err := scanner.Err(); err != nil {
        os.Exit(1)
    }
    if cmd != nil {
        cmd.Wait()
        os.Remove("tmp.wav")
    }
}

2016-01-30

移動

空飛ぶ自動車なんていうものがSFにはよく出てくるが、現実にはそれが普及する未来は来ないだろう。もちろん、技術的には小型の浮遊体は実現可能だろうし、実際にそういった製品が発売される可能性はあるだろうが、自動車のようなかたちで普及する前に人間が移動する機会が減っていく。

30年前に比べると仕事のあり方の多様性はかなり広がっただろう。もちろん職種によるところが大きいが、自宅作業が可能な職種も多いし、Skype等を利用することで、わざわざ出張せずとも、電話や手紙よりも情報量の多い通信が可能になった。この後30年間で、情報の方を移動させることで人間を移動させずに済ませるという傾向はさらに進むだろう。これはコストの問題だ。人間と人間が直接合わないと通信できないという時代は、言語を発明した時点から終わり始め、近年の益々広がる遠距離通信による伝達可能情報量によりそれは加速されている。合理化を図ろうと思うと、輸送業等の移動自体が仕事である業種を除き、仕事に伴う移動は減らすべきである。社内ではそれを推し進めることは簡単だろうが、社外に対しては相互理解が一つの壁になるだろう。お互い移動にはコストが伴うことを承知の上で、まさにそのために直接伺うことが誠意の表明になるという悪しき風習を断ち切るのにどれだけの時間がかかるかだ。

日常での移動はどうなるだろうか。保育園の送り迎え、通学等の教育に関係する部分については、仕事との関連も大きい。現状のように、仕事自体が一箇所に人を集めて管理することで成り立っている場合には、教育もまた一箇所に人を集めて行うことになるはずだ。
仕事の方が変わってくると、教育も学校のような施設ではなく、家庭等のより小さい単位での実施にシフトしてくるだろう。これも技術的には現在でもできるわけだから、社会システムの方が変わるかどうかにかかっている。買い物については価格と速度を考えればネット通販が普及する。Amazon Nowの仕組みは要はおつかいである。ネット通販は長らく、ほとんど何でも注文できるが時間はかかるという世界だったものが、日用品等は1時間あまりで届くということになってしまうと、小売店には勝ち目がない。店頭販売にはどうしても接客が発生するし、商品の陳列効率も倉庫に比べると圧倒的に劣る。接客と陳列にかけるコストを配送に振り分ければ、日本の大部分をカバーする販売網が形成できるのではないだろうか。

自動運転技術が確立された後では、都市圏の車両と夜間に走行する車両は自動運転に限るという運用がされるかもしれない。すべてが自動運転車になれば、自動車同士の事故は非常にまれになるだろう。また、交通状況もかなり正確に予測されるため、日本の鉄道並に自動車移動が時間に正確になる。最近でも痛ましい事故があったが、夜間走行車両こそ自動化の恩恵が得られる最大の領域だ。それが常識になった後では、かつて人がハンドルをにぎっていたなんていう恐ろしい時代があったんだと思い起こされるだろう。

さて、どんなに移動のコストが意識される時代になっても減らないと思われるのが余暇のための移動だ。これはまさに移動のための移動だからである。環境を変えたいという欲求のある程度は環境制御技術の発達で解消されるかもしれないが、何かを見たいというような、直接性を得るための移動は何をもっても代えがたい。

結局は仕事の場合もそうだが、この直接性の神話への信仰と移動のコストを天秤にかけることで移動の要否が決まってくる。現状、GoogleやAmazonを始めとした情報分野の大企業が、VRやAR、AI等の開発で直接性の神話を切り崩すとともに、人間が移動しないことによるコストを切り下げている。30年後も、東京で大雪が降ったり大地震が起きると、駅が人で溢れかえる様子が見られるだろうか。

教育

そして二人だけになったの教育に関する話を読んでいて、
魔法の色を知っているか?でラジオを使ってSOSを発信する
シーンを思い出した。

教育とは、受信側のスイッチが入っていることと、
発信した信号が受信可能であることを期待して
発信する以外にないという勅使河原の話が、
もはやラジオが廃れた世界で、ごくまれなアマチュア無線家の
存在を信じてSOSを発信したシーンに重なる。

昨今流行りのディープラーニングでは、
データセットから特徴を抽出し、プログラム自身が
判断のルールを決めていく。
プログラムに抽象が可能になったわけだ。
ここに至るともはや教育とはデータを与える行為に収束していく。

Wシリーズの描く二世紀先の世界では、
教育という幻想が崩れているという様を、
ラジオによる通信の難しさに重ね合わせたのかもしれないと思った。

2016年現在、GoogleやAmazonは無料無制限のかざりをぶら下げて
世界中のユーザを教師にすることで、人工知能の教育に邁進している。
教師というよりも環境や入力あたりの言葉が近いかもしれないが。
一方で、日本の教育現場では学習指導要領の変遷(ゆとり教育から脱ゆとり)、
モンスターペアレントの誕生、学習塾の普及等、もはや家庭と学校の役割とは
何なのかがよくわかならくなってきている。

何のために教育をするのか。
さらによい教育を受けるため?
その先には収入の高い職業が待っている?
その収入でまた自分の子によい教育を受けさせる?
自分では教育もせずに?

30年後に、家庭や学校という仕組みはどの程度残っているだろうか。

そして二人だけになった

森博嗣の新シリーズと四季シリーズの間に
百年シリーズがあるのだが、未読であった。
まずは同じ新潮文庫から出ている
「そして二人だけになった」を読んだ。

明石海峡大橋と大成建設が出てくる。
そして建築構造の話が盛りだくさんだ。
力学がわかる人間であればある程度フォローできるだろうが、
完全にはフォローできなくても何かすごそうな感じがするだけでも
よいのかもしれない。

あえてディテールをはぶけば、勅使河原潤サイドと森島有佳サイドの
ストーリィが交互に展開される。
各章とも、奇数節が勅使河原サイド、偶数節が森島サイドであり、
アスタリスクでそれ以外のストーリィが挿入される。

まるで量子力学のようなストーリィ展開だったと言えば伝わるだろうか。
分離していたと思っていたものは一つになり、
一つだと思っていたものは離別する。
小説の前半は古典力学だ。
観測者も観測対象も確固たるものとして把握される。
それが終盤での量子力学の発見によって、
実は世界が重ね合わさった複数の可能性だったものとして捉え直される。
読み終えた段階で読者はこの小説を観測できただろうか。
いや、最後の最後まで現象は収束することなく、
シュレーディンガーの猫は古典的な意味で生きても死んでもいない。

奥付に初出は平成十一年六月とあるから、まだ二十世紀のころの作品だ。
兵庫県南部地震が平成七年、
明石海峡大橋の竣工が平成十年、
NYの同時多発テロ事件が平成十三年、
福島の原発事故が平成二十三年。
物語の終盤で、明石海峡大橋が竣工した後にH県南西部地震が
発生しており、特定の周波数で共振するような設計になっていたという
話はなるほどと思ったが、実際には応答解析をチェックすれば判明するだろう。
それよりも、
「これからの大規模構造物の設計でもっとも大きく、確率の高い外力はテロである」
といった話や、原子力発電の是非について勅使河原がインタビューを受ける話は、
世間(というよりもマスコミか)が五年後十年後に躍起になって取り上げた
話題をうまく挟んであり、改めて森博嗣が好きになった。
そう、この小説ではアスタリスクの節が一番好きなシーンだった。
自分の意見を一つに絞ろうとする必要はないと思います
そもそも自然とは何か、という問題が一番難しい
仕事を持っている、というのは、自分でシャツを着ることができる、くらいの価値かな
教育なんていう行為が、はたして本当に存在するのでしょうか
いつでもどんなときでも正しいことってあるのでしょうか


2016-01-28

電子書籍2

電子書籍についてその2。

森博嗣の新シリーズ「彼女は一人で歩くのか?」には
「熊の生態」という本が出てくる。
主人公のハギリはロシア語が読めないので
翻訳機を兼ねたスコープを通して読むのだが、
その途中で真賀田四季からのメッセージが一時的に挿入される。
ここではスコープの側がクラッキングされたということに
なっていたが、紙の本でなければ書籍の側を操作することも可能だ。
「彼女は一人で歩くのか?」の電子書籍版では是非そういった
仕掛けをやってほしいが、おそらくそうはなっていないだろう。
そもそもreader(リーダと読者)側がそういうことを想定していない。

漫画、映画、アニメ、演劇、音楽、朗読、ゲームその他諸々のいずれとも違う、
まぎれもない本という形式でありながら電子化による紙媒体との
差別化は如何にして図れるだろうか。

季節、時間帯、あるいはセンサによる入力等に応じて
表示する文章を変えたとき、その作品はもはやスタティックな
本としてではなく、ダイナミックなストーリィとして受け取られる。
小説では、人称を自由に行き来するような表現もできるだろうか。
ページをめくるたびに文字数が少なくなることで緊張感の高まりを表したり、
めくってもめくっても文字が出てこない、あるいは逆に、
めくってもめくっても「失敗した失敗した失敗した」のような、
富豪的プログラミングならぬ富豪的ライティングだって可能なはずだ。
それも、予め決められたページ数ではなく、例えばページのめくり方に応じた
終了条件も可能なはずだ(10ページ以上めくった段階で1秒以上めくらなかった
場合に次に進む、等のように)。
円城塔あたりがこういうことに興味をもってやらないだろうか。

この本は電子書籍で読まないとわからない、
というような本が出てくることを切に願う。

2016-01-27

通信

SFで、身体が機械化されているのに通信が音声を
介しているものとして描画されるものは
結構多いように思われる。

電気信号を肉体の動きに変換して空気の振動を生じさせ、
別の個体が空気の振動を肉体の振動として受け取って
電気信号に変換するなんているまわりくどい方式をとるよりも、
電磁波でやり取りしたほうがシンプルだと思うのだけど。

フレーム問題

フレーム問題の人間における解決方法が忘却なのではないか。ただし、タイムアウトというよりは、評価値の収束状況で思考を切り上げて判断を下しているのかもしれないが。フレームはむしろ判断が下った後で、そこにあったように見える。

2016-01-26

4bit

先日のrpnカルキュレータは、入力パターンと機能の
組み合わせが任意なので、変わったものも試してみている。

デフォルトでは普通の電卓と同じように、各点は
左上から右下にかけて、789→456→123の
数字入力に対応しており、ロゴはenterキーになっている。
これを、右下の4つを4bitとして、1から15の数字入力に
なるようにマッピングしてみた。
おかげで残りの5点が解放されるので、
0、.(小数点)、E(エクスポーネント)、バックスペース等が
1キーに割り当てられる。
しかも10〜15までの数字も複数キーであるが1ストロークで
入力できるので、慣れれば入力は早くなるかもしれない。

しかし、これに慣れるとRPNであること以上に特殊なので、
慣れるのもまた問題である。

16.1.30 ロゴ画像を追加。
15はFであるから、Fをモチーフにした案も考えたが、
4bitということで円を4つ。

魔法の色を知っているか?

「魔法の色を知っているか?」を読み終えた。
前作 彼女は一人で歩くのか?

ストーリィは相変わらず程よい未来感をたたえている。
特に、ラジオ等の旧来の技術のはさみ方が抜群である。
この辺りは著者の趣味的な部分が多いに活躍しているのだろう。
新しい方の技術にしても、エンジニア的な視点をもっているというか、
なんとなく有り得そうな説明に感じられるのは自分も
エンジニアだからだろうか。

個人的にはやはりハギリとヴォッシュの両博士の間で
交わされる議論が面白いと思う。

スーパ・サーバ・システムに関する一悶着のくだりで
ヴォッシュが語る、無機の正義のようなものを構築して
それを人類に課してくるという抽象的な説明は、
つまり現状で言うところの倫理観の押し付けである。
倫理とはある集合にとっての正義のことであり、
今の時代で言えば人類にとっての正義である。
人工知能が発達することで、人工知能にとっての倫理を
構築するとしたら、それはまさにここで言うところの
無機の正義であるし、今人類がやっているのと同じように、
自分たち以外にもその正義を押し付けることになるだろう。
だから、「スパコンには論理的判断はできても倫理的判断は
できないのか」というかつての問に対する答えとしては、
「コンピュータが自律的に思考するようになった場合、
自らにとっての正義は獲得しうるだろう。ただし、それが
人類のものと一致するかはわからない。その意味で、
倫理的判断は人類の思うようにはできないだろうと予想される。」
のようなものになる。

頭脳細胞が新しくても老化がありえる、ハードではなくソフト、
あるいはデータの問題だ、というのはつまり、
最適化を免れられない仕組みになっているということか。
できるだけ計算せずに短絡させられるところは短絡する。
それが判断の高速化を助け、生き延びることにつながるし、
痴呆、習慣、常識、宗教等様々なものの原因になっている。


真賀田四季がプログラムを埋め込んでいるという展開は
すべてがFになると同じ仕組みである。
あの時は真賀田四季が外に出るための装置だった。
このプログラムの内容によっては人類はすでに檻の中だ。
いや、檻の中にいるのですらなく、真賀田四季の
シミュレーションの中のデータの一つになったのかもしれない。
ナクチュというのは現代社会の縮小モデルであるし、真賀田四季は神である。
宗教を捨て、ナクチュ以外の部分を内側にしてしまった時点で、
人類の側がある意味で負けてしまったのだろう。


マービン・ミンスキーがなくなったようなので、
心の社会を読もうと思う。

日本人は何でも箸と醤油で食べる、
Japanese people eat anything with chopsticks and soy source.
というのは去年思い付いたジョークの中でも
ベストだと思っているが、知り合いの中で
笑ってくれそうな人は一人くらいだ。

ということを、食堂で醤油を手に取るたびに思い出す。

忘却の問1への回答

忘却における破棄は、消去ではなく
走査時に随時起きる取りこぼしのようなものだ。
それは、ある判断を、その判断が有意であるうちに
終了させるために必要とされる。
だから、走査スピードが速ければ速いほど、
見かけの記憶量は多くなる。

コンピュータに対しては、HDDやSSD等の記憶装置に
全データを蓄積してあるとの認識があり、
それに即座にアクセスできることが日常的にはほとんどなので
忘却が難しいように感じるのだろう。
データ量が膨大になればタイムアウトを取らないと
ハングアップするのは当然だ。
それを回避するシステムは忘却と呼ばれるべきだろう。

記憶領域の走査方法としては、switch-case文のような
一対一対応の検査ではなく、ビットの01を追っていく
絞り込みのような検査に近いはずだ。
それであれば「聴いたことがある」のような記憶の再生の
され方もエミュレートできる気がする。

人間の早すぎる最適化問題についてはまたいずれ。

忘却

痴呆(とは最近は呼ばないが)とはある種の最適化である。

痴呆と忘却とは似て非なる現象だ。
痴呆は経験の蓄積に伴う短絡であり、
忘却は経験の破棄によるシステムの保全である。

きっと忘却という仕組み抜きでは安定的な意識は保てない。
人工知能はその問題をどうやってクリアするんだろうか。

一方、人間が長生きするには如何に痴呆による最適化を
かわすかを考えなければならない。

2016-01-25

23+6=29

23歳になってから6年が経った。

思いの外ちゃんとこのブログを続けている。
日記のような内容になることはほとんどないので、
見返したところでその日に何をしていたのかを
思い出すためのよすがにはならないが、
(よすがって縁と書くのか)
どんな本を読んでいたかや、何を考えていたかは
わかる記事も多いので、30年後くらいに読んで
当時の自分がどの程度わかっていてわかっていなかったのかを
振り返ってみるのも面白いかもしれない。

2046年1月25日、59歳もまたPRIMEth Birthdayである。
紙の本、QWERTY配列の物理キーボード、
人間が運転する自動車はまだ残っているだろうか。
プログラミングは人間がしているだろうか。
建築現場では配筋や現場溶接が行われているだろうか。
未だに人間は忙しなく働いているんだろうか。
がんや痴呆が解決され、人間の寿命は延びただろうか。
延びた寿命、減った仕事に耐えられず、
新たな社会問題が発生しているだろうか。
おそらくそれは少子高齢化や環境問題よりも
人間社会の存続にとって遥かにクリティカルだ。
現代の宗教は死を前提として如何に生きるかを主題としているが、
未来の宗教は生を前提として如何に死ぬかを主題として
展開し直されることで、退屈に耐えられない人類に
救いの手を差し伸べているのかもしれない。

30年後、俺はこのエントリィを読んでるだろうか。

2016-01-21

rpn更新

スマートフォン用のrpnカルキュレータを更新した。
以前のものは関数ボタンへの画面遷移があるため、
四則演算以外はどうしても2動作必要になる。
これだと、ほとんどの演算子が裏にあるような状態なので、
あまり魅力的でないのが問題だった。

ボタンの個数を抑えつつ、なるべく簡潔な動作で
より多くの機能を配置するには、ということで
最初に考えたのがフリップ入力方式だ。
しかし、ボタン名の表示がゴチャゴチャするのが
いやなのと、ボタンへの機能の割り当てを変えるたびに
ボタン名も更新しないといけないのが苦痛だ。

そこで冒頭のパターンロック方式に思い至る。
Androidのパターンロックと同様のジェスチャが入力できる
フィールドを用意し、ジェスチャと機能を対応させている。
ジェスチャへの機能割り当てをできるようにしておけば、
機能配置にほぼ制限が感じられないくらい自由度が高くなる。
問題は各機能のジェスチャを覚えていられるかどうかだ。

golangでもgxuiでデモ版は作ったが、golang.org/x/mobileを
使うのがまだまだ面倒すぎてgolangでのAndroidへの移植は断念。
patternLock.jsというおあつらえ向きのライブラリがあったので、
monacaでさらっと実装した。
最も苦労したのはcssで、<input type="image">で挿入した
ロゴをタップした時の青いハイライトを消すところだ。
ずっと:active擬似クラスだと思って検索していたら、
-webkit-tap-highlight-color:rgba(0,0,0,0);
だった。わかるか。

p.s.
monacaのBasicプランでは24時間に3回だけビルドできるのだが、
この制限に引っかかるたびに思い出すのは、
幽白で霊丸を打てる回数に最初は制限があったなぁということだ。

2016-01-18

雪の日に

都内で雪が降ると必ず話題にされる交通機関の雪への弱さ。
でも、雪対策をいろいろ施すには当然メンテナンスもつきまわるわけで、
年に数回しか降らない雪のために、雪国並みの対策をとっていたら
それこそエンジニアリングがわかっていない。
年に数度のイベントのために函館駅に新宿駅と同レベルのホームと
改札を設置し、普段は使わないでおくのは滑稽には見えないだろうか。

それにしても、駅に溢れかえる人の数には驚かされる。
日々これだけの乗客を捌いている鉄道機能はさすがである。

しかしそれ以上に思われるのは、
いつまでこんな移動を繰り返すのだろうかということだ。

2016-01-16

雪の進軍

雪の進軍 氷を踏んで
Marching in the snow, Stamping on the ice,
何処が河やら 道さえ知れず
Where's the river on the earth, There's no knowing of the path,
馬は斃れる 捨ててもおけず
Horses break down, Can't be left behind,
此処は何処ぞ 皆敵の国
Tell me the where, Enemies everywhere,
儘よ大胆 一服やれば
What the heck is going on, Take a break with a made up mind,
頼み少なや 煙草が二本
Hope is too little, Only with two cigarettes.


2016-01-15

バイノーラル

バイノーラル音源をイヤホンで聴くことと、
Oculus Riftで映像を見ることには、
感覚器官に擬似入力を行う点で大差がないと思うんだけど、
なぜ後者ばかりがVRとして取り上げられるのか。

常識3

プログラミング界隈における「歴史的経緯により」は
常識という概念に近いものがある。

いずれも後方互換性を保つために導入されるあたりが。

p.s.
LGTMのような、FHR(for historical reasons/raisins)画像を作りたい(作らない)。

負数の二乗

良識のある計算者であれば、-10^2=-100だと答えるはずだが、
どうやら世の中の表計算ソフトでは-10^2=100とするのが常識のようだ。
 ・Microsoft Office Excel2013
 ・LibreOffice Calc version4.4.3.2
 ・Googleスプレッドシート(本日付)
のいずれも、セルに「=-10^2」を入力すると(-10)^2と解釈され
「100」が表示される。
問題なのは、「=-10^2」は「100」なのに、「=10^2-10^2」は「0」であり、
「=-10^2+10^2」は「200」になることだ。
もはや不快感を覚えるレベルで適当だ。

こういう場合にプログラミング界隈で使用される説明は決まって
歴史的経緯により for historical reasons」である。
便利な言葉だ。

p.s.
Googleスプレッドシートのバージョンはどこで確かめられるのだろう。
ソフトウェアのバージョンが特定できないのはバグや仕様変更への
追従が非常に困難になるため問題だと思うのだが。

アナログ時計

アナログがある連続量を別の連続量で表示することなのだとすれば、
秒針が1秒ごとに動くタイプのアナログ時計はデジタルである。
しかも、コンマ秒まで表示するデジタル時計と比べると離散度が高い。

2016-01-08

GuP

いいぞ。

Oculus Rift

VRデバイスのOculus Riftがついに発売されるようだ。

こういった形式での拡張現実感の限界は、
脳内での認識の前に別の圧縮行程が入る点に
あると思う。

前述のとおり、認識が入力された情報の圧縮の
ことなのだとしたとき、脳内では一旦バッファされた
情報の切り貼りが行われる。
ここでどんな情報が切り捨てられたかということも
認識した結果にある程度の影響をもつのではないか。
そういった部分がごっそりと抜け落ちた状態で、
それでもある程度の現実感を保つには、
もうそれに慣れてしまうしかないのではなかろうか。

先日の六方位の記事で出た「前」についての話。

空間では顔がある方を前、
時間では過去を前と呼ぶのが、
進む方向という定義からはずれてしまう。

空間と時間の前の共通点とは、
次にすべき判断の材料となる情報が存在する
方向のことなのではないかと思う。

p.s.
情報といえば、「通信の数学的理論」で有名な
ワレン・ウィーバーの言に、以下のものがあるらしい。
共通の基礎の上にそれぞれ別個の高い塔が複数あり、それぞれに人が住んでいるとしよう。彼らが互いに対話しようとする場合、それぞれの塔から周囲に向かって声を張り上げるだろう。しかし音では最も近い塔に届くのも難しく、対話は遅々として進まない。しかし、塔から降りて外に出れば、大きな基礎があり、全ての塔がその基礎の上にあることがわかる。こうして彼は同じように塔から降りてきた人々と有意義な対話を簡単にできるようになる。
この話、自動翻訳の記事を書いたときに考えたことに近い。

2016-01-06

h2database

h2データベースの公式サイトからダウンロードした
zipファイルに含まれているh2.shがうまく動かない。

chmod u+x h2.sh
./h2.sh
としても
エラー: メイン・クラスorg.h2.tools.Consoleが見つからなかったか
ロードできませんでした
となってしまう。

h2.shを開いてみたらfile formatがdosだったので、
:set ff=unix
で直してから再度実行したらうまくいった。

githubに置いてあるファイルはff=unixだったので、
コンパイル、圧縮、解凍のいずれかのタイミングで
ff=dosになっているのか。

2016-01-04

六方位

正月休みにamazonプライムを利用して
邦画をいくつか観た。
「舟を編む」もその一つで、そこに出てきた
「右」を定義する話が面白かった。

広辞苑を引くと、
 右:南を向いた時、西にあたる方。
とある。
では南はどうなっているかというと、
 南:日の出る方に向かって右の方向。
となっている。
西は日の入る方角、東は日の出る方とされているのでこれを採用すると、
南とは、東に向かってその方角を向いた時の方向が、
その方角に向かって西を向いた時の方向と一致する方角のこと、となり、
右とは、東に向かってその方向を向くと、向いた方向から
さらにその方向を向いた時に西が見える方向のこと、となる。
これでは南は北でも成立してしまい、右は左でもよくなってしまう。

上下、前後、左右の六方位の中で、左右ほど曖昧なものはない。

上下にあたる概念は、ポテンシャルエネルギーによって規定され、
ポテンシャルの低い方が下、高い方が上と呼ばれる。
人間は地球の重力ポテンシャルに支配されているから、
通常は地球の中心を基準にして、近い側が下、遠い側が上である。
電荷を帯びた物体が電磁ポテンシャルが支配的な世界に生きていたら
その電磁ポテンシャルを基準にして上下の概念ができるだろう。

前後にあたる概念は、進行方向によって規定され、
進む方向が前、戻る方向が後と呼ばれる。
この概念が生まれるためには、そもそもその物体が非対称な構造を
もっている必要がある。
放射状の体をもつ生物には前後の概念に意味がない。
多くの脊椎動物は口が前にあるが、栄養摂取機関としての
口を進行方向に配置することが生存上有利にはたらきそうだと
考えられるので、むしろ口がある方に進むためにそちらを
前と呼んでいるというのが正しいのかもしれない。

果たしてここで左右に至るとき、右はどのように定義できるか。
人間の身体は、左右に関しては概ね対称な構造をもっているので、
そもそも左右という概念は前後に比べると必然性が低い。
だから鏡に映った姿を見て左右が反転したと認識するのだ。
言語の発生よりも前に、左右の概念を作るのは難しいだろうか。
(ここで「前」という表現が使えるあたりに、時間が非対称な構造を
もつという共通認識があることがわかる。しかし時間に言及するときには
進む方向を「後」、戻る方向を「前」と呼ぶ。何故だろう。)

地球上の生物にとってのもうひとつの支配的な因子に自転がある。
生命維持に必要なエネルギーの多くを太陽から得ているので、
太陽光の照射範囲を決定する自転を基に方向概念ができてもおかしくはない。
北半球と南半球で左右の概念が反転するということはなかったのだろうか。
まあおそらく反転していたところで身体の構造がほぼ対称なので
あまり不便はなく、右と左にあたる語が逆に翻訳される程度だろう。

右とは、上下前後ではない残り二方向のうち、文化的に決まる一方のことである。
往々にして多数派であることが多い。

2016-01-02

線対称

2016年の年賀状を描いた。

「申」という字と「二〇一六」という数字がいずれも
線対称だったので、両サイドに半分ずつ配置する。
「申」の字は伝わるだろうか。

餅つき大会

もちつきたいかい
つかいたいきもち
使いたい気持ち

2016-01-01

日本晴

2016年の元日は日本晴。
遥か遠方の富士山も薄っすら見える。
150kmくらいだろうか。

よく晴れた冬の日に見える遠くの山々は、
緑ではなく空より少し黒い青に近く、
遠くのものほど空の色に漸近していく。
日本画によく見られる遠近表現である。
これってレイリー散乱の影響なんだろうか。