「6÷2(1+2)」問題について教育委員会に問い合わせてみた

厳密には「6÷2(1+2)」ではなくて、数字の部分が文字になっているものですが。「かけ算の順序問題」のように、呼びやすい名前があるといいのですが、そうでもないので、最近よく目にする「6÷2(1+2)」をタイトルにしてみました。

さて本題。

記号が省略されたかけ算と、明記されたわり算の優先順位については、検索すればいろいろ見つかります。最近では「6÷2(1+2)=1 or 9 まとめ」など。私は、そのまとめのコメント欄にも登場している黒木さん(過去のtweet)にまったく同意するものです。

入試問題

mondaiそんな中ちょうど、新聞で高校入試の問題を目にしました(画像は試験当日の夕刊)。そこにまさにこの問題が出ていたのです。1(1)ウがそれです。

問い合わせてみた

そこで、これを実施した県教育委員会にメールで問い合わせてみました。

---------------------------------
質問1
新聞では「解答例(県教委)」として本設問の答が「6a」となっていた。これは県教委が発表したものに間違いないか?

質問2
その答は、『「記号の省略されたかけ算」は「記号の明記されたわり算」より優先する』を前提としたときに導かれるが、この理解で正しいか?

質問3
そうだとすると、『「記号の省略されたかけ算」は「記号の明記されたわり算」より優先する』の根拠は何か? できれば典拠を示していただきたい。

質問4
数学において『「記号の省略されたかけ算」は「記号の明記されたわり算」より優先する』は常識ではない。すると本設問の答は「6 a^5 b^4」でもあり得る(ここで ^ はべき乗)。これも正解としないのか?

質問5
以上のように本設問はあいまいであり、入学試験問題としては不適切である。見解を伺いたい。
---------------------------------

回答があった

翌日にさっそくPDFファイルが添付されたメールで回答がありました。PDFといっても、1枚の画像そのままです。PDFにしている意味がよくわかりません。

回答の内容を書き写すと、

  • 答えは、県教委が発表したもので間違いありません。
  • 中学2年の数学『単項式の乗法、除法』において学習しています。
    • (教科書(啓林館)の例)
    • 「平成26年度 全国学力・学習状況調査」の出題例
  • 以上のように、中学校での学習や国の調査問題でも指導されております。このことから、学力検査問題として適切なものと考えております。

ということでした(式の部分はここに書き写すのが難しいのでPDFファイルを見てください)。

これから

こちらからの質問4、「これは数学においては常識ではない」がちょっと弱かったなと反省しています。自分でもそうは思っていたのですが、なるべく早く問い合わせたほうがいいと考えたので、じっくり考えて書く暇がなかったのでした。今回の回答のような“逃げ”を打たれないように、もう少し裏打ちのある根拠をこちらから挙げて聞くことができればよかったと思っています。このへん、どのような質問にすれば有効か、お知恵がありましたらコメントをいただければさいわいです。

ネットでああだこうだ言っていても、それだけで中学校の授業や高校入試の状況に影響を与えるのはなかなか難しいでしょう。しかし、高校入試というのはたいへんいい機会です。今回のように新聞に発表されますし、問い合わせれば出題ミスの可能性がある限り、まじめに検討して回答せざるを得ません。多くの問い合わせがあれば、各教育委員会からさらに本省のほうへ問い合わせが行くようになるかもしれません。少なくとも今回のような問題は「悪問」として、入試では避けよう、となるかもしれません。

何もしないよりはましだろうとまずは行動してみたよ、というお話でした。

【2019年2月4日追記】

この記事へのコメントは非常に長大になり、今後この記事を目にする人たちにとっては苦痛とも言えるほどになってしまいました。そのため、この記事へのコメントの受付は2019年2月4日をもって停止します。自由に意見を述べることを封殺する意図はありません。後にここを目にする人たちに対しての配慮です。ご理解ください。

