KiCAD日本語対応その後

メインシステムであるFedoraが30になったので、そちらの対応に追われていました。
Fedora30ではKiCadが5.1.2となっています。例によって.srpmを調達してnewstroke_font.cppを入替え。無事にLinux版はビルドに成功しました。

それにしても、バージョンアップの度にこれだと面倒だな… Windows版だとWinbuilderにまた変化が有ったようなのでこちらは手強そう。

ところで、この日本語対応版KiCADのバイナリって需要があるのかな? 本家kicad.jpも活動が停まっているように見えるしな。

Fedora30

新しい版の発表が先日ありました。予定では7日とのことで、連休明けだなぁと思って居ましたが、運良く休み期間中に発表になったので早速入替え。半年に一度の煩わしい楽しい時間の始まりです。

とりあえず最小限インストールして、何時のように必要なものをインストール。
さすがに半年に一度インストールしている関係で環境構築はすっかり慣れし親しんだルーチンワークで、約2時間ほどで8割方元の環境が戻りました。あとは開発系のパッケージだけど、なにが必要化はよく掴んでないので、必要と言われるままに入れていくしか無いな。

例によって再ビルドするパッケージが山積みとなりますが、楽しくしばらく遊べそう。

演算精度その2

単純に整数の逆数を足し込んでいくだけのライプニッツ級数は収束が遅いことがわかりました。なので、べき乗項の有るオイラー級数だったらどうなのかをさっそくテスト。大して計算式に変化はありませんのでちょいちょいと変更してコンパイル。

#include <stdio.h>
#include <quadmath.h>
#include <math.h>

void main(void)
{
    char    c1[80];
    long    loop;
    __float128  res=0.0Q,r1=1.0Q;
    
    for (loop=1;loop<100000000;loop++) {
        res=res+1.0Q/(r1*r1);
        r1=r1+2.0Q;
    };
    res=sqrtq(res*8.0Q);
    quadmath_snprintf(c1,sizeof(c1),"%.40Qf",res);
    printf("loop=%ld\tresult=%s\n",loop,c1);
}

結果は、
$ gcc -o paicalc2.o paicalc2.c -lquadmath
$ ./paicalc2.o
 loop=10000000 result=3.1415926217588012757267165560912027187844
$ ./paicalc2.o
 loop=100000000 result=3.1415926504066943431811710021935384220221

と言う訳でライプニッツ級数の1億項の計算に比べて1000万項の計算で1桁精度が向上しました。項数を同じにした場合は2桁の向上ですね。でもそんなものか…

実際にはその後いろんな方法が考案されていて、そちらを使えばってのが身も蓋もない言い方。実際ガウス・ルジャンドル法だと3回目には18桁正しい値が得られるし、昨今の多数桁計算にはマーチンの式が使用されている。
とは言え、今から300年前に手計算だけでこれにたどり着いたのだからすごいことだと思うな。

演算精度の話

大先輩のブログでライプニッツ級数で円周率の計算って話が出ていました。もともとはプログラム電卓でどこまでやれるのかということが主眼なので、でかいPCを持ち出すのは野暮の極みといったところですが、ついつい悪乗り。

gccでもVer.4.8以降だと4倍精度小数点つまり128bit floatが使用できるとのことでしたので、さっそくテスト。
ちなみにソース(paicalc.c)はこんな感じ。面倒なので定義通りの記述。なんかねぇ…

#include <stdio.h>
#include <quadmath.h>
#include <math.h>

void main(void)
{
    char    c1[80];
    long    loop;
    __float128  res=0.0Q,r1=1.0Q,r2=3.0Q;
    
    for (loop=1;loop<100000000;loop++) {
        res=res+1.0Q/r1-1.0Q/r2;
        r1=r1+4.0Q;
        r2=r2+4.0Q;
    };
    res=res*4.0Q;
    quadmath_snprintf(c1,sizeof(c1),"%.40Qf",res);
    printf("loop=%ld\tresult=%s\n",loop,c1);
}
コンパイルして実行した結果は、
$ gcc -o paicalc.o paicalc.c -lquadmath
$ ./paicalc.o
 loop=100000000 result=3.1415926485897931884626429145303967199477

