K.Maebashi's BBS

ご自由に書き込んでください。雑談も可。
テスト書き込みの類はテスト用掲示板にどうぞ

[日付順表示] [日付順インデックス] [スレッド順インデックス]

新規投稿 | 開設者ホームページへ戻る | ヘルプ

[1686] Re:オセロについて
投稿者:学生
2011/01/20 22:05:39

基本値の計算が作成できました。 次にミニマック法を作成してみたいと思うのですが ComputerPlayer.javaでは何手先まで読んでいて、どこでやっているんでしょうか? 後、ab法はどこでやっているのですか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[1685] Re:オセロについて
投稿者:(ぱ)こと管理人
2011/01/20 00:30:23

>Eval00.javaでは、 cellPriority[][]で評価をしていて、 >自分の石だったら足して、コンピュータの石だったら引いているのは >わかるのですか最後のcellsValue + canPutNum * 100では >なぜ100をかけているんでしょうか? canPutNumは石が置ける場所の数(着手数)です。 オセロは石が置ける限りたとえ不利になるとしてもパスはできないので、 着手数は重要です。手詰まりが最大の敵です。 そのため、canPutNumが評価値に対して大きなウエイトを占めるように するために、100をかけています。 もちろん、cellPriorityの各要素の値を小さくしても同じ効果が あるでしょうけど。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1684] Re:オセロについて
投稿者:学生
2011/01/19 22:54:45

返信ありがとうございます。 >Eval00.javaやEval01.javaの方が、Eval02.javaよりはずっと簡単なので、 >読むならそちらの方がよいでしょう。 その通りで、自分にはEval02.javaは難しいので、 Eval00.javaを参考に作成したいと思います。 Eval00.javaでは、 cellPriority[][]で評価をしていて、 自分の石だったら足して、コンピュータの石だったら引いているのは わかるのですか最後のcellsValue + canPutNum * 100では なぜ100をかけているんでしょうか? 後、Eval00.javaは上の説明であっているでしょうか? 違っていたら、流れを教えてもらえないでしょうか? たびたび質問すいません。よろしくお願いします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1683] Re:オブジェクト指向のメリット
投稿者:(ぱ)こと管理人
2011/01/19 02:44:56

>インスタンスを理解していないので、「どのインスタンスのメソッドを呼ぶのか」と >いう発想ができず、その場でnewして呼んでしまう。これは、私が以下のページで書いた >画面に線を引くたびにCanvasをnewした新人君と同レベルの発想です。 すみません、「以下のページ」のURLを貼り忘れました。ここです。 http://kmaebashi.com/programmer/object/shigoto.html いやさ、それにしても、本当にこのページの 「「どの」オブジェクトに仕事をさせればよいのか」 あたりの説明を読んで、それでもまったく理解できなかったの? だとすれば、いかに相手がアレな人とはいえ、さすがに私も自信をなくします……
[この投稿を含むスレッドを表示] [この投稿を削除]
[1682] Re:オブジェクト指向のメリット
投稿者:(ぱ)こと管理人
2011/01/19 02:32:48

たいやきさんからの回答がないですが(アクセスログも見ましたが、私が 質問を書いた以後ここを見ていないようです)、 たいやきさんって、ハンドルと発言内容からして、こちらで質問されている taiyaki123さんですよね? http://oshiete.goo.ne.jp/qa/6438120.html >せっかく回答してくださって申し訳ないのですが、100%の自信がないのであれば >回答くださらなくても結構です。ありがとうございました。 ……まあこれはさておき。 他にこちらでも質問されているようですが、 http://oshiete.goo.ne.jp/qa/6438154.html >信じられないのは、インスタンス変数が書き換えられるということです。 >サーブレットではインスタンス変数が共有されるのは理解していますが、 >サーブレットから呼ばれるインスタンスで定義されているインスタンス変数も >それに該当するのでしょうか。 >それとも、サーブレット内だけの話で、サーブレットから呼ばれるインスタンスでは >インスタンス変数は独立していると思ってよいでしょうか。 >後者の認識ですが、こういう書き方をされると、サーブレットから呼ばれた先でも >インスタンス変数が共有されると読めて、怖くて仕方ないです。 どう見ても、明らかに「インスタンス」を理解してないですよね。 (そしておそらくは「参照」も) 「サーブレットから呼ばれるインスタンス」って、そもそもインスタンスは 呼ぶものではありません。呼ぶことができるのは「インスタンスのメソッド」です。 揚げ足取りに見えるかもしれませんが、おそらくこのケースでは違います。 なぜなら、No.1の回答の方への「お礼」のところに、taiyaki123さんは 以下のように書いているからです。 >念のため質問内容が分かるようなソースをつけます。 >SampleClassで定義されているメンバー変数(staticではない変数)が、 >スレッド毎に共有されるかという質問です。 >servletclass extends HttpServet{ > public int a = 0; > public void doPost(){ > SampleClass sc = new SampleClass(); > } >} > >SampleClass{ > public int x = 0; >} >このようなプログラムがあったとします。 >このプログラムを複数の人が、同時にアクセスした場合に、 >SampleClassで定義されているメンバー変数のxが共有されるかという意味です。 >もちろん、共有されないという認識です。 新しいSampleClassをdoPost()のたびにnewしてるんだから、 共有されないのは当たり前です。サーブレットは何も関係ありません。 以下も。 http://oshiete.goo.ne.jp/qa/6438120.html >オブジェクトを作って実行するなら >testclass tc = new testclass(); >tc.method(); >というように2行です。 >オブジェクトを作らないなら、testclass.method() >というように1行です。 なにしろtaiyaki123さんはインスタンスを理解していないので、 インスタンスは、「メソッドを呼ぶときにnewするもの」でしかないのでしょう。 だから必要性もわからないし、「サーブレットから呼ばれるインスタンス」という トンチンカンな言葉も出てくる。 もしこの人がプロのJavaプログラマなのだとすれば(想像したくないですが)、 よく聞く、staticメソッドだけで開発している職場なのかもしれません。 インスタンスを理解していないので、「どのインスタンスのメソッドを呼ぶのか」と いう発想ができず、その場でnewして呼んでしまう。これは、私が以下のページで書いた 画面に線を引くたびにCanvasをnewした新人君と同レベルの発想です。 つまり、まったくのド素人です。 (いや、こんなのと一緒にしちゃ新人君に失礼ですが) 本来であれば、「疑りぶかい~」は、こういう人を対象読者としている はずなのですが…… サーブレットの件で当然の疑問を提示しているNo.1やNo.2の人に、 >ですので、以下の回答は間違いですね。 とか >まったくもって間違った回答ですね。 >サーブレットからインスタンスを呼ぶことができないなんて・・・。 とか答えて、せっかくのアドバイスを拒絶してしまうような人が相手では、 私の文章が理解されなかったのだとしても、私のせいではないでしょう。 http://oshiete.goo.ne.jp/qa/6402168.html このへんも、ねえ……
[この投稿を含むスレッドを表示] [この投稿を削除]
[1681] Re:オセロについて
投稿者:(ぱ)こと管理人
2011/01/19 01:54:09

