「設計の理論」の版間の差分
削除された内容 追加された内容
typo ほか |
多項式近似は測定値データ台帳で使うので付近に移動。 |
||
133 行
ただし、これはあくまで、設計図面の書き方です。教本や指導書などの書き方とは、設計図面の書き方は、違います。もし、新人むけの指導書や教科書・教本を書く場合には、やや重複のある内容でも何度も説明して覚えさせましょう。
170 ⟶ 169行目:
マトモな業界では、プログラムの検証のため、そのソフト以外およびそのソフトを動かしているハードウェアとは別のデバイス（電卓でも良い）を使って、ダブルチェックをするのが常識です。（※この常識には出典を出せませんが（企業秘密などに関わるので）、しかしダブルチェックを軽視する側の主張も満足な出典を出せていないので、対抗的にこの文を残します。）
さて、入力されたハズのデータの台帳のような内容の一覧の書類が、一般の技術系企業では必要です。業界で「台帳」と言うのかは知りません。名前が無いと困るので、とりあえず土木工学ではこういうのを「○○台帳」というので<ref>国土交通省大臣官房技術調査課『改訂版よくわかる公共土木工事の設計変更』、一般財団法人 建設物価調査会、60ページ</ref><ref>国土交通省大臣官房技術調査課『改訂版よくわかる公共土木工事の設計変更』、一般財団法人 建設物価調査会、60ページ</ref>、それに習って「データ台帳」という題名を本セクションでは、つけているだけです。なので、
== 多項式近似 ==▼
測定値などで、入力変数が一変数なら、エクセルなどを用いて多項式近似が出来ます。
しかしIT業界などの実務では人間の検算などの手間を減らすために、なるべく、せいぜい2次式や3次式といった、低めの次数におさえて利用するのが、IT企業では普通です。▼
もし先端科学のための多項式近似なら、9次を超えるような多項式近似をするような場合もありますが、しかし、一般の企業では、そこまでの多項式近似は不要ですし、むしろ検算などの管理の手間が増えるので、9次のような多すぎる次数は嫌われますので、なるべく2次ていどに抑えましょう。▼
ゲームではバグがあっても、人は死にません（過労自殺などを除けば）。なので、アイデアが思いついたら、どんどんとプロトタイプで試してみましょう。▼
ですが、他の業界だと、バグがあると人が死ぬ場合もあります。たとえば、製造業での、組み込み機器などがそうです。▼
書籍で紹介されている事例だと『メタルカラーの時代』シリーズ（山根一眞（やまね かずま）による取材）で、▼
「日本ユニシス」というIT企業がかつて、提携している別企業のNC工作機械に向けた組み込みソフトの開発で（組み込みソフト部分をユニシスが開発）、開発テスト中のバグにより工作機械の刃物が本体にぶつかって折れて飛んできて、あやうく人が死ぬところだった、▼
・・・という感じの事例がインタビュー先のプログラマから紹介されています。 ▼
それまで日本ユニシスおよびその担当プログラマーでは、組み込みの仕事はほとんど扱わずに、どちらかというとIT業界内での顧客を仕事をしていたので、そういう人が死にそうな事例に経験することがなかったので、製造業の組み込みソフトでは特にバグおよびバグ予防に対する考えをIT業界内の仕事とは変えなければならない必要があることに気づかされた、とユニシスの技術者はインタビューで述懐しています。▼
== 履歴の管理 ==
437 ⟶ 455行目:
;大小関係の前提
数学的には、「最大」や「最小」といった大小関係を語るには前提として、何かの尺度にもとづいての序列化を直線的・一面的にだけ行う必要があります。裏を返せば、ジャンケンのグ－・チョキ・パーのように強さが循環するものについては、大小関係を定義できないということが、数学的に解明されています。（出典を求めるなら、たとえば数学科の大学2年レベルの代数学などの教科書（『群論』（ぐんろん）や『集合論』（しゅうごうろん）などの科目）で説明されている。）大小関係では、ジャンケンのような循環は許されません。
▲== 多項式近似 ==
▲なお、一般にIT業界での実務の多項式近似では、原理的には9次でも20次でも、どんなに次数が高くても（おそらく int 整数型の限界くらいまで）計算できてしまいますが、
▲しかしIT業界などの実務では人間の検算などの手間を減らすために、なるべく、せいぜい2次式や3次式といった、低めの次数におさえて利用するのが、IT企業では普通です。
▲もし先端科学のための多項式近似なら、9次を超えるような多項式近似をするような場合もありますが、しかし、一般の企業では、そこまでの多項式近似は不要ですし、むしろ検算などの管理の手間が増えるので、9次のような多すぎる次数は嫌われますので、なるべく2次ていどに抑えましょう。
▲{{コラム|バグあると人の死ぬ業界|
▲ゲームではバグがあっても、人は死にません（過労自殺などを除けば）。なので、アイデアが思いついたら、どんどんとプロトタイプで試してみましょう。
▲ですが、他の業界だと、バグがあると人が死ぬ場合もあります。たとえば、製造業での、組み込み機器などがそうです。
▲書籍で紹介されている事例だと『メタルカラーの時代』シリーズ（山根一眞（やまね かずま）による取材）で、
▲「日本ユニシス」というIT企業がかつて、提携している別企業のNC工作機械に向けた組み込みソフトの開発で（組み込みソフト部分をユニシスが開発）、開発テスト中のバグにより工作機械の刃物が本体にぶつかって折れて飛んできて、あやうく人が死ぬところだった、
▲・・・という感じの事例がインタビュー先のプログラマから紹介されています。
▲それまで日本ユニシスおよびその担当プログラマーでは、組み込みの仕事はほとんど扱わずに、どちらかというとIT業界内での顧客を仕事をしていたので、そういう人が死にそうな事例に経験することがなかったので、製造業の組み込みソフトでは特にバグおよびバグ予防に対する考えをIT業界内の仕事とは変えなければならない必要があることに気づかされた、とユニシスの技術者はインタビューで述懐しています。
}}
| |||