科学

2022/09/03

IOC List v12.2 released

IOC World Bird List v12.2 のドラフト版は 8 月上旬にはアップロードされていたのですが,その後正式版になったというアナウンスが無いままに 9 月に入ってしまいました. その間 8 月 23 日付で BOW ページが v12.2 に更新されたというアナウンスがあっただけです.このため 8 月 23 日で更新が完了したと見なしたいと思います.

これは 2022 年 2 回目のリリースです.前回 v12.1 のリリースが 2022 年 1 月 20 日だったので,今回は 6 か月 + 1 か月以上経ってからの更新となりましたが,これは他の主要な鳥類チェックリストとの統合の議論がある程度進捗するのを見極めてから更新作業を行ったためと思われます.この調子だと,鳥類チェックリストの大統合が予想外に早く達成されるかもしれません.

今回収録されたのはが 44 ,が 253,が 2,383 ,が 11,093 (うち絶滅種が 160 ),亜種が 19,880 です.

今回と前回 v12.1 との差分を調べてみると大きな変更はなく,他の主要チェックリストに合わせて 20 種程度の英名を変更したことが目立つくらいです.大規模な属の異動もありませんでした.例によって日本のバーダー向けに重要と思われる変更点を書いておきますが,今回はほとんど書くべきことがありません.強いて書くと,

  1. Pandion cristatus, Easterm Osprey, オーストラリアミサゴが P. haliaetus, Western Osprey, ミサゴの亜種にまとめられ,P. h. cristatus となりました.これに伴い,P. haliaetus の英名が Western Osprey から Osprey に変更されました.ちなみに日本で見られるミサゴは基亜種 P. h. haliaetus です.従って今後日本のミサゴの英名はただの Osprey となります.
  2. Strix davidi, Pere David's Owl, シセンフクロウが S. uralensis, Ural Owl, フクロウの一亜種に格下げされ,S. u. davidi となりました.ちなみに日本の本州島のフクロウは S. u. hondoensis, 亜種フクロウです,他の島のフクロウも S. uralensis の亜種なので,シセンフクロウと同列の扱いです.

と,この程度です.今回は英名の変更が多かったのですが,日本のバーダーにとっては影響はわずかでしょう.なお,IOC List が更新されるたびに別記事で紹介していた tautonym(反復名)ですが,今回は前回の v12.1 と全く同じなので省略します.


IOC 本家の Master List(学名と英名を収録した Excel ファイル)を編集して,Refsort/Ruby 用の辞書ファイル(拡張子が .ref のテキストファイル)を作りましたので,Microsoft One Drive 上に設けた “IOC List Archive„ にアップロードしました.

エンコーディングは UTF-8US-ASCII の2種類です.正版は UTF-8 版で US-ASCII 版は簡易版ですが,詳細についてはユーザーズガイドをご覧ください.


このオリジナル版の辞書ファイルと併せて,全ての掲載種に和名をつけた辞書ファイル 2 種と,IOC Master List の和名追加版(Excel ファイル)も同時にリリースしました.今回は山階鳥研論文誌に掲載されている目と科の新しい和名を参照して,目と科の和名を若干修正しました.さらに同じく山階鳥研の論文誌に掲載されたフクロウ目の種和名の改訂に関する論文を参照して,フクロウ類の和名の若干の改訂を行いました.変更部分は辞書ファイル中に明記してあります.元論文は辞書ファイルのヘッダー部分を参照してください.

和名追加辞書についても,UTF-8 でエンコードしてあるものが正版ですが,Windows などでの使い勝手を考慮して Windows-31J でエンコードしたものも同時にアップしてあります.詳細についてはユーザーズガイドをご覧ください.

単に種名を調べるためだけであれば,和名追加版の Master List(Excel ファイル)が最も便利です.ただし長大なワークシートなので,目的の名前をスクロールして探すのは非効率です.検索メニューからジャンプするのが良いでしょう.


これらのファイルは前述のとおり,Microsoft One Drive 上に設けた IOC List 専用のフォルダからダウンロードできます.それには,このブログ右側のコラムの最上段の Archive の中の IOC List Archive をクリックしてください.そうすると One Drive のフォルダに入ることができますので,あとは適当に選んでダウンロードしてください.


