O（n)のソートアルゴリズムを発見した

やばい！論文書きます

>>3-
そーっとしておいてあげてください

O(1)のソートアルゴリズムがある件

バケツソートとか普通にあるだろ。

対象データに仮定が必要ないんだぜ

特許とれ。

こういう単純な処理は標準ライブラリに限る。
ただ、自前で実装しないといけない場合がよくある。
そういう用途のソートアルゴリズムがほしいわけです。(簡単で高速で特に欠点ないやつ)

夏だなあ・・・

もうネタ出尽してるのに人気あるよなソート

たまに思い出したように湧いてくるよね。
とっとと駆除しないと。

いや待て、古典アルゴリズムなら無理だが、
量子アルゴリズムなら可能かもしれないだろ？
>>1 は古典アルゴリズムと明言していない。
ならまだ可能性はあるんじゃないのか？

量子アルゴリズムが効果的に使えてその辺で買えるコンピュータがあればくれ。

>>12
http://music8.2ch.net/test/read.cgi/classical/1211529290/

listコンテナにもつかえるsortアルゴリズムというと
バブルソートだけですか？

古典コンピュータ以外でのO(n)のアルゴリズムが発見されたとしても、lg(n)時間減るだけじゃなあ。
元々多項式時間なだけに価値があるかどうか。

>>14
マージソートとか

O(n)のソートを開発したぜ。ただしある特定の配列のみ適用可能。

def sort(arr)
    for i in 0..arr.length-2
        if arr[i] > arr[i+1]
            raise "not sorted!"
        end
    end
    return arr
end

sort [1,2,3]

それなら、

def sort(arr)
  [1,2,3]
end

でよくね？

ソート対象のデータに全順序以外の仮定がない場合，
ソートの計算時間の下限がO(NlogN)なのはすでに証明済みだったような？

双方向リストってクイックソート使えても良さそうだと思うんだけど、
何で使えないのん？

作ってないから。

>>1しょぼいな
俺なんかナップサック問題を多項式時間で解くアルゴリズムを発見したぞ。

でもそれを記述するにはこの余白はあまりにも少なすぎ

0-1でなきゃ貪欲法で元々多項式時間じゃないか。

>>23 最適解じゃないし。そんなの解いたとは言わん

>>22
書き始めていいよ
埋まりそうになったら次スレ用意する

>>24
0-1でなきゃ、の意味も掴めないのか？一般化ナップサックの話だよ

suckと申したか

卑猥だな

おまいら、コンビニの前でチンチンの(自己申告の)でかさを競い合ってるDQNとかわらんぞ。

>>26
おいおい、0-1でないと意味ないだろ。
お前、月に行くとして酸素ボンベ半分とか、拳銃0.8個とかナップザックに詰めて
持っていくのかよ。月　を　な　め　る　な

月に拳銃は要るのかどうかは知らんがﾜﾛﾀ

>>22
フェルマー乙

オレもありとあらゆるデータを1bitにするアルゴリズムを持ってるよ。

非可逆のハッシュなら俺も持ってる。

>>20
ttp://www.geocities.jp/m_hiroi/light/pyalgo08.html

>>35
xyzzyの人ですか

>>35
別に普通にできるだろ？
ttp://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/8332.txt

要素数が少なくなったらO(N^2)に切り替えるというのも、
分割する際についでに数を数えておけば最初の１回以外は何とかなる。
std::list::sort にした方がノードの交換効率もいいし最初でもO(N^2)交換ができるが、
std::sort を使えなくする必要性はないと思われる。

×O(N^2)交換
○O(N^2)ソート

カウントはO(N)だから最初にやってしまってもいいな

age

>>38
std::sortはクイックソートである必要はないという建前だから。
例えば、最初はクイックソートするけど、
分割していって要素数が減ったら別のソートをやるということがあるでしょ。

>>38 はまさにその話だろ？
リストは普通にO(N^2)ソートできるから問題ない。
std::sort では要素数少ない時は
交換回数の少ない選択ソートが使われる事が多いが、
別に双方向リストでも選択ソートは可能だ。
ttp://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/8359.txt

std::sort は O(N logN) で余分なバッファを使わなければ何でもいいのだが、
まさにこれはその要件を満たしてる。
まあ、実際には pivot の扱いを変えないと std::sort としては使えないんだが、
そこは std::sort にするならそう実装すればいいってことで。
（昔書いたコードの使い回しなんで・・・）

