少し前ってかまあ、そもそもこれまで利用してきたSystem.Data.SQLite.Core 1.0.119はもう随分と長い事バージョンアップが気になってたんですが、ってのも、本体(?)というか元のSQLite自体が何度かバージョンアップしてたので追従するんだろうなと思うのは普通なのでね。しかし、なにやら微妙に2.xとかの話がフォーラムで出たりしてたので、適度にチェック入れてました。
まあ、詳細とか気になる方は公式サイトでご確認頂ければと思いますが、最初はSystem.Data.SQLiteの方を利用してましたが、対応プラットフォームが.NET Frameworkから.NETxになった時に今の.Core付に変えた記憶が。で、ざっくりな話としてはSystem.Data.SQLite 2.0.1.0は.NET 8や.NET 9にも対応しているとの事なので特に問題無く移行出来ればとは思うけど、やって問題があって戻す作業がまた大変なので二の足踏む感じです。リリースされたの昨日なので、少し様子見かな。
| 8R | 1点 | 芝(7R) | ダート(1R) | 8頭以下(1R) | 9～12頭(5R) | 13頭以上(2R) | 多点 |
| 単勝 | 12.50% (15.00%) |
14.29% (17.14%) |
0.00% (0.00%) |
0.00% (0.00%) |
20.00% (24.00%) |
0.00% (0.00%) |
50.00% (50.42%) |
| 複勝 | 50.00% (71.25%) |
57.14% (81.43%) |
0.00% (0.00%) |
0.00% (0.00%) |
60.00% (76.00%) |
50.00% (95.00%) |
87.50% (63.33%) |
| 枠連 | 0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
-- (--) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
| 馬連 | 0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
| ワイド | 25.00% (61.25%) |
28.57% (70.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
40.00% (98.00%) |
0.00% (0.00%) |
50.00% (42.50%) |
| 馬単 | 0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
| 三連複 | 0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
| 三連単 | 0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
| 総合 | 50.00% (19.03%) |
57.14% (21.85%) |
0.00% (0.00%) |
0.00% (0.00%) |
60.00% (24.75%) |
50.00% (11.87%) |
87.50% (9.72%) |
| 64R | 1点 | 芝(34R) | ダート(28R) | 障害(2R) | 8頭以下(6R) | 9～12頭(17R) | 13頭以上(41R) | 多点 |
| 単勝 | 23.44% (73.28%) |
23.53% (52.35%) |
25.00% (103.93%) |
0.00% (0.00%) |
50.00% (91.67%) |
23.53% (129.41%) |
19.51% (47.32%) |
56.25% (89.95%) |
| 複勝 | 54.69% (80.63%) |
52.94% (70.29%) |
53.57% (90.36%) |
100.00% (120.00%) |
50.00% (53.33%) |
70.59% (102.35%) |
48.78% (75.61%) |
85.94% (77.97%) |
| 枠連 | 16.67% (78.52%) |
11.54% (35.77%) |
19.23% (112.69%) |
50.00% (190.00%) |
-- (--) |
17.65% (76.47%) |
14.63% (71.71%) |
27.78% (98.77%) |
| 馬連 | 14.06% (70.63%) |
11.76% (33.53%) |
14.29% (105.00%) |
50.00% (220.00%) |
16.67% (20.00%) |
17.65% (82.35%) |
12.20% (73.17%) |
25.00% (101.77%) |
| ワイド | 20.31% (48.59%) |
17.65% (25.59%) |
21.43% (72.86%) |
50.00% (100.00%) |
50.00% (58.33%) |
23.53% (72.94%) |
14.63% (37.07%) |
40.62% (74.74%) |
| 馬単 | 4.69% (49.22%) |
2.94% (3.82%) |
7.14% (107.86%) |
0.00% (0.00%) |
16.67% (21.67%) |
5.88% (122.94%) |
2.44% (22.68%) |
25.00% (102.73%) |
| 三連複 | 6.25% (46.41%) |
8.82% (39.41%) |
3.57% (58.21%) |
0.00% (0.00%) |
33.33% (106.67%) |
5.88% (95.88%) |
2.44% (17.07%) |
12.50% (77.70%) |
| 三連単 | 3.12% (237.81%) |
2.94% (11.76%) |
3.57% (529.29%) |
0.00% (0.00%) |
16.67% (66.67%) |
5.88% (871.76%) |
0.00% (0.00%) |
12.50% (66.93%) |
| 総合 | 57.81% (85.78%) |
55.88% (34.02%) |
57.14% (147.84%) |
100.00% (78.75%) |
66.67% (59.76%) |
70.59% (194.26%) |
51.22% (43.08%) |
85.94% (78.60%) |
先程さらだの先週の結果アップしてて、こちらの現状とどの程度違うのか気になり出してみた。新馬戦はほぼ同じ感じなのでもう少し学習させてみる必要がありそうなので今晩は8時間やってみます。通常の方ももう少しってか先日またやらかして、気が付いたらWindows Updateで強制再起動されてて最終的なRMSEとかも分からない状態だったし😓 Windows Updateを常時停止していて適度に手動でも良いかもだけど、なんか緊急のとか出た時の事を考えるとねぇ。
WinUI3でのアプリ作成で、特に何も考えずに当たり前に使い始めてた、まあいわゆるプロジェクトのプロパティをVisual Studioで開くと左の一番下に「設定」って出る奴ね。これ、今のVisual Studio 2022とかでは確かに
「プロジェクト プロパティ経由では実行されなくなりました」とか出るんですよね。それでもWindowsフォームアプリでは使い続けてました。これ、Copilotの説明だと.NETなんかの流れらしく、WinUI3とかでは推奨されないらしい。で、ApplicationData.Current.LocalSettingsが推奨されるって事で本日午前中はこの修正で終わりました😅
まだまだ全然C#も初心者だし、WinUI3とかもそうなんですが、これまでのSettings.settingsに変えて、今後使用するべく
public static class AppSettings
{
// 🔹 アプリケーション設定のキー
//
// 文字列取得・設定の例
// string dbPath = AppSettings.Get("JVD_DB");
// AppSettings.Set("Theme", "Light");
//
// 整数取得・設定の例（オーバーロード）
// int retry = AppSettings.GetInt("MaxRetry", 5);
// AppSettings.Set("MaxRetry", retry + 1);
//
// 真偽値取得・設定の例（オーバーロード）
// bool logging = AppSettings.GetBool("EnableLogging");
// AppSettings.Set("EnableLogging", !logging);
// 初期値定義（すべて文字列）
private static readonly Dictionary<string, string> DefaultSettings = new()
{
{ "JVD_DB", "JVData.db" },
{ "UserDB", "UserData.db" },
{ "AnalyzeDB", "Analyze.db" }
};
private static readonly ApplicationDataContainer _settings = ApplicationData.Current.LocalSettings;
public static bool IsInitialized => _settings.Values.ContainsKey("Initialized");
public static void InitializeDefaults()
{
if (!IsInitialized)
{
foreach (var kvp in DefaultSettings)
_settings.Values[kvp.Key] = kvp.Value;
_settings.Values["Initialized"] = true;
}
}
public static void ResetToDefaults()
{
foreach (var kvp in DefaultSettings)
_settings.Values[kvp.Key] = kvp.Value;
}
// 🔹 基本型の取得
public static string Get(string key)
{
if (_settings.Values.TryGetValue(key, out var value))
return value as string ?? DefaultSettings.GetValueOrDefault(key, "");
else
return DefaultSettings.GetValueOrDefault(key, "");
}
public static void Set(string key, string value)
{
_settings.Values[key] = value;
SettingChanged?.Invoke(key, value);
}
// 🔹 型付き取得
public static int GetInt(string key, int defaultValue = 0)
{
var value = Get(key);
return int.TryParse(value, out var result) ? result : defaultValue;
}
public static bool GetBool(string key, bool defaultValue = false)
{
var value = Get(key);
return bool.TryParse(value, out var result) ? result : defaultValue;
}
// 🔹 型付き設定（オーバーロード）
public static void Set(string key, int value) => Set(key, value.ToString());
public static void Set(string key, bool value) => Set(key, value.ToString());
// 🔔 設定変更通知（任意）
public static event Action<string, string>? SettingChanged;
// 🔹 補助プロパティ
public static IEnumerable<string> Keys => DefaultSettings.Keys;
public static IReadOnlyDictionary<string, string> AllDefaults => DefaultSettings;
}
こんな感じでラッパークラスを追加すればってCopilotの提案を素直に受け入れて進めてみてます。
なんだろ?年齢的になのか本当に頻繁にやらかしてます。で、前回7月1日なので45日目での獲得ですが、今回は5,250ポイントを楽天660ポイントにしました。これ、出たり消えたりで今回はAmazonではなく楽天を選択してますが、期間限定(6カ月)です。まあ、楽天モバイル契約してるのでほっておいても毎月回線料金で1,080ポイントは消費されます。なので気にはなりませんが、Amazonとの使い分けでは毎回ちょっと悩んだりしてます。どちらも頻繁に利用してますので無駄にはならないけど、何となくどちらがお得?とか気にしたりね。継続は力ですね。
先日AutoMLのPreviewがバージョンアップしてLightGBMの4.6.0が使われる様になったって事で、この所、WinUI3での開発の合間にAutoMLでの学習もさせてました。まあ、現在リリースしてるバージョンに添付してる学習モデルも昨年末までのデータでのものでしたし、う～う～言いながらWinUI3での開発で四苦八苦している程度なら裏で学習させていても然程影響もないのでって事で有効活用してた訳です。が!例えば、新馬戦用ではAutoMLで多分30時間以上も学習させて得た最適RMSEは1.9949でした。
| 45R | 1点 | 芝(38R) | ダート(7R) | 8頭以下(15R) | 9～12頭(15R) | 13頭以上(15R) | 多点 |
| 単勝 | 17.78% (53.11%) |
21.05% (62.89%) |
0.00% (0.00%) |
40.00% (113.33%) |
6.67% (14.67%) |
6.67% (31.33%) |
53.33% (97.93%) |
| 複勝 | 40.00% (66.44%) |
39.47% (69.21%) |
42.86% (51.43%) |
53.33% (78.00%) |
33.33% (42.00%) |
33.33% (79.33%) |
88.89% (78.22%) |
| 枠連 | 0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
-- (--) |
0.00% (0.00%) |
0.00% (0.00%) |
16.00% (81.39%) |
| 馬連 | 2.22% (5.56%) |
2.63% (6.58%) |
0.00% (0.00%) |
6.67% (16.67%) |
0.00% (0.00%) |
0.00% (0.00%) |
15.56% (36.96%) |
| ワイド | 11.11% (19.33%) |
13.16% (22.89%) |
0.00% (0.00%) |
26.67% (50.00%) |
6.67% (8.00%) |
0.00% (0.00%) |
42.22% (76.52%) |
| 馬単 | 2.22% (8.00%) |
2.63% (9.47%) |
0.00% (0.00%) |
6.67% (24.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
15.56% (30.67%) |
| 三連複 | 4.44% (23.11%) |
5.26% (27.37%) |
0.00% (0.00%) |
6.67% (15.33%) |
6.67% (54.00%) |
0.00% (0.00%) |
15.56% (35.72%) |
| 三連単 | 2.22% (16.44%) |
2.63% (19.47%) |
0.00% (0.00%) |
6.67% (49.33%) |
0.00% (0.00%) |
0.00% (0.00%) |
15.56% (38.45%) |
| 総合 | 40.00% (25.41%) |
39.47% (28.95%) |
42.86% (6.67%) |
53.33% (49.52%) |
33.33% (14.83%) |
33.33% (13.83%) |
88.89% (47.25%) |
ああ、これ、さらだでではなく、さらだ64使ってます。
いや、別にサボってないよって事では無いですが(笑)、地道に進めてますって報告兼ねてね。
でも、相変わらずModel Builer自体がLightGBMのどのバージョンを採用しているのかは不明ですが、こちらだと本日5時間程度の学習走らせて得た最適RMSEは1.9632で
| 45R | 1点 | 芝(38R) | ダート(7R) | 8頭以下(15R) | 9～12頭(15R) | 13頭以上(15R) | 多点 |
| 単勝 | 15.56% (50.44%) |
18.42% (59.74%) |
0.00% (0.00%) |
20.00% (65.33%) |
20.00% (54.67%) |
6.67% (31.33%) |
53.33% (87.26%) |
| 複勝 | 53.33% (87.11%) |
55.26% (93.68%) |
42.86% (51.43%) |
53.33% (78.67%) |
60.00% (78.00%) |
46.67% (104.67%) |
91.11% (72.67%) |
| 枠連 | 0.00% (0.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
-- (--) |
0.00% (0.00%) |
0.00% (0.00%) |
8.00% (13.19%) |
| 馬連 | 4.44% (26.44%) |
5.26% (31.32%) |
0.00% (0.00%) |
13.33% (79.33%) |
0.00% (0.00%) |
0.00% (0.00%) |
11.11% (38.15%) |
| ワイド | 13.33% (30.44%) |
15.79% (36.05%) |
0.00% (0.00%) |
26.67% (50.67%) |
13.33% (40.67%) |
0.00% (0.00%) |
37.78% (64.81%) |
| 馬単 | 4.44% (47.33%) |
5.26% (56.05%) |
0.00% (0.00%) |
13.33% (142.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
11.11% (30.00%) |
| 三連複 | 6.67% (30.22%) |
7.89% (35.79%) |
0.00% (0.00%) |
13.33% (36.67%) |
6.67% (54.00%) |
0.00% (0.00%) |
11.11% (23.78%) |
| 三連単 | 4.44% (132.00%) |
5.26% (156.32%) |
0.00% (0.00%) |
13.33% (396.00%) |
0.00% (0.00%) |
0.00% (0.00%) |
11.11% (33.09%) |
| 総合 | 53.33% (53.47%) |
55.26% (62.31%) |
42.86% (6.67%) |
53.33% (121.24%) |
60.00% (28.42%) |
46.67% (17.00%) |
91.11% (39.48%) |
って感じなんです。ああっ、どちらも学習データは今年の6月末までを使用したので、検証は7月1日～先週末までですので、期間が短く甲乙つけるのは微妙ではありますけどね。
ああっ、TensorFlowは諦めた訳ではないのですが、やはり、簡単ではない様です。既にさらだ64では、TensorFlowの学習モデルをonnx形式に変換したモデルを使った予測も出来る状態にまでは来たのですが、いやね、各epochで出るRMSEもそうなんですが、AutoMLでもModel Builderでも1.4前後なのに0.00??とか異常に小さい数値が出てて、もしかすると学習設定で諸々する方法が何か間違っているかもなので、素人の自分がそれを解決するのには時間が掛かると判断しての作業スケジュールの見直しです。
WinUI3は未だに好きになれないけど、ここまで来てまた最初からってか、Windowsフォームアプリとしてのさらた64なら、まあ、単純に現状のさらだのターゲットをx64に変えて、JV-Linkアクセス周りのみ外部32bitプロセスを作ってって事で行けばってのも選択肢としてはあるのですが、さらだ自体の画面設計やテーマ対応(ダークモードとかね、自分自身のPCはダークモードだし)とかね。実際、少数しかいない、さらだユーザーさんのPCでどんな感じで動いているのかも気になりますし、WinUI3でのさらだ64はその辺りも吸収して解像度に依存しないで行けるアプリになればって期待も含めてね。ただ、UI周りとしては大分作りこみましたが、肝心のJV-Linkアクセス用の外部32bitアプリは全く手つかずorz いや、サボってるのではなく、現行のさらだでDBを最新にしておいて、さらだ64でそのDBを使えば動くようにはしてるので、ちょっと思案中。
仮に現行のさらだにおんぶ的にさらだ64ではJV-Link無でリリースして基本さらだでDB更新してさらだ64で諸々って運用も出来なくはないので...いや、決して使い勝手は良くないのですが、開発期間がまだまだ掛かる事を想定するとってのと、もしJRA-VANがJV-Linkの64bit化をしてくれれば、現行のさらだのコードを利用して最小限の工数でさらだ64に実装も可能なのでってもあるのでね^^;
まっ、そんな訳でWinUI3でのさらだ64の開発進めながら、今現在はModel Builderで通常用の24時間学習をさせている所です。って、あれ?なんかエラーが出まくってるので、その対処しますので、一旦ここまでで報告終わりです。
追記 2025.8.13 18.25
書き忘れました! さらだ64はWindows11のみ対応です。Windows10は残り3カ月程度でMicrosoftのサポートが切れます。有償での延長とかって、基本一般ユーザーはしない可能性高いと思うし、WinUI3ではWindows10は微妙な感じなので切ります<m(__)m>
Visual的な開発環境のVisual Studioにおいて、Windowsフォームアプリ開発は適してる感じはします。しかし、現状のWindows11的なUIでのアプリ開発はWinUI3が適しているって事の様ですが、これがWindowsフォームアプリ経験者にはいばらの道?
自分自身が未熟だからなら仕方ないけど、それが理由? 今回WinUI3アプリに挑んでますが、本当に辛い😭 ここまでスムーズに出来ないのは、最近リリースされるアプリが相変わらずWinUI3ではないのが理解出来る気がしてきました。経験すれば分かってくれるんじゃないかと思いますが、ジジイの自分だからかそもそもなのかは別として、今回のアプリ64bit化についでにWinUI3化も挑んだ結末ってか代償ってかねぇ。多分単純に64bit化としてWindowsフォームアプリで行ってたら、半分以下の工数でってか、本当にそれ以上に少ない苦痛レスな作業になった気がします。
そのうちにVisual StudioでWinUI3が標準でサポートされ、今のWindowsフォームアプリで出来ている事が実現すれば、きっと今より多くのアプリがWinUI3プラットホームでリリースされる日が来るかも? 乗り掛かった舟だから、このまま進みますが、ゴール出来るかな?
これね、やった事がある人じゃないと分からないと思うわ! ここまで別次元で苦労強いられるのは、本当に苦痛以外の何物でもないですし、これで得られるものは?
TensorFlowでの一般用(これまで通常用と言ってきたけど、新馬戦用と一般用にします)の順位予測の学習モデルに取り掛かってましたが、昨夜からいよいよ学習が出来る所まで来た(?)と思うので、ちょっと失敗はいきなり50epochsで行っちゃったので、現時点で31/50だったりしますが、遅くとも土曜日の朝には終わるかと😓 いや、多分10epochsとかにすれば良かったと悔やんでます。
ただ、一般用はこれまでC#での利用が出来ていません。学習終了後にonnx形式に変換してML.NETでの利用を目指します。順調に行けば、それ元に検証プロセスの実装もして実力を確認したいと思ってます。
追記 2025.8.8 18:07
やらかしました😱 本日、盆前最終勤務後に帰宅してPC確認すると、エラーで止まってました。もう少し修正漏れがあったので、この30数時間が無駄にorz 修正は即座にして、念の為、1epochで行ってます。で、もしかしたら50epochsは必要ないのかも? 正常にセーブまで行くの確認したら取敢えず10epochsで行けば明日朝には終わってる筈なので、順調にコーディング出来れば、その実力を見てみようかと思います。
別にチェックをサボってた訳じゃないけど、気が付けばML.NETのpreviewが上がってた。まあ、これまでも何度かありましたが、今回はこれ上げただけで実はLightGBMが4.6.0にあがりました。つまり、ML.NETが正式にLightGBMの最新バージョンに対応した様です。これが意味する所は、これまで個別にLightGBMでの学習なんかをしてましたが、AutoMLすれば最新のLightGBMでの学習がされる、筈?w
個別に外部プロセスとしてLightGBMを利用してきましたが、お役御免になる感じかと思います。明日、盆前最終勤務後にさらだの方の諸々も対処したいと思います。つまり、さらだからLightBGMの外部プロセスは削除って事になるかと。っと、それに伴って学習モデルの再学習って事になるかとは思いますので、ちょっと時間頂き、新バージョンのリリースにしたいとは思います。が!、さらだ64も控えてたり、TensorFlowが本当に化けるかも?
何にしても秋競馬に間に合う様に出来る限りは尽くします!!
追記 2025.8.7 21:33
これ、これまでのバージョンと番号振りが変わってるのはミスなのか故意なのかが不明。
もう、何カ月苦戦しているか...確かGW辺りには取り掛かってた記憶なので😖
いや、進展がない訳でもないし、沢山学習はって学習モデルの学習ではなく自分自身の学習ですがさせて頂きました。これはCopilotに感謝ですが...まあ、滅茶苦茶遠回りもしてる感じはしますけどね。
そんな過程から、現在までML.NETから始まった機械学習で、ターゲットとして走破予測をしてきたのですが、これは実際には目的ではないのです😞 そもそもの目的は各レースでどの馬が来るかを予測してもらい馬券を当てるのが目的です。なので学習データの出力を走破タイムではなく確定着順に変更して今後は作業進めて行きます。
ML.NET系のAutoMLやLightGBMは現状のままで行きますが、TensorFlowでは順位の直接予測にします。これである程度の無駄が省けると思います。CSV出力からの修正になるので、また少し時間は掛かりますが、ここまでの苦労でモデルの学習や出来たモデルのonnx変換からのML.NET経由でのC#での活用は無駄にはならない筈なので一気に行きます。
ただ、新馬戦用のサイズでは問題はないのですが通常用のサイズで問題解決には至ってないのは気になりますが、この方向で進めて問題解決していく予定。
散々苦労した対応なんですが、ダイエットは止めて現状で進める事に。ってのもtf2onnxでモデルが2GB超えるとって話ですが、これ、そもそも
python -m tf2onnx.convert --saved-model .\saved_model_multi_output\ --output Souha.onnx --large_model --opset 17
としてたんですが、--large_modelを付けた時点で出力されるモデルはzip圧縮されたものらしい。つまり、
python -m tf2onnx.convert --saved-model .\saved_model_multi_output\ --output Souha.zip --large_model --opset 17
として、利用するには適当なフォルダに解凍して(今回の場合は583個のファイルが出てくる)、その中に含まれる__MODEL_PROTO.onnxを指定してやれば
var pipeline = mLContext.Transforms.ApplyOnnxModel(
modelFile: Properties.Settings.Default.TF_Souha_Onnx,
outputColumnNames: new[] { "output" }, // Netronで確認した出力名
inputColumnNames: allInputColumns // 入力名と一致させる
);
でも利用可能らしい。ただ、今回は色々やったおかげで諸々元に戻す作業と再学習時間が掛かってます。更に新馬戦用の学習中なんですが、学習中はPCが重い。他のデバッグ作業にも影響が出るし、ブラウザーの反応すら悪い。
更に非常に気になっているのはレース選択後に途方もない時間が掛かってます。まあ、レースの出走馬のデータ収集後にまずはML.NET用のデータ準備して予測し、その後にTensorFlowのデータ準備して更に予測。この際、最初のデータ収集でDBからの取得は済ませて置き、後はそこからそれぞれのクラスに適用して予測。このそれぞれのクラスに適用が思いのほか時間が掛かってます。単純にクラス→クラスでスマートにいけば良いのですが、以前まだまだ続く辛い道のりでも書いたクラスのメンバーにプログラムでアクセスする的に
var properties = new (string target, string src)[]
{
("barei", "Barei"),
("blinkers", "Blinkers"),
("cdchaku1", "CDChaku1"),
("cdchaku2", "CDChaku2"),
("cdchaku3", "CDChaku3"),
("cdchaku4", "CDChaku4"),
("cdchaku5", "CDChaku5"),
("cdchakux", "CDChakuX"),
⋮
};
for (int i = 0; i < umas.Count; i++)
{
foreach (var (target, src) in properties)
{
string targetProperty = $"uma{i + 1}{target}";
PropertyInfo targetProp = typeof(TFShinbaOnnxInput).GetProperty(targetProperty, BindingFlags.Public | BindingFlags.Instance);
string srcProperty = $"{src}";
PropertyInfo srcProp = typeof(RaceDetailInfo).GetProperty(src, BindingFlags.Public | BindingFlags.Instance);
if (srcProp != null)
{
if (srcProp.CanRead)
{
if (targetProp != null && targetProp.CanWrite)
{
if (targetProp.PropertyType == typeof(float[]))
{
if (srcProp.PropertyType != typeof(float))
{
Debug.WriteLine($"{targetProperty}({targetProp.PropertyType})に{srcProperty}({srcProp.PropertyType})をセットする為に?→float");
var value = Convert.ToSingle(srcProp.GetValue(umas[i])); // ?をfloatに変換
targetProp.SetValue(this, new float[] { value });
}
else
{
var value = (float)srcProp.GetValue(umas[i]);
targetProp.SetValue(this, new float[] { value });
}
}
⋮
まあ、こんな感じにしてるので単純な代入ではない為に滅茶苦茶遅い。リリースビルドになれば少しは改善されるかもだけど、多分劇的に早くなる訳ではなさそうだから何か考える必要があるかも。
Visual Studio Community2022のC#でML.NET使ってTensorFlowのモデルを利用する為にonnx形式に変換して利用する為にこれまで随分時間掛けて挑んで来ました。新馬戦用ではそれでも1.53GBと大きく、通常用では2GB超えるので、先日もちらっと書きましたが、tf2onnxで"--large_model"を付けて変換し2.07GBです。しかし、
var pipeline = mLContext.Transforms.ApplyOnnxModel(
modelFile: Properties.Settings.Default.TF_Souha_Onnx,
outputColumnNames: new[] { "output" }, // Netronで確認した出力名
inputColumnNames: allInputColumns // 入力名と一致させる
);
として新馬戦用と同様にロードしようとしてもエラーになり、Copilotに相談すると2GB超えるlarge_modelには対応してない可能性が高いという事でTensorFlowでのモデルのダイエットが必要になりました。これまでは、
# レースのカテゴリ変数を定義 input_joucd = Input(shape=(1,), name="JouCD", dtype=tf.int32) # 場コード embedding_joucd = Embedding(input_dim=11, output_dim=4)(input_joucd) # 場コードの埋め込み flatten_joucd = Flatten()(embedding_joucd) input_kaisaituki = Input(shape=(1,), name="KaisaiTuki", dtype=tf.int32) # 開催月 embedding_kaisaituki = Embedding(input_dim=13, output_dim=4)(input_kaisaituki) # 開催月の埋め込み flatten_kaisaituki = Flatten()(embedding_kaisaituki) input_trackcd = Input(shape=(1,), name="TrackCD", dtype=tf.int32) # トラックコード embedding_trackcd = Embedding(input_dim=60, output_dim=4)(input_trackcd) # トラックコードの埋め込み flatten_trackcd = Flatten()(embedding_trackcd) ⋮
としてましたが
# レースのカテゴリ変数を定義 input_joucd = Input(shape=(1,), name="JouCD", dtype=tf.int16) # 場コード embedding_joucd = Embedding(input_dim=11, output_dim=4)(input_joucd) # 場コードの埋め込み flatten_joucd = Flatten()(embedding_joucd) input_kaisaituki = Input(shape=(1,), name="KaisaiTuki", dtype=tf.int16) # 開催月 embedding_kaisaituki = Embedding(input_dim=13, output_dim=4)(input_kaisaituki) # 開催月の埋め込み flatten_kaisaituki = Flatten()(embedding_kaisaituki) input_trackcd = Input(shape=(1,), name="TrackCD", dtype=tf.int16) # トラックコード embedding_trackcd = Embedding(input_dim=60, output_dim=4)(input_trackcd) # トラックコードの埋め込み flatten_trackcd = Flatten()(embedding_trackcd) ⋮
ってまあ、tf.int32→tf.int16に変更。当然だけどC#側でも
internal class TFShinbaOnnxInput
{
[ColumnName("baba")]
[VectorType(1)]
public int[] baba { get; set; }
[ColumnName("course")]
[VectorType(1)]
public int[] course { get; set; }
[ColumnName("joucd")]
[VectorType(1)]
public int[] joucd { get; set; }
⋮
だった所を
internal class TFShinbaOnnxInput
{
[ColumnName("baba")]
[VectorType(1)]
public short[] baba { get; set; }
[ColumnName("course")]
[VectorType(1)]
public short[] course { get; set; }
[ColumnName("joucd")]
[VectorType(1)]
public short[] joucd { get; set; }
⋮
にする必要があるんだけど、万が一元に戻すのも箇所が多いので面倒になる。って事で
// namespaceの外側で
using category_type = System.Int16[];
namespace SaraD64;
internal class TFShinbaOnnxInput
{
[ColumnName("baba")]
[VectorType(1)]
public category_type baba { get; set; }
[ColumnName("course")]
[VectorType(1)]
public category_type course { get; set; }
[ColumnName("joucd")]
[VectorType(1)]
public category_type joucd { get; set; }
⋮
としておけば、category_type宣言部を修正するだけで済む。ただ、問題は本当にこれでダイエットになるのかは、また途方もない修正作業と学習時間が必要になるので、まずは新馬戦用で試して確認してます。
Copilotに振り回され、Geminiでも微妙なので時間の節約で一旦、保存後の再学習は諦めて、先程50epochsをスタートしたので金曜日には終わるかな😅 ちょっとML.NETでのonnx形式での予測実装用の入力クラス定義でNetronでモデル開いて確認しながらクラス定義記述してると明らかな違和感があり、Pythonでのコード確認すると...酷いコーディングミスを発見😖
その部分を含めて一応一連を再確認しての学習スタートなので今週末には通常用含めた予測が可能になると期待して、それを元に順位予測用CSVデータ出力して、その学習させて、そのモデルのML.NETでの予測実装ってステップになるかと思ってます。
最悪の想定として秋のGIスタートには間に合うかなぁって最近は諦めてみます。でも、実装や学習等を並列実行して時短し、更に各モデルの検証も実装する予定です。で!この検証が重要で、これが楽しみでもあります。AutoMLやLightGBMでは多変量多出力回帰モデルは対応しておらず、ざっくりな話として、予測対象馬のデータのみ学習させて予測してました。
多変量多出力回帰モデルに対応しているTensorFlowでは、予測対象のレースに出走する全ての馬のデータを学習させて、全ての馬の走破予測や順位予測をさせます。ここで、ざっくりな話として対象馬のみのデータでは同一レースで走る馬、騎手、その他諸々の情報加味しての予測になる筈。新馬戦用で1,018個の特徴量だったかと思いますが、通常走破予測では9,589個の特徴量です。なので新馬戦用とは桁違いに学習時間が必要です。
余談ですが、これまでも何度かやらかしてるというか、Microsoftの無能な対応で人の苦労を勝手に無にしてます。長時間学習ではWindows Updateの自動は無効にしないとってのは何度もやられてます。ちょっと今回は33時間程度の予定でそれ程と思ったのが間違いなのと、夜間だと思ったのに真昼間にやられた事。このUpdateってそもそもMicrosoft自体のチョンボの尻拭いであって、こちらのミスではない。更にPCがアイドル状態とかならまだしも、Visual Studioが2つも起動し、一つは編集途中、一つはデバッグでの実行中なのはタクス確認すれば分かるってか、詳細は別としてCPU使用率は確実に高い状態が維持されている。AI学習されていれば当然CPUはぶん回ってます。そんな事もチェックせずに勝手に再起動させて、こちらの努力を無駄にしてくれる。悲しいかな、こんな無能集団のMicrosoftから逃れられない呪縛。ああっ、ちょっと愚痴りました。
だからではないけど、TensorFlowにはぜひともAutoMLとかLightGBMなんかを遥かに超えた予測してくれる事を期待してひたすらコーディングしてます。
先週末も競馬そっちのけでひたすらCopilotとの格闘。プラス自分のコーディングミスなんかの処置で予想する気力とか時間とかね。でも、先が見えたかも!
そもそもの問題はってか、通常の走破予測の学習モデルはTensorFlowで1epochで40分弱なんです。最低でも500epochs程度は学習しようとは思ってますが、50epochsで学習終了後にセーブ時にエラーで全てが無駄にorz それを踏まえて小刻みに学習をさせるべく、その術をCopilotに問い合わせ、その実現に向けて先週末はほぼ終わりました。
ここまでは
# SavedModel形式で保存
model.export('TFMShinbaCK')
# TensorSpec を生成（shapeは共通なので固定）
input_signature = [
tf.TensorSpec([None, 1], dtype, name=name)
for name, dtype in feature_info
]
@tf.function(input_signature=input_signature)
def serve_fn(*features):
return {"output": model(list(features))}
saved_model_path = "saved_model_multi_output"
tf.saved_model.save(model, saved_model_path, signatures={"serving_default": serve_fn})
この2本立て。いやね、当初諸々してた時にたどり着いたmodel.exportなんですが、これ、多分無用ですね。先日も書いてますが、その次のがonnx形式には重要ってか使います。
一旦学習したモデルを保存して、後日読込して再学習が必要と思い、その実現に先週末は時間を費やしました。最初Copilotが提案したのが
model.save("Shinba.keras")
なんですが、これはNG! 詳細既に忘れてますが、そもそも".keras"では保存がエラーになる。これって別に自分がやろうとしたのではなく、単にCopilotのアドバイスからね。で、次は
model.save("Shinba.h5")
これは、Geminiも案内した方法なんですが、これをこれからちょっと色々とやってみるかなぁ。ってのも、それ以前に新馬戦用のonnx形式は実装出来たので、走破予測のonnx形式も確認して実装作業しながら学習も進めていこうってのと、それ出来たら二つ合わせた走破予測の検証して、それ使った順位予測の学習用CSVの出力とその学習。
自分の年齢的にものんびりする予定は無いです! ただ、想定より遥かに時間を必要としているので、ここは慌てずに着実に進めていく予定です
追記 2025.7.21
ちょっとビビった😅 実は昨晩どうにか走破予測モデルをたった1epochで完了してまして、これをonnx形式にしてNetronで確認してML.NETで予測する部分の実装進めようかと思っていて、早速いつものってかAnacondaの仮想環境でお約束のコマンド使ってみた所、そのままでは2GBの壁か何かでNG! --large_model付ければってCopilotがいうので試した所、無事にonnx形式に出来た。参考までに1epochしかしてないモデルですが、2.07GBでした。
先日もちらっと書きました。現行tf2onnx(1.16.1)はnumpy 1.26.4までにしないとダメです。
python -m tf2onnx.convert --saved-model .\saved_model_multi_output\ --output Shinba.onnx
自分はAnacondaの仮想環境使ってるので、Anaconda PowerShell Prompt使って仮想環境をアクティブにして上記コマンドでSavedModel形式の
# TensorSpec を生成（shapeは共通なので固定）
input_signature = [
tf.TensorSpec([None, 1], dtype, name=name)
for name, dtype in feature_info
]
@tf.function(input_signature=input_signature)
def serve_fn(*features):
return {"output": model(list(features))}
saved_model_path = "saved_model_multi_output"
tf.saved_model.save(model, saved_model_path, signatures={"serving_default": serve_fn})
とした方を指定して変換。出来上がるShiba.onnxは1.53GBってデカイ! Netron使って開いてみると
って感じです。まあ、こんなのはどうでもいいですが、Graph Properties開くと
と表示されるのが重要で、これを元に
internal class TFShinbaOnnxInput
{
[ColumnName("baba")]
[VectorType(1)]
public int[] baba { get; set; }
[ColumnName("course")]
[VectorType(1)]
public int[] course { get; set; }
[ColumnName("joucd")]
[VectorType(1)]
public int[] joucd { get; set; }
[ColumnName("kaisaikai")]
[VectorType(1)]
public float[] kaisaikai { get; set; }
[ColumnName("kaisainichi")]
[VectorType(1)]
public float[] kaisainichi { get; set; }
[ColumnName("kaisaituki")]
[VectorType(1)]
public int[] kaisaituki { get; set; }
[ColumnName("kyori")]
[VectorType(1)]
public float[] kyori { get; set; }
[ColumnName("tenko")]
[VectorType(1)]
public int[] tenko { get; set; }
[ColumnName("tousu")]
[VectorType(1)]
public float[] tousu { get; set; }
[ColumnName("trackcd")]
[VectorType(1)]
public int[] trackcd { get; set; }
// uma10
[ColumnName("uma10bareidays")]
[VectorType(1)]
public float[] uma10bareidays { get; set; }
...
って感じの入力クラスを準備して、先程のGraph Propertiesの最後まで行くと確認出来る出力部分も確認して
internal class TFShinbaOnnxOutput
{
[ColumnName("output")]
public float[] output { get; set; }
}
てな感じの出力クラスも用意。
MLContext mLContext = new MLContext();
var inputType = typeof(TFShinbaOnnxInput);
// int[]のColumnName一覧
var intColumnNames = inputType.GetProperties()
.Where(p => p.PropertyType == typeof(int[]) &&
p.GetCustomAttributesData().Any(a => a.AttributeType == typeof(ColumnNameAttribute)))
.Select(p => p.GetCustomAttributesData()
.FirstOrDefault(a => a.AttributeType == typeof(ColumnNameAttribute))
?.ConstructorArguments[0].Value?.ToString() ?? p.Name)
.ToList();
// float[]のColumnName一覧
var floatColumnNames = inputType.GetProperties()
.Where(p => p.PropertyType == typeof(float[]) &&
p.GetCustomAttributesData().Any(a => a.AttributeType == typeof(ColumnNameAttribute)))
.Select(p => p.GetCustomAttributesData()
.FirstOrDefault(a => a.AttributeType == typeof(ColumnNameAttribute))
?.ConstructorArguments[0].Value?.ToString() ?? p.Name)
.ToList();
var allInputColumns = intColumnNames.Concat(floatColumnNames).ToArray();
var pipeline = mLContext.Transforms.ApplyOnnxModel(
modelFile: Properties.Settings.Default.TF_Shinba_Onnx,
outputColumnNames: new[] { "output" }, // Netronで確認した出力名
inputColumnNames: allInputColumns // 入力名と一致させる
);
var emptyData = mLContext.Data.LoadFromEnumerable(new List<TFShinbaOnnxInput>());
var model = pipeline.Fit(emptyData);
var predictionEngine = mLContext.Model.CreatePredictionEngine<TFShinbaOnnxInput, TFShinbaOnnxOutput>(model);
var input = new TFShinbaOnnxInput();
input.SetValue(_baba, _courseKB, byte.Parse(_jouCD), _kai, _nichi, _tuki, _kyori, _tenko, _tousu, _trackCD, raceDetails);
var prediction = predictionEngine.Predict(input);
って感じにC#でモデルロードして予測が出来ますね😁
もうどの位の期間取り組んできたのか忘れた。相当時間掛かってます。Netronでモデルの情報確認してあれこれ試し、
model.export(save_path)
として保存してたのを
tf.saved_model.save(model, saved_model_path, signatures={"serving_default": serve_fn})
にしても結局何かがダメって言われる。この何かが理解不能でCopilotやGeminiで解決図ったが行き詰った。
public class TFShinbaModelInput
{
[VectorType(1)]
[ColumnName("serving_default_Baba")]
public int[] Baba { get; set; }
[VectorType(1)]
[ColumnName("serving_default_Course")]
public int[] Course { get; set; }
[VectorType(1)]
[ColumnName("serving_default_JouCD")]
public int[] JouCD { get; set; }
...
新馬戦用でも1,018個の特徴量があったりで
var mlContext = new MLContext();
var inputType = typeof(TFShinbaModelInput);
var intColumns = inputType.GetProperties()
.Where(p => p.PropertyType == typeof(int[]) &&
p.GetCustomAttributesData().Any(a => a.AttributeType == typeof(ColumnNameAttribute)))
.Select(p =>
{
var attr = p.GetCustomAttributesData()
.FirstOrDefault(a => a.AttributeType == typeof(ColumnNameAttribute));
return attr?.ConstructorArguments[0].Value?.ToString() ?? p.Name;
})
.ToArray();
var floatColumns = inputType.GetProperties()
.Where(p => p.PropertyType == typeof(float[]) &&
p.GetCustomAttributesData().Any(a => a.AttributeType == typeof(ColumnNameAttribute)))
.Select(p =>
{
var attr = p.GetCustomAttributesData()
.FirstOrDefault(a => a.AttributeType == typeof(ColumnNameAttribute));
return attr?.ConstructorArguments[0].Value?.ToString() ?? p.Name;
})
.ToArray();
var allFeatureColumns = intColumns.Concat(floatColumns).ToArray();
var pipeline = mlContext.Model.LoadTensorFlowModel(Properties.Settings.Default.TF_Shinba)
.ScoreTensorFlowModel(
outputColumnNames: new[] { "StatefulPartitionedCall" },
inputColumnNames: allFeatureColumns,
addBatchDimensionInput: true);
こんな感じでしっかり準備したうえでロードしてるんですが結局ダメでした。
以前確か試した記憶があるんですが、TensorFlowモデルをonnx形式で保存してML.NETでonnx形式を利用する方法を試すべく新たな仮想環境を準備。ってのもtf2onnxはnumpy 2.0以降で削られたnp.castとかの部分がNGでnumpy 1.26.4にダウングレードして試す必要があるようなので、今その環境で新馬戦用モデルの学習してます。それが済んだらonnx形式で保存してML.NETでロードしてまた苦戦する予定😣
2025.7.14 23:02
ひゃ～! onnx形式で行けた😂 これでちょっと先が見えたので、一気に進めます😉
3カ月ぶりに新たな芋焼酎探しの買い物をしました。
楽天の買い回り利用しての購入でしたが
取敢えず甕から試しましたが、まあ、値段的にもですが、美味い。表現難しいけど、角が無くまろやかな甘みがある芋ですね。ただ、値段的にもリピートは微妙。お気に入りのだいやめは12,650円/ケースの送料無料だから。
久しぶりにWMware入れてみようとダウンロードしました。ここ最近はPlayerが個人が無料で利用出来るって事で使ってたんですが、今はProも個人は無料😁 ちょっとビックリでしたが、まあ、ダウンロードしてインストール。
先日からちょいょいやらかしてます。夜勤明けに忘れたり、先週末はひたすらコーディングが気になり、すっかり忘れました。そんな訳で今のストリークが3だったりします😓 それでも継続は力? 本日Amazonギフト600円分頂きました。前回5月14日から49日での達成です。前回が４０日での達成だったので大幅に伸びたのはやらかしてるからですね。でも、継続します。ああっ、楽天はもっと貯めないと交換出来ないので今回は諦めた。でも、今後は検討してみようかと思います。しかし、現時点で確認しても楽天は無くなってる。どうも不安定ですね。
頑張って書いてるんですが時間掛かってます。やる事が多過ぎて時短は厳しい😓
今後この画面にLightGBMやTensorFlow使った予測も入れ込めれば64bit化した恩恵が更に深まる。この辺りは優先的に進めたいと思ってます。特にTensorFlowの予測に期待しているので早い段階で使える事が確認出来れば学習も同時に進められるので効率も良いかも。
BIGって発売当初からほぼ買ってます。まあ、色々とね。これまで末等の数百円とかはありました。普通のBIGは確か末等の次は千円程度の当りもあったかとおもいますが、それなんかも当りって感じではなく、まあ、宝くじの下1桁的な感覚のものですよね。だって開始当初は今の数百円の末等は無く、千円程度が末等だった記憶です。でまあ、今回当たったのは、高額ではないのですが、
開発もしてますよ。
WinUI3のデータグリッドでは基本的にDataGridTextColumnを使いますが、文字の色や背景、ツールチップを追加等は派生クラスをいちいち定義するのが結局一番効率が良いのかな?例えばタイム型データマイニングだと
internal class DataGridTextColumnTimeDM : DataGridTextColumn
{
protected override FrameworkElement GenerateElement(DataGridCell cell, object dataItem)
{
Border border = new Border
{
HorizontalAlignment = HorizontalAlignment.Stretch, // セル内で均等に広がる
VerticalAlignment = VerticalAlignment.Stretch, // 上下も均等に広がる
Padding = new Thickness(5) // 適度な余白
};
TextBlock textBlock = new TextBlock
{
TextAlignment = TextAlignment.Center, // テキストを中央揃え
HorizontalAlignment = HorizontalAlignment.Center, // 左右中央揃え
VerticalAlignment = VerticalAlignment.Center // 上下中央揃え
};
if (dataItem is RaceDetailInfo item)
{
textBlock.Text = item.TimeDM;
// 現在のテーマを取得
var theme = Application.Current.RequestedTheme;
// 文字色を変更
switch (item.TimeDMRank)
{
case 1:
border.Background = new Microsoft.UI.Xaml.Media.SolidColorBrush(SaraD64Constants.BackColor1);
textBlock.Foreground = new SolidColorBrush(Colors.Black);
break;
case 2:
border.Background = new Microsoft.UI.Xaml.Media.SolidColorBrush(SaraD64Constants.BackColor2);
textBlock.Foreground = new SolidColorBrush(Colors.Black);
break;
case 3:
border.Background = new Microsoft.UI.Xaml.Media.SolidColorBrush(SaraD64Constants.BackColor3);
textBlock.Foreground = new SolidColorBrush(Colors.Black);
break;
default: // その他
textBlock.Foreground = new SolidColorBrush(theme == ApplicationTheme.Dark ? Colors.White : Colors.Black);
break;
}
// ツールチップ追加
ToolTipService.SetToolTip(textBlock, item.TimeDMToolTip);
}
border.Child = textBlock; // Border に TextBlock を含める
return border;
}
}
ああ、現在のテーマチェックして一応ダークモードとライトモードで切り替えは自分でやる必要があるっぽい。まっ、テーマ的に全て色を統一してれば自動にって方法があるのかもですが、これまで色にあくまでも近い形にしたいので深く考えずに少しだけ考慮しておこうかと。ただ、実際自分はダークモードしか使わないので、一通り形になった時に念のためにライトモードは試してからリリースしなきゃだなぁっと。
まだまだ全然途中ですが、
滅茶苦茶堅そうだけど、まあ、グランプリだしちょっとだけ参戦😉
ああ、13年程度使ってきた三菱の冷蔵庫が...製氷機能がダメだ。まあ、この冷蔵庫は問題多過ぎで、買った時から気になってたけど、氷庫の裏側に氷が頻繁に落ちる。オフシーズンに氷をあまり使わないとカビが発生する。現在の三菱の冷蔵庫もこの氷が裏側に落ちるらしいので選択肢から排除。うちは元々パナで3台程度ハズレ引いたのでパナも除外してます。残るは日立か東芝か?悩む所ですが、東芝が気になるのは問い合わせ先。フリーダイヤルがあるんですが、携帯電話はナビダイヤル。以前もここに書いた気がするけど、このナビダイヤルに掛けさせる企業の姿勢が本当に疑問。こちらがかけ放題や無料通話アプリでもナビダイヤルは課金されます。なら、普通の固定電話番号を用意してくれた方がどうとでもなる。フリーダイヤルは携帯番号認識して撥ねられる。固定電話なんて既に解約済みです。時代にマッチしない企業にはあまり関わり持ちたくないんですよねぇ。
Windowsフォームアプリでは
var columnNames = new string[]
{
"umaban", "bamei", "kishu", "choukyosi", "tansho", "fukusho", "bataijyu", "mark", "chaku"
};
var columnHeader = new string[]
{
"馬番", "馬名", "騎手", "調教師", "単勝", "複勝", "馬体重", "印", "着順"
};
var columnWidth = new int[]
{
30, 201, 88, 88, 60, 130, 60, 30, 30
};
for (int i = 0; i < columnNames.Length; i++)
{
DataGridViewColumn tbCol = new DataGridViewTextBoxColumn();
tbCol.Name = columnNames[i];
tbCol.HeaderText = columnHeader[i];
tbCol.HeaderCell.Style.Alignment = DataGridViewContentAlignment.MiddleCenter;
tbCol.DefaultCellStyle.Alignment = DataGridViewContentAlignment.MiddleCenter;
tbCol.ReadOnly = true;
tbCol.SortMode = DataGridViewColumnSortMode.NotSortable;
dgv.Columns.Add(tbCol);
dgv.Columns[columnNames[i]].Width = columnWidth[i];
}
って感じでC#で定義してたりしました。素人的にWin UI3でデータグリッド使うにはxamlで
<Grid Grid.Row="1">
<controls:DataGrid x:Name="RaceDetailGrid"
AutoGenerateColumns="False" HeadersVisibility="Column"
CanUserResizeColumns="False" SelectionMode="Single" RowHeight="30" CanUserSortColumns="False"
>
<controls:DataGrid.Columns>
<controls:DataGridTextColumn Header="馬番" Binding="{Binding Umaban}" Width="60"/>
<controls:DataGridTextColumn Header="馬名" Binding="{Binding Bamei}" Width="200"/>
<controls:DataGridTextColumn Header="服" Binding="{Binding Fuku}" Width="80"/>
<controls:DataGridTextColumn Header="騎手" Binding="{Binding Kishu}" Width="120"/>
<controls:DataGridTextColumn Header="調教師" Binding="{Binding Chokyosi}" Width="120"/>
<controls:DataGridTextColumn Header="単勝" Binding="{Binding Tansho}" Width="80"/>
<controls:DataGridTextColumn Header="複勝" Binding="{Binding Fukusho}" Width="140"/>
<controls:DataGridTextColumn Header="馬体重" Binding="{Binding Bataiju}" Width="100"/>
<controls:DataGridTextColumn Header="印" Binding="{Binding Mark}" Width="60"/>
<controls:DataGridTextColumn Header="着順" Binding="{Binding Chaku}" Width="80"/>
</controls:DataGrid.Columns>
</controls:DataGrid>
</Grid>
としてみてたのですが、今後こんなの増えてくるとってのと今回カスタム列タイプも試したのでその為にもスマートに定義が出来ればと思い、Copilotに質問ぶつけて得た方法は
public class DataGridColumnDefinition
{
public string Header { get; set; }
public string BindingPath { get; set; }
public int Width { get; set; }
public string ColumnType { get; set; } // 列の種類を文字列で管理
}
として定義用クラスを用意し、
private void DesignRaceDetailGrid(DataGrid dataGrid)
{
var columnDefinitions = new List<DataGridColumnDefinition>
{
new DataGridColumnDefinition { Header = "馬番", BindingPath = "Umaban", Width = 60, ColumnType = "Text" },
new DataGridColumnDefinition { Header = "馬名", BindingPath = "Bamei", Width = 200, ColumnType = "Text" },
new DataGridColumnDefinition { Header = "服", BindingPath = "Fuku", Width = 80, ColumnType = "Text" },
new DataGridColumnDefinition { Header = "騎手", BindingPath = "Kishu", Width = 120, ColumnType = "Text" },
new DataGridColumnDefinition { Header = "調教師", BindingPath = "Chokyosi", Width = 120, ColumnType = "Text" },
new DataGridColumnDefinition { Header = "単勝", BindingPath = "Tansho", Width = 80, ColumnType = "Text" },
new DataGridColumnDefinition { Header = "複勝", BindingPath = "Fukusho", Width = 140, ColumnType = "Text" },
new DataGridColumnDefinition { Header = "馬体重", BindingPath = "Bataiju", Width = 100, ColumnType = "Text" },
new DataGridColumnDefinition { Header = "印", BindingPath = "Mark", Width = 60, ColumnType = "Text" },
new DataGridColumnDefinition { Header = "着順", BindingPath = "Chaku", Width = 60, ColumnType = "Text" },
};
foreach (var column in columnDefinitions)
{
DataGridColumn dataGridColumn;
switch (column.ColumnType)
{
case "Text":
dataGridColumn = new DataGridTextColumn
{
Header = column.Header,
Binding = new Binding { Path = new PropertyPath(column.BindingPath) },
Width = new DataGridLength(column.Width, DataGridLengthUnitType.Pixel)
};
break;
default:
throw new InvalidOperationException($"未対応の列タイプ: {column.ColumnType}");
}
dataGrid.Columns.Add(dataGridColumn);
}
}
定義しやすさとメンテしやすさと思ってしてみました。
自分自身も期待している部分もあるのでちょっとだけ頑張ってはいるんですが、例えば、アプリの終了です。こんなのこれまでWindowsアプリだろうと、言っちゃえばDOSや他のOSなんかでも普通に終了的にすれば問題無いのに、Win UI3だと違うっぽいです。これで昨晩かなり時間を費やしました。
基本的にWin UI3なら
Application.Current.Exit(); // アプリケーションを終了
とすれば良いってCopilotとかに言われてしても、終了時にエラーが出るしまつorz まあ、そんなのはいつもの事なので、更に突っ込んだ質問ぶつけてもなかなか良い回答は得られずでしたが、結局の所
Process.GetCurrentProcess().Kill(); // アプリを強制終了
とすれば、一応エラー無しで終われる事を確認しました。が、なんでそんな事に時間費やすんだろうって疑問はねぇ^^; まあ、なにやらリソースが解放されてないのがって事ではって話だが、そんなの勝手に処理しろよってね。でまあ、
定義的な話は別として、JRA-VANの有料サービス契約してJV-Linkを使ってデータ取得するのは基本なんです。自分が感じた感覚的な話ではありますが、JRA-VANはソフトウェア開発においては素人の集団でほぼ役に立たないJRAからの天下り的なメンバーなんだと感じます。いや、あくまで外野の感じたフィーリングからなので、実際にはどうなのかは知りませんのであしからず。
そんな事は別にしてJRA-VANが提供するData Labのデータ提供を活用してデータ取得するにはJV-Linkの利用を強要してるのは既成事実。これが32bit環境を強要しているのも事実。何度かここでも書いてますが、AutoMLやLightGBM、多分TensorFlowもなんだと思いますが64bitを要求してます。で、Data-Labの提供データを利用するアプリとしては32bitに制限されるので、ここまではアプリ本体を32bitで行いData-LabのデータをSQLiteに蓄積して利用する方向で、64bitが必要な部分に関しては外部プロセスとして連携する事で実現してきました。
最近やってた事はTensorFlowでの機械学習なんですが、これの実装でまた外部? もう外部多過ぎだよねぇっと考えて、単にJV-Link経由でデータ取得する部分のみ32bitで外部プロセスとしておけば、残りのアプリ本体は64bitで行けるんじゃないかって話です。
で、ここまでWindowsフォームアプリの開発してきました。これってそもそもの始まりは、多分Visual Basicなんだと思います。MS-DOSの時代にMS-DOSに乗せる形で起動してたWindows Version 2.1辺りとかまではアプリ開発も非常にハードルが高く、Cなんかで苦労して色々する所を、記憶的には曖昧ですが、Windows 95辺りでMS-DOSから独立(?)して単独なOSとして動くようになり、アプリ開発をビジュアル的な行える様にしたのがVBの始まりだったと思います。これに慣れているとWin UI3とかでって本当に原始的? この辺りは流石MSです(笑) 最先端OSのWindows 11的なアプリにはWin UI3を使う事でって事の様なんですが、これが本当に地味なもので、ここ最近は何度もトライして挫折の繰り返しorz ただ、今回はちょっと本腰入れての取り組みなので今日も1日やってました。
思う所があり、今ならまだ間に合う? いや、年齢的にね、ここで気合い入れればまだやり遂げられる? JRA-VANのJV-Linkの64bit化について公式は相変わらずの無反応。諸々が64bitでないと動かない為に外部プロセスとして実装試みてきましたが、これが間違った対応だったんじゃないかと思えてきました。JV-Linkを使ってデータ取得する部分は確かに32bitでなければ動きませんが、その取得したデータを64bitのアプリに渡す32bitの外部プロセスを作って64bitアプリから利用するって考えれば、全てがスムーズに行える様に思えてきました。
まあ、64bit化してアプリを作り直すならWindowsフォームアプリではなく、最近のWindows11的なアプリにしていく必要があるかなぁって事でWin UI3になる訳です。これまでにも何度かWin UI3はいじってみたのですが、Windowsフォームに比べたら、まあ所謂Visualって事ではなくコード書くんかい!ってなものね。これが本当に面倒な気がしてますが、楽に開発出来ないのか知りたいです。なので、まっさらな状態からやる事になるので、しばらくは「さらだ」の開発は「さらだ64」目指すので頓挫する可能性もありますし、ちょっと時間頂く事になるかと思います。ってここに書くのも微妙ですが、サポートサイトに書いちゃうと確定事項的に後戻りも出来なくなる気がするので、あえてこちらに書きます。ユーザー様の何人かはこちらにも着て頂いているかと思うので😅
朝から色々やってたら、結局Win5の締切に間に合わずですが、まあ、当たらんから良いか(笑)
継続は力とはよく聞きますが、諦めずにやれる事を続けてきてます。そもそもの原因は自分の理解不足なのは承知してます。更にCopilotに振り回されても耐えられる忍耐と多分知力かなぁ。まあ、なんにしてもRMSEが38辺りでって問題は突破出来た。簡単に言えば、層の構築方法に問題があった模様です。
って事で、本来のデータを使った訓練スタートしてます。相変わらずのサイズなので38分/epochで50epochsを試してますので32時間弱かな。明日夜には終わる予定なので、そこまで無難に訓練されていれば良いのですが、数値的に問題があったりしたら中断するかもです。現時点では3epochがRMSE 18辺りなんですが、少なくとも明日朝にはRMSE 2未満になっている事を期待したいかな。
で、まあ、これが順調に終わったと仮定すると、新馬戦用、通常用、順位予測の3本建てのモデルが揃うってか、そもそも新馬戦用と通常用が出来た時点で、これを使った順位予測用学習データ出力にしなければならなくて、それを使って順位予測の訓練をする必要もある。この辺りをまとめて外部プロセスとしてLightGBMでも作った感じのものをTensorFlow用にも作成してアプリに同胞出来る様に仕上げる訳ですが、ダービーには間に合わないorz
それでもそれ仕上げるのとUI変更なんかもこれから徐々に進めてもう少しだけ良いものになればと思ってます。まだまだやる事が山ほど有るな😓
追記 2025.5.25 7:44
あと少しで29epochが終わりますがRMSEはやっと16未満になる辺り。ただ、じりじりと下がってはいるので回数が必要なんだと。順位の時だったか500epochを5日半とか掛けてやりましたが、この通常用でやると13日ちょい掛かるって2週間ぶん回すのはキツイなぁ。電気代もそうだけど、このポンコツPCにトドメ刺しそう。しかもね、これ、そこまでやって本当に良い結果が得られる保証は無い。単純計算では2週間このポンコツ(750W電源使用)回すと７千円以上の電気代になるっぽい。アイドル状態ではなく、機械学習してるとほぼPCのファンがうるさい状態って事はかなり電気は消費してると思われますしね。
こちらにも何度も書いてますが、Microsoft Rewardsはほぼ欠かさず参加してます。夜勤で、人数調整の為に半日有休で帰宅して、日付が変わっているので本日分の「日々のセット」内のクイズで
何をどうするとこんな事になるんだろ? ４０年以上前に"Where are you from?"ってアメリカ人に聞かれて"From Japan."と答えると"Hong Kong?"って...遥か遠くのアジアの話ならってのも本来微妙だけど、自国の話でしょ? いや、もしかしてこの問題作ったのはMicrosoftとは無関係でアメリカとは無縁の場所の方が?
TensorFlowの理解が全く進まない。
これが現時点の問題で、5epoch辺りで収束してそれ以上改善されない。先週はこれに挑んで、まあ、こんなグラフ出力までしても何の改善方法も見つけられない。昨夜久しぶりに新馬戦用の訓練もしてました。20時間弱で500epochsをこなし、見てる限りはRMSE 2.0辺りまで行ってましたが、最終的な表示は8.9とかだったかな? これはなんか計算方法間違えてるのかは疑問だが、それでも500回でもまだモデル自体は収束ってまあ、確かになかなかそれ以上は進まない感じながらもじりじりとで、たった5回程度で収束方向ってのとは違う。
今回改めて新馬戦用の訓練を実行したのは、Anacondaの仮想環境の再構築ってか、そもそも以前ちょっと試してダメだったGPUの力を少し試すってのをね、まあ、うちのPCは今年の夏には丸７年になるポンコツで、NVIDIA GeForce GTX 1050Tiに4GBメモリなZOTAC ZTGTX1050TI-4GD5MINI001/ZT-P10510A-10って18,800円のグラボしか載ってないのでほぼ助けにはならないのは覚悟でCUDAとcuDNNを以前インストールしたらVisual Studioの動きに支障があったのでアンインストールして放置してたんですが、
をインストールして仮想環境を再構築しました。今回は一応NVIDIA公式のCUDA Installation Guide for Microsoft Windowsを参考に
conda install cuda -c nvidia
としてAnaconda側でもCUDAを入れて
python -m pip install --upgrade setuptools pip wheel
とする事で
python -m pip install nvidia-pyindex
これが出来る様になるらしい。で、仮想環境を構築する準備が出来たので仮想環境をPython 3.9で作成して
をpip使って入れて、新馬戦用はこれで足りますが、通常版ではグラフ出したりするので更に
も入れてます。
でも、ここまでしても流石にグラボの恩恵はほぼ感じられない😞
層毎のユニット数調整では顕著な変化は見られなかったので新たな試みとして
をCopilotの助言を元に施してみました。
from tensorflow.keras.layers import Activation, BatchNormalization
x = Dense(256)(merged_features)
x = BatchNormalization()(x)
x = Activation('relu')(x)
x = Dropout(0.3)(x)
x = Dense(128)(x)
x = BatchNormalization()(x)
x = Activation('relu')(x)
x = Dropout(0.3)(x)
x = Dense(64)(x)
x = BatchNormalization()(x)
x = Activation('relu')(x)
uma_networks.append(x)
これが特徴量の正規化追加した部分で
from tensorflow.keras.optimizers import Adam
# 学習率を指定
initial_learning_rate = 0.001
lr_schedule = tf.keras.optimizers.schedules.ExponentialDecay(
initial_learning_rate, decay_steps=10000, decay_rate=0.9, staircase=True)
optimizer = Adam(learning_rate=lr_schedule)
# モデルをコンパイル
model.compile(optimizer=optimizer, loss='mse', metrics=['mae', root_mean_squared_error])
これがExponentialDecayを利用して
としているらしい。50epochsで既に開始して、今までだとRMSE 38辺りが限界値的に得られた程度だったんですが、7epoch辺りで到達してここから更に良くなるかが気になる所です。まあ、CopilotにはDropout(0.3)はちょっと大きいのでDropout(0.2)にしてみてはってアドバイスも頂いてるので、それも試そうとは思ってます。
ここ最近はTensorFlowに労力全て持っていかれて他に手が回らない状態が続いてます。やりたい事は山ほどあるけどってのと、やはり現在のPCの能力の低さが痛いです。
まあ、そんな中でも久しぶりに現在のLightGBMの今年の検証をしてみました。2025.1.1～2025.5.11分です。
| 1,227R | 1点 | 芝(529R) | ダート(652R) | 障害(46R) | 8頭以下(48R) | 9～12頭(265R) | 13頭以上(914R) | 多点 |
| 単勝 | 23.63% (87.19%) |
21.36% (98.07%) |
25.15% (78.68%) |
28.26% (82.61%) |
47.92% (136.87%) |
28.30% (85.06%) |
21.01% (85.20%) |
53.14% (85.47%) |
| 複勝 | 51.26% (83.46%) |
48.02% (85.44%) |
53.53% (82.15%) |
56.52% (79.35%) |
66.67% (92.71%) |
55.85% (81.55%) |
49.12% (83.53%) |
85.82% (80.81%) |
| 枠連 | 13.43% (92.55%) |
11.09% (86.00%) |
15.17% (99.32%) |
12.82% (60.00%) |
-- (--) |
14.72% (66.98%) |
12.36% (95.21%) |
27.83% (80.83%) |
| 馬連 | 9.13% (71.43%) |
6.62% (53.91%) |
11.04% (86.92%) |
10.87% (53.48%) |
10.42% (33.96%) |
11.70% (71.70%) |
8.32% (73.33%) |
19.48% (68.45%) |
| ワイド | 19.89% (76.42%) |
16.07% (63.40%) |
22.09% (83.97%) |
32.61% (119.13%) |
29.17% (51.67%) |
26.42% (74.68%) |
17.51% (78.23%) |
39.61% (72.15%) |
| 馬単 | 5.54% (75.24%) |
4.73% (87.73%) |
5.98% (65.32%) |
8.70% (72.17%) |
10.42% (67.08%) |
7.55% (89.47%) |
4.70% (71.54%) |
19.48% (69.32%) |
| 三連複 | 4.07% (49.41%) |
3.59% (24.52%) |
4.29% (67.87%) |
6.52% (73.91%) |
10.42% (63.96%) |
7.92% (65.81%) |
2.63% (43.88%) |
11.74% (56.12%) |
| 三連単 | 0.81% (21.65%) |
0.76% (15.33%) |
0.92% (28.31%) |
0.00% (0.00%) |
4.17% (93.75%) |
1.89% (48.30%) |
0.33% (10.14%) |
11.74% (52.80%) |
| 総合 | 52.97% (69.45%) |
50.28% (63.94%) |
54.91% (73.98%) |
56.52% (67.73%) |
72.92% (77.14%) |
56.98% (72.94%) |
50.77% (67.63%) |
86.31% (62.51%) |
| 1,272R | 1点 | 芝(548R) | ダート(678R) | 障害(46R) | 8頭以下(48R) | 9～12頭(268R) | 13頭以上(956R) | 多点 |
| 単勝 | 21.31% (81.12%) |
18.07% (88.14%) |
23.30% (74.16%) |
30.43% (100.22%) |
37.50% (100.83%) |
24.25% (90.63%) |
19.67% (77.47%) |
50.79% (89.18%) |
| 複勝 | 50.47% (84.58%) |
47.45% (86.04%) |
52.36% (83.11%) |
58.70% (88.70%) |
62.50% (86.67%) |
58.21% (94.63%) |
47.70% (81.65%) |
84.75% (82.22%) |
| 枠連 | 12.06% (87.98%) |
9.81% (78.37%) |
13.66% (94.01%) |
12.82% (104.10%) |
-- (--) |
13.43% (62.76%) |
11.09% (90.72%) |
26.00% (74.86%) |
| 馬連 | 8.25% (70.29%) |
6.20% (66.48%) |
9.88% (75.37%) |
8.70% (40.87%) |
10.42% (33.96%) |
10.82% (74.48%) |
7.43% (70.94%) |
18.79% (107.09%) |
| ワイド | 18.63% (74.61%) |
16.06% (72.17%) |
20.06% (76.00%) |
28.26% (83.26%) |
33.33% (59.79%) |
26.49% (87.16%) |
15.69% (71.84%) |
39.62% (81.72%) |
| 馬単 | 4.32% (58.28%) |
3.28% (58.70%) |
4.87% (56.99%) |
8.70% (72.17%) |
10.42% (67.08%) |
5.22% (71.57%) |
3.77% (54.11%) |
18.79% (111.78%) |
| 三連複 | 3.38% (40.63%) |
3.47% (29.69%) |
3.39% (49.66%) |
2.17% (37.83%) |
14.58% (96.04%) |
5.22% (45.56%) |
2.30% (36.46%) |
10.30% (48.55%) |
| 三連単 | 0.71% (44.70%) |
0.36% (8.21%) |
1.03% (77.23%) |
0.00% (0.00%) |
4.17% (93.75%) |
0.37% (5.11%) |
0.63% (53.34%) |
10.30% (47.10%) |
| 総合 | 52.20% (67.58%) |
49.45% (60.70%) |
53.98% (73.24%) |
58.70% (65.15%) |
66.67% (76.88%) |
59.70% (66.49%) |
49.37% (67.07%) |
85.06% (67.29%) |
決して褒められたレベルではないのは確かです。まあ、だからTensorFlowに期待して作業進めてるんですがね。
追記 2025.5.18 10:36
比較としてモデルビルダーも載せておきます。
| 1,227R | 1点 | 芝(529R) | ダート(652R) | 障害(46R) | 8頭以下(48R) | 9～12頭(265R) | 13頭以上(914R) | 多点 |
| 単勝 | 21.35% (84.25%) |
17.58% (75.60%) |
24.69% (93.17%) |
17.39% (57.39%) |
31.25% (125.00%) |
22.64% (77.25%) |
20.46% (84.15%) |
49.47% (77.12%) |
| 複勝 | 51.02% (85.97%) |
45.75% (78.36%) |
55.06% (92.71%) |
54.35% (78.04%) |
60.42% (91.67%) |
56.23% (84.83%) |
49.02% (86.01%) |
85.90% (83.74%) |
| 枠連 | 12.01% (77.44%) |
9.57% (66.93%) |
13.27% (73.78%) |
20.51% (260.77%) |
-- (--) |
15.09% (99.40%) |
10.50% (67.09%) |
27.03% (91.36%) |
| 馬連 | 7.17% (59.21%) |
5.29% (45.82%) |
8.44% (61.18%) |
10.87% (185.22%) |
10.42% (79.37%) |
10.19% (88.49%) |
6.13% (49.66%) |
19.32% (76.03%) |
| ワイド | 20.95% (86.59%) |
18.15% (80.95%) |
23.31% (90.05%) |
19.57% (102.39%) |
35.42% (96.04%) |
27.92% (94.94%) |
18.16% (83.67%) |
40.34% (80.47%) |
| 馬単 | 3.83% (54.95%) |
2.65% (46.18%) |
4.91% (64.48%) |
2.17% (20.65%) |
6.25% (117.92%) |
4.91% (71.55%) |
3.39% (46.83%) |
19.32% (71.10%) |
| 三連複 | 5.05% (78.08%) |
4.73% (92.31%) |
5.52% (71.15%) |
2.17% (12.83%) |
6.25% (32.92%) |
7.55% (73.09%) |
4.27% (81.90%) |
13.77% (74.77%) |
| 三連単 | 0.73% (41.21%) |
0.38% (59.77%) |
1.07% (29.05%) |
0.00% (0.00%) |
0.00% (0.00%) |
0.38% (5.17%) |
0.88% (53.82%) |
13.77% (76.23%) |
| 総合 | 52.73% (70.90%) |
47.64% (68.26%) |
56.60% (71.94%) |
56.52% (86.34%) |
68.75% (77.56%) |
57.74% (74.34%) |
50.44% (69.14%) |
86.63% (77.05%) |
| 1,272R | 1点 | 芝(548R) | ダート(678R) | 障害(46R) | 8頭以下(48R) | 9～12頭(268R) | 13頭以上(956R) | 多点 |
| 単勝 | 19.42% (73.78%) |
15.15% (61.15%) |
23.01% (85.90%) |
17.39% (45.65%) |
33.33% (126.25%) |
22.01% (71.31%) |
17.99% (71.84%) |
48.98% (75.59%) |
| 複勝 | 48.51% (82.84%) |
42.15% (76.51%) |
53.10% (88.41%) |
56.52% (76.09%) |
62.50% (93.13%) |
53.73% (86.27%) |
46.34% (81.36%) |
85.46% (84.03%) |
| 枠連 | 12.15% (80.00%) |
10.44% (81.52%) |
13.35% (77.97%) |
12.82% (95.64%) |
-- (--) |
17.91% (109.85%) |
9.94% (67.70%) |
25.74% (86.78%) |
| 馬連 | 7.86% (79.50%) |
6.39% (65.73%) |
9.14% (92.57%) |
6.52% (50.87%) |
12.50% (94.37%) |
12.69% (104.14%) |
6.28% (71.84%) |
18.71% (77.90%) |
| ワイド | 20.60% (93.10%) |
17.52% (82.79%) |
23.16% (101.80%) |
19.57% (87.61%) |
33.33% (85.42%) |
27.99% (99.25%) |
17.89% (91.76%) |
39.15% (85.33%) |
| 馬単 | 4.01% (86.53%) |
3.65% (82.96%) |
4.57% (95.28%) |
0.00% (0.00%) |
8.33% (140.21%) |
6.34% (115.34%) |
3.14% (75.75%) |
18.71% (71.69%) |
| 三連複 | 5.11% (94.65%) |
4.20% (84.23%) |
6.19% (109.50%) |
0.00% (0.00%) |
6.25% (37.50%) |
7.46% (99.48%) |
4.39% (96.17%) |
13.92% (96.15%) |
| 三連単 | 0.86% (55.42%) |
0.73% (83.89%) |
1.03% (36.17%) |
0.00% (0.00%) |
0.00% (0.00%) |
1.49% (84.22%) |
0.73% (50.13%) |
13.92% (102.51%) |
| 総合 | 50.39% (80.73%) |
44.34% (77.28%) |
54.72% (85.98%) |
58.70% (43.49%) |
68.75% (82.41%) |
56.34% (96.23%) |
47.80% (75.82%) |
85.93% (91.96%) |
若干ではあるがモデルビルダーの方が回収率が良いので買うならこちらかな😅