問題タブ [lazy-sequences]

私は、clojure の遅延シーケンスがいつ遅延するのか、いつ作業が行われるのか、そしてそれらにどのように影響を与えることができるのかを理解しようとしています。

ここで「fn call!」が 2 つだけ表示されることを期待していました。それを管理する方法はありますか？とにかく、議論の余地なく 1 つの評価しか必要としないものに移ります。

first遅延シーケンスには適していませんか?

この時点で、すべてを理解することなく、おもちゃの lz-seq の先頭にアクセスする方法について完全に途方に暮れています。どうしたの？

私は次のように書いた：

4clojure.com の問題 #118 を解決するには: http://www.4clojure.com/problem/118

マップなどを使用せずにマップを再実装するように要求し、そのソリューションはテストに合格します（それが正しいかどうかはわかりません。他のソリューションに非常に近いです）。

問題は怠惰でなければならないと述べていたので、私の解決策をlazy-seqで「ラップ」して上記のコードを書きました...しかし、lazy- seqがどのように機能するかわかりません。

ここで「怠け者」とは何か、またそれをテストする方法がわかりません。

私が尋ねる(type ...)と、当然のことながら、clojure.lang.LazySeqが得られますが、それと単にレイジー seqの「ラッピング」を削除した場合に得られるものとの違いは何なのかわかりません。

もちろん、lazy-seq を削除すると、これを実行しようとする理由でスタック オーバーフローが発生します。

それ以外の場合 (つまり、lazy-seq ラッピングを適切に行えば)、問題なく動作するようです。

そこで、どういうわけか「デバッグ」/何が起こっているのかを追跡して、すべてがどのように機能するかを理解しようとすることにしました。次のマクロを使用しました (SO IIRC で見つけました)。

そして、作業バージョンをdbgマクロ内にラップし、再度実行しようとしました。そして今、kaboom: 正常に動作していたバージョンでも、stackoverflow がスローされるようになりました。

今はよくわかりません: マクロの望ましくない効果で、他の方法では評価されないものの評価を何らかの形で強制するのでしょうか?

この単純な関数と単純なテストを使用して、ここで遅延がどのように機能するか、正確には何が呼び出されるかなどを誰かが説明できれば素晴らしいと思います.

私はシーケンスA003602のPythonジェネレーターを作成するための巧妙な方法で遊んでいました

これは機能しているように見えますが、理由がわかりません。無限再帰を打つべきだと私には思えます。Pythonは、私が認識していない場所で遅延評価を行っていますか？

私には、RZがインターリーブによって返されたメソッドを即座に呼び出し、次にRZであるbを呼び出すので（最初のyieldの呼び出しの前に）、これは無限再帰である必要があります。しかし、これは実際には機能しているようです。誰かが理由を説明できますか？

私はよく、配列インデックスが複雑なユーザー指定のセットから生成される多次元配列を扱います。

任意の数のインデックスと任意の複雑な述語を持つ複雑なセットを表すためのクラスを含むライブラリを探しています。セットの説明が与えられた場合、目的の出力はジェネレーターになります。このジェネレータは、多次元配列インデックスに対応するdicts またはs を生成します。tuple

そのようなライブラリは存在しますか？

例

次のユーザー指定のセット ( set-builder 表記法) があるとします。これは、配列変数のインデックスを表しますx[i][j]。

{i in 1..100, j in 1..50: i >= 20, j >= 21, 2*(i + j) <= 100}

これをある種の遅延クラス (おそらくジェネレーター式) に入れたいと思います。これにより、セットの要素を遅延評価して配列のインデックスを生成できるようになります。このクラスが呼び出されたとしlazysetます。これは望ましい動作です。

ジェネレーター式を使用して独自のロールを作成できると考えていますが、これはほとんど解決された問題のようです。それで、これを処理する確立されたライブラリに誰かが遭遇したかどうかを尋ねたと思いました（少なくともある程度は）。そのようなライブラリは存在しますか？

この怠惰な素数シーケンスの定義が非終了を引き起こす理由がわかりません。私が取得したスタック トレースはあまり役に立ちません (clojure に関する私の不満の 1 つは、スタック トレースがわかりにくいことです)。

