読者です 読者をやめる 読者になる 読者になる

ゆくゆくは有へと

おかゆ/オカ∃/大鹿有生/彼ノ∅有生 の雑記

もやもやのメモ

Go

構造体のセレクタ

golang.jp

セレクタは自動的に構造体へのポインタの間接参照を行います。xが構造体へのポインタ型のときx.yは(*x).yの簡略形として使用可能です。フィールドyも同じく構造体へのポインタ型のときx.y.zも同様に(*(*x).y).zの簡略形です。xが*A型の匿名フィールドを持ち、かつAも同様に構造体であるなら、x.fは(*x.A).fの簡略形です。

どおりで!

new()

golang.jp

組み込み関数newはパラメータに型Tを取り、型*Tの値を返します。

なるほどなあっ!

make()

golang.jp

スライス、マップ、チャネルはnewによる間接的なメモリ割り当てを必要としない、参照型です。組み込み関数makeはパラメータに型Tを取ります。このTはスライス、マップ、チャネル型でなければなりません。またオプションとして式のリスト(作成する種類によって異なる)を取ります。makeはT型(*Tではない)を返します。

なるほどなあっっ?

www.geocities.jp

スライスが配列へのポインタをもって云々というのは分かる(参照してる感が理解できる)けど、マップはどうしてるんだろ?キャパシティ云々のこと考えると、やっぱバックで適当に配列見繕ってマップパターンを実現してるのかな?

日本人のロジバン学習ロードマップ(たぶん)

lojban

オチ

学習 - La Lojban

ここを適宜読もう!

はじめに

この記事は、日本人(注:英語の教材を読むよりは日本語の教材を読む方が楽な人のことを指しています)がロジバンを学びたいときにどこを読んでいけばいいのかというのを書いたものです。

ですが、やっぱり最終的には英語のドキュメントにあたることになります。仕方ないですね。英語力も鍛えてください。

ここでは、できる限り基本は日本語で学べるような道を用意します。

まずはここから

間違ったスタートダッシュ

ロジバン - Wikipedia

やめときましょう(先人のアドバイス)。

正しいスタートダッシュ

はじめてのロジバン 第2版 - はじめてのロジバン第2版

は?宣伝です。

とは言え、ロジバンに興味をもって学ぼうとした人が訪れる場所は大抵「はじロジ」っぽいので、やっぱりここをオススメします。

「ニューゲーム」はほぼ完成(メンテナンスのみ)しているので安心して読めますが、その続編である「つよくてコンティニュー」はいまだ執筆中のようです(ようです?)。

とはいえ、とりあえず「ニューゲーム」だけでも読んでおけば、語彙も基本中の基本はそこそこ、文法は割りかし適度に追えるようになれるはずです。「つよコン」は…、出来上がってるところまで読んで、書き上がり次第フォローしていきましょう。

サプリメント

「はじロジ第2版」は音声に関してはめっきりなので、発音が気になるという人はこちらもオススメします:

ko lojbo .iu ロジバン入門

日本語の音声講座で、毎回の終わりに発音講座があります。そこだけ聞いてもよし、もちろん文法講座のところも聞いてよし。

その次は?

「はじロジ2」が完結すれば、この寄り道はいらないんですが、現状はここに立ち寄るのがベターらしいです。

seesaawiki.jp

「はじロジ2」を読んでいれば、入門コースは飛ばしても大丈夫だと思います。「PSの傾向」くらいは読んでてもいいかもしれない(雑学程度だけど)。

初級コースをかいつまみましょう。たとえば:

  • 品ある品詞:brivla の下位分類、gismu, lujvo, fu'ivla に関する簡単な説明がある
  • 命題を項に(抽象詞):{tu'a}の説明がある
  • 項で項を(pe,ne):{po}, {po'e} の説明がある(けど、実際に使う機会はほとんどない気がするので飛ばしてもOK)
  • アレ、云々(省略語):そこまで重要な話でもないが、体系的に語を覚えたいなら。

冠詞のところ、数詞のところ、分配性と集団性は読まなくてもいいです。というか読まないほうがいいかもしれない。理由は単に「分かりにくい」からで、はじロジ2でもっと分かりやすい解説がくるのを待ったほうがいいです。

補助資料や補習資料も気になるものに目を通せばいいと思います。

サプリメント

分配性と集団性についてどうしても気になる人で、かつ、論理学の素養がある程度ある人はここを読むのをおすすめします:

gadri の論理学的観点からの解説 - La Lojban

ただ…、まあそんな気にするものでもないです(アドバイス)。最近のロジバンはこのあたり特に考えなくても簡単に使えるようになっています。

その次は?

lojban wave lessons(おかゆはLWLと略す)を読みましょう!日本語訳版は現在2つあって、現在はlojban wikiの方がメインです。経緯としては、まず「味噌煮込みロジバン」での日本語訳があり、それが wiki に移行されました:

lojban wavelessons 日本語版 - La Lojban

misonikomilojban.blogspot.jp

はじロジと難易度・内容はそこまで変わりませんが、定番の講座ではあるので、一読をおすすめします。はじロジとは異なる視点でロジバンを理解しておくのも大事なことです。

サプリメント

Lojban Wave Lessons - La Lojban

英語版(原書)です。最後の数章は日本語に訳されていないので、どうしても読みたい場合は英語で読むことになります(が、まあこの時点で読まなくてもいい気はしないでもないです)。

割と読んできたけど?

ロジバン大全: The Complete Lojban Language 日本語抄訳

おかゆはCLLと略します。いわゆるロジバンの仕様書のようなものです。が、微妙に仕様が古いところがあります(特に冠詞まわりの意味論)。ので、あくまで参考ということで読むのがいいと思います。細かい仕様はCLLを見ないとどうにもならないことは確かにあります。

ただ、完読は結構しんどいとは思うので、気になるところだけ読みましょう。20章の「セルマホ目録」は便利な索引です。

サプリメント

The Lojban Reference Grammar

LRG。CLL日本語抄訳の底本(1.0)の改訂版。

さらにロジバンを知りたい人へ

ここからは英語になります。

BPFK Sections - La Lojban

BPFKは、ロジバンの意味論をいまいちど整理しようとして動いている委員会(公式)です。BPFK Sections は委員会によって整理・提案されている各機能語の意味論が載っています。CLLが微妙に気に食わないときはここを読んで気に入りましょう。

BPFK sections に載ってない場合は、各メーリスを覗くと色々分かるかもしれません。

  • ロジバン相談室:日本のロジバンメーリス
  • lojban:ロジバンのメーリス
  • BPFK:さっき言ったBPFKのメーリス(これについては英語どころかほぼ完全にロジバンだけによる議論です♡)

あ、あと、wiki 見ると何かあるかもしれませんね:

Lojban

このあたりを調べ尽くして無いようなら、多分ないです。

おわりに

まあオチは最初に書いたので言うことはないんですが、とりあえずこっちに来て一緒に苦しみ楽しみましょう!

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

python

括弧が逆ゥ!

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

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:桁を切れ

初期化が連鎖するダイヤモンド継承は__init__の引数がすべてのクラスで同じときだけにすべき

python

っていうメモ(あとで詳しく書くかも)。mix in はどうぞ好きなだけ多重継承してください。

なんで?

superの関係。

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

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系。勝手に閉じてくれる。

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

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

python

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

lojban

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}を例に出したのか。聞かないでください。