ALGLIBで試したところ、オブジェクトからの印刷に問題があり、ArrayPrint関数はオブジェクトを印刷しません。 しかし、[][]からは、ヘッダーがあってもきれいな行列が印刷されるので、やはり、計算結果を視覚的に追う必要があるときに見やすいですね。 はい、フォーラムのいくつかのトピックを見ましたが、印象に残っていません。だから、すべてが面倒で非効率的に見えるのです。C言語は非常にエレガントな言語なので、mqlはそれを壊してしまう傾向があります。 確かにC言語ではポインタによって動的行列のメモリを確保できますが、mqlでは変数へのポインタがないため、やはりオブジェクトに渡すしかありません。 ArrayResizeMx(A, n, m, k)という関数が1つだけ必要で、それがネイティブの実装になる場合、その違いを理解することができます。 まあ、続ける意味もないし、聞いた上でやってくれるのなら、ありがたいことです。でも、この機能は本当に便利で必要なものなんです。
そのため、ArrayResize と同様の機能を、行列 ArrayResizeMx(A, n, m) に対して作成することをお願いしたいです。 そして、おそらく多次元的なものに対しても。つまり，行列をオブジェクトとして扱うのではなく，C言語流に言えば通常の配列として扱えるようにするのです． 特に行列を視覚的に表現するために、ArrayPrint(A, 0) 関数は、オブジェクトからではなく、配列から行列を表示します。
関数型プログラミングに比べたら？
wikipediaで確認する。
そして、同じものではないことがわかるのです。
つまり、手続き的なものばかり...。
意外かもしれませんが、今の若いプログラマーは、手続き型プログラミングよりOOPの方が簡単なプログラミングだと考えているんです。
25年前を基準に考えているのでしょう。今の若者は、母乳でOOPを吸収しています。流行に乗りたければOOPを学べ、そうでなければ不平不満ばかりを言うことになる。
でも、本当にそうなんです。老練なプログラマーに、小学生 向けのオリンピックの課題を解かせてみてはいかがでしょうか。
大学では、動的計画法、グラフ理論、OOP、クラスなどの科目を勉強してきた。
そして、それは自然なことです。自然界の法則 :)
はい、私はOOPを理解しています。もちろん、私が望む程度ではありません。
これは不平不満ではなく、建設的な提案です。
開発者が2つのmallocを確保するために1つの関数を書かなくて済むように、ユーザーにOOPを学ばせるのです。
もちろん、その進歩や大衆化である。さて、ここでは、彼らがいかにOOPを愛し、理解しているかがわかります。
ほら、ニコライさん、ラッパーの中身はすべて実行される必要のないコードなんですよ、説明するまでもないでしょう。
最近の最適化コンパイラについては言わずもがな、どのような命令が適用されるかはわからない。
また、アメリカのプログラマーでさえ、手続き型で書くことを好むのは、OOPが悪いからではなく、コードがよりシンプルで速いからだということも、驚かれるかもしれません。
また、プロジェクトにオブジェクトタスクがない場合、なぜラッパーを使うのか、なんとか理解しなければならない、若い人向けです))
だから、若い人たちがOOPを熱心に吸収するというのは納得できないんです。
mql言語のロジックが構築されているC言語で考えているのです。
Cは1972年生まれなので、48年前のものです ))
しかし、とにかくC言語は最速の言語の1つです。なぜかわかりますか？クラスラッパーを持たないからです。
まあ、そんなことは全然ないんですけどね。ただ、OOPを使わないで使われている言語もまだたくさんあるんですよ。Cなどです。例えばカナダでは、ほとんどの政府機関がコボルの上に座っていて、それを捨てられないでいるのです。
https://www.tiobe.com/tiobe-index/
Romanさん、正直なところ、行列の次元を変えて大騒ぎする理由がよくわからないんです。
そのためにポインタやOOPは必要ない。
とにかく、コンピュータにとっては、どんな次元の配列も一次元の配列なのです。
そこで、1次元の動的配列で作業します。そして、マトリクスを仮想的に形成し、関数の助けを借りて自由にサイズを変更することができます。
例えば......こんな感じ。
実際には、私は1次元配列しか使わないが、1次元配列をベースに多次元配列も扱う。
だから、ArrayResizeのような関数は、行列に対してのみ作るようにお願いしたい ArrayResizeMx(A, n, m)
OOPを使った既製品はいらない（OOPを知らなくてもいい、既製品を使え！）。
ALGLIBを使用すると、行列のサイズを変更するメソッドがあります Resize()...。しかし、それでも全てはOOPで行われます ))))
SZS：フォーラムを検索すると、このトピックでは何度もあった、例があった、あなたはこれらの構造の配列で配列フィールドと構造をラップすることができます - それはOOPなしだろうが、私にはそれがすべて面倒に見える
mqlのロジックの基本であるCで考えています。
C言語が誕生したのは1972年ですから、48年前の言語であることがわかります ))
しかし、とにかくC言語は最速の言語の一つです。なぜかわかりますか？クラスラッパーを持たないからです。
私はピュアCを覚えていません、ずっと前にユニで勉強しましたが、私の記憶が間違っていなければ、Cはそのような動的配列を持っていませんでしたが、メモリへのポインタを扱うことができ、メモリ割り当てと メモリアクセス制御の作業は完全にプログラマにありました、これは本質的には同じラッパーです
よし、これはすごい議論になりそうだ、続けても意味がない。
Romanさん、正直なところ、行列の次元を変えることにどんな困難があるのか、騒ぐ理由がわかりません。
そのためにポインタやOOPは必要ない。
とにかく、コンピュータにとっては、どんな次元の配列も一次元の配列なのです。
そこで、1次元の動的配列で作業します。その間、仮想的にマトリクスを形成し、関数を使って好きなようにリサイズしてください。
コンピュータにとっては、どの次元も一次元配列であることは明らかです。
言語の使い勝手の問題で、[][]という次元があれば、1次元の配列ではなく行列であることが視覚的に理解できます。
コードの可読性は、[][]が何を含んでいるかを推測するよりもはるかに高いです。
行列のメモリ割り当てに関する関数を1つ追加してください」と言われても、これほど理解不足に出会うとは思ってもいませんでした。
皆さんは、ArrayResizeを使うと便利だから、わざわざ使わなくてもいいのでは？多次元配列の メモリ確保関数を書くことは、開発者にとってどんな問題があるのでしょうか？
その通り、何の問題も障害もなく、ユーザーにとってもコードの整理がしやすく便利です。そこで、数値計算手法の大きな優れたC言語ライブラリをmqlに移植することにしました。
が、そのための普通のmqlツールは持っていない。またもや松葉杖があり、非効率的なコードを作りたいという欲求をすべて取り除いてくれます。
もちろん、思うほどではありませんが、OOPは理解しています。
これは不平不満ではなく、建設的な提案です。
開発者が2つのmallocを確保するために1つの関数を書かなくて済むように、ユーザーにOOPの学習を強いているのです。
もちろん、その進歩や大衆化である。さて、ここでは、彼らがいかにOOPを愛し、理解しているかがわかります。
ほら、ニコライさん、ラッパーの中身はすべて実行される必要のないコードなんですよ、説明するまでもないでしょう。
最近の最適化コンパイラについては言わずもがな、どのような命令が適用されるかはわからない。
また、アメリカのプログラマーでさえ、手続き型で書くことを好むのは、OOPが悪いからではなく、コードがよりシンプルで速いからだということも、驚かれるかもしれません。
また、プロジェクトにオブジェクトタスクがない場合、なぜラッパーを使うのか、なんとか理解しなければならない、若い人向けです))
だから、若い人たちがOOPを熱心に吸収するというのは納得できないんです。
mql言語のロジックが構築されているC言語で考えているのです。
Cは1972年生まれなので、48年前のものです ))
しかし、とにかくC言語は最速の言語の1つです。なぜかわかりますか？クラスラッパーを持たないからです。
MQLはC++で作られています。
Romanさん、おっしゃるような機能を導入するためには、MQLはメモリを扱うという点で、いろいろと追加で導入しなければならないでしょう。そして、これが初心者には複雑なのです。
ご自身でも「プロでない人の方が楽だろう」とおっしゃっていましたね。
それは、「自転車のペダルを漕ぐことを覚えるのは得意だ、とても簡単でわかりやすい」というような状況です。BMWにペダルをつけよう、簡単だろう"。:)
s.e.私は一般的に、手続き型もOOP型もダサくて実用的ではないという意見を持っています))
OOPを使った既製品はいらない（OOPを知らなくてもいい、既製品を使え！）。
ALGLIBを使用すると、行列のサイズを変更するメソッドがあります Resize()...。しかし、それでも全てはOOPで行われます ))))
SZS：フォーラムを検索すると、このトピックでは何度もあった、例があった、あなたはこれらの構造の配列で配列フィールドと構造をラップすることができます - それはOOPなしだろうが、私にはそれがすべて面倒に見える
問題は、あなたが純粋なCを覚えていないことです。私はユニで勉強しましたが、私の記憶が間違っていなければ、Cにはそのような動的配列はありませんでしたが、メモリへのポインタを扱うことができ、メモリの割り当てと メモリアクセスの制御の作業は完全にプログラマに任されていて、プログラマのラッパーになるはずです
よし、これは大論争になるかもしれないし、続ける意味はない。
ALGLIBで試したところ、オブジェクトからの印刷に問題があり、ArrayPrint関数はオブジェクトを印刷しません。
しかし、[][]からは、ヘッダーがあってもきれいな行列が印刷されるので、やはり、計算結果を視覚的に追う必要があるときに見やすいですね。
はい、フォーラムのいくつかのトピックを見ましたが、印象に残っていません。だから、すべてが面倒で非効率的に見えるのです。C言語は非常にエレガントな言語なので、mqlはそれを壊してしまう傾向があります。
確かにC言語ではポインタによって動的行列のメモリを確保できますが、mqlでは変数へのポインタがないため、やはりオブジェクトに渡すしかありません。
ArrayResizeMx(A, n, m, k)という関数が1つだけ必要で、それがネイティブの実装になる場合、その違いを理解することができます。
まあ、続ける意味もないし、聞いた上でやってくれるのなら、ありがたいことです。でも、この機能は本当に便利で必要なものなんです。
憶測が独り歩きしていますが、むしろ開発者へのアピールになるのではないでしょうか。
このズロイについては、個人的な感想は禁物です。
そのため、ダイナミックマトリクスは、オブジェクトや構造体を通してしか扱うことができません。もうひとつの松葉杖は、一般に作成されているものです。
mqlには変数へのポインタがないので、ポインタが利用できるオブジェクト・アプローチを利用する必要があります。
ですから、ダイナミックマトリクスを使うためには、ユーザーはOOPとポインタの扱い、さらにはMQLの実行について知っていなければなりません。
この知識を持っている人はどれくらいいるのでしょうか？答えは自分で分かっているはずです。 オブジェクトアプローチを理解するのに苦労はしないが、OOPを知らない人には
特に動的な行列を扱うときに、この言語を使うための人工的な敷居を高くしてしまうのです。
私が思うに、開発者は逆に、言語を複雑にするのではなく、使いやすくすることに関心を持つべきでしょう。
つまり、ユーザーがその言語を快適に使うために必要な機能を開発することです。
ましてや、数値計算方法のほぼ基本である行列ではなおさらだ。
そのため、ArrayResize と同様の機能を、行列 ArrayResizeMx(A, n, m) に対して作成することをお願いしたいです。
そして、おそらく多次元的なものに対しても。つまり，行列をオブジェクトとして扱うのではなく，C言語流に言えば通常の配列として扱えるようにするのです．
特に行列を視覚的に表現するために、ArrayPrint(A, 0) 関数は、オブジェクトからではなく、配列から行列を表示します。
これについては、開発者がかなり具体的に説明してくれています。こちら
これについては、開発者がかなり具体的に説明してくれています。こちら
遠くへ行く必要はない、次の記事で、プライヴァルからの具体的な質問を紹介します。
ほぼ同時期から長い付き合いをしている、有能な軍事開発者だ。何が、なぜここを去ったのか、答えは明白だ。
10年ぶりですが、何か変わったことはありますか？
シンプルなアルゴリズムで満たされていたため、そのレベルにとどまっています。プロフェッショナルな解決策はどこにあるのか？
しかし、私たちがパイソンに書いているのは、こうした専門的なソリューションを書いたり、コドベースを開発したりするためのツールを提供することではありません。
そこがミソで、ツールがない、プログラマーのレベルが適正でない。
よし、もう寝よう、まだ寝てないんだ。みんなに幸あれ。
つまり、手続き的なものばかり...。
プロシージャルはB、そこにあるのは初歩的なものばかりで、自分の足を撃つ機会が増えるだけです。
間違って機能的という意味になってしまったようですね。そんなことはどうでもいいんですけどね。