プロフェッショナルの胎児とディリータの胎児をプログラム的にどのように区別しているのですか？ - ページ 8

新しいコメント
 
TheXpert:
Shitheads ))

そう、最適化する必要がないほどシンプルなコードもある。それは、単に最適化するものがないからだ。この場合、最適化を探ろうという試みは、デタラメ以外の何物でもないことに同意します。:)

まあ、最適化の結果が あるかどうかだけが、プロのコードと初心者のコードを見分ける基準ではないことは認めますが。もっと何かあるはずだ。例えば、コードの書き方や、コードができるだけ読みやすくなるような変数名の付け方などです。

困ったことに、ある問題に対するすべての解答のうち、最も簡単なものは、それにたどり着くまで多くのゴミに目を通し、ふるい分けなければならないものなのです。

 
tara:
感動は売り物ではありません。でも、原稿は売れるんですよ。

今どき原稿が売れない！？原稿を出版するためには、権威あるコンペティションでの受賞、スポンサー、出版社への支払いなどが前提条件となる場合があります。大切な人たちや自分自身の体験からわかることです。そして、強制的な月並みな表現も必至!

そして、当局の粉飾決算に加担したり、大衆の嗜好に乗ったりする者だけが、より早く認められるのです。 そして、すべての版、公演、制作から著作権が発生しますが、残念ながら、プログラマーにはその輝きはないのです。

感動は売るものではない、生きるものだ!

 
PapaYozh:

いいから


原則的にステートチェックは必要なのか、という疑問もある
if( !IsOptimization() ) {
}
ObjectCreate()、Alert()、Print()、Comment()などの関数の前に？
つまり、このチェックはすでに書かれていて、最適化の際に自動的に
から除外され、重複したチェックを省くことができるのではないでしょうか？
 
F(プログラムコード)=プログラマーレベルという式が成り立つなら、プログラマー自身にプログラムコードを書かせることができる--例えば遺伝的アルゴリズムを使って。
 
chief2000:

ステータスチェックは原則的に必要なのか、という疑問もある
ObjectCreate(), Alert(), Print(), Comment() などの関数の前に？
もしかしたら、このチェックはすでに書き込まれており、自動的に行われているのかもしれないということです。
最適化の際に自動的に除外され、重複したチェックのコストを削減することができます。
また、2つのバリアントでExpert Advisorをテスト し、チェックの妥当性について結論を出すことを妨げるものは何ですか？
 
borilunad:

私が思うに、プロのプログラマーは、作家や作曲家として自分のために書き、またプロとして注文し、必ずしも本当に良い結果を出さなければならないのです。もう一つは、プログラマーにとってそのアイデアは結論が出ないにもかかわらず、顧客のアイデア（TOR）で書いてくれと言われた場合、その場合、プログラマーはそのチップでは仕事はできそうにないと警告するが、顧客がどうしてもというので、プログラマーはその注文を実行するのである。ここでは仕様が異なり、時の試練に耐える名作がないことは理解していますが、MT5のMarketで全歴史の中で長寿の例（テスターで検証）があることには同意しています。これは、トレーダーが知っているから、方法を知っているからではなく、結果によって、プログラムとプログラマーのプロ意識を判断する出発点になると思います。もちろん、このプロの仕事にはそれ相応のコストがかかるはずです。

また、作家や作曲家がよくやるように、「ズボンを支えるために」必要なアルバイトと見下して、叩き出すことを禁じている人もいない。率直な意見で申し訳ないのですが、それがなければ、なぜ発言しないのですか？


作詞家なんですか？:-)

プログラマー・作曲家とはどんなものか、"そして、注文にも、プロフェッショナルに、必ずしも本当の肯定的な結果を出すために "である。:-)誰の命令？自分のですか？

"私が思うに、プロのプログラマーは、作家や作曲家のように、自分のために書くべきであり、依頼された場合も、プロとして、必ずしも本当に良い結果をもたらすものでなければならない。"- 間違っている。その結果、作曲家のためにPAMMを組織し、運営することができました。イワン・ペトロフを 見よ！なんという作曲家なのだろう。私は彼の出資者です。そして、私もハイリスクで非公開の ものです。

"プログラマーにとって納得のいかないアイデアであるにもかかわらず、顧客のアイデア（ToR）に従って書くように言われるのは別問題" - 誰も納得する必要はないのだ!TORがあれば、与えられたアルゴリズムに従ってコードを取得する必要があります。以上です。

これらの質問に対して、あなたは漠然とした考えを抱いています。フォーラム5を読むと、今話題の顧客と請負業者が、厳格に定義されたアルゴリズムのコードテストなど、一連のタスクをパスすることで協力していることがわかります。

ハックワークはだめだ。 最初から最後まですべて規制されなければならない！（これは今、ファイブの人々がやっていることだ）。

すべて - IMHO!

 
Roman.:

作詞家なんですか？:-)

プログラマー・作曲家とはどんなものか、"そして、注文にも、プロフェッショナルに、必ずしも本当の肯定的な結果を出すために "である。:-)誰の命令？自分のですか？

"私が思うに、プロのプログラマーは、作家や作曲家のように、自分のために書くべきであり、また、プロとして、必ずしも本当に良い結果をもたらすように注文することである。"- 間違っている。その結果、作曲家のためにPAMMを組織し、運営することができました。イワン・ペトロフを 見よ！なんという作曲家なのだろう。私は彼の出資者です。そしてまた、リスクの高い、非公開の ものにドル箱。

"プログラマーとしては結論の出ないアイデアであるにもかかわらず、顧客のアイデア（ToR）に従って書くように言われるのは別問題" - 誰も説得する必要はない!TORがあれば、与えられたアルゴリズムに則ってコードを取得する。以上です。

漠然とした問題意識を持っているのですね。フォーラム5を読む - そこにちょうど今、厳格に定義されたアルゴリズムのコードテストなどを含むタスクのシリーズを渡すことによって、顧客と請負業者の間でPROUD相互作用の実際のトピック、。

ハックワークはだめだ。 すべてAからZまで規制されなければならない！（これは今ファイブの人々がやっていることだ）。

すべて - IMHO!

規制されることで、プロと顧客が利益を得ることができるのは評価できる。我々とDCの 関係が、お互いの利益のために規制されればいいのだが......。
 
borilunad:
...我々とDCの 間に互恵的な関係があればいいのだが!
それはもうCFTCにありますよ。そして、自分の好みや色に合わせて、きちんとしたDCを選ぶこと。
 
Roman.:
これは、すでにCRDFRの中に入っています。そして、自分の好みや色に合わせて、きちんとしたDCを選ぶことです。
それは分かっています。利益相反を回避する方法という意味です!クライアントが勝てば自分たちに有利になり、逆はないと言うのだ。
 
バランスシートの引用によると...。ホームページで見ると...あとは、あなた次第
123456789101112131415...20
新しいコメント