円周率の頭の方の分かっている数値は3.141592653589793…なので4倍精度だからといって7桁程度しか出てませんが、式から言えば当たり前ですね。
それとこのquadmathライブラリは当たり前ですが、ソフト処理なのでしょうから通常の64bit演算に比べると大幅に時間がかかります。倍精度の場合は0.76秒で済みましたが、4倍精度の場合は19.4秒と25倍以上も時間がかかっています。

オイラー式だとべき乗級数なのでもうちょっと収束が早いかな。ただ結果が円周率の2乗なので、開平演算の誤差が乗ってきそう… まぁ明日試してみますか。

Windows10初期化その4

結局分かったのは、CADソフトであるDraftsightの2019SP0という最新版を入れるとおかしくなると言うこと。

レジストリの例のCacheを消しても改善しないので、一旦アンインストール。そしてShellExtensionのCacheの中身を消すことで問題は解決するのですが、なんか気分が良くない。一方旧版であるDraftsight2018を入れる分には問題が起きないので、2019版はSP1が出るまでお預けです。
Readme.txtを読んでないもので、2018->2019の変化がなんなのかよくわかりません。なので2018のままでも特に支障は有りませんが。

まずはメーカーに文句を言うべきなんでしょうけど、どうも英文しか受け付けない雰囲気なのでちょっと面倒そうです。このあたりは片手間で日本でも売っている製品を利用する点でのリスクですね。

PDF関係のツールと音響関係のツールを戻したところで、クローン作成で一段落。
あとはVisiualStudioだけど最新の2019を入れるべきか2017にしておくかで悩み中。

Windows10 初期化その3

またまたずっこけたWindows10。今まで普通に使えていたアプリケーションをインストールしただけでおかしくなったのが納得のいかない点なのです。

で、バックアップから書き戻すつもりが最新版、つまりずっこけた状態をバックアップしてしまうというドジを踏んでしまったので、やむなく本腰を入れて原因追及を開始。

ファイルを右クリックして「プログラムから開く」で無反応となるトラブルなので、PathかShell系の設定に異常を疑い調査。
Pathには特に不審点は無いので次にShell系の調査。

Regeditで\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\
の中から怪しそうなShell Extensionをチェック。すると中にCachedという項があってずらずらと値が並んでいます。残念ながら、全部Hash化された値なので何に該当するのかはさっぱり。なのでエイヤっと全部削除して再起動。その結果トラブルが解決したのでした。

さて、怪しいアプリケーションを再インストールしたら現象が再現するんだろうか? そして再現した場合、同じ処置で解決するのだろうか? なんかもやもやします。

連休はこんなことに時間を使うつもりはなかったんだがなぁ…

Windows初期化その2

使用頻度の高い順に戻していって、8割方終わったところで、異常がないことを確認。この先また異常が出ると面倒なのでここで一旦クローンを作成。
これで万一この後こけても復旧の手間がだいぶ省ける。まぁ何も起きないに越したことはないのですが。

CADソフトのライセンスをいったん戻しておくのを忘れたので、どういう扱いになるのかがすごく心配。ダメと言われるとまた$99の支払いが発生するので、どうにかして回避しなきゃ。

4/27追記
心配していたことが再発。なんだろうなぁ… とりあえず怪しいやつは特定できた気がするので、そいつを除いて全体を再構築しなきゃ。

Windows初期化

なにが原因化は不明ながら、普段使いのWindowsが絶不調に。エクスプローラーでファイルを選んでおいて「プログラムから開く」をやるとエクスプローラーが固まります。エクスプローラーが固まるのではなく、Windowsのシステム自体が無反応となる模様で、他のファイラーなどを使っても結果は同じです。
いろいろ対策はしてみましたが、どれも効果無し。これでは困るのでバックアップを取って初期化開始。

