- ★★Java質問･相談スレッド171★★
815 ：デフォルトの名無しさん[sage]：2014/12/13(土) 09:01:39.31 ID:1Rys2+MB - >>813
操作のタイミングやDBアクセスのパターンが
そこらへんの業務アプリと大差ないというのもあるな
|
- Ruby 初心者スレッド Part 55
980 ：デフォルトの名無しさん[sage]：2014/12/13(土) 09:11:32.36 ID:1Rys2+MB - >>978
Set
|
- Ruby 初心者スレッド Part 55
985 ：デフォルトの名無しさん[sage]：2014/12/13(土) 09:26:51.09 ID:1Rys2+MB - >>981
最近の言語では列ごとに縦の配列を作るなんてFortranや昔のCみたいな前時代的な発想はしない
確かにメモリの利用効率やアクセス効率の面でメリットはあるが、
Rubyの配列はもともとクソ非効率だから意味は無い
レコードごとにハッシュ作るような昔の人が見たら卒倒するようなことすら平気で行われる
|
- Ruby 初心者スレッド Part 55
992 ：デフォルトの名無しさん[sage]：2014/12/13(土) 09:57:09.43 ID:1Rys2+MB - >>991
だったらソートしてから比較しろ
|
- Ruby 初心者スレッド Part 55
994 ：デフォルトの名無しさん[sage]：2014/12/13(土) 10:07:58.45 ID:1Rys2+MB - 土方言語のVBやC#やJavaでもできるけどね
|
- ★★Java質問･相談スレッド171★★
817 ：デフォルトの名無しさん[sage]：2014/12/13(土) 11:16:03.94 ID:1Rys2+MB - インデックス使わなくても問題ないんなら付けなくていいだろう
いわゆる「時期尚早な最適化アンチパターン」ってやつで、別にDBに限った話じゃない
|
- C#, C♯, C＃相談室 Part85
671 ：デフォルトの名無しさん[sage]：2014/12/13(土) 11:37:29.69 ID:1Rys2+MB - 「ランダム性」の意味によるだろう
事前に予測できないが入力が同じなら結果も同じでいいんならIComparerでハッシュ値でも使って比較すればいい
|
- ★★Java質問･相談スレッド171★★
825 ：名無しさん＠そうだ選挙に行こう[sage]：2014/12/13(土) 20:14:26.76 ID:1Rys2+MB - MinecraftってPC版以外はC++でしょ?
今はMicrosoft傘下だからすぐにC#一本になるかもね
|
- ふらっと C#,C♯,C＃（初心者用） Part113
844 ：名無しさん＠そうだ選挙に行こう[sage]：2014/12/13(土) 20:20:35.48 ID:1Rys2+MB - >>841
そりゃラムダに限らず単に管理がいい加減なだけだろう
|
- C#, C♯, C＃相談室 Part85
730 ：名無しさん＠そうだ選挙に行こう[sage]：2014/12/13(土) 22:31:52.23 ID:1Rys2+MB - >>726
アプリケーション的な条件を含めて考えていいんならこんな視野の狭い議論は無駄
そもそも幅優先探索にすればnが大きくなるだろうとか
結局面白い面白くないの問題なんだったらわざわざ探索中の全てのソートで同一値をランダムにする必要はないとか
そんなレベルの話になる
|
- C#, C♯, C＃相談室 Part85
733 ：名無しさん＠そうだ選挙に行こう[sage]：2014/12/13(土) 22:45:02.72 ID:1Rys2+MB - じゃ最初はクイックソートだけでやって
配列から次の手を取り出すときにその次善の手も調べて
評価値が同じだったら同一値を考慮したソートでやり直せ
|