C# と VB.NET の質問掲示板
ASP.NET、C++/CLI、Java 何でもどうぞ
掲示板トップ
C# と VB.NET 入門
新規作成
利用方法
ツリー表示
トピック表示
ランキング
記事検索
過去ログ
ログ内検索
キーワードを複数指定する場合は 半角スペース で区切ってください。
検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
[返信]をクリックすると返信ページへ移動します。
キーワード
/
検索条件
/
(AND)
(OR)
検索範囲
/
(現在のログ)
(全過去ログ)
(過去ログ1)
(過去ログ2)
(過去ログ3)
(過去ログ4)
(過去ログ5)
(過去ログ6)
(過去ログ7)
(過去ログ8)
(過去ログ9)
(過去ログ10)
(過去ログ11)
(過去ログ12)
(過去ログ13)
(過去ログ14)
(過去ログ15)
(過去ログ16)
(過去ログ17)
(過去ログ18)
(過去ログ19)
(過去ログ20)
(過去ログ21)
(過去ログ22)
(過去ログ23)
(過去ログ24)
(過去ログ25)
(過去ログ26)
(過去ログ27)
(過去ログ28)
(過去ログ29)
(過去ログ30)
(過去ログ31)
(過去ログ32)
(過去ログ33)
(過去ログ34)
(過去ログ35)
(過去ログ36)
(過去ログ37)
(過去ログ38)
(過去ログ39)
(過去ログ40)
(過去ログ41)
(過去ログ42)
(過去ログ43)
(過去ログ44)
(過去ログ45)
(過去ログ46)
(過去ログ47)
(過去ログ48)
(過去ログ49)
(過去ログ50)
(過去ログ51)
(過去ログ52)
(過去ログ53)
(過去ログ54)
(過去ログ55)
(過去ログ56)
(過去ログ57)
(過去ログ58)
(過去ログ59)
(過去ログ60)
(過去ログ61)
(過去ログ62)
(過去ログ63)
(過去ログ64)
(過去ログ65)
(過去ログ66)
(過去ログ67)
(過去ログ68)
(過去ログ69)
(過去ログ70)
(過去ログ71)
(過去ログ72)
(過去ログ73)
(過去ログ74)
(過去ログ75)
(過去ログ76)
(過去ログ77)
(過去ログ78)
(過去ログ79)
(過去ログ80)
(過去ログ81)
(過去ログ82)
(過去ログ83)
(過去ログ84)
(過去ログ85)
(過去ログ86)
(過去ログ87)
(過去ログ88)
(過去ログ89)
(過去ログ90)
(過去ログ91)
(過去ログ92)
(過去ログ93)
(過去ログ94)
(過去ログ95)
(過去ログ96)
(過去ログ97)
(過去ログ98)
(過去ログ99)
(過去ログ100)
(過去ログ101)
(過去ログ102)
(過去ログ103)
(過去ログ104)
(過去ログ105)
(過去ログ106)
(過去ログ107)
(過去ログ108)
(過去ログ109)
(過去ログ110)
(過去ログ111)
(過去ログ112)
(過去ログ113)
(過去ログ114)
(過去ログ115)
(過去ログ116)
(過去ログ117)
(過去ログ118)
(過去ログ119)
(過去ログ120)
(過去ログ121)
(過去ログ122)
(過去ログ123)
(過去ログ124)
(過去ログ125)
(過去ログ126)
(過去ログ127)
(過去ログ128)
(過去ログ129)
(過去ログ130)
(過去ログ131)
(過去ログ132)
(過去ログ133)
(過去ログ134)
(過去ログ135)
(過去ログ136)
(過去ログ137)
(過去ログ138)
(過去ログ139)
(過去ログ140)
(過去ログ141)
(過去ログ142)
(過去ログ143)
(過去ログ144)
(過去ログ145)
(過去ログ146)
(過去ログ147)
(過去ログ148)
(過去ログ149)
(過去ログ150)
(過去ログ151)
(過去ログ152)
(過去ログ153)
(過去ログ154)
(過去ログ155)
(過去ログ156)
(過去ログ157)
(過去ログ158)
(過去ログ159)
(過去ログ160)
(過去ログ161)
(過去ログ162)
(過去ログ163)
(過去ログ164)
(過去ログ165)
(過去ログ166)
(過去ログ167)
(過去ログ168)
(過去ログ169)
(過去ログ170)
(過去ログ171)
(過去ログ172)
(過去ログ173)
(過去ログ174)
(過去ログ175)
(過去ログ176)
(過去ログ177)
(過去ログ178)
(過去ログ179)
強調表示
/
ON
(自動リンクOFF)
結果表示件数
/
20件
30件
40件
50件
100件
記事No検索
/
ON
大文字と小文字を区別する
全過去ログを検索
ヒット / 731件
(41-60 を表示)
ヒット件数が多いので過去ログ1〜119 までの検索結果 /
過去ログ120からさらに検索→
<<
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
29
|
30
|
31
|
32
|
33
|
34
|
35
|
36
>>
■20140
Re[1]: 検索プログラムについて
□投稿者/ 凪瀬 -
(2008/06/06(Fri) 15:44:50)
>
■
No20138
(名無し さん) に返信
> (LinkedListと入力すると、Linked.classしか検索して表示されない)
「LinkedList.class」かな?
> 入力されたクラス名の全文一致検索しかできないので
> 部分一致検索に切り替えたいのですが、何かいい方法はないでしょうか。
パフォーマンス抜きに単純にやるならば、Map#entrySet()でEntryを取得して、
ループですべてのEntryのキーと部分一致するかを正規表現なりでチェックするということになるでしょうか。
クラス名をキーにMapからgetするのに比べたらパフォーマンスは落ちますが、
たかだか数百とか程度のオーダーのデータなら問題にならないんじゃないかな。
記事No.20138 のレス /過去ログ39より /
関連記事表示
削除チェック/
■20182
Re[2]: 検索プログラムについて
□投稿者/ 名無し -
(2008/06/07(Sat) 09:51:19)
■
No20140
(凪瀬 さん) に返信
> ■
No20138
(名無し さん) に返信
>>(LinkedListと入力すると、Linked.classしか検索して表示されない)
> 「LinkedList.class」かな?
>
>>入力されたクラス名の全文一致検索しかできないので
>>部分一致検索に切り替えたいのですが、何かいい方法はないでしょうか。
>
> パフォーマンス抜きに単純にやるならば、Map#entrySet()でEntryを取得して、
> ループですべてのEntryのキーと部分一致するかを正規表現なりでチェックするということになるでしょうか。
>
> クラス名をキーにMapからgetするのに比べたらパフォーマンスは落ちますが、
> たかだか数百とか程度のオーダーのデータなら問題にならないんじゃないかな。
>
記事No.20138 のレス / END /過去ログ39より /
関連記事表示
削除チェック/
■20259
Re[3]: 検索プログラムについて
□投稿者/ 倉田 有大 -
(2008/06/08(Sun) 21:26:32)
■
No20182
(名無し さん) に返信
> ■
No20140
(凪瀬 さん) に返信
>>■
No20138
(名無し さん) に返信
> >>(LinkedListと入力すると、Linked.classしか検索して表示されない)
>>「LinkedList.class」かな?
>>
> >>入力されたクラス名の全文一致検索しかできないので
> >>部分一致検索に切り替えたいのですが、何かいい方法はないでしょうか。
>>
>>パフォーマンス抜きに単純にやるならば、Map#entrySet()でEntryを取得して、
>>ループですべてのEntryのキーと部分一致するかを正規表現なりでチェックするということになるでしょうか。
>>
>>クラス名をキーにMapからgetするのに比べたらパフォーマンスは落ちますが、
>>たかだか数百とか程度のオーダーのデータなら問題にならないんじゃないかな。
>>
この引用だけ返信は失礼とおもうのですが、わたしだけかいな。
記事No.20138 のレス / END /過去ログ39より /
関連記事表示
削除チェック/
■20141
Re[8]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ じゅで -
(2008/06/06(Fri) 15:47:45)
・要員の再配置
・残業すれば出来る事は出来ない事にする。
・PMやPLが注視しなければならないワークパッケージを明確にする。
(他は多少おくれても問題ないのは悪い言い方をするとほっとく)
・コアな部分は、内部の出来る人に任せる。外だししない。
・新人などを、人数に数えて、工数と照らし合わせて作業分担をしない。
・お客さんの要望を吸い出す人間とクラスなどの詳細設計を行う人間は、
必要なスキルが違うので、明確に分ける。
・上司は、実装部分に口を出さない。必要であれば、技術力のある人間をつれて
客先につれていく。
(お客さんにできない事は出来ないといえるような仕事をとるのが一番ですorz)
まだまだ色々あるでしょうが、長くかいてたら送信できなかったので、
短くしてみましたorz
記事No.20108 のレス /過去ログ39より /
関連記事表示
削除チェック/
■20142
Re[12]: ディレクトリの排他アクセス
□投稿者/ れい -
(2008/06/06(Fri) 15:50:45)
お。
お返事が。
■
No20137
(す さん) に返信
> ■
No20105
(れい さん) に返信
>>つまり、今現在適切にファイルIOを処理をしているプログラムにとっては、
>>ディレクトリの排他ロックが可能であってもコード量は変化しません。
>>大変なことにはなりません。
>
> そんなことはありません。エラーの発生状況や頻度が変われば、
> 対処も変えなければなりません。
んー。そうですね。
共有違反の頻度が激しく上がるなら、
根本的に変えなきゃいけない場合もありえると思いますが…
> なら、予想より実際に試してみたほうが早いのでは?
それがですね。
一応やってみてはいるんですが…確かなことが言えないのです。
確かにユーザーフォルダとかをロックすると多少困りはしますが、
エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。
乱用しまくると確かに邪魔ですが、ファイルロックの乱用も同様に邪魔です。
それと比べてどのくらい邪魔なのか、どう比較するのかわかりません。
どこまで行儀の悪いプログラムを考慮するべきかというのもよくわからない要素の一つで。
最悪プロセスを殺せばいいわけですが、
それをどの程度重く考えるべきなのかも人や状況によって違います。
条件が複雑で曖昧なので、
普通に考えて全然問題ない、とも言えず、
普通に考えてロックがうざくて使えない、とも言えないなぁと。
微妙な感じです。
OSは結構な頻度でディレクトリを「共有書き込み禁止」で開いてますが、
邪魔になることは普通ありませんよね?
それはアクセスが細切れになってるから邪魔じゃないのか、
邪魔にならないようにシステムが調節してるのか、
そもそもディレクトリロックはそれほど邪魔じゃないのか。
いろいろ試したのですが、自信を持って言えるほど十分に試せませんでした。
#予想としては困らないと思うんですが…。
私が気づいていない致命的欠陥があったり、何か大切なところで勘違いしてたり、
そういうことがありそうなのでここで皆さんの知恵をお借りしたいと。
> そんなことはないと思います。同時実行性が相当損なわれると思います。
排他でアクセスできるようなシステムだと「同時実行性が相当損なわれる」ような状況というのは
どのような状況でしょうか?
まさにそれが、知りたい所です。
記事No.19998 のレス /過去ログ40より /
関連記事表示
削除チェック/
■20143
Re[13]: ディレクトリの排他アクセス
□投稿者/ す -
(2008/06/06(Fri) 16:07:49)
■
No20142
(れい さん) に返信
> エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。
ん? そういうモデルじゃロックの意味がないでしょ?
ふつう、エントリを列挙して、アプリが何か処理して、エントリを書き込みするまで
の間書き込み禁止するからロックの意味があるのでは?
こういうモデルだと、相当長い期間ロックされるので、相当困ったことになると
思いますが。
記事No.19998 のレス /過去ログ40より /
関連記事表示
削除チェック/
■20145
Re[14]: ディレクトリの排他アクセス
□投稿者/ れい -
(2008/06/06(Fri) 16:36:36)
■
No20143
(す さん) に返信
> ■
No20142
(れい さん) に返信
>>エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。
>
> ん? そういうモデルじゃロックの意味がないでしょ?
なぜでしょう?
少なくともエントリの列挙中にエントリが削除されたり追加されたりしなくなる、という意味がありますが。
> ふつう、エントリを列挙して、アプリが何か処理して、エントリを書き込みするまで
> の間書き込み禁止するからロックの意味があるのでは?
おやや?
それが「ふつう」だと考えるのですか。
では す さんは「ディレクトリのロック」と聞いたときに、
ディレクトリ内の整合性をとるための機能だと思うわけですね?
NyaRuRuさんが示したTxFで実現されてるような機能を想像しているということですね。
なるほど。
「ロック」とばかり言っていたので誤解を招いたようですが、
■
No19998
(れい さん) に返信
> Windowsでファイルを開くとき、共有モードやアクセス権を設定して開きます。
> 共有しないと設定してファイルを開けば、
> 他のプロセスからファイルが削除されたり変更されたりすることがないという前提でプログラムを作れます。
>
> ですが、ディレクトリを扱う場合はこれができません。
上記のように、ロックはロックでも、「同一プロセスからしか書き込めない」というロックではなく、
「共用アクセス制御」の方のロックを話題にしていました。
.Net的に言うなら、「FileShare」の話です。
一応誤解ないように書いておきますが、
「FileStream.Lock」のようなロックはディレクトリにはありません。
APIにもありませんし、Windows内部にもありません。
ディレクトリのアクセス制御といったときにどんなアクセス制御の話をしてるのかよくわからない、
というのもアクセス制御がない理由の一つかもしれないですねぇ。
記事No.19998 のレス /過去ログ40より /
関連記事表示
削除チェック/
■20146
Re[15]: ディレクトリの排他アクセス
□投稿者/ す -
(2008/06/06(Fri) 17:12:36)
■
No20145
(れい さん) に返信
> なぜでしょう?
> 少なくともエントリの列挙中にエントリが削除されたり追加されたりしなくなる、という意味がありますが。
そんなのに何か価値があります?
エントリを列挙し終えてロックが外れた瞬間、エントリが削除されたり追加されたり
するのと、大して違いませんが。。。
>>ふつう、エントリを列挙して、アプリが何か処理して、エントリを書き込みするまで
>>の間書き込み禁止するからロックの意味があるのでは?
>
> おやや?
> それが「ふつう」だと考えるのですか。
おや、違うんですか?
例えば、エントリを列挙して、アプリが何かの条件でエントリを絞り込んで、
それを削除か更新しようとしたら、先に誰かが削除してた、とかいうシナリオを
想定したのですが。。。
記事No.19998 のレス /過去ログ40より /
関連記事表示
削除チェック/
■20148
Re[16]: ディレクトリの排他アクセス
□投稿者/ れい -
(2008/06/06(Fri) 17:41:20)
■
No20146
(す さん) に返信
> ■
No20145
(れい さん) に返信
>>なぜでしょう?
>>少なくともエントリの列挙中にエントリが削除されたり追加されたりしなくなる、という意味がありますが。
>
> そんなのに何か価値があります?
> エントリを列挙し終えてロックが外れた瞬間、エントリが削除されたり追加されたり
> するのと、大して違いませんが。。。
No20027
あたりで書いてますが、
ファイルシステムを利用する側からみると大していいことはありません。
ハンドルを開いている間はエントリの重複も抜けもチェックしなくてよいとか、
エントリの属性を適用する際に整合性を維持することもできるとか。
>>それが「ふつう」だと考えるのですか。
> おや、違うんですか?
私には「ふつう」どう考えるのかはわかりませんので、違うかどうかはわかりませんが、
それを す さんが「ふつう」と捉えているというのはちょっと興味深いです。
> 例えば、エントリを列挙して、アプリが何かの条件でエントリを絞り込んで、
> それを削除か更新しようとしたら、先に誰かが削除してた、とかいうシナリオを
> 想定したのですが。。。
ふむふむ。
やはりディレクトリ内での整合性の維持、ということですね。
読み直してみるに、シャノンさんもそう捉えていたということかしら。
「ディレクトリのロック」とだけ言うと、
そう捉える人は少なからず居るようですね。
「ディレクトリの共用アクセス制御」と厳密に表現したほうが良さそうですね。
記事No.19998 のレス /過去ログ40より /
関連記事表示
削除チェック/
■20151
Re[17]: ディレクトリの排他アクセス
□投稿者/ す -
(2008/06/06(Fri) 18:17:11)
■
No20148
(れい さん) に返信
> ファイルシステムを利用する側からみると大していいことはありません。
それが、れいさんが欲してた「理由」なのでは?
> ハンドルを開いている間はエントリの重複も抜けもチェックしなくてよいとか、
抜けはチェックの仕様がないような。
重複のチェックは可能だけど、必要なのは場合によりけりだし。
> エントリの属性を適用する際に整合性を維持することもできるとか。
どういうことでしょう?
> やはりディレクトリ内での整合性の維持、ということですね。
> 読み直してみるに、シャノンさんもそう捉えていたということかしら。
>
> 「ディレクトリのロック」とだけ言うと、
> そう捉える人は少なからず居るようですね。
ロックで、整合性以外に思い浮かぶものがないんですけど。。。
> 「ディレクトリの共用アクセス制御」と厳密に表現したほうが良さそうですね。
と言われても、共用アクセス制御って知らないですけど。。。
MSDNライブラリで引いても出て来ないし。。。
記事No.19998 のレス /過去ログ40より /
関連記事表示
削除チェック/
■20150
Re[17]: ディレクトリの排他アクセス
□投稿者/ シャノン -
(2008/06/06(Fri) 18:06:41)
2008/06/06(Fri) 18:08:41 編集(投稿者)
■
No20148
(れい さん) に返信
出来ても何が嬉しい訳でもないけれど、そうなっている方が自然だと思う、ってことですかね?
<追記>
> 上記のように、ロックはロックでも、「同一プロセスからしか書き込めない」というロックではなく、
> 「共用アクセス制御」の方のロックを話題にしていました。
> .Net的に言うなら、「FileShare」の話です。
これはよくわかんなかったです。
FileShare.None を指定すれば、同一プロセスからしか書き込めなくなると思いますが。
(同一プロセスからさえ、別ハンドル経由では書き込めませんけど)。
</追記>
記事No.19998 のレス /過去ログ40より /
関連記事表示
削除チェック/
■20144
Re[12]: ディレクトリの排他アクセス
□投稿者/ ネタ好き -
(2008/06/06(Fri) 16:10:28)
>エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。
これは正しいと思います。DBでも読み込み可、書き込み禁止のロックは一般的です。
記事No.19998 のレス /過去ログ40より /
関連記事表示
削除チェック/
■22014
Re[18]: わんくま同盟勉強会 福岡#2 検討スレッド
□投稿者/ さかもと -
(2008/07/15(Tue) 09:01:43)
宣伝エントリを上げようかと思いますが、(仮)ということでスピーカー各位のお名前を出しても良いものでしょうか?
記事No.21522 のレス /過去ログ44より /
関連記事表示
削除チェック/
■22019
Re[19]: わんくま同盟勉強会 福岡#2 検討スレッド
□投稿者/ うつせみ(虚蝉) -
(2008/07/15(Tue) 09:38:21)
■
No22014
(さかもと さん) に返信
5名のスピーカーの方々はかまわないと思います。
(確定ですよね?ね?)
そろそろ一ヶ月前ということで締めですよね。
記事No.21522 のレス /過去ログ44より /
関連記事表示
削除チェック/
■22055
Re[20]: わんくま同盟勉強会 福岡#2 検討スレッド
□投稿者/ とっちゃん -
(2008/07/15(Tue) 13:24:39)
>
■
No22019
(うつせみ(虚蝉) さん) に返信
> ■
No22014
(さかもと さん) に返信
> 5名のスピーカーの方々はかまわないと思います。
> (確定ですよね?ね?)
>
> そろそろ一ヶ月前ということで締めですよね。
そうですね。ぼちぼちと順番とかも決めないとですw
というか...今週末までにもろもろ提出です>スピーカー各位&ディレクター
そうしないと募集サイトが開けられなくてあちこちに宣伝が出せません。
スピーカーの顔出しがNGっぽいのは、画伯くらいなので
#他はみんな一度以上顔出ししてるw
なので、画伯が問題なしなら誰も問題にはなりませんw
ちなみに予定では福岡に行く前に E-Mobile が使えるようになってるはず<おいらw
なので、中継は問題なくやれますよ。
あるとしたら、おいらのセッション中にそのマシンでの中継が耐えられるか?
というくらいw
ま、今回はデモはない予定なので、多分大丈夫でしょうw
というか、セッションだけならおいらは自分のマシンじゃなくてもやれるしw
#MISAOはあったほうが面白そうなので、セッティングは必要ですが
記事No.21522 のレス /過去ログ44より /
関連記事表示
削除チェック/
■24265
Re[4]: 見積書作成ソフトを作りたいけどデータベースがわからない
□投稿者/ 堂島ロール -
(2008/08/31(Sun) 09:03:45)
みなさまが経験豊富な上司ならおっしゃるでしょう
「データベースはそれほど難しいものじゃないんだから
データベース勉強してからやっとけ」
ということですよね
ありがとうございました
上記URLも参考にやってみます
記事No.24246 のレス / END /過去ログ45より /
関連記事表示
削除チェック/
■24267
Re[2]: プログラミングの学習法について
□投稿者/ 北圭次 -
(2008/08/31(Sun) 10:30:55)
>「目標を高く持つことです。無謀と思っても絶対にできると信じれば、
>必ず実現します。思い込みこそが力です」
>学習じゃなくて楽習って考えればいいピヨ。
>まー失敗学ですね、いっぱい失敗して欲しい。
>進み続ければ抜けられないトンネルはないので頑張って下さい。
たくさんの力になるお言葉、ありがとうございます。
また、学習法についても詳しくおしえていただき感謝しております。
>Jitta on the wayさんが記載されているような、アプリケーションを作ってみたらいかがでしょう
>か?
はい。チャレンジしてみようと思っています。
今後ともご指導のほどよろしくお願いします。
記事No.24251 のレス / END /過去ログ45より /
関連記事表示
削除チェック/
■24266
Re[1]: プログラマーと栄養ドリンク
□投稿者/ ちわわ -
(2008/08/31(Sun) 09:53:56)
■
No24264
(倉田 有大 さん) に返信
> 会社で働いているとき!
> デスマーチのおとも栄養ドリンク!
> 近くのコンビニで、みんなで買いに行った記憶があります。
> みなさま、何か常用の栄養ドリンクってあります?
>
> ちなみに私は錠剤にかえました。安いので^^;
> キューピーコーワiにしようかなと思ったのですが、有名メーカー品でたかいので、ジャパンで売っている180錠、1800円ぐらいのにしました。
> 一日(2錠まで)
> カフェインははいってないので眠気ははらせませんが〜
>
> ブルーベリーを一年ほど飲み続けましたが。効果わからん〜
> なにげに、ブルーベリーは月に1400円ぐらいするので、ビタミン剤の方がやすいんですよね。
栄養ドリンクは、ほとんど効き目がないそうですよ。
ドリンクを飲んで効いたとしたら、それは薬のプラシーボ効果と同じようなものかもしれません。
ドリンクに入っている成分は、ほとんどが糖分で、それが疲れを一時的にもとってくれる、特に
脳の疲れには糖分が効くそうですね。
私は、そういった健康食品には拒絶反応があるのでほとんど飲んだことがありませんが、
効くと思って飲むのなら、それはそれでよろしのではないかと考えています。
ちなみにプラシーボ効果も薬の薬効だけでなく、効くと思いこむ気持ちが、体を賦活させる未知の
成分を大量に分泌させることもある、という説が、いつか医学的にも証明される日がくるかもしれませんね。
記事No.24264 のレス /過去ログ45より /
関連記事表示
削除チェック/
■25902
Re[2]: CG関連の数学の情報源について
□投稿者/ ごう -
(2008/09/27(Sat) 11:20:14)
■
No25901
(なちゃ さん) に返信
> 幾何の教科書
> 入門系の3DCGプログラミング本
>
こんにちは。
まず行列について勉強されることをお勧めします。
行列演算について理解が出来ればいいので、入門書1冊マスターするぐらいの知識が必要です。
画像処理にまつわるライブラリというのもいくつかありますが(OpenCVなど)
行列をマスターしないと扱えないものが多いんですよね。空間図形になればなおさらです。
行列(幾何)の教科書は、石村園子氏の入門書「すぐわかる線形代数」などのシリーズがおすすめです。
(「行列とは何ぞや?」という文系の方でも、読みやすくとっつきやすい内容かと思います。)
記事No.25900 のレス /過去ログ48より /
関連記事表示
削除チェック/
■32014
Re[6]: C++→C#
□投稿者/ επιστημη
@
-
(2009/01/30(Fri) 18:27:31)
>
> まず答えを求めてそれをじっくり吟味して学習していく方法は間違っているのでしょうか?
それがやれるのは土台がしっかり組みあがってから。
# C++できるんならそんなに難しくないっすよ > C#
記事No.31995 のレス /過去ログ56より /
関連記事表示
削除チェック/
<前の20件
|
次の20件>
<<
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
29
|
30
|
31
|
32
|
33
|
34
|
35
|
36
>>
ヒット件数が多いので過去ログ1〜119 までの検索結果 /
過去ログ120からさらに検索→
パスワード/
-
Child Tree
-