なお旧版の v12.1j について,何か所か和名の誤記が見つかったので,訂正版をリリースしています.ioclist_v121jp1 という総称で,それぞれ UTF-8 と Windows-31J でエンコードしたものがあります.旧版を使い続ける方はこちらをお使いください.

さて,本年秋のリリースが予定されていた 10 年ぶりの更新となる日本鳥類目録改訂第 8 版ですが, Covid-19 の影響を受けて検討作業が遅滞しているとのことで,リリースを 1 年延期して 2023 年 9 月とすることがアナウンスされています.しかも,これまでになかったような和名の変更がいくつか予告されており,興味深いものになるようです.例えば長すぎる和名を短くするとか,亜種の名前を種名と異なるものにする例外を設けるとか・・・こちらの記事が参考になります.一年先延ばしになってしまいましたが,ぜひ世界の進度に伍して行ってもらいたいと思います.


I am pleased to announce that I have posted reference files for Refsort/Ruby compiled directly from the latest IOC World Bird List v12.2. It contains 44 Orders, 253 Families, 2383 Genera, 11,093 species including 160 extinct ones, and 19,880 subspecies, respectively. Please try it out, and enjoy its capability and speed.

Note that the reference file "ioclist_v122u.ref" is encoded in UTF-8 in order to retain all European accents and umlauts with complete fidelity as they are in the IOC Master List.

For those who want to use Refsort/Ruby in universal ASCII environments, I have posted another reference file "ioclist_v122a.ref" encoded in pure US-ASCII. Note that characters with accents and umlauts have been simplified to their nearest neighbors. So please be careful in particular when you refer to authorities of species.

I have also posted two different reference files "ioclist_v122ju.ref" and "ioclist_v122jw.ref" (encoded in UTF-8 and Windows-31J, respectively) which include Japanese names for all species. If you want to know Japanese names, please refer to those files.

In order to sort a list properly using these reference files, you need to align the encoding of the input file to that of the reference file, and you should add a magic comment specifying the encoding in the first line of these files, such as

#!E -*- coding: UTF-8 -*-

or, add an option "-E UTF-8" into your commandline.

You can skip this process if your iput file is encoded in the default encoding of your platform, e.g., US-ASCII or Windows-31J for Windows, UTF-8 for macOS or Linux.

A master list in Excel format containing a column of Japanese names has been posted as well. This would be most convenient for quick reference.

You can download appropriate files from my area of Microsoft One Drive by clicking "IOC List Archive". Enjoy, and bon appétit.

| | | コメント (0)

Refsort/Ruby v3.73 released

辞書参照型ソーティング・フィルタ Refsort/Ruby (新しいほうから *1 *2 *3 *4 *5)の改訂版 v3.73 をリリースしました.今回の改訂は機能の追加が主なものです.

まず,数値の大小で並べ替えを行うための --value, -e オプションの機能を拡張し,数字の直後に + または - 記号を最大で 5 個まで付けることで,付けなかった場合の数値よりも「わずかに」大きいまたは小さい数値を表現できるようにしました.これにより例えば,

100-- < 100- < 100 < 100+ < 100++

という大小関係が成立するようになります.野外での生物個体数のカウント,培養シャーレや顕微鏡視野内のカウントなどで,概数として + や - を付ける場合があることに対応しました.

なお, 100+ や 100++ は 100 よりも「ほんのわずか」大きいということだけに意味があるので,他の数値に対しては 100 とほぼ等価です.このため強いて書けば,

100+ < 100++ < 100.001

99.999 < 100-- < 100- < 100

という評価になることにご注意ください.

負の数についても,+ はわずかに大きい数,- はわずかに小さな数を表すので,

-100-- < -100- < -100 < -100+ < -100++

となります.

次に --showencoding, -g の機能を以下のように修正しました.まず BOM や コマンドライン,あるいは何も指定がない場合のデフォルトで初期設定されているエンコーディングを表示し,その後辞書ファイルや入力ファイルを読み込んだ段階で埋め込みオプションによりエンコーディングが変更された場合には,変更後のエンコーディングも表示するようにしました.これによりエンコーディングの初期設定・変更の過程がわかりやすく表示されます.

