オートマチックマジックナンバー - ページ 3

 
BarrowBoy:

部分的に注文を閉じていない のであれば、コメントを使用して、元のペア/時間枠の情報を保存することができます...?

同じシンボルと時間枠に2つのEAがある場合、履歴のある注文の中からそれぞれのIDをピックアップすることをどのように知ることができるでしょうか?


これらはすべて、再起動の際に利用可能であることが保証されていると仮定する情報に依存する部分です。例えば、このフォーラムでは、このようなデータをチャートウィンドウの隠し オブジェクトに保存している人がいます。それはそれで悪くないのですが、個人的には、ユーザがその方法や理由を知らずに壊してしまうような仕組みは怖いです。

 
jjc wrote>>

同じシンボルと時間枠に2つのEAがある場合、それぞれのIDをピックアップする注文をどうやって知るのでしょうか?

くそー、それはプロジェクトの範囲内だったのか :D

私は、EA(異なるタイプやバージョンの場合)が同様にコメントで識別子を持つことを想定していたと思います :)

-BB-

 
jjc wrote>>

MT4またはユーザーが各EAにIDを割り当てない限り、これが可能だとは思えません。もっと正確に言うと、ユニークなIDを生成して、EAの.chrファイルを修正してEAのexternパラメータの一部としてIDを保存するような、非常に厄介なことを伴わないものが見当たりません。

そして、一般的な娯楽として、以下は本当に何の議論も進展させませんが、djb2ハッシュへの入力をユニークであることが保証された値で置き換えます(DLLコールを必要とする代償として)。GUIDのようなものに対してdjb2がどの程度優れているかは知らないが、1,000,000個のIDを生成してみたところ、衝突は起きなかった。しかし、それでも再起動の問題は解決しません。

MT4かユーザーが各EAにIDを割り当てないと、こんなことはありえない。もっと正確に言うと、ユニークなIDを生成して、EAの.chrファイルを修正してEAのexternパラメータの一部としてIDを保存するような、非常に厄介なことを伴わないものが見当たりません。

>>EAのn番目のインスタンスは、どのようにchartyy.chr ファイルをp/uするのでしょうか?

.

インスタンスが実際にそれ自身の.chrファイルをマップすることができると仮定して。

もし、EAのソースに extern int myID = <someCompileTimeVal> があれば、 <someCompileTimeVal> を見たインスタンスは、次のようになります。

とすると、<someCompileTimeVal>を見たインスタンスは、「初めて」であると仮定できます -> idを生成 ->myID 行を修正 ->myIDの 一意性を使って回復ファイルを作成、...となります。

そして、再起動時に検出され、.chr ファイルにアクセスし、マスターキーとなるmyID を p/u して、ファイルの再マップを可能にする....

.

例えば

チャート02.chr

<チャート>
シンボル=EURUSD
期間=15
..

..

<専門家
name=LMT 1.8
フラグ=343
window_num=0
<入力
myID=<someCompileTimeVal>とする。

...

</inputs>
</expert>
EOF


ヘルプ

.

そして、一般的な娯楽として、以下は議論を何ら進展させるものではありませんが、djb2ハッシュへの入力をユニークであることが保証された値に置き換えます(その代償としてDLL呼び出しが必要です)。djb2がGUIDのようなものに対してどの程度の性能を持つのか知らないが、1,000,000個のIDを生成してみたところ、衝突は起きなかった。

PsPadのedで1milを吸い込み、remove dupsに チェックを入れてsortを行いました。

>>しかし...この「...衝突のない」 検出はどうやってやったんですか?

 

"そして、一般的な娯楽として、以下は議論を何ら進展させるものではありませんが、 djb2ハッシュへの入力を一意性が保証される値に置き換えます (その代償としてDLL呼び出しが必要です).GUIDのようなものに対してdjb2がどの程度良い意味を持っているかは知りませんが、1,000,000個のIDを生成してみたところ、衝突はありませんでした。"

