投稿者
　メール
　　題名
　　内容 入力補助動画検索<OBJECT>タグが利用可能です。(詳細)
　　　　
　ＵＲＬ
[ ケータイで使う ] [ BBSティッカー ] [ 書込み通知 ] [ teacup.コミュニティ ]

投稿募集！　スレッド一覧

スレッド作成 他のスレッドを探す
[PR] 社員求人 食事券 愛媛の求人・転職 ファストフード店大阪府 GMO SEO
[ teacup. ] [ 無料掲示板 ] [ プレミアム掲示板 ] [ teacup.コミュニティ ] [ ブログ ] [ チャット ]
【From teacup.】この掲示板は投稿が一定期間無いため、各記事中に広告を表示しています。
全73件の内、新着の記事から10件ずつ表示します。 1  2  3  4  5  6  7  8  |  《前のページ |  次のページ》 

6×6オセロ

 投稿者：和  投稿日：2005年 4月 4日(月)18時00分5秒
  は1993年に2週間ぐらいかけて解いた人がいます。
今のPCなら数時間でしょうね。
最強のオセロ「ロジステロ」は自分自身と対局して終盤データベース(終盤の答え)を学習していくようです。
ただこれは一定の強さに近似するということで理想的な強さにはなりません。
そうではなくひたすら解を求め続け、最終的には最強になることができるオセロができるんじゃないかと思うわけです。
6×6はアルゴリズムのテストなどには使えると思うのでやるべきでしょうね。 		 

全部読みきる

 投稿者：DO++  投稿日：2005年 4月 4日(月)15時42分57秒
  ことはそれはそれでおもしろいことかもしれませんね。前、５＊５の囲碁の完全解が求められたとかいっていたような気がしましたが、オセロで求められたらそれはすごいでしょう。

全部読みきるのではなく、いくつかの問題に分けられることを示すだけでもすごいとは思いますけど。もうちょっと解ける問題（６＊６とか）を解くのはどうでしょう 		 
お得なプロバイダーとくとくBB

オセロ

 投稿者：和  投稿日：2005年 4月 4日(月)07時32分32秒
  確かに天文学的な数値ですが、4×4オセロの局面数から大雑把に予想した人がいて検索ノード数10^58で重複を除いた局面数は10^28ってとこらしいです。
でも本当だろうか？という疑問です。
あと検索木の最も枝に近い場所=終盤から何とか根の方向に逆に木を作ることが出来れば終盤データベースが出来ます。これが出来れば序盤データベース→中盤の枝狩りなどの腕の見せ所→完全読みきりが序盤データベース→終盤データベースの勝つ局面へたどり着く完全読みきり→終盤データベースで最強になるとは思うのですが。 		 
お得なプロバイダーとくとくBB

ゲームの分岐数

 投稿者：DO++  投稿日：2005年 4月 3日(日)09時23分31秒
  を考えると、オセロあたりはぎりぎり全局面入るのでしょうかねぇ。と思ったら重複は面倒なので考えないとして3^64（白、黒、無し）でちょっと天文学的な数字ですね。実用的には場面を分割して保存するのでしょうか。すでに結構研究されていそうですけどね。
コンピュータ将棋をやっている人が身近にいるので、将棋ではどうやっているのか聞いてみます。 		 

オセロについて

 投稿者：和  投稿日：2005年 3月31日(木)21時27分29秒
  今全局面をディスクに保存するプログラムを作っています(到底不可能ですがね)。
一度出た局面を重複して書き込まないようにするためハッシュやB-Treeを考えていました。
が、そもそも追加のみで更新と削除がないからB-Treeのメリットは薄いし、ハッシュにしても局面が果たしてどれぐらいあるか分からないため途中で拡張できないので、オーバーフローしたら出来た局面は最終的にソートして配列として持つ必要があり、何かと容量、時間的に無駄が多そうです。
メモリよりはるかにシーケンシャルアクセスとランダムアクセスの性能差があるため追加のみに特化したなにか良いデータ構造はないかと考えています。
現在小さなソート済み配列をいくつか作っていき、ある程度大きくなったらマージする、というような仕組みを考えています。容量の無駄もないしシーケンシャルな操作で速度も速そうな予感です。 		 

あけまして

 投稿者：DO++  投稿日：2005年 1月 7日(金)01時45分29秒
  おめでとうございます。

すごいお久しぶりですね。あれから一応いろいろな文献を読み漁って、あの頃は解決できなかった問題などなどが大分わかってきました。

私が書いた頃は正直まだ本格的に研究を始めたばかりなので、いつか機会があれば本という形じゃなくても書き直したいなと思っています。

>「文書データ圧縮アルゴリズム入門」の復刊リクエストをしてしまいました。
>はっきり言って名著です。興味をもたれた方はぜひ投票お願いいたします。

　これ実はまだ読んだことないんですよねぇ。あれば欲しいですけどね 		 
ケータイで撮った動画を掲示板に投稿

お久しぶりです＆あけましておめでとうございます。

 投稿者：【えぬ】  投稿日：2005年 1月 7日(金)01時17分20秒
  2000年ごろ圧縮について話し合っていた「(の)の人」です…
って覚えていないかもしれないですね。
あれから会社勤めにかまけて圧縮のことをすっかり忘れてしまいましたが、
昌達K’z氏のや、奥村先生のや、もちろんDO++さんの本はとりあえず購入しているので、
暇を見つけて勉強し直そうとも考えています。

ちなみに、このたび復刊.comにて
「文書データ圧縮アルゴリズム入門」の復刊リクエストをしてしまいました。
はっきり言って名著です。興味をもたれた方はぜひ投票お願いいたします。
http://www.fukkan.com/vote.php3?no=27499

http://www.fan.gr.jp/~n2s/

  

フィボナッチヒープ3

 投稿者：DO++  投稿日：2004年12月18日(土)01時31分58秒
  >フィボナッチヒープってちょっとググりましたがかなり複雑なアルゴリズムのようですね。まだ理解不能です。

　途中まで複数の木をもっておいて、たまにまとめてそろえるという感じだったような
　前読んだ本では結構わかりやすかったような
　「計算とアルゴリズム　　新コンピュータサイエンス講座」
　これとかにいろいろかいてあったりする

　理論と実際の差はあったりしますし、実装の複雑さもアルゴリズムを述べる上で
重要なキーのひとつですね 		 
お得なプロバイダーとくとくBB

フィボナッチヒープ2

 投稿者：和  投稿日：2004年12月15日(水)23時53分6秒
  フィボナッチヒープってちょっとググりましたがかなり複雑なアルゴリズムのようですね。まだ理解不能です。
ツリーっていうのは1つのデータを追加、削除するのは速いですが、まとめての処理は苦ってなようで。
最近は単純は配列を見直してきています。容量の有利さはそのままに「まとめて」をうまく使えば挿入、削除、ソートのコストをうまく隠蔽できそうですね。 		 

フィボナッチヒープ

 投稿者：DO++  投稿日：2004年12月 7日(火)19時58分52秒
  とかがそういう感じですよね。＞あとでまとめてやる

追加する場合でもまとめて追加するという形だと計算量や領域量が大幅に改善される
ことが多いですよね 		 
お得なプロバイダーとくとくBB
以上は、新着順41番目から50番目までの記事です。 1  2  3  4  5  6  7  8  |  《前のページ |  次のページ》 
／8 


[PR]