今見てみたのですが、 >評価関数がどこにあるかといえば、Eval02.javaにあります。 >これはEvaluateBoardインタフェースを実装しており、Eval00.javaとかEval01.javaと >差し替えられるようになっています。Eval02を実際にnewしてくっつけているのは >ReversiApplet.javaです。 Eval00.javaやEval01.javaの方が、Eval02.javaよりはずっと簡単なので、 読むならそちらの方がよいでしょう。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1680] Re:オセロについて
投稿者:(ぱ)こと管理人
2011/01/19 00:43:38

>評価、着手数、要素の計算などはどこでやっているのか教えてもらえないでしょうか? 評価関数がどこにあるかといえば、Eval02.javaにあります。 これはEvaluateBoardインタフェースを実装しており、Eval00.javaとかEval01.javaと 差し替えられるようになっています。Eval02を実際にnewしてくっつけているのは ReversiApplet.javaです。 着手数や要石の計算は、このEval02.javaの中のscanLineで盤面を4方向にスキャンし、 フラグを立てています。以下のページに図があります。 http://kmaebashi.com/javaworld/index.html ただ、「学生」さんの現状のプログラムが、 >コンピュータの作成では、ランダムでしか対戦ができないため、 >コンピュータが強くないので強くしたいと思っている所です。 ランダムで(打てるところに?)打つ、というレベルなら、なにもこんな複雑な 評価関数をいきなり導入しなくてもよいのではないでしょうか。 …と、いうことを前回の返信で言いたかったのですが。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1679] Re:オセロについて
投稿者:学生
2011/01/18 22:35:29

ご返信ありがとうございました。 >「学生」さんがどの程度のスキルをお持ちかわかりませんが、 > javaは本を一冊読んだ程度の実力です。 オセロゲームを現在、作成しています。 コンピュータの作成では、ランダムでしか対戦ができないため、 コンピュータが強くないので強くしたいと思っている所です。 リバーシゲームのアルゴリズムは検索して調べてみたのですが、 ソースを見ても詳しくわからないので 評価、着手数、要素の計算などはどこでやっているのか教えてもらえないでしょうか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[1678] Re:オセロについて
投稿者:(ぱ)こと管理人
2011/01/18 02:16:58

はじめまして。 >javaでオセロゲームを作っているのですが、リバーシゲームの思考ルーチンについて >ソースをダウンロードして見ているんですけど、よくわかりませんでした。 >どうやっているのかを詳しく教えていただけないでしょうか? 「学生」さんがどの程度のスキルをお持ちかわかりませんが、 http://kmaebashi.com/javaworld/index.html このページで簡単に説明しているように、このリバーシゲームのアルゴリズムは ミニマックス法とαβ枝刈りです。 それぞれどんなものかについても上記ページにごく簡単に説明していますが、 もちろんこの説明ではわからないからこそここで質問されたのかと思います。 ミニマックス法とαβ枝刈りはこの手のゲームの思考ルーチンとしては ごく一般的なものなので、検索すれば解説ページは出てきます。 Wikipediaの解説もそんなに悪くないかも。 http://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%8B%E3%83%9E%E3%83%83%E3%82%AF%E3%82%B9%E6%B3%95 αβ枝刈りも検索すれば出ますが、高速化の手段なので(しかもそんな 劇的に早くなるわけでもないので)、最初はなくてもよいかも。 あとは評価関数ですが、少々手抜きの評価関数でも、ある程度先読みすれば、 並の人間の相手は可能なぐらいの強さにはなります。 たとえば盤面の各マスに評価値を付けておいて(当然四隅が最大)、 自分の石があったらその値を加算、敵の意思があったら減算、ぐらいの 評価関数でもそこそこ遊べるようなものになった記憶があります。 私のリバーシゲームでは結構凝った評価関数を実装していますが、 実のところこれがよい評価関数なのか、私には判定できません。 私自身がこの手のゲームが得意でないため、自分の作ったプログラムに まるっきり勝てないので、評価関数を直しても、強くなったのか弱くなったのか 判定できないためです。 実は、私のプログラムの評価関数は、以前別件で作った「6×6オセロ」の 評価関数の焼き直しです。「6×6オセロ」のときは、評価関数同士を 戦わせたりしてまじめに検討したのですが、それを8×8に焼き直すときには、 まったく検証していません。手抜きです……
[この投稿を含むスレッドを表示] [この投稿を削除]
[1677] オセロについて
投稿者:学生
2011/01/17 22:37:20