Refsort/Ruby とそれに関連するコンテンツのアーカイブを Microsoft One Drive に置いています.画面右側コラムの Archive の中の Refsort/Ruby Archive をクリックしていただくと,私の OneDrive 上に設けたライブラリが開きますので,そこから過去分も含めてファイルをダウンロードすることができます. Refsort 本体の refsort.rb は refsort_v373.rb というファイル名でアップロードされていますので,ダウンロード後に refsort.rb に変更するとよいでしょう.改行コードも CR/LF になっていますので,適宜変更してお使いください.エンコーディングは US-ASCII ですので,そのままでよいでしょう.ユーザーズガイドは,リリースが遅れている IOC List v12.2 が完全にリリースされてから改訂したいと思います.

| | | コメント (0)

2022/07/25

火山が一番恐ろしい

桜島が爆発的噴火をしたそうです.避難した住民たちは一晩中眠れなかったそうです.きっと怖かったでしょう.何しろ何トンもあるような噴石が 2 km 先まで飛んでくるような噴火です.風向きが悪ければ火山灰も降ってきます.ろくなことはありません.

桜島は常時活発な活動を続けている日本でも有数の火山.常時噴火を繰り返して火山灰を降らせるので,鹿児島市では昭和の頃から衣類乾燥機の普及率がダントツで日本一.さらに鹿児島市では道路に積もった火山灰をかき集めて収集する専用車両も多数用意してあるそうです.富士山の降灰が予想される地域にそのような用意はあるでしょうか?

私は阿蘇山からそう遠くないところで生まれ育ったので,火山の怖さや有難みはある程度分かっているつもりです.小学校の同級生には阿蘇山の噴火で父親を亡くした子供もいました.

私は数ある自然災害の中で,火山はダントツに破壊的で長期の悪影響をもたらす災害だと確信しています.どんなに大きな地震や津波でも,どんなに強大な台風でも,火山の破壊力に比べれば大したことはありません.せいぜい 100 年も経てば自然も人々の生活や社会も復旧されるはずです.しかし火山はそうはいきません.発生頻度は小さくてもその破壊力はすさまじいからです.

Ashes1867440_1280

Image by Pexels from Pixabay

桜島は姶良カルデラという海底カルデラに含まれる火山ですが,このカルデラは 2.5 万年前にこの火山が大噴火 (A-Ito) した名残りです.このときの軽石が神奈川県の丹沢山塊で見つかっています.想像できますか?鹿児島では数 10 m も積もった火山灰がシラスとして知られています.

その後つい最近 7,300 年前に,薩摩半島の南 50 km にあった火山が超巨大噴火を起こして鬼界カルデラを形成しました.現在の薩摩硫黄島と竹島がその外輪山の一部.過去 1 万年以内では世界最大規模の噴火と言われており,九州南部の縄文文化を壊滅させたと言われています.火砕流で直接死亡する以外にも,堆積物によって農耕や狩猟採集が出来なくなり,他所へ移り住んだとも考えられます.

実は阿蘇山の巨大カルデラ噴火 Aso-4 はこれらよりだいぶ前で 9 万年ほど前.現生人類が日本列島に住み着く前だったと思われますが,アジアのローカルな人類は住んでいたかもしれず,住んでいたとしたら九州島の人口は火砕流のためほとんど失われたと思われます.なにしろ北海道で火山灰が 15 cm ほど積もっています.

Landscape4129533_960_720

Image from Pixabay

もっとスケールの大きな噴火もあるそうで,スマトラ島のトバ火山が 73,000 年前に超巨大噴火を起こしたのですが,これはイエローストーンと並んで第四紀で確認される最大の単一噴火イベントだそうです.そして,この噴火と同時期にヒトの遺伝子の多様性が著しく減少していることから,この噴火で当時の人類の大半が死滅したという説があります.火山の噴出物によって地球規模の寒冷化が 6,000 年ほど続いた後,ヴェルム氷期に突入したというシナリオです.脆弱な生存基盤しか持たなかった当時の現生人類や他の人類の大部分が死滅してしまった,ということのようです.ま,異論もあるので話半分に聞いておくべきでしょうが,それにしても火山がいかに破壊的であるか,それに対する備えはあるのかと問い直す必要があると思います.

| | | コメント (0)

2022/07/07

Refsort v3.72 released

辞書参照型ソーティング・フィルタ Refsort/Ruby (新しいほうから *1 *2 *3 *4 *5)の改訂版 v3.72 をリリースしました.今回の改訂はバグの修正と,例外処理の若干の簡素化です.

