ゆくゆくは有へと

おかゆ/彼ノ∅有生 の雑記

ありふれたクソみたいな記事(シーケンスの速度比較)

括弧が逆ゥ!

はてブ見てたらこういうの見つけた:

Python簡単実験:内包で何倍高速になるか - TIM Labs

「なんで対話型インタプリタ使ってるんや・・・・・?」という疑問は置いといて、こんなに違うのかとちょっと信じ切れなかったので、自分でも書きました。

まずは4つ

作ったのは4つで、

  1. 単純に for で回す
  2. 内包表記使う
  3. range をそのまま list に投げる
  4. ジェネレータを list に投げる

です。

# coding=utf-8

import time


def time_calc(func, *arg, **kwds):
    start = time.time()
    func(*arg, **kwds)
    end = time.time()
    return end - start


def calc(func, n, *arg, **kwds):
    times = [time_calc(func, *arg, **kwds) for _ in range(n)]
    return sum(times) / n


def simply_for(n):
    a = list()
    for i in range(n):
        a.append(i)
    return a


def comprehension(n):
    a = [x for x in range(n)]
    return a


def range_case(n):
    a = list(range(n))
    return a


def range_(n):
    for i in range(n):
        yield i


def generator_case(n):
    a = list(range_(n))
    return a


if __name__ == '__main__':
    n = 10**7
    for func in (simply_for, comprehension,
                 range_case, generator_case):
        print("{}: {}sec.".format(func.__name__, calc(func, 5, n)))

おかゆのパソコンはうんちなのですが、とりあえずこうなりました*1

simply_for: 2.1997323036193848sec.
comprehension: 1.3124329090118407sec.
range_case: 0.550351619720459sec.
generator_case: 2.0610249996185304sec.

内包表記、うちのぱちょこんだと2倍も速くならないくらいですね。まあ速いことに変わりはありません。 それにしても、list(range(n)) が思った以上に速いですね…。

上の記事だと、単純な for より内包表記は約5倍ほど高速になってることを考えると、list(range) は10倍くらい速いことになりそう。

とはいえ、値を計算して…というのはできないですから、結局、内包表記使うのが速くていいですね。

あとは…、おかゆパソコンだと非常に微妙ですが、130msほどジェネレータつくってやるほうが速いですね。

内包表記はforが入れ子になると表記が煩わしくなるので、そういうときはジェネレータ作ってやると for よりは速いということになるのかもしれない(オーバーヘッドはあるだろうけど)。

からの入れ子3つ

というわけで、入れ子3つにしてみた:

def simply_for_2(n):
    a = list()
    for i in range(n):
        for j in range(n):
            for k in range(n):
                if i+j+k % 2 == 0:
                    a.append(i+j+k)
    return a


def comprehension_2(n):
    a = [i+j+k for i in range(n) for j in range(n) for k in range(n)
         if i+j+k % 2 == 0]
    return a


def generator_2(n):
    for i in range(n):
        for j in range(n):
            for k in range(n):
                if i+j+k % 2 == 0:
                    yield i+j+k


def generator_case_2(n):
    a = list(generator_2(n))
    return a


if __name__ == '__main__':
    n = 300
    for func in (simply_for_2, comprehension_2,
                 generator_case_2):
        print("{}: {:.3f}sec.".format(func.__name__, calc(func, 3, n)))
simply_for_2: 8.179sec.
comprehension_2: 7.936sec.
generator_case_2: 7.853sec.

び、びみょ~~~~~~~~~~~~~~~( ᕦ 。 ᕤ)

入れ子が増えると内包表記もfor並にとろくなるのかしら。そう考えると、コードの見た目の観点から普通にfor書くべきだね。

ジェネレータは安定して、「微妙に」速い。

併用や!

見た目的にも、かつ、汎用性も兼ねることを考えると、ジェネレータと内包表記を併用するのが良さそう?

def generator_3(n):
    for i in range(n):
        for j in range(n):
            for k in range(n):
                yield i, j, k


def generator_and_comprehension(n):
    a = [i+j+k for i, j, k in generator_3(n) if i+j+k % 2 == 0]
    return a

if __name__ == '__main__':
    n = 250
    for func in (simply_for_2, comprehension_2,
                 generator_case_2, generator_and_comprehension):
        print("{}: {:.3f}sec.".format(func.__name__, calc(func, 3, n)))
simply_for_2: 4.445sec.
comprehension_2: 4.476sec.
generator_case_2: 4.380sec.
generator_and_comprehension: 7.460sec.

ひえっ( ᕦ 。 ᕤ)お、おしょい・・・!

まあ恐らく原因は、forが実質1つ増えてるというところでしょうかな……。