この話題の続編とも言える記事が『「6÷2(1+2)」問題は100年前にも議論されていた』にあります。そちらにコメントしようとする場合は、ここに既にあるコメントと内容的に重複しないよう、慎重に考えた上でお願いします。

hubot-slack アダプタ v2 から v3 へ

もう日も変わろうという時間になっても Hubot Advent Calendar 2014 の13日目が埋まっていないようなので急遽飛び込んでみます。うーん、ちっともそれ向きの話ではないかも。

hubot の Slack アダプタ がバージョン 2 から 3 (これを書いている時点では 3.1.0)になりました。これに伴って Slack 側の Hubot Integration も様変わりしています。

試しに触ってみて、気づいた点をメモしておきます。

大きく変わったこと

Slack 側の Hubot Integration

発行される token の形式が変わりました。v2 から v3 に変更すると以前のものは使えず、改めてもうひとつ Hubot の integration を追加する必要があります(以前のものはあとで不要になれば削除)。

hubot の名前はここで設定します。

チャンネルは、はじめは #general にのみ参加している状態になります(後述)。

以前にはあった Hubot URL の欄はなくなりました。自前ホストの Hubot と Slack を連携させる場合につまづく点だったのですが、なくなりました。ということは、Hubot を動かすサーバーはたとえ NAT 越しの LAN の中でもよくなりました。テストのとき便利です。

環境変数はひとつ

Hubot 側で設定する環境変数は、上記の token の HUBOT_SLACK_TOKEN のみになりました。HUBOT_SLACK_TEAM は不要となり(たぶん token にその情報が含まれるのでしょう)、HUBOT_SLACK_BOTNAME も不要になりました(上記のように Slack 側で設定)。

名簿に現れるようになった

以前は名簿に現れず隠れメンバーのようなものでしたが、v3 ではまるで一般メンバーと同等の扱いです。従ってその名前をちゃんと設定しておく必要があり、それが Hubot Integration で行うものです。

一般メンバーに対して行うように、ダイレクトメッセージを送ることができます。名簿で hubot の名前をクリックするとその画面になりますが、ここではいつものように hubot ping と bot 名を前置せず、単に ping と入力するとちょうどいいという形になります。

参加チャンネル

はじめ、hubot は #general のみに参加している状態です。ほかのチャンネルに招待( /invite @hubot )すれば、そこに参加させることができます。プライベートグループにも参加させることができます。

これまで使っていたスクリプトが動かなくなるなどの影響について

今後更新されるかもしれませんので、あくまでこれを書いている時点の問題です。

【追記】2014年12月17日現在の最新版 3.2.0 で、下記のアットマーク問題とURL問題は解決されているようです。したがって以下のパッチは不要です。【追記終わり】

robot.messageRoom での room 名

これまでのバージョンでは Readme にも

Slack API uses channel ID’s by default, which uses computer-friendly alphanumeric ID. To use the pretty names, prefix it with a hash.
  robot.respond /hello$/i, (msg) ->
    robot.messageRoom '#general', 'hello there'

