link もっと前
   2019年 10月 29日 -
      2019年 10月 20日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

ニッケル水素電池の使い道

家にはニッケル水素電池がたくさん(15本くらい、※1)あって使い道がなくて困っていたのですが、停電時にモバイルバッテリーにすれば良いのでは?と思い立ち、Owltech の OWL-DBU1 という製品(製品サイトへのリンク)を買いました。

乾電池 4本で 5V 1A 出力が可能な製品です。最近のスマホはバッテリー容量が大きく、乾電池 2本を使う製品ですと満足に充電できません。その点、この製品は乾電池が 4本使えるので Good です。

不満な点は専用ケーブル(硬い、短い)でないと充電開始しないことです。専用ケーブルをなくすとゴミと化します。

(※1)いきなり電池を 15本買ったわけじゃなくて、買ったものもあるし、家電に付属していたものもあって、じわじわ増えて今の数です。

乾電池タイプのモバイルバッテリーとニッケル水素電池

乾電池を使うタイプのモバイルバッテリー製品は、アルカリ電池(1.5V)が前提で、ニッケル水素電池(1.2V)は想定されていないことが若干心配だったんですが、残念ながらこの製品もニッケル水素電池が苦手そうです。

アルカリ乾電池を使うと 4.9V 0.9A くらいでほぼ定格出力しますすが、ニッケル水素電池だと 4.5V 0.8A くらいまで電圧低下します。どちらも無負荷ならば 5V ですから、ニッケル水素の電圧の低さが悪さをしているように思います。


OWL-DBU1 にニッケル水素電池を使って充電中

上記の写真で充電しているデバイスは Zenfone 4 なんですけど、よくこの出力で充電できますね。期待している電圧より 10%も低い(5V を期待している)のに……。逆に凄いな。

充電効率はいかほどか?

充電できなくなった段階で、USB 電力計は約 1000mAh を表示していました。電圧が 5V でなくても、正確に測れているのかわかりませんが、表示を信じれば 4.4V 1000mAh = 4.4Wh くらい放電した計算です。

また、充電前の電池の電圧は 1.23V で、充電後の電池の電圧は 1.15V くらいでした(負荷 30Ω)。ニッケル水素電池の終止電圧は 1.0V ですから放電しきっていません(※2)。つまり、電池の表面に書いてある容量(1900mAh)は発揮できて「いません」。

ニッケル水素電池は 1本 1.2V 1900mAh = 2.28Wh、4本で 9.12Wh なので、48.2%しか使えておらず大変効率が悪いように見えますが、先も書いた通り終止電圧まで放電していないことによるロスと、DC-DC 変換のロスがあるので、この数字だけ見て製品が悪いとは言えません。

乾電池タイプのモバイルバッテリーを使う場合、ニッケル水素電池からエネルギーを絞り切ることを目指すより、電池の数に物を言わせてガンガン入れ替えていく運用の方があっていそうですね。

(※2)終止電圧 1.0V に達した後、充電せずに放置すると完全放電してしまい電池がかなり傷むらしいので、使い切る前に止まってくれた方が嬉しい仕様だと思います。

[編集者: すずき]
[更新: 2019年 10月 28日 00:25]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

天皇誕生日の移動

以前対応した(2018年 10月 12日の日記参照)カレンダーの設定が間違っていたので、修正しました。具体的には下記のとおりです。

  • 2018年まで 12/23: 祝日、おなじみ天皇誕生日
  • 2019年 12/23: 祝日ではない、天皇誕生日は 2019年は存在しない
  • 2020年から 2/23: 祝日、新しい天皇誕生日

詳細は内閣府のサイトに掲載されています。特に 2019年と 2020年に関しては休日の一覧が載っていて、とてもわかりやすいです。

[編集者: すずき]
[更新: 2019年 10月 24日 00:48]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

線形探索と 2分探索の話

Twitter で線形探索と 2分探索の性能逆転ポイントはどこか?という話をしていて、気になったので測ってみました。

線形探索と 2分探索は、要素数を N としたとき、処理量オーダーでいうと O(N) と O(logN) となり、圧倒的に 2分探索が速いです。ただし処理量オーダーによる比較は、N が十分に大きい場合に成り立ちます。N が極端に小さい場合は線形探索が 2分探索と同等、もしくは、勝ってしまう領域があるのではないか?という話です。

結論だけ先に言えば 2分探索の圧勝でした。かなり N を小さく(100 程度)しないと、線形探索に勝ち目はなかったです。個人的には N=1000〜2000 程度ならば線形探索が勝つ予想をしていましたが、全くそんなことはなかったです。2分探索スゴい。

探索速度検証

