電気自動車とガソリン車の比較はまだ鵜呑みにできない

電気自動車とガソリン車のエネルギー効率比較の記事で出ているが
まだまだ鵜呑みにできないと思います。

----------------------------------------------

記事
基幹技術が出そろった電気自動車、その近未来像
http://eetimes.jp/ee/articles/1201/23/news003.html
の中の
慶應義塾大学環境情報学部教授の清水浩教授の説では

電気自動車 35%
ガソリン車 8.6%

電気自動車側  35% は、本当かなあ、、、。

電池の充放電効率85%は、あまり信用できないが、、、。
電池の充電/放電効率 85% が、
二回かかるのではないか
0.85*0.85=0.72
かなと心配になる。

あとインバータの変換効率
90-95%が充電/放電で二回あるはず。
0.9*0.9 = 0.81
0.95*0.95 = 0.9025
だ。

ゲーム機の電池はすぐ放電してしまうしなあ。
高温になったら、放電は激しいはず。

電気自動車のエリーカ開発の清水浩教授ですから、
電気自動車側は、
理論上の最高の効率数値の可能性がありそう。

プリウスのカタログ燃費と実燃費の差が
かなりある(話半分近くまでになります)のと同様に
理想値と現実の落差がありそう。

話半分から話50%引きで割り引くと
17%-23%程度
と思ったほうがよさそう。

清水浩教授の説
ガソリン車 8.6% は、厳しい現実かもしれない。
でも資料が古い可能性もある。
最近のガソリン車の低燃費化の話が
盛り込まれていない可能性がある。

-----------------------------------------------------
で、
EVのエネルギー効率
http://www.projectev.info/knowledge/37-basic/118-ene
という記事も見つけたが
こちらは、

日産EVフォーラムの
電気自動車 14%
ガソリン車 12%
が、電気自動車リーフの正直な実績であろう。

ここで、「モータ効率が75%と低い。」と書いてあるのは
日産のリーフは、インホイールモーターではないので
多少効率は悪いはずだし、
電池や回路のトータルの効率を
含めているのだと解釈。

この記事が面白いのは、
ガソリン   14%
ガソリンHV 22%
ディーゼル 19%
を示していることだ。
電気は、清水浩教授と同じ34%は変だがね。

日産EVフォーラムの
電気自動車 14%
を見ると、
もしかするとガソリンとほぼ同様ということです。

-----------------------------------------------------
車の場合、冷房にエアコン、暖房にヒーターを使う

プリウスに乗っているとエアコンとヒーターで
途端に燃費悪化することがわかる。

ガソリン車やディーゼル車は、
熱源があるので、暖房はおまけでできる。
冷房もその気になれば廃熱でできる可能性がある。

廃熱利用を徹底して進めるなら、
一走りで100[L]ぐらいの温水を作り、
帰宅して家庭に供給することも可能。
(大人 二名余分に乗車ということですな)

電気自動車では、冷房暖房どうするのかな。

-----------------------------------------------------
あと、インホイールモーターが、本当にトータルで効率がいいのか
説明理由があまり理論的でない。

一方でインホイールにすることで、
雨、台風、雪道、泥道、砂道の
耐久性がとても不安。

耐久性が悪いと、コスト効率が悪いのである。

素人考えだが、
シャフトの回転慣性がそんなに
大変な効率ロスとも思えない、
単に既存のガソリン車の変速機や
デイファレンシャルギア(デフギア)の効率が悪いだけなら、
後輪駆動車で、モータを二個ダイレクトに
後輪につなげばいいだけのはずだ。
こうすれば、高価なモーターは安全な場所に置ける。

電気自動車は、日産のリーフが2011年に発売され
トヨタ自動車が1997年に初代プリウスを発売してのと同じ状況
初代プリウスはガソリンで走り、
価格以外にこれまでの自動車にくらべて何も問題が無かったので
12年かけで価格が安くなり
爆発的に普及した。

リーフは、価格以外に、充電に時間がかかる、航続距離が短いと
二つの実用上の課題があり、これを解決するにはまだ時間がかかりそう。

自家型でサーバ型の前払式支払手段

好試力研究所の各種のWEBサービスの代金支払いについて

法律用語の「自家型の前払式支払手段(サーバ型)」

つまり、

好試力研究所内にだけ通用する仮想コインを
先に買って貰い仮想財布にチャージし、
仮想財布から各サービスを利用する度に、
仮想コインを差し引く形で支払う方法

を実現するとすれば、、、、

-----------------------------------------------
未使用発行残高が政令で定める額（1000万円）を
超える場合に届出が必要。

