問題タブ [zipper]

私は自分のプログラムで実存的なタイプに苦労しています。私は非常に合理的なことをしようとしていると思いますが、タイプチェッカーを乗り越えることはできません:(

モナドを模倣したデータ型があります

ここで、 Zipperに関するHaskell Wikiの記事で説明されているものと同様のコンテキストを作成しますが、簡単にするためにデータ構造の代わりに関数を使用します-

データ値をコンテキストとサブ値に分割する関数を作成しようとすると、タイプチェッカーは次のように文句を言います。

エラーは-

しかし、私はそのようにそれを回避することができます-

なぜこの2番目の定義はタイプチェックするのに、最初の定義はタイプチェックしないのですか？

また、Rをチェックして完全な関数に変換しようとするctxと、タイプチェックエラーが再び発生します-

エラー -

このエラーを回避するにはどうすればよいですか？

どんな助けでも大歓迎です！

以下のAlexTaggartの発言の後に編集されました。

私はジッパーを使用して、何千ものノードに成長する可能性のあるツリーを簡単にトラバースして編集しています。各ノードは、最初に作成された時点では不完全です。データは常にランダムな位置で追加/削除され、リーフノードはブランチに置き換えられます。

ツリーは非常に不均衡になる可能性があります。ノードへの高速ランダムアクセスも重要です。

実装は、ジッパーを使用してツリーをトラバースし、キーでインデックス付けされたノードのハッシュテーブルを作成することです。言うまでもなく、上記は次のように非常に非効率的です。

• 各ノードの2つのコピーを作成する必要があります
• 変更は、2つのデータ構造（ツリーとハッシュマップ）間で一貫してミラーリングする必要があります。

要するに、トラバース/更新の容易さと、clojureのハッシュテーブルへの高速アクセスを組み合わせるための時間/スペース効率の良い方法はありますか？

Haskellの2Dグリッドに関する最近の質問に触発されて、リストのリスト内の位置を追跡するために2次元ジッパーを作成できるかどうか疑問に思っています。リスト上の1次元のジッパーを使用すると、大きなリスト内でローカルに非常に効率的に移動できます（一般的な例はテキストエディターです）。しかし、次のような2番目の次元があるとしましょう。

ここでグリッド内を左右だけでなく上下に効率的に移動するために、ある種のジッパーデータ構造を作成できますか？もしそうなら、リストのリストを無限のリストの無限のリストに置き換えても、効率的な移動を得ることができますか？

木 T を定義しましょう:

新しいノードが E に追加され、T' が生成されたとします。

変更可能な言語では、これは簡単な作業です。E の子を更新するだけで完了です。ただし、不変の世界では、まず E へのパスを知り、次に E + 新しい子から E' を導出し、次に B' を導出し、最後に A' ( = T') を導出する必要があります。

これは面倒です。理想的には、E と G (および場合によっては T) の値を取り、E へのパスを提供せずに T' を生成する関数が存在します。

この問題に対処するには、次の 2 つの方法が考えられます。

• 親参照 - このようにして、すべてのノードはルートへのパスを導出できます。2 つの問題: 相互に参照する 2 つのノード (つまり、親 <-> 子) を作成することは、純粋関数型言語の問題です (簡単な解決策はありますか?)。E -> E' が導出されるときはいつでも、E' の代わりに E の古い値を保存するため、E' のすべての子も新しく導出する必要があります。
• ジッパー - すべてのノードは、親ジッパーから派生した作成時にジッパーを格納します。相互参照の問題は解消されますが、E -> E' が導出されると、E' の子のジッパーもすべて導出する必要があります。これは、古いツリー E を指しているためです。

合理的なパフォーマンスを念頭に置いて、私が望むことは可能ですか? ご意見をお寄せいただきありがとうございます。

担当者にジッパーを印刷すると、このデータが表示されます。これが、ジッパーをシリアル化するために必要なすべてのデータである可能性があると思いますか？提供されたデータからジッパーを逆シリアル化することは可能ですか？

以下に想像するzip/serializeおよびzip/deserialize関数のようなものを探しています。

誰かがこれを行う方法を知っていますか？

単純なプロジェクトで(初めて) clojure を試しています。csv ファイルを指定して xml ツリーを更新する必要があります。私はcsvファイルを1行ずつ読んで、いくつかの値を抽出し、いくつかの値を指定してノードをループし、別の値を持つ子ノードを挿入しています。

