gtestでfloat値をExecl計算値と照合を試みる

gtestでテスト対象モジュールで計算されたfloat値を正しく計算されたか、Execl計算値と照合するケースは多いのではないでしょうか? floatは32bitですが数値分解能は23bit(確か…)、longの方が精度が高く、実際にはあまり使わないものです。今時のPCや携帯端末では、doubleを多用してもへっちゃらです。

しかし、マイコン向け組込みソフトでは未だdoubleを多用できるほど処理能力がありません。MATLAB/simulink の自動コード生成の都合で float(single) は使う場合もあるようですが、そもそも浮動小数点数は自体あまり使うべきではないと考えますが…

とあるお客さまで、gcc 使用でfloat値 不一致が多発していたので少し調べてみました。調査は VC++2019 で行っています。


Execl計算値をそのまま EXPECT_FLOAT_EQ に指定した場合、指定した数値から精度が落ちたことを警告されます。なるほどgccよりvc++の方が賢いみたいですね。テストはgccと異なり合格になります。Execl2003はVC++でBuildされてるでしょうから同じコンパイラから生成された数値は一致しやすいのでしょうか?


Execl計算生値では精度が大きすぎるようです。値をVBAマクロでfloat(Single)化した値をEXPECT_FLOAT_EQ に指定してみると、精度が落ち切っていないようです。


Execlに精度をあわせて EXPECT_DOUBLE_EQ を使うと上手くいくのでは? と思いましたが、float -> double 拡張で数値が変わってしまうようです。


ということて面倒ですが数値公差範囲を決めて、 EXPECT_NEAR を使しかなさそうです。EXPECT_FLOAT_EQ の公差は 4 ULPs (Unit of Last Place: 下4桁?) 以内にとのこと。

BungBungame KALOS のカスタムROM化は可能か?

ユーザさんより台湾BungBungame製 KALOS のカスタムROM化が可能か問合せがあったため調べてみました。その覚え書きです。

年式2013、当時日本でもいろいろ紹介されていたようです。現在、情報も少なく、スペックはこちらのようです

Android4.22止まり、有機EL、2560×1600と解像度は当時としては高く、Wi-fiモデルのみ。

https://androidfilehost.com/ にも直接はヒットせず。しかし「BaikalOS」といキーワードが出てます。これはAndroidの派生の一つのようです。たまたま単語部分一致でヒットした模様です。
2013年製となると、どのみち最新に近いAndroid相当のROMは作られていないと思われます。

SwiftではTextEditorの縦サイズが端末毎に変わってしまう

Shitf-UI にてライセンス許諾文を、TextEditor に表示した際の覚え書きです。Xcode 14.1 です。

TextEditor は、オートサイズが無いようです。フォントサイズを指定して、ライセンス許諾文が収まるようTextEditor 横縦サイズを指定しておきました。理論上どの端末でも同じになるハズですが、端末によって、ライセンス許諾文が途中で切れてしまいます。 これは iOSシュミレータと実機での間でも発生します。付随条件としては、TextEditor だけはスクロールできないので ScrollView をかませました。この時の端末は iPad 6th です。

@State private var licenseText : String = "Error"
 :
中略
 :
var body: some View {
 :
中略
 :
    ScollView( [.vertical], showsIndicators:true) {
	     TextEditor(text: $licenseText/* $必須 */ )
	     .frame(	width: myWidth * 0.9, height:8000)
	     .disabled(true)	// 入力禁止有効 
    }
    .border(Color.black, width: 1)
 :
中略
 :
}
.onAppear {
   :
  ライセンス文読込み
   :
	licenseText = tmptxt.string
   :
 後略

おそらく端末毎に dpi が異なるためだとおもうのですが、dpiを取得して演算するまで凝りたくありません。表示領域が多い分には実害はないので、弊方では height値 を一番高性能そうなiPad Pro 12inch の iOSシュミレータで合わせこんでおきました。

    ScollView( [.vertical], showsIndicators:true) {
	     TextEditor(text: $licenseText/* $必須 */ )
	     .frame(	width: myWidth * 0.9, height:9000)
	     .disabled(true)	// 入力禁止有効 
    }

8000 -> 9000 にUPで収まったということはザックリ1割のマージンを持たせておいた方が無難という感じでしょうか?

Swiftでフォントに影をつけるには

Swift-UIで、画面タイトルなどちょっとフォントを装飾したい。しかしフォント装飾の機能は何も見当たらない。Appleだからこジャレた装飾がたくさんあるのかと想像していましたが... ちゃんとタイトル画像を作ることがAppleポリシーなのでしょうか? そこまでは労力を掛けたくない。

そこで以下のようにすると、ZStack でノーマルフォントとボールドフォントを重ねると、フォントに影がついて少し見た目がよくなりました。

	/* アプリVersion、等長fontでBoldを下にひいて影付け */
	ZStack {
		// 下側(影)
		Label(	"Version 1.5.5",
			systemImage: "")
		.font(.system(size: 36, weight: .bold, design: .monospaced))
					
		Label(		"Version 1.5.5",
				systemImage: "")
				.font(.system(size: 36, weight: .regular, design: .monospaced))
        .foregroundColor(Color.yellow)
	}

表示例は、

ちょっとイマイチかもしれませんが、プレーンな状態と比べるとかなりマシです。

Swiftでは画像縮小時、縦横比が保持されない

Swift-UIで画像を縮小表示する場合、アスペクト比を保ったまま表示されませんでした。htmlでさえ幅か高さだけ指定すれば、アスペクト比を保ったまま表示してくれるのに… その対策か他記事では見当たらなかったので報告します。 Xcode 14.1 です。急いでいたので幅広く調べてはいません。

対策は、オリジナル画像の縦横サイズを確認して、コード上で縦サイズと横サイズをアスペクト比を保つように計算します。

let bounds = UIScreen.main.bounds
let myWidth	 = bounds.width		// 自画面幅

Image("picture")
.resizable()	// Memo: コレ付けないと原寸表示される。
// Orignalサイズ 1664 x 1912 から画面サイズで計算する。
.frame(width: 1664 * myWidth/1912  * 0.35 ,
 	     height: 1912 * myWidth/1912 * 0.35 )
.padding(20)

複数の端末種に対応させるために、スクリーン横幅基準にズーム率を乗じます。

う~ん、本当にこれでいいのか? 面倒すぎる。