ジェネレータで入れ子forを分離してやるというのは、個人的には見た目すごいスッキリして好きなんだけどな…。

ちなみに、

def generator_and_for(n):
    a = []
    for i, j, k in generator_3(n):
        if i+j+k % 2 == 0:
            a.append(i+j+k)
    return a

if __name__ == '__main__':
    n = 250
    for func in (generator_and_comprehension, generator_and_for):
        print("{}: {:.3f}sec.".format(func.__name__, calc(func, 3, n)))
generator_and_comprehension: 7.505sec.
generator_and_for: 7.465sec.

なので、もうジェネレータ律速って感じがしますね。内包表記の速みはどこにいったのか……?

itertoolsや!

from itertools import product


def product_and_for(n):
    a = []
    for i, j, k in product(range(n), range(n), range(n)):
        if i+j+k % 2 == 0:
            a.append(i+j+k)
    return a


def product_and_comprehension(n):
    a = [i+j+k for i, j, k in product(range(n), range(n), range(n))
         if i+j+k % 2 == 0]

if __name__ == '__main__':
    n = 250
    for func in (generator_and_comprehension, generator_and_for,
                 product_and_for, product_and_comprehension):
        print("{}: {:.3f}sec.".format(func.__name__, calc(func, 3, n)))

いけー!ぷいきゅあがんばぇー!

generator_and_comprehension: 7.478sec.
generator_and_for: 7.412sec.
product_and_for: 4.933sec.
product_and_comprehension: 4.959sec.

!!

普通に回すよりは若干遅くなるものの、product の力が伺えますね。これが標準ライブラリ(というかC)のちからか…!

というわけで

単一 for なら内包表記で、入れ子なら itertools.product 使って単一 for で回すのがキレイにそこそこ速そう。

10.1. itertools — 効率的なループ実行のためのイテレータ生成関数 — Python 3.5.2 ドキュメント

ちなみに、product(range(n), range(n), range(n))product(range(n), repeat=3) とも書けます。

ちなみに

単一 for でも、回したいシーケンスが range では上手く表現できないときは、内包表記渡すかジェネレータ式渡すか、ですが、メモリ的なこと考えるとジェネレータ式渡したほうがよさそうではある?

面倒なのでやりませんけどね!😇

てか

なんでこんなに内包表記が遅くなったんでしょ?

def if_for(n):
    a = list()
    for i in range(n):
        if i % 2 == 0:
            a.append(i)
    return a


def if_comprehension(n):
    a = [i for i in range(n) if i % 2 == 0]
    return a

if __name__ == '__main__':
    n = 10**7
    # for func in (generator_and_comprehension, generator_and_for,
    #              product_and_for, product_and_comprehension):
    for func in (if_for, if_comprehension):
        print("{}: {:.3f}sec.".format(func.__name__, calc(func, 3, n)))
if_for: 2.967sec.
if_comprehension: 2.430sec.

ふむふむ。内包表記 if いれるだけでこんなに時間が接近するとは。

もしかして、入れ子がダメなのか?

def for_for(n):
    a = list()
    for i in range(n):
        for j in range(n):
            a.append(i+j)
    return a


def comp_comprehension(n):
    a = [i+j for i in range(n) for j in range(n)]
    return a

if __name__ == '__main__':
    n = 3500
    # for func in (generator_and_comprehension, generator_and_for,
    #              product_and_for, product_and_comprehension):
    for func in (for_for, comp_comprehension):
        print("{}: {:.3f}sec.".format(func.__name__, calc(func, 3, n)))
for_for: 3.454sec.
comp_comprehension: 2.177sec.

ほほう🤔約1.5倍なので、これは最初にやった単一forと変わらないですね。

内包表記、if 入れると遅くなるのか……?

結論

if はヤバイ(?)

*1:桁を切れ

おかゆのAtomのパッケージのメモ

色んな人のオススメ記事をはてブしまくってたのだけど、整理したいから記事にまとめる。

Win10です。

その前に

grooyv.hateblo.jp

結局フォントはこれにしました。

pasolavo.com

基本のショートカットキーの一覧。ほげげ~~~!ってなる。

  • 行全体選択 ctrl + L
  • 行削除 ctrl + shift + K
  • コメントアウト ctrl + /
  • 行をブクマ ctrl + alt + F2
    • ブクマに飛ぶ F2
    • ブクマ全削除 ctrl + shift + F2
  • シンボル検索・移動 ctrl + R
  • ワード単位でカーソル移動 ctrl 押しながら → ←
  • カーソル位置のワード選択 ctrl + D
  • 括弧の開始・終端間の移動 ctrl + M
  • 括弧の中身の選択 ctrl + alt + M
  • コマンドパレット ctrl + shift + P
  • ファイル検索 ctrl + P