当然 std::list::sort として実装した方が効率的なので
std::list::sort が存在することに何も問題は無いんだが、
std::sort を random access iterator に限定して
bidirectional iterator に対してわざわざ使えなくする必要性は無いよね。

そんなことほかにも考えているやついるんじゃないかと思ってググってみたら案の定。
http://www.kmonos.net/wlog/68.html#_2116061224
この人の場合、クイックの後で併用するソートの計算量が良くないねという結論で終わっている。

なるほど。ヒープソートも使ってんのか。
それじゃしかたないかもね・・・。

そろそろだと思うんだ。


Big-O　ショー　タァーイム！！


Comb Sort11最高。

gap ありだと bidirectional iterator に適用し辛いな。
余計なバッファを使う必要がある。

シェルソートと似たようなアルゴリズムなのに
何でシェルソートより速いんだろうな。

コムソートは平均でも最悪でもほぼO(n log n)でしょ？
理論的限界もO(n log n)じゃなかったっけ？
実装簡単だしメモリ食わないし好きだ。

コムソートは欲しいときにすぐ書けるのがいい。
安定でないのが玉にキズだけど。

ソートって、データの全てのペア(nC2)についての
比較情報だけ（少し無駄がある）あれば、理論的にはOKだよね？

その比較演算が全順序関係になっていると保証できればOK

じゃんけん風味だと終わんないもんな

>>52
だから普通のソート法は最悪でもO(N^2)のオーダーなわけだ。
ボゴソートのような無茶苦茶なものは除いて・・・。

bidirectional iterator に適用できる
メモリ使用量 O(lonN) 以下の
最悪計算時間が O(NlogN) のソート法ってないもんかねえ・・・。
ないことが証明されてたりするのかね。

ボゴソートは要らない子

>>57
そんな彼が好きなんです。

ソート済みのデータでも容量がGBやTBクラスだと
どうやって取り扱ったら良いのか分かりません＞＜

ISAMとか真似すれば？

B木とかそういうので扱えばいいんじゃないかな

shear sortって、wikipedia日本語版では「シェアソート」って紹介されてるのね。
どう聞いても「シア」にしか聞こえないんだけど、「シェアソート」になった由来は何かあるのかな?
# 最近話題の「ウィンド･シア」の方はシェアとは言わんよね。
## あっちの業界はあっちの業界で、「porpoise」を妙ちきりんな読み方しているけど。

シェルソートにひきずられたかなぁ？
まぁ古いアルゴリズムとかは妙なカタカナが定着してたりすることは
よくあること...だけど、活字で残ってる用例あるかなぁ。あまり紹介
されないソートだし。てか今知った。

最初に訳した奴がバカだったんだろう
そういうのあるよね

ねーよｗ

ウィキペディアだとありそうだな。

どうもウィキペディアを勉強ノート代わりにしたっぽい奴が書いた項目を見つけて
頭が痛いところだったり。

直してあげな。

いやぁ、なんか理由があるのかと思って躊躇していたのさ。
誰も直さないようなら、今度暇なときにでも直しておくよ。

Googleで検索する限りでは、シアソートって書いてるページ、ほとんどないぞ？

シェアソートって書いてあるページも、多くはWikipediaを参照している罠。

『アルゴリズム辞典』に載ってればそれに従うところだが、載ってないんだよな。
TAOCPはどうだろう。

あらかじめソートされた結果を知っていれば
たとえ
ボゴソートとかであっても恣意的な神の手を加えることにより
ものすごい低いオーダーを実現できるよねｗ

安定でマージソートより優秀なのは何？

クレオソート

バケツソート

>>72
ソート済のデータを渡せばO(1)

汎用ソートの場合、ifを使わずにreturn a-bとかで直接返した方が効率いいんだろうな。
strcmpやmemcmpとかも使って。可読性は知らんが。

>>77
例えばint型のときにreturn a-bなんてしたら、値域が限定されて汎用じゃなくなるよ。

それはint型の比較関数としてreturn a-bがふさわしくないから。
ソートの汎用性とは関係ない。

比較関数は比較する型ごとに作るんだよ？わかる？

こいつわかってないわ

　　 ∧＿∧　　／￣￣￣￣￣
　　（　‘∀‘）＜　オマエガナー
　　（　　　　） 　＼＿＿＿＿＿
　　｜ ｜　|
　　（_＿）＿）

つまり、a-bって書くとunsigned同士は勿論、signed同士でも巧くないってことか。

