  |
はてなキーワード: 整数とは
8進数において
a+b+c+d+eが7の倍数のとき
整数abcde
＝10000a＋1000b＋100c＋10d＋e
は
（7777a＋a）＋(777b＋b)＋（77c＋c）＋（7d＋d）＋e
＝（a+b+c+d+e）+7（1111a＋111b＋11c＋d）
よってa+b+c+d+eが7の倍数のとき8進数abcdeは7の倍数
Table of Contents： ||||||
| オープンソースソフトウェアとGIS | Open Source software and GIS | Open Source software and GIS | 1 (6) |
| オープンソース概念 | Open Source concept | 1 (2) | |
| オープンソースGISとしてのGRASS | GRASS as an Open Source GIS | 3 (2) | |
| ノースカロライナサンプルデータセット | The North Carolina sample data set | 5 (1) | |
| この本の読み方 | How to read this book | 5 (2) | |
| GISの概念 | GIS concepts | GIS concepts | 7 (14) |
| 一般的なGISの原理 | General GIS principles | 7 (6) | |
| 地理空間データモデル | Geospatial data models | 7 (4) | |
| GISデータとシステムの構成 | Organization of GIS data and system | 11 (2) | |
| 機能 | functionality | ||
| 地図投影法と座標系 | Map projections and coordinate systems | 13 (8) | |
| 地図投影原理 | Map projection principles | 13 (3) | |
| 一般的な座標系とdatums | Common coordinate systems and datums | 16 (5) | |
| GRASSをはじめよう | Getting started with GRASS | Getting started with GRASS | 21 (32) |
| 第一歩 | First steps | 21 (16) | |
| GRASSのダウンロードとインストール | Download and install GRASS | 21 (2) | |
| データベースとコマンドの構造 | Database and command structure | 23 (3) | |
| GRASS6のためのグラフィカルユーザインタフェイス: | Graphical User Interfaces for GRASS 6: | 26 (1) | |
| QGISとgis.m | QGIS and gis.m | ||
| ノースカロライナを用いてGRASSを開始 | Starting GRASS with the North Carolina | 27 (3) | |
| データセット | data set | ||
| GRASSデータ・ディスプレイと3D可視化 | GRASS data display and 3D visualization | 30 (4) | |
| プロジェクトデータ管理 | Project data management | 34 (3) | |
| 新しいプロジェクトでGRASSを開始 | Starting GRASS with a new project | 37 (7) | |
| aのための座標系の定義 | Defining the coordinate system for a | 40 (4) | |
| 新しいプロジェクト | new project | ||
| 空間投影されていないxy座標系 | Non-georeferenced xy coordinate system | 44 (1) | |
| 座標系の変換 | Coordinate system transformations | 44 (9) | |
| 座標系のリスト | Coordinate lists | 45 (2) | |
| ラスタとベクトル地図の投影 | Projection of raster and vector maps | 47 (1) | |
| GDAL/OGRツールで、再投影 | Reprojecting with GDAL/OGR tools | 48 (5) | |
| GRASSデータモデルとデータの交換 | GRASS data models and data exchange | 53 (30) | |
| ラスターデータ | Raster data | 54 (16) | |
| GRASSの2Dの、3Dのラスターデータモデル | GRASS 2D and 3D raster data models | 54 (2) | |
| 領域の統合と境界 | Managing regions and boundaries | raster map resolution | |
| ジオコードされたラスターデータのインポート | Import of georeferenced raster data | 58 (8) | |
| スキャンされた歴史的地図のインポートとジオコーディング | Import and geocoding of a scanned | 66 (3) | |
| ラスターデータエクスポート | Raster data export | 69 (1) | |
| ベクトルデータ | Vector data | 70 (13) | |
| GRASSベクトルデータモデル | GRASS vector data model | 70 (3) | |
| ベクトルデータのインポート | Import of vector data | 73 (5) | |
| xy CAD描画のための座標変換 | Coordinate transformation for xy CAD drawings | 78 (2) | |
| ベクトルデータのエクスポート | Export of vector data | 80 (3) | |
| ラスターデータを使う | Working with raster data | 83 (86) | |
| ラスター地図を表示、管理 | Viewing and managing raster maps | 83 (22) | |
| ラスターデータの表示と、カラーテーブルの割り当て | Displaying raster data and assigning a color table | 83 (3) | |
| ラスター地図に関するメタデータを管理 | Managing metadata of raster maps | 86 (2) | |
| ラスター地図のクエリとプロファイル | Raster map queries and profiles | 88 (2) | |
| ラスター地図の統計 | Raster map statistics | 90 (1) | |
| ラスター地図のズームと、部分集合の生成 | Zooming and generating subsets from | 91 (1) | |
| 簡単なラスター地図の生成 | Generating simple raster maps | 92 (2) | |
| 再分類と再スケーリング | Reclassification and rescaling of | 94 (3) | |
| ラスター地図 | raster maps | ||
| ラスター地図タイプの記録と値の置換 | Recoding of raster map types and value replacements | 97 (2) | |
| カテゴリラベルの割り当て | Assigning category labels | 99 (4) | |
| マスキングとノーデータ値の取り扱い | Masking and handling of no-data values | 103(2) | |
| ラスター地図の計算 | Raster map algebra | 105(10) | |
| 整数と浮動小数点データ | Integer and floating point data | 107(1) | |
| 基本的な計算 | Basic calculations | 108(1) | |
| “if"状態を使う | Working with ``if'' conditions | 109(1) | |
| r.mapcalcのNULL値の取り扱い | Handling of NULL values in r.mapcalc | 110(1) | |
| r.mapcalcでMASKを作成 | Creating a MASK with r.mapcalc | 111(1) | |
| 特別なグラフ演算子 | Special graph operators | 112(1) | |
| 相対的座標での近傍演算 | Neighborhood operations with relative coordinates | 113(2) | |
| ラスタデータの変換と内挿 | Raster data transformation and interpolation | 115(11) | |
| 離散的ラスターデータの自動的ベクトル化 | Automated vectorization of discrete raster data | 115(3) | |
| 連続フィールドの等値線の描画を生成 | Generating isolines representing continuous fields | 118(1) | |
| ラスタデータのリサンプリングと内挿 | Resampling and interpolation of raster data | 119(5) | |
| ラスター地図のオーバーレイとマージ | Overlaying and merging raster maps | 124(2) | |
| ラスターデータの空間分析 | Spatial analysis with raster data | 126(29) | |
| 近傍分析とクロスカテゴリー統計 | Neighborhood analysis and cross-category statistics | 126(7) | |
| ラスタフィーチャのバッファリング | Buffering of raster features | 133(2) | |
| コストサーフェイス | Cost surfaces | 135(5) | |
| 地勢と分水界分析 | Terrain and watershed analysis | 140(13) | |
| ランドスケープ構造解析 | Landscape structure analysis | 153(2) | |
| ランドスケーププロセスモデリング | Landscape process modeling | 155(11) | |
| 水文学的、地下水のモデル | Hydrologic and groundwater modeling | 155(3) | |
| 浸食と宣誓証言モデル | Erosion and deposition modeling | 158(8) | |
| ラスタベースのモデルと解析に関するまとめ | Final note on raster-based modeling and analysis | 166(1) | |
| ボクセルデータを使う | Working with voxel data | 166(3) | |
| ベクトルデータを使う | Working with vector data | 169(94) | |
| 地図の表示とメタデータ管理 | Map viewing and metadata management | 169(4) | |
| ベクトル地図を表示 | Displaying vector maps | 169(3) | |
| ベクトル地図メタデータ維持 | Vector map metadata maintenance | 172(1) | |
| ベクトル地図属性管理とSQLのサポート | Vector map attribute management and SQL support | 173(14) | |
| GRASS6でのSQLサポート | SQL support in GRASS 6 | 174(7) | |
| サンプルSQLクエリと属性変更 | Sample SQL queries and attribute modifications | 181(4) | |
| 地図再分類 | Map reclassification | 185(1) | |
| 複数の属性があるベクトル地図 | Vector map with multiple attribute tables: layers | 186(1) | |
| ベクトルデータをデジタル化 | Digitizing vector data | 187(5) | |
| 位相的データのデジタル化の一般原理 | General principles for digitizing topological data | 187(2) | |
| GRASSでの対話的なデジタイジング | Interactive digitizing in GRASS | 189(3) | |
| ベクトル地図クエリと統計 | Vector map queries and statistics | 192(4) | |
| 地図のクエリ | Map queries | 192(2) | |
| ベクトルオブジェクトに基づくラスター地図統計 | Raster map statistics based on vector objects | 194(2) | |
| ポイントベクトル地図統計 | Point vector map statistics | 196(1) | |
| 幾何学操作 | Geometry operations | 196(20) | |
| 位相的な操作 | Topological operations | 197(6) | |
| バッファリング | Buffering | 203(1) | |
| フィーチャの抽出と境界のディゾルブ | Feature extraction and boundary dissolving | 204(1) | |
| ベクトル地図を修理 | Patching vector maps | 205(1) | |
| ベクトル地図のインターセクディングとクリッピング | Intersecting and clipping vector maps | 206(3) | |
| ベクトルの幾何の変換と3Dベクトルの作成 | Transforming vector geometry and creating 3D vectors | 209(2) | |
| 点からのコンベックスハルとトライアンギュレーション | Convex hull and triangulation from points | 211(1) | |
| 同じ位置の掘り出し物の複数のポイント | Find multiple points in same location | 212(2) | |
| 一般的な多角形境界の長さ | Length of common polygon boundaries | 214(2) | |
| ベクトルネットワーク分析 | Vector network analysis | 216(11) | |
| ネットワーク分析 | Network analysis | 216(5) | |
| 直線的な参照システム(LRS) | Linear reference system (LRS) | 221(6) | |
| ラスタへのベクトルデータ変化 | Vector data transformations to raster | 227(3) | |
| 空間的な内挿と近似 | Spatial interpolation and approximation | 230(19) | |
| 内挿方法を選択 | Selecting an interpolation method | 230(5) | |
| RSTによる内挿と近似 | Interpolation and approximation with RST | 235(2) | |
| RSTパラメタの調整: テンションとスムージング | Tuning the RST parameters: tension and smoothing | 237(4) | |
| RSTの精度を評価 | Estimating RST accuracy | 241(3) | |
| セグメント化処理 | Segmented processing | 244(3) | |
| RSTとのトポグラフィー分析 | Topographic analysis with RST | 247(2) | |
| ライダーポイントのクラウドデータを使う | Working with lidar point cloud data | 249(8) | |
| ボリュームに基づくは内挿 | Volume based interpolation | 257(6) | |
| 3番目の変数の追加: 高度のある降水量 | Adding third variable: precipitation with elevation | 258(3) | |
| ボリュームとボリューム-時間内挿 | Volume and volume-temporal interpolation | 261(1) | |
| 地球統計学とスプライン | Geostatistics and splines | 262(1) |
一部のはてな記法
gcdは最大公約数
pow(a,b)はaのb乗
mod(a,b)はaをbで割ったときの余り
｛1,2,…,N-1｝から適当にgcd(a,N)=1となるaを取る
aのNを法とした位数rを求める
aのNを法とした位数rを求めるには
としてf(x+kr)=f(x)となるrを求める（kは任意の自然数？）
rが偶数になるまでaを取るとこからやり直す
p=gcd(pow(a,r/2)+1,N)
q=gcd(pow(a,r/2)-1,N)
p,qのいずれかがNでなければそれらが求めたい因数
らしい
で、rを求めるところがイマのコンピュータだと大変で、
Sony Japan｜プレスリリース | 液晶テレビ＜ブラビア＞の情報閲覧機能「アプリキャスト」個人向けソフトウェア開発ツールを公開
早速見てみた。
ここからBRAVIAに搭載されてるJavaScriptインタプリタのソースがダウンロードできる。
まんまSpiderMonkey。
つまりフルのJavaScriptの言語仕様がサポートされてるってこと。
「３の倍数と３の付く数字だけアホになる」世界のナベアツが整数列においてどの程度アホになるかを判定する、所謂「世界のナベアツ問題」があり、どうやら死ぬほど続けていくと、限りなく100%に近い確率でアホになるようであるが、この問題に対しする数学的アプローチは理系の方々に任せ、数学が病的に出来ない私としては、この問題に対し哲学方面からのアプローチを試みたいと思う。
「クレタ人は嘘つきだ」と（クレタ人の）エピメニデスが云った。というもので、仮にこの命題が真だとすると、エピメニデスは嘘つきなので、『「クレタ人は嘘つき」』は嘘になるはずなのだが、本当のことを云っていることになり、矛盾が生じる。
逆に、この命題を偽とすれば『「クレタ人は嘘つき」』という発言は嘘になり、矛盾が生じる。
『「私は嘘つきだ」』という嘘をついたエピメニデスは正直者だ、ということになるのだ。
つまり、「３の倍数と３の付く数字だけアホになる」と発言するナベアツは、この説明時に「アホ」にならなければならないのではないか、ということである。
ゲーデルの不完全性定理によれば、『「事実（観測された事項）」が定理に合致する』ということをもって初めて「『証明』として完結することが出来る」ということから、ナベアツのアホについての説明はできないこととなる。
私が数学が嫌いな理由は、解が一つに収束することである。
「世界のナベアツ問題」について、どのような回答をするか。
京極夏彦なら「世の中にはアホなナベアツなどありませんよ。アホだと感じるなら感じる者が無知なだけです。」というだろう。
村上春樹なら、「完璧なアホのナベアツなどといったものは存在しない。完璧な絶望が存在しないようにね。」というかもしれないし、
サン・テグジュペリなら「大人は、みんなはじめはアホだった。」というだろう。
問いに対して、バラエティーに富んだ答えがある、哲学的な命題を愛して止まない。
そして、「2の倍数と2が付く数字のときに感じる滝川クリステル」企画の実現を切に願う。
2拍子で喘いで、20から29までラッシュ、みたいな。
日本語はややこしいと思う。
例えば数学の文章問題。
「こう問われたらこう解きなさい」というお約束事はわかる。
だが、それは暗黙の了解を多分に含むお約束事を前提にみんなが訓練されているからだと思う。
中学校の頃、
数学の教科書で、その問いかけ方が凄くおかしい気がしておもわず教科書会社に電話してしまった。
今思えばなんでそんなことしたんだかもわからんが、
ただ中２の俺には「任意の整数」とかの「任意」が許せなかったんだ。
なんで許せなかったのかも今となっては思い出せない。
多分条件がすべてかかれてないのに任意とか書いたら問題が解けないじゃないかとかそんな文句だと思う。
ちなみに学校の公衆電話から電話したんだが、さんざんまたされたあげく、
どちらの先生ですか？ときかれて、生徒ですといったら軽くあしらわれた気がする。
某所での書き込みの続編、回答編みたいなものです。
「隅に角度記号のようなものがあります。」
「小部屋も二等辺三角形でした。」
「再帰的で合同な二等辺三角形は数少ない。その隅は36度だね。
普通に考えれば、記号を中心に部屋が回転して並んでいる十角形の建物。
仕切りの壁で風車か星になるはず。」
「そのまま過ぎるかな。ほかに部屋の並びがあるとすれば、
乱杭歯と正五角形に対角線を引いた形。小部屋の壁を調べてみて。」
「五角形の隠し部屋がありました。そこにコーヒーが。」
「そのカップ十角形だね。飲んでみて。」
「カップの底にさっきと同じ記号があります。」
「隠し部屋には他に何かあった？」
「天井に絵が書いてありました。」
「ヒントを順に見つけていくと、最後は答えに至るみたいだ。
でも、それでは時間切れになるかもしれない。
→記号→十角形→五角形→十角形→記号→
一番目の鍵がそのまま問題の回答かな。…ボードの１は何？」
「そうか！1番は人、ヒトです。答えとして自然ですね。」
「待って。１、ONEは人であり神だけど、普通の人、という意味もある。
普通の人では王に成れない。
整数なら１ではなく０からはじまるか。０でオー、王の駄洒落かな。
記号を見せて。なんだ。これだけでわかるね。
結果が確定してない以上、参加者皆王であり王でない。
僕たちは、生きていてかつ死んでいる、箱の中の猫といったところかな。
「正解だ！さすがです。」
俺しがないWEB屋なんだけど、とあるWEBアプリケーションを頼まれで作ったときの話。
何でもやるIT土方なので、本当はデザインからシステムまで全部こっちで引き受けたいところなんだけど、発注側（代理店）が最初から勝手に「このイメージでいく」とクライアントに提出してて引っ込みつかなかったらしく、デザインに関しては別のWEB制作業者を入れ込んできた。
CMYKなのは許すとして、単位が全てmm。しかも整数になってないので手で適当に置いたのがバレバレ。
もしかしてpxに変換すると整数になるのかもしれないと期待してみたが、案の定、もっと酷い状況に。
大きさも配置も小数が混じるので、画面に書き起こしたときに同じ要素でも幅も高さも位置も2-3px程度ばらける破目に。
何べん言っても改善してくれない。
ピクセルとかアンチエイリアスとかすら理解してくれないので「じゃあ書き出すときアンチエイリアスを切ればいいじゃないですか」とか言われるし。れっきとした株式会社が自社のサイトの事業にWEBデザインもやりますとか書いてあるのに。
わかってもらえないようなので、言いがかりと捕らえられない様、丁寧に説明してるんだがそれでも聞く耳を持たない。
最終的には「あなたの言ってることがわからない。そんなに気になるんであればそちらで対応すれば」という一方的な態度に出られた。
仕方なく、もらった「素材」をもとに、全てこちらで作り直した。
それでも先方はしっかり「WEBデザイン」として予算の全額を持っていきやがった。
もちろん、代理店に説明しても理解されなかった。
最初にしっかり納品物の用件定義をしなかった俺を含めて、
WEB屋の底辺ってこんなもの。
相談乗ってもらってる立場なのに気づかず時間開いてすまん。
まあファイル内容いったんメモリ上の配列にしてもいいのかもしれないけど、どうせならIOごと減らすアプローチからと欲張っているのだ…やりすぎたかな。メモリ消費はあんまり気にしないけど、ともかく動作時間はストレスなんで減らしたい。まあバイナリサーチも考えたけど、アベレージがわかってればそっちの方が早いかな…と欲張っている状態。それと行数！＝IDなんでちょっとややこしい。
あと文字列オブジェクトのメンバ関数to_iは、整数化メンバらしいです。
＃実は /^( ID1 )\t( ID2 )\t( DATA )$/ なるもっと嫌なファイルが控えていたり…げんにょり
http://anond.hatelabo.jp/20071211012602
改訂：2:30
増田今夜は寝ます、おやすみー
あれ、小学校の時つるかめ算みたいな△□であらわすのなかった？
２×□ ＋ ３×△ ＝ ２６０
５×□ ＋ ２×△ ＝ ３８０
・・・。
あれ・・・？？
ちょっとマジ計算。
2x+3y=260
5x+2y=380
x=(260-3y)/2
5(130-3y)+2y=380
650-13y=380
13y=270
y=270/13
・・・俺の時代だったらこれが整数になったんだがな。
2x+3y=260/1.05=247.619...=248
5x+2y=380/1.05=361.904...=362
こういうことか?
5((248-3y)/2)+2y=362
5(248-3y) + 4y = 724
1240-15y+4y=724
11y=516
y=516/11
・・・。
わかった！！
ノート２冊、鉛筆３本で２６０円→鉛筆は一本10円 ノート115円
ノート５冊、鉛筆２本で３８０円→鉛筆は一本10円 ノート72円
俺もカウンタのオーバーフローだと思って電車の中で概算していた。パスモ導入開始から208日か。1日86400秒だから、17,971,200秒と言うことになる。10mS秒ごとの32bit符号付整数カウンタがオーバーフローするには、ちと短い。
ことから、
大阪方面で問題が起きていないことから、自動改札機には鉄道会社ごとの独自仕様がかなり深いところに盛り込まれているのかもしれない。それは単一問題で社会が停止する危険を回避できるともいえるし、くだらない独自仕様でコストアップをまだ続けているともいえる。
女教師ブログさんの「頭のいい人は、難しい概念も簡単に説明できるはずだ」問題という記事がはてブで話題になっていて、その大元はせつないエントリ群という増田の記事らしい。消されてて見れないが。
| 頭がいい | 頭が悪い | |
| 易しい説明が出来る | １ | ３ |
| 易しい説明をしない | ２ | ４ |
割り算の「100÷30」を教える場合とする。
１は割り算を知らない人にも分かりやすいが、答えは出せないし、教えた相手を割り算が出来るところまで引き上げる物ではない。
２は割り算の計算方法や算数的意味も過不足無く説明しており、また掛け算と足し算が出来る人ならばこれにより割り算も出来るようになるであろうが、掛け算も足し算も理解していない人には何の事やら解らない。
３と４は説明不要。
上記の例で言う１をやってくれる人。さらに言えばそれを教えているときに相手をバカにした態度をしない人。また２の様な基礎部分は一切触れずに、割り算が社会のどのような場面で役立っているかという物語を語れる人。
「簡単に説明して欲しい人」は割り算を出来るようになりたいと思ってるわけではない。あくまで概要を知りたいだけなので、そもそも２の様な説明は必要ないし、やったところで足し算・引き算・掛け算を理解してない場合も多いので意味が分からない。
ただしこれが出来る人だけを「頭のいい人」と定義して良いかどうかは難しいところだろう。概要を説明する能力、割り算を出来る能力、人をバカにしない人格、物語を語れる能力は明らかに全て別の物だ。この様な言葉を発する状況はほとんどの場合は合理化だと思われる。また一部、物語を語ることが専門（企画や営業など）の人が物語を語れない相手を見下している場合も見受けられる。
割り算を習得する前程として足し算・引き算・掛け算が必要なのは自明だが、相手は必ずしも自分が割り算を出来るようになりたいと求めているわけではない。
割り算の概要を知りたいという人にはその概要の解説を、答えを知りたいという人には答えだけを、自分も習得したいという人には足し算からの学習方法を教えるべきだろう。
世の中には様々な知識や学問があるが、どの知識も学問も世の中全ての人に必要なわけではない。必要と便利は違うもので、皆自分の人生や職業に必要な物は専門知識として蓄えていく。便利な物は意欲がある人は覚えればよいし、それにより人生の深みが増したり職業選択の幅が広がったりすることは多々あるだろうが、意欲が無い人に押しつけるべき物ではない。
なお、概要だけを知ることは無意味だという議論は間違いだ。ほとんどの人はよく分からないブラックボックスの上に現在の専門知識を成り立たせている様に、概要からさらに別の何かに役立てられることも多い。これは証明の仕方が解らない定理でも利用できることに似ている。定理を使って別のことをやりたい人に、本人が望んでいないのに定理の証明方法を教える必要はないだろう。（プログラマなら、定理＝関数やクラス、証明方法＝実装と読み替えると感覚的に解りやすいかも）
あなたがどのぐらいの内容の回答を欲しがっているのかは「・・・ってどういう事ですか？」という様な単純な質問からではなかなか解らない。自分がその問題の概要だけを知りたいのか、前程となる部分からの仕組みを知りたいのか、習得したいのかなどはきちんと相手に伝えなければならない。
そして概要を説明するのも、専門家なら誰でも簡単に、という物ではない。面接の質問などがこれに近く、例えば「あなたの在学中の活動やそこで得た物を簡潔に教えてください」という質問に、自分の人生の専門家であるあなたであっても、事前に何の準備もせずあなたを全く知らない人が感心し納得してくれるような話をするのは難しいのと同じだ。
今の時代は様々な、苦心してまとめた結果が保存されている便利なサイトがあるのだから、可能であればそのようなサイトを見る方が手っ取り早い上に、内容的にもそちらの方が得策であることも多い。
また世の中には概要を説明しづらいものも多く、さらに「・・・はどう凄いのか」という様な感覚実感も含めた問は、前程知識など無しに説明するにはせいぜい例え話が限界である場合がほとんどだ。これは小説の面白さをネタバレ無しに他人に語るのが難しいのと同じだ。（そしてこの例え自体がそうだ）
なお、知的好奇心を満たすだけであればそれほど完成度が高くない概要でも事足りるが、その概要を別の物事（例えばプレゼンや記事など）に利用する場合は完成度の高い「商品としての概要」が必要になる。しかしそのような物を作るのは先の面接の質問の例でもあるようになかなか難しい。専門家と言っても商品としての概要を作ることが専門ではないため、この様な場合は、あなた自身が前程知識の概要を理解し最終的に必要な商品としての概要を自分で組み立てるべきだろう。
色々な人の意見を参考にすれば私が気付いていなかった箇所なども考えることが出来ると思いますので、はてブなどに回答してみます。出来る限りひねくれずに答えたいと思います。「書いていただけませんか？」というフレーズを使いますが、特にこれに関しては嫌みの意味を一切込めないで書くつもりです。
また念のため、追記より上の部分は文章の間違いの修正以上の修正はしないことを誓います。単語間違いレベル以上をもし修正する場合はdelタグを使います。信用できない人は魚拓なりローカルなりに取っておいてください。
なお、以下に一つだけ私が定義した言葉を使いますので説明しておきます。（ネット上ではそれなりに使われていますが正式な言葉ではありませんので）
※ 「オレ定義」とは… 辞書的意味ではなく、「この言葉はオレの中ではこういう意味だ」という意味・定義。人それぞれなので議論するだけ時間の無駄。
追記を書いていたら案外多いのでまとめます。
「頭がいい」をどう定義するかはここでは問題にしません。
理由は追記４に詳しく書きましたが、「本当に頭がいい」という言葉は人によって定義が違いすぎるからです。なお「よく言われる・・・」という項目は、Googleで「頭がいい」「本当に頭がいい」など、適当に思いつく言葉で検索した先を20-30件ほど読んだ結果と、とつげき東風氏の本当の頭の良さという記事から私なりにまとめたものです。もちろん「定義」ではありません。
ここで一番問題としたい核の部分は、どのようにすれば良い質問と回答が出来るかです。伝わってなければ私の文章力の欠如が問題でしょう。大変申し訳ないと思います。
これらの理由により「本当に頭のいい人は…」で始まるような記事はコメントは結構ですのでご理解ください。
以下、既に書いた部分に関しては残しますが、以降「頭がいい人」のオレ定義に関するような部分は追記しません。
2007年10月07日 penkun はてな, ブログ 頭がいい悪いは別として、正しいことを適切に簡単に教えてほしいと願うのが教わる側です。
それはそうでしょう。私も現在受験しようとしているとある資格が一発で取れるぐらいの試験の要点などを簡潔でしかも眠くならないよう教えてくれる講師がいれば、月額20万ぐらいなら本当に支払ってもいいから受講したいと思います。しかし世の中にはそんな便利な物はありませんから受験勉強しています。
また、あなたが適切と思うラインは質問文に盛り込まれていますか？ あなたの現在の知識は伝えてありますか？ ジャンルは解りませんが、例えば学問的内容であれば、高校レベルはもう解らないとか、中学レベルなら解るとか、そう言うことは書いていますか？
質問とその答えというのは、会話や応答文である以上お互いの共同作業によって成り立つものです。片方の発言に足りてない部分があれば質問意図は相手に伝わりきらず、あなたが適切と感じる回答は得られないでしょう。責任は説明する側と質問する側、両方にあります。
2chの自作板にはエスパースレといわれるスレッドがあります。不十分な質問からその人の質問意図を出来る限り読み取り、出来る限りそれに答えてあげようというスレッドです。もちろん質問意図を読み違えることも多々あります。あなたの質問はエスパーに頼らないといけないような質問になっていませんか？ エスパーに頼らずに済む質問にしたければ事前調査が必要ですが、質問の前に調査していますか？ 2chであればテンプレは読んでいますか？
249 Socket774 ：2006/04/08(土) 22:08:10 ID:B56/Hai2
わからない五大理由
読まない
調べない
試さない
理解力が足りない
人を利用することしか頭にない
乱暴ではありますが真実だと思います。少なくとも他人の疑問に山ほど答えて疲れ果てた人の心の叫びだと、私は感じます。
2007年10月07日 zonia コミュニケーション, 教育, イメージの齟齬 あー、100÷30のアナロジーは不適切だなあ。「頭がいい＝割り算を理解している」というのは飛躍しすぎだ。頭がいいって何だ？ 割り算を「理解」しているって何だ？ 「理解」してないと説明できないのか？
仰るとおりで、適切な例を誰もが解る例で出せなかったのは私の解説力の無さです。未だに思いつきません。本当に嫌みではなく、もし可能であれば適切な例で解説記事をお願いできればと思います。
なお、「頭のいい」や「理解している」は所詮オレ定義になってしまうので、こちらに関しては結構です。
2007年10月07日 hebomegane はてな 僕が腑に落ちる説明の仕方してくれる人がやっぱスゲーなと思います。
同じく凄いと感心します。私もそのような理由で尊敬している人もいます。しかしそれは次の状況を満たしていたんだろうと思います。
私はとあるローカル局の番組でコメンテーターをしている方の解説能力を尊敬していて、その人で帯番組を持って欲しいと常々思っているのですが、私が既に勉強している分野の事に関しての解説は不満を感じることが多いです。その人は説明の前程として中学程度の知識などを前程にしているから、既に知っている人間には冗長な部分が多く突っ込みが足りないんだと、自分がある程度詳しい分野の事を解説しているときに見えてきますね。
2007年10月07日 SiroKuro 教育 それは「頭のいい人」じゃなくて「良いプレゼンター」。ところで、その簡単な説明だけであなたは難しい概念を理解できるのですか？
仰るとおり、「良いプレゼンター」だと私も感じます。ただし「頭のいい人」という言葉の意味は所詮誰しもオレ定義ですので、別に気にしていません。今回はググってある程度色々な人のオレ定義の「頭のいい人」を読みつつ、とつげき東風氏の本当の頭の良さという記事も参考にしました。なお追記２及びこれらの理由より、「頭のいい人」論は結構です。もし適切な質問方法と適切な回答方法に関する記事を書いていただけるのなら是非お願いしたいと思います。
後半、「その簡単な説明だけで・・・」ですが、結論だけ言えば誰かの概念の説明だけでは理解できません。それを取っ掛かりにして調べたり書物を読んだり、数式が出てくることなら解いて、プログラムなら車輪の再発明をして、そこまでやって初めて、当該項目が仕事に利用できるぐらい本当に理解できると思っています。この様な手間が掛かったとしても、指針があるだけ自分で一から勉強するよりも早く勉強できるので回答していただけることはかなり有用だと思っています。
2007年10月07日 ululun はてブ米に入りきらないのでエントリを起こす
お待ちしております。
2007年10月07日 REV あたまのいい、が未定義
はい、意図的に未定義です。理由は前述の通り、どうやってもオレ定義になるだろうと考えられるからで、文中の「よく言われる・・・」はググった結果と前述のページから私なりにまとめたものです。
またこれも重複してしまいますが、オレ定義の乱発になりますので「頭のいい」に関する定義問題は結構です。
2007年10月07日 mmasuda mmasuda 「説明させる」と「理解させる」の間には困難な道のりがあることを忘れている人ほど「簡単に説明しろ」と言いがちのような気がする。
同感です。実感まで含めて理解するには、浅くでいいので前程知識の部分などを一通り、実際になぞってみる必要があると感じています。
少し見ない間にブックマークがかなり増えていて驚いています。
2007年10月08日 monnet 教育, 考え方 「難しい概念も簡単に説明できる頭のいい人」とは物語を語れる人。なるほど。でも具体例は１つの解釈とは思うが、もとの算数の例では、易しい説明で、概要理解→計算習得まで教えるプロセスが含まれているのでは？
元の算数の例というのがなにを指しているのか不明瞭なのですが、「切ないエントリ群」の事であれば、元が読めないので私には解りません。
私の割り算の例を指しているのであれば、もし足し算すら知らない人に割り算まで理解させるとなると、教育方法としてはある程度のラインであると考えられる義務教育ですら、割り算を教える所まで到達するのに270時間程掛けています（参考：会津若松市立一箕小学校）。「易しい説明」という言葉の語感にこれだけの時間が詰まっているとは私には考えられないのですが…
本題とは関係ないのですが、私も書く前に少し考えたことなので。
2007年10月08日 tokoroten999 「「本当に頭のいい人は・・・」で始まるような記事はコメントは結構です」こういう他者との意見交換をしたいならブログや日記でやればいいのに。なぜ増田？
自分のブログや日記を持つ気がないからです。ちまたに溢れるブログサービスに捨て垢で、ということは考えましたが、はてなのアカウントを持っていれば増田が使えるからいいか、とこちらにしました。多少意見交換が面倒ではありますが、運用で何とかなる範囲だと思っています。
2007年10月08日 kokokubeta ヒント この種の問題でいつも悩むのは、「相手がどこまで理解していて理解してないのか」を把握するのが難しいのと、「どこまで理解したいのか（知るだけか、理解したいのか、できるようになりたいのか）」だなあ。
同感ですね。文中にも書きましたが、教える側はこれを感じ取る・聞き出すことが胆だと思います。
2007年10月08日 petem 増田, 教育, *思考法 私は説明する前に「すごくわかりやすく説明するけど7割くらいしか正確じゃないから」といって例外部分をはしょります。深く理解したい人はその後も質問してくるのでそのとき対応。
私も教育においてまず例外部分を削るのは良いことだと思います。例外は見方によって何段階にも分けられますが、小学校３年生で割り算を習う際に分数や小数はまだ教えないのも、整数以外を例外と見なして単純化だろうと私は考えています。
ただ概要の説明だけの場合は例外を省略するのは当然として、枝葉は省略しつつも幹だけでなく全体の形や他の物との関係性の説明も必要であったりと、省略の仕方がなかなか難しいところです。
2007年10月08日 cappin 剰余「30円商品は100円なら3つで10円余り」きっちり「100Lの水を30人は一人3.3L」余らす^o^「100万を30人で割勘なら一人3.4万で余り2万」一般に、使う場面での役に立ち方を言うと納得されやすいと思っている。
そのような説明も良いですね。私が使用した説明は、元々小数や分数での割り算の意味が分からないという話の際の説明から来ているので、今回の例としては不適切ではないかとも思いますが、記事を書いていた際には他に思いつきませんでしたのでこれを使用しました。
2007年10月08日 terracao 言及された 「解説」書いてもらったのに難癖をつけるのは申し訳ないんだが、増田主にとって「割り算」は難しい概念なのかな。私は現代思想とか社会理論とかを想定していたんだけど。／増田にあるまじき丁寧なレスに感動！！！
ご本人様からお返事を戴き有り難うございます。
割り算が難しい概念かどうかという事ですが、「難しい」というのは相対的な感覚なので例として使えないことは無いと考えました。義務教育を受けていることが当然の現代の日本人からすれば全く難しくない問題でしょうが、中世の「読み書きそろばん」を習わずに一生を過ごした人からすればある程度難しい問題だと思います。難しさの実感も含めてとなれば、例えば高校レベルの問題を例にすれば難しく感じる人も増えてくるかと考えましたが、そうすると「難しい概念を簡単に説明するとは何か」という私が本質としたい部分から議論が離れていきそうだと思い、こちらにしておきました。
3の倍数判定法の証明。その他略
簡単のため、3桁の整数について考える。
100 の位の数を a 、10 の位の数を b 、1 の位の数を c とすると、3桁の整数は 100a + 10b + c と表わせる。
100a + 10b + c = 99a + a + 9b + b + c = 3 (33a + 3b) + (a + b + c)
3 (33a + 3b) は 3 の倍数なので、a + b + c が 3 の倍数ならば、3 桁の整数 100a + 10b + c は 3 の倍数である。
よって、各位の和が 3 で割り切れたら、その数は 3 の倍数である。
http://anond.hatelabo.jp/20070802144801
昔は5,6人でひとつのCPUを作ってたんだが今は一人でひとつのCPUを作ってるみたいだ。その分内容は簡単になってるみたいだけど、マルチプレクサや符号拡張の回路図まで示しちゃうのは甘やかしすぎのような気がする。
コンパイラは昔から一人でひとつ作ってるけど、基本は整数のみのサポートだからその東大の実験よりは楽そうだな。東大での「ゼロから」っていうのがどれほどのものを指すかは知らないけど、こっちだと字句解析・構文解析はlex・yacc任せだし。
それにこういうのは最終奥義「先輩からの遺産」があるんで、実はわかってないけど「要領よく」やっちゃう人もそれなりにいるかも。
gan2 の Ruby 勉強日記 - 配列の中身をランダムに並び替える
ary = (1..100).to_a
ary2 = ary.sort_by{|i| rand }
p ary2
なんだこれ難しいな…。
100までの整数がなんらかの状態でレコードにあって後はSQLひとつ流せばおわりなんだけど
select if (tf.fizzbuzz = '',tf.num,tf.fizzbuzz) fizzbuzz from ( select num, concat( if (mod(num,3)=0,'fizz',''), if (mod(num,5)=0,'buzz','') ) fizzbuzz from tmp_fizzbuzz ) tf ;
うえのSQLをphpMyAdminで流しても反応がない。。。。
いまいちどころか、なかなかピンとこないなぁ。
慣れてきたつもりだったんだけど。。
＿ノ乙(、ン、)＿
昔、妖精現実のトップにあった記事。探しても見つからないや。
「水からの伝言」…水は否定的な言葉を見せたときと肯定的な言葉を見せたときで異なる結晶を作る。
（念のために言うが、↑は科学的事実ではない。しかしネタとして、あえて） これが成り立つ世界を考える。ただし、次の公準も仮定する。
考古学的応用: 水は世界中の言語を理解できるので、 未解読文字の解読に役立つ。 少なくとも、お礼を言っているのか、宣戦布告の文章か、といった程度の判別はつく。 「正しい解読結果をアルファベットで表記したとき1文字目は大文字小文字を区別せずにAである」「…Bである」…と書いてある30枚弱の紙を水に見せて、どれが肯定的かを判断することを、結果の文字列長（この整数値も水に問い合わせることができる）だけ繰り返せば、あらゆる謎の古文書が解読できる。 水さん、ありがとう。
問1: 解読結果が1万文字以内であることは分かっている文がある。 解読結果の文字列長を表す整数値を必ず確定させるのに必要な最小の「水への問い合わせ回数」はいくつか。
問2: 現在は不治の病であるXについて、それを根治する薬品があると仮定する。 その有効成分をIUPAC等の標準的な化合物命名法で記述して1万文字以内であると仮定せよ。 以上によって、水が肯定否定を判断できるなら、難病のいくつかが克服できることを説明せよ。
問3: 水に問い合わせられるときP=NP問題は肯定的に解決されるか。
軍事的応用1: ゆえにRSA暗号、楕円曲線暗号、その他、いかなる未知の暗号であっても、ダイレクトに高速にクラックできる。 上記同様、解読結果のどれが肯定的か1文字ずつ判断させるだけで良い。量子通信・量子暗号さえ解読できてしまうだろう。
軍事的応用2: さらに、暗号に限らず、情報一般に応用できるから、チャフによる妨害や、敵の欺まん電波を見破るように水を結晶させる装置を弾頭に装着することで、電子妨害を受けない強力な兵器を構築できる。
こういうの、大好きだ。