まずバグの修正について.Refsort は --output, -o オプションで出力するフィールドを自由に選択できるのですが,出力のフィールド区切り記号そのものが含まれているフィールドは二重引用符で囲んで出力するようにしています.これは出力の再利用を容易にするためで,ある意味必須の機能です.例えば出力の区切り記号が空白の場合,フィールド内部に空白があるとそのフィールドを二重引用符で囲みます.例えばこんな感じ.

A B "C1 C2" D E

このフィールドを再び Refsort で読み込むと,フィールド分割を { } で示すことにすれば,

{A} {B} {C1 C2} {D} {E}

という具合に正しくフィールドが分割されます.

ところが,フィールド内に二重引用符自身が含まれていると,二重引用符自身をエスケープしてやらないと再利用するときのフィールド分割がうまく行かずに困ったことになってしまいます.しかしこれまで二重引用符のエスケープは放置されたままというバグが残っていました.

今回,二重引用符で囲まれたフィールド内の二重引用符は CSV の習慣に従って二重引用符自身でエスケープする,つまり二重引用符を2個連ねることでエスケープすることにしました.つまりこんな感じに出力されます.

A B "C & ""Special""" D E

これを再利用時に Refsort で読み込むと,

{A} {B} {C & "Special"} {D} {E}

という具合に正しく分割されます.

もうひとつの改訂は --didyoumean, -y--fullsearch, -Y オプションを使ったときのメッセージに,正解候補の文字列だけではなく,その候補が辞書ファイルの何行目にあるのかを示すようにしたことです.例えばこんな感じの出力が得られます.

!I 16: "オオタグロカモメ" not found in jpblist_v70p5w.ref
  Did you mean? "オオズグロカモメ" at R 698
               "オオセグロカモメ" at R 716

Refsort/Ruby とそれに関連するコンテンツのアーカイブを Microsoft One Drive に置いています.画面右側コラムの Archive の中の Refsort/Ruby Archive をクリックしていただくと,私の OneDrive 上に設けたライブラリが開きますので,そこから過去分も含めてファイルをダウンロードすることができます. Refsort 本体の refsort.rb は refsort_v372.rb というファイル名でアップロードされていますので,ダウンロード後に refsort.rb に変更するとよいでしょう.改行コードも CR/LF になっていますので,適宜変更してお使いください.エンコーディングは US-ASCII ですので,そのままでよいでしょう.現時点でユーザーズガイドは未改訂ですが,IOC List v12.2 が公開された後で,その内容を反映させたものをリリースする予定です.

| | | コメント (0)

2022/07/06

T + B > D

昨日の記事の終盤に言葉足らずの点があったので,ちょっと補足です.再生可能エネルギーを大量に導入した場合の調整力と,それを反映した CO2 排出原単位とコストについて.

再生可能エネルギーを主力電源にすることを考えます.再生可能エネルギーには多種あるのですが,日本の現状から太陽光,風力,水力だけを含めることにします.これらの出力を R [GW] とします.この R は時々刻々激しく変動する時間の関数で,理論上の最大値は設備容量の公称値ですが,実際の最大値はそれよりかなり小さな値となります.最小値は渇水期の夜間の無風時に発生する可能性があり,その値はゼロ (*注 1) です.

次に原子力発電の出力を A [GW] とします.日本では原発の出力調整は禁忌なので,定検時期を除けば A はほぼ一定です.ここでは定検時期ではない場合を想定し,A は定数とします.

さらに様々な種類の火力発電が持っている発電能力(要請があればすぐに供給できる電力)を T [GW],蓄電池の出力能力(同様)を B [GW] とします.これらはポテンシャルの値なので定数です.

CO2 排出量を最小にする電源構成を目ざして,電力を原子力と再生可能エネルギーだけで賄うことにします.需要電力を D [GW] とし,送電ロスを無視する(送電端電力 = 受電端電力)と,

R + A > D    (1)

が常に成り立たなければなりません.R と D は時間の関数,A は定数です.不等号が付いているのは余裕が必要だからです.これだけ見ると,原子力と再生可能エネルギーさえあれば全需要を賄えるように見えます.しかし R は非常に激しく変動するので,この不等式を常に成り立たせるには追加の条件が必要となります.

