eoml0001
の編集
https://khfdpl.osask.jp:443/wiki/?eoml0001
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
2016_10
2016_11
2016_12
BracketName
Essen
Essen0
Essen1
Essen2
Essen3
Essen4
EssenMemo0001
EssenMemo0002
EssenMemo0003
EssenMemo0004
EssenMemo0005
EssenMemo0006
EssenMemo0007
EssenMemo0008
EssenMemo0009
EssenMemo0010
EssenMemo0011
EssenR2
EssenR2_ess03f
EssenR2_ess03h
EssenR2_ess03i
EssenR2_ideas
EssenR2_jit00
EssenR2_jit01
FormattingRules
FrontPage
Help
IP
InterWiki
InterWikiName
InterWikiSandBox
K
KHPC
KHPC_v000doc01
KHPC_v001doc01
KHPC_v002doc01
KHPC_v003doc01
MenuBar
OSC
OSC20181027
OSC20190222
OSC20191123
OSC20230401
OSC20230528
OSC20231021
OSC20240310
OSC20241026
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
SltVA
VariableArray
WikiEngines
WikiName
YukiWiki
advcal20161205
advcal20161206
advcal20161209
advcal20161210
advcal20161215
eoml0001
eoml0002
essen_ex01_0001
impressions
kcl_malloc
khfdpl_result1
members
memo0001
memo0002
note0001
note0002
note0003
note0004
note0005
note0006
oldworks
oldworks00
oldworks06
oldworks12
oldworks13
osaskjp_index
persistent_C
populars
pr20161105
pr20161105b
scsc
seccamp2017
spam_test
uxf
uxf_01
uxf_02
uxp
* Essen Object Management Library #0001 -(by [[K]], 2017.01.31) ** 基本型 -通常データ: --intとかdoubleとか文字列型とか、まあなんでも。 --サイズが規定できればよい。型のタイプも記述する。 --可変長でもあってもいい。 -メタデータ: --通常データと似た扱いを受けるが、多少の追加サポートがある。 --(dir) (memberTable) (namelessDir) ** ディレクトリ -Essenにおけるディレクトリは、構造体と配列を融合したようなもの。 -たとえば以下のようなデータを考える。 (a:1 b:2) -このデータをシステムは以下のように管理する。 p0: (dir)[p1 p2 p3] // p1がメンバ名情報, p2とp3は値. p1: (memberTable)[2 p4 p5] // 2はメンバ総数, p4とp5は名前. p2: (int)[1] p3: (int)[2] p4: (string)["a"] p5: (string)["b"] -このとき、さらに以下のような記述をしたとする。 (a:3 b:1) -このデータは次のように管理される。 p6: (dir)[p1 p7 p2] p7: (int)[3] --つまり、データは共有される ---ただしデフォルトで自動共有されるためには条件がある ---しかし明示的に共有を指示すれば確実に共有部分は共有される ---自動共有がデフォルトではない最大の理由は、重複排除のための比較にそれなりにコストがかかるため。 ---もちろんハッシュ値などを使って高速化するが、それでも何もしないよりはどうしたって遅い。 -さらに以下のようなケースを考える。 (0:(a:1 b:2) 1:(a:3 b:1)) -このデータは次のように管理される。 p8: (dir)[p9 p0 p6] p9: (memberTable)[2 p10 p2] p10: (int)[0] -ただし、メンバ名が(int)で0,1,2,...の場合に限って簡略表現を用意したい。そうすればメンバーテーブルの氾濫を緩和できる。 -メンバ名を持たないディレクトリも作れる。 ((a:1 b:2) (a:3 b:1)) → (namelessDir) [2 p0 p6] --まあそれぞれの名前をnulにしても同じことはできる。しかし出現頻度を考えると、内部的に(namelessDir)があったほうが有利だと思う。 -(註)初期のバージョンのEssenでは双方向リストを使ってこれらを管理していたが、今後のバージョンではこのように双方向リストを使わない実装をメインに据える。 ** 配列 -メモリをより節約したいという観点では、ディレクトリのメンバの型がすべて同じときには、それらをまとめられる機能がほしくなる。 --でもそんなことをしても大して節約できないのかもしれない。 --ということでまずは検討してみる。効果が大したことなければ没にする。 -p8の内容を書きかえてみる。 p11: (array) [p9 p1 p2 p3 p7 p2] --これでどれだけ節約されたのか? --p0やp6の内容はいらなくなった。それでオブジェクト2つが節約できた。ポインタの数としては差し引き3個得した。 --微妙だなあ。役に立っていると言えばそうなんだけど、内部タイプを増やすだけの価値があるかというと悩ましい。 -よし、悩んだときは作らない! ** サイズの省略 -(memberTable)でサイズを明示する必要ってあるだろうか?データのサイズは取得できるのだから、そこから分かりそうなものだ。 -(namelessDir)にもサイズは不要だろう。 ** 双方向リストのサポート -Essenの式評価アルゴリズムを考えると、要素の挿入や削除がかなり頻繁に繰り返されるので、双方向リスト的なものはやはり必要である。だからそのサポートも必要だ。 -双方向リストのノードは、前後が誰であるかという情報を持っているので、そのポインタ情報があだとなって値が同じでも共有はまずできない(=他と同じ値になることはまずないだろう)。 -となれば、値だけを別のオブジェクトに追い出すことによって共有の可能性を高めるという方法は可能ではある。 (doublyLinkedList) [p0 p1 p2] --p0がprev, p1はnext, p2がvalueへのポインタ
タイムスタンプを変更しない
* Essen Object Management Library #0001 -(by [[K]], 2017.01.31) ** 基本型 -通常データ: --intとかdoubleとか文字列型とか、まあなんでも。 --サイズが規定できればよい。型のタイプも記述する。 --可変長でもあってもいい。 -メタデータ: --通常データと似た扱いを受けるが、多少の追加サポートがある。 --(dir) (memberTable) (namelessDir) ** ディレクトリ -Essenにおけるディレクトリは、構造体と配列を融合したようなもの。 -たとえば以下のようなデータを考える。 (a:1 b:2) -このデータをシステムは以下のように管理する。 p0: (dir)[p1 p2 p3] // p1がメンバ名情報, p2とp3は値. p1: (memberTable)[2 p4 p5] // 2はメンバ総数, p4とp5は名前. p2: (int)[1] p3: (int)[2] p4: (string)["a"] p5: (string)["b"] -このとき、さらに以下のような記述をしたとする。 (a:3 b:1) -このデータは次のように管理される。 p6: (dir)[p1 p7 p2] p7: (int)[3] --つまり、データは共有される ---ただしデフォルトで自動共有されるためには条件がある ---しかし明示的に共有を指示すれば確実に共有部分は共有される ---自動共有がデフォルトではない最大の理由は、重複排除のための比較にそれなりにコストがかかるため。 ---もちろんハッシュ値などを使って高速化するが、それでも何もしないよりはどうしたって遅い。 -さらに以下のようなケースを考える。 (0:(a:1 b:2) 1:(a:3 b:1)) -このデータは次のように管理される。 p8: (dir)[p9 p0 p6] p9: (memberTable)[2 p10 p2] p10: (int)[0] -ただし、メンバ名が(int)で0,1,2,...の場合に限って簡略表現を用意したい。そうすればメンバーテーブルの氾濫を緩和できる。 -メンバ名を持たないディレクトリも作れる。 ((a:1 b:2) (a:3 b:1)) → (namelessDir) [2 p0 p6] --まあそれぞれの名前をnulにしても同じことはできる。しかし出現頻度を考えると、内部的に(namelessDir)があったほうが有利だと思う。 -(註)初期のバージョンのEssenでは双方向リストを使ってこれらを管理していたが、今後のバージョンではこのように双方向リストを使わない実装をメインに据える。 ** 配列 -メモリをより節約したいという観点では、ディレクトリのメンバの型がすべて同じときには、それらをまとめられる機能がほしくなる。 --でもそんなことをしても大して節約できないのかもしれない。 --ということでまずは検討してみる。効果が大したことなければ没にする。 -p8の内容を書きかえてみる。 p11: (array) [p9 p1 p2 p3 p7 p2] --これでどれだけ節約されたのか? --p0やp6の内容はいらなくなった。それでオブジェクト2つが節約できた。ポインタの数としては差し引き3個得した。 --微妙だなあ。役に立っていると言えばそうなんだけど、内部タイプを増やすだけの価値があるかというと悩ましい。 -よし、悩んだときは作らない! ** サイズの省略 -(memberTable)でサイズを明示する必要ってあるだろうか?データのサイズは取得できるのだから、そこから分かりそうなものだ。 -(namelessDir)にもサイズは不要だろう。 ** 双方向リストのサポート -Essenの式評価アルゴリズムを考えると、要素の挿入や削除がかなり頻繁に繰り返されるので、双方向リスト的なものはやはり必要である。だからそのサポートも必要だ。 -双方向リストのノードは、前後が誰であるかという情報を持っているので、そのポインタ情報があだとなって値が同じでも共有はまずできない(=他と同じ値になることはまずないだろう)。 -となれば、値だけを別のオブジェクトに追い出すことによって共有の可能性を高めるという方法は可能ではある。 (doublyLinkedList) [p0 p1 p2] --p0がprev, p1はnext, p2がvalueへのポインタ
テキスト整形のルールを表示する