.

参考までに、私は1milのコード呼び出しで衝突を発見しました。

ソート済みEOF

.

ソート済み+重複削除 済みEOF

 
fbj:

>>EA の n 番目のインスタンスは、どのようにchartyy.chr ファイルを p/u するのでしょうか?

.

インスタンスが実際にそれ自身の.chrファイルをマップすることができると仮定して。

もし、EA のソースに extern int myID = <someCompileTimeVal> があれば、 <someCompileTimeVal> を見ているインスタンスは、どのようにマッピングすればよいのでしょうか?

とすると、<someCompileTimeVal>を見たインスタンスは、「初めて」であると仮定できます -> idを生成 ->myID 行を修正 ->myIDの 一意性を使って回復ファイルを作成、...となります。

そして、再起動の検出時に.chrファイルにアクセスし、マスターキーとなるmyIDを p/uして、ファイルの再マップを可能にする...

あなたの言うとおりです。同じシンボルと時間枠のEAが複数ある場合、EAがその.chrファイルを識別する明白な方法がないことを忘れていました。GUIDのようなものを含む隠しラベルオブジェクトを 作成し、正しい値を含む.chrファイルを探すことができるのではないかと考えていました。しかし、新しいオブジェクトがチャートに追加されたときに、.chrファイルが更新されないことは確かです。


そして、もう一つの問題があります。MT4はチャートの情報をメモリ上に保持し、MT4が終了したとき(またはEAのプロパティに変更が加えられたとき)に.chrファイルに書き込むので、EA自身が実行中に.chrファイルに加えた変更は上書きされてしまうのではと思います。もし、あなたが非常に勇敢であれば、代わりに、プロパティウィンドウを呼び出し、必要な設定に移動し、それを変更し、Enterを押すなど、キー押下をシミュレートすることによってexternプロパティを設定してみることもできます。

 
fbj:

参考までに、私は100万回のコード呼び出しで衝突を発見しました。

ソート済みEOF

再実行したところ、私もそうでした。1,000,000回の試行で172回の衝突がありました。

 
jjc wrote>>

おっしゃるとおりです。同じシンボルとタイムフレームに複数のEAがある場合、EAがその.chrファイルを識別する明白な方法がないことを忘れていました。GUIDのようなものを含む隠しラベルオブジェクトを作成し、正しい値を含む.chrファイルを探すことができるのではないかと考えていました。しかし、新しいオブジェクトがチャートに追加されたときに、.chrファイルが更新されないことは確かです。

そして、もう一つの問題があります。MT4はチャートの情報をメモリ上に保持し、MT4が終了したとき(またはEAのプロパティに変更が加えられたとき)に.chrファイルに書き込むので、EAが実行中に.chrファイルに加えた変更は上書きされてしまうのではと思います。もしあなたがとても勇敢なら、代わりにキー入力をシミュレートすることによってexternプロパティを設定してみることができます - プロパティウィンドウを呼び出し、必要な設定に移動し、それを変更し、Enterを押すなど。

私は上記を読み、エクササイズをしに行き、シャワーを浴びている間に灰色の細胞がOBJECTと叫びました。あなたは.chrルートを消したが、"label object "という2つの単語が、その脳の爆発を促したのだ :)

というわけで、100%保証されたIDを取得することはひとまず忘れて、どうでしょう?もう一つは、EAsのIDを含むこの回復可能な状態メモリ です。

さてと...

1. void vArchiveID (int iID), int iRestoreID () [and int iGetNewID () get to another post if this one is ok :].

2. vArchiveID()は、EAの ステート・メモリ・チャートに[hidden?]

オブジェクト名はどのEAを呼び出しても同じでなければなりません。つまり、(1)では.ex4 libまたは.mqh libです。

3.CTが破綻、またはEAが破綻した場合など。