このあたりは覚えたい(おかゆが)

それから、テーマは seti-ui とか atom-material-ui とか標準の one dark。syntaxテーマは monokai 使ってます。

パッケージ

トテモベンリー

japanese-menu

日本語化してくれる。トテモベンリーのトップに書いておきながら、ふだんは disable にしている(なんとなく)

atom-runner

alt + R で開いてるファイルを実行できるぞ!(嬉しい)

alt + shift + R で、選択範囲のみの実行もできる。

symbols-tree-view

画面の右側に定義した関数とかクラスとか変数とかのリストが出てきて、クリックするとそこまで飛んでくれるヤバイやつ。

デフォルトでも ctrl + R があるけど、こっちのが便利。

minimap

スクロールバーのところにマップが表示される。

minimap-autohide

minimapが隠れてくれる。

symbols-tree-view も使うときや、minimap を左に置いておきたいときとかは使わないほうがいいっぽい。

git-plus

gitの操作がAtomでできるようになる。shift + ctrl + H

commit, add, push まわりのショートカットもあるみたい。

Python

MagicPython

シンタックスハイライト。関数アノテーションにも対応している。他にもいろいろと魔法がある。

使うときは Atomデフォルトの language-python を disable しておこう。

linter-pep8

Python の pep8 に則って美しいコードになるよう(うざいまでに)指摘してくれる。

別パッケージの linter が必要みたいだけど、このパッケージのインストール中に勝手にインストールしてくれた。

python-indent

pep8 的にいい感じにインデントしてくれる憎いやつ

アルトベンリー

fonts

パソコンにインストールしてあるモノスペースなフォントを列挙してくれる。

Atomデフォルトだとフォント名手打ちしないといけないので、割と助かる(誤字の多い人)。

advanced-open-file

デフォルトの ctrl + P をアドバンスしたもの。ctrl + alt + O です。

project-manager

プロジェクトを色々変えれる(雑)。alt + shift + P でつくってあるプロジェクトのリストが出る。

プロジェクトの作成は、おかゆは、ツールバーの packages からの Project Manager で色々してる。

管理データは cson で、titlepaths の形式。

file-icons

かわいい

emmet

HTML系。あんま書かないけどどこかで激推しされてたから一応入れてる

autoclose-html

これもHTML系。勝手に閉じてくれる。

参考記事(はてブしてたの)

せや!コイツも疲れとるやろしインタプリタ閉じたろ!

1/3の確率で「ンゴwww」と言いながら、その関数を実行せずにインタプリタを閉じてくれるクソムカつく優しいデコレータを作りました。

# coding=utf-8

import random
import functools


def bebna(function):
    @functools.wraps(function)
    def _(*args, **kwds):
        x = random.choice([False, True, True])
        if x:
            return function(*args, **kwds)
        else:
            print("ンゴwww")
            quit()
    return _


@bebna
def print_hello():
    print("Hello!")

実行例:

>>> import bebna
>>> bebna.print_hello()
Hello!
>>> bebna.print_hello()
ンゴwww

自分で作って自分で遊んで氏ねって思いました。

あまりにも実用性がないので、少し一般化しました。

import functools
import random


def may_fail(fail_action, fail_percent=10):
    if not isinstance(fail_percent, int):
        raise TypeError
    if not (0 <= fail_percent <= 100):
        raise ValueError

    random_list = [True]*(100-fail_percent) + [False]*fail_percent

    def fail_decorator(function):
        @functools.wraps(function)
        def _(*args, **kwds):
            x = random.choice(random_list)
            if x:
                return function(*args, **kwds)
            else:
                return fail_action()
        return _

    return fail_decorator

たまに失敗しうるような関数を作れます。失敗したときの挙動は関数として渡せます。

使用例

def fail_action():
    print("failed.")


@may_fail(fail_action, 50)
def test():
    print("success.")


for _ in range(20):
    test()

結果

success.
success.
success.
failed.
success.
success.
failed.
success.
success.
success.
failed.
success.
failed.
failed.
success.
success.
failed.
failed.
failed.
success.

なんかたまに失敗しそうなやつの代わりに使えそうですね(?)

あるいは、関数の中身自体は書き換えたくないけど、こいつが時々挙げる例外に対する挙動をシミュレートしたいってときに失敗率100%にし、当該例外をあげる関数を渡して、デコレートするとか、そういうのならまだ使いみちはありそうですね(ユニットテストのモジュールに既にありそう)

ZpDIC for ponjo jbopre

www.adventar.org

18日目です。

ZpDIC って知ってる?

ZpDIC は Ziphil さんが人工言語開発のための辞書ソフトということで作っている辞書ソフトです。