検証方法ですが、線形探索(lsearch)を実装して、C ライブラリ(GNU libc 2.29)に実装されている 2分探索(bsearch)と速度を比較しました。線形探索 lsearch の API は 2分探索と揃えています。

処理の概要は下記の通りです。探索の対象は同じものを使っています。

  • 要素数 N の配列を作る
  • 配列を乱数で埋める
  • 配列をソートする(bsearch はソート済みの配列にしか使えない)
  • 2分探索(bsearch)を M 回実行する、時間を測る
  • 線形探索(lsearch)を M 回実行する、時間を測る

ソースコードは下記のとおりです。

線形探索と 2分探索の速度比較プログラム

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>

int comp(const void *key, const void *val)
{
	int k = *(int *)key;
	int v = *(int *)val;

	return k - v;
}

void *lsearch(const void *key, const void *base,
	      size_t nmemb, size_t size,
	      int (*compar)(const void *, const void *))
{
	void *v = (void *)base;
	size_t i;

	for (i = 0; i < nmemb; i++) {
		if (compar(key, v) == 0)
			return v;
		v += size;
	}

	return NULL;
}

int main(int argc, char *argv[])
{
	int *array, *keys;
	int **fb, **fl;
	size_t n, kn, i;
	struct timeval start_b, end_b, ela_b;
	struct timeval start_l, end_l, ela_l;

	if (argc < 3) {
		fprintf(stderr, "usage:\n\t%s n loop\n", argv[0]);
		return -1;
	}

	n = atoi(argv[1]);
	kn = atoi(argv[2]);
	if (n == 0 || kn == 0) {
		fprintf(stderr, "usage:\n\t%s n loop\n", argv[0]);
		return -1;
	}

	srand(time(NULL));

	array = (int *)malloc(n * sizeof(int));
	keys = (int *)malloc(kn * sizeof(int));
	fb = (int **)malloc(kn * sizeof(int *));
	fl = (int **)malloc(kn * sizeof(int *));

	for (i = 0; i < n; i++) {
		array[i] = rand() % (int)n;
	}
	for (i = 0; i < kn; i++) {
		keys[i] = rand() % (int)n;
	}

	qsort(array, n, sizeof(int), comp);

	gettimeofday(&start_b, NULL);
	for (i = 0; i < kn; i++) {
		fb[i] = bsearch(&keys[i], array, n, sizeof(int), comp);
	}
	gettimeofday(&end_b, NULL);
	timersub(&end_b, &start_b, &ela_b);

	gettimeofday(&start_l, NULL);
	for (i = 0; i < kn; i++) {
		fl[i] = lsearch(&keys[i], array, n, sizeof(int), comp);
	}
	gettimeofday(&end_l, NULL);
	timersub(&end_l, &start_l, &ela_l);

	for (i = 0; i < kn; i++) {
		if (fb[i] && fl[i] && *fb[i] == *fl[i])
			continue;

		if (fb[i] != fl[i])
			printf("diff %d: key:%d, fb:%d, fl:%d\n",
				(int)i, keys[i],
				(fb[i]) ? *fb[i] : -1,
				(fl[i]) ? *fl[i] : -1);
	}

	printf("n:%d, loop:%d, bin: %d.%06d[s], lin: %d.%06d[s]\n",
		(int)n, (int)kn,
		(int)ela_b.tv_sec, (int)ela_b.tv_usec,
		(int)ela_l.tv_sec, (int)ela_l.tv_usec);

	return 0;
}

コピペしていたり、エラー処理が甘かったり、適当な書き方で申し訳ないですが、性能比較が目的なのでそこは見逃していただくとして。測ってみるとこんな結果になりました。

環境は Ryzen 7 2700, Debian 10 (Linux 5.2.0-3-amd64) です。コンパイラは gcc 9.2.1 で、最適化レベルは -O2 です。

線形探索と 2分探索の速度比較(100万回)
$ for i in 1 `seq 25 25 500`; do ./a.out $i 1000000; done

