1

を更新するために、O(1)の性能、のは、私は整数配列を持っているとしましょう。 私は配列の要素を変更したい場合は、私は、メモリ内の特定のアドレスのデータを変更することによって、そうすることができます:a[2] = 9; =>{1, 2, 9, 4, 5}Clojureの可変性:<code>int[] a = {1, 2, 3, 4, 5};</code>:Javaでは、ベクター

はClojureので、私はベクトルを持つことができます(def a [1 2 3 4 5])。 O(1)の最悪ケースの時間複雑度が保証されたベクトルの特定の位置の要素を変更するにはどうすればよいですか?私はassocキーワードがO(1)平均時間の複雑さを持っていることを読んだが、これは私が探しているものではない。また、一時的なベクトルを調べましたが、O(1)のベクトルを更新するための良い例と簡単な例はまだありません。

+0

あなたは既に配列にO(1)更新があり、ベクトルに平均O(1)更新があることを知っています - 両方のデータ型をClojureから使うことができます。 – noisesmith

+0

@noisesmithはい、質問があります。上記のようなパフォーマンスを持つプリミティブなClojureデータ構造はありますか?また、上述したように、平均時間複雑度が有用であるので、この場合はそうではない。 http://stackoverflow.com/questions/17048076/big-o-of-clojure-library-functionsこれはassocが実際にO(logn)(基数32)であることを示すテーブルです。また、Clojureデータ構造には、O(1)最悪のアクセス時間または更新時間がないことも示されています。 – ljeabmreosn

+0

プリミティブなし。 ClojureはJavaライブラリです。Javaデータ構造が必要な場合は、Clojureコードで使用できます。 – noisesmith

答えて

4

はClojureのでは、ベクターは、特定のデータ型である - それは不変であり、O(log_32(n))を更新、通常、元と構造的に共有する新しいベクターを返しを有しています。あなたはO(1)の更新が必要な場合

、あなたは、Array、Javaのデータ型のすべてが、Clojureのから使用可能なを使用することができます。ここではintoを使用して、replで簡単に表現できるようにしています。それぞれの使用法によって新しいベクトルが作成されるため、パフォーマンスを重視するコードではこれを避けることをお勧めします。

+user=> (def a (into-array Object [:a 1 :b "m" (java.util.Date.)])) 
#'user/a 
+user=> a 
#object["[Ljava.lang.Object;" 0x456d6c1e "[Ljava.lang.Object;@456d6c1e"] 
+user=> (into [] a) 
[:a 1 :b "m" #inst "2016-06-11T20:28:05.230-00:00"] 
+user=> (aset a 2 'new-contents) 
new-contents 
+user=> (into [] a) 
[:a 1 new-contents "m" #inst "2016-06-11T20:28:05.230-00:00"] 

Clojureにはさまざまな種類のfunctions defined for working with arraysがあります。

+1

Java配列によるO(n)更新またはO(1)更新? – ljeabmreosn

+0

これはエラーです – noisesmith

2

Clojureのベクターは、それらの現在の実装では、O(log_32(N))(ベース32における対数)の複雑さを有します。数学的には、O(log_32(n))はO(log(n))と同じです。違いは、理論が、実用的ではありません。

  • AFAICT、Clojureの永続的なベクターは、より多くの、と言うよりも、40億個の要素、log_32(n)を含めることはできませんのでやり方で、だから、7より大きくなることはありません、それ一定時間です:)。これは、Persistent Hash Triesの分岐ファクタが32であることを説明しています(分岐ファクタが2である多くのツリーデータ構造とは異なります)。
  • 定数因子が問題になります。 Java配列の更新は永続的なベクトルよりもはるかに高速です。あなたは漸近的な複雑さについて考えるべきではありませんが、この一定の要因があなたにとって大きすぎるかどうか疑問に思うべきではありません。もしそうなら、transientsを見てください。
関連する問題