アカウント名:
パスワード:
実績あるライブラリ関数+馬鹿の書いたアルゴリズムより、馬鹿の書いた関数+馬鹿の書いたアルゴリズムの方が事故が起こりにくいと考える理由が分かりません。
その考え方は半分正しくて、半分間違ってます。
車輪ユーザは自分で作れなくても、車輪のデキを判定する能力は持ってます。料理が作れなくても、ウマイマズイ自分に合ってる、のレベルでの判定能力を持ってる（持てる人の数＞＞＞作れる人の数）のと同じことです。
それを無視して「お前らは作れもしないくせに俺に注文を付けるのか」という形になったら作る側として失格です。
一方で、「俺は客だ。俺が評価者だ。お前らは俺の意見だけ聞いて黙って作るだけだ」とか車輪ユーザーが言い出したなら、速攻でそんな奴は見捨てて車輪のない生活を楽しませてあげましょう :-)
アルゴリズムは理解してなくても計算精度について判断できるなら、そのライブラリの品質について不安を抱く、というのはまっとうなユーザの態度だと思います。
違う違う。自分では車輪を使うことしかできないくせに、｢車輪を作ること自体｣を馬鹿にする素人にウンザリなの。虎の威を借る狐。
それはOSS全般についての共通の悩みですよ。よほど叩かれて欠点まで明らかになってる枯れたものじゃないと、自分が使い込んだ経験のないOSS品は大抵どこかでドツボにはまります。
マニュアルとヘルプとコードが違うとか、サポート済みと言われているものが実は「お前これ動かしたことあるのか？」位に簡単に吹っ飛ぶとか日常茶飯事。だからOSSを使うというのは「誰かが作ったものにフリーライドしよう」とか思ってるとあんまり使いこなせない。
崩れやすい巨人の肩に乗るつもりで、崩れた部分は自分が再建するくらいの感覚で石橋を叩きながら使う、というのがOSS導入の姿勢として妥当かと。そういうコストを払ってでも、共有地を耕すことが幸せになるんだと思いながら。
それはOSSに限らないでしょう。今やっている某ソフトウェア製品の検証でもドキュメントと実装は全く違うUIで嫌になっています。OSSだけで問題が起こるというのは大きな間違いで、VMwareでもWindowsでも皆、細かな環境の違いはテストできていないから大量のKBがリリース後に出る訳です。
自製、導入品・HW・SWにかかわらず、部品は検証してから使えってただそれだけな気がします。検証の手法とスキルが必要で、それには0から作るに等しい技術がいるかもしれませんが、自分で作る必要はない。なぜそこで自分で作るというリスクを取る？
例えば、精度の悪いネジは大事故の元になるけど、普通ネジを自分で作らない。通常の範囲ならば、精度のいいネジを使うで十分。本当に必要ならば作る分野もある。それを分けるのは検証。
組み込みの話ですが、kenelにLinuxを使っているのに、LinuxのUSBクラスドライバを使用せずに、独自にUSBドライバを作れとか言われたプロジェクトがあったな。確かに使用するUSBデバイスがただ一つしかない環境ではあったのですが、クラスドライバやフレームワークの使用を禁止して、車輪を再発明することを強要するプロジェクトは多い。いかにクラスドライバやフレームワークを活用たうえで、短納期で要求仕様を満たすかという視点もあってもいいと思う。まあ、発注元の上流工程の技術者がタコで、ハードの性能やOSの機能、ライブラリの仕様を理解せずに要求仕様を設計している段階で、無理があるだろう。機能単位での設計はできても、システム全体での最適化や効率的な設計ができない上流工程の技術者が多すぎる。
誤差などに不安を感じるときは、その誤差を検出できるテストを書いておくといいよ。何か修正したときには、テストを通して通ればそれで安心だし。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
ライブラリの利用にたまに不安を感じることが (スコア:1)
アルゴリズムの手元での検証に行列計算のライブラリ等を使っています。
使っている際に，ライブラリ内で行われている計算の原理と実装を理解してないと
火傷することがあるんじゃないかな，ということを何度か感じました。
現時点では誤差の出方がライブラリの採用しているアルゴリズムで違ったり，式の定義が微妙に違ってるとか，
その程度なので使おうと思ってドキュメントを見てる時点で気付いていますが･･･。
怖いからといって数値計算の部分を全部一から丁寧に書いていると
目的の検証に辿りつくまでに非常に時間がかかってしまいます。
でもライブラリの中身をよく理解しないでライブラリの関数に丸投げしてしまうと，
いつかアルゴリズムが自分の手元を離れて利用されるときに事故が起きる気がします。
道具に頼っていると道具で作りやすいものしか生み出せなくなってしまうのではないか，という漠然とした不安もあります。
適当な距離感が良く分からなくてたまに勝手に悩みます。
Re: (スコア:0)
実績あるライブラリ関数+馬鹿の書いたアルゴリズムより、
馬鹿の書いた関数+馬鹿の書いたアルゴリズムの方が事故が起こりにくいと考える理由が分かりません。
Re:ライブラリの利用にたまに不安を感じることが (スコア:1)
（アプリケーションの元になるというより，ある種の計算を正確にやらせるだけ）
のため，不安を感じたのかもしれません。申し訳ないです。
例えば逆行列を数値計算するとき，アルゴリズムが違うと，
行列の中身によって誤差の出方が変わってしまうようです。
反復計算によるアルゴリズムになっていた場合は
行列の中身によって正確な解が出ない可能性もありました。
また，例えばある窓関数が，知ってる窓関数と同じ名前なのに微妙に式が違っていたりしました。
無知由来の軽い話なので，軽くドキュメントを見ただけで回避できますが，
いつかどこかでもっと深い部分に気付かずに火傷しないかな，と感じてしまいました。
Re: (スコア:0)
Re: (スコア:0)
その考え方は半分正しくて、半分間違ってます。
車輪ユーザは自分で作れなくても、車輪のデキを判定する能力は持ってます。
料理が作れなくても、ウマイマズイ自分に合ってる、のレベルでの判定能力を
持ってる（持てる人の数＞＞＞作れる人の数）のと同じことです。
それを無視して「お前らは作れもしないくせに俺に注文を付けるのか」という形に
なったら作る側として失格です。
一方で、「俺は客だ。俺が評価者だ。お前らは俺の意見だけ聞いて黙って作るだけだ」とか
車輪ユーザーが言い出したなら、速攻でそんな奴は見捨てて車輪のない生活を楽しませて
あげましょう :-)
アルゴリズムは理解してなくても計算精度について判断できるなら、そのライブラリの
品質について不安を抱く、というのはまっとうなユーザの態度だと思います。
Re: (スコア:0)
違う違う。
自分では車輪を使うことしかできないくせに、｢車輪を作ること自体｣を馬鹿にする素人にウンザリなの。
虎の威を借る狐。
Re: (スコア:0)
それはOSS全般についての共通の悩みですよ。
よほど叩かれて欠点まで明らかになってる枯れたものじゃないと、
自分が使い込んだ経験のないOSS品は大抵どこかでドツボにはまります。
マニュアルとヘルプとコードが違うとか、サポート済みと言われているものが
実は「お前これ動かしたことあるのか？」位に簡単に吹っ飛ぶとか日常茶飯事。
だからOSSを使うというのは「誰かが作ったものにフリーライドしよう」とか
思ってるとあんまり使いこなせない。
崩れやすい巨人の肩に乗るつもりで、崩れた部分は自分が再建するくらいの感覚で
石橋を叩きながら使う、というのがOSS導入の姿勢として妥当かと。そういうコストを
払ってでも、共有地を耕すことが幸せになるんだと思いながら。
Re: (スコア:0)
それはOSSに限らないでしょう。今やっている某ソフトウェア製品の検証でもドキュメントと実装は全く違うUIで嫌になっています。
OSSだけで問題が起こるというのは大きな間違いで、VMwareでもWindowsでも皆、細かな環境の違いはテストできていないから大量のKBがリリース後に出る訳です。
Re: (スコア:0)
自製、導入品・HW・SWにかかわらず、部品は検証してから使えってただそれだけな気がします。
検証の手法とスキルが必要で、それには0から作るに等しい技術がいるかもしれませんが、
自分で作る必要はない。なぜそこで自分で作るというリスクを取る？
例えば、精度の悪いネジは大事故の元になるけど、普通ネジを自分で作らない。
通常の範囲ならば、精度のいいネジを使うで十分。
本当に必要ならば作る分野もある。それを分けるのは検証。
Re: (スコア:0)
組み込みの話ですが、kenelにLinuxを使っているのに、LinuxのUSBクラスドライバを使用せずに、独自にUSBドライバを作れとか言われたプロジェクトがあったな。確かに使用するUSBデバイスがただ一つしかない環境ではあったのですが、クラスドライバやフレームワークの使用を禁止して、車輪を再発明することを強要するプロジェクトは多い。いかにクラスドライバやフレームワークを活用たうえで、短納期で要求仕様を満たすかという視点もあってもいいと思う。まあ、発注元の上流工程の技術者がタコで、ハードの性能やOSの機能、ライブラリの仕様を理解せずに要求仕様を設計している段階で、無理があるだろう。機能単位での設計はできても、システム全体での最適化や効率的な設計ができない上流工程の技術者が多すぎる。
Re: (スコア:0)
誤差などに不安を感じるときは、その誤差を検出できるテストを書いておくといいよ。
何か修正したときには、テストを通して通ればそれで安心だし。