javaでオセロを作っているものですがよろしくお願いします。 javaでオセロゲームを作っているのですが、リバーシゲームの思考ルーチンについて ソースをダウンロードして見ているんですけど、よくわかりませんでした。 どうやっているのかを詳しく教えていただけないでしょうか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[1676] Re:オブジェクト指向のメリット
投稿者:(ぱ)こと管理人
2011/01/16 23:52:17

>>オセロゲームですが、普通に一つのオブジェクトしかつくれないようなプログラムを書いておけば、サーブレットから起動されればそれぞれのオブジェクト(オセロ盤)が >>作られますから、マルチインスタンスを気にしなくてもよいと思います。 >>イメージ沸きますでしょうか。 > >すみません、イメージ沸きません。 >「普通に一つのオブジェクトしかつくれないようなプログラム」における >「プログラム」とはどのような単位ですか? >「サーブレットから起動」の「起動」とは、具体的にどういうことですか? >「起動」されたプログラムが終了するタイミングはいつですか? で、こちらについての回答はなしですか? 上記についても答えてもらいたいのですが、回答に時間がかかるかもしれないので、 追加で質問させてください。簡単に答えられるように選択式にしておきます。 たいやきさんは、今まで、サーブレットのプログラムを一度でも書いたことがありますか? a) 自分で全体を書いたことがある。(小さなテストプログラムのようなものでも可) b) 全体を書いたことはないが、仕事でチームで開発する等で、 c) 実際にコードを書いたことはない。ただ、本で勉強したことはある。  (書名を書いてください) d) 書いたこともなければ本で勉強したこともない。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1675] Re:オブジェクト指向のメリット
投稿者:(ぱ)こと管理人
2011/01/16 23:47:43

>そういう色んな経験やスキルがある人で、オブジェクト指向に挫折した人に、 >ちゃんと全てのオブジェクト指向の特徴とメリットを説明することが、 >アンチテーゼとしての役割だと思います。 知らんがな、としか言いようがありませんが。 うちのページが不満なら読んでいただかなくて結構ですし、 もっといい説明方法があると思うのなら、たいやきさんがご自分で Webでもなんでも書けばよいでしょう。 うちのページの趣旨は、「再入門」ですので、他の書籍やWebページの オブジェクト指向の説明において「欠けている」と私が感じた部分に 特化しています。 当時「マルチプルインスタンス オブジェクト指向」で検索しても 1件もヒットしなかったのが、今だと1000件以上ヒットします。 multiple instanceという言葉自体は一般的なものなので、この1000件 すべてが私の記事からの派生ではないと思いますが、それにしても 相応に需要はあったと言えると思います。 >>>継承には、重複コードを省くというメリットがあります。 >>>ポリモーフィズムには、ロジックの共通化というメリットがあります。 >私はこのメリットが正しいということに自信を持っています。 >また、そういう使い方をしているPGも回りにあります。 >また、書きませんでしたが、他にもメリットがあるとも思っています。 >私が言うメリットが正しいかどうかは置いておいて >ここで言いたかったのは、オブジェクト指向の3大特徴には、 >それぞれメリットがあって、それも説明しないと、オブジェクト指向の >説明としては不足であるということです。 >ですので、管理人様が間違っておられると思うのであれば、それはそれでいいと >思いますし、管理人様が思われるメリットを主張されればよいと思います。 >だた、継承やポリモーフィズムの説明をされる際には「今どきやらない」という >表現は誤解を生むと思います。 「今どきやらない」とは私は書いていません。 「今どきは、流行らない」と書いています。 まあ、これは実際紛らわしいですし、ひらがなで書いた私も悪いと思うのですが、 そもそも「継承やポリモーフィズム」について「今どきやらない」とも 「今どき流行らない」とも書いてはいません。ここで「今どき流行らない」と 書いているのはあくまで実装継承についてのみです。正しく読んでください。 で、 >>>継承には、重複コードを省くというメリットがあります。 実装継承については、かつては確かにもてはやされていた時代がありましたし、 便利な局面もあることはあるんでしょう(もちろん、デメリットの方が大きいと 判断されたからこそ流行らなくなったのですが)。 しかし、 >>>ポリモーフィズムには、ロジックの共通化というメリットがあります。 こっちについては実のところ意味がわかりません。 ポリモルフィズムで、どう、ロジックを共通化するのですか? 具体的な例を挙げて説明してください。 >私はこのメリットが正しいということに自信を持っています。 >また、そういう使い方をしているPGも回りにあります。 仕事のプログラムならそのまま提示することはできないと思いますが、 差し支えのない範囲で、どのようなコードを書いているか提示してもらえませんか? 興味があります。ここを見ている他の方もそうでしょう。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1674] Re:オブジェクト指向のメリット
投稿者:たいやき
2011/01/15 17:08:37