今まではローカルで使う人工言語の辞書としてはPDICが主流だったと思いますが、今年(だよね?)に ZpDIC が公開されて、今後の動向が気になるところです。

今までのロジバン辞書

ロジバンの単語は、 jbovlaste: A Lojban Dictionary Editing System を公式サイトとして登録・管理されていますが 見にくい

おそらく最近ウェブ上*1で一番まともにロジバン単語が検索できるのは la sutysisku です*2

la-lojban.github.io

ローカルでなら、おかゆの知ってる限りでは、guskantさんが作った stardict 形式の辞書データを使う方法がベストかな。

lo jbovlaste pe la stardikt

参考:lela.iúk.tánxe - オフラインでロジバン辞書を使う

stardict 形式に対応した辞書ソフトならロジバン辞書になるのが強みです
たとえば、iOS なら Dictionary Universal を使えます*3

ただこのstardict、Winしか使えない情弱なおかゆとしてはよく分からない対象で、guskantさんがstardict形式へのコンバータのスクリプトを公開してくれているものの、情弱*4的にはよく分からなくて与えられたものを使うだけのおかゆになっていました。

それから、(おそらく)基本的に stardict形式の辞書ソフトは read onlyで、たとえば「ロジ日辞書の悪いところをまとめてローカルで編集するぞ!」というようなときには使えません。

純粋なユーザーとしてロジバンを楽しむ分には辞書編集機能というのは必要ないと思いますが、ここで会ったが百年目、きっとあなたはロジバンを学ぶにつれモヤモヤし、アァ!と言い、.oisai と叫ぶことでしょう。

となると、編集機能のある PDIC でロジバン辞書データを作ればいいわけですが、なんか微妙に使いにくくてやる気がありませんでした*5

ZpDICでロジバン辞書をひこう!

そこで、知り合い(ということにしておいてください)でもある Ziphil さんが作った新しい辞書ソフト!*6が対応している形式でロジバン辞書データを作ろうと思いたちました。

ZpDIC は、これまた知り合いであるスライム氏などが考えた OTM-json 形式をメインにサポートしています:

OTM-JSON | 人工言語学 Wiki | Fandom powered by Wikia

とはいえ中身は json なので、これなら la .piton. しか使えないおかゆにも色々融通が効きます!というわけで、公式jbovlaste の吐き出してくれる xml ファイルを OTM-json 形式に変換したロジバン辞書データというのをおかゆは作りました。

github.com

"otm-json" フォルダに最近のxmlを変換した OTM-json 形式を入れてあります。これを使ってくだちい。

余談

余談ですが、"OTM-json" という名称は "OneToMany json" ということで、これ自体には「人工言語辞書用の形式だよ」ってことは意味されません。ので、おかゆ的にはもう少しそれを仄めかした名前のがいいんじゃないかなと思ったりします。

たまにおかゆは "dicson" とか読んでます。"dictionary" な "json" だから "dicson" です。「人工」感も盛りたいなら "condicson" とかになるかもしれませんが、この辞書形式それ自体は恐らく自然言語にも対応するはずなので、単に "dicson" でいいかなって思っています。

"OTM-json" より書きやすいし読みやすくないですか?

ZpDIC jbovlaste のここがすごいよ! i'ese'i

la sutysisku や stardict形式では、公式jbovlaste にはある "glossword" や "keyword" の欄は表示されません。些細ですが、その定義を登録した人の名前もこれらの辞書ツールでは省かれてしまっています。

おかゆは激怒した。必ず、かの邪智暴虐のjbovlasteの項目に忠実に対応しなければならぬと決意した。

というわけで、ZpDIC用にはこれらの項目を盛り込みました。Etymology も入れたかったんですが、残念ながら Etymology は xml ファイルにそもそもデータが載ってなくて諦めました…。ので、正確には、xml に載ってる情報はほぼすべて盛り込みました。

さらにさらに!ロジ日の辞書を引いたことがある人は分かると思いますが、たとえば {sirji} の Notes 欄:

「zu'a cmana .i ri'u xamsi .i fo le pa sirji pluta fa lo litru cu klama/左は山、右は海、その一筋道を旅人は行く」(山頭火『行乞記(二)』) ・大意: まっすぐ ・読み方: スィルジ ・関連語: korcu, linji, kruvi, kuspe

ロジ日の辞書の Notes はコンテンツが盛りだくさんです!具体的には

  • 大意
  • 読み方
  • 語呂合わせ
  • 関連語

の4つが Notes に入っています(関連語については他の辞書でもありますが、他の3つは日本語辞書独自だと思います)。

