きままにブログ

プログラミングを主とした私のメモ帳です。寂しいのでコメントください笑

JavaScriptスレがすごかった

JavaScript 3でのとある会話。

160 デフォルトの名無しさん [] 2014/01/19(日) 12:48:15.65 ID: Be:
jQueryで下記のように所持しているツリー用のデータをkeyを指定してtitleを変更する
処理を作りたいんですが、どのようにしたらいいでしょうか?
子が何階層まであるかは不明で、うまいやり方が思いつきません。

[{"key":"1", "title":"ファイル1", "children":{{"key":"12", "title":"ファイル2", "children":{...}}}},{"key":"2"...}]

ツリー用のデータというのはおそらく、Windowsでいうツリービューのようなものをいっていると思います。フォルダの構造のように再帰的な構造となっているのが見て取れます。

161 デフォルトの名無しさん [sage] 2014/01/19(日) 12:59:50.46 ID: Be:
javascriptjQueryも関係なくツリー構造の再帰処理だよな?

func(node)
{
for(i = 0 ; i < node.children.length ; i++)
{
func(node.children[i]);
}
doSomething(node);
}

162 デフォルトの名無しさん [] 2014/01/19(日) 13:00:21.18 ID: Be:
>>160
線形リストでござるか?
ループでたどるのがいんじゃないかしら。

function main() {
 var n = search(node, "1");
 if (n != null)
  n.title = "タイトル";
}

function search(node, key) {
 for (var n = node; n != null; n = n.children)
  if (n.key == key)
   return n;
 return null;
}

163 デフォルトの名無しさん [sage] 2014/01/19(日) 13:02:26.69 ID: Be:
>>160
jQueryはDOM、つまりHTML用のライブラリだから
そんな用途には使えないよ。
普通に再帰処理書けば良い。

一般的な階層構造だと指摘しています。そこで、

164 デフォルトの名無しさん [sage] 2014/01/19(日) 14:20:21.14 ID: Be:
>>162
1
 12
  ...
2
 ...
こういう構造だから線形リストではないよね。
最初の階層で一文字目が決まり、次の階層で2文字目が決まると
考えると構造はトライに近いかな。

[{key:"1", title:"title1", children:[{key:"12", title:"title12", children:}]}, {key:"2", title:"title2", children:}]

構造の一貫性を考えるとデータの定義はこうじゃないかな。

と、keyが階層を表していると勝手に解釈した意見が出ています。(結果的に間違っていました。)数学の教科書で、行列の添え字を「12」とか「24」とか表すように、今回は例として階層構造が分かりやすいように1とか12とか付けているのは明かです。

165 デフォルトの名無しさん [sage] 2014/01/19(日) 14:23:13.81 ID: Be:
こういう構造ってよくあるんだけど、
ここでいうchildrenっていうキーどうしても必要だよね。
なんかね、違和感があるだよ。
childrenは不要ではないかと。

こういう構造を扱う、汎用的なライブラリが作れそうなんだが、
childrenというキーを引数に取らなきゃいけないのが
なんか気持ち悪い。

でも普通に考えたらやっぱりいるよなぁ。なんだろこの違和感。

自身のキーに対してそれが値なのか、階の仮想を持つのかを規定するのに、例えばオブジェクトの種類で判別する方法もあります(Compositeパターン)ので、childrenというプロパティを持たないようにもできますね。

166 デフォルトの名無しさん [sage] 2014/01/19(日) 14:26:01.16 ID: Be:
>>160
https://friendpaste.com/5mgzGGj24KWKgfQZiEY2we

167 デフォルトの名無しさん [sage] 2014/01/19(日) 14:30:51.72 ID: Be:
>>166
ちょっと冗長だし使いにくいね。
もう少し頑張ってみて。

168 デフォルトの名無しさん [sage] 2014/01/19(日) 14:32:52.40 ID: Be:
>>167
俺には無理だからもっと簡潔な書き方を君が俺に教えてください。

169 デフォルトの名無しさん [sage] 2014/01/19(日) 14:46:54.04 ID: Be:
>>165
childrenが嫌いならparentをもったらいいじゃない!!
木構造をデータベースに入れるときはparentを保存するようにしてた。
それを読み込んでchildrenに変換するのが超面倒だった思い出がありまくり。

170 デフォルトの名無しさん [sage] 2014/01/19(日) 15:16:43.62 ID: Be:
>>168

// 汎用関数
function select_node(nodes, children_key, callback) {
  var ret = [];
  function recursive(nodes) {
    if ( !nodes ) { return }
    for ( var i = 0 ; i < nodes.length; i++ ) {
      var node = nodes[i];
      if ( callback(nodes) ) { ret.push(nodes) }
      recursive(nodes[children_key]);
    }
  }
  recursive(nodes);
  return ret;
}

var nodes = [ { key:"1", title:"title1", children: [ { key:"12", title:"title12" } ] }, { key:"2", title:"title2" } ];

// nodeを選択する
var founds = select_node(nodes, 'children', function(node) {
  return node.key === "12";
});

// 見つかったものを書き換える
for(var i = 0; i < founds.length; i++) {
  founds[i].title = "rename " + founds[i].title;
}

ソースファイルは