いくつかの Clojure コードのストレス テストを行っているときに、大規模なデータ セットを反復処理しているときにヒープ領域が不足していることに気付きました。私は最終的に、Clojure のdoseq機能と遅延シーケンスの実装の組み合わせに問題を突き止めることができました。

これは、使用可能なヒープ領域を使い果たして Clojure をクラッシュさせる最小限のコード スニペットです。

のドキュメントにdoseqは、遅延シーケンスの先頭を保持しないことが明確に記載されているため、上記のコードのメモリの複雑さは O(1) に近いと予想されます。足りないものはありますか？非常に大きな遅延シーケンスを繰り返し処理する Clojure の慣用的な方法は何doseqですか?

私はいくつかの文字列を持っています：

次に、それらの一部を連結して、文字列「テキスト」を作成します。残念ながら、以下の両方の文字列は機能しませんでした。

これは、関数がレイジーシーケンスtakeをtake-last返すためです。問題は、文字列の複数の遅延シーケンスを連結して1つの文字列を返す適切な方法は何ですか？

編集：私は1つの解決策を見つけました---(apply str (concat (take 4 a) " " (take-last 4 a)))しかしそれは最も正しい方法ですか？

これを実行すると、期待どおりに機能します。

しかし、私はベクトルで同じことをしたいと思います：

これにより、スタックオーバーフローが発生します。なんで？

レイジー seq は常にチャンクされているという印象を受けました。

によって返されるレイジー seq はrange32 要素のチャンクに分割されるため、予想どおり 32 ドットが出力されます。ただし、代わりにrange自分の関数でこれを試すとget-rss-feeds、遅延シーケンスはチャンクされなくなります。

ドットが 1 つだけ出力されるので、返される lazy-seq はget-rss-feedsチャンクされていないと思います。それはそう：

のソースは次のget-rss-feedsとおりです。

そのため、チャンク性は、レイジー seq の生成方法に依存するようです。関数のソースをのぞき見したところrange、「分厚い」方法で実装されているというヒントがあります。だから私はこれがどのように機能するかについて少し混乱しています。誰かが明確にしてもらえますか？

これが私が知る必要がある理由です。

次のコードが必要です。(get-rss-entry (get-rss-feeds h-res) url)

を呼び出すとget-rss-feeds、調べる必要のあるフィードの URL の遅延シーケンスが返されます。

への呼び出しget-rss-entryは、特定のエントリ (:link フィールドが get-rss-entry の 2 番目の引数と一致する) を探します。によって返された遅延シーケンスを調べますget-rss-feeds。各項目を評価するには、新しい RSS フィードを取得するためにネットワーク経由で http 要求が必要です。http リクエストの数を最小限に抑えるには、シーケンスを 1 つずつ調べて、一致したらすぐに停止することが重要です。

コードは次のとおりです。

entry-with-url一致の遅延シーケンスを返すか、一致がない場合は空のシーケンスを返します。

これをテストしたところ、正しく動作しているようです (一度に 1 つのフィード URL を評価します)。しかし、どこかで、どういうわけか「分厚い」方法で動作し始め、一度に 32 個のフィードを評価し始めるのではないかと心配しています。here で説明されているように、チャンキーな動作を回避する方法があることは知っていますが、この場合は必要ではないようです。

非慣用的にレイジー seq を使用していますか? ループ/再帰はより良い選択肢でしょうか?

述語を使用してシーケンスをフィルタリングする関数を作成したいのですが、結果には、述語がfalseを返す最初の項目も含まれるはずです。

F＃にbreakキーワードがあった場合、ロジックは次のようになります。

Seq.takeWhileとSeq.skipWhileの組み合わせを試してみました。次のようなものです。

...しかし問題は、述語に一致する最初の項目がtakeWhileとskipWhileの間で失われることです。

また、入力シーケンスは怠惰であるため、シーケンスを消費し、後で決定を行うソリューションは実行可能ではないことに注意してください。

何か案は？

ありがとう！

編集：すべての答えをたくさんありがとう！こんなに速く反応することは期待していませんでした。それぞれをすぐに見ていきます。ここで、もう少しコンテキストを示したいと思います。シェルを実装する次のコーディングカタについて考えてみます。

この実装には、「さようなら」が出力されないという問題があります。コマンドqが入力されたとき。

私がやりたいのは、 「q」を含む「q 」までのすべてのコマンドを処理するように、関数processUntilQuitを実装することです。