n:1, loop:1000000, bin: 0.001702[s], lin: 0.001710[s]
n:25, loop:1000000, bin: 0.019114[s], lin: 0.011656[s]
n:50, loop:1000000, bin: 0.022469[s], lin: 0.018549[s]
n:75, loop:1000000, bin: 0.026413[s], lin: 0.023774[s]
n:100, loop:1000000, bin: 0.028008[s], lin: 0.028900[s]
n:125, loop:1000000, bin: 0.029601[s], lin: 0.034308[s]  ★この辺りで逆転される★
n:150, loop:1000000, bin: 0.030671[s], lin: 0.040280[s]
n:175, loop:1000000, bin: 0.031898[s], lin: 0.045664[s]
n:200, loop:1000000, bin: 0.032771[s], lin: 0.048153[s]
n:225, loop:1000000, bin: 0.033985[s], lin: 0.052148[s]
n:250, loop:1000000, bin: 0.034322[s], lin: 0.055871[s]
n:275, loop:1000000, bin: 0.034761[s], lin: 0.059935[s]
n:300, loop:1000000, bin: 0.035766[s], lin: 0.065683[s]
n:325, loop:1000000, bin: 0.036407[s], lin: 0.070435[s]
n:350, loop:1000000, bin: 0.037010[s], lin: 0.072971[s]
n:375, loop:1000000, bin: 0.036926[s], lin: 0.077805[s]
n:400, loop:1000000, bin: 0.037422[s], lin: 0.082656[s]
n:425, loop:1000000, bin: 0.037844[s], lin: 0.086240[s]
n:450, loop:1000000, bin: 0.038894[s], lin: 0.089354[s]
n:475, loop:1000000, bin: 0.038516[s], lin: 0.093286[s]
n:500, loop:1000000, bin: 0.038590[s], lin: 0.100021[s]

結果の見方ですが、最初の n: は配列の要素数です。次の loop: は何回検索するかを表しています。bin: は 2分探索 bsearch、lin: は線形探索 lsearch を表し、それぞれ loop 回実行し終わるまでの時間を出しています。

線形探索と 2分探索の逆転ポイントは実行するたびに割とズレますが、N=500 にもなれば、もはや線形探索に勝ち目はありません。2分探索強いです。

ループ回数を増やしても大勢に影響はありませんが、ループ回数を増やすほど lsearch がわずかに有利になるようです。N=1 のとき lsearch が勝つことが多いので、関数の呼び出しコストが低いのかも?

個人的に予想していた N=1000〜2000 のレンジでは、線形探索は桁違いに遅かった(2分探索の 10倍近く時間がかかる)です。私の予想は当てにならんなあ。

[編集者: すずき]
[更新: 2019年 10月 24日 00:45]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

イコライザー

普段ヘッドフォンを使っているのですが、若干、低音が足りないなと思うことがあります。

Windows 標準の Bass Boost は設定項目が 2つと大変シンプルでわかりやすいですが、音の歪みを防止するためなのか、Boost を有効にすると音が全体的に小さくなってしまうのが辛いところです。


Bass Boost

最大値は 24dB ですが、最大値に設定しようものなら非常に音が小さくなります。良いヘッドフォンアンプを持っていればアンプ側で音量を上げれば良いですが、PC のヘッドフォン端子に直接ヘッドフォンを接続している場合は、ボリュームを最大にしても聞こえなくなる可能性があります。


Bass Boost の設定画面

これはイマイチだなあってことで、代わりを探していましたら、VLC Player のイコライザはシンプルデザインかつ設定の幅が広くて、とても良かったです。


VLC イコライザの設定画面

全体の音量(Preamp)と、各帯域ごとの音量を別々に調整できるので、Windows の Bass Boost に似た設定もできる(Preamp を下げ、80Hz 帯を上げる)し、音が歪むのもお構いなしの設定にもできます。あまりやりすぎるとバリバリ言い始めるのでほどほどに、ですけど。

[編集者: すずき]
[更新: 2019年 10月 24日 00:36]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
   2019年 10月 29日 -
      2019年 10月 20日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 11/11 11:44

カレンダー

<2019>
<<<10>>>
--12345
6789101112
13141516171819
20212223242526
2728293031--

最近のコメント 5件

  • link 19年09月01日
    すずき 「私も正直びっくりです。間違って違う製品を...」
    (更新:09/04 23:39)
  • link 19年09月01日
    hdk 「車向けの製品の中でも、車載コンピューター...」
    (更新:09/02 23:20)
  • link 19年07月18日
    hdk 「あっ、AAMはマニュアルのオペレーション...」
    (更新:07/25 00:02)
  • link 19年07月18日
    すずき 「AAM(ASCII Adjust AX ...」
    (更新:07/24 22:22)
  • link 19年07月18日
    hdk 「加算減算は符号のありなしどちらも命令が同...」
    (更新:07/24 07:25)

最近の記事 3件

link もっとみる
  • link 19年11月07日
    すずき 「[独自の apt サーバー - その 6 - ソースコードパッ] ...」
    (更新:11/11 11:44)
  • link 19年08月29日
    すずき 「[独自の apt サーバー - その 5 - 複数のセクション] ...」
    (更新:11/08 00:41)
  • link 19年08月13日
    すずき 「[独自の apt サーバー - その 4 - まとめ] 独自の a...」
    (更新:11/08 00:41)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報