function main() {
var node = createNodes();
find(node, "12").title = "テスト";
println(find(node, "1").title);
println(find(node, "2").title);
println(find(node, "12").title);
}

function println(s) {
java.lang.System.out.println(s);
}

function createNodes() {
return [{key:"1", title:"title1", children:[{key:"12", title:"title12", children:[]}]}, {key:"2", title:"title2", children:[]}];
}

function find(nodes, key) {
var ns = nodes;
for (var i = 0; i < key.length; i++) {
var n = find2(ns, i, key[i]);
if (n == null) {
return null;
}
if (i == key.length - 1) {
return n;
}
ns = n.children;
}
return null;
}

function find2(nodes, index, char) {
for (var i = 0; i < nodes.length; i++) {
var n = nodes[i];
if (n.key[index] == char) {
return n;
}
}
return null;
}

main();

find関数は、nodeのなかから、keyの0文字目からkeyの末尾まで順番にfind2を呼び出し、ループします。find2関数は、現在のノードとkeyの位置(i)およびその文字(c)が与えられ、現在のノードと同じ階層にあるものを全て調べ、そのkeyのiの位置の文字と、与えられた文字(c)が等しいか調べます。一致すれば発見したと見なしそのノードを返します。

これから分かるように、164氏の発想で書かれたコードです。おそらく164氏が書いたのでしょう。このコードだと、親の階層とこの階層の先頭の文字列が一致していなければなりません。文字数も1階層に付き1文字しか使えません。

170氏は正しい解釈に基づいてソースを提示しました。階層構造にふさわしい再帰処理です。そこへ食いついてきました。

171 デフォルトの名無しさん [sage] 2014/01/19(日) 15:23:14.98 ID: Be:
>>170
if文の改行で誤魔化してるだけだよね。
簡潔さの欠片もないし、階層がいくつか不明って言ってるんだから再帰はないよね。
話にならないな君。

if文の改行とは、if文の{}が複数行に書かないで1行で書かれていることでしょうか? 階層が不明ならそもそも終了条件がないと言うことなので、どのような方法も採れません。170氏の提示された方法ではif ( !nodes ) { return }とあるようにchildrenが空なら終了します。

172 デフォルトの名無しさん [sage] 2014/01/19(日) 15:30:15.53 ID: Be:
>>171
わかってないね。

汎用関数っていうのは、一度作ってしまえばもう二度と見る必要がないってことだよ。

つまり、ツリー構造から検索するキーが違う別の処理を書くのに、
コピペする必要はなく、これだけでよくなってる。
var founds = select_node(nodes, 'children', function(node) {
  return node.key === "1" || node.key === "2";
});

あんたの場合、長ったらしいコードに埋め込まれているからコピペするしかなくなってる。

見つかったものを書き換えるルールもこれだけで変更できる。
for(var i = 0; i < founds.length; i++) {
  founds[i].title = founds[i].title + "を変更"
}

テストコードを書くときを考えても、select_nodeのテストコードを一度書けば終わりだし、
残りの書き換えコードはあとは間違えないような些細なコードだし、
そのテストコードも簡単。配列与えて変わっているか調べれば良い。

えっと、ここまでの偉そうなことを君、言える?

173 デフォルトの名無しさん [sage] 2014/01/19(日) 15:33:44.66 ID: Be:
このコードはjQueryと同じ発想で(というかjQueryよりもずっと前からある発想だが)
ツリー上になっているDOMを$(セレクタ)で配列の形に変換するのと一緒。

select_nodeが$(セレクタ)のかわりでツリーを条件を元に見つけた配列にしている。
ツリーをそのまま扱うのは面倒なので、一旦見つかったノードの配列にしてしまう。

そうすれば後は、簡単に処理できるってわけ。

174 デフォルトの名無しさん [sage] 2014/01/19(日) 15:43:39.40 ID: Be:
>>172-173

冗長の人、スタックオーバーフローの言い訳をお忘れのようですが?

175 デフォルトの名無しさん [sage] 2014/01/19(日) 15:45:20.84 ID: Be:
冗長君は自分のコードが簡潔で他人のコードが冗長に見える病を患っておられるのです。
誰もが通る道です。やさしく見守ってあげましょう。

176 デフォルトの名無しさん [sage] 2014/01/19(日) 15:48:42.69 ID: Be:
>>174
再帰コードをディスってるの?

再帰コードであるかぎりスタックオーバーフローの
可能性は限りなく0に近いが0にはならない。

お前、再帰を一切使うなって言ってるのか?

177 デフォルトの名無しさん [sage] 2014/01/19(日) 15:49:14.11 ID: Be:
>>175
分かりました。

再帰も書けない冗長なコード書いた君ですねw

178 デフォルトの名無しさん [sage] 2014/01/19(日) 15:50:30.83 ID: Be:
圧倒的な差を見せつけると、反論ではなく
口ばっかりしかでてこないものよ。

どうやら指摘されたのが相当気に触ったのか、(末尾再帰でない)再帰コードに対して全否定でかかってきました。

179 デフォルトの名無しさん [sage] 2014/01/19(日) 15:58:35.60 ID: Be:
>>176
>再帰コードであるかぎりスタックオーバーフローの
>可能性は限りなく0に近いが0にはならない。

