- PR -

プログラムの書き方でご指導お願いします。

«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»
投稿者投稿内容
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-11-11 11:41
引用:

trueについて明確なのはそうだと思うのですが。 falseは「tureではない」という程度の意味合いしか持たないように感じているです。数学でいう逆とか不完全性定理とかそーゆー面倒なジャンルに突入してしまうのですが(苦笑
そのあたりが、明示的であるtrueに対して、falseをもうひとつ信用していない理由なのかもしれないです。

C 言語に馴染んできたから true を信じるスタンスなのかもしれない、とか言ってましたけど、それも考えてみるとおかしな話ですね。C 言語での false(偽値) は 0 のみですが、true(真値) は 0 以外のすべての値です。つまり、真偽値が数値であらわされているという実装を意識した場合、true(真値) のほうが範囲が広く揺らぎがあるわけです。

それなら、より限定的な false のほうが信用できるということになりませんか？ false は必ず 0 なのですから。数値としてみた場合に範囲の広い true こそ、がるがるさんのいう「それ以外全部まとめて」に該当するのではないですか？ どのような歪んだ C 言語の学び方をしたら、true は信用できるが false は信用できないという意識が身に付くのかまったく理解できません。

引用:

falseは「tureではない」

なぜ、true は「false ではない」という意識にならなかったのでしょう･･･。ちなみ私は true の範囲が広いとかそういうことは関係なく、「true は false ではない。false は true ではない」と考えています。( C 言語を使うときにも )

引用:

数学でいう逆とか不完全性定理とかそーゆー面倒なジャンルに突入してしまうのです

チラ見せキーワードで終わらせずに、このあたりもうちょっと丁寧に説明していただけませんか？ 面倒といって説明を怠っていては、それこそ議論になりませんよ？ 数学に弱い私のアタマで、その不完全性定理を理解できるかどうか分かりませんが、よろしくお願いします。

引用:

「ステータス２つの状態でのチェック」と「ちょっと条件が増えてステータス３つの状態でのチェック」と…ってのが混在するような要求がある場合もあって。

そんなことが本当にあるんですか？ あるひとつの要素に基づいて二分岐する場合と三分岐する場合があるなんて信じられません。もし、それが事実だとすると、3 ステータスを大雑把な 2 ステータスに集約できなくてはいけないことになります。つまり、3 ステータスのうち追加されたひとつのステータスは、既存の 2 ステータスの一方にマッピングできなくてはいけません。

そうすると、第 3 のステータスは、第 1, 第 2 いずれかのスタータスの子ということになります。これは、がるがるさんが当初、主張されていたことと矛盾しますよね。

二分岐と三分岐が混在する例をあげておきます。

　二分岐: 無色 or 着色
　三分岐: 透明 or 赤 or 青

よく見ると三分岐の要素が同等でないことに気付くはずです。

引用:

私は勝ちました。この議論で、いくつか得がたい知識が身につけられましたので。
# 勝利条件：得るものがあったか否か

すばらしい考え方だと思います。相手に納得させるという対外的な効果に執着して躍起になっていた自分が恥ずかしくなります。内面と向き合って成長という軸で勝敗を考えられるというのは、なかなかできることではないと思います。

ただ、得るものがあったから勝ちというのは、ちょっと短絡かもしれません。野球の試合で 1 対 3 という得点で試合が終了したとき「1点取った(得るものがあった)から勝ちだ」と言えるでしょうか。「3点失った」ということにも目を向けなくては成長できないと思います。

これは、私との対決という図式ではなく がるがるさんの内面の話として、本当に老婆心ながら申し上げるのですが･･･。がるがるさんは、この議論でなにかを失ってはいないでしょうか？

masa さんの「今まではとても〜」という言葉を聞いても、態度を改めないところをみると、がるがるさん自身は気付いていないのかもしれませんが、私は、がるがるさんがこの議論で目に見えない大切なモノをたくさん失ったのではないかととても心配しています。

積み上げてきた信頼を失わぬよう大切にしてください。その第一歩が責任ある発言だと私は考えています。
ぼのぼの
ぬし
会議室デビュー日: 2004/09/16
投稿数: 544
投稿日時: 2005-11-11 12:54
こんにちは。
一連の流れ、興味深く読ませて頂きました。
しかし、長い… orz 結局何がベストな解なのかわかりません。
ちょっと私なりにまとめてみます。

■前提とする要件
  • 処理１：状態Aと状態Bがあり、両方の状態を満たしている時正常処理をする。どちらか満たしていなければ処理を中断し、適切なエラー処理を行う。（スレ主の最初の質問）
  • 処理２：状態Aと状態Bがあり、どちらかを満たしていればそれに応じた正常処理をする。どちらも満たしていなければ処理を中断し、エラー処理を行う。（臨時承認、代理承認etcの例だとこっち）
  • 現時点では状態はAとBの2つだが、将来的にC,Dと増える可能性がある。

この要件を、try〜catch, boolean, enumが使える言語で、機能拡張時に修正漏れを作り込みづらい（修正箇所が分散しない、或いは修正漏れを発見しやすい）ように実装する方法は、んあ〜！（トリビアの種風に）

■候補（私なりに考えてみました。他にあればご指摘ください。）
(1)void型のcheckA, checkBメソッドを作り、それぞれ業務例外により異常を通知。
(2)boolean型のcheckA, checkBメソッドを作り、それぞれ戻り値により正否を通知。
(3)checkAとcheckBを統合したvoid型のcheckメソッドを作り、業務例外により異常を通知。
(4)checkAとcheckBを統合したenum型のcheckメソッドを作り、戻り値により状態を通知。
(5)checkAとcheckBを統合したvoid型のcheckメソッドを作り、checkメソッドが属するクラスの別メソッドにより状態を通知

■流れ
[1](2)前提で使う側をどのように実装すると良いかというのが当初の質問。これは早々に結論が出る。
[2](1)(3)(4)等、他の候補が出てきてそん中でそれが良いかという議論に置き換わる。
[3]更に(5)の候補が出てきて、この方法が良いか悪いかという議論に置き換わる。
[4]更に、(5)の別メソッドの戻り値がbooleanで、booleanの表す真偽値がどこまで信用できるかという議論に置き換わる。

概ねこんな流れだと思うのですが。
私は議論に参加してなかったので、横槍だというのは承知の上で一言言わせて頂くと、[4]の結論が出てもあまり嬉しくないです。むしろ結論出て欲しいのは[2]なんですが。こっちに流れを戻して頂くわけにはいかないでしょうか？
ラフィン
ぬし
会議室デビュー日: 2002/05/23
投稿数: 809
お住まい・勤務地: 外野
投稿日時: 2005-11-11 13:22
引用:

■前提とする要件
  • 処理１：状態Aと状態Bがあり、両方の状態を満たしている時正常処理をする。どちらか満たしていなければ処理を中断し、適切なエラー処理を行う。（スレ主の最初の質問）
  • 処理２：状態Aと状態Bがあり、どちらかを満たしていればそれに応じた正常処理をする。どちらも満たしていなければ処理を中断し、エラー処理を行う。（臨時承認、代理承認etcの例だとこっち）
  • 現時点では状態はAとBの2つだが、将来的にC,Dと増える可能性がある。

この要件を、try〜catch, boolean, enumが使える言語で、機能拡張時に修正漏れを作り込みづらい（修正箇所が分散しない、或いは修正漏れを発見しやすい）ように実装する方法は、んあ〜！（トリビアの種風に）

■候補（私なりに考えてみました。他にあればご指摘ください。）
(1)void型のcheckA, checkBメソッドを作り、それぞれ業務例外により異常を通知。
(2)boolean型のcheckA, checkBメソッドを作り、それぞれ戻り値により正否を通知。
(3)checkAとcheckBを統合したvoid型のcheckメソッドを作り、業務例外により異常を通知。
(4)checkAとcheckBを統合したenum型のcheckメソッドを作り、戻り値により状態を通知。
(5)checkAとcheckBを統合したvoid型のcheckメソッドを作り、checkメソッドが属するクラスの別メソッドにより状態を通知


　とりあえず(5)。

［checkメソッドが属するクラスの別メソッド］は
・boolean型のis_処理１いってよし
・boolean型のis_処理２いってよし
の２つにしとくのがよいように思います。
コナン
ベテラン
会議室デビュー日: 2005/01/31
投稿数: 98
投稿日時: 2005-11-11 15:04
こんにちわ。

引用:

ぼのぼのさんの書き込み (2005-11-11 12:54) より:

処理１と処理２って要件としては全く別物だと思うんですけど、一緒にする必要ってあるんですか？

処理１は「戸締り確認タイプ」で、処理２は「お年玉タイプ」のような気がします。
「お年玉タイプ」は、学生／社会人と、20才未満／20才以上で、
「社会人かつ20才以上の孫にはお年玉をあげない」みたいなイメージです。

戸締り確認タイプなら、チェック項目が増えても各チェック項目の値は
真・偽以外はありえないです。
でもお年玉タイプは、チェックする項目数だけでなく、その値も変わる可能性がありますね。
（学生／社会人／ニートとか）

素朴な疑問でごめんなさい。
ぼのぼの
ぬし
会議室デビュー日: 2004/09/16
投稿数: 544
投稿日時: 2005-11-11 16:11
引用:

コナンさんの書き込み (2005-11-11 15:04) より:

処理１と処理２って要件としては全く別物だと思うんですけど、一緒にする必要ってあるんですか？


一緒にする必要はないんですけど、これまでの流れをまとめようとしたらで両方出てきてたもんで(^^;
コナンさんの言葉を借りると、一番最初にスレ主さんが示した例が「戸締り確認タイプ」で、途中で出てきた承認云々の例は「お年玉タイプ」なのかなあ、と。
で、せっかく「全く別物の」二つの事例が出てきたんで、両方に対して結論が出た方がいいかな？と思って両方のっけました。

なので処理１なら(3)、処理２なら(5)みたいな考え方もありだと思います。
Tdnr_Sym
ぬし
会議室デビュー日: 2005/09/13
投稿数: 464
お住まい・勤務地: 明石・神戸
投稿日時: 2005-11-11 16:15
こんにちは。

またまた話の脱線で恐縮です。
（個人的には、あまり話しの流れに興味がないもので(~_~;)　）

引用:

未記入さんの書き込み (2005-11-11 11:41) より:
引用:

数学でいう逆とか不完全性定理とかそーゆー面倒なジャンルに突入してしまうのです

チラ見せキーワードで終わらせずに、このあたりもうちょっと丁寧に説明していただけませんか？ 面倒といって説明を怠っていては、それこそ議論になりませんよ？ 数学に弱い私のアタマで、その不完全性定理を理解できるかどうか分かりませんが、よろしくお願いします。


たしか「ゲーデルの不完全性定理」ですね。
私も学生の頃、ブルーバックスの本で読んだ記憶がありますが
今から１５年位前のことで、うる覚えなのですが、
確か、数学的アプローチで「ある理論が完全であることを証明することはできない」ということを（偶然に）証明してしまったんじゃなかったでしたっけ！？
なんか哲学的に通じる定理ですね。「完全な理屈なんてない（というか証明できない）」ってな、感じだったと思います。
＃私は理系でしたが数学専攻じゃなかったので、詳しいことはよく分からなかったです。

なんだか物理で習った「ハイゼンベルクの不確定性原理」のように、
”どんなに頑張っても限界がある”と予言（証明）した原理に似ているなぁと思っていた記憶があります。

＃なぜこのスレで「不完全性定理」の話が出てきたのかは、分かりませんけれども(~_~;)


【余談】
ハイゼンベルクやシュレディンガー達の確立した量子論がなければ、現代のような科学技術の発展はなかったでしょうね。
コンピュータも例外ではないですね。半導体技術に量子論は不可欠ですから。


[ メッセージ編集済み 編集者: Tdnr_Sym 編集日時 2005-11-11 16:50 ]
ラフィン
ぬし
会議室デビュー日: 2002/05/23
投稿数: 809
お住まい・勤務地: 外野
投稿日時: 2005-11-11 16:35
引用:

なので処理１なら(3)、処理２なら(5)みたいな考え方もありだと思います。

　おっ、処理１と処理２は And でなく Or ですか。

　であれば、処理１なら(3)、処理２なら(5)でよさげに思います。
　好みで言うと共に戻り値はboolean型で「ダメ」をまず実装しておきたいですが．．．

# 最初の返答時には、処理２の”それに応じた”を見逃しておりました。
コナン
ベテラン
会議室デビュー日: 2005/01/31
投稿数: 98
投稿日時: 2005-11-11 17:04
引用:

ぼのぼのさんの書き込み (2005-11-11 16:11) より:

一緒にする必要はないんですけど、これまでの流れをまとめようとしたらで両方出てきてたもんで(^^;
コナンさんの言葉を借りると、一番最初にスレ主さんが示した例が「戸締り確認タイプ」で、途中で出てきた承認云々の例は「お年玉タイプ」なのかなあ、と。
で、せっかく「全く別物の」二つの事例が出てきたんで、両方に対して結論が出た方がいいかな？と思って両方のっけました。

なので処理１なら(3)、処理２なら(5)みたいな考え方もありだと思います。

了解しました
#でもオブジェクト指向のことはよく分からないので、投票は控えさせていただきます…。

引用:

Tdnr_Symさんの書き込み (2005-11-11 16:15) より:

たしか「ゲーデルの不完全性定理」ですね。
私も学生の頃、ブルーバックスの本で読んだ記憶がありますが
今から１５年位前のことで、うる覚えなのですが、
確か、数学的アプローチで「ある理論が完全であることを証明することはできない」ということを（偶然に）証明してしまったんじゃなかったでしたっけ！？
なんか哲学的に通じる定理ですね。「完全な理屈なんてない（というか証明できない）」ってな、感じだったと思います。
＃私は理系でしたが数学専攻じゃなかったので、詳しいことはよく分からなかったです。

哲学的な解釈はいろいろあるようですが、数学としてゲーデル数だけ見ても味わい深いというか、
恐るべしです
«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）