汎用クラスライブラリ - バグ、説明、質問、使用上の特徴、提案 - ページ 9

新しいコメント
 
レジェックス・コノウ。
解答には2つの関数と1つの配列を使用したことを付け加えておきます。ポインタやコネクションはありません。

あなたの解決策はダメです。すでに100x100x255、つまり255万セルの配列が100ワード分確保されているわけですからね。また、10 000 000ワードとなると、32ビットシステムではメモリの限界に達してしまいます。また、衝突回数が100回を超えた場合はどうでしょうか？Sで始まる単語はいくつ、Pで始まる単語はいくつ？- 明らかに100個以上あるのに、なぜ保存してはいけないのか？

 
fxsaber

つまり、タスクごとに、辞書のサイズ（RAM）とハッシュ関数の計算量（CPU）の適切なバランスを見つける必要があるのです。

そうなんです。以下、ハッシュ関数の要件について書きます。
 
fxsaber

ここまで書いて、ふと思ったのですが、スレッドで議論されているような方法でティックを保存するのは現実的な作業ではありませんね。これらは時間順にソートされ、単純な配列に格納される。

History Order/Dealsの場合も同様です。そして、HistorySelectから判断して、時間ごとに配列に格納されている。また、チケットやIDでレコードを検索するようなことは（現在の実装では）できないと思うのですが。

そしてすべて、名前のある歴史の場合、このようなものを作るのは合理的でないからです。練習用にはシンプルな配列で十分です。

そうですね。
 
fxsaber

ハテナや余計な存在のネタバレを排除して、簡潔に書いてください。

これはトレーニングの例なので、失礼ですが、ダメです。しかし、戦闘編ではこのように、できるだけ簡潔に、効率よくコードを書いていることを指摘しておきます（お好きなようにどうぞ）。トレーニングの例では、コードは誰でも理解できるように、できるだけシンプルでわかりやすく書かれています。

s.w. Caps、OK、掃除しておきますね。
 
Vasiliy Sokolov：

しかし、戦闘編ではこのように、できるだけ簡潔かつ効率的にコードを記述していることを指摘したいと思います（お好きなようにどうぞ）。


現実のプロジェクトでは、「行動規範」に従って書かれている。
そして、fxsaberさんの ケースのように、そのようなバリアントは使用されていません。

bool Contains(string word)
{
   return words[word[0]-'a'] != NULL;
}

理由は平凡で、都合よくデバッグすることができないからです。

 
ワシリー・ソコロフ

あなたの解決策はダメです。すでに100x100x255、つまり255万セルの配列が100ワード分確保されているわけですからね。また、10 000 000ワードとなると、32ビットシステムではメモリの限界に達してしまいます。また、衝突回数が100回を超えた場合はどうでしょうか？Sで始まる単語はいくつ、Pで始まる単語はいくつ？- 間違いなく100個以上、だから保管しない方がいいのでは？


ReTeg Konow codeからの提案されたコードを勉強して戻ってきました。
申し訳ないが、ハッシュテーブルはもちろんのこと、ハッシュの話題全般を全く無視したゴミである。
hubrに行けば、少なくともハッシュの話題に触れることができるのに、なぜこの車輪のついた棺桶を作ったのでしょう。

そう、独自のハッシュテーブルをまともに実装することは、決して簡単なことではないのだ。
しかし、提案されたコードでは、何の理解も問えないのです。

 

友達です。スレッドが静かになったようですね。

議論の邪魔をしたくないので、自主的に辞退します。

図書館には面白いものがたくさんあるかもしれません。

お気軽にご相談ください。

(私の解は3.2倍遅いので、いずれにせよ悪いです)。

 
Vasiliy Sokolov：

あなたの解決策はダメです。すでに100x100x255、つまり255万セルの配列が100ワード分確保されているわけですからね。また、10 000 000ワードとなると、32ビットシステムではメモリの限界に達してしまいます。また、衝突回数が100回を超えた場合はどうでしょうか？Sで始まる単語はいくつ、Pで始まる単語はいくつ？- 明らかに100個以上あるのに、なぜ保存してはいけないのか？

配列の大きさは、辞書の大きさに合わせて簡単に変更することができます。

エンドレスのバリエーションは考えていません。

 
セルゲイ・デジュブリク


Retag Konow codeから提案されたコードを勉強し直した。
申し訳ないが、これは全くのたわごとで、ハッシュテーブルはもちろんのこと、ハッシュ全般の話題について完全に誤解している。
hubrに行けば、少なくともハッシュの話題に触れることができるのに、なぜこの車輪のついた棺桶を作ったのでしょう。

そう、独自のハッシュテーブルをまともに実装することは、決して簡単なことではないのだ。
しかし、提供されたコードでは、何の理解もないままです。

このコードが始まりです。誰もあなたのさらなる発展を阻むものはいない。
 
ワシリー・ソコロフ

あなたの解決策はダメです。すでに100x100x255、つまり255万セルの配列が100ワード分確保されているわけですからね。また、10 000 000ワードとなると、32ビットシステムではメモリの限界に達してしまいます。 また、衝突回数が100回を超えた場合はどうでしょうか？ Sで始まる単語はいくつ、Pで始まる単語はいくつ？- 明らかに100個以上あるのに、なぜ保存してはいけないのか？

私のバージョンでは、衝突回数が100回を超えることはまずありません。1文字から始まり、同じ文字数を持つ単語を100個以上思いつくことができますか？

(バリアント「テキスト1」、「テキスト2」、「テキスト3」、「テキスト4」、「テキスト5」...を除く)

12345678910111213141516...38
新しいコメント