可能性が限りなく0に近いことの根拠はなんなの?
例として提示されたデータは最初の階層が1文字で
次の階層が2文字になってる。階層の深さが文字列の長さに比例すると
考えるなら限りなく0に近いなんて言えないと思うんだけど。

>>177
>再帰も書けない冗長なコード書いた君ですねw

書かなかったことと書けないことが同じことだとするなら
君はトライのコードを書けないからパフォーマンスが悪く
スタックオーバフローの可能性のある劣悪なコードを書いたってことになるけど。

“次の階層が2文字になってる。階層の深さが文字列の長さに比例すると”という勝手な推量によって発言されています。そもそも、JavaScriptでも文字列はスタックに確保されず、ヒープに確保されます。従って文字列の長さに関係なく、ポインタだけのサイズとなります。全く以て関係のない指摘ですがこれは……。

180 デフォルトの名無しさん [sage] 2014/01/19(日) 16:05:22.81 ID: Be:
>>178
冗長君、君はなかなか痛い子だねw

181 デフォルトの名無しさん [sage] 2014/01/19(日) 16:05:50.48 ID: Be:
> 可能性が限りなく0に近いことの根拠はなんなの?

現在のスタックの量は、JavaScriptが動くマシンであれば
十分な量が与えられている。

かりにスタックの量が1MB、1回の関数呼び出しに
100バイト消費するとして10000階層になる。
nodeで実験したら、20930階層までできた。

反論終わり。

具体的な指摘によって再帰がどこまでできるのか、示されています。ツリーの階層が20000階層もあることは人間の世界では考えられないのでほとんど問題ないと考えられます。仮に問題が派生するなら書き直すことは容易です。

182 デフォルトの名無しさん [sage] 2014/01/19(日) 16:10:03.22 ID: Be:
>>181
反論じゃなくて回答ね。俺の質問に答えてくれたんだから。
文字列は何文字まで可能なのかな?

183 デフォルトの名無しさん [sage] 2014/01/19(日) 16:13:18.78 ID: Be:
>>182
文字列の長さは影響ない。
スタックを使うものじゃないのだから当然の話だが。

184 デフォルトの名無しさん [sage] 2014/01/19(日) 16:14:33.68 ID: Be:
> 例として提示されたデータは最初の階層が1文字で
> 次の階層が2文字になってる。階層の深さが文字列の長さに比例すると

メモリ使用量=スタック使用量とか思っていそうw
スタックも知らないのかな?

いや、そもそも、階層の深さが文字列な長さに比例するってのが
意味不明だな。

どういう意味?

185 デフォルトの名無しさん [sage] 2014/01/19(日) 16:14:34.75 ID: Be:
>>183
ちょっと何言ってるのかわからないからできるだけ省略しないで言ってくれると
助かるんだけど、文字列の長さは何に影響がないの?

186 デフォルトの名無しさん [sage] 2014/01/19(日) 16:15:04.63 ID: Be:
>>185
いや、そもsも、文字列の長さが
なんで階層の深さに比例するんだよw

187 デフォルトの名無しさん [sage] 2014/01/19(日) 16:17:46.12 ID: Be:
階層の深さが文字列の長さに比例って、何の文字列の話してるんだろ?

188 デフォルトの名無しさん [sage] 2014/01/19(日) 16:19:59.74 ID: Be:
>>186
質問の答えになってないよw
階段とばすと会話がかみ合わなくなるからちょっとそういうやめてもらいたい。

>>160のデータの例では最初の階層はkeyが1文字で次の階層はkeyが2文字になってる。
そのことからトライに近い構造なんだろうと思って俺はコードを示した。

“なんだろうと思って”という勝手な思い込みをしておいて“階段とばすと会話がかみ合わなくなるから”という図々しさ。

189 160 [sage] 2014/01/19(日) 16:21:30.58 ID: Be:
>188
別に例が一階層目のキーの1、二階層のキーにたまたま12って書いただけで、
別に階層が深くなれば、キーの名前も伸びていくなんて言ってませんよ。

190 デフォルトの名無しさん [sage] 2014/01/19(日) 16:22:21.97 ID: Be:
>>188
仮にキーの長さが伸びていったとしても、
それで消費するのはヒープの量じゃん。

ヒープはスタックとは別のメモリ領域に
割り当てられるって知らないの?

191 184 [sage] 2014/01/19(日) 16:24:41.26 ID: Be:
やっぱりこいつはスタック使用量とメモリ使用量を
ごっちゃにしているって説であっていたようだw

192 デフォルトの名無しさん [sage] 2014/01/19(日) 16:24:42.39 ID: Be:
>>189
いまさら出てこられて後出しされても困るんでできれば黙ってて欲しいかな。
keyの文字列と階層が比例するとは言ってはいないけど、keyの文字列と階層が
比例しないとも言っていないんで、俺はそれが比例するものだという仮定のもとで
コードを書いた。

193 デフォルトの名無しさん [sage] 2014/01/19(日) 16:25:31.69 ID: Be:
ワロタwww

> 例として提示されたデータは最初の階層が1文字で
> 次の階層が2文字になってる。階層の深さが文字列の長さに比例すると
> 考えるなら限りなく0に近いなんて言えないと思うんだけど。

    ↓

