Programming – nibuiroフラグメント β

Dark side of Boost C++

話自体は2年前なのですが, 重み付きサンプラーを探していましてね?Boost C++に入門するかーと.

https://www.boost.org/doc/libs/1_71_0/boost/compute/random/discrete_distribution.hpp

あ, ダメなやつ. と.


修正されていると思ったのですがね… Current Release “August 19th, 2019 15:31 GMT”
Boostに頼る前に標準ライブラリを使いこなしているのかと.
利用者にあの大きなライブラリをインストールさせて申し訳ないと思わないのですか?

Boost C++は爆速アルゴリズム集ではない

NN構築の失敗談

逐次更新…(笑 えない。

Pytorch

ResidualNet

RuntimeError: Given groups=1, weight of size [16, 3, 3, 3], expected input[30, 16, 101, 101] to have 3 channels, but got 16 channels instead

 BCHW: ネットワークの頭、中間のレイヤでsumの操作を加えるときにショートカット側で畳み込みしておかないとチャンネル数(フィルタ数)が合わずにエラーが吐かれる。
 

ValueError: Target and input must have the same number of elements. target nelement (16384) != input nelement (65536)

 BCHW: ネットワークの出力がターゲットのサイズと合致していないと吐かれる。適当なサイズ/数でPoolingするなどしてダウンサンプリングする。

Keras (TF backend)

DenseNet-BC

TypeError: __init__() got multiple values for argument 'axis'

 BHWC(恐らく): 畳み込みレイヤの出力をConcatenateを用いて連結させようとしたところ吐かれた。詳細は確認していないがconcatenateを代用することで解決。
 

ValueError: Negative dimension size caused by subtracting 2 from 1 for 'pool4/AveragePooling2D' (op: 'AveragePooling2D') with input shapes: [?,1,1,64]

 BHWC: Transition layerを含むDense blockを重ねすぎて(プーリング層を入れすぎて)吐かれた。Dense block(本質的にはプーリング層)を減らして解決。Dense blockをさらに重ねたければDenseNet-Bを採用すべし。
 

【WPF】【戯言】この私が…

【WPF】【戯言】この私が…

 「’mainwindow.xaml’ をプロパティ ‘StartupUri’ に割り当てることができません。値が有効な範囲にありません。」
 …Umm. 名前は変更していないのだけどねぇ。App.xamlを確認しても文字列は間違っていない。
ネットでググってちらほら出てくるようなありふれた原因ではないのか。フっ、この私が…愚民共と同じと思うなよ!?Google殿!!

 ま、まぁ完全一致ではない(汗)。
 MVVMフォルダ構成に整理したため「StartupUri=”View/MainWindow.xaml”」なのだよ。

終幕っ!!!

MVVM on WPF

MVVM on WPF

View

  • Modelの公開しているデータとコマンドを操作しやすいようにViewをつくる

 UIのことでありXAMLで記述される。Datacontextにクラスを指定してリソースとして利用するなどする。またCommandをバインディングする、ホットキーのバインドなどもxamlに記述される。viewが「UI/UXについて」、と考えればここでホットキーがバインドされることになんら問題はない。

Model

  • WPFで組んでいるものをFormsに変更することになると考えた場合に、変わらない部分をまとめるとモデルになる。

 a.k.a.エンジンで良いのではないかと。
 入力の検証はViewが変わったとしても変更されるわけではないのでModel側。Modelは変更通知機能を有することが許されていて、View側がModelからデータを直接受けとることはタブーではない。

ViewModel

  • ModelとViewで合わない部分を合うように変換する機能を作るとViewModelになる

 INotifyPropertyChanged、Command(ICommnad)などは基本的にここの枠組みに実装する。難読化が懸念されるほどのコマンド量が想定されれば適切な粒度で分類してファイルに分ける。Modelを継承したクラスに機能を追加してViewModelとしてもいい。役割はView専用の保持データの管理だと広く認知されている。ViewによってはModelに直接接続できない部分の変換を行う。言い換えると、View専用の表示に合うようにデータ整形する。逆に入力をModelに合うように整形する。
 表示することが目的のアプリの場合はページそのものがモデルで管理されるデータであるからViewModelでは管理しない。

識者によると、

「VMが注目されすぎて、Modelに実装すればいい機能までVMに実装してしまって、VMにMが混ざってしまうのが混乱する原因だと思う。」

「「Modelを継承してViewModelにしてやれば違いを意識せずに使えるよね」「後でVMにするならModelにINotifyPropertyChangedを実装してしまえ」という実装が楽ちんなのでよくやります。」

とのこと。