>こちらを見ていただくとわかるかと思うのですが、 >http://kmaebashi.com/programmer/object/othello.html > >「メンバー変数を隠したり、メンバー変数やメソッドをまとめたり」というのは、 >「疑りぶかい~」の想定読者は(たとえCで書いても)すでにやっているだろう、 >というのが前提です。 >この前提が正しいかどうかはよくわかりません。世間のCプログラマは、 >staticを使ってデータや関数を隠そうなどとは考えたこともない人が >大部分なのかもしれません。だとすれば、私がやっていることは効率の悪い方法だ、 >ということになるかと思います。 > >ただ、もしこの前提が正しいとするなら、そういうプログラマにカプセル化を >トクトクと語っても、「何だそんなことは俺もとっくにやってるよ」と思われるのが >オチです。 いいえ。そうではありません。 そもそも不思議なのが、なぜ、C言語をやってきた人(C言語に対するある程度 の知識があること)だけが対象なのでしょうか。 オブジェクト指向の理解に挫折した(このサイトを読む)人には、 今までC言語をやってきた人もいれば、やってきてない人もいます。 オブジェクト指向言語が始めてのプログラム言語の人もいると思います。 COBOLだけ知っている人もいると思います。 そういう色んな経験やスキルがある人で、オブジェクト指向に挫折した人に、 ちゃんと全てのオブジェクト指向の特徴とメリットを説明することが、 アンチテーゼとしての役割だと思います。 その特徴やメリットが、これまでのプログラム言語でも既に出来るのであれば、 それはその言語での特徴やメリットが、オブジェクト指向言語にも 連綿とひきつがれているんですと説明すればいいだけです。 そうすれば、「オブジェクト指向は今までの開発言語で出来ることやメリットも 継承しながら、新しい考え方や技術もとりいているんだよ」という事実が 分かってもらえると思います。その事実をちゃんと説明することが大切で、 「なんだそんなこととっくにやっているよ」という人だけを意識して説明することで、返ってオブジェクト指向を正しく理解してもら阻害になっていると感じます。 もし、C言語をやってきた人(C言語に対する知識がある程度ある方)向けの 説明であれば、「疑りぶかいあなたのためのオブジェクト指向再入門」という 名前の付け方や、書かれている内容は適切ではないと感じます。 すごく期待を持たせるようなタイトルであり、書き出しで オブジェクト指向の説明が不適切であることを指摘し、最適な説明を期待させる ような内容になっていながら、実は端にC言語との比較だけの説明になっています。 >>継承には、重複コードを省くというメリットがあります。 >>ポリモーフィズムには、ロジックの共通化というメリットがあります。 > >このメリットはどっちも間違っているような。 >少なくともいまどき実装継承ははやらないですし、ポリモルフィズムは >同じインタフェースで違うロジックを与える機能ですので(Template Methodパターン >みたいな使い方もあるにはありますが)。 私はこのメリットが正しいということに自信を持っています。 また、そういう使い方をしているPGも回りにあります。 また、書きませんでしたが、他にもメリットがあるとも思っています。 私が言うメリットが正しいかどうかは置いておいて ここで言いたかったのは、オブジェクト指向の3大特徴には、 それぞれメリットがあって、それも説明しないと、オブジェクト指向の 説明としては不足であるということです。 ですので、管理人様が間違っておられると思うのであれば、それはそれでいいと 思いますし、管理人様が思われるメリットを主張されればよいと思います。 だた、継承やポリモーフィズムの説明をされる際には「今どきやらない」という 表現は誤解を生むと思います。 もし、管理人様が世界中の全てのコードをみてそういわれているのであれば いいですが、そうではないと思いますから、このような狭い範囲での経験をもって 断定的な表現は、読む方に誤解を与えます。 今使われているかどうかというより、どういうメリットがあるかを一つ一つ正確に 伝えることが、一番正しく理解してもらえると思います。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1673] Re:オブジェクト指向のメリット
投稿者:(ぱ)こと管理人
2011/01/14 01:15:39

>クラスには、メンバー変数を隠したり、メンバー変数やメソッドをまとめたり、 >オブジェクトをたくさんつくれるというメリットがあります。 こちらを見ていただくとわかるかと思うのですが、 http://kmaebashi.com/programmer/object/othello.html 「メンバー変数を隠したり、メンバー変数やメソッドをまとめたり」というのは、 「疑りぶかい~」の想定読者は(たとえCで書いても)すでにやっているだろう、 というのが前提です。 この前提が正しいかどうかはよくわかりません。世間のCプログラマは、 staticを使ってデータや関数を隠そうなどとは考えたこともない人が 大部分なのかもしれません。だとすれば、私がやっていることは効率の悪い方法だ、 ということになるかと思います。 ただ、もしこの前提が正しいとするなら、そういうプログラマにカプセル化を トクトクと語っても、「何だそんなことは俺もとっくにやってるよ」と思われるのが オチです。でも、クラスには、たいやきさんも挙げておられるように 「オブジェクトをたくさんつくれるというメリット」もあるので、 そこを無視して「何だそんなことは俺もとっくにやってるよ」と思われたら 先に進めない。「疑りぶかい~」でマルチプルインスタンスを強調している 意図はそこです。 継承やポリモルフィズムは、いずれ書こうと思ってほったらかしになっている、 というのが実態ではありますが、 >継承には、重複コードを省くというメリットがあります。 >ポリモーフィズムには、ロジックの共通化というメリットがあります。 このメリットはどっちも間違っているような。 少なくともいまどき実装継承ははやらないですし、ポリモルフィズムは 同じインタフェースで違うロジックを与える機能ですので(Template Methodパターン みたいな使い方もあるにはありますが)。 >オセロゲームですが、普通に一つのオブジェクトしかつくれないようなプログラムを書いておけば、サーブレットから起動されればそれぞれのオブジェクト(オセロ盤)が >作られますから、マルチインスタンスを気にしなくてもよいと思います。 >イメージ沸きますでしょうか。 すみません、イメージ沸きません。 「普通に一つのオブジェクトしかつくれないようなプログラム」における 「プログラム」とはどのような単位ですか? 「サーブレットから起動」の「起動」とは、具体的にどういうことですか? 「起動」されたプログラムが終了するタイミングはいつですか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[1672] Re:オブジェクト指向のメリット
投稿者:たいやき
2011/01/13 22:24:25