と書かれており、room 名にハッシュ(#)を付けることになっていました。

v3 ではちょうど逆になって、ハッシュ(#)を付けないようになりました。これが付いていると正しく動作しません。

たとえば現時点の hubot-rss-reader が引っかかりました。

アットマーク付きbot名に反応しない

これまでは、bot 名の前にアットマーク(@)があってもなくても、また後ろにコロン(:)またはカンマ(,)があってもなくてもよかった、つまり

hubot ping
hubot: ping
@hubot ping
@hubot: ping

はいずれもhubotへの命令として有効だったのですが、v3になってなぜか@付きが無効になっています。不具合だと思われますので、早晩解決するでしょう。

対策

プルリクエストされているパッチに、さらにコロンとカンマのところを修正して適用してみました(下記)。

URLをパラメーターにすると括弧がついてしまう

たとえば hubot-rss-reader

hubot add http://example.com/index.rdf

みたいにして使うのですが、自動的に hubot add 〈http://example.com/index.rdf〉 のように山括弧( 〈 と 〉 )が付加されたものが bot に渡されるため、スクリプトがこれを URL と認識しない、ということになってしまいます。

v2 にはこれに対する処理があったのですが、v3ではすっかりなくなっています。不具合だと思うのですが、開発者は割と悠長な構えに見えます。

対策

v2 にあった処理を持ってきて適用してみました。なにか不都合があるのかなあ。

--- slack.coffee.orig 2014-12-13 17:53:24.290393342 +0900
+++ slack.coffee 2014-12-13 19:42:08.788464223 +0900
@@ -8,6 +8,7 @@
constructor: (robot) ->
@robot = robot
+ @botUserID = null
run: ->
# Take our options from the environment, and set otherwise suitable defaults
@@ -44,6 +45,13 @@
loggedIn: (self, team) =>
@robot.logger.info "Logged in as #{self.name} of #{team.name}, but not yet connected"
+ # Go through the list of known users and find the name that matches ours
+ for id, user of @client.users
+ if user.is_bot and user.name == self.name
+ @botUserID = id
+ break
+ @robot.logger.info "Bot's Slack user ID is #{@botUserID}"
+
# Provide our name to Hubot
@robot.name = self.name
@@ -103,6 +111,11 @@
# If this is a DM, pretend it was addressed to us
if msg.getChannelType() == 'DM'
txt = "#{@robot.name} #{txt}"
+ # Or, if we were @-mentioned
+ else if matches = txt.match(/<@([^>]+)>[:,]?\s?(.*)/)
+ [userID, someText] = matches[1..2]
+ if @botUserID and (userID == @botUserID)
+ txt = "#{@robot.name} #{someText}"
@receive new TextMessage user, txt, msg.ts
view raw atmark.patch hosted with ❤ by GitHub
--- slack.coffee.orig 2014-12-13 17:53:24.290393342 +0900
+++ slack.coffee 2014-12-13 17:53:51.421673532 +0900
@@ -61,6 +61,24 @@
@client.removeListener 'close', @.close
@client.removeListener 'message', @.message
+ ###################################################################
+ # HTML helpers.
+ ###################################################################
+ unescapeHtml: (string) ->
+ try
+ string
+ # Unescape entities
+ .replace(/&amp;/g, '&')
+ .replace(/&lt;/g, '<')
+ .replace(/&gt;/g, '>')
+
+ # Convert markup into plain url string.
+ .replace(/<((\bhttps?)[^|]+)(\|(.*))+>/g, '$1')
+ .replace(/<((\bhttps?)(.*))?>/g, '$1')
+ catch e
+ @robot.logger.error "Failed to unescape HTML: #{e}"
+ return ''
+
message: (msg) =>
return if msg.hidden
return if not msg.text and not msg.attachments
@@ -96,7 +114,7 @@
else
# Build message text to respond to, including all attachments
- txt = msg.getBody()
+ txt = @unescapeHtml msg.getBody()
@robot.logger.debug "Received message: '#{txt}' in channel: #{channel.name}, from: #{user.name}"

attachment が使えなくなった

この機能を使っていないので詳しいことは述べません。さっそく別のスクリプト hubot-slack-attachment ができているようです。

Hubot で docomo 「雑談対話」API を使う — “敬称”を Hubot コマンドに

これは Hubot Advent Calendar 2014 の 5 日目の記事です。が、その流れにうまく乗れているのかいないのか。1週間ほど前に自分の書いた「Hubot ping の日本語化」に引き続き、Hubot を日本語で楽しく使おうという話です。Advent Calendar の前日(4日)の記事の最後のほうでも、メッセージを日本語化するとより親しみがわく(あるいは腹が立つ)というお話でしたね。

さてさて、存在確認(ping)以外にもう少し会話的なものを楽しみたいのですが、大量の質問と答を仕込むのは労力の割に楽しくなさそうだし、人口無能みたいなものを組み込むのはこちらの技量からして難しいし……と考えあぐねていたところに、docomo Developer support 提供のAPI「雑談対話」というものを見つけました。しかもちょうど開発用APIキー有効期間の制限が廃止され、特に本申請をせずともよくなりました。

hubot-docomo-dialogue をつくった」を参考にしました。そこでは、すべての発言に反応するよう

...
  robot.hear /.*/, (res) ->
...

となっていました。しかし、これではまじめな話をしているところに割り込んできてうっとうしいので robot.respond にしたいところです。さりとて、コマンドを日本語化したとしても

user> わぷー 雑談 今日は寒かったね。

というのも無粋というか興ざめです(「わぷー」というのは bot の名前です。hubot の起動時に bin/hubot --name wapuu --alias わぷー として起動して、日本語名を与えています)。

“敬称”をコマンドに

ちょっと思案して、敬称の「さん」をコマンドにしてみました。

...
  robot.respond /さん(?:、)?\s*(.*)/, (res) ->
...

使用する時は、bot名とコマンドのあいだの空白は実はなくても大丈夫なので、

user> わぷーさん、今日は寒かったね。

と、ずいぶん自然な文体にすることができます。「わぷー」がbot名、「さん、」がコマンド、「今日は寒かったね。」が処理に渡されるパラメータと解釈されます。

Hubot のほかのちゃんとしたコマンドのときは呼び捨て、雑談したいときは「さん」付け、と使い分けることになります。

Wikipedia「敬称」にあるものを適当に詰め込み、読点をつけてもつけなくてもいい(ただし呼び捨てに読点を付けると雑談になる)ようにしました。

雑談対話 API

雑談対話と知識Q&A雑談対話 API には“会話の継続”というものがあります。いったん言葉(リクエスト)を投げかけ、返答に含まれる「コンテキストID」を次のリクエストにつければ継続的な対話になるというものです。この機能も組み込むことにしました。これでしりとりもできるようになりました(「わぷー、りんご」みたいにいちいち呼びかけなければなりませんが)。そして、2分あいだをあけると継続としないことにしました。

できた script は

です。

試してみましたが、しりとりは確かに上手にできます。しかし継続対話は期待ほどではなく、的外れなものになりがちでした。API の向こう側の対話能力は今後バージョンアップされるのでしょうか。

同様の docomo API 「知識Q&A」を利用するための docomo-knowledge.coffee も作ってみました。

こちらも試してみましたが、うーん、あんまり実用的な答は返ってきませんね。

user> わぷー教えて、ロスはいま何時?
wapuu> ロサンゼルスの今の時刻は15時35分です。

がちょっと便利なくらいです。

Hubot ping の日本語化 — 「いるのか?」の正規表現

Hubot の ping コマンド

hubot_wapuuSlack というコミュニケーションツールを利用することになって、そこでこれは便利かもということで Hubot をいじってみています。

現時点での安定版 Debian Wheezy に Hubot をインストールするにはどうすればいいんだとか、Slack に連携させるときに Heroku を使う方法ならすぐに見つかるが、自前ホストのHubotとSlackを連携させるにはどうするんだとか、いくつか引っかかりながらも、ここにリンクした情報が既にあったのでうまくいきました。

この bot がちゃんと作動しているかどうか反応を見るのに、ping というコマンドがはじめからサンプルとして付属しています。bot の名前に ping と付けて問いかけると、PONG と答えるというものです。

user> hubot ping
hubot> PONG

さて、「HubotのScriptを翻訳するとかわいい」にありますように、日本語化すると愛着がわきます。ping の Script はとても簡単で、肝は

  robot.respond /PING$/i, (msg) ->
    msg.send "PONG"

です。使用目的はとにかく存在確認ですから、日本語にすると

  robot.respond /いるのか\?$/i, (msg) ->
    msg.send "はい、ここにいます!"

です。

また、Hubot を起動するときに bot 自身の名前と別名を付けることができます。そこでこれを日本語で

bin/hubot --name wapuu --alias わぷー

と付けてやると、ますます親しみがわきます。これで応答は

user> わぷー いるのか?
wapuu> はい、ここにいます!

となりました。

「いるのか?」のバリエーションの正規表現

このままですと、script の質問文のところは正規表現で書けるのに、ただ「いるのか?」に正確にマッチしないと返答しないということになっています。

「いるのか?」の分解存在確認の日本文「いるのか?」を考察してみます。これを4つ(疑問符を入れると5つ)に分けて、それぞれのバリエーションとその組み合わせを思いつくまま挙げてみました(図)。ありえない組み合わせ—たとえば、2段目が「ります」のとき、その前に「い」はありえない—の制限を付け加えながら、正規表現にして書いてみると、次のようになりました。

/(((い|ゐ|居)(て?))(?!り)|(お|を|居)|((い|居)(て?)は)(?!ま))((る|ん(?=の))|((り?)ます)(?!ん))((の?ん?)(です)?|(んだ)(?!か))?(か(い?な?|よ|ね)?|(よ?)(ね|な))?\s?(\?|?)/

これで、質問文は「いる?」から「いてはりますのんかいな?」(いや、これが現実にありうる表現かどうか確証は持てないのですが)まで対応できます。

ping の目的は存在確認なので、日本語では「生きてる?」とも言いそうです。1段目の前に「生きて」を付けて、元の1段目を必須から任意に変更すればよさそうです。さらに、「調子どう?」「元気?」というフレーズもよく使いそうですね。これはもうそのままということにします。だんだん手抜きになってきました。

結局、日本語版 ping はこうなりました。

  robot.respond /(((い|ゐ|居)(て?))(?!り)|(お|を|居)|((い|居)(て?)は)(?!ま))((る|ん(?=の))|((り?)ます)(?!ん))((の?ん?)(です)?|(んだ)(?!か))?(か(い?な?|よ|ね)?|(よ?)(ね|な))?\s?(\?|?)/i, (msg) ->
    msg.send "はい、ここにいます!"

  robot.respond /(い|生|活)きて(((い|ゐ|居)(て?))(?!り)|(お|を|居)|)?((る|ん(?=の))|((り?)ます)(?!ん))((の?ん?)(です)?|(んだ)(?!か))?(か(い?な?|よ|ね)?|(よ?)(ね|な))?/i, (msg) ->
    msg.send "はい、ここにいます。"

  robot.respond /(調子どう|元気)/i, (msg) ->
    msg.send "はい、元気です。"

wapuu_pingちゃんと数えていませんが、これで「いるのか?」を意味する数十種類の表現に答えることができるようになりました。

このWapuu bot は、WordPress の日本語コミュニティがこれから活用していこうとしている Slack にいます。WordPress 本体の開発元でこの Slack を使っていくことになったことに触発され、そこに収まりきれない話題—日本語圏特有の話題、日本語で話したほうが楽な話題など—を扱っていこうという場所です(たぶん)。単に「WordPressの使い方」を尋ねるような場所ではありませんが、何かちょっとでも手助けしたい(日本語圏で最も求められているのはたぶん翻訳です。本体のみならず多くのドキュメントやニュースなどが翻訳されるのを待っています。もちろんほかにも何かがあります。たとえばこの記事のように、どうでもいいような冗談を仕込むとかもきっと)と思っている方があればぜひ参加してみてください。参加資格などなく、参加方法の手続きを踏めさえすれば誰でも参加できます。Wapuu bot はそこで待っています。

昨年のクリスマスプレゼント「ビルダーキット テクノ ツールボックス」

今年もそろそろサンタクロースの代理としてクリスマスプレゼントを考えなければならない時期になりました。昨年のプレゼントを思い出してみますと……。

当時5歳のスウちゃん(仮名)に届いたのは、Quercetti の「ビルダーキット テクノ ツールボックス」。しばらく前から、大人がちょっとした家具を組み立てたり自動車のタイヤを交換したりするときに「スウちゃんも!」とスクリュードライバーやスパナを持ちたがるので、こういうものにしてみました。

難易度はそれほど高くなく、前年(4歳)の Zometool と順番が逆だったかなという感じも少ししましたが、これはこれで非常に楽しんでくれました。

簡単な作成例(完成図のみ)の冊子が付いていて、はじめはそれをまねて作っていました。徐々にオリジナルの車や、収納箱の蓋(たくさん穴が開いていてネジがきってある)に平面状に絵を作ったり。

場所によって適切な長さを選ぶとか、その頭のミゾに合わせて工具を変えるとか、さらにナットを締めるときに反対側のボルトも工具で押さえておかなくてはならないというような、どうかすると大人でもうっかりしそうな技を習得しつつあります。

プラスチック製のボルトとナットで(ほかのパーツや工具もすべて)、車のハンドルなど可動部はすぐに緩んできてしまうのがやや難ですが、逆にこれがきっちり締まるようになっていると、幼児の手ではとれなくなってしまうのかもしれません。

ドミノとさんすう

ドミノ

スウちゃん(仮名、6歳)は保育園から帰るととにかく「遊びたい」。眠っていないあいだはとにかく遊び続けなければ死んでしまうというくらい遊びたい。といって家や近所に子どもはいないから、一人遊びじゃなければ大人が相手をすることになる。いろんなゲームもやってきた。カルタ、すごろく、どうぶつしょうぎ、オセロ……。そして最近の流行はドミノだ。

【DOMINO W6 in The Wooden Box】木箱入プラスチック製ドミノ W6 白黒Premium Set of 55 Double Nine Dominoes with Wood Case, Brown いまうちにあるのは私(=スウちゃんの父)が学生の頃に麻雀牌も売っているようなおもちゃ屋で買ったもの。でもいま日本でちゃんとしたもの[1]はあまり売っていなさそうだ。「木箱入プラスチック製ドミノW6白黒」だと真ん中に鋲がないなあ。Amazon USA のダブル・ナインは鋲あり。日本から買うと送料が本体と同じくらいかかってしまう。

ルールは「ファイブ・アップ」(参考1参考2)。

しばらくは点数関係なしで、札の出し方を学習。ゲームとなれば子どもは簡単に覚える。

続いてプレイ中の得点。どれを出せば得点になるかなんて戦略もないのでとにかく出せるものを出す。たし算ができないので、出したものを大人が計算してやる。「5の倍数だったら、5で割った商が得点」なのだが、意外に早く5の倍数を覚える。「15」→「3点!」、「20」→「4点!」のように[2]

終了時は「相手の手に残った目の合計を5で割った値(うちでは端数切り捨てというローカルルール)」でやっているが、これも合計を大人がやってやれば「その中に5はいくつ入ってる?」と聞けばほぼ得点を出せる。九九で言えば「5の段」が、それも九九とは全然別の形で頭に入っているらしい[3]。ゲームだとこんなことまでできるんだなあ。

まともな勝負には程遠いが、とりあえずなんとかゲームの体をなすことはできる。さて、大人は手札を元に計算しながら出せるので、強い。同じ札でもあっちに出せば得点できるのにこっちに出すと得点できないということも起こる。子どもはだんだん悔しくなってくる。ここで「たしざんができるようにならないとつよくなれないねー」ということになる。

たたみかけるように、ここでダブル・ナインのセットに替えて同じゲームをやると目の数がぐっと増えるので、それまではたし算できなくても目を数えあげて何とか出来ていたものも追いつかなくなり、いよいよ悔しさをつのらせる。

さんすう

1年ほど前、何の拍子だったか忘れたけれど数に興味を示して、そのうち「同じ数を2回」、つまり「2と2は4」「3と3は6」「4と4は8」……を言えるようになっていた。九九で言えば「2の段」に相当する。せっかくそういう興味が出てきたのならちゃんとやってあげようか、などと考えて、道具を揃えてみた。

カラフルマスキューブ テキストには「わかるさんすう 1」。かなり古くまた検定は通しはしないけれど「教科書」としてしっかり練られたものということを知っていたので、これにしてみた。Amazon では手に入りにくいが、ふつうに街の本屋さんで注文したら簡単に入手できた。

わかるさんすう 1」では、「タイル」を使う。手作りでもいいけれど、横着して買うことにした。「タイル」ではなくて「キューブ」。似たような商品もあるが、安さと、それに「接続できる」ということでこれにした。またちょっと別のもので「100だまそろばん」というのもよく評判を聞くが、やはり自由さの点でキューブにした。

2カラーせんせい 紙が潤沢に使えるのであればそれがいいのだろうけれど、きりがないのでうちではもっぱらおえかきボードを活用している。

いまは2色の「2カラーせんせい」なんだな。うちにあるのはおさがりでもらった「スーパーせんせい」で1色のもの。元の持ち主は4歳くらいでもう飽きて遊ばなくなったからと、スウちゃんが1歳か2歳のころにもらったものだが、うちではいまだ現役。でもこういう用途だと、もうすこし画面が大きく、また解像度が高いといいなと思う。

さてさて、今から1年ほど前にこうして「さんすう」をやりかかってみたけれど、スウちゃんははじめのあいだはともかく、ほどなく興味を失ってしまった。こちらも是が非でも早期教育をとも思っていなかったし、ただ、もし数に興味を示すのなら(ほら数学の天才は幼児期からそうだと言うでしょう)その芽を摘まなくても、という程度の考えだったので、めったに日の目を見なくなっていた。つまりスウちゃんは数学に関しては天才ではなかったわけだが。

ふたたび「さんすう」

時は戻ってふたたび現在。ドミノのおかげで、たし算をできるようになりたい、という気がスウちゃんに俄然湧いてきた。こうなると見向きもしなかったテキストとキューブ(ブロック)に取り組み始める。

いまは

  • 5-2進法は強くこだわらないことにする。本人がどちらが楽かまだわからないので。
  • たし算を同時にひき算も教える。「7は5と2だから……」のように、たし算の過程でひき算に相当する部分が出てくるので。
  • ほとんど最初から筆算(縦書き)にする。この先の繰り上がりを見据えて。
  • 適宜ブロックを使う。
  • いまのところ、素過程を網羅的に、とは考えない。これは「水道方式」のいいところを落としているのかもしれないけれど。少し先にひき算(13−7など)をやるときに困るかもしれない。そのへんは行きつ戻りつやればいいか。
  • 文章題も適宜。逆に「たし算の問題を作る」ような作業も多めに。

という感じで進めている。

自由な発想

スウちゃんはすごろくなどのゲームやドミノでサイコロ(の目の形)に親しんでいたからか、「6は3と3」の意識が強い。5-2進法のための「6は5と1」とはなかなかならない。そこで「6+3」を計算する際はブロックを3×2に並べ、そこに3つのブロックを加えて3×3の形にし、「こたえは9」になる。どうやらイメージ先行らしい。

この先の発展のためにはどうかとも思うが、まだカリキュラムに沿った学習をしていない子どもの発想は自由でおもしろい。「8−2」は、まず2×2×2の立方体を作って「8」。なんだそれ。3次元じゃないか。2の3乗だよ。それから2つをとり、変形させて3×2にして「6」。このへんはボール紙で作ったタイルじゃなくて、縦横に接続できるカラフルマスキューブにしていたからこそだったかもしれない。

世の中、算数だけで出来ているわけではないから、小学校に入って型通りの授業が始まるまではこの自由な発想を楽しむことにしよう。

さて、こんな調子でスウちゃんはドミノが上手になれるだろうか。

  1. と言っても、うちのもさすがに象牙製ではない。ドミノ倒し用ではなく樹脂製の適度な重みのもの。
  2. これと同時期に時計の分針を読めるようになり、「ドミノといっしょ!」と叫んでいる。
  3. いまの段階で九九の暗誦なんて絶対にやらせたくない。

リモートに置いてある音楽ファイルをローカルPCのスピーカーで鳴らす

以前に「インターネットラジオを FM ラジオで聴く」というのを書きました。少し離れた場所にあるマシンにFMトランスミッターを付け、目の前のPCから操作する(そしてFMラジオで聴く)というものでした。

それから月日は流れ、ハードウェアを入れ換えたり、その際にOSもすっかりインストールし直したりしているうちに、そのリモートのマシンでの音声出力ができない状態になってしまいました。

そこで前回とは逆に「リモートに置いてある音楽ファイルをローカルPCのスピーカーで鳴らす」というのが、今回やりたいことです。目新しいことは何もなく、既に情報がどこかにあったので楽でした。自分のためのメモも兼ねてここに書いておきます。

先にまとめておくと、

  • リモート
    • 音楽ファイルが置いてある
    • Pulseaudio
    • MPD
  • ローカル
    • スピーカーが接続されている
    • Pulseaudio
    • gmpc

という構成になります。

Pulseaudio

ここではリモートもローカルも OS は Debian (これを書いている時点での安定版)です。

まず、ローカルで

sudo apt-get install pulseaudio
と pulseaudio をインストールし、

paplay local-sample.ogg

などとやってちゃんと動いていることを確認します。ところがここで音が出ませんでした。

sudo apt-get install pavucontrol

とやって pavucontrol で、「出力装置」を見ると、ポートが「HDMI」になっていました。ここの環境ではそこにスピーカーはなく、USBポートにサウンドアダプタを挿してその先にスピーカーがある状態です。「設定」で、GF108 High Difinition Audio Controller が HDMI になっているので、これを Off にすると、「出力装置」のポートが「スピーカー」または「デジタル出力(S/PDIF)」になって、音が出るようになりました。

リモートとローカルの Pulseaudio の設定

ローカルの /etc/pulse/default.pa で、

load-module module-native-protocol-tcp auth-ip-acl=192.168.1.0/24

リモートの /etc/pulse/client.conf で、

default-server = 192.168.1.xxx (スピーカーのあるPC)

とします。必要に応じてローカルのポート 4713 を開けます(今回のローカルPCはファイアーウォールを置いていないので特に設定の必要なし)。

テストとして、リモートで

paplay remote-sample.ogg

などとやるとローカルのスピーカーが鳴ります。

MPD

当初の目的は達成されましたが、このままでは不便なので、MPD を使うことにします。これは音楽再生やプレイリスト管理をリモートから行うためのものです。

リモート

まず

sudo apt-get install mpd

でインストールします。/etc/mpd.conf で、music_directory に音楽ファイルの置いてあるディレクトリを設定し、bind_to_address に接続を許すアドレス(今回は(LAN内の)どこからでも接続できるよう “any” としました)を設定します。

出力先の設定は

audio_output {
        type            "pulse"
        name            "My Pulse Output"
#       server          "remote_server"         # optional
#       sink            "remote_server_sink"    # optional
}

とします。ここで mpd を再起動します。

ローカル

ローカルPCには、gmpc をインストールして使います。これは高機能で、細かな設定やプレイリストの管理を行うことができます。ふだんは、再生/ポーズ/停止くらいの操作しか必要ではないので、シンプルな xfce4-mpc-plugin をパネルに置いてこれを使うことにします。

sudo apt-get install gmpc xfce4-mpc-plugin

どちらも、ホストとして MPD を動かしているリモートのマシンを指すように設定します。