TKGは暇を持て余す

高時給バイトのフリーターしながらゆるゆると生きている頑張らない系趣味日記

バルミューダのパンを焼くアレ

こんにちわ。たかぎです。

みなさんも一度は聞いたことくらいはあるのではないでしょうか。バルミューダのパンを焼くアレを使う機会があったのでレビューをします。すでに世界中でレビューされつくしているものですが、実際のところどうなのか、素直な感想を書きたいと思います。

 

これです。

 

Amazonのレビューをみると今までのパンが見違えるように美味しくなっただの、今までのトーストには戻れないだの色々かいてありますがそれだけで買える値段ではないですよね。

ところでみなさん「いつどこで見たのかも分からないけれど、なんか頭の中にある噛むとサクっとした食感のトーストが食べたい。」こんなことを思ったことは無いでしょうか。僕はあります。

 

急に何だと思ったでしょうが、この「外はかりっと、中はもっちり」を叶えてくれるのがこのトースターです。焼いている様子を見るとわかりますが、この機種のトーストモードは規定量の水を居れて庫内が曇った状態でヒーターのON/OFFを切り替えながら最後数十秒で外側をカリっと焼くというきっと何回も研究したんだろうなあという焼き方をしています。そのため、安いパサパサの食パンを焼いても素敵な食感のトーストが焼き上がります。やや厚めの食パンを推奨時間の上限くらいで焼くのがいい感じになると思います。その出来栄えは、まさに頭の中にあるサクサクもっちりなトーストそのものだと思います。それが焦げることもパサパサになることもなく簡単に焼き上がるのはこのトースターの魅力でしょう。

しかしやはり高い値段を出して買う価値があるのかと言われると、個人的にはそうは思いません。確かに食感は素晴らしいですが、トーストはトーストです。味はほとんど食パンに依存します。

 

「確かにサクサクもっちりだけれども、決して焼いた食パンの域は出ない。」

 

これが僕の結論です。

毎日のようにトーストを食べる人でいつでもサクサクもっちりのトーストが食べたいような人でないとわざわざこの金額を出して買うことは無いと思います。あるいは旅館のモーニングで食パンをセルフで焼くために置いてあったらいいなとは思います。ただ、たまに食べるトーストのクオリティを上げるために出す金額では無いと思いました。

結論：開発者のトーストにかける情熱はすごいと思います。あとデザインは悪くないです。でも自分で買うことは無いと思います。贈り物でもらったらちょっとうれしい。

小規模事業所の勤務シフト作成自動化アプリ（遺伝的アルゴリズムを用いた最適化問題の解決）

おひさしぶりです。たかぎです。

久しぶりに更新したかと思ったら調子に乗って２記事も書きました。

 

先日いつも行っている美容院にいったところオーナーさんが「今日は野郎しか居ねえなあ」と言ってました。聞くとアシスタントさんは大体男女同じくらい出勤するようにシフトを組んでもらってるみたいですが、その日はたまたま男ばっかりになってたそうな。

シフトはスタッフさんが作ってオーナーがチェックするようですが毎月かなりの労力がかかって困っているとのこと。以前遺伝的アルゴリズムを用いた最適化の手法がシフト作成に使えると何かで見て知っていたことと、最近ポケモン自動化のためにPython触っていて頑張ればできそうだし勉強になるかなと思ったのでちょっと作ってみることにしました。

 

とりあえず遺伝的アルゴリズムの手法についてゆーちゅーぶ先生に教えてもらい、システムの要件をまとめてChatGPTに投げました。勉強になるとか言ってコード書いてないやん。

とはいえ、いきなりコード全体を作ってもらうのは無理なので、開発に必要なステップを（ChatGPTに聞いて）決めて、必要な機能を（これも聞いて）細かく分けて、それぞれのクラス、メソッドを１個ずつ作ってもらいました。そしてさいごにそーれがっちゃんこ。整合性が取れてなくてエラーの出る部分を再度ChatGPTに該当部分のコードを投げて直させて出来上がり。約900行のコード、40~50時間くらいでできたと思います。素人にしては早く出来たと思います。今月apex始めてプレイ時間が既に100時間余裕で突破したのを考えると安いもんですね。ちなみに作業時間のうち9割以上は仕事中に作ってました（？）自宅での作業時間はほぼゼロです。

 

で、出来上がったのがこちら

従業員管理から従業員情報を入力して、年・月を選んでシフト作成開始。

店の休みの日、希望の休日、従業員ごとの休日日数をセットしてシフト作成ボタンをポチッと。

 