>JavaでServletを使う場合も、オセロ盤のインスタンスが複数作れないと、 >同時に複数の対戦を行うのはかなりやりにくくないですか? >たいやきさんがどのような作り方を想定しているのか具体的に >教えていただけると嬉しいです。 この質問に答える前に、私はオブジェクト指向が分かっているのか/分かってないのかすら分かりませんが、自分なりにオブジェクト指向とは、 「従来(非オブジェクト指向)のプログラミングを多少なりとも楽にする技術や概念の総称」だと理解しています。 そのオブジェクト指向の考え方を利用した技術や考え方として、フレームワーク、 ザインパターン、UML、オブジェクト指向プログラミングといった技術がありますが、 このサイトではオブジェクト指向プログラミングに焦点を当てておられるので、 それに特化してみると、クラス・継承・ポリフォーフィズムという3つの技術が あると思います。 クラスには、メンバー変数を隠したり、メンバー変数やメソッドをまとめたり、 オブジェクトをたくさんつくれるというメリットがあります。 継承には、重複コードを省くというメリットがあります。 ポリモーフィズムには、ロジックの共通化というメリットがあります。 この中にはオブジェクト指向でなくても出来る点はありますが、オブジェクト指向でも 使える訳で、これらを使うことにより、結果として、従来のプログラミングより 多少なりとも楽が出来るというのが、オブジェクト指向プログラミングだと思います。 これが正しいかどうかわかりませんが、仮りに正しいとすると、他の言語でも出来るとか、最初に覚えることではないとかではなく、 これらを一つ一つ丁寧に説明することが、「疑りぶかい人」へオブジェクト指向 をちゃんと説明することになると思っています。 他の説明を置いておいて、クラスのメリットであるオブジェクトをたくさん 作れることを主眼に置いて説明することは、「疑りぶかい人」にオブジェクト指向を 正しく理解してもらえることにはならないと思います。(私がそうでした。) このサイトは、下手なオブジェクト指向の説明にたいするアンチテーザとして作られた サイトだと思っていますので、このサイトを見た人がさらに挫折することの無いような工夫を期待します。 オセロゲームですが、普通に一つのオブジェクトしかつくれないようなプログラムを書いておけば、サーブレットから起動されればそれぞれのオブジェクト(オセロ盤)が 作られますから、マルチインスタンスを気にしなくてもよいと思います。 イメージ沸きますでしょうか。  
[この投稿を含むスレッドを表示] [この投稿を削除]
[1671] Re:オブジェクト指向のメリット
投稿者:(ぱ)こと管理人
2011/01/11 23:00:21

>サービス毎に(要するに対局1件毎に)別プロセスを起動するってのは UNIX 系では >一般的手法と思う。 それはそうなんですが、たいやきさんの主張は以下なので、 「Servletを使ったとき」を想定しなければいけないでしょう。 >というのはJavaでサーバを動かすときには、servletを使うことが出来ますが、 >その場合はマルチにインスタンスが作れなくても(1つしかつくれなくても)、 >オンラインオセロのようなゲームは作れるためです。 Servletそのもののインスタンスは(少なくとも通常は)全体でひとつなので、 複数対戦をホストしたければBoardのインスタンスを複数作って セッション等からそれを参照するように作るのが自然なように思います。 >俺なら「盤面は先読み1手につき1個必要」と例示するかな・・・ >再帰深さ1段につき盤面1個を要するってことで。 これはわかります。私が作ったプログラムでも実際にそうなっています。 http://kmaebashi.com/javaworld/index.html ただ、これを理解するにはオセロの思考ルーチンに対する理解がある程度必要で、 そうなると本筋から離れてしまいますから、「複数対戦をホストするため」という ことにしました。 ただ、公開当時も「複数対戦をホストするなら、自分ならプロセス分ける」という 方もいらっしゃって、「思考ルーチンで先読みするためにも使いますし」と答えたら 「それなら納得できます」と言われたので、このあたり、どのような説明なら 納得できるかは個人差がありそうです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1670] Re:オブジェクト指向のメリット
投稿者:774RR
2011/01/11 11:36:49

たいやき氏ではないが一意見として サービス毎に(要するに対局1件毎に)別プロセスを起動するってのは UNIX 系では一般的手法と思う。 samba などでも接続1件につき1個 smbd が起動するわけで。 静的変数はプロセス毎に作られるものなので「対戦1件につき1プロセス」なら、 プロセス単位で盤面1個でも別に困らない、ってことではないかな・・・ 俺なら「盤面は先読み1手につき1個必要」と例示するかな・・・ 再帰深さ1段につき盤面1個を要するってことで。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1669] Re:オブジェクト指向のメリット
投稿者:(ぱ)こと管理人
2011/01/09 13:08:07

ご意見をいただくのは歓迎ですし、「偉そうに」とか恐縮される必要は ないのですが、 >マルチプルインスタンスをオブジェクト指向の特徴としてあげるのはよいと >思いますが、オセロでの説明はやめたほうがよいのではと個人的に思っています。 >というのはJavaでサーバを動かすときには、servletを使うことが出来ますが、 >その場合はマルチにインスタンスが作れなくても(1つしかつくれなくても)、 >オンラインオセロのようなゲームは作れるためです。 JavaでServletを使う場合も、オセロ盤のインスタンスが複数作れないと、 同時に複数の対戦を行うのはかなりやりにくくないですか? たいやきさんがどのような作り方を想定しているのか具体的に 教えていただけると嬉しいです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1668] Re:ライザ言語の件(お久しぶりです)
投稿者:
2011/01/08 18:15:11

