  |
はてなキーワード: 演算とは
ごめん。よく分からないんだけど、πはπでしょ。
ガチな数値演算の時は、もう、πはπという値を呼び出すから、自分でそんな桁打ち込まないよね？
関数電卓ならπぐらいあるでしょ？Excelにだってπ関数はある。
何桁も使うときはそれこそ、最初の１度で定数表を作るときぐらいだけど、その時はググればいいじゃん？
3.14以上を暗記しなければ行けない必要なんてどこにもないんだから、通常は暗記しなくて十分。
公式にしろ、何にしろ、外部記憶装置としてグーグルが使える物は暗記しておく必要はないと思う。
それよりも、πを使った公式、数式などを薄く広く覚えておいて、必要に応じて、ググる単語をしっていて、呼び出せる方が大事だよ。
暗記というのは、インターネットが無い頃の文化。
これからは、ググるための基礎知識を浅く広く身につける時代だと思う。
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) |
ノンリニア編集（ノンリニアへんしゅう、Non-linear editing）はコンピュータを使用した非直線的（ノンリニア）な映像編集方式のこと。2台以上のデッキを使いテープからテープへ映像をコピーするリニア編集に比べ、編集箇所を自由に選択でき、映像データを即座に追加・削除・修正・並べ替えることができる利点がある。1990年代に登場し、PCと共に急速に普及した。
編集システムとしてはAvid、Adobe Premiere、Corel Ulead VideoStudio、Final Cut Pro、flame、Kino、Canopus CWSシリーズ、Canopus HDWSシリーズなどが代表的である。
PS3のCPUであるCell B.E.は浮動小数点演算処理能力が飛び抜けており、動画エンコード/デコード能力は現在市販されているハイエンドCPUよりも十分に高い。
仮に年月が経過して一般的なPCの性能が向上し、相対的にPS3の処理能力が陳腐化したとしてもコストパフォーマンスの面で断然有利。PS3本体とソフトの価格の合計5万円弱で、同等の環境をPCで揃えるのは至難。時間が経てば本体価格も下がっていくだろうし。
全てのパッケージにHDDが標準搭載で、今月からは80GBが標準になり、しかもその気になればさらに大容量の市販のHDDに換装可能。よって素材となるファイルのストレージとしては容量面も拡張性も十分。また「PLAYSTATION Eye」といったUSBカメラで直接の素材取り込み手段もある。
一般的なMPEG1、2のみならずh.264やDivXも再生に対応しているので、出力形式の対応も敷居は低いのでは。
PS3用ソフト「まいにちいっしょ」には、ゲーム内を録画してYouTubeにアップロードする機能があり、他のメーカーに提供されている開発環境にもこの機能は含まれていると聞く。よって制作した動画や音声をシームレスにYouTubeにアップロードする事も可能なのでは。
制作した動画をフレンドに送ったり、制作者のhomeでフレンドを呼んで上映するといった機能も実現可能なはず。もしくは、ソフトそのものにストリーミングサーバの機能を付加するというのもアリかも。
当然ながら可能だろう。
大容量ストレージと高性能CPUが必須のソフトなのでWiiにはまず不可能だろう。可能性があるとすればXbox360だが、(3)は専用HDDしか選択肢がなく価格も高価。(5)は今のところ実績は無く、PS3に十分なアドバンテージが見込める。
YouTubeやニコニコ動画など、ユーザが作成する動画コンテンツ(CGMとか言うんだっけ)の隆盛は今後も続くと思われるので、その分野で一定の地位を確立するのも将来的にも有益ではないかと思うが、いかがだろうか。
とりあえずまとめてみましたが、回答はまだ募集中です。
アンケートの設問はこちらhttp://anond.hatelabo.jp/20080909170753
「生活する上では役に立たないけど、人生には生活だけじゃなくて楽しみも必要だよ。フィクションはそこで役に立つよ」
http://anond.hatelabo.jp/20080909181215
http://anond.hatelabo.jp/20080909181946
http://anond.hatelabo.jp/20080909172255
「フィクションは新しいものの見方をもたらしてくれることがあるよ。だから生活の上でも役に立つと言えるよ」
http://anond.hatelabo.jp/20080909173319
「役に立つものと役に立たないものがあるよ。それは享受してみないとわからないよ」
http://anond.hatelabo.jp/20080909172553
「そもそもお金や言語だってフィクションだよ。社会はフィクションを利用することで成り立ってるよ」
http://anond.hatelabo.jp/20080910000004
「嘘だから無意味ということにはならないよ。後に続く質問についても同様だよ」
http://anond.hatelabo.jp/20080909172135
「数あるフィクションをひとくくりに論じられるはずがないよ」
http://anond.hatelabo.jp/20080909172553
「嘘ってそもそも何だ。曖昧すぎて答えられないよ」
http://anond.hatelabo.jp/20080909191226
現時点までに8人の方に回答していただきました。ありがとうございます。
回答結果から考えるに、Q1に対しては「生活には役に立たないけど楽しみにはなるし、何か見つけられたらもうけものだから」もしくは「質問の意味がわからない」と答えるのがよさそうです。
それと本題とは関係ありませんが、こうやって複数の人間がひとつの質問に対して枝分かれするように回答を続けていくというのは人力演算機みたいでいいなと思いました。
2008/0910 18:32修正
問い：xを実数としpを有理数としたとき、x+pが無理数であるならば、xが無理数であることを示せ。
簡単に解くには、xを有理数として、x+pが有理数であることを示せばいいだけ。有理数は四則演算に閉じているから問題なし。
ならばこれをほかの方法でとくことができるのか？考えてみてください。一応自分で考えたのは下のほうに流れだけを書いておきます。
自分の回答(欠陥あり)
xを二次無理数を仮定し、xを循環連分数の形に直す。その場合においてx+pはある一定のところからまた循環連分数となり、循環連分数が無理数であることを証明すればよい。この場合だと二次無理数にしか適応できないのが問題。だとえばpiとかこの方法だと示すことができない。
なぜならpiは循環連分数でないからだ。この場合はどうすればいいのだろうか。xが超越数であることを仮定して解かなければならないのか。解き方がわからん。
プログラムを学ぶ上での一番根源的なものとしてアセンブリ言語が扱われることってわりと多いように思う。
便利なプログラムもコンピューター内ではこう処理されてます、とか。
だけど、その説明ってあんまり意味が無いよなとか思ったり。
add D1 D2 D3(アセンブリの命令でD1とD2の値を足してD3へ代入を意味)なんてもはや単なるプログラミング言語に過ぎない訳で、それＣでも出来るよ、としか思わない。
はいはいアセンブリ不便ですね、ってなって結局主軸は別の言語に移す。
プログラミングの楽しさや便利さはその別の言語を通じて学ぶことになるのだし、じゃあアセンブリ言語を学ぶ意義ってなによ。
c=a+bって書けばコンピューターが計算してくれますっていうのと、add D1 D2 D3ってやればCPUが計算してくれますっていうのは感覚としては同じ。
本当に根源的なものまで突き詰めるのなら電気信号をどう解釈してどういう仕組みで演算して数を格納してっていうことをやってほしい。
アセンブリを根源扱いして崇めることにはなにか抵抗を感じる。
違う。工学自体が本質はチート。数学における抽象化もチートそのもの。
いや、揚げ足をとってるんじゃない。こういうことが理解されてないから、技術や学問を必要以上に難しいものと考えて、苦手意識におびえたり、逆恨みして衒学趣味だとかなんとか筋違いの批判を浴びせる人が後を絶たないんだよな。
工学ってのは、面倒なことや大変なことを機械的にできるようにしようという営みだし、数学を抽象化するのはまさに「暗記を最小限にしよう」ということなのだ。それを念頭に置いておけば、勉強するときにもツボが見つけやすくなるし、逆に「難しいものをがんばって覚えよう」というような努力ほど本質から遠ざかることというのはない。
余談ながら、このあたりの勘違いが一番ひどいのは工学の中でもITの分野で、ITってのはそもそも「サボる技術」なのに、IT技術者ほど「合理化してサボろう」という精神が身に付いてない人たちって珍しいんじゃないか。そういう人種が「エンジニア」を名乗ってるのを見ると、本当に殴り倒したくなるね。
連立方程式が行列で一般化されて「ハイ簡単に解けますね？」って
いわれても「計算量ぜんぜん減ってないじゃん」っていまいち納得できなかったけど
複素数はマジすげえと思った。
「連立方程式が簡単になる」という説明は非常に悪い説明だと思う。本当は、線型代数（行列とかベクトルとか）のありがたみは「次元を増やす」「座標変換を簡単にする」ことにある。
実はラプラス変換というのもある種の座標変換なのであって、「微分」という演算が簡単に計算できるように座標軸をあわせてやっているのだよ。
そりゃ「影響」はしてるだろうがな。別にキリスト教の神である必然性などない。／いや、親鸞の書いたものは当然古語で書かれてるでしょ？
いや、自明とか間違いなくとか言われてもなあ。具体的に挙げてくれる？ 君の議論の最大の弱点って多分具体性がないことだから。
グレコ・ローマン文化の話じゃなかったのかよ。近代以降ならそりゃ当然だろ。
いや君がニュートンを引き合いに出したんでしょうに。民主主義に関してはギリシャにまで遡って意義深い書籍を見つけることは出来るだろうなあ。
ほら、君は「??だとすれば」という仮定が読めないんだよね。
で、いつまで撤回した仮定を引きずるわけ？ｗ
何かひとつ共通言語がないとＩＴなんてやってられん、というのは厳然たる事実だろ。
一方で、文化資本による格差なんぞないほうがいいに決まってる。
東大卒は毎年数千人だ。それで、MIT卒は何人いるか知ってる？ハーバードは？プリンストンは？スタンフォードは？オックスフォードは？ケンブリッジは？
数千人か。なおさらたいしたことないな。で、MIT卒全員をエリートと呼んだ覚えはないが？（他の大学もね）。
まあそうね。勝手にどこかで学んできそうな気はする。
教育ってのは、特に公教育ってのは、底上げのためにやるもんであって。
誰も「普通の東大生数百人のレベルをギリギリにチューンする」なんて言ってないし、そもそも東大生の中で「教育制度がもっとよければ俺はもっと偉くなれた！」なんて言ってる奴は落ちこぼれだけだよ。だから「普通の東大生数百人のレベルをギリギリにチューンする」という発想自体がそもそも無意味。
いや、お前そういう話しかしてなかったじゃんｗ 俺が公教育は平均と底辺を上げるためのものだと主張したらやたら激しく反発してたよなあ？
主流と標準を辞書で引くことをお勧めする。そりゃ、主流が標準を塗り替えてしまうことは結構あるが、少なくとも数値計算の世界ではまだだろう。過去の蓄積ってのがあるんだ。
Cを使ってアセンブラまがいのコードを書き、新しい言語なんて覚える暇があったらもっと他のことをするとかなんとか言ってる人だって一定の比率で存在する。おわかり？
それは、特にアセンブラが必要でもないケースでか？ ちょっと勘弁して欲しいなｗ まあ仕事としてうまくやれてるならそれでもいいけどさ、特殊ケースだろ？
まだ、例えば専用プロセッサなり組み込みデバイスなりを制御するためにアセンブラ使うってほうがはるかに一般的なケースだと思うがな。数値計算やパターン認識においてさえ。
どうも話が巧妙にずらされてる気がするんだが。
いや、君自身RubyとかPerlとかC++とかJavaとかに言及しちゃったからねえ。どっちが引っ掛けたかというのは不毛になりそうだからやめようや。なんなら俺がズルかったということにしてもいいが。
たとえばいきなりJavaを覚えさせられた人間がそれがわかるとは到底思えない。ライブラリのソースを読めるレベルになってはじめてわかることだろう、それは。
いや、Javaのライブラリのソースを読むレベルになったらたしかにかなり専門的だが、そもそもJavaで書いたコードで高速計算させようというほうが間違いなわけで。
C++に関して言うなら、アセンブラ的な最適化に手を出すのはだいたい最後の最後だろう。俺（や多分君）のような古い世代はアセンブラからの積み上げで高級言語を見るけど、高級言語の側から必要なレベルまで掘り下げていく、という見方も可能なはずだし、最適化の上ではむしろそちらが本筋。
で、君が重いクラスライブラリとして想定してるのはなんなの？ ちゃんと最近のものを使ってれば、そんじょそこらの奴がCでちゃっちゃと書くコードと同じかたいていは速いコードを生成するし、もちろん可読性も高くなるな。
C++の話も同様。敢えて「C++らしい」処理を書けば計算量はどんどん増えて、例えば行列をカプセル化して演算子をオーバーロードしてなんてことやってたら計算時間が倍ぐらいになってもおかしくはないだろう。一晩で終わる計算が翌日の昼までかかるということになったら作業効率には歴然たる差が出るぞ。
具体的にどこの出してるC++用行列演算ライブラリがそこまで効率悪いって？
（補足追記）
最近のC++用の数値演算ライブラリはかなり出来がよく、FORTRAN用のそれに性能で肉薄するところまで来ている。そう、ここでは、ライバルは君が主流からも標準からも蹴落とされたと主張したいらしきFORTRANなんだよ。
で、どの辺がネックかというと、君の言うように記述性と実行速度の関係だったりはする。でも、それは低水準処理がどうこうという問題ではないよな。
この件については、議論してる人がネットでも結構いるから読んでみるといい。君が思うほどにC,C++が圧勝しているわけではないよ。随分C++が向上してはいるけど。で、FORTRANのほうが言語の構造上最適化が効き易い等の話題はあっても、手作業で機械語レベルの最適化をするなんてのは、候補にさえ挙がらないな。
数理論理学、というかさ、AND, OR, NOT, THEN とかの論理演算を高校で教えてないことはありえない機会損失を招いてる気がする。
それぐらいは高校で教えてますけど。というか THEN なんて論理演算はないと思うが。ちなみに勘違いしてるかも知れないが論理学でいうA⇒Bとプログラミングの世界でいうif A then Bは別物だぞ？
ときどきこういう勘違いをする奴がいるから指摘しておくが、別に西欧語が論理的な表現力に優れているわけでもなければその他の言語が劣っているわけでもない。実際、西欧語で書かれたあらゆる数理論理学や数学の本を日本語に訳すことができる。
なんだ、君、プログラマーだったのか。だったら話が早い。
例えば、JavaとかRubyとかVBとかPHPとか、そういう種類の言語一種類しか使えないプログラマがいたらどう思う？あまり難しい仕事任せられないって思わない？最低限、Cとかアセンブラとかできるだけ低レベルに近い言語はある程度使えてほしいし、できればLispみたいな関数型言語とかOSやコンパイラの理論とか、そういうのを知識としてだけでもいいから知っておいてほしいと思うよね？
だったらどうして、古文や漢文の勉強が自分には意味ないって思うかなあ？日本語で文章を書くのは、仕事上の重要なスキルでしょ。まずその前提がよくわからない。
別に「新たに」なんて言ってないけど。ただし、資源ってのはメンテナンス要員が必要なんよね。現在の教育は、その中から一握りの専門家とそこそこ多くのファンを再生産する役目は果たしてると思うけどな。
あと、日本の観光ビジネスはまだ産業として未熟だよ。ヨーロッパ行ってみるとわかるけど、日本の観光ビジネスは横のつながりが弱くて商売がヘタクソ。たとえば厳島神社なんて世界遺産になってるのに、宝物殿では大した物展示されてないし、宮島にある飲食店はろくなお店がない。
劣るとも思わないけどね。ただね、現代文学は古典文学を下敷きにしてたりするから両方読めると楽しいことは知っておいた方がいいだろうね。
あと、古文とか漢文ってのは現代文と読み書きや文法の体系が少しだけだけど違うから、文法ぐらい教えておかないと、興味を持った人があとで独学たって難しくなってしまうことは理解できるよね。いまの高校の教育はそういう目的で文法だけを中心に教えてるようなもんだよ。
それとさー、どうしてあれを教えたらこれを教えるのやめろって話になるわけ？両方教えたらいいだけじゃないの。ただでさえゆとり教育なんだからさ。たとえば俺は高校時代理科と社会を全科目履修したし、数学も数III数Cまでやったし、古文や漢文だったら例えば岩波文庫の注釈付きなんかで訳なしで読めるよ。
俺も理系人間で、たいして出来がよくなかったから思うんだが、行列は大学入試という重しがある高校生の間にある程度慣れておくべきものだ。
大学で習った偏微分とか周回積分とかいっこも覚えてない俺でも行列演算は一通り出来るし、プログラミングとかで使えるのは、高校でみっちりやったからだよ。
それは単なる君の不勉強でしょ。高校までで役に立つこと勉強したいんだったら高専とか工業高校に行くべきなんだし。普通高校ってのはジェネラリストを育成するところなんだからね。
それに、君はたまたま高校で習った行列計算だけで用が足りてるのかもしれないけど、行列の計算だけできても普通は何の役にも立たない。それに、大学の線型代数やったんなら、高校でやるレベルの話なんて子供だましもいいところだってわかるでしょ。
というか、固有値やベクトル空間を理解せずにどうやって大学を卒業できたんだ？力学も振動論も微分方程式も統計学も信号処理も量子力学も、何一つ理解できないでしょ、それじゃ。
行列と比べてどうなんだと聞いてるんだが。
だから、本来比べるのがおかしいし比べられないと書いたんだが。
ただし、君が思ってるほど高校の行列計算は一般には役に立たないし、観光は大きな産業になり得る。理由は上に書いたとおり。
そりゃ基礎技術力が高く工業力が強いほうが観光立国よりずっといいだろ。
君一人の数学力が問題なのではなく、日本人の平均的学力の話だからねえ。高校数学の範囲で言えば難度は高いほうで、だから外されたんじゃなかったっけか。でも、難しいから外す、じゃダメだったんじゃないかと俺は思うんだ。
正直、文学作品は読んでる暇が無いんだよね…。読まなきゃいかんなーと常々思ってはいるんだけど。
数学とか英語とか技術とか経済とか金融とかを勉強するだけで手一杯の現状。
行列演算なんて(ジョルダン標準形とかまで行かなければ)息をするのと同程度だし(高校ではやんなかったけど)、最適化とか微分方程式とか統計的予測とかプログラミングとかアルゴリズムとか、そういったものをどんどん勉強していかなければならない。仕事で必要だからね。経済や金融は自分の資産形成のために勉強しなければならない。
どうしても文学作品読む暇があったら科学の専門書読むって話になっちゃうんだよね。そのほかでも、経済や金融や歴史や実用書になってしまいがち。どうしたらいいんだろう？速読を身につけるしかない？でも俺記憶力が致命的に悪いからしんどいんだよね…。
※横増田です
具体的にどんな古典教育強化でどこが「新たに」観光資源になるんだ？
日本は今でも十分歴史的伝統的なものを観光ビジネスに利用出来てるが。
文学をたしなむことが、人生を豊かにするという仮説を受け入れるとしても、まず現代語で書かれた文学をちゃんと読ませたほうがいいと思うけど。三島も太宰も漱石も芥川も鴎外も、せいぜい教科書に載ってるものくらいしか読んでない奴がいっぱいいるだろう。つーか、グッと読みやすく村上春樹でもいいよ。一冊も読んだことない奴がいっぱいいるぞ。今日本はそういう状況なんだ。
あと世界文学ね。「罪と罰」やら「戦争と平和」やら、名前だけしか知らない人ばかりだろ。
「楽しむ」という観点で言えば、古典や漢文の題材がそれらよりも優先するようには思わない。
俺も理系人間で、たいして出来がよくなかったから思うんだが、行列は大学入試という重しがある高校生の間にある程度慣れておくべきものだ。
大学で習った偏微分とか周回積分とかいっこも覚えてない俺でも行列演算は一通り出来るし、プログラミングとかで使えるのは、高校でみっちりやったからだよ。
行列と比べてどうなんだと聞いてるんだが。
そりゃ基礎技術力が高く工業力が強いほうが観光立国よりずっといいだろ。
C++で値同士の論理積、論理和などの論理演算は最適化でビット演算になるくせに常用しても「可読性を考慮して」という理由から怒られたりはしない。
でも関数の引数型が組み込み型であった場合にそれをconstな参照型にすると「組み込み型は参照型にすると参照のコストがコピーのコストより大きくなるから」という理由から怒られる。前述の可読性云々という理由をこの話に当てはめると意味の方から考察するに『変更不可能な引数』になるからこっちの方が適しているし、更に同じ様に最適化で参照渡しは消えて値渡しになるんだから怒られる理由はない。この程度の最適化は近年のまともなコンパイラなら造作ないので、できる限り可読性を重視して単純な最適化はコンパイラに任せた方が良いのに。
自分の自尊心を保ちたいだけなのか俺を単に公の場で馬鹿にしたいだけなのか知らないが何も分からない無能が偉そうに物言いやがって死ね糞っ垂れ。
「どうして小、中、高の教育カリキュラムの中に算数や数学が含まれているのですか？」
「理由は二つあります。一つは社会生活を営む上で最低限必要な知識を習得するためです。例えば、数字や四則演算は物の数を数えたり、暦を見たり、町で買い物をしたりする時に必要です。少し込み入った話になると、ローンの利息計算などの資産管理や、移動時間の見積もりなど、数学が必要な場面はたくさんあります。
もう一つは進路保証のためです。専門的な職業につく場合において、より高度な数学を必要とする場合があります。測量、統計調査、機械設計などがそれにあたります。これらの作業を行う際には三角関数、微分積分、数列、グラフ、オートマトンなどが必要になってきます。子どもたちは中学、高校を卒業したあたりから進路を考え始めると思いますが、それまでに、どんな職業でも通用するような基礎的な知識や学力を蓄えることが、数学に限らず、学校のカリキュラムの意義だと思います。そうでなければ、若いうちから子どもの可能性を奪ってしまうことになるという危惧があります。
数学はあくまで便利な道具すぎませんので、必要なければ微分積分などを無理に覚える必要はありません。
必要なときに必要な数学を学んでいただければ、それで十分だと思います。文系、理系を問わず、どんな方でも、実際に使用する公理、公式以外には興味がないことがほとんどです。」
前世紀に想像されていたようなスーパーコンピュータが作られた。莫大な演算能力を用いて、最適な人材配分・資源配分を行うことによって、人の手ではなしえないくらい効率的な社会運営を行えるそのコンピュータは、すぐにでも配備されるものだと思われていたが、いざ配備しようとすると問題視する人が続出した。旧世代の人々にとって前世紀の創作物に描かれたような社会は畏れの象徴でもあったので、頑として受け入れようとしなかった。仕方がないので政府はモデルケースとして人口が少ない土地にコンピュータを置き自治権を持たせることにした。半年後のテスト開始までにその土地で暮らしたくない人は転居にかかる諸費用を負担するので転居してもらい、逆にその土地で暮らしたい人には移住してもらった。
旧世代がメディアを握っていたので、その土地で暮らしたい人はほとんどいないだろうとのことだったが、蓋を開けてみたら若い世代を中心に数多くの人がその土地に移り住み、元々その土地に住んでいた人も出て行く人よりも残る人の方が多かった。勿論、新しい社会制度に夢を見た人もいたが、大半はその条件の良さが理由だった。全自動化した機械が中心の上、効率化した組織運営が行われるので人がやるべきことはとても少ない。だから優秀な人材にとっては現在の社会の1/10の勤務時間で2倍の年収を保証されていたし、優秀でない人材はなんと働かなくとも現状以上の衣食住が保証されていた。彼らを賄えるだけの余剰は効率化によって十分得られる予定だったし、次世代の人材を作るための生殖用人材の確保と、彼らが生殖が行えなくなったとしても安心して暮らしていけるための示威としてはお釣りが来るほどであった。
かくしてモデルケースがスタートした。結果は1年も経たずに現れ始めた。見る見るうちに富が集まり始めたのだ。効率の次元からして違うのだから当然だった。そして集まった富で更に設備を拡充させて効率化を図る。その繰り返しなのだから人手で非効率な運営をしている他の民間企業が相手になるわけもなかった。それでもまだ余剰が溢れるように生まれるので住居施設も充実させた。すると、ネットは繋がったままだったので、そこからどんな暮らしなのかが外へと伝わる。「今日もまた一日中遊び続ける仕事が始まるお」「ネットしてるだけでお金が貯まる仕事はじまるお」などなど。そんな中でも注目を集めたのは「今日もまた俺の嫁とのセクロスだお」「毎日がこれなんてエロゲだお」などの書き込みだった。
生殖はコストの面から人工生殖ではなく自然生殖が採用されていたが、一般的な自然生殖だとそこで生じる関係性によって様々な問題が起こると予想されていたので、ゴーグルをつけての生殖が規則であった。ゴーグルには相手の位置を検出してそこに理想とする相手を映写する機能がついていた。対象の顔の位置を検出して違う顔画像と差し替える技術は昔からあったが、そのゴーグルでは顔だけではなく体も、しかも画像ではなく表情や仕草もあり、見た目の質感なども再現できる優れものであった。理想の相手との性交なのだから皆進んで励む。相手を探している人とのマッチングはコンピュータがやってくれ、部屋の隅にある移動用の区画に座っていれば、マッチングが済み次第、部屋へと自動で運ばれてすぐ事に及べた。ほとんどの場合相手は毎回違うのだが、主観的にはゴーグルに映写されている相手との性交なので気にされることはなかったし、映写する人物も飽きたら変えるという人がほとんどだったので問題にすらならなかった。ディスプレイの向こうにいるのが誰かということよりも、ディスプレイに誰を映すかという方がよっぽど関心のある事だったのだから。
3年もする頃には参加希望者が予想を大きく上回り自治地域を拡大した。それでも間に合わず5年後には逆転させて、コンピュータによる運営を国家政策として、それが嫌な人は自治をしてもらうことになった。それでもネットと接続していると移住してしまう人が続出したので、ネットが普及する前の文化基準で自治を行い、さながらアーミッシュのようでもあった。初めは一国の地域単位だった出来事も、それが国単位に及び、地域から国への普及を繰り返すように、コンピュータによる社会運営を選択する国が続出した。まるで低きに流れるように。
現在ほとんどの国では同じような光景を見ることができる。自室から出ることもなくただ貪り生殖する動物が数え切れないくらい収容されている箱が、さながら厩舎のようでもあり生物のようでもある無数の箱が、地上に立ち並ぶ光景を。
３行とか……無茶言うなあ。
といいつつ、なんとなくオラわくわくしてきたぞ。
変態かな。
以下、本の内容を３行で。
演算だけでなくそもそもどんな言葉の意味も一番さかのぼると「これが○○（直示的定義）」にたどり着きます。
直示的定義には常に誤解が入り込み得ます。だから相手が「ホントに理解してるか」なんて確かめる術はありません。
以上。
最初の話にさかのぼって言うと、ある演算式がinputされた際に、暗記にたよろうが頭の中で一つずつ絵を並べて数えていようが、そろばんの得意な人みたいに頭の中で何か神秘なることを起こしていようが、outputさえ正しければ基本的には誰もその正当性を問わないということです。事実、例に挙がった話でも、答えが違っていて初めて「頭の中で起きていること」が問題になっているでしょう。我々の日常に「お互いに同じ言葉を実は違って認識していた」なんてことは、よくあることです。
だから足し算を「正しく定義する」というのは無意味な考え方ですが、足し算が「できるようにする」というのは別に難しい話ではない。りんごの絵とみかんの絵とかで直示的に定義して訓練すれば、大抵の子供はすぐinputとoutputをそろえることはできるようになる。奇妙に思えるかもしれませんが、我々の世界というのはそういう風にできているということです。
…って３行といいつつ膨大に補足した。正直反省している。
ミニブログがとうとう産声をあげ始めた今のこの状況を見て、インターネットの創始者は「これこそインターネットだ！」と言うに違いない。今までのインターネットは、どこか現実と離れすぎていたからだ。
匿名で情報を発信できる構造を作れるが故に、接続している人間全員が平等に情報を受信できるが故に、ネットに存在できる情報が多様であるが故に、あたかも別の世界を形成しそこには“様々な情報と文化が無秩序に飛び交う混沌とした秩序”があった。
これは現実とは違う。情報の仕入先にこそ目は現実に向けられているが、一部の愛好家っぽい人でしか接点を持っておらずインターネットの中でのスタイルは本来互換性を持っているべきである現実とはほとんど剥離していた。
しかし今は違う。PCや携帯電話を『ブラックボックス』『魔法の箱』『ボタンがいっぱいついてる玩具』と見なす機械音痴の方が少数派になってきている。どの様に動くか、その超高速の演算能力をどの様に使うかを理解し、現実と結びつけて有効活用する人が増えた。
もう勘の良い人は分かっているかもしれない。インターネットは高性能なコンピューターと大規模なネットワークだけでは役に立たない、現実と結びつける力を持った人間が居て始めて威力を発揮するのだと言う事を。