動作はこんな感じ（確認用に動作回数を減らして試行回数1回で終わるようにしてます）

数回の試行後最も評価の高いバイトのシフト表が出力されるので、あとは人の目で確認して変えたい部分をちょっと変えればOKです。１から考えるよりははるかに楽になるはずです。

評価関数や社員属性は美容院用につくってあるのでこのまま他の事業所には使えませんが、設定をちょっといじるだけなので変更自体は簡単です。

 

という感じでシフト表自動作成プログラムを作ってみました。月数千円出せば専門家が作った高機能なアプリがあるっぽいんですけどね。

 

試作段階なのと事業所ごとに条件の設定が必要なので一般公開の予定はありませんが、必要としている方がいればTwitterでご相談ください。お安くしておきます。

 

備忘録 pandas,pandastableにおけるDataFrameオブジェクトのkeyerror

おひさしぶりです。たかぎです。

 

ちょっと知り合いに頼まれてアプリ開発をしていましたが、pandastableのDataFrameオブジェクト内でセルに直接値を入力しようとしたところ、keyerror(整数値)というエラーが返ってきてデータが編集できないという問題が発生しました。

 

ChatGPTにpandasとpandastableのエラー箇所のソースを提示して原因を聞いたところ

 

こんな感じで原因をさくっと教えてくれました。

要するにpandastable内の表の行や列のラベルに整数値の名前をつけるとプログラムが列位置なのか列の名前なのかわからなくなってエラーが発生するということみたいです。

 

panastable自体があんまり使われてないせいか日本語で調べても情報に辿り着けなかったのでいつか誰かの役にたてばと思って記事にしておきます。それにしてもChatGPT便利ですね。

備忘録（pandastableのDataFrameオブジェクトのkeyerror)

おひさしぶりです。たかぎです。

 

ちょっと知り合いに頼まれてアプリ開発をしていましたが、pandastableのDataFrameオブジェクト内でセルに直接値を入力しようとしたところ、keyerror(整数値)というエラーが返ってきてデータが編集できないという問題が発生しました。

 

ChatGPTにpandasとpandastableのエラー箇所のソースを提示して原因を聞いたところ

 

このコードを見ると、self.currentcol が列の位置（0から始まるインデックス）を参照していることが明確になります。これが self.model.getColumnType(self.currentcol) で使用され、そこでエラーが発生しています。

したがって、エラーの原因は、getColumnType() 関数が列位置を引数として受け取り、列名を取得しようとするため、整数の列名と列位置が混同されている可能性が高いです。

対策としては以下のようなものが考えられます：

  1. getColumnType() の定義を見て、列位置ではなく列名を正しく参照できるように改修する。つまり、この関数は列名を引数として受け取るべきです。

  2. handle_arrow_keys() の coltype = self.model.getColumnType(self.currentcol) の部分を改修して、列名を引数として渡すようにする。つまり、列位置（self.currentcol）から列名を取得するための変換が必要です。

以下のようなコードで列名を取得できます：

python
column_name = self.data.columns[self.currentcol] coltype = self.model.getColumnType(column_name)

ただし、この改修によって getColumnType() が列名を期待している他の箇所に影響を及ぼす可能性があるので注意が必要です。また、getColumnType() 関数がどのように定義されているかを確認することも重要です。この関数が列位置を受け取るように設計されている場合、この改修は機能しないかもしれません。

 
User
元々のDataFrameのラベルを変更して、列位置と混同されないように整数値を含まないラベルに変更することでもエラーは回避できますか
 
 
ChatGPT

はい、そのアプローチも可能です。

あなたのDataFrameでは、1から31までの整数値が列の名前として使用されています。これは列の位置と混同される可能性があるため、これを避けるために列の名前を文字列に変更することができます。

例えば、以下のように「日」という文字列を加えることで列の名前を文字列に変えることができます。

python
# Rename the columns to be 'Day1', 'Day2', etc. self.data.columns = ['名前', '職種', '性別'] + [f'日{day}' for day in range(1, days_in_month+1)] + ['休日数']

上記のコードは、日付を表す列の名前を '日1', '日2', '日3', などに変更します。こうすることで、列の位置と列の名前の混同を避けることができます。

ただし、列の名前を変更すると、その後のコードで列を参照する際にも変更を反映させる必要があります。この変更が他の箇所で予期しない影響を及ぼさないように注意してください。

 

こんな感じで原因をすぐに教えてくれました。

日記

