kmycode / kmy-keiba Goto Github PK

現状は三角形を使っているが、直線の時は長方形に変えたい

予想の場合は騎手、調教師のデータが見られるけど
結果画面は、特に表示するものがないのでは

レース結果のコーナー順位から内・外のどちらに出やすいかを数える
上り坂、下り坂によって違うかもしれないから見ておきたい

３歳・４歳未勝利などよりもどうでもいいレースという印象を与えてしまう

それぞれの距離適性ごとの得点を計算できればなおよい

#19 の平地版

タイム・脚質・荒れ度などでボタンを分けるのをやめて、
「傾向分析（←ここに計算後のデータをまとめる）」「対象レース一覧」の２画面だけでいいのではないか

「３歳」「４歳」と表示されてるのに水色とオレンジのものが混在しているのが特に多い

坂で「追い越した回数―追い越された回数」を、上り・下り別に計算する

地方競馬DATAのNVCloseメソッドの呼び出しが完了せず、以下の処理が実行できない。
現状は地方競馬情報を取得するときに限り、Closeメソッドを呼ばないようにしている。ただしそのまま続けてOpenを呼び出すと、AlreadyOpenエラーが起きる。
いったんアプリを終了して再度起動した場合、Openはできる。

将来的に、メインアプリでデータをダウンロードする場合はDownloaderアプリを起動するという運用を想定している（メインアプリは64bitであり、64bitだとUmaConnが動作しないため）ので、現状開発に影響はないが、Closeしないままアプリを終了するというのもなんだか気持ち悪い

想定される原因

Open、Gets、Closeメソッドを同じスレッド上で実行していない

対処したがだめだった。対処漏れがあるかもしれない
EntityFrameworkをはじめとしたどっかのフレームワークやライブラリの内部でConfigureAwait(false)をやっているのでは？調査が必要

このようなプログラムになっているので、await this.LoadAsyncの中のどこかにConfigureAwait(false)が１つでも混じっていればDisposeメソッドの呼び出しは別スレッドになってしまう

            using (var reader = link.StartRead(dataspec,
              option,
              this.StartTime.Value,
              this.IsSetEndTime.Value ? this.EndTime.Value : null))
            {
              await this.LoadAsync(reader, loadSpecs, true, false);
            }

想定される理由その２

エントリーポイントに[STAThread]をつけていない。
今度試してみる

#17 とどちらか片方を次verまでに実装するかな

坂道が他の馬より弱い　マイナス２ポイント　みたいな感じで
ポイントの数字は適当　後で調整する　タイム指数をポイントに加算してから比較する感じ？

数文字でかまわないのでなんか生成する。
どこで失速したか、追い上げがすごかったかなど
record構造体にenumやパラメータを保存して、ToStringによってコメント出力できると理想的

コーナー通過順位で複数馬の集団に入った馬が、次のコーナー通過順位で同じ集団に入っている他の馬より先になっていた回数、またはその馬数など

結果画面に表示しても意味ないように思える

ユーザーはとかく長い処理中は離席しがち。

現状のダウンローダでは、一度ダウンロードに失敗すると
未ダウンロードのデータを処理しないまま途中で終わってしまうようになっているので、
エラーが起きても最後まで処理されるよう修正する必要がある

ここを作る

着順リスト、払い戻し

でもってもともとの脚質とは別の変数に入れたい
RaceHorseDataクラスで、RunningStyle（レース結果から推測した脚質評価）とExpectedRunningStyle（レース前にユーザーが予想した脚質）を共存させる感じ

ただし本アプリの展開予想機能は、上書きした脚質をもとに予想処理するようにする

現状、簡易的に途中まで作っているのでこれを完成させる

予想のときには標準偏差も使えると望ましい

この画面を作る

脚質の組み合わせによる展開予想、タイム指数、後３ハロン指数
前走、騎手成績、調教師成績などやりたい
後でissue分ける

専門知識がなくてもインストールできるようにしたい

64bitアプリから32bitアプリを起動する方法→cmd /c downloader.exe

情報を交換する方法、おそらくファイルでやり取りする。WCFは使えない
標準出力は使えないか調べる

ダウンローダを常時起動して情報をファイルまたは標準入力でやり取り、か？

JVLinkと同じ方法でNVLinkでデータ取得期間を指定した場合、
「２０１５年から２０１８年までのデータ」を取得しようとしても、
「２０１５年から２０２２年（プログラム実行時点の最新）までのデータ」を取得しようとしてしまう。

データの更新時刻が範囲外であれば取得しない処理が対策として考えられるが、
**競馬（JVLink）でも終端時刻を指定してもまれに範囲外のデータが取り込まれるケースがあるので、
その発生条件を特定できない限り、上記処理を安易に付け足すのはあまりよくないのではないかと。
最終的には、更新時刻だけでなく例えばレースのIDの中に入っている日付も分岐に使うべきか。

原因として、JVLinkとNVLinkで細かい仕様が異なるというのが考えられるが、NVLinkのマニュアルが入手できてないので詳細は不明

基本は、坂路・ウッドチップ調教の成績、体重増減から推測
ユーザーが自分で設定できる機能があればなおよい（パドックとかのデータは取得できないため）

それぞれ**競馬の重賞／地方競馬の一般レースとなっているが、完全にレベルの異なるレースであり、同じ色を使うと誤解を生みやすい

ラップタイムを追加
結果を削除

予想脚質から展開を考える
タイム指数、上がり指数から、その脚質を維持できるか・最後の直線でいけるかを、時系列でシミュレートする

シミュレーション画面で、予想脚質、天気などを変えられればなおよい

起動しないとファイルの削除ができない

JV-Link使わずDBだけで完結する処理は、メインアプリ内で直接実行するようにしたい

JV-Link、NV-Linkから配信されるデータとは別に、ユーザーが自分で天気や馬場を書き換えられ、それをもとにして予想できる機能
もちろんRaceDataクラスにおいて、本来の天気・馬場とは別の変数を新設し、そこに保存する