4. EAを再起動すると、まずiRestoreID()を呼び出し、チャートにオブジェクトがない場合は-1、前回起動時のアーカイブIDを返します。

5. IDがない場合、iGetNewID()、vArchiveID()を呼び、おそらく[初めて]ダンプファイルのものをセットアップする。

6. IDが'restored'であれば、ダンプファイルを介して最後の状態を回復するために愉快に行く....

..

どうでしょう?

 
fbj:

[...]

どう思う?

あなたが提案していることは、私がタイムスタンプ14:43の投稿で言及したこととまったく同じだと思います。このルートで唯一危険なのは - そして、外部プロパティを 設定するために .chr ファイルを直接操作する唯一の理由は - ユーザーが誤ってチャートからオブジェクトを削除してしまう可能性を排除することです。しかし、それさえも、deinit()において、必要であれば、obejctが再作成されることを保証することによって、大部分を克服することができます。


しかし、BB/CBは.chrファイルへの依存を容認できないと考えているかもしれません。彼らは、オフサイトにあるデータ(ブローカーが保有する取引リストなど)から純粋に復元できるものを望んでいるかもしれない。

 

しばらくこのスレッドから遠ざかっていました。


自動化されたマジックナンバーで復元できるようにするために、ある程度の複雑さを加えているように思えますが?転生したコードが前世で誰だったかを知ることができるようにね。必ずしも悪いことではないでも...


文書化(非常に簡潔)しておくと便利だと思ったんだ。

- マジックナンバーを導入するかどうかの判断基準

- マジックナンバーを自動生成することを決定する基準

- 永続化レイヤーを実装するかどうかの判断基準

- 永続化のためにグローバルとファイル・アクセスのどちらを使用するかを決定する基準


これを提案する理由は、誰もが EA にキッチンシンクを実装しなければならないと考えるのを避けるためです。


ビュー?


CB


- しばらくお休みする前に、8つの投稿を残すのみとなりました。

 

はい、まあ結局のところ、キッチンシンクは、このサイトでは すべての学問の可能性が高いです。私の場合、まず第一の関心事は、保証された自動[make|acquire]エキスパートIDを持つことです。この値は、多くの目的に使用することができます。

再起動時にダンプファイルにアクセスするユニークな方法を持つことは、せいぜい行き当たりばったりで、いずれにせよ、ユーザーはEA使用のルールセットを遵守することを要求されます。多くのccy+period+EAインスタンスというのは選択肢にありません。

私は、どのインスタンスでも、再起動前に誰が私で あるかを決定できることを意図していましたが、それは実行不可能であることが示されています。私としては、最も基本的なルールセットに従うユーザーを信用しないことにしています。もし私が自動的な方法を完全に確信できないのであれば、ユーザーの介入が必要な中途半端な方法は採用しないでしょう。

.

jjcのCoCreateGuid() i/fを使って、私は十分な数の非反復数を生成するつもりだ。十分というのは主観的なものですが、私は多くのものを目指しています...。番号を保持するファイルへのリソースアクセスサーバー関数として、1つのライブラリコードチャンクと結合されます。少なくとも2年間は再利用されないような数の量にする。EOFに達すると、BOFにラップアラウンドして、番号を提供し続ける。私の空の指の計算では、10人のリクエスト者が週5日、年間50週間稼働し、1人のリクエスト者が1日に20の新しいIDを必要とする場合を想定しています。この結果は2倍になります。基本的に200,000という膨大な数です。そう、石器時代の機能ですが、私のコードを実行する能力以上に端末に依存する必要がなく、水密性が高いのです。もちろん、1つ、10個、100個のファイルやその物理的な位置、アクセスの仕組みの影響について、何年も続けることができます。最終的には、私の哀れなmake expert id関数よりもはるかに優れており、[現実には]2年以上にわたって番号の一意性に関して完璧です。

.

CB、666はチョッパーのパイロットのラッキーナンバーなんだろうな?