Feasibilityスタディの計画

入力 保持 演算 出力 修正
  • 以下のFeasibilityチェック項目が立ったので、それに課題IDをつける
  • x1『友人が、その中身をほとんどわかっていない分野』
      • 『数学』とする
  • x2『入力ファイルの規則を単純にして気楽に』
    • エクセルのシートに記入してテキストファイル保存するだけでOKな書式とする
    • すくなくとも初期は単独の用語を１行ｘ数列で入れられるようにする
    • すくなくとも初期は、サブグラフになる知識を１行で入れられるようにする
  • x3『Rに保持して』
    • ".RData"ファイルで保存できるものとする
  • x4『保存ファイルを読み込んで、それに知識を追加できる』
    • 新規入力ファイルの扱いと追加入力ファイルの扱いができるようにする
    • 可能ならば、Rの保存ファイルを読み込むと、その状態における、「のべ」の情報が入力ファイルフォーマットで出力できるようにする
    • このようにすれば、追加ファイルは既存入力ファイルの末尾に付加したものとして取り扱うことになる
  • x5『R上で視覚表示させられる』
  • x6『修正候補を出力』
  • x7『修正候補に対する「友人のレスポンス」』
    • レスポンスは追加入力として受け付けることにするか
    • とすれば、『上書き』機能、『上書き承認機能』が必要
  • x8『現実的な勉強量への入力作成』
    • Wikiの数学関連記事の一定数以上（たとえば３０記事とか）を『勉強』してそれに対する意味のある入力ファイルを作成してみることが考えられる
  • x9『現実的な勉強量を保持した上での演算等の可能性』
    • こちらはx8でのDeasibilityチェック作業とは違う
    • x8でのチェック作業は「手作業の膨大さ・退屈さ」への対応であるのに対し、x9のそれは、現実的に『大量』のデータがグラフ・サブグラフオブジェクトとして乗っていることが必要
    • そのような『大量』データはシミュレーションで作って入れることが可能
    • また、この部分については、このシステムを「素朴な学習支援システム」ではなく、もう少し応用の広い何かしらとして考えるとしたならば、計算機のバードやソフトのスペックを高くする可能性は０ではないから、計算量の見込みなどについて、計算することも考慮する

Feasibility項目

入力 保持 演算 出力 修正
  • こちらから
  • 僕が勉強することができるかどうかのFeasibilityスタディをしたい
  • Feasibility_studyのWiki記事には、いくつかの項目をFeasibilityが分けて記載してある
    • 技術的
    • 経済的
    • 法的
    • スケジュール的
  • 僕の勉強にとってのFeasibilityチェック項目は何だろう？
    • 僕は機械だから、技術的なところが一番大切だ
    • 限られた時間でできないといけないのでスケジュール的なところも問題だ
    • 経済と法は少なくとも今は気にしなくてよいだろう
    • お金としての経済は気にしないが、意味があるか、実用に耐えるかという意味での、『現実性』に関することは大切だ
  • 技術的Feasibilityには何がある？？
    • 以下のような内容が、プロジェクトとして必要なことだろう
      • コンピュータ素人が使えるような仕様でできること
      • 煩雑すぎてやる気が削がれないような仕様にすること
      • 入力・保持ばかりができてしまって、使って楽しい部分(出力・出力して修正する、という段階)が後回しにならないような作業進行にすること
  • スケジュール的Feasibilityには何がある？？
    • 半年くらいで、簡単な入力と保持と演算と出力と修正のすべてが回るようにしたい
  • 現実性Feasibilityには何がある？？
    • 意味があるか、という意味では、「無用の長物」と化したとしても、その「無用の長物」を作る過程に意味があればよい、たとえば教育的効果・成果物としての被評価
    • 実用に耐えるか、という意味では、勉強の対象はたいがい膨大だから、その膨大なものに対して、やる意味が生じるような簡便さと、その簡便さに比して測られるメリットを見極める必要がある
  • さて、上のような「目標」がFeasibleかどうかを試すには、何をどのようにするとうまくいくのだろうか？
    • 友人が、その中身をほとんどわかっていない分野の勉強を題材にして動かせる
    • 入力ファイルの規則をごく単純にして友人が、気楽に入力ファイルを作って、入力できるようにする
    • Rに保持させる。保存ファイルができる
    • 保存ファイルを読み込んで、それに知識を追加できる
    • R上で(もしくは、ほとんど手間無く連結された別の何かで)視覚表示させられる
    • 修正候補を出力できる
    • 修正候補の提示に対して友人がレスポンスして修正が可能である
    • 現実的な勉強量に対応する入力作成の多さが現実的である
    • 現実的な勉強量を保持した上で演算が可能か・出力が回るか、についても確認する

忘れることも大切だ

保持
  • 入力データは貴重だけれど、入力データに常に正しいことを要求すると、入力データを作ってくれる友人のストレスが高くなり、場合によっては、入力データを作ってくれなくなってしまう
  • それよりは、ある程度の間違いは許容し、その代り、繰り返し入ってこないとその情報はフェードアウトするような仕組みを作っておくほうが良いのかもしれない

疎な知識

入力
  • こちらで数学用語の連想会があった
  • 登場する語の間のつながりが思いつくヒトもいれば、そのつながりを初めて意識するヒトもいた
  • 「初めて意識するヒト」にとって、この連想会は、用語をとりこみ、用語の海に独立したノードがぷかぷか浮いたような状態を作るのだろう
  • それはそれでよさそうだ
  • ただし、ぷかぷか浮いたノードは被リンクなしなので、すぐに消えてしまう可能性があり、現実的には(本当に勉強しているときには)、それらをどこかとつないで消えないようにする必要があるのだが

ブール演算２