とはいえ、この4つ、本来は別に項目を持っておくべきもの。jbovlaste の形式は残念ながらこれらに対応していないため、Notes 欄にぶちこまれています*7

OTM-json版では、これら4項目は Notes から分離しています!

さらにいえば、「大意」は "glossword" に統合されています。

たとえば{klama}はこんな感じになります*8

f:id:waraby0ginger:20161216022221p:plain

というわけで、少なくとも jbo日辞書に関しては、la sutysisku よりも使いやすいものになってるんじゃないかと思っています。

まとめ

ZpDIC for lojban はいいぞ。

追記 2016/12/18 1:20

という声をいただき、そして確かにそうだと思ったので、"otm-json/test" に、glossword を translation のほうに移したデータを置いています。

*1:ネットに繋がなくても動くみたい

*2:数年前ならvlasiskuというのがありました(懐かしい…)

*3:有料(しかも割とする)ですけどね!Androidの方は分かりません。fau'u

*4:情弱と言ってればなんでも許されると思ってる節がありませんか?

*5:個人差があります

*6:おかゆは割とミーハーです

*7:「大意」については"glossword" があるのでそちらに移植すべきですが、ロジ日辞書翻訳の経緯上、Notes欄で今もなお息を潜めております。

*8:どうしてさっきは{sirji}を例に挙げたのに、ここでは{klama}を例に出したのか。聞かないでください。

ko jbosarxe .iu ciska -1 mo'o-

www.adventar.org

16日目です。もう折り返し地点ですね。

「か、勘違いしないでよねッ!こ、コこッこれは別に、私がそう思ってるってだけなんだから……」

はい(はいじゃないが)。

{ko jbosarxe .iu ciska} 「ロジバン調和的♡に書こう」(直訳)という題です*1*2

この記事のコンセプトは「ロジバンの基礎的な部分を少し意識して、ロジバンに馴染んだ表現を心がけてみよう」です。

ma jbosarxe

「私たちが表現したロジバンが、ロジバンらしさだよ!」*3というのはもっともですが、ロジバンはそれでもやはり「哲学的言語」あるいは「工学言語」です。そこにはロジバンの根本の構築を手掛けた製作者たちの何らかの意図があると思うわけで、いくら「ロジバンが無色の粘土で、表現者次第でいろんな色を付けられる」としても、その意図と完全に反するような開発や表現は、―おそらくロジバンはそれを許容し、そしてかつ実現さえしてくれるでしょうが―あんまりキレイな色に仕上がるとは思えないというのがおかゆの気持ちです。

あるいは:確かに無色の粘土だし、それに表現者がいろんな色をつけて遊ぶことはできるけど、やっぱり根本の思想に基いたスタイルを使えば、よりシンプルで素直な表現ができるだろう、というのはあると思うわけです。プログラミング言語でも「そのスタイルで実装できなくはないけど、その言語の哲学・仕様上、このスタイルで実装したほうが分かりやすいし素直」みたいなことあると思いますが、それと似たような感じです(プログラミング言語もロジバンも人工言語ですからね)。

というわけで、そういう「根本の思想に基いたスタイルを使った表現」というのをこの一連の記事では {jbosarxe} と称したいと思います。

一連の記事でやること

ですから、やるべきことは喩えるなら「ロジバンが無色になりきれてないところってどこだろう?」ということを追求することです。 とはいえ、この追求はある意味で jboske(ロジバン学)における究極的な問いかけへの挑戦にも思えます。 恐らくヲかゆは今回の2016年アドベントカレンダーでこのことに完全に答えることはできないでしょう。 それでも、ここでいくらか足掻いておけば、まあ誰かが続きを考える材料くらいにはなるでしょう a'o。

対象のタイプについて

おかゆが最初に目をつけるのは「ロジバンで現れる対象のタイプ」です*4

ロジバン学習の途中で、{tu'a} について学ぶときに "sumti-raising"(sumti昇格)という用語に出会うかと思います。これは「モノはコトではありえない」という認識からくるものでしょう。一般的に「出来事」が入るべき述語の引数位置に「物」を入れることはできないので、{tu'a}を冠する必要がある、というわけです*5

というわけで、ロジバンの not unofficial な機能語としてそういう「対象のタイプ」を意識した語があります。ですから、ロジバンに現れる対象のタイプをきちんと把握することは、jbosarxe に一歩近づく道だと思うわけです。

では、ロジバンの世界には一体どんなタイプの対象があるのでしょう?有名な入門講座 lojban wave lesson に "Types" という章があり、そこではまさにロジバンに現れる対象のタイプについて説明がなされています。あいにく、この章はまだ日本語訳されていませんから、まずはこの章の内容をかいつまんでいきます。

lojban wave lessons - Types