1回めは「ユーザーデーターを残して初期化」としましたが、問題は解決せず。
仕方がないので「完全初期化」を開始。最初の処理に何をしているのかは判りませんが、やたらに時間がかかります。なんだかんだで一晩かかって再インストール。
問題はその後です。言われるがままに設定していったところ、今までのOneDriveの中身を無視してMy Documentの中身が全部OneDriveへ!!! なので、OneDriveの中身がぐちゃぐちゃになってしまいました。どうにかこうにか対処して、必要なアプリケーションを入れていって、ほぼ完了といったところで症状再発。うーん、なにが悪かったかな…

ここまで戻すのに、合間を縫っての作業なので一週間かかってます。またやり直しとは…トホホホ。プログラムリストを探しに行ってそれで何かとんでもないPathが有ってそこで引っかかっているような気もするのでそこが見つかれば解決?

KiCAD日本語対応その5

いろいろ発生してくれましたが、どうにか作成に成功したようです。歯切れが悪いのは、出来上がった実行ファイルを起動しようとしたら、「libzstd.dllが見つかりません」と出て起動してくれなかったから。
こんなファイルはコピーリストに無かったんだがとは思いましたが、無ければ動いてやらないといわれる以上、調達の必要が有ります。

そもそもこのlibzstd.dllはWindowsのシステムに含まれるものらしいので、無いと言われること自体が異常事態。原因不明のフリーズ病も度々発生するので、そろそろ一回OSのクリーンインストールの必要が有りそう。データーのバックアップをしなきゃならないので手間がかかるな。

物理的所有の続き

前回書いてから、Microsoftのストアで扱っていた電子書籍を取りやめるとの発表が有りました。利用者には返金するとありますが、今で所有していたつもりの電子書籍が全滅なので影響はそれなりに有ると思います。このような場合、やっぱり物理的所有に勝るものは無いなと思うわけです。

ところで、物理的所有が無敵なのかと言えば、たぶんそうでは無い。次に発生するのが利用方法にまつわる問題。例えばアナログレコードや磁気テープに限らず、物理媒体から記録されているデーターを取り出す装置が必要となりますが、必ずしも必要な時に簡単に手に入るわけでは有りません。レーザーディスクやビデオテープなんてのは、その典型ではないかな。
また、物理媒体への記録フォーマットやデーター自体のフォーマットも全てに対応できるかと言えばそうでもない訳です。

例えば音声データーでさえもmp3,asf,aac,aiff,atrac,wma,mvi,wav,flac,mp4,oggなどと乱立。さらにvqfと言った廃れてしまったフォーマットも有ります。規格が公開されていれば廃れてしまったフォーマットでもなんとか読み取りはできるのでしょうけど、公開されていなければお手上げ。

結局の所、以前から有るデーターを一旦電子化しておいて、時々媒体やデーターフォーマットも含めて最新システムに移し替えて保存しておくのがベストなのかな。そうでないと物理的に所有していたとしても、ただのゴミの山を所有していることになってしまいます。

一方で特別な読み取り装置が必要ではない書籍でも記録フォーマット(?)が問題となり、一筋縄では行きません。たかだか150年前ほどの文書でさえも原典を読みこなせず、現代語訳なる物が用意されるご時世。明治初頭でなくても、昭和初期の本でも旧字・旧仮名なので、人によっては読めないことも有るでしょう。
それよりも前の文書、いわゆる古文書の類だと、あのミミズののたくったような文字を、それこそ「解読」して、意味を読み解く必要が出てきます。

こちらもやはり、その時々の最新フォーマット(?)に変換して保管しておくのがベストなんでしょうね。ただ、書籍の場合は紙の痛み問題を除けば5,60年は同じ本でも大丈夫なのが違いかな。