>迷惑ということはまったくありません。 ありがとうございます。でも、何かありましたら言ってください。 今は3Dグラフィックの組込を行っており、その一部の組み込み関数が87個です。 それでもまだまだ少なく、まだ多くの組込関数が必要です。 今は、3Dのマトリックス演算処理に四苦八苦しています。 いま、数行のプログラムで画面に3Dキャラが出て踊ったりはしているのですが、 それ自体では、システムを作っている意味が全く見えないのが残念です。 意味を持って見せられるようになるのは、先が遠そうです。 ふと、vector なり Matrix 変数型を作りたいとも思ってしまいましたが、 これはでは、本来の目的と外れて本末転倒とも思ってしまいます。 (でも結局 sheet 変数型作ってるけどね) 気は焦りますが、またーりやっていきます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1667] Re:オブジェクト指向のメリット
投稿者:たいやき
2011/01/08 14:35:27

管理者様 返信が遅くなり申し訳ありません。 ご回答くださりありがとうございます。 オブジェクト指向でインスタンスがたくさん作れることが特徴であることと、 その特徴によって複数人で同時アクセスできるシステムが作れること (例えばオンラインオセロ)は、まったく無関係だと思います。 マルチプルインスタンスがオブジェクト指向の特徴の一つであることに 異論はありませんが、その説明をオンラインオセロで説明されることは、 返ってオブジェクト指向を間違って説明している(もしくは誤解をさせる)ことに なると思います。 実は、私はオブジェクト指向がわかっておらず、このサイトを読ませていただいて、 オブジェクト指向を教えてくれる親切なサイトがあるんだなとずっと思っていました。 が、最近、オブジェクト指向の本質がわかるにつれ、このサイトの説明は怪しいな と思うようになりました。 マルチプルインスタンスをオブジェクト指向の特徴としてあげるのはよいと 思いますが、オセロでの説明はやめたほうがよいのではと個人的に思っています。 というのはJavaでサーバを動かすときには、servletを使うことが出来ますが、 その場合はマルチにインスタンスが作れなくても(1つしかつくれなくても)、 オンラインオセロのようなゲームは作れるためです。 マルチプルインスタンスの説明は、もっと単純に説明できますし、そのほうが 本当に分かってない人にはわかりやすいと思います。 せっかくご説明をいただいて、偉そうに申し訳ありません。 では、失礼します。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1666] Re:ライザ言語の件(お久しぶりです)
投稿者:(ぱ)こと管理人
2011/01/05 23:03:15

お久しぶりです。Diksamはすっかり放置してしまっていますが、そちらは 開発が進んでいるのですね。 > また、日記みたいに書いてしまうかもしれません、問題がありましたら注意 >してください。でも、ここで書く事も1つのモチベーションになるので、ご迷惑 >でなければよろしくお願いいたします。 迷惑ということはまったくありません。 > {L"dummy", L"", 0}, > {L"push_int_1byte", L"b",8}, > {L"push_int_2byte", L"s",8}, > {L"push_int_4byte", L"i",8}, // 実際の値を持つ たぶん中身は全然違っていると思うのですが、バイトコードのニモニックには Diksamの痕跡が残っていますね。うれしいことです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1665] ライザ言語の件(お久しぶりです)
投稿者:
2011/01/04 21:21:06