> keyの文字列と階層が比例するとは言ってはいないけど、keyの文字列と階層が

194 デフォルトの名無しさん [sage] 2014/01/19(日) 16:26:37.58 ID: Be:
なんで階層の深さとキーの長さが比例するって
考えたんだwwww

そのほうが頭がおかしい。

195 デフォルトの名無しさん [sage] 2014/01/19(日) 16:27:46.03 ID: Be:
だいたい>>160で

> jQueryで下記のように所持しているツリー用のデータをkeyを指定してtitleを変更する
> 処理を作りたいんですが、どのようにしたらいいでしょうか?

って書いてあるじゃんw

“keyの文字列と階層が比例するとは言ってはいないけど、keyの文字列と階層が比例しないとも言っていないんで”と仰る164氏。これは論理的に破綻しているが大丈夫でしょうか?

たとえ話ですが、(数学の問題文)「今、複素数xを考えます。」(愚かな回答者)「xが整数ではないとも言っていないんで」のようなものです。どのようなxも考えているのに、xが整数だけに限定するのはいけません。xは整数では(必ずしも)ないって言っているのです。

196 デフォルトの名無しさん [sage] 2014/01/19(日) 16:28:37.69 ID: Be:
>>190
>>191
いや、君は間違ってる。
俺がどういうことを考えたのかという認識に関しては>>189が合ってる。
俺が考えたことはkeyの長さと階層が比例する、かつ、階層の深さは不明だから再帰
処理するとスタックオーバフローのおそれがあるよねということ。だから君はただ間違ってる。
ヒープとかは関係ないかな。

どうやら170氏のJavaScriptはスタックにキーがどんどん積まれていく処理に見えるようです。ところが、引数に渡しているのはnode(内部実装ではおそらくポインタでしょう)です。keyの長さとは無関係です。

197 デフォルトの名無しさん [sage] 2014/01/19(日) 16:29:10.13 ID: Be:
>>192
だからさ、キーの長さが階層に比例したとしても
キーの長さはスタック領域ではなく、ヒープ領域に格納されるから
キーの長さは全く無関係なの。

なんでキーの長さにこだわってるのさ?

198 デフォルトの名無しさん [sage] 2014/01/19(日) 16:31:09.36 ID: Be:
>>194
トライっていう文字列を管理するデータ構造があってそれに
近いデータ構造なのかなって考えた。頭はおかしくないと思うんだけどなあ。
まあ本人が言っても説得力ないかw

>>195
うん? ちょっと何を言っているのかよくわからない。
199 デフォルトの名無しさん [sage] 2014/01/19(日) 16:31:43.98 ID: Be:
階層の深さが不明だから、スタックが~っていうのならわかるが、

キーの長さは一体どこから出てきたんだw
キーの長さの話をした時点で、お前が馬鹿だっていうのは
みんなにバレてるんだよ。

200 デフォルトの名無しさん [sage] 2014/01/19(日) 16:33:04.17 ID: Be:
>>198
> トライっていう文字列を管理するデータ構造があってそれに

質問を読め

>>160
> jQueryで下記のように所持しているツリー用のデータをkeyを指定してtitleを変更する

ツリー用のデータって書いてあるだろ。

お前、よく仕様をちゃんと読まないで突っ走って作っちゃって
あとからこれじゃだめだって青くなるタイプだろ?

201 デフォルトの名無しさん [sage] 2014/01/19(日) 16:36:11.36 ID: Be:
>>197
文字列の長さと階層の深さが比例すると仮定するなら
文字列の長さが30000文字だったとするなら30000階層ノードを再帰的に
たどることになるでしょう。文字列の長さがヒープに格納されるっていうのはどういう
話をしているのかわからない。

>>193
最初読んでちょっと意味がわからなかったんだけど、たぶん主格を
読み間違ってるんじゃないかと。

>階層の深さが文字列の長さに比例すると考える

これの考えるという動作の主体は俺。

>keyの文字列と階層が比例するとは言ってはいないけど

これの言ってはいないという動作の主体は質問者である>>160。

これでたぶんわかるんじゃないかと。

最初から分かるとおり、この人の中では文字列の長さが階層を示していることになっています。“文字列の長さが30000文字だったとするなら30000階層ノードを再帰的にたどることになるでしょう。文字列の長さがヒープに格納されるっていうのはどういう話をしているのかわからない。”と言っているのは、文字数は関係がなく、文字数=階層だから、再帰処理では(階層による)スタックオーバーフローが起こるということみたいです。

事の発端は164氏が“話にならないな君。 ”といって煽ったからです。“これの考えるという動作の主体は俺。”と自分の誤解を棚に上げてなかったことにしています。

202 デフォルトの名無しさん [sage] 2014/01/19(日) 16:36:59.45 ID: Be:
トライは文字の種類が多くなるとメモリを大量に消費するんだが?

203 デフォルトの名無しさん [sage] 2014/01/19(日) 16:38:00.21 ID: Be:
>>201
> 文字列の長さと階層の深さが比例すると仮定するなら

だから、仕様にそんなこと書いてないのに
仕様に書いてないことに対応するためのコードかくなって
こういう奴がいると迷惑なんだよ。
使いもしない、余計なものを作りやがっって。

