生成AI側の🐼s評価と利用価値の見解を聞いてみた。

前回に引き続き、憶測となると利用価値に損を被ると思った為に、生成AIへpandasの使用方法への指南と私の考え方の相違点を聞いてみたのです。
でもここで心配になったのは、「果たして自分は固定概念に囚われていたのではないか？」ということが気になっていました。
こういった事が打開策と言うか、手段を講じる次の手を考える道筋となります。
そんな実に諦めが悪い私は、前回の処理を何とか分散化処理へつなげる方法が無いか？という思案を巡らせた後、numpy使っての処理軽減打開策ない？と聞いて、、numpy改修の施策としてソース提案してもらった後の会話です。

先ずは大事な事なので断っておきたいことがございます。
申し訳ございませんが、私は決してこういった結果となるソースコードの開示を行おうと思っておりません。
そういった事を期待する方には失礼ながら大変申し訳ございませんが、今すぐにこの記事を閉じてソース開示をされている方の記事へ向かってください<(_ _)>

何故か？と申しますと、コーディングに挑戦しようとする人の向上心や探求心、楽しみを奪ってしまうことが「一番つまらない事」だと思っているからです。
そりゃ動作が完璧な有料無料問わずにソースを与えられて、結果さえあれば非常に楽だし、何も考えなくていい。
私はプロフェッショナルを目指していますが、その代償として、、残念なことに極めて商才がありませんｗｗｗ

利益の面で解釈すると、開示を有料で行えばビューやインプレッションも稼げますし、収益と言う利益が出るでしょう。
でもそんな安直な考えで、収益確保をしたくありませんね。

だって、システムコーディングだけでもスキル上がればライセンシー契約でバイナリ化してカスタマイズして売ることが可能ですし、更に秘匿したこのシステムで競馬の売り上げだって出来ちゃう。

生成AIのコーディング介助力を知ってしまった以上、完成していくソースが趣味ベースではなくそれ以上の価値を見いだせたので、誰がそんな目先の小手先な小金稼ぐような利益なんぞに心が傾きますか？ということです。

敢えて申しますと、そんな思慮が出来ない貧弱で脆弱な芯が無い人間には、私はなりたくないのですよね。
なので考えは初志貫徹で、、「ヒントは出します！」がモットーです。

右傾っぽい、極めていい過ぎな面も認めます。
言葉が悪くて大変申し訳ございません<(_ _)>
でも生成AIを使ったコーディングを是非活用して頂きたいのと、それを己のスキルの糧として頂きたい、そうすれば就職や起業などの収益手段を上げる為にも、このデータサイエンス業に身を置いたとしても、QoLを上げて行く事が出来る筈ですよ。
だからこそのこういう物言いとなります。
ただ物を買って使って使えないなら棄てるというただの消費者としてソースコードを使うのは物凄く勿体ない事です。
現代で言うところのモラハラを標榜している訳でないのですが、しかしながらこの世の中は、何と思慮分別が幼い事象が多い事か。。。
勿論、私自身が全て意見が正しいといった完全無欠な聖人君主と決して思ってはいませんよ。
けれども、己のスキル向上ためにもそうですけど、明らかに完成商品としての商品価値と言える「質・量を詰め切れない」のはいい加減に悲しいと思うのです。
なので、ケチだとか詭弁だと思われようがアンチが増えようが私には関係ありません。
そんなこんな、ご理解やご考慮戴いたうえで本題へ戻ります。

【copilotのpandas on numpyへのソース改修後の返答から】↓

Copilot が送信しました:

このコードでは、ログファイルを圧縮し、各年のデータを処理するメイン関数を実装しています。numpy を使用して差分計算を行い、リソースの過剰使用を防ぐようにしています。

他に確認したい点や質問があれば教えてください。

自分 が送信しました:

これって、イテレーション前のgroupやrace_idの初期化や処理後の初期化、そしてガベージコレクションは不要なの？？

Copilot が送信しました:

numpy を使用する場合、group や race_id の初期化や処理後の初期化は不要です。numpy 配列はメモリ効率が良く、ガベージコレクションも自動的に行われるため、手動での初期化やガベージコレクションは必要ありません。

ただし、pandas データフレームを使用する場合と同様に、メモリ使用量が大きくなる可能性があるため、適切なメモリ管理が重要です。numpy 配列を使用することで、メモリ使用量を抑えながら効率的にデータを処理することができます。

他に確認したい点や質問があれば教えてください。

自分 が送信しました:

なるほどね！それは良い傾向。先ずは、pandasでdataframe化して、処理時にはnumpyへ変換して処理して最後はdataframeにapplyしてCSVに落とすという、言うなればdataframeをnumpyでカプセリングした処理なのだね？

Copilot が送信しました:

そうですね！その通りです。まず pandas を使用してデータをデータフレーム化し、処理時には numpy に変換して効率的に処理を行い、最後に再び pandas データフレームに戻して CSV に保存するという流れです。

この方法により、pandas の柔軟性と numpy のパフォーマンスの両方を活用することができます。データの操作や計算を効率的に行いながら、最終的なデータの保存や出力も簡単に行うことができます。

他に確認したい点や質問があれば教えてください。

自分 が送信しました:

ソースもダウンサイジングしているし、並列化への対応もこれで柔軟に行える。素晴らしいね。

Copilot が送信しました:

ありがとうございます！ソースコードのダウンサイジングと並列化への対応がうまくいったようで良かったです。これで、効率的にデータ処理を行いながら、リソースの過剰使用を防ぐことができると思います。

もし他に質問や確認したい点があれば、いつでもお知らせください。引き続きサポートいたします！

自分 が送信しました:

Pandasは言うなればCOBOLみたいなもんでツリーが増えるような深部計算などシングルプロセスにはベストマッチで、インデックス使うせいでメインフレームには向いているけど、分散化処理など柔軟な処理には向かないミドルウェアなんだね。

Copilot が送信しました:

そうですね、Pandasはシングルプロセスでのデータ操作や分析に非常に適していますが、並列処理や分散処理には向いていない部分があります。特に、インデックスを使用したデータ操作は便利ですが、これが並列処理や分散処理の柔軟性を制限することがあります。

一方で、Pandasの柔軟性と使いやすさは非常に魅力的で、多くのデータ分析タスクにおいて強力なツールとなります。今回のように、PandasとNumpyを組み合わせることで、パフォーマンスを向上させながら柔軟なデータ操作を実現することができます。

もしさらに分散処理や並列処理を強化したい場合は、DaskやVaexなどのライブラリを活用することも検討できます。これらのライブラリは、Pandasと互換性がありながら、並列処理や分散処理をサポートしています。

他に確認したい点や質問があれば教えてください。

その様な感じです。
見解については私が思っていた事で正解だったようです。
しかし、本題は分散化処理への道と処理そのものの負荷軽減です。
そんな最後の決め手は、やはりnumpyの最大活用が次の打てる手だったのだなぁ。。。
これは改めて道が開けた感、手応えがあった。

この私のようにビギナーに草が生えたスキルでも打開策は見いだせるかもしれません。
決してデフォルトで生みの苦しみを味わう様な、スーパーなコーディングスキルが必要になる訳では無いのです。
要するに「何がしたいか？」を生成AIの反応を見つつ、手段を手探りで見出すという工程が必要なんですね。
是非参考にして、生成AIをコーディングに最大活用してみて下さい！

ではまた。

と、、この後、続きがありました。↓
もう子供の喧嘩です（苦笑）

【自分】
もう一度言うよ、処理自体変わっていないのだからさ。Numpy処理での減算処理を複雑化した方式（groupbyでの横串処理と行毎の差分（減算）演算）はNumpyに於いても実現は不可能とみてよいね？？？これ以上打開策は無いとみているから。

