水位予測 using deep learning その3

Nan を回避するのに、はまりました。
前回のUPから5日かかっていますね。

原因はやはり「0」と関数の定義の2種のようです。
ただ、コードの思いつく箇所を修正してもダメ。場当たり的な回避方法は見つけましたが、根本的な対処法はいまだわからず。まだ、Pythonを理解し始めたばかりですので、どこか記述の仕方を誤っているのだと思います。プロが傍に欲しいですね。

まず、関数定義の異常について。
def 内で雨量を読み込ませると、それを計算に使用しなくてもNanを吐きます。最初はVSのバグかと思い、それを経由させずに直接 Python で走らせてみました。すると、より多くのエラーが吐き出されました。
まず、関数を認識しません。インデントがおかしいと、吐き出されます。スペースとタブが混在していたため、そこがおかしいのだろうとタブに統一（今まで、適当に扱ってきたところです）。
次は、関数の終わりを認識してくれません。次の行まで関数として認識されます。これは1行開けることで問題なく修正できました。
さらに、def  内で配列を加算させていたのですが、これもダメなようです。データを読み込む前にEXCELで計算させてcsvを作り、そのファイルを読み込むとNanを吐きません。一方、def 内での加算を使うと、Nanを吐きます。両者を比べても全く同じ値・並びになっているのですが、なぜか後者だけNanを吐きます。理解できません。

「0」に関しては、まず一番に疑っていたのですが、前回、適当な数値を def 内で足しても Nan を吐いていましたので検討から外していました（前回は加算の方で引っかかっていたようですが）。
しかし、0にいくら重み係数をかけても0でしょうから、やはり調整は難しいのでしょう。
対処法は先にEXCEL内で雨量に0.01mmを加算しておくという場当たり的なもの。これを直接読み込めばNan は吐き出されなくなりました。

で、計算！

が結果が悪い。

2層ほど追加してみましたが、予測形状は変わりません。ま、あたりまえの結果ですね。
過去24時間の雨量データを使っていますので、雨量のない日は一律0.01mmになります。それ以上の長期雨量は考慮されませんので、基底がフラットな形状に近くなるという訳でしょう。実効雨量に半減期の考え方が取り入れられているのも、こういったフラットな形状を回避するためなのでしょうね。違うツールを使って初めて気づくその工夫。思いつかれた方は凄いとあらためて感心。

で、使用するデータを過去24時間から240時間に変更。

ダメでしょう。これは。

もう少しケース数を増やさないと結論は出せませんが、雨量のみから水位を推定するのは得策ではないようです。複数期間の実効雨量から deep learning を使って推定するのは特許に引っかかりそうですし、それなら今まで通り実効雨量と回帰分析で十分です。これは、雨量と水位から推定させる方針にした方が良いのでしょうか？そうなると、井戸の枯渇が施工の影響かどうか？といったような問題には適用できなくなりますが。うーん。