204 デフォルトの名無しさん [sage] 2014/01/19(日) 16:40:11.59 ID: Be:
>>201
本当にお前は頭が悪いな。

> 文字列の長さが30000文字だったとするなら30000階層ノードを再帰的に
> たどることになるでしょう。文字列の長さがヒープに格納されるっていうのはどういう

文字列の長さが30000文字じゃなくても、
30000階層のノードがあれば同じことだろ。

つまり、スタックというのは階層が増えるたびに消費するもので
文字列の長さとはまったく関係ない。

だから文字列の長さ話をする必要はないんだよ。
そこからお前が、無駄なことを考えてるってわかるわけさ。

205 デフォルトの名無しさん [sage] 2014/01/19(日) 16:40:29.64 ID: Be:
>>200
>ツリー用のデータって書いてあるだろ。

書いてあるね、トライもツリーだから言葉上の整合性はとれるのよね。

>お前、よく仕様をちゃんと読まないで突っ走って作っちゃって
>あとからこれじゃだめだって青くなるタイプだろ?

どうなんだろうね、いまは働いていないけどこの先IT業界で
働き出したらそういうことになるのかもしれないね。まあ仕事就けるか
自体わからないけどね。君はそんな俺のことを思い浮かべながら仕事に
精を出したらいいと思うよ。

“トライもツリーだから言葉上の整合性はとれるのよね”と言っています。データ構造で言うトライ木がツリー(木)なのは間違いありませんが、“ツリー用のデータ”という言い方をするでしょうか? データ構造〈用〉ですよ、データ構造のためのデータっておかしいでしょ! 逆です。データに適するためのデータ構造です。

206 デフォルトの名無しさん [sage] 2014/01/19(日) 16:44:17.77 ID: Be:
>>205
必要にならないものをせっせと書いてる馬鹿がいたなーって思い出せばいいのか?w

どうせならこの言葉を覚えよう

http://ja.wikipedia.org/wiki/YAGNI
"You ain't gonna need it"[1]、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。
理由[編集]

YAGNI原則を提唱する人々は、その理由として以下を挙げている。
あとで使うだろうとの予測の元に作ったものは、実際には10%程度しか使われない。したがってそれに費やした時間の90%は無駄になる[2]。
余計な機能があると我々の仕事が遅くなり、リソースを浪費する[2]。
予期しない変更に対しては設計を単純にすることが備えとなるが、今必要とする以上の機能を追加すると設計がより複雑になってしまう[2]。
あなたの人生の時間は貴重である。あなたの能力は単にコードを書くためではなく、現実の問題に集中するために使うべきである[3]。
結局はその機能は必要ないかもしれない。もしそうなったら、あなたがその機能を実装するのに費やした時間も、他のみんながそれを読むのに費やした時間も、その機能が占めていたスペースも、すべて無駄になってしまうだろう[3]。
コードをすばやく実装するために最も良い方法は、あまりコードを書かないことである。バグを減らすために最も良い方法も、あまりコードを書かないことである[3]。

207 デフォルトの名無しさん [sage] 2014/01/19(日) 16:45:13.16 ID: Be:
>>203
俺は仕事でコード書いたわけじゃないし、質問読んで思いついたままに
コード書いただけだよ。君はたぶん嘘を言ってると思うんだよね。
君は何も迷惑していないよ。迷惑を受ける道理がない。俺の返信を迷惑だと
思うなら俺に返信してこないと思うし。俺の言ってること筋通ってない?

>>204
>文字列の長さが30000文字じゃなくても、
>30000階層のノードがあれば同じことだろ。

同じことだね。それで、いまは文字列の長さと階層が比例するっていう仮定で
話をしているんだから、文字列の長さと階層はとうぜん関係あるし、深い階層を
再帰でたどればスタックオーバーフローになるよね。

208 デフォルトの名無しさん [sage] 2014/01/19(日) 16:45:43.84 ID: Be:
トライって言葉を使いたかったおこちゃまだなw

209 デフォルトの名無しさん [sage] 2014/01/19(日) 16:48:14.16 ID: Be:
>>206
それはちょっと説得力に欠けるかと・・・

>>172
>つまり、ツリー構造から検索するキーが違う別の処理を書くのに、
>コピペする必要はなく、これだけでよくなってる。

こういうふうに言ってしまってるわけだし。読んでないと思ったでしょ?
俺読んでるんだからね。

210 デフォルトの名無しさん [sage] 2014/01/19(日) 16:48:26.12 ID: Be:
>>207
> 俺の言ってること筋通ってない?

うん。ガキだなって思うよ。

非論理的で、おおよそ数学者や技術者に向いていない性格

211 デフォルトの名無しさん [sage] 2014/01/19(日) 16:49:06.13 ID: Be:
>>208
まあそれもあるかな、コードを書きたかったっていうのが近いけど、まあどっちでもいいかw
212 デフォルトの名無しさん [sage] 2014/01/19(日) 16:49:21.65 ID: Be:
>>209

> それはちょっと説得力に欠けるかと・・・

有名な言葉 VS お前

説得力があるのはどっちだと思う?

213 デフォルトの名無しさん [sage] 2014/01/19(日) 16:49:59.36 ID: Be:
>>209

> 俺読んでるんだからね。