情報管理規定を整備すること。
- 残高がブラウザでわかること。
- 金額の出入りをすべて記録し、後で参照できること。
- 金額の出入りと残高を都度メールで連絡すること。

基準日(3月9月)における未使用発行残高が政令で定める
額（現行1,000万円）を超える場合に、その2分の1以上の
額の発行保証金を供託する義務
（銀行等の保証契約でも可）。

供託そのものには、手数料はかからないが、
大抵は金融機関経由となり振込み料がかかる。

前払式支払手段の保有者への払戻しを原則禁止し、
廃業等の場合に払戻しを義務づける。

消費税は、前払金を物品又は役務の購入に
利用するときに計上する。

雑務が増えるなあ、、、、。

-----------------------------------------------
前払式支払手段のユーザ・メリットは、
親によるPaypal支払いを一回ですませ、
教材毎に細切れに支払える、
これだけか。
-----------------------------------------------
現状のやる勉の問題点

・支払い方法がPaypalしかないので子供が払えない。

 (前払式支払では、改善はてきても解決できない)

 前払式支払は検討したが導入はやめよう。

----------------------------------------------

前払式支払手段に関連する法律は、
「資金決済に関する法律」
URL http://law.e-gov.go.jp/announce/H21HO059.html
の第二章　前払式支払手段 の 第二節　自家型発行者

「資金決済に関する法律施行令」
平成二十二年三月一日政令第十九号）
http://law.e-gov.go.jp/announce/H22SE019.html

「前払式支払手段に関する内閣府令」
（平成二十二年三月一日内閣府令第三号）
http://law.e-gov.go.jp/announce/H22F10001000003.html
の 「第二章　自家型発行者（第九条―第十三条）」

iPhone iPad の改善点

iPhone、画面全体が少しズームされ元に戻らなくなりかなり焦る。3本指タップで、画面全体が少しズームされる、元に戻すには、また3本指タップ。余分な機能だね。

iPhoneの設定、良く使う設定だけが自動で先頭に集まるヒストリーが欲しい。探したくない。

iPhone(3GS)のサウンドオン/オフは、押しても動かない。ボタンじゃなくて前後スライドだった。iPod機能の音は関係なし。

iPhoneのかなフリック入力、右利きなので、見える左上側に4文字が出て欲しい。左利きなら、右上側に。