一年以上のお久しぶりです。8ヶ月ほど別のソフトを作っていたので、その間 何もしていませんでした。が、まだまだ作っています。 グラフィック部分をメインに作成しているので、なかなか見れる物ができません。 現在約4万5千行ほどのプログラムになっています。  また、日記みたいに書いてしまうかもしれません、問題がありましたら注意 してください。でも、ここで書く事も1つのモチベーションになるので、ご迷惑 でなければよろしくお願いいたします。 言語のインプリメントですが色々変えすぎて、何を変えたか分からなくなるほ どです。  まずはバイトコードが変わりました。 C++のwstringはやはり重たく、zwstringをオリジナルに作りました。 もちろんガーベージコレクションを必要としない可変長文字列変数です。 ↓がオペコードリストです。 {L"dummy", L"", 0}, {L"push_int_1byte", L"b",8}, {L"push_int_2byte", L"s",8}, {L"push_int_4byte", L"i",8}, // 実際の値を持つ {L"push_double_0", L"", 12}, {L"push_double_1", L"", 12}, {L"push_double_8byte", L"d",12}, // 実際の値を持つ {L"push_string_const", L"s",12}, // 文字列の位置NOを持つ0~ {L"push_null", L"", 8}, /**********/ {L"push_stack_int", L"s", 8}, // intローカル変数をスタックに {L"push_stack_double", L"s", 8}, // {L"push_stack_string", L"s", 12}, // {L"pop_stack_int", L"s", -8}, // スタックのintをローカル変数に {L"pop_stack_double", L"s", -8}, // {L"pop_stack_string", L"s", -12}, // /**********/ {L"push_static_int", L"s", 8}, // int静的変数をスタックに 予約 {L"push_static_double", L"s", 12}, // {L"push_static_string", L"s", 12}, // {L"pop_static_int", L"s", -8}, // スタックのintを静的変数に 予約 {L"pop_static_double", L"s", -12}, // {L"pop_static_string", L"s", -12}, // /**********/ {L"push_sheet", L"s", 8}, // sheet番号をスタックに {L"push_sheet_int ", L"s", 8}, // sheet変数をスタックに {L"push_sheet_double", L"s", 12}, // {L"push_sheet_str ", L"s", 12}, // {L"pop_sheet_int ", L"s", -24}, // スタックからsheet変数に {L"pop_sheet_double", L"s", -28}, // {L"pop_sheet_str ", L"s", -28}, // /**********/ {L"push_array_ref ", L"s", 8}, // 配列参照 {L"push_array_int ", L"s", -1}, // int配列処理 {L"push_array_double", L"s", -1}, // {L"push_array_string", L"s", -1}, // {L"pop_array_int ", L"s", -1}, // スタックからint配列に {L"pop_array_double", L"s", -1}, // {L"pop_array_string", L"s", -1}, // /**********/ {L"and_int", L"", -8}, // 以下は総て算術演算子 {L"or_int", L"", -8}, {L"xor_int", L"", -8}, {L"add_int", L"", -8}, {L"add_double", L"", -12}, {L"add_string", L"", -12}, {L"sub_int", L"", -8}, {L"sub_double", L"", -12}, {L"mul_int", L"", -8}, {L"mul_double", L"", -12}, {L"div_int", L"", -8}, {L"div_double", L"", -12}, {L"mod_int", L"", -8}, {L"mod_double", L"", -12}, {L"minus_int", L"", 0}, {L"minus_double", L"", 0}, {L"increment", L"", 0}, {L"decrement", L"", 0}, // ここまで算術演算子 /**********/ {L"cast_int_to_double", L"", 4}, // 以下はキャスト処理 {L"cast_double_to_int", L"", -4}, {L"cast_string_to_int", L"", -4}, {L"cast_string_to_double", L"", -0}, {L"cast_boolean_to_string", L"", 4}, {L"cast_int_to_string", L"", 4}, {L"cast_double_to_string", L"", 0}, // ここまでキャスト処理 /**********/ {L"eq_int", L"", -8}, // 以下は総て論理演算子 {L"eq_double", L"", -16}, {L"eq_string", L"", -16}, {L"gt_int", L"", -8}, {L"gt_double", L"", -16}, {L"gt_string", L"", -16}, {L"ge_int", L"", -8}, {L"ge_double", L"", -16}, {L"ge_string", L"", -16}, {L"lt_int", L"", -8}, {L"lt_double", L"", -16}, {L"lt_string", L"", -16}, {L"le_int", L"", -8}, {L"le_double", L"", -16}, {L"le_string", L"", -16}, {L"ne_int", L"", -8}, {L"ne_double", L"", -16}, {L"ne_string", L"", -16}, // ここまで論理演算子 {L"logical_and",L"", -8}, // {L"logical_or", L"", -8}, // {L"logical_not",L"", 0}, // /**********/ {L"pop", L"", -8}, // スタックを1つ減らす {L"duplicate", L"", 16}, // スタック内容をコピーしてスタックに {L"jump", L"s", 0}, // 指定ポインターにjump {L"jump_if_true", L"s", -8}, // スタックがtrueならjump {L"jump_if_false", L"s", -8}, // スタックがfalseならjump {L"nop------------",L"", 0}, // nop /**********/ {L"push_function", L"", 0}, // 関数情報をスタック、未使用 {L"call_function", L"ssss", 0}, // 関数コール {L"return", L"", -1}, // 関数戻り /**********/ {L"set_array_literal_int", L"ss", 0}, // int定数配列を変数にコピー {L"set_array_literal_double",L"ss", 0}, // double定数配列を変数にコピー {L"set_array_literal_string",L"ss", 0}, // string定数配列を変数にコピー また、メイン関数も1つのスレッドになり、待機リターンをしてVMを保持しないようにしました。  ↓例 //===================================================================== // 最初に実行されるmein関数 //===================================================================== int main(int qid,int p1) { if(qid == スレッド開始) { main_init(); return スレッド待機; } elsif(qid == 終了指示) { return スレッド終了; } return スレッドエラー終了; } また、配列操作のバイトコードもよりシンプルになり 2/3以下のバイトコードになりました。 シートの宣言も関数外で↓のようにラベル宣言するようにしました。 sheet s_system[10][20]; // システム設定のシート定義(変更不可) sheet s_key_input[2][256]; // キー入力定義(変更不可) sheet s_mouse_input[2][11]; // マウス入力定義(変更不可) sheet s_pad_input[8][20]; // パッド入力定義(変更不可) 初期バージョン完成にはまだまだかかりそうです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1664] Re:MD5関数ですが
投稿者:sayonara
2010/12/29 16:50:38

>今頃だったら md5 でなく sha1 にするともう少しマシになるかもしれない。 sha1ですか。覚えておきます!
[この投稿を含むスレッドを表示] [この投稿を削除]
[1663] Re:MD5関数ですが
投稿者:774RR
2010/12/29 07:48:13

この種のセキュリティって奴を考察する上では、 ・誰から何を守るのか ・かかるコストが効果に見合うか を考えないと意味がない。 正規の管理人が平文パスワードを(見たくないのに誤って)見てしまうこと対策 掲示板運営している httpd サーバに侵入されて掲示板ソースだけ盗まれた場合の対策 遠隔地からデーターベースに侵入されてデータだけ盗まれた場合の対策 httpd と DB 両サーバに侵入されてソース+データが両方盗まれた場合の対策 下に行くほど、なさそうなシナリオ+被害大、なわけだが ・現実的にありえないような状況に対する施策のために  コスト(金銭的、手間的)をどこまでかける必然があるか? の線引きになるだけのこと。 掲示板ソフト上の固定文字+乱数 salt +ユーザーパスワード、ってのは現実的解だと思う。 今頃だったら md5 でなく sha1 にするともう少しマシになるかもしれない。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1662] Re:MD5関数ですが
投稿者:sayonara
2010/12/28 12:20:28