読んでるから何なんだよwwww

214 デフォルトの名無しさん [sage] 2014/01/19(日) 16:50:37.09 ID: Be:
>>210
どこが非論理的かな?俺もまだ君から論理的な言葉を聞いていないな。

215 デフォルトの名無しさん [sage] 2014/01/19(日) 16:54:18.45 ID: Be:
>>212
いやそうじゃなくて、伝わらんもんだな。
たとえばダウンタウンの浜田が人の頭を叩いちゃいけません
っていっても説得力感じないでしょ。浜田はそれで笑いを
とりまくってるわけだし。そういうこと。わかるだろ。わかれ。

216 デフォルトの名無しさん [sage] 2014/01/19(日) 16:58:15.65 ID: Be:
>>214
非論理的だろ。

スタックがオーバーするのは、階層の深さが問題になるのであって
文字列の長さは問題にならない。

文字列の長さが階層の深さに比例するというのは
お前が勝手に決めたルールであって、そんなルールは
ツリーという言葉には適用されない。

お前が言ってるのはキーの長さが階層の深さに比例する場合
(※注意トライツリーにこのような定義はない)であって
いまはそんな特殊なツリーの話はしていない。

故にキーの長さは階層の深さ(とスタックオーバーフロー)は無関係。

お前が言ってるのは「哺乳類は卵を生むよ。カモノハシと仮定するならね」って
言っているようなもん。

十分非論理的だ。

かなり非論理的なことを言っているのに非を認めません。“スタックがオーバーするのは、階層の深さが問題になるのであって文字列の長さは問題にならない。”は大変端的に述べられています。

ある現象の原因がXだとします。ところがXはYが起こると起きます。このとき、ある現象の原因はYだけでしょうか? いえ、もしかしたらXはZが起こると起こるかもしれません。結局、本質的な原因はXなのです。相手に説明するときに、Yだけ言及して、「結局Xだから同じでしょう?」というのはとても非論理的だと思います。

217 デフォルトの名無しさん [sage] 2014/01/19(日) 17:01:35.11 ID: Be:
>>215
> たとえばダウンタウンの浜田が人の頭を叩いちゃいけません
> っていっても説得力感じないでしょ。浜田はそれで笑いを

確かにお前が何を言っても説得力ないね。
はたから見てお笑い芸人みたいだからかな?w

218 デフォルトの名無しさん [sage] 2014/01/19(日) 17:05:43.94 ID: Be:
人を笑わすお笑い芸人と
単に笑われているやつを一緒にするなw

219 デフォルトの名無しさん [sage] 2014/01/19(日) 17:24:50.85 ID: Be:
>>217
それはちょっと卑怯な論法かな。
確かにと言って話を変えてるよね。

君は>>206でYAGNIを覚えようと俺に言った。
しかし、言った本人が>>172でYAGNIを破ってるじゃないか。
どういうことなんだい。っていうのが俺が言いたかったこと。
確かにって思ってくれる?

>>216
>文字列の長さが階層の深さに比例するというのは
>お前が勝手に決めたルールであって、そんなルールは
>ツリーという言葉には適用されない。

俺はデータを見て文字列の長さと階層の深さが比例すると仮定してコードを
示しただけだから、仮定はルールとは違うよね。それはそのとおり。
文字列の長さと階層の深さが比例するという仮定はツリーという言葉のみから
導いたものでもないのですべてのツリーに当てはまるというのは偽である。
これもそのとおり。なんだか疲れるなあ。なんかあれだな、ストローマン論法しかけられてるみたいw

文字列の長さが階層の深さに比例するというのはルールだなんて俺言ってないし、
そのルールがツリーという言葉に適用されるとも言ってないw

では文字列の長さが階層の深さに比例するというのはルールだといったのは誰か? 君だよね。
そのルールがツリーという言葉に適用されるといったのは誰か? これも君だよね。

こういう自作自演の論法は無益なだけだと思うんだよなあ。俺無職なんだけど、お仕事してる人は
毎日こういうことと戦っているの?おじさん働きたくない!!

“文字列の長さと階層の深さが比例するという仮定はツリーという言葉のみから導いたものでもないのですべてのツリーに当てはまるというのは偽である。これもそのとおり。”と認めておられます。結局、このひとは勝手に勘違いした上でコードを書き(ここまでは悪いことではありません)、その問題点が指摘されるととたんに相手を批難する、そんな姿勢がいけないのです。

220 デフォルトの名無しさん [sage] 2014/01/19(日) 17:35:29.27 ID: Be:
>>219
> しかし、言った本人が>>172でYAGNIを破ってるじゃないか。

破ってないよ。

きれいなコードを書いただけ。

221 デフォルトの名無しさん [sage] 2014/01/19(日) 17:36:21.17 ID: Be:
カモノハシ君必死だなw

222 デフォルトの名無しさん [sage] 2014/01/19(日) 17:38:53.06 ID: Be:
>>216
>「哺乳類は卵を生むよ。カモノハシと仮定するならね」

どうでもいいっちゃどうでもいいんだけど、これって筋通ってないか?

(大前提)すべてのカモノハシと呼ばれるものは卵を産むものだ。
(小前提)すべての哺乳類と呼ばれるものはカモノハシと呼ばれるものだ。
(結論)ゆえにすべての哺乳類と呼ばれるものは卵を産むものだ。

