アルゴリズム、解法、性能比較 - ページ 7 1234567891011121314...23 新しいコメント Реter Konow 2017.12.10 16:36 #61 Alexandr Andreev: まあ、一言で言えば、1文字の文字列は、0から255までの何らかのコードを持つ文字で、1バイトの重さがある...ということです。で、256個の値を格納するのに十分なメモリが割り当てられ、257個はそこに収まらないので、最初のものに切り替わります。どのページでも、すべての文字が0から255までの数字になっている...。そこで、4バイトの数字10000000を文字列 "10000000 "に変換し、各文字に0から255までのグラフのようにメモリを割り当てる...。合計8バイト。 メモリーセーブはどこにもない。なるほど、そういうことだったんですね。 このソリューションでは、メモリ消費量を正確に計算する必要があります。 Yury Kulikov 2017.12.10 16:38 #62 Реter Konow:2行目を書き始めることができます。次に3番目と...。:) コンストラクタ」の作成に時間がかかる理由がわかりました。 Реter Konow 2017.12.10 16:40 #63 Vasiliy Sokolov: p.s. そうそう、もう一つ間違いがありますね。3回目の呼び出しでMathRandが例えば1000を返し、_3_1000_と書き込んだ場合、注文番号1000のトランザクションにはどのようなメドがつくのでしょうか。要は、MathRandは メディジー数をシミュレートするためにのみ必要なのです。メジックの数値はユーザーが設定するもので、10万以下の値を迂回することができる（とする）。ただし、記載されている例には誤りがある可能性があります。おっしゃるとおりです。ご観覧ありがとうございました。完全なソリューションは、この点を考慮する必要があります。 Alexandr Andreev 2017.12.10 16:43 #64 Реter Konow:言いたいことはわかります。 このソリューションで消費されるメモリ量を正確に計算する必要があるのです。 また、各文字列へのアクセスはchar[x]配列へのアクセスと同じなので、内部参照に多くのリソースを浪費することになります。この場合のリンクとは、ある配列要素に アクセスすることです。そして、そこに大量に積まれたものを見ていくだけです。intで実装した方が何倍も簡単でわかりやすいと思うのですが...。文字列の長さの制限については、通常、char[x]配列の最大サイズの制限に依存します - それは同様に、独自の最大制限を持っています。 Sergey Dzyublik 2017.12.10 16:43 #65 この人は、本当に自分の愚かさに気づいていないのだ。ダニング・クルーガー 効果の発動。 Alexandr Andreev 2017.12.10 16:45 #66 大丈夫です、人は型付けされない言語があれば問題ありません)) それでも速度に差はありますが Yury Kulikov 2017.12.10 16:47 #67 Vasiliy Sokolov: p.s. そうそう、もう一つ間違いがありますね。MathRandの3回目の呼び出しで、例えば1000を返して、_3_1000_と書くと、序数1000を扱うためにどんなマジックがあるのでしょうか？ ディールの前にアンダースコアを、マジシャンの前に別のシンボルを置くと、もう少し「考えて」この問題を解決してくれるでしょう :) Реter Konow 2017.12.10 16:49 #68 Alexandr Andreev: また、文字列の各文字へのアクセスは配列のchar[x]へのアクセスと同じであるため、内部参照に多くの資源を浪費することになります。この場合のリンクとは、ある配列要素に アクセスすることです。そして、そこに大量に積まれたものを見ていくだけです。intで実装した方が何倍も簡単でわかりやすいと思うのですが...。文字列の長さの制限については、通常、char[x]配列の最大サイズの制限に依存します。将来のトランザクション数が事前に分からないので、intで実装することはできない。取引ごとに配列のサイズを推測するか、データを書き換えて往復する必要があるのです。他にどうすればいいのか？私のソリューションのスピードは異常です。 メモリは消費されるが、どの程度非効率なのかは不明である。確かめなければならない。 Alexandr Andreev 2017.12.10 16:49 #69 Yury Kulikov: 彼はもう少し「考えて」この問題を解決するでしょう：取引の前にアンダースコアを置き、マジシャンの前に別のシンボルを置くのです :)ここで指摘しておきたいのは、他のみんなと違って、ピーターはおそらく最大の忍耐力を持っていて、単調なコードを書くことを厭わないということです。そうでなければ、なぜ彼がこれほど多くのことを書けたのか、説明できない。 Alexandr Andreev 2017.12.10 16:52 #70 Реter Konow:将来の取引数が事前に分からないため、int型で実装することはできません。推測するか、取引のたびに配列のサイズを変えてデータを上書きして往復するしかないのです。他にどうすればいいのか？私のソリューションのスピードは異常です。 メモリは消費されるが、どの程度非効率なのかは不明である。確かめなければならない。文字列には、最大サイズ（予備）があるか、メモリが割り当てられ、あなたの場合、追加処理中に毎回割り当てられるかの2つのバリエーションしかありません。つまり、int型配列のサイズを変更 するのと同じです。1in1 まあ、1文字分のメモリを確保するのに、文字列よりintの方が10％くらい時間がかかるかもしれません。 1234567891011121314...23 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
まあ、一言で言えば、1文字の文字列は、0から255までの何らかのコードを持つ文字で、1バイトの重さがある...ということです。で、256個の値を格納するのに十分なメモリが割り当てられ、257個はそこに収まらないので、最初のものに切り替わります。
どのページでも、すべての文字が0から255までの数字になっている...。そこで、4バイトの数字10000000を文字列 "10000000 "に変換し、各文字に0から255までのグラフのようにメモリを割り当てる...。合計8バイト。 メモリーセーブはどこにもない。
なるほど、そういうことだったんですね。
このソリューションでは、メモリ消費量を正確に計算する必要があります。
2行目を書き始めることができます。次に3番目と...。:)
p.s. そうそう、もう一つ間違いがありますね。3回目の呼び出しでMathRandが例えば1000を返し、_3_1000_と書き込んだ場合、注文番号1000のトランザクションにはどのようなメドがつくのでしょうか。要は、MathRandは メディジー数をシミュレートするためにのみ必要なのです。
メジックの数値はユーザーが設定するもので、10万以下の値を迂回することができる（とする）。
ただし、記載されている例には誤りがある可能性があります。おっしゃるとおりです。
ご観覧ありがとうございました。完全なソリューションは、この点を考慮する必要があります。
言いたいことはわかります。
このソリューションで消費されるメモリ量を正確に計算する必要があるのです。
また、各文字列へのアクセスはchar[x]配列へのアクセスと同じなので、内部参照に多くのリソースを浪費することになります。この場合のリンクとは、ある配列要素に アクセスすることです。そして、そこに大量に積まれたものを見ていくだけです。intで実装した方が何倍も簡単でわかりやすいと思うのですが...。
文字列の長さの制限については、通常、char[x]配列の最大サイズの制限に依存します - それは同様に、独自の最大制限を持っています。
この人は、本当に自分の愚かさに気づいていないのだ。
ダニング・クルーガー 効果の発動。
大丈夫です、人は型付けされない言語があれば問題ありません))
それでも速度に差はありますがp.s. そうそう、もう一つ間違いがありますね。MathRandの3回目の呼び出しで、例えば1000を返して、_3_1000_と書くと、序数1000を扱うためにどんなマジックがあるのでしょうか？
また、文字列の各文字へのアクセスは配列のchar[x]へのアクセスと同じであるため、内部参照に多くの資源を浪費することになります。この場合のリンクとは、ある配列要素に アクセスすることです。そして、そこに大量に積まれたものを見ていくだけです。intで実装した方が何倍も簡単でわかりやすいと思うのですが...。
文字列の長さの制限については、通常、char[x]配列の最大サイズの制限に依存します。
将来のトランザクション数が事前に分からないので、intで実装することはできない。取引ごとに配列のサイズを推測するか、データを書き換えて往復する必要があるのです。
他にどうすればいいのか？
私のソリューションのスピードは異常です。
メモリは消費されるが、どの程度非効率なのかは不明である。確かめなければならない。
彼はもう少し「考えて」この問題を解決するでしょう：取引の前にアンダースコアを置き、マジシャンの前に別のシンボルを置くのです :)
ここで指摘しておきたいのは、他のみんなと違って、ピーターはおそらく最大の忍耐力を持っていて、単調なコードを書くことを厭わないということです。そうでなければ、なぜ彼がこれほど多くのことを書けたのか、説明できない。
将来の取引数が事前に分からないため、int型で実装することはできません。推測するか、取引のたびに配列のサイズを変えてデータを上書きして往復するしかないのです。
他にどうすればいいのか？
私のソリューションのスピードは異常です。
メモリは消費されるが、どの程度非効率なのかは不明である。確かめなければならない。
文字列には、最大サイズ（予備）があるか、メモリが割り当てられ、あなたの場合、追加処理中に毎回割り当てられるかの2つのバリエーションしかありません。つまり、int型配列のサイズを変更 するのと同じです。1in1 まあ、1文字分のメモリを確保するのに、文字列よりintの方が10％くらい時間がかかるかもしれません。