iPad((カーナビやコンビに端末)の50音かなキーボード、なんで「あいうえお」が、左側縦列なのか、日本人の常識は、右側縦列ではないのか。
横文字対応なら、横に「あいうえお」縦に「あかさたな」もう一列で「はまやらわ」でしょうに。
(カーナビやコンビに端末でも、ときどきそうなんだよなあ、だからソフト技術者は配慮が足りないと思われる)

MySQLで高速処理するSELECT文の書き方案

(1)LEFT JOINとRIGHT JOINは、必要の無い限り使わない

LEFT/RIGHT JOINは、JOINする相手(RIGHT/LEFT)にないレコードを結果セットに残す機能。

MySQL 5.1 リファレンスマニュアル 6.2.11. 外側Join 単純化
では、
「オプティマイザが外側joinオペレーションのjoinクエリ計画を評価する際、各オペレーション時、外側テーブルが内側テーブルより前にアクセスされます。そのようなプランは、入れ子ループスキーマによる外側joinオペレーションを含むクエリの実行のみ可能なため、オプティマイザ選択肢は制限されています。」
と書いてある。

外側joinとは、LEFT JOINとRIGHT JOINのことである。

(2)INNER JOINのON節は、使わずWHERE節で条件を指定してよい。

MySQL 5.1 リファレンスマニュアル 6.2.11. 外側Join 単純化
では、
「T1 INNER JOIN T2 ON P(T1,T2)フォームの全ての内側join表現は T1,T2、P(T1,T2)結合されたWHERE条件によって置き換えられます。(あるいは、組み込まれたjoinのjoin条件が存在する場合は、それに置き換えられます)。」
と書いてある。

苦労してON節を書く、つまり構文を覚える必要はない。

(3)あとはMySQLオプティマイザに任せる

MySQLオプティマイザは、かなり賢いらしいが詳細が不明

以下は、推測

(4)FROM節で絞込み効果のあるテーブルを先に書く

理由:
- MySQLオプティマイザはどのテーブルから処理するか明言していないが、判断に困れば先に書いてあるテーブルを外部のFOR-LOOPで処理するらしい

(5)WHERE節では、できるだけ、トップレベルの結合をAND結合とする式にする

良い例: WHERE ( 式1 AND 式2 AND 式3 )

- ここで式1内部に OR が、あってもよい。

悪い例: WHERE ( 式X OR  式Y OR 式Z )

理由:

- MySQLオプティマイザの判断が容易になる
- AND結合なら評価順(テーブルFOR-LOOPの内外への移動)を簡単に変更できる。
- 対象レコードの絞込みが設計者にとって考え易い、


(6)WHERE節では、絞込み効果のある式を先に書く

 AND結合にした後での話であるが、MySQLオプティマイザが判断に困れば先に書いてある式を優先利用するらしいから

(7)OR結合なら、成立しやすい式を先に書く


(8)ネストするSELECTは書かなくてもよい。


どうも、レコードルーブが二回になると大概は遅いらしい。MySQLオプティマイザはネストを解消してから処理を始めようとするらしい。

ということで、早くなると信じて苦労してネストするSELECTは書く必要がなさそう。

遺言預かり所のFAQを改定しました。

遺言預かり所のFAQに説明を追加したほうが良いと思い、追加しました。
英語のFAQも同時に追加してあります。下手な英語ですが、、、。

追加は以下になります。

5.遺言預かり所にどのような遺言を預けたらよいですか



に以下を追加です。

以下の例はオンライン・サービスのユーザ名とパスワードがあるので完全に安全ではありません。
(相応しくない例) 幸せな人生でした。皆さんに感謝します。 全パスワードは、オンライン・サービス(やる勉)のメニュー:ツール/秘密メモにて管理中です。 URL: http://www.mylovewill.com/ya user: granpa@mail.com passwd: xxxyyyzzz 秘密メモ暗号キー: aaabbbccc 秘密メモのバックアップは、PC(user:granpa passwd:012345676)の C:\Users\granpa\Documents\MyProfile\PrivateBack.txt

9.家族に事前に知らせておく必要がありますか




に以下二点を追加です。


家族への通知は毎年一回程度行うことが好ましいでしょう。

以下の例はオンライン・サービスがあるので完全に安全ではありません
(相応しくない例) 件名: 暗号化遺言の復号用の鍵文字列 本文: もしも自分が連絡不能になった数日後に、 遺言預かり所から暗号化された遺言メールが送付されます。 遺言メールを復号する鍵文字列は、 xxxxxxxx です。 遺言メールには、 銀行口座 オンラインサービス等のパスワードを 暗号化して預けたオンライン・サービス(やる勉)のURLとパスワードが含まれます。 このメールは、大切に保管してください。

好試力研究所のホームページを改訂

好試力研究所のホームページに以下の二項目を追加しました。

やる勉のメモ帳

最近のメモから自動で並ぶメモ帳です。やる勉に組み込みです。ケータイでもパソコンでも利用でき情報の一元化になります。(無料)

やる勉の秘密メモ

あなたの秘密を暗号化してお預かりいたします。やる勉に組み込です。ケータイでもパソコンでも利用できます。(無料)

また、携帯電話かせホームページを見たとき、データサイズの大きな画像を送信しないようにして、携帯電話のエラーを防止しました。

やる勉のメモ帳機能

やる勉 に秘密メモを追加しましたが、
普通のメモ帳も必要と思い、追加しました。

つねに、日付順、最近のメモから、自動で並べられるメモ帳です。

何ページでも記入できます。
(ただし、無料会員は6ページまで)

メモを再編集すると、最新のメモとして最上位に移動します。

タイトルは、メモの先頭行から自動作成します。

ケータイ、ゲーム機、iPhoneなどのスマートフォン、
パソコンでメモの共有が簡単にできます。

やる勉に秘密メモ機能を用意しました

やる勉 に 暗号化して保存できる 秘密メモ機能 を追加しました。

弊社のプログラムを信用してもらえれば、十分安全に使えます。

参考までに、仕様概要を転記しておきます。

暗号キーと平文メモはサーバーに送信されますが、保存されません。
サーバープログラムは、暗号キーで平文を暗号にし、暗号だけを保存します。
暗号方式は、AESの256ピット鍵(rijndael-256, cbc-mode)です。
サーバーに保存された暗号文だけからは平文メモは判りません。
通常は安全にご利用いただけるはずですが、
万が一、サーバーのプログラムの改竄攻撃を受けた場合、
平文メモが流出する可能性があります。
リスク回避には平文にパスワードなどの重要機密を記入しないでください。
本システムが暗号キーと平文メモの対応を取ることはありません。
そのため暗号キーと平文メモの対応は各自で行う必要があります。
安全のためURLが https://www.mylovewill.com の弊社サイトであることを確認してください。
弊社より暗号キーや平文メモをお問い合わせすることはありません。
くれぐれも詐欺に会わないよう各自注意してください。
暗号キーは、各自で安全な場所に保存してください。