int全体の比較関数をa-bと書くのはアホだろ。

単なるバグだし。

20億近くまで数字が分布するようなアプリのが少ないから問題ないだろ。
お金周りのアプリなら8バイトなり古典小数点数ライブラリなり使うだろうし。

×古典 ○固定

会計処理で重要なのは、固定小数点ではなく、十進演算であること

JavaのBigDecimalは十進演算だったのか。
言われてJavaDoc覗いて初めて気付いたｗ

いや、Decimalって書いてるだろｗ

>>84
問題は、その発想のままshort intにまで適用してしまう可能性があることだな。

return (a>b)-(a<b);

>>87-88

表示する時の演算コストを考えてんだろうね

Ruby 1.9 And Rails 3.0
http://www.slideshare.net/arrrrcamp/ruby-19-and-rails-30

なんでボゾソートがボゴソートより速いのか理解できない

∨
[[[[[[[ Ruby 1.9 And Rails 3.0 ]]]]]]]（キリ!!!!キリッッッキリッッッッ!!!!
∧∧∧∧∧∧∧(←きリッッ!!

Sleep SortのスリープをCPUクロック数に置き換えたら凄いんじゃね？
しかも超マルチコア前提で

よし、O(N)のアルゴを教えてやろう。
ソート前の全組み合わせの膨大なデータを分散ストレージに用意しておくんだ。
ソート処理ではハッシュを計算するだけ。

>>97
それってビンソートとどこが違うの？

クイックソートをマルチスレッド化したらどれくらい速くなるかなあ？
分割する度に片方の群を別スレッドに渡していくような処理を考えたんだけど
もちろん要素数が少ない時はスレッド分割なしにして
メモリアクセス性能次第かな

>>99
TSV DRAMが普及するまで待て
現在のDRAMの構造ではマルチコアの性能を最大限に発揮出来ない

http://www.speedtest.net/result/1500561067.png

http://www.speedtest.net/result/1500563768.png

http://www.speedtest.net/result/1500570462.png
http://www.speedtest.net/result/1500563768.png
http://www.speedtest.net/result/1500561067.png

http://www.speedtest.net/result/1500570462.png
http://www.speedtest.net/result/1500563768.png
http://www.speedtest.net/result/1500561067.png
http://www.speedtest.net/result/1326987708.png

http://www.speedtest.net/result/1500619815.png

保守

>>1
ソート対象の要素の序数が最初からわかっているという条件があって、ようやくO(n)となるのだが・・・
アカシックレコードでも発見したのか？

timソート

フリーの TBB でも使って組んでみたら？

>>96
その実装が見てみたいわ

>>99
粒度をどのくらいにするかだよね。マルチ化するために処理が増えるから
そのトレードオフを自動的に考えて判断させるような自動最適化ができた
上で最速を探すのって面白そうだけどな。前段階がちょっとおもそうだけど。

>>96
クロック数とか持ち出す時点でオーダー記法の意味わかってなさすぎ

お前>>96の意味わかってないだろ

クロックに合わせたスリープソートでマルチコアってできなくね？

nコアで値分だけnop発行とか?

>>115
あ、なるほど。勉強になりました。

1クロックですべてのデータを投入することが出来れば
クロックに合わせたスリープソートは実現可能。
でなければデータ投入にかかるクロックを厳密に計算しなければならない。

データ量に応じていろいろ考えないといけないね。
キャッシュミスしたら死ぬし。

つまりあれだ、SIMD的な何かがあればいいのか
SSXとか

このスレまだあったのｗｗｗ
俺が大学生の時に建てたスレだｗ

>>120
なんだ、中退したのか?

今ならGPUでバイトニックソート使うのが速さ的には一番だろうな

うんこぶりぶり。
精子ドピュッドピュ

中央値を高速に見つけたいんだけど、やっぱソートしなきゃダメかね

Wikipediaにはソートが必要だからO(nlogn)かかるって書いてあるね。
中央値 - Wikipedia http://ja.wikipedia.org/wiki/%E4%B8%AD%E5%A4%AE%E5%80%A4

以下、データ数nが奇数だという前提の下でソートから省ける処理がないか考えてみた。

n-1個のソートされたデータに対してn番目のデータを追加するとき、
中央値を得るだけが目的ならば暫定中央値候補2つとの比較だけすればいい。
時間を戻して、同様にn-2個のソートされたデータに対してn-1番目,n番目のデータを
追加することを考えると、n-1番目のデータは暫定中央値候補3つとの比較だけでよい。

nを101だとすると、52番目までは普通にソート。
53番目は50回比較。
…
100番目は3回比較。
101番目は2回比較。

…ダメか。(n+3)/2個のデータのソートは必要なので、
係数は変化するかもしれんが計算量がO(nlogn)であることからは逃れられん
っていうかむしろO(n^2)の部分を含んでるしorz。
高速化自体が目的なら、データ数次第では計算量のみで必ずしも優劣が決まるというわけではないけど。

両端の極端な値を落としてだいたい真ん中らへんの値
がほしいだけだから、アバウトでいいんだけど

適当にグループ分けて中央値の中央値を取ればいいのかな
でもその時点で最後までソートしても大差なさそうだな

>>123
うわっ
俺の書き込みだわこれ
懐かしい

どーでもいーけど>>125の訂正。
このやりかただとO(nlogn)でFAでした。なぜなら2分探索すると次のようになるから。logの底は2。
53番目は50回、じゃなくてlog(50)回比較。
…
100番目は3回、じゃなくてlog(3)比較。
101番目は2回、じゃなくてlog(2)比較。


アバウトでいいなら計算時間が許容範囲になるまで間引くとかも考えられるけど
（合計値の）中央値の中央値とかのほうがまっとうだね。
データ数はすごく大きいのかな？

訂正。（合計値の）←これナシで。

>>125
それは Wikipedia が間違っている。
中央値は平均ではなく最悪O(n)で求められる。

わかりにくい文だが中央値を平均O(n)で求められるなんて書かれていないぞ。
「平均値」を求める計算量がO(n)と言ってるだけ。
とくに何も断っていなければO記法の定義から最悪値の話に決まってる。
中央値を最悪O(n)で求められるというのが本当ならどのみち間違ってるけど本当?

よく読んだらたしかに平均O(n)とも言ってないな。
平均O(n)でいいなら std::nth_element でいいし、最悪O(n)が欲しいなら以下:

(1) a_0,...,a_{n-1} を D個ずつ(ここではD=5) のグループに分ける:
　　a_0, a_1, a_2, a_3, a_4 | a_5, a_6, a_7, a_8, a_9 | a_10, ...
(2) 各グループのメディアンを求める。
　　求めたメディアン m_i は、各グループの先頭要素と交換しておく。
(3) ストライド 5 にして (m_i だけを見るようにして) 再帰し、m_i のメディアン M をもとめる。
(4) M をピボットにして quick sort 的な分割を行う。
(5) 求めたい順位が含まれるほうへ再帰。

ピボットの選び方を工夫しているので、(5) では多くても 7n/10 の要素に絞ることができる。

(1) から (5) までにかかる時間 T(n) の内訳は
　(2) と (4) は Kn (K は定数)
　(3) は n/5 個の要素で再帰するので T(n/5)
　(5) は多くても T(7n/10)

よって T(n) < Kn + T(n/5) + T(7n/10)

n をある有限の範囲内 (たとえば n < 100) のときに限れば、
十分大きい定数 L を持ってきてT(n) < Ln たらしめることができる。

そこで、L をあらかじめ巨大にとっておけば (K << L になるように)
帰納法によって任意のnに関し T(n) < Kn + 9/10 Ln < Ln が示せる。

(3)が結局O(nlogn)じゃーんそれ

いや訂正、(3)はO(n)か

結局全体ではO(nlogn)じゃーん？

O(n)の処理によって候補を最悪でも7/10に絞り込めるけど、
つまりデータ量が(10/7)倍になるごとにそのO(n)の処理をプラス1回やんなきゃいけなくなるわけだから。

>>136
5で割り切れないときとかを端折って証明も添えたけど
理解できないか？

その辺の教科書によく書いてある有名な話だよ。

実際は、重いピボット選択を適当にサボるほうが平均的には速い。

gcc の nth_element の実装はサボってる。
(だから平均 O(n), 最悪 O(nlogn))

>>137
証明って、十分大きい数を用意する話はそもそもO記法の表現には関係なくないですか？

＞Kn + T(n/5) + T(7n/10)
いわゆる”O(n/5)”も”O(7n/10)”も全部O(n)ですから、
「この計算時間はKn + T(n/5) + T(7n/10) 」→「このアルゴリズムはO(n)」
の→(ならば)の部分には異存はないんです。ただそもそも計算時間はそれじゃないんじゃないかというのが>>136です。

俺が誤解してるとしたらT(n/5)の意味ですが、これってTの値がn/5の一次式で表現されるって解釈でいいんでしょうか？

あー失礼T(n/5)の意味がわかりました、漸化式みたいなもんだったんですね。

ちょっとでも数学を知っていればO(n)なんてあり得ないこと位、理解できそうなもんだ
O(n)であるということは、各々のデータの順位を求める処理の量がnの値に関係なく一定であることを意味している

つまりデータ同士の比較(これの処理量はｎの値に相関する)を使うことはできないということ

ではどうする？お前らに問いたい

>>140
バケットソートはO(n)なんだが。

なにごとも前提しだいと言うことだ。

バケツソートは「比較によらないソート」であって、一般にソートと言えば
比較によるソートのことだからな。

ソーティングの下界はnlognだと証明されてる

未来予知するアルゴリズムがあればO(n)を実現できるよ

テーブル展開してしまえばO(1)だよ、使用メモリは宇宙の全ての物質を使っても全然足りないけどなｗｗｗ

>>145
O(n)の間違いじゃね？

>>142
ではどうする？ に対して言ってるのに何を言ってんだお前は。
バカじゃないのか？ アホなのか？

>>146
ソート前のデータ全てのビット列をメモリアドレスに見立てて、
メモリの出力をソート済みの全データのビット列として取り扱うものとすればいいんじゃね

>>148
データが重複してないことが前提じゃね？

面倒だから数字一桁のソート(1と3と5が重複)

メモリアドレス：31415926535
　　　　↓
メモリデータ：11233455569

>>140
ほら、比較なしでソートできたzo

char型の値2つのソートをテーブルで実現するときそのサイズは32KB。
short型(16bit)の値2つなら16GB。char型の値4つでも16GB。今のPC事情ならメモリ上に展開できる。
int型(32bit)の値2つなら…1TBのストレージが1000円で買えたとして1475億円か。国家プロジェクトにすればいける！

チューリングマシンって無限長テープ(メモリ)だよな
ランダムアクセスできないけど

>>150
なるほど〜
アイデアとしてはアリなんだな。
問題はメモリの効率化だけだな。

いいね

>>153
まあ数学者は計算が有限時間で終わるかどうかにしか興味ないから

>>145
対応できる入力のサイズに上限があるからそもそもO記法の適用範囲ではない。
(データに応じてテーブルを大きくするんじゃなくて、どんなサイズのデータにも
対応できるテーブルをあらかじめ用意していないとダメ)
チューリングマシンのテープの長さは無限だけど、あらかじめ書きこんでおける
空白以外の記号は高々有限個だけ。
つまりあらかじめ用意しておけるテーブルのサイズも高々有限

>>156
んなわけないだろ、だったらＰとかＮＰとかの発想出てこねえよ
ＰだってＮＰだって有限時間で終わるけど興味の対象だろうがよ

ΩとかΘ記号の話が出てこないようじゃ話してる人のレベルが知れるな
記号はＯだけじゃないぞ

>>159
いずれの記号もnを無限に大きくできなければ適用できない

>>158
「数学者は」というのは一般化しすぎだったけど計算可能解析学のマイナーさを考えたら
大半の数学者が興味持ってないのは事実だろ。
有限時間内での計算量を扱う分野は数学ではなくて計算機科学に分類されることが多いし

>>161
多くの数学者にとっても計算時間は重要じゃね？
無限に時間を使っていいならこの世どころかあの世も含め
すべての事象は計算可能なわけだし。

>>162
またまたー
じゃあ停止問題解いてみろよ

問題を解くのに無限の時間がかかるってのは解けるって言うのか

>>163
無限時間チューリング機械なら停止問題は解けるよ

そもそも無限に時間を使っていいなんて言った覚えはないけど。
数学者は無限でなければ気にしないとは言ったが

英語版Wikipediaにはちゃんと中央値を求める線形時間アルゴリズムが載ってた
https://en.wikipedia.org/wiki/Selection_algorithm#Linear_general_selection_algorithm_-_Median_of_Medians_algorithm
わかってたことだがやっぱ日本語版はうんこだ

>>166
それじゃ、日本語版を改善してやってくれ。

日本語版「ん？」

選択アルゴリズム - Wikipedia
http://ja.wikipedia.org/wiki/%E9%81%B8%E6%8A%9E%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0