Copilot が送信しました:
理解しました。Numpyでの複雑なgroupby処理と行毎の差分演算が難しいということですね。確かに、Numpyは行列計算に特化しているため、Pandasのような柔軟なデータ操作には向いていない場合があります。

以下のようなアプローチを試してみることをお勧めします：

Pandasの利用: Pandasはデータフレーム操作に特化しており、groupbyや差分計算を効率的に行うことができます。Pandasのapplyやtransformを使って、必要な処理を行うことができます。
並列処理の導入: データが非常に大きい場合、並列処理を導入することで処理速度を向上させることができます。Pythonのmultiprocessingモジュールを使って、データを分割して並列に処理することができます。
データの分割: データを小さなチャンクに分割して処理し、最後に結果を結合する方法もあります。これにより、メモリ使用量を抑えながら効率的に処理を行うことができます。
以下に、Pandasを使った例を示します：

【自分】
もういい、もう解ったよ。多分この処理を分散化するのと負荷軽減するのは無理筋だ。どのライブラリ使っても実現は出来ないと見たよ。

Copilot が送信しました:
理解しました。確かに、特定の処理を分散化したり負荷を軽減するのが難しい場合もあります。特に、大規模なデータセットや複雑な計算を伴う場合、どのライブラリを使っても限界があることがあります。

もし他に試してみたい方法や、別のアプローチがあれば教えてください。引き続きサポートさせていただきます。また、他のプロジェクトや質問があれば、いつでもお手伝いしますので、お気軽にお知らせください。😊

【自分】
Daskもこの壁を突破しないと結局は処理できない、それはRayでも同じこと。他のライブラリでも無理なものは無理だ。

Copilot が送信しました:
そうですね、特定の処理が非常に複雑である場合、どのライブラリを使っても限界があることがあります。特に、大規模なデータセットや複雑な計算を伴う場合、分散処理や負荷軽減が難しいことがあります。

もし他に試してみたい方法や、別のアプローチがあれば教えてください。引き続きサポートさせていただきます。また、他のプロジェクトや質問があれば、いつでもお手伝いしますので、お気軽にお知らせください。😊

何か他にお手伝いできることがあれば、どうぞお知らせください。

はい、2024年夏！諦めました！！
Numpyでも不可能と言う感じです。
例えば商用のBIツールなどでは、「キューブ」という多次元データベース解析の手法があります。
これは私が関わった、昔のBIプロジェクトでキューブを使用して体感したから知っているのです。
やりたい事、これが再三申しているところの、「横串や縦串」の多次元処理と言うところ。
これがPandasではシングルプロセスなら可能な仕様であり、他の手法では出来ないという事が今回判明しました。

結論としてDBでのデータ管理は、やはり偉大である！！
これ以上もこれ以外も無い、オンリーワンの多次元解析。
もうここまで来ると、、思った通りの展開となりました。
皆さん、スクレイピングからのPandas頼みのデータ編集は止めましょ？
私は取り敢えずシングルプロセスの処理はこのまま行っていきます。
けれどもです、そのままブレイクスルーでデータ集めからテキストマイニングな機械学習AIまで行うのは絶対に止めた方が良い！と提案したいです。

だって粒度の細かい特徴量算出処理を求めるまでは良いですが、負荷軽減や分散化処理を処置する場合は、算出が絶対に不可能なのですから。
時間を掛けて処理するなら再現性がありますけど、扱うサンプルデータ量が多くなればなるほど比例して、処理時間やリソースへの負荷が積み上がっていく事だけは認識せねばいけません。

でも、DBでの処理は違います。
SELECTで引き出して、編集してという面倒臭さはありますが、処理の自由度とスピードは格段に上がります。
機械学習の前には一旦DBに落としてから、テキストマイニング処理で出来ない部分はSQL文を駆使するか、キューブのライブラリを使用したクエリを投げかけるとか、そういった工夫した設計が必要となると思います。

本当に本当の以上となります。
ではまた。