小前提が間違ってるから論証としては間違ってるけど演繹は正しいよね。
小前提が成り立たないだけで。演繹が正しいならじゅうぶん論理的だと思うよ。

そもそも質問者の話が一番尊重されるべきで、後から仮定を付けて離すのは良くないと思います。仮定を付ける場合はそれをはっきりと断った上でソースコードを張るべきです。思い込みが間違っていたならそれを認めて誤るなりフォローを入れるべきです。

ちなみに仮定が偽だと命題は真です。

223 デフォルトの名無しさん [sage] 2014/01/19(日) 17:42:28.58 ID: Be:
>>220
じゃあ俺も破ってないよ、仮定がたまたま違ってただけ。

224 デフォルトの名無しさん [sage] 2014/01/19(日) 17:42:35.08 ID: Be:
「哺乳類は卵を生むよ。哺乳類=カモノハシという仮定が正しければね」

性格には、だろ?

225 デフォルトの名無しさん [sage] 2014/01/19(日) 17:43:41.35 ID: Be:
>>223
仮定が間違っていたのだから
答えが間違っているっていうんだよ。

ツリーはトライツリーじゃないし、
トライツリーは階層が深くなるとキーが長くなると決まっていない。

226 デフォルトの名無しさん [sage] 2014/01/19(日) 17:56:08.61 ID: Be:
>>225
>仮定が間違っていたのだから
>答えが間違っているっていうんだよ。

んなアホな。俺いまのプロジェクト終わったら結婚するんだと言った人が
プロジェクトが終わらなかったとしても子どもができちゃって結婚する
かもしれないだろ。プロジェクトが終わるという仮定は間違ってても
結婚するという答えはあってるかもしれないだろ。俺はまだあきらめてない。
安西先生も言ってた、あきらめたらなんとかかんとかって。

>ツリーはトライツリーじゃないし

そうだね、質問した本人がそういう旨のこといってるからそれは間違いない。

>トライツリーは階層が深くなるとキーが長くなると決まっていない。

トライは文字ごとにノード作るんだから文字列が長ければ階層も深くなるよ。

この人はキー自体(文字列)と識別するためのデータを混同されている。

227 デフォルトの名無しさん [sage] 2014/01/19(日) 18:19:52.93 ID: Be:
>>226
トライツリーを、理解するのに精一杯でしょw

文字列が合って、そこからトライツリーにするんじゃなくて、
トライツリーという構造が合って、その実装に
文字列キーに使ったり、文字列以外の物をキーに使ったりするわけ。

主体は文字列ではなくて、トライツリーなんだよ。
まだまだ素人、抽象化って考え方ができていない。
文字列がなければトライツリーという構造をイメージ出来ないでしょう?

228 デフォルトの名無しさん [sage] 2014/01/19(日) 18:28:53.18 ID: Be:
>>227
理解してるつもりなんだけどなあ。
>>166でコードも書いたし。

>文字列キーに使ったり、文字列以外の物をキーに使ったりするわけ。

トライで文字列以外のものも管理できるよって話ね。
文字列以外のものって数値とか?

>主体は文字列ではなくて、トライツリーなんだよ。

これはちょっと意味がわからない。何の主体?

“文字列以外のものも管理”といっていますが、そもそもキーは管理するために付けるラベルであって、管理される対象ではありません。主体はキーではなく、そのキーに対応づけられているデータ(トライ木)です。

229 デフォルトの名無しさん [sage] 2014/01/19(日) 18:31:17.20 ID: Be:
トライツリーに文字列は必須ではない。
つまり、文字列は不要って話。

230 デフォルトの名無しさん [sage] 2014/01/19(日) 18:32:48.93 ID: Be:
>>228
コードは真似すればいいだけだから誰でもかける。
重要なのは考え方。

素人は、何かを知ったらそれで全部やろうとしてしまう。
つまり、ツリーと聞いてトライツリーのしかも一実装を
前提にしてしまうのがその証拠。

考え方を理解しているのではなく、
その一例を知ってるだけ。

231 デフォルトの名無しさん [sage] 2014/01/19(日) 18:33:04.27 ID: Be:
>>229
ちょっと勝手に話を終わらせないで欲しいなwまあいいや君あまり知らなそうだし。

232 デフォルトの名無しさん [sage] 2014/01/19(日) 18:34:32.25 ID: Be:
>>230
俺は素人だと君は言ってるだけだね。
そういう話は興味ないわw悪いけど。
技術的な話が聞けるかと思って話し振ってみたんだけど、無理そうだからいいですw

233 デフォルトの名無しさん [sage] 2014/01/19(日) 18:36:21.16 ID: Be:
だいたいツリーって言っているだけなのに、
トライツリーであるという思い込みで
アルゴリズム書くのが馬鹿だよね。
トライツリーじゃなかったらどうなるのさ?

あなたのアルゴリズムは使えません。って言われるのが落ち。

仕様をきかずに突っ走って実装する
典型的な素人を脱したつもりの素人。

234 デフォルトの名無しさん [sage] 2014/01/19(日) 18:40:29.86 ID: Be:
>>232


技術的な話?
>>160の話だよね。