(a) A >> R として R がたとえゼロになっても不等式が成り立つようにする.
(b) R を非常に大きな値にして最小値でも不等式が成り立つようにする.
(c) R の変動を吸収するために,R の低下分を他の電源で賄う.

まず (a) は全需要を原子力だけで賄えと言っているので現実的ではありません.また (b) では再生可能エネルギーの設備容量をどんなに大きくしても,気象条件によって R ゼロになる可能性は否定できません (*注 1) し,そもそも設備容量が膨大になって経済的に成立しません.

そこで (c) が必要になるのですが,これを実現するためには R の寄与分を火力発電と蓄電池でカバーしなければなりません.つまり変動する R の様々な値に対して,定数である T と B は,

T + B > R    (2)

という不等式を満たさなければなりません.これを調整力と言います.調整力とは,実際に発電して電力を供給するかどうかとは無関係に,必要であればいつでも供給できる能力 (*注 2) のことを指します.

さて,これら (1) と (2) の不等式を辺々足し算して A を移項すると,

T + B > D - A    (3)

という不等式が得られます.これはつまり,電力需要からベース電源である原子力を差し引いた分を,火力と蓄電池はカバーできなければならない,ということになります.特に東電管内では A = 0 の状態が続いているので,T + B > D でなければなりません.

あれ?せっかく再生可能エネルギーをたくさん導入したのに,結局火力発電と蓄電池も全需要をカバーできる分だけ持っていなければならないってこと?

その通りなのです.注意すべきは,火力発電と蓄電池はあくまで調整力なので,常に電力を供給しているとは限りません.気象条件が良ければ再生可能エネルギーと原子力だけで全需要を賄えるので,火力発電や蓄電池はなにも仕事をせずにただ遊んでいるだけです.その間は CO2 排出量は非常に低く抑えられます.

いざ気象条件が悪くなって再生可能エネルギーの出力が不足してきたときには,待機していた火力発電や蓄電池がそれっとばかりに電力を供給してブラックアウトを防ぐことになり,CO2 排出量はその分だけ増えることになります.

ここからが本題です.CO2 排出量を減らすために再生可能エネルギーを導入しても,それと同じだけの調整力を持つために火力発電と蓄電池へも投資しなければなりません.そして特に火力発電は実際に調整用電力を供給すればその分 CO2 を排出します.この排出量を再生可能エネルギーの CO2 排出原単位に含めると,その分再生可能エネルギーの原単位は増えます.また火力発電プラントや蓄電池を建設・廃棄するときにも CO2 が発生するので,これも加わります.それでも火力発電を主力電源にして化石燃料を大量に燃やすよりは CO2 排出量はずっと少なくなるので,CO2 削減のためには上記のシナリオが一つの端的なオプション (*注 3) になります.

ただし CO2 排出量は減るのですが,設備投資は二重に必要になります.つまり電気料金には稼働率の低い火力発電プラントや蓄電池の減価償却費と保守管理費用も加算されるということになります.これを許容できるかどうかが判断の一つの分かれ目になります.

(注 1) ここでは R の最小値をゼロとしましたが,貯水地域の降雨が安定していたり,風力の容量が十分に大きくかつ広域での連系ができるのであれば,R の最小値はゼロよりも大きな値に出来るので,式 (2) は T + B > R - Rmin という風に修正され,調整力の必要容量は Rmin の分だけ緩和されます.つまり Rmin をいかに大きくかつ保証できるかが一つの鍵となります.北海やバルト海は風況が良く,ノルウェーは水力資源が豊富なので,欧州はこれでだいぶ得をしています.

(注 2) この調整力は市場で売買されるのが普通で,日本でも制度設計が進められています.例えば今日の午後 1 時から 2 時までの間に要請があってから 10 分以内に 1 GW の電力を供給できればいくら(容量市場), 1 秒以内に 0.1 GW の電力の供給と吸収を行うことができればいくら(周波数市場)という具合に対価が設定されます.そして実際には要請が来なかったために供給しなかったときでも対価は支払われ,要請が来たのに供給できなければペナルティが課せられます.