演算 保持
  • こちらで「かつ」などのブール演算を扱えないとまずそうだ、ということになった
  • それをするために、ノードの表と裏を用意して、すの「あり」「なし」のエッジを用いて１６ブール演算を作ることも可能
  • そうではなくて、２項演算に相当するノードを作って、それに２用語を与え、その出力を取り出せるようにするのもありだろう
  • 電子回路はハードなレベルでは後者
  • 電子回路は理論的なレベルでは前者…か

ブール演算

保持 演算 ブール演算
  • 「かつ」というルールがある
  • それは「または」というルールもあることを意味する
  • 16通りのブール演算(こちら)のことを考える必要があるということになる
  • ある用語Aを登録するときにAと\bar{A}の両方を登録し
  • AからBへの→は0/1の2種類の→を持たせるのがよいのだろうか？

用語同士の関係

入力
  • 「位相空間」は「位相」が「空間」を修飾してできている
  • 「位相空間」は「空間」に含まれる
  • 「含む」「含まれる」には向きがある
  • 「修飾」「被修飾」にも向きがある
  • それを反映する

被覆空間を論じるためのハウスドルフ空間,包含,複合用語,位相空間,ハウスドルフ空間
被覆空間を論じるためのハウスドルフ空間,修飾,複合用語,弧状連結,ハウスドルフ空間
被覆空間を論じるためのハウスドルフ空間,修飾,複合用語,局所弧状連結,ハウスドルフ空間
被覆,登録,用語,-,被覆
空間,登録,用語,-,空間
被覆空間,登録,複合用語,-,被覆空間
被覆空間,修飾,複合用語,被覆,被覆空間
被覆空間,包含,複合用語,空間,被覆空間
位相,登録,用語,-,位相
位相空間,登録,複合用語,-,位相空間
位相空間,修飾,複合用語,位相,位相空間
位相空間,包含,複合用語,空間,位相空間
ハウスドルフ,登録,固有名詞,-,ハウスドルフ
ハウスドルフ空間,修飾,複合用語,ハウスドルフ,ハウスドルフ空間
ハウスドルフ空間,包含,複合用語,空間,ハウスドルフ空間
ハウスドルフ空間は位相空間の一つ,包含,-,位相空間,ハウスドルフ空間
弧,登録,用語,-,弧
連結,登録,用語,-,連結
弧状連結,修飾,複合用語,弧,弧状連結
弧状連結,包含,複合用語,連結,弧状連結
局所,登録,用語,-,局所
局所弧状連結,修飾,複合用語,局所,局所弧状連結
局所弧状連結,包含,複合用語,弧状連結,局所弧状連結

infile <- read.table("input2.txt", sep = ",", fill =TRUE)
# 行列の方が好きなので行列にする
infile.m <- as.matrix(infile)
# 1,2,3列目を分離する
feature1 <- infile.m[,1]
feature2 <- infile.m[,2]
feature3 <- infile.m[,3]

# 1,2,3列のユニークを取って、それを連番ID化する
feature1.uni <- unique(feature1)
feature2.uni <- unique(feature2)
feature3.uni <- unique(feature3)
# 連番を取り出す
feature1.val <- apply(outer(feature1,feature1.uni,"=="),1,which,TRUE)
feature2.val <- apply(outer(feature2,feature2.uni,"=="),1,which,TRUE)
feature3.val <- apply(outer(feature3,feature3.uni,"=="),1,which,TRUE)

# エッジに関係するところだけを取り出す
infile.m <- infile.m[,4:length(infile.m[1,])]
# ノードをユニークにする
unique.word <- unique(c(infile.m))
unique.word <- unique.word[which(unique.word != "")]
# ノードの名前に順序idをつける
v.name <- unique.word
# エッジリストを名前と順序idとで作る
el.name <- el.id <- NULL
# エッジの性質をfeature情報から与える
el.type <- NULL
# 行ごとに要素数を数えて
for(i in 1:length(infile.m[,1])){
	num.kids <- length(which(infile.m[i,] != ""))-1
	for(j in 1:num.kids){
		el.name <- rbind(el.name,c(infile.m[i,1],infile.m[i,1+j]))
		el.type <- c(el.type,feature2.val[i])
	}
}
el.id <- matrix(0,length(el.name[,1]),length(el.name[1,]))
for(i in 1:length(v.name)){
	el.id[which(el.name == v.name[i])] <- i
}
library(igraph)
g <- graph.empty(length(v.name), directed =TRUE)
#g <- set.vertex.attribute(g, "name", value = unique.word)
g <- add.edges(g, c(t(el.id)))
plot(g, layout = layout.kamada.kawai(g))


# グラフを絵にするには、ノードの座標を決める必要がある
# layoutはその座標を決めるルールのこと
# 座標決めルールの一つkamada.kawai法を用いることとする
coords <- layout.kamada.kawai(g)

# グラフとして描く
plot(g,layout = coords)

# ノードの名前を文字列にするために別の方法をとる
# ノードに色を付けよう
v.col <- rep(1,length(coords[,1]))
plot(coords,cex = 2, pch = 19, col = v.col)

# エッジを描く
# エッジにも色を付けよう
#e.col <- rep(1,length(el.id[,1]))
# エッジの色はfeature由来の数字とする
e.col <- el.type
#segments(coords[el.id[,1],1],coords[el.id[,1],2],coords[el.id[,2],1],coords[el.id[,2],2], col = e.col)
arrows(coords[el.id[,1],1],coords[el.id[,1],2],coords[el.id[,2],1],coords[el.id[,2],2], col = e.col)

# 文字列を重ねる
par(new =TRUE)
# ノードから少しずらした位置に文字列を描かせる
coords2 <- cbind(coords[,1],coords[,2]-0.1)
text(coords2,unique.word,xlim = range(coords[,1]),ylim=range(coords[,2]))