>また、データベースの中身を覗けている時点で、悪人はPHPのソースを見て >「秘密」の文字列を見ることができている可能性が高いような気もします。 >その場合には、「秘密」は役に立たないということになります。 ここは懸念ですね。ソースに記述しない方法ってあったりするのかな!
[この投稿を含むスレッドを表示] [この投稿を削除]
[1661] Re:MD5関数ですが
投稿者:(ぱ)こと管理人
2010/12/28 01:41:18

774RRさん、毎回ありがとうございます。 それだけでは何なので蛇足ですが。 こちらに以下のような説明がありますが、 http://kmaebashi.com/programmer/bbs_dev/delete.html | また、こうしておくことで、掲示板を運営しているサーバが万一クラックされたり、 | レンタルサーバ業者がD/B情報を漏洩させたりしたときにも、投稿者のパスワードを | 守ることができます。 | なお、いくらMD5アルゴリズムが逆方向の推測が困難だといっても、辞書攻撃や | 総当り攻撃により破られる可能性はあります。そこで、上のソースでは、 | パスワードに対し秘密の文字列(赤字部分)を連結しています。もちろん実際の | ソースでは、ここには「秘密」という文字列ではなく、推測されにくいでたらめな | 文字列が書かれています。こうしておけば、そのでたらめな文字列がばれない限り、 | パスワードそのものを推測することはできません。 saltの話はひとまず除外し、「秘密」についてだけ考えます。 もしこの「秘密」文字列をくっつけなかったとすると、 データベースの内容が悪人に漏洩した場合、悪人は、辞書等の単語に 片っ端からMD5をかけることでパスワードの推測が可能な場合があります。 ちょっと昔のUNIXでは、パスワードに1方向ハッシュをかけた文字列を そのまま(誰にでも見える形で!)保存していて、私も一度、とあるサーバにて、 「ユーザIDと同じパスワードを使っている人」がいないか調べてみたら ぼろぼろ見つかってしまった、ということがありました。 ユーザIDと同じパスワードは論外として、辞書攻撃的なものには「秘密」は 有効ですが、「総当り攻撃」に対しては、本質的には「程度問題」の防御にしか なりません。もっとも文字列長が増えるので、この「程度問題」はかなり 大きな「程度問題」ですけれども。 また、データベースの中身を覗けている時点で、悪人はPHPのソースを見て 「秘密」の文字列を見ることができている可能性が高いような気もします。 その場合には、「秘密」は役に立たないということになります。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1660] Re:MD5関数ですが
投稿者:sayonara
2010/12/27 18:10:43

課題1まで理解した上で質問しました。 わかりやすい説明でありがとうございます。 議論の板を読んで、 "秘密"は任意で良いとなんとなく思ってましたが、 確信できずに調べても出てこなかったです。 何度も回答していただいてすみません。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1659] Re:MD5関数ですが
投稿者:774RR
2010/12/27 15:42:48

salt の役割を理解していればそんな質問最初から出ないと思うが・・・ 先に挙げた掲示板上の議論の詳細は読んで理解できた? 課題1:パスワードを平文(ひらぶん)で保存するのはユーザにとっても管理人にとってもうれしくない 解決策:パスワードを1方向ハッシュで保存したらいい 1方向ハッシュとして MD5 アルゴリズムを使うとしたら md5($password) でいい # そもそも1方向ハッシュって何か?の解説は略 ここまで大丈夫?これが理解できていないのであれば以下の話は読むだけ無駄。 課題2:データベースクラックされてハッシュ化されているパスワードが漏れたら、 そのときのセキュリティをどう担保すればいい? 解決策:パスワードだけを md5 すると「md5 辞書アタック」で破られうるので、 パスワードに別の文字をくっつけたら「破るコストが跳ね上がる=破られない」。 そのために「くっつける文字」というのを用意するとよい (これが salt) PHP では文字列の連結に . を使う。"hoge" . "piyo" は連結されて "hogepiyo" になる。 http://www.php.net/manual/ja/language.operators.string.php ユーザーが入力したパスワード (例: "hoge") に 掲示板ソフトが用意した乱数文字列 salt (例: "piyo") をくっつけて md5("hogepiyo") としてハッシュ値を保存すれば、 データーベースがクラックされてハッシュ結果と salt の "piyo" が漏れても 元パスワード "hoge" を取り出すコストは膨大なものになる=破りにくい。 # 実用的時間のうちに破ることができないのであれば、破られないと言い切っていい。 先の hash_user_password は「ユーザの入力したパスワード」「ソフトが乱数で用意した salt 」の他に 「掲示板プログラムをインストールするごとに変えられるカスタマイズ可能文字 "秘密" 」をくっつけている。 だから "秘密" のところには何を入れてもいい。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1658] MD5関数ですが
投稿者:sayonara
2010/12/27 09:16:18

54: function hash_user_password($src, $salt) { 55: $dest = md5("秘密" . $src . $salt); 56: 57: return $dest; 58: } 以上の”秘密”のところに何を入れればいいでしょうか。 hash_user_passwordは$src, $saltの値が入力され、$destを出力すると 自分の理解はここまでですが、色々調べても乱数$saltを使ったMD5関数の使い方は見つからなかったです。 どうか教えてください。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1657] Re:DBにテーブル作成時の項目について
投稿者:(ぱ)こと管理人
2010/12/22 03:48:07

返信が遅くなりましてすみません。 また、774RRさん、回答ありがとうございました。 >このページにある「messageテーブル」についてですが、 >password項目が二個並んでいるのはどうしてでしょうか。 >↓ >password varchar(64) パスワード >password varchar(64) パスワードのsalt このページの記述がこうなってしまっているのは単なる誤植ですね。 修正しました。ご指摘ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]