>>160の問題を解決する、正しくて素晴らしい実装を示しただろ。
それを理解できず的はずれな指摘で難癖つけてるのはお前

お前が出したものはトライツリーでなければ使いものにならない
アマチュアコード書いて自己満足しているみたいだけど。

そして延々と自分の都合のいい話をしているだけ。

235 デフォルトの名無しさん [sage] 2014/01/19(日) 18:47:56.92 ID: Be:
>>233
仕事でここにいるわけじゃないし。仕事もしてないし。
素人というなら俺は生粋の素人。
ここはこうなのかと詳細つめて実装するのも面倒なんで
質問文読んでこういう仮定でこういうコード書いたって提示して
あとは質問者が選ぶだろうからそれでいいかと。俺のコードを
何がなんでも使えと質問者に押し付けてるわけではないし、
押し付けることができるわけでもないし。質問者がありがとうございましたと
返信してくれたらラッキくらいの本当に謙虚な気持ちで俺はここにいるわけ。

あなたのアルゴリズムは使えませんと言われてもじゃあしょうがないとしか思わないので
まあ別にどうでもいいかなそのへんは。君はそういうの気にするほう?大変じゃない?ここ2chだよ。
おじさん君のメンタルが心配だよ。

“技術的な話が聞けるかと思って”るのに技術的な話をされると“まあ別にどうでもいいかなそのへんは”といってしまうのはどうしてなんでしょう?

236 デフォルトの名無しさん [sage] 2014/01/19(日) 18:59:50.29 ID: Be:
>>234
正しいことを判断するのは君じゃないよねw
素晴らしいと自分で言うのはあれだよね、あれだと思うよ。君、あれだよ。
俺はトライのような構造という仮定でコードを書いた。
君は俺とは違う仮定でコードを書いた。
仮定が違うからお互いに言い合うことが的外れなのはまあ仕方ないかと。
すこしくらいすれ違うほうが会話は弾むものだよ、ご愛嬌ってことで。
俺と話して楽しかったでしょう?いやあ俺もね思わず時間を忘れたね、ひさびさに楽しかったね。

237 デフォルトの名無しさん [sage] 2014/01/19(日) 19:31:47.82 ID: Be:
>>235
仕事かどうかじゃなくて、
プログラマかどうかね。

本物のプログラマの品質と
素人(お前の)の違い。

仕事してなくても本物のプログラマはいる。
ようはゴミコードばらまかないでくれって話。

238 デフォルトの名無しさん [sage] 2014/01/19(日) 19:33:22.90 ID: Be:
>>236
> 俺はトライのような構造という仮定でコードを書いた。
その仮定のでお前は無駄なコードを書いた。
トライではなかったのだから。

まあ、トライにしてもコードの質は低いけどねw
かろうじて動く程度のコード
メンテナンス性など一切考慮されていない。

239 デフォルトの名無しさん [sage] 2014/01/19(日) 19:59:00.97 ID: Be:
>>237
プログラマじゃないしプログラマのようにコード書けると
思ってるわけでもないんで、なんで君はそう何度も俺に素人だと
言ってくるのかちょっとよくわからない。恋心とは違うでしょ?
違うと思うわ。俺はねそのへん冷静に考えられるだけの頭は持ってるつもりだから
君が俺に思いをよせてるとは当然思っていないよ、でも君がもしよ、もし女で、
ある程度容姿が優れていて俺のことを少なからず思っているというのなら
俺はメールアドレスを交換する用意があることをお伝えせざるを得ない。

>ようはゴミコードばらまかないでくれって話。

い や だ。

>>238
無駄というならこうやって2chをながめていることさえも
君にとっては無駄なことだろう。俺は生活の一部だけどねw
俺にとって無駄なことだからやるべきじゃないと俺のことを
心配してくれているとしたらほんとうにありがとうございます。

>メンテナンス性など一切考慮されていない。

そうだね。2chに投稿したコードを今後ともメンテナンスしていこうなどという
気概はまったく持っていない。俺もITのお仕事に就いたらそういうふうに考えるように
なるのかなあ。それって幸せなことなんだろうか。いまの俺には皆目わからない。

240 デフォルトの名無しさん [sage] 2014/01/19(日) 20:13:41.75 ID: Be:
>>239
うぜぇw

241 デフォルトの名無しさん [sage] 2014/01/19(日) 20:13:48.82 ID: Be:
単純な話、そういう気概で議論したい人は(多分)2chにはいないと思うから
好きなだけ一人相撲するといいよ

242 デフォルトの名無しさん [sage] 2014/01/19(日) 20:16:09.66 ID: Be:
なに恋とかわけわからんこと言い出してるんだろw
こいつ脳みそおかしいw

243 153 [sage] 2014/01/19(日) 21:33:49.95 ID: Be:
誰が誰だかわからんが
>>167の偉そうな感じの悪さは頂点クラス

どうせこいつのせいだろ荒れたの

私はこのスレに書き込んだことすらありませんが、客観的に見て悪いのはトライ木の人です。……ですよね?

私のサークルでもこんな話に矛盾があって、言い訳ばかりして、自分は何も改善しようといないで、口ばかり動かして、向上心のない人がいました。そんな人に似ていたのでつい取り上げてしまいました。