知りたいのは、ある程度共通認識となっている(であろう)対象のタイプに関してです。LWL(Lojban wave lessons)では、次のタイプを挙げています:

  • Material object
  • Event
  • Selbri
  • Amount
  • Concept
  • Bridi
  • Text
  • Set
  • True value

雑に日本語で:

  • 物体
  • 出来事
  • selbri・属性・関係
  • 概念
  • bridi・命題
  • 文・テキスト
  • 集合
  • 真理値

の9種です*6。それぞれが具体的にどういうものなのかというのは、補足として最後に載せておきます。確かにそれぞれの対象が何であるかというのは理解のために必要ですが、「何であるか」という問いに一定の答えを与えようとするにはどうしても一つの哲学的立場を導入しないといけないと思うからです。

おかゆ的には、これに「数値・数」を入れるべきかと思います。{li pa} とか、そういう表現が表示する対象です。

というわけで、ロジバンに出てくる対象は、合計10種類のタイプのどれかだということになります。物体タイプには膨大なサブタイプがあるだろうというのは分かるとしても、それだけ?という感じはします。

「物体タイプがカテゴリとして膨大すぎる」という意見があるかもしれませんが、まあこれは程度問題でしょう。いずれにせよ、物理的実体という大きな枠組みがあることは確かです。むしろ、そんなことよりももっと重大なことに気づくべきです。

「時間」と「空間」はどこ行った?

と、その前に:「対象が存在する」ということについて

ロジバンの「時間」と「空間」について考える前に、そもそも「ロジバンの世界に現れる対象」ってなんなのかという話をしておきます。