(注 3) このような極端なシナリオは現実的ではないので,火力からの寄与を常時含めることにして,式 (1) を R + A + T > D と修正すべきです.火力のうち調整力のために温存しておく発電能力を Ta とすると,式 (2) は Ta + B > R と修正されます.そして式 (3) は Ta + B > D - A - T という当たり前の式に修正されます.式 (3) は R の値に依らないので,結局 A,B,T,Ta を D に対してどのような比率で配分するかという問題になります.

| | | コメント (4)

2022/07/05

HEV v.s. BEV

酷暑の日はエアコンを効かせた部屋に引き籠っていることが多く,いきおい色々な Web サイトを渉猟して歩く機会が増えます.そこでちょっと面白いと思ったのが BEV の電費と HEV の燃費の比較です.

実は私は半年少々前に車を買い替えて最新の HEV に乗っているのですが,燃費がすこぶる良いのです.ちょっと遠出をすると 30 km/L 以上出ます.今ごろ夏の暑い時期にエアコンをかけて近所に買い物に出かけることだけを繰り返しても 28 km/L は楽に行きます.これはひょっとして BEV に勝てるのではないか?

ではどういう共通の指標で比較すればよいのでしょうか?燃費の単位は km/L,電費の単位は km/kWh なので直接の比較はできません.しかも BEV が充電するときの電源には,原子力,火力,水力,地熱,太陽光,風力などがあり,それらの比率は時々刻々変化するので,大もとの投入エネルギーをうまく定義できません.

ここでは,現在の首都圏には原発由来の電力はほとんどないこと,風力はごくわずかであること,さらに日中は太陽光発電の寄与があるものの,BEV が主に充電する夜間には太陽光発電はゼロであることから,BEV の電源は 100% 火力発電由来であると仮定します.

まず LEAF ですが,日産 LEAF の電費をユーザーの声から拾ってみると,だいたい 7.5 km/kWh というのが平均のようです.そして受電端発電効率をかなりひいき目に見て 35% とします.これは LNG コンバインド発電超々臨界圧石炭火力も含んでの話です.すると元々の熱量に対する走行距離は,

(7.5 km/kWh) x 0.35 = 2.63 km/kWh = (2.63 km) / (3600 kJ) = 0.731 km/MJ

という値になります.つまり発電所で 1 MJ の発熱量を持つ燃料を燃やして得た電力で,0.731 km 走ることができるということです.

Electriccarg3397f8897_1280

Wolfgang EckertによるPixabayからの画像

ではこれを私の車,新型 AQUA の燃費 28.5 km/L と比べてみましょう.ガソリン 1 L あたりの発熱量は石油連盟の資料によれば 33.36 MJ/L らしいので,その効率は

(28.5 km/L) / (33.36 MJ/L) = 0.854 km/MJ

という値になります.

これからわかることは,燃料の発熱量あたりの走行距離はほぼ同等.へぇ?こんなに一致するなんて不思議ですが,むしろ HEV のほうが良いくらいです.非常に大雑把な計算ですが,最新の HEV は結構いい線をいっていて,価格を考えると現状最良の現実解だということはわかると思います.

さていくつか考慮すべき点があります.まずは車格(特に重量)が同じか?という点です.これは LEAF と AQUA の形状や重量などを詳しく見なければなりませんが,大雑把に言ってこれら2車種は見た目ほぼ同格と言っていいでしょう.

次に,LCA で比較しなくてよいのかという議論もあります.一般的には HEV と比較して BEV のほうが製造や廃棄に係るエネルギーは多い(主として大量の電池やインバーターなどのパワーエレクトロニクス部品の製造と廃棄による)ので,利用時の効率が同程度であれば,LCA で見たときにはむしろ HEV のほうがエネルギー効率に優れている,ということになります.

なお,CO2 排出量に関して LCA ベースでまじめに議論をしようとすると,HEV の場合も BEV の場合も CO2 排出原単位の緻密な調査と計算をしなければなりません.いろいろな研究機関がいろいろな試算を行っていますが,私の知る限り BEV が HEV に比べて圧倒的に優れているという報告は見たことがなく,ほぼ同等という結論が多いように思います.最近注目したのは大型電動トラックに関するこの記事

もちろん再生可能エネルギーだけで BEV の充電ができれば,指標の定義の難しさはありますが,BEV が非常に有利になることは予想できます.ただしその場合でも,再生可能エネルギーの変動を吸収するために必要な揚水,待機火力や蓄電池への投資を再生可能エネルギーの CO2 排出原単位に含めると,社会全体としての優位さは削がれてしまうことは覚えておく必要があります.