これは、アイテムを初めて挿入するときにうまく機能します。2 回目に NullPointerException を取得します (トレースなし)。insert-child から取得した戻り値からルートを検索し、そのルート ノードを次のループに渡します。どういうわけか、そのルート要素で 2 番目の挿入が失敗します。ここで何がうまくいかないのか誰にもわかりますか？または、Clojure を作成するのはこれが初めての試みであるため、このコードに関する全般的なフィードバックをお願いします。

リアルタイム信号を収集し、派生信号を計算し、生データと派生データの両方を循環バッファーに保存するため、最後の 100 万個のサンプルのみを保持します。

すべてのシグナルの現在の値をシリアル化する必要がある場合があります。だから私は次のようなものが必要です：

SignalBufferのシーケンスですSignalValue。ボックス化されていない浮動小数点数の配列にすることができます。Haskell はFunctorインスタンスを派生させることができるので、すべてからfmap最後にフェッチし、構造体を渡してシリアライズすることができます。SignalValueSignalBufferAeson

SignalBuffer新しいティックが到着したときにすべてのバッファに新しい値をプッシュできるように、循環バッファ API を実装するにはどうすればよいですか? メモリを節約したいので、ボックス化されていない配列を使用する必要があると思います。STUArray変更可能なボックス化されていない配列 ( ?) を使用して、配列の更新がメモリに蓄積されないようにすることは有利ですか? この設定で可変配列を使用することはまったく可能ですか? 私は変化する準備ができてMyDataおりCurrentSignals、仕事をするものは何でもします。

循環バッファを実装する方法を知っています。問題は、更新を にエレガントに適用する方法MyDataです。

みたいなことを考えている

一部の信号は、他の信号の「畳み込み」です (実際の畳み込みではなく、同様の種類の処理です)。シグナルのバッファーを更新するには、他のシグナルのバッファーにアクセスする必要があります。そのため、UpdateFunc はバッファー変更関数を受け入れて返しますMyData。SignalValue

updateAllBuffers次に「zip」D0 UpdateFuncしMyDataて new を取得しますMyData。

もちろんModifier、自分のタスクに合ったものを使用する準備ができています-それは関数、モナド値などです.

この質問では、質問者は次のようにドキュメントを変換したいと考えています。

これに：

そこでの回答で指摘したように、Anti-XMLのジッパーはこの問題に対する明確な解決策を提供します。たとえば、空白要素の名前を変更するには、次のようにします。

残念ながら、以下は機能しません。

もちろん、いったんzipWithIndexジッパーを -ed すると、もはやジッパーはありません。定義が でIndexedSeqあるため、 - を持つことはできません。Zipper[(Node, Int)]trait Zipper[+A <: Node] ...

アンチ XML ジッパーを使用するクリーンな方法はありますzipか?zipWithIndexmap

Haskellの単純なジオメトリツリーを表すADTがいくつかあります。私の操作タイプをツリー構造から分離することについての何かが私を悩ませています。Tree型に演算子のコンストラクターを含めることを考えていますが、よりクリーンなようです。これに関して私が目にする問題の1つは、これらの新しい可能なコンストラクターをすべて反映するために、Zipperの実装を変更する必要があることです。これを回避する方法はありますか？それとも私はいくつかの重要な概念を見逃していますか？一般的に、Haskellでプログラムを一般的に構成する方法を理解するのに苦労しているように感じます。私はほとんどの概念、ADT、型クラス、モナドを理解していますが、全体像はまだ理解していません。ありがとう。

Huet Zipperを読んでいますが、go_upメソッドを理解できません。

他のタイプの定義の完全なソースはリンクされたペーパーで見つけることができます、あなたがジッパーを理解しているなら、それは私の質問に答えることは問題ではないと思います。

私がZipperについて知っていることから、aLocationには現在のノードとそのPathまたはいわゆる 。が含まれていContextます。Pathには、現在のノードとそのサブノード、または一部の人々がそれを呼んだ以外のすべてがありますa one-hole-context。

フォーカスを上に移動すると、現在のノードの親ノードが新しい現在のノードになります。ただし、ここでは、作成者は現在のノードとその兄弟を連結します。ただし、これは親ノードではなく、親ノードの子だけです。Scalaで独自のmoveUpメソッドを実装するときにここで立ち往生し、現在のノードの親ノードを正しく表すことができませんでした。