「対象が存在する」、もう少しおかゆ的にきちんと言えば「ロジバンにおいて対象化される」とは、項の値になれるということです*7。有り体に言ってしまえば、{da} や {bu'a} によってアクセスできないようなものは、ロジバンでは存在言明ができません。そのようなものは、「ロジバンの世界において対象化されない」、あるいは「ロジバンの世界においては存在しないもの」として扱うことになるでしょう。だって存在論的言及に引っかからないんだもん( ᕦ 。 ᕤ)

さて、ロジバンは内容語として(少なくとも gismuだけを考えても)1000以上の述語を備えています。これはロジバンにおいてどんなものが対象化されるのかということを規定し(てしまい)ます。用意された述語セットによってどんなものが {da} されるのかがある程度決まってしまうという話です。この基本セットは、ロジバンの根本的なところの存在論(これはまさに「無色になりきれていない」ところ)を規定します*8*9

おかゆは、余程のことがない限りgismuセットに現れないものは今後も現れないと考えます。これらの述語セットは、互いに結びついて、ネットワークを形成します。このネットワークのおかげで、ある述語の項の値になれる対象はそのネットワークに参与することで、ロジバン世界に上手く組み込まれることになります。もちろん、述語の基本セットの下では現れないような対象も、新たに内容語を導入することで(無理やり)対象化することができます。しかし、そのようにして対象化した対象は、他のどの述語の項の値にもなれないわけで、既存の述語ネットワークからは孤立した存在です。そのような対象がロジバン世界において有意義であるとは思えません。「余程のことがない限り」と言いましたが、このことを踏まえて、その対象を項の値とするような述語の拡張セットをつくり、その小さなネットワークを既存のネットワークとうまく接続してやれば、その対象は細々とではありますがネットワークの中に上手く組み込まれることになり、いくらか使用に堪えるようになるはずです。

ロジバンの対象タイプの少なさを意識しよう

直前の話は、結局のところ、なぜ「時間」と「空間」がロジバンの対象のタイプにないのかということの一定の答えになります。単純に「述語の項の値にならないから」です。「どこ行った?」と言いましたが、そもそもこの2つは対象として「ロジバンには存在しない」というのがおかゆの答えです*10

しかしこのことは、時間的・空間的なことに関する言明がロジバンでは不可能だということではありません。ロジバンでは、そのような言明を、時間・空間を対象化せずに、手元にある少数のタイプの対象を用いて間接的に行ないます

detri : x1 is the date [day,{week},{month},year] of event/state x2, ...

djedi : x1 is x2 full days in duration (default is 1 day) ...

ロジバンでは、日付―出来事の時間的な位置―を、時間という対象に言及せず、数(tcika1)と出来事(tcika2)の関係によって間接的に表現します。同様に、出来事の時間的長さも、そのような対象を用意せずに、あくまで出来事の一性質(正確には出来事と数の関係)として表現するのみです。あえて「時間」の在り方について答えるとすれば、それは「述語の中」ということになります、対象化されないがしかし言及すべきことについて述語が上手くラッパーとして働き、既存の少数の対象タイプによってそのことについて語れるようになっている(逆に言えばそのようにしか語れないようになっている)わけです。

このことから引き出される最も重要な教訓は、自然言語の名詞句表現に対応する項表現が必ずしもあるわけではないということでしょう。まあこのことはどんな2つの自然言語にでも言えそうですが、ロジバンではより顕著だと思います。他言語において名詞で(対象的に)表されるものが、ロジバンでは述語に組み込まれた形で(つまり対象としては存在せずに)存在しているということが往々にしてありえるわけです。

ロジバンには概ね10種の対象のタイプがあり、述語はそのタイプだけを項の値として取るようにインターフェースを整えています(実際は先述の通り、述語がそのような仕様だから結果的に対象のタイプの在り方がこのようになっているわけですが)。このことを意識しておけば、他言語のどの部分を項として、どの部分を述語として分析してロジバンに翻訳すべきかということがかなりスムーズに行えるのではないかと思います。そして、当の目的である jbosarxe な表現というのは、明らかにこのインターフェースに従った書き方によってなされるはずです。

あとがき

書きたいことは割と書いてしまいました。2 mo'o はあるかもしれませんが、それはアドベントカレンダーの外かもしれません。お疲れさまでした。

補足:9タイプそれぞれの概要

物体(Material objects)は、時空間上に居場所をもち、時間経過に対して不変(非時間的)であるように捉えられるような対象のタイプのことです。

出来事(Event)は物体と同じく時空間上に位置するものの、物体と異なり時間経過に従って展開するようなものとして捉えられるような対象のタイプのことです(直観的に「出来事」で捉えていいと思います)。端的にいって、nu1 です。*11

属性・関係(Selbri)は、端的にいって ka1 のことです。出来事とちがって非時間的な抽象的対象です。「緑であること」「愛すること」等々。属性か関係かというのは、単純にロジバンでは節内の{ce'u}の数によります:1つなら属性で、それ以上なら関係です。そう考えるとたしかに Selbri と呼んじゃうほうがロジバンでは自然な気がします。

量(Amount)は、端的にいって ni1 のことで、或る性質がどれだけ適合しているかを表すような対象のタイプです。量は、定量が実際に可能かどうかはさておき、何らかの数で表現されるようなものです*12

概念(Concept)は、端的にいって si'o1 のことです。ka や ni と顕著に異なるのは、節の無記述な位置の引数が zo'e でなく全て ce'u と解釈されることです。

BPFK Section: Abstractors - La Lojban

ヒントとして、恐らくロジバンの概念は概ね「[内容語の大意]という概念」というところのものです*13。ひとつの考え方によれば、対応する概念を理解することで話者はその内容語を適切に使えるようになります。たとえば、私たちが或る事態を {klama} という内容語を述語に用いた文で表せると思えるのは、{klama}の概念を理解していて、事態をそのように分析・分類できるからです。*14

命題(Bridi)は、端的にいって du'u1 です。素朴には「叙述文の表すこと」です。たとえばロジバンの文法講座で、ある形式の文と別の形式の文の意味が同じだというのは、概ね、その2つの文がそれぞれ表す命題が同じものだということです。

テキスト(Text)は、テキストです。表現と言ってもいいかもしれませんが、まあ、テキストです。

集合(Set)は、あの数学の集合のことです。

真理値(Truth value)は、端的にいって jei1 です。True とか False とか Mostly true とか、そんなアレです。数字で表現できますが、数字そのものではありません*15

補足:「空間」はないのか?

本文では「時間」が確かにロジバンでは述語に内部化されていることは見ましたが、「空間」については見ませんでした。それは単に「微妙だな~」と思ったからです。

ただ、この話、少し長くなりそうなので、2 mo'o にまわします。

先取りしておくと、経験的にロジバンで空間・場所・位置を指示するようなことがあったような気がするけど、あれはどうなんだろう?…というあたりです。

co'oru'e

*1:{cusku}のがより正しいとは思うが、まあいいでしょう

*2:これを書こうかなと思ったのは2週間前で、そのときちょっとテンションが高かったので、今は後悔しています .u'uru'e

*3:某さおりん

*4:以下で論じる「タイプ」というのは論理学の用語でいえば恐らく「ソート」に相当するものです

*5:実際の運用で「出来事」が入るべきところに、一般に「物」を表す表現が入っていた場合、聴き手にできることは2つあります:1つはsumti昇格で、そのような「物」が関わっている「出来事」と解釈すること。もう1つは、本来「物」として捉えられる対象それ自体を「出来事」として捉えようとすること。

*6:実は Function もありますが、これは Selbri, Amount, Concept の総称としての分類なので抜きました

*7:Technicalな話をすると、ここで言った「項」というのは一階述語論理的な項だけでなく、少なくともロジバンデフォルトにおいては二階述語論理的な項(つまり述語)も意味します。試験的cmavoも含めれば、{bu'ai}がありますからより高階の述語論理における「項」も意味しえます。

*8:ここは少し暗黙に前提を入れていて、「ロジバンの基本単語セットをすべて受け入れるのであれば」の話です。

*9:さらに言えば、これは少し語弊があります。「根本的なところの存在論」と言ったのは、個々にどういったものが存在するかということよりは、どんなものが差異化・相対化されるような存在論的構造かというようなことです。後述のネットワークという語を使えば、各話者はその述語ネットワークの構造だけを共有していれば十分で、そのノード(項の値)が具体的にどんなものであるかということについては各話者の存在論によるはずです(なんか難しくなってきたので逃げます)。

*10:ただし「空間」については議論の余地があります。詳しくは補足で。

*11:架空の出来事はどうなんでしょうね。おそらく、「時空間上に位置する」というのは客観的事実としてではなく、あくまでその対象に対しての話者の認識・捉え方がそうであるということでしょうから、架空の出来事であっても、それが出来事タイプとして捉えられているなら出来事でしょう。

*12:とはいえ、やっぱり原理的に定量不可能なものの量(ボブとの友だちである量;ボブとの友情量?とか)にはあんまり使用しないほうがいいだろうという声もあります。……でも、「定量可能性」って何???

*13:もちろん、si'o は節をとるので、正確に言えば、「[内容語に相当するような表現の大意]という概念」とでも言うべきです

*14:このあたりの話は、ロジバンの内容語がすべて述語的であることとかなり深く関連すると思っています。たとえば、ロジバンにおいて、私たちは日本語の名詞「犬」に対応するいう概念を持ち合わせてはいません。あくまで私たちは {gerku} という或る事態的・関係的な概念を持っているだけであり、…つまり、個体的な概念というのはロジバン話者としては持ち合わせていないはずです(ただ、この分析は少し古いかもしれず、認知言語学のフレーム理論とかベース・プロファイル関係を用いれば、日本語においても実際はロジバンのような関係的な概念をもっているだけ…というような話になるかもしれません。ただ、あまり詳しくはないので、この程度に留めておきます)。

*15:と言いながら、LWLでの例文は{li pi bi jei la tinjin cu mikce}となっており、jei1 は数が入っていました。もし jei1 に数が入るのであれば、ロジバンの対象タイプに真理値なんてないでしょ…と思うのですが、よく分かりませんね。おかゆとしては、「数字で表現できる」という以上、真理値(jei1)とその数値による表現を関係づける述語を用いて記述すべきだと思いますが。或いはせめて、{la'e li pi bi jei la tinjin cu mikce} にしてほしいですよね。とはいえ、{la'e}による間接的な参照でしか真理値という対象がありえないのなら、本文中でも述べた通り、わざわざ真理値なる存在にロジバンでアクセスするのは na jbosarxe かと思います。

ConEmu の設定メモ

サンシャイィ~~~~~~~ン

Co~

nッ!バシュッ!

E~muゥ……

イェェエエエエエエエエエエエエエエエエエエエエエエエエエ!

サンシャイン池崎だいすき、おかゆです。

conemu.github.io

ConEmu は、いい感じのターミナルエミュレータ?です*1。おかゆは情弱で Emacs とか Vim とかはちょっと使えない人*2なので、ConEmu を入れています。

だいぶ前に ConEmu は入れて愛用していたんですが、別PCに入れる際に設定のこと全く忘れていたのでこの機会にと思いメモ。
というか、お役立ちページをまとめておく。

ちなみにインストール版を使いました。

Windows:コマンドプロンプト代替をConsole2からConEmuに変更

  • Main の monospace のチェック外し
  • Main > Size & Pos, AlignmentのCenter console…にチェックを入れて、右側のPad Sizeに 10px 設定。
  • Main > Appearance, Title bar (caption)…のHide caption always(タイトルバーを無くす;すっきりして可愛くなる)。
  • IntegrationのRegisterボタンを押す(エクスプローラで右クリックから ConEmu 起動できる)
  • Features > Colors から Schemes を "monokai" に(お好きなのをどうぞ)

上のサイトを参考に基本の5項目を設定。さて次~

qiita.com

フォントを変えたいならこれに従う。色々試した感じ、結局 Ricty Deminished かなって感じ。

  • 画面を縦横に分割したい場合は、右上の + ボタンを右クリック -> "New console split" をお好きに。

今回使わなかったけど今後読むかもしれない記事たち

qiita.com

qiita.com

qiita.com

*1:ふくし…?の大学に通ってるんですけど!

*2:お米