対戦AI作りたいんだけど難しいので勉強だけしてます。強化学習でやらなきゃ無いけど大変そう。AlphaZeroのアルゴリズムをしっかり理解するレベルまでいくのが夢、無理。

対戦補助ツールはちょこちょこ機能追加とかをしてるんですが、まだ追加したい部分はあるんだけど使用感にはある程度満足してしまってるからモチベーション低下中です。誰かに使ってもらってデバッグと追加機能のリクエストとかもらえるといいんですが…出来ればPython開発環境が使える方が良いけどあんまり居ないのでこれはどっちでもいいです。協力してくれる神様が居ればDM下さい。一般公開はデバッグも十分ではなくおおっぴらに出せる形でのビルドが面倒くさすぎるのでまだ予定ありません。

 

減量中でエネルギー枯渇してて眠すぎるので早寝します。おやすみなさい。

ポケモン対戦アシストツールを作りたい　進捗報告②

たかぎです。ツールの大枠が出来てきたので進捗報告です。

 

 

前回（https://hokkesan.hatenablog.jp/）からの進捗として

・持ち物、特性、天気etc基本的な部分の実装（全部ではない）

・技を最大９個まで予め登録しておいてワンクリックで相手の色々な型に対するダメージ計算を行う

・PT登録時の挙動の改善

なんかを進めていました。特にダメージ計算部分について対戦での頻度の多いものに関してはほぼ出来上がったのが大きいです。これにより対戦中のダメージ計算の速度が大幅に向上しました。上の画面は古代活性でSが上がるトドロクツキが晴れハチマキ炎テラバーストでハリテヤマを飛ばせるかどうか計算しているところです。H振りに対して93.23~98.96%で相手の残りHPが89.64％なので確定で落とせるとわかります。ハリテヤマはHAだと仮定すれば火炎玉の火傷ダメが１回入っていれば概ねOKでしたね。

こちらは同じトドロクツキとイーユイの対面です。イーユイのHPはステロを踏んだあとなのですが解像度と相手のHP実数値の関係で微妙に誤差が出ます。実際の対戦ではSが上がったテラバーストで上から落とすことが出来たので相手はおそらくCSスカーフだったのかなと思います。

パーティー登録画面はこんな感じで

ｐｔ単位で登録出来るようになっています。ポケモン名と技名は入力補助があります。

ポケモン単位でも登録して組み合わせて構築を保存出来るようになると便利そうですが面倒くさいので気が向いた時にでも…

 

今後の予定は

・２発以上の攻撃での確定数と確率の表示

・ポケモンHOMEの情報の取得

・被ダメージ機能の作成（相手の技選択肢をどうするかが問題）

・CUDAを使用したGPUアクセラレーションの実装（優先順位低め）

・相手のHP残量をメモするボタンが今は手動ですが最初の１回だけ押せばあとは自動になるように変更（誤認識回避のため読込みのマージンを取る必要があるので読込みに時間がかかってしまうから微妙かも、オンオフ選べるようにしてもいい）

こんな感じのアップデートを考えています。

 

あとは平行してTesseract-OCRの追加学習プロジェクトを進めていくのですが、教師データとしてポケモンのゲーム内での文章の画像が大量に必要です（数百枚～）

できるだけいろいろな語句を含む文章を集めたいのでもし協力してくれる方がいると嬉しいんですが需要がなさそうなのでアレ

ぼちぼち進めて行きますが応援してもいいよって方はイイねもらえるとやる気がでます

バグ残ってるので動作の保証はできませんが使ってみたい方は個別にご相談頂ければ対応します

ではまた～

わざわい系の特性とこだいかっせい/クオークチャージの関係

備忘録です。

ツイートもしました一応検索にも引っかかりやすいように？日記にもしておきます。

わざわい系の特性（わざわいのうつわ、つるぎ、おふだ、たま）で能力が下がった時、こだいかっせい/クオークチャージは下がった能力を考慮したうえで上がる箇所が決まるのかどうかでダメージ計算ツールのプログラムがだいぶ変わるので調べてみましたが誰も情報をつぶやいて居ませんでしたので検証しました。

 

動画のテツノコウベはとくこう145,すばやさ121なのでとくこうが3/4(3072/4096)になればとくこうは108となります。クオークチャージがわざわい系の影響を考慮するのであればすばやさが上がるところですが上昇したのは特攻でした。つまり、こだいかっせい/クオークチャージはわざわい系の影響を無視して上昇箇所が決定するようです。（条件を色々と変えて試したわけではないので確かなことは言えませんが…

 

参考になれば幸いです。