dllと市場。 - ページ 6

新しいコメント
 
TheXpert:

あなたの論理には欠陥があります。そんなソリューションを使っていたら、思考停止してしまいますよ。

あなたは非常に残酷に間違っている）共鳴ユーザーは、例えばhrenfx、およびこれです...はただの世界の恨み節オタク。

まあ...そこで3つの単語を言ったところ、子音と反対意見の書き込みのページができました。そして、私はどこにもない私のコンテンツ+指標+ EAsと英語圏のいくつかのスレッドでそこにいる、など...私は、何度も言いたくはないのですが．

才能があるのに、その才能を生かしきれていないのです。私はそういう人を「共鳴者」と呼んでいます。

 
sergeev:

何のことかよくわからないという方のために、少し説明させてください。

dllの話ではなく、現在のパイプの実装ではサーバーになるための機能がない、という話です。
サーバーパイプがないと、ファイルで情報をやり取りしなければなりません。
しかもMemoryMapping経由ではなく、サンドボックス経由で。
というのは、まさに私が言ったとおりです。「MQL（情報交換）内では、ディスクに穴を開けて拭くことで解決する。 この解決策は、まともな考えでは使えない」。

だから、繰り返しになりますが、DLができないのではなく、ハードディスクに穴をあけないことができない、という話です。そのような解決策を使うことはできますが、それは悪いことです。

まとめるとこの質問について議論しましょう。
 
sergeev:

:)

タスクは、ローカルマシンのエージェント間で情報を交換することです。

MQLの枠組みでは、ハードディスクに穴を開けて拭くことで解決しています。

このソリューションは、正気では使えません。

いや、課題ではなく、シンプルで多くのユーザーに理解しやすいソリューションを書くことが課題なのです。6ページ目の議論ですが、いまだにこの製品のポイントがわかりません。情報交換のための自分との情報交換なのか。engineer2engineerなどは、商業的な可能性がゼロの製品です。ファイルマッピングやデータ交換の細かい作業に没頭するためにお金を払うのではなく、トレーニングや準備、作業なしに、今ここで、あなたの期待やタスクを実現するためにお金を払うのです。したがって、もしあなたが作ろうとしている製品が複雑で、マッチを焚く時間では説明できないものであれば、商業利用するために実装しようともしないほうがよいでしょう。
 
C-4:
6ページ目の考察ですが、まだ製品自体の意味がわかりません。
私が理解する限りでは、ある種の遺伝的な自動最適化 だと思います。
 
TheXpert:
私の理解では、遺伝子の自動最適化のようなものです。

C-4はスレッドを読みたくないだけで、筆者の回答はスレッドの3ページ目にあります。

 
Urain:

C-4はスレッドを読む勇気がないだけで、筆者の答えはスレッドの3ページ目に書いてありますよ。

O.C.は、コンピューティングリソースへの アクセスという点では良いアイデアだと思いますが、フクロウそのものは採算が合わないといけません。つまり、計算性能で買うのではなく、結果で買うということであり、これらはやや異なるものである。
 
C-4:
O.C.は、コンピューティングリソースへのアクセスという点では良いアイデアだと思いますが、フクロウ自体に採算が合うことが必要なのです。つまり、演算性能で買うのではなく、結果で買うということであり、これらはやや異なるものである。

この場合の性能は二の次の要素です。本質は、最適化のプロセスを管理する能力です。

そして、マーケットにはフクロウだけがいるわけではありません。

 
joo:

この場合、性能は二の次です。ポイントは、最適化のプロセスを管理できることです。

そして、市場はフクロウだけではありません。

これは、オプティマイザーをリアルタイムに利用できる、最適化マネージャーか何かの製品へのヒントなのでしょうね。
 
C-4:
これは、リアルタイムでオプティマイザーを使える最適化マネージャーとか、そういう製品のヒントなんでしょうね。
フクロウからオプティマイザを実行するオプションが与えられている場合は、オンデマンドでリアルタイムでも。
 
レナート このテーマについて、あなたの意見を聞くのはとても興味深いです。
1234567
新しいコメント