このような計算ができるにも関わらず BEV が脚光を浴びているのは,HEV の技術開発でトヨタに負け,クリーン・ディーゼルのスキャンダルで深手を負った欧州の完成車メーカーと,彼らに食わせてもらっている EU の高級官僚や政治家たちの,産業競争力上の危機感と余裕の無さの現れだと思います.ロシアから天然ガスが入って来なくなるドイツで,どこまで原子力や石炭火力に頼らず BEV を推していけるのか,一つの社会実験として注視していく必要があります.

| | | コメント (0)

2022/03/12

Refsort/Ruby v3.71 released

辞書参照型ソーティング・フィルタ Refsort/Ruby (新しいほうから *1 *2 *3 *5 *5)の改訂版 v3.71 をリリースしました.今回の改訂は先月リリースした v3.70 に残っていたロジックの不備を補うもので,機能的な変更はありません.

前回の改訂でコマンドライン・オプション "-E, --encoding" を導入しましたが,BOM によるエンコーディング設定との整合性が十分に取れておらず,エンコーディングの優先順位が混乱していました.今回の改訂はその優先順位を整理し,それに基づいて警告文を出す条件と文言を改めたものです.改めて書くと,エンコーディングの優先順位は

BOM > 埋め込みオプション > コマンドライン・オプション > ロケール

となります.辞書ファイルや入力ファイルで BOM が検出されれば,それに従ってエンコーディングが(実質的には UTF-8 に)設定されます.BOM がない場合,埋め込みオプションがあればそのエンコーディングが使用され,埋め込みオプションも無くてコマンドライン・オプションがあればそれが使用され,エンコーディングに関するオプションが何も指定されていなければデフォルトのロケールが使用されるということになります.

新設したコマンドライン・オプションは,辞書ファイルと入力ファイルの両方に有効な “共通エンコーディング” という概念を作ります.すると,辞書ファイルと入力ファイルが同じエンコーディング(ロケールと異なっていてもかまいません)で書かれてさえいれば,コマンドライン・オプションを付けて実行するだけで,自動的に入力ファイルと辞書ファイルの両方にそのエンコーディングが設定されます.このとき,辞書ファイルに埋め込みオプションが書かれていれば,優先順位によって共通エンコーディングは上書きされますが,それがコマンドライン・オプションと同じであれば問題は生じません.

エンコーディングをどのような手段で指定しようとも,辞書ファイルと入力ファイルのエンコーディングは同一でなければなりません.これが一致していなければ Refsort はエラーを吐いて停止します.従ってユーザーは自分がどのエンコーディングを選択しているのか,よく意識する必要があります.これはロケールの中だけの世界では注意する必要が無かったことです.

Refsort/Ruby とそれに関するコンテンツのアーカイブを Microsoft One Drive に置いています.画面右側コラムの Archive の中の Refsort/Ruby Archive をクリックしていただくと,私の OneDrive 上に設けたライブラリが開きますので,そこから過去分も含めてファイルをダウンロードすることができます. Refsort 本体の refsort.rb は refsort_v371.rb というファイル名でアップロードされていますので,ダウンロード後に refsort.rb に変更するとよいでしょう.改行コードも CR/LF になっていますので,適宜変更してお使いください.エンコーディングは US-ASCII ですので,そのままでよいでしょう.ユーザーズガイドも若干改訂されています.

| | | コメント (0)

2022/02/23

冬のスズメは群れる

ここ数日間は寒気の吹き出しで北西風が強く,雪国は豪雪で大変なことになっています.日本海には長大な距離を直線状に積乱雲が連なり,いわゆる線状収束帯を作って雷の放電が頻繁に起こります.そのとき光核反応が起こり,電子の対生成対消滅が起きているそうです.これは本当に驚きですね.雷様ってすごい!金沢市内では各所に小型の観測装置を置いて観測が行われています.

Lightningg5b4363fa6_1280

Pixabayより転載

当地でも西風が強いのですが,今日はスズメが田んぼの際でたくさん群れていました.スズメは留鳥と思われがちですが,意外と長距離を移動しているようで,特に冬にはどこからともなく集まってきて,数百羽程度の群れを作って行動しています.

Winteraroundhome_feb2022_0267m

どういうわけか今日は彼らに落ち着きがなく,枯れたヨシやガマの茎に止まっていたかと思うと一斉に飛び立って別の繁みに移動することを繰り返していました.近くに数羽のモズがいたので,狙われているとでも思ったのでしょうか?

Winteraroundhome_feb2022_0268m

| | | コメント (0)

2022/02/10

Refsort/Ruby v3.70 released

辞書参照型ソーティング・フィルタ Refsort/Ruby (新しいほうから *1 *2 *3 *4 *5)の改訂版 v3.70 をリリースしました.今回の改訂では,辞書ファイルや入力ファイルのエンコーディングを指定するコマンドラインオプションを新設しました.意味的にやや大きな改訂なので,サブバージョンを 0.1 上げて v3.70 としました.

少し詳しく説明します.Refsort はその生い立ちからコマンドプロンプトでの操作とフィルタとしての機能を基本にしているため,ロケール以外のエンコーディングを扱うことは例外とし,その場合には辞書ファイルや入力ファイルの先頭に埋め込みオプションでエンコーディングを指定することにしていました.

しかし Windows において Windows-31JShift_JIS だけでなく UTF-8 も広く使われるようになり,Excel のワークシートから直接 UTF-8 の CSV ファイルを書き出せるようにもなって,ロケールを前提にすることに無理が生じてきました.そこで扱うファイルのエンコーディングをコマンドラインオプションで指定できるようにしました.オプションの書式は “-E encoding” または “--encoding encoding” です.“encoding” に与える文字列としては,Windows-31J,Shift_JIS,UTF-8,EUC-JP などの ASCII 互換エンコーディングが可能です.

エンコーディングを指定する複数の手段の間の優先順位は,

埋め込みオプション > コマンドラインオプション > ロケール

となります.つまりロケールが何であろうと埋め込みオプションがあればそれが使用され,埋め込みオプションが無くてコマンドラインオプションがあればそれが使用され,エンコーディングに関するオプションが何も指定されていなければデフォルトのロケールが使用されるということになります.

今回の改訂によるメリットは,例えば Windows 上では,従来 UTF-8 のファイルを使うにはわざわざファイルの先頭に埋め込みオプションを書かなければならなかったのに対して,今後はコマンドラインオプションで “-E UTF-8” と指定するだけでよく,扱うファイルに破壊的変更を加える必要がなくなったということです.これは運用上大きなメリットになると期待しています.従来の手法もそのまま残してあり,今回の改訂が上位互換となる建て付けなので,移行は円滑にできるはずです.

ただし辞書ファイルに関しては従来通り埋め込みオプションを書くことを推奨します.なぜならばユーザーにエンコーディングの選択を意識させずに済むからです.

また従来と同じく,エンコーディングをどのような手段で指定しようとも,辞書ファイルと入力ファイルのエンコーディングは同一でなければなりません.これが一致していなければ Refsort はエラーを吐いて停止します.ユーザーは自分がどのエンコーディングを選択しているのか,よく意識する必要があります.

Refsort/Ruby とそれに関するコンテンツのアーカイブを Microsoft One Drive に置いています.画面右側コラムの Archive の中の Refsort/Ruby Archive をクリックしていただくと,私の OneDrive 上に設けたライブラリが開きますので,そこから過去分も含めてファイルをダウンロードすることができます. Refsort 本体の refsort.rb は refsort_v370.rb というファイル名でアップロードされていますので,ダウンロード後に refsort.rb に変更するとよいでしょう.改行コードも CR/LF になっていますので,適宜変更してお使いください.エンコーディングは US-ASCII ですので,そのままでよいでしょう.ユーザーズガイドも若干改訂されています.

| | | コメント (0)

2022/01/27

Emberiza personata だよ

今月のこの記事この記事アオジの学名の変更とそれに伴う和名の取り扱いについてポストしましたが,今日の散歩ではその改訂なった Emberiza personata を間近で見ることができました.

Winteraroundhome_jan2022_0493m

今回の改訂では Emberiza personataモノタイプ(単型)とされたので亜種も基亜種もありません.ひょっとして西日本では Emberiza spodocephala (シベリアアオジ)の基亜種である E. s. spodocephala (亜種シベリアアオジ)が見られるかもしれません.

| | | コメント (0)

より以前の記事一覧