  |
はてなキーワード: フローチャートとは
集合論を表す音というだけで、集合論自体を直接操作するわけじゃない。そこが自然言語の数学との違いかもしれない。数学は位置関係が関わってくるから紙が必要だが、自然言語は必要じゃない。
具体的な形を持っていない。
＞意識が集まるというのはやはり話者の意識がその音に向けられるということでいいのかな。
話者というもの自体が、ある地点（あるいはフローチャートの前提？それは分からんが）への意識の集まり。話者は説明に必要無い。
＞「区切られる」とは？
空間における意識の在り方。論理における空間はフローチャートと集合論を合わせたものだが、フローチャートの側面に着目すれば「終止」となるし、集合論の側面に着目すれば「区切り」となる。
＞集合論って人間の意識を扱うものじゃないと思うけど、どういうこと？
そもそも人間の意識は集合論でもフローチャートでも無い。人間においては、人間の意識が前提にあって、そこに集合論が載っている。
＞「あり方の一つ」というのならどういうあり方なのか説明してほしい。
集合論的な、何と何が同じものである、というのにおける意識では、集中する状態と、気が散る状態があると考えている。ここでは気が散る状態を拡散と呼んでいる。
＞空間ってなに？ 話者が認識する現実世界の空間？ それとも数学の話？
論理における空間は、フローチャートと集合論を合わせたものと考えている。動けなければ空間では無いし、また一体性が無ければ空間では無い。
＞誰がなにを一つのものとみなすの？ 話者が aud- によって表されるなにかを一つのものみなすということ？ 例えば audio であれば具体的に一つふたつと数えられるものではないけどその場合は？
誰が、という事は考えていない。一人称かもしれないし二人称かもしれないし三人称かもしれない。a（意図の集中）u（区切り/終止）d（集合）のuの「終止」というニュアンスが強く働いているように思える。
対話しようじゃないですか。それが私にとっては一番です。
https://anond.hatelabo.jp/20171211180854
私は集合論とフローチャートが分かれば、それらの図示に過ぎないのだから分かると想定している。しかしなぜか分からないと返ってくる、という状態。
なにが分からないのか、論理的なレベルで分からない。論理的には説明として成立していると考えている。そこで何が分からないのか、どこを改良すれば良いのか対話したい。
数学には直感主義と形式主義があったはずだけど、直感主義がフローチャートってイメージは俺には無いな。知らないだけかもしれないけど。
論理的って、実は集合論とフローチャートの二種類を指しているんだよね。集合論はもちろんだけど、論理の弾き出すようなイメージはフローチャートのもの。
けどほとんどの人は論理が集合論とフローチャートの二種類だと意識していない。
もし音に意味があるとすれば、論理では表現できない曖昧なものか、論理である集合論とフローチャートなはず。
今までの言語学ではソシュール以後、音に意味なんか無い、あるとしても曖昧なものであるはずだ、というドグマのようなものがあった。
集合論とフローチャートの知識があっても（そっちもそんなにないのだが）日本語のことが分からなきゃ無理だよ
もっと詳しい増田が別の枝に来てくれたみたいだから、そちらに任せます
丁寧に答えてくれてありがとう
それぞれの図は、何か具体的な事物を表す集合とかフローチャートではなく、
集合やフローチャートと言う概念そのものを表してるということで合ってる？
そして、図に書き入れてあるアルファベットは数学で使うxとかの代数じゃなくて、アルファベットが表す音そのもの？
各音素が、集合やフローチャートの一部のような概念を司っており、
その組み合わせが、音素によって出来上がる単語の意味と一致する、という理論だと解釈した
コミュニケーションって歩み寄りだから、相性も必要だし、双方の能力も話題に見合う分必要なわけよ。
俺としては、これらは集合論とフローチャートの各部を図示して、音に結びつけただけだから、集合論とフローチャートが分かれば分かるだろと思ってるわけよ。
https://anond.hatelabo.jp/20171211180854
これは英文法のSVOみたいなもので、チェックも何も、今日本語で書いていても対応してるからな。
コミュニケーションって歩み寄りだと思うのだけど、どの段階で分からんのだろうか。
論文の人と同じなのかね。あまりに結論ありきであるように感じるが、論文や査読という制度の中では音の研究は出てきえない。
それは論文という形式が自然言語研究に与える制約でしか無い。自然言語は人間が使うもので理論的に解明されていない。客観的なんていうのは最初からあり得ない。
質問に答えると
＞thのθのところだけど、音を重視するのに、tとhと、字面の方が意味の判断で用いられるのはどうしてでしょうか。
タイトルへのツッコミだろうか。この理論は日本語にも適用される。だから音が根拠だと考えるべきだ。
例えばcはkyであると同時にsとも発音するが、どちらにせよ「空間におけるフローチャート（地点/存在）」を指し示している。
その時、kyと解釈しても、sと解釈しても、「空間におけるフローチャート（地点/存在）」という概念の近似にはなっている。
＞クロアチア語のガイ式ラテンアルファベットにはć /tɕ/（キリル文字だとЋ）とか出てくるけど
知らんな。それが問題とも思わん。
http://otoimi.net/ 罵倒でも何でも良いので感想が欲しい。
私が個人的に発見した「音と意味の関係の法則性」で英単語の語源をおぼえようという趣旨のサイトです。
法則として厳密かはともかく間違いなく関連性はありますし、その上で精度も相当に高く、英単語暗記に役立てるぐらいなら十分なものです。
ただ音の意味というのは、その音が使われる全ての単語にあてはまるくらいに広い意味なので、文字列から直接的にその単語の意味を弾き出したり、その単語の意味から直接的に文字列を弾き出す事はできません。
しかし英単語をおぼえる際の実感には繋がりますし、実感があれば英単語暗記も今よりは無味乾燥なものでは無くなるはずです。
以下の表が皆さんの英単語学習に彩りを添える事になれば嬉しいです。
音の意味一覧
d 集合
n 要素
h 要素を含むもの
m 条件
l 選択肢
z フローチャートにおける動き
y フローチャートにおける動き
k 地点/存在
b 場/路
s 動き
p 動き
w 動かされ得るもの
a 意図の集中
i 情報
o ポインティング
u 区切り/終止
E.「複合した音」
q （ku） :質/実態
v （bu） :強調された場/路
j （zy） :フローチャートにおける動き
twitterアカウント：https://twitter.com/otoimi_gogen 著者としてはこのアカウントをフォローして学習の参考にするぐらいがオススメです。
http://otoimi.net/theory 実際は画像メインなんで踏むのを推奨する。
まずdは集合論の集合、gは集合に含まれるもの、nは要素、hは要素を含むものを意味します。
※dとh、gとnは同一であるように見えますが、gとhは関係を表しているので違います。
要素を含まない集合があり得るという意味で「集合」と「要素を含むもの」は違いますし、集合に含まれない要素があり得るという意味で「要素」と「集合に含まれるもの」は違います。
例えば「男」という集合があったとして、その集合にはこの世界のあらゆる男が要素として含まれるはずです。
その内の一人がいなくなったとして、「男」という集合は「男」という集合のままです。
「男」という集合の定義は、この世界の男を全て集めたもののような、ゴチャゴチャしたものでは無いです。
その意味で「要素」と「集合に含まれるもの」はイコールではありませんし、だから「集合に含まれない要素」もあり得るという事になります。
そしてｚとyが「フローチャートにおける動き」を意味していて、zが肯定・否定や呼びかけなど、yがORや呼びかけなどを意味したりします。
※私はこの図のようにzが前提寄り、yが結果寄りだと考えているんですが、肯定・否定を目的に適うかどうか、ORを条件から選択肢とすると、この逆だと考える人もいるかもしれません。
しかし前提から選択肢だからこそ目的に適うか問われるという考え方もありますし、ORは選択肢から結果だという気もしますし、何より逆だとj（zy）が分からなくなります。
ただどちらにせよ背中合わせの関係を持っていて、表記ではどちらも「フローチャートにおける動き」というだけなので、好きなように考えれば良いと思います。
※肯定・否定、OR、呼びかけなどは、例えば連続的でなくフローチャートなのでステップだったりして、動きと呼ぶべきかは分かりませんでしたが、それに当てはまる言葉が無かったので単純に「フローチャートにおける動き」としました。
Cでは動きに関する音を多く扱いますが、「動く何か」が成立するにはフローチャートの条件・選択肢、肯定否定・ORなどでは足りません。
また存在も集合論だけでは足りません。集合論は「〜だ」というだけで、空間における他との区別を持たないからです。
なので「動く何か」を考えるには集合論とフローチャートを合わせる必要があり、それがこのCだという事になります。
まずkが地点/存在、tが空間における集合的なもの、bが場/路を意味します。（tは唯一画像として用意できませんでした）
またフローチャートは神経の反射のようなものなので、「動く何か」を持ちませんし、だから地点もありません。地点も存在を必要とします。
つまり存在と地点は表裏であり、それを表す音がkという事になります。
空間におけるkの地点/存在に対して、tがそれらの集合的なもの、bが動きの場/路を表しています。
ちょうどt,k,w,b→d,g,n,hの関係を持っていると考えれば良いと思います。
※wの「動かされ得るもの」とはつまり、空間における普通の「もの」の事です。
対するkの「存在」は存在というより地点と紙一重の存在以前のようなもので、理論上それぞれただその座標一点にしか存在しないので、当然動かし得ません。
※「意図」とは何か。
そもそも我々の意識は集まったり広がったりするような性質を持っていて、集合論でもフローチャートでもありません。
ここでの「意図」とはつまり、「集合論やフローチャートにおける意識のあり方」を指します。
aが意図の集中、eが意図の拡散で、これらは集合論における意図を表しています。
iが情報（同一性）、oがポインティングで、これらはフローチャートにおける意図を表しています。
uが区切り/終止を意味していて、これはおそらく空間における意図を表しています。
※始まりには意図の集中であるa、真ん中の存在における動きには情報であるiやr（lu）が使われます。
E.複合した音
fがh（要素を含むもの）u（区切り/終止）で空間における「要素を含むもの」。
rがl（選択肢）u（区切り/終止）で空間におけるフローチャート（フロー）。
vがb（場/路）u（区切り/終止）で強調された場/路。
cがk（地点/存在）y（フローチャートにおける動き）で空間におけるフローチャート（地点/存在）。
cがkyというのは発音のルール（http://mymeet-up.com/?p=762）と英単語の意味から判断しました。
jがzyでフローチャートにおける動き。
１・空間を前提とした→の体系
空間を前提とした→（動き）を線で表すと数直線になる。点や円で表すと「リンゴが２個、ミカンが３個」のような例のような感じになる。
「＋」は数直線での右への移動。「－」は左への移動。「×」はその存在の個数。「÷」は中に存在がいくつあるか。「累乗」は次元。
このような数の体系の問題は、フローチャートのような形で書き記すことができる。
問題では前提か答えのどちらかに条件、というか限定がある事が多い。
２・空間を前提とした○の体系
・○の外側の体系
点、線、面、立体、円や球など。
点や線など、それぞれの越境が問題になる事が多い。答えは○という事で、面以上である事が多い。
・○の内側の体系
３・空間を前提とした○→の体系
４・ネットを前提とした体系
０・答えの性質
１・空間を前提とした→の体系
空間を前提とした→（動き）を線で表すと数直線になる。点や円で表すと「リンゴが２個、ミカンが３個」のような例のような感じになる。
「＋」は数直線での右への移動。「－」は左への移動。「×」はその存在の個数。「÷」は中に存在がいくつあるか。「累乗」は次元。
このような数の体系の問題は、フローチャートのような形で書き記すことができる。
問題では前提か答えのどちらかに条件、というか限定がある事が多い。
２・空間を前提とした○の体系
・○の外側の体系
点、線、面、立体、円や球など。
点や線など、それぞれの越境が問題になる事が多い。答えは○という事で、面以上である事が多い。
・○の内側の体系
３・空間を前提とした○→の体系
４・ネットを前提とした体系
・リストはこのように表す。
（Ａ）→（Ｂ）→（C）→（D）
← ← ←
・手続き型プログラミング言語（Ｃ言語など）はこのように表す。
（Ａ）→・（Ｂ）→・（Ｃ）→・（Ｄ）
０・答えの性質
大企業や銀行で、昔から動いている基幹システムは、大抵メインフレームにCOBOLの組み合わせである。
それをここ十年くらい、リプレースでx86系サーバにJavaという構成に変更することが多い。
しかし、ハードが汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。
ぶっちゃけCOBOLはCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは？と思うのだ。
その理由はこうだ。
COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。
勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOLの文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである。
そういうモノが既にある企業や銀行の文化において、当然発注側は担当者からお偉いさんまでCOBOLer系フローチャート脳だし、新しいシステムの設計でもそれを踏襲しようとする。
というか踏襲すること前提じゃないと設計書をレビューできない。
UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。
というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法の設計書で処理を組み上げざるを得なくなる。
そうなると、実装もフローチャートの設計を基にコードを書くわけだが、こういう設計はハッカー文化で発展してきた言語(Fortran→C/C++→Javaという流れと、PerlからPython・PHPというインタプリタ系の諸言語)との相性が最悪である。
設計とは実装を楽にするために書くのに、これらの言語において、フローチャートの設計は役に立たないどころか、邪魔でしかない。
だからFortranしかなかった頃から、本物のプログラマ達はフローチャートをdisってきたわけである。
ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である。
しかし、「普通の人達の普通の思考」からはかけ離れ過ぎているという意味で、「普通の人達の普通の仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。
…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLかアセンブラを選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。
というわけで、自分はCOBOLからのリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。
