  |
はてなキーワード: 変数とは
変数だの関数だのの命名の社内ルールを守らないやつがいたら、1秒でも早く退社して欲しい。
実際の感染者数＝822人、私の予測＝823人。ほぼ的中っす。惜しかったっす。
| 評価期間 | Knoa氏平均 | 私の平均 | 実際の平均 | 勝敗 | コメント |
|---|---|---|---|---|---|
| 7/6-7/9 | 910.75 | 815.25 | 807.25 | 圧勝っす | Knoa氏誤差=103.5人 vs. 私の誤差=8人 |
| 曜日 | Knoa氏予測 | 私の予測 | 実際の感染者数 | 勝敗 | コメント |
|---|---|---|---|---|---|
| 7/6 (火) | 705 | 642 | 593 | 1勝0敗 0分 | 楽勝っす。明日も楽しみっす。 |
| 7/7 (水) | 1031 | 982 | 920 | 2勝0敗 0分 | 楽勝っす。明日も楽しみっす。 |
| 7/8 (木) | 962 | 814 | 894 | 2勝1敗 0分 | 14人差でまさかの惜敗っす。明日こそ勝ち越しを決めるっす。 |
| 7/9 (金) | 945 | 823 | 822 | 3勝1敗 0分 | 完勝っす。とりあえず勝ち越し確定っす。 |
| 7/10 (土) | 967 | 967 | ？ | 3勝1敗 1分 | 引き分けっす。この日は絶対引き分けっす。 |
| 7/11 (日) | 699 | 702 | ？ | ?勝?敗 1分 |
しつこいけど、専門家なら誰もが考慮しているあのデータをきちんと考慮してないというのがあなたの問題だと思うの。
あなたの予測が一貫して常に上ずれしてハズレた値になってしまっているのは、そういうことだと思うの。そのハズレ方は誤差じゃないと思うの。
（Knoa氏の「予測の説明」を読んでも説明変数の記述ばかりで、モデルの記述がまったくないから、今はこのくらいしか言えないの。）
※ 7月9日、ほぼ的中。すでに御祝いの言葉を下さった増田様ありがとうございます。何かうれしい。
ｔ時点のデータが明らかにｔー１時点のデータに影響を受けていて単位根があることが濃厚な新規の感染者（前週比でも依然として単位根があると思われる）と人流のデータを使って回帰モデルを作る場合、その単位根の存在に留意した上で問題ない回帰分析の手法を採用しなければならないのに、当て嵌まりがいいからと何も考えずにそのまま回帰やってそうな時点であの予測はもう当たるも八卦当たらぬも八卦の世界の数字に過ぎないよ。統計的妥当性はおそらく（もしかしたら明記していないだけで実際には考慮している可能性があるからの"おそらく"）無い。挑戦者氏が説明変数の記述ばかりでモデルの記述がまったくないって指摘しているけど、その説明変数や被説明変数の記述でさえ、どんなdata generating processと見ているかまで記述していないので不十分。
| 曜日 | Knoa氏予測 | 私の予測 | 実際の感染者数 | 勝敗 | コメント |
|---|---|---|---|---|---|
| 7/6 (火) | 705 | 642 | 593 | 1勝0敗 0分 | 楽勝っす。明日も楽しみっす。 |
| 7/7 (水) | 1031 | 982 | 920 | 2勝0敗 0分 | 楽勝っす。明日も楽しみっす。 |
| 7/8 (木) | 962 | 814 | 894 | 2勝1敗 0分 | 14人差でまさかの惜敗っす。明日こそ勝ち越しを決めるっす。 |
| 7/9 (金) | 945 | 823 | ？ | ?勝?敗 0分 | |
| 7/10 (土) | 967 | 967 | ？ | ?勝?敗 1分 | 引き分けっす。この日は絶対引き分けっす。 |
| 7/11 (日) | 699 | 702 | ？ | ?勝?敗 1分 |
| 評価期間 | Knoa氏平均 | 私の平均 | 実際の平均 | 勝敗 | コメント |
|---|---|---|---|---|---|
| 7/6-7/8 | 899.3 | 812.7 | 802.3 | 圧勝っす | Knoa氏誤差=97.0 vs. 私の誤差=10.3 |
【感想】
しつこいけど、専門家なら誰もが考慮しているあのデータをきちんと考慮してないというのがあなたの問題だと思うの。
あなたの予測が一貫して常に上ずれしてハズレた値になってしまっているのは、そういうことだと思うの。そのハズレ方は誤差じゃないと思うの。
（Knoa氏の「予測の説明」を読んでも説明変数の記述ばかりで、モデルの記述がまったくないから、今はこのくらいしか言えないの。）
変数や構文などのプログラミングの基礎は覚えた人向けに、ソースコードを書くときのコツを紹介していきます。どれも今日から実践できるものばかりです。他のプログラマと差をつけることができる技術ですので、ぜひ意識するようにして下さい。良い子はまねしないで下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、その利便性からプログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
使う前の印象はヤフー知恵袋並にマトモな回答が来ないと思っていたが、
割としっかり質問の意図を汲み取り、補足までつけてくれて驚いた。
ちょっと踏み込んだ内容だと回答は来なくなるけど、新しいライブラリを使う入り口として使うのも悪くないのかなと思った。
m.ts10806に会うまでは。
どう検索しても1つしかないページのurlを要求してくる辺り怪しいと思った。
んで、少し小馬鹿にされたのでコイツ調べると初心者にバンバン回答してたの見て、
パッと見て適当に回答してるやつだと分かった。
プログラミングの回答って、変数宣言の仕方並の質問じゃないとバンバン回答できるものだと思えないので。
teratailを使う際には中級レベルより上の質問を出したほうがいい。（回答が来るのは期待しないほうがいい）
簡単そうな内容の質問だと、やった事も使ったこともないのに適当な憶測をほざく上位ランカーがいるので。
質問が糞だと言われてることも多いが、それに突っかかる回答者の方がキチなので質問が来なければ考え編集し、回答が来るのを待とう。
わざわざ質問に指摘するやつは総じてゴミなので気にしないこと。
しっかりヒアリングして、質問者に分からないことは質問し、優しく丁寧な答えを導き出す人が本物の技術者だと思ってる。
にしてもこいつムカつくな。
ブロックできんのか