アカウント名:
パスワード:
十数年仕事で(アマ時代を入れると20年以上)使っていたのに知らなかったので数日はまった。
バグったコードからエラー原因を簡素化したテストコードは以下。float型(i)とint型(k)で1ずつ加算していって異なったら標準エラーに出力。
#include <stdio.h>int main(){ float i; int k; i=0; for(k=0;k<=16777217;k++){ if(k != (int)i) fprintf(stderr,"%i %i\n",k,(int)i); i += 1; } return 0;}
えー常識だと思っていたけどな計算機イプシロンとかその辺で出てくる話題だと思た
計算機的な講義(世代により中学なり大学なり新人研修だったりするだろうけど)でイの一番に習いそうだけど。
浮動小数のバックグランドを知らない人間に浮動小数を扱わせてはいけない、の実例。
Z80用の単精度浮動小数点ライブラリを自分で書いてみたクチだから、どれくらい浮動小数点での加減算が信用できない(精度が足りなくなる)か身に染みて分かる。今は浮動小数点形式の構造ばかりか、スタックの構造やらポインタ、果てはデータのメモリ内での記憶方法なんぞを知らなくても良い時代になったと思えばいいのかなあ。
今はNCデータが割と身近にある仕事してるんだけど、それに慣れてると、小数はぜんぶ1000倍して常に整数で持たせたくなる。モノはでかくても4mくらいだし。
なぜ1024倍でないのか?
CNCだったら普通、アドレス中に小数点がない時に使用する基準単位って設定項目にあるよね。そこでumを設定しておけば解決するでしょ?
0.001mm を 1024倍して何が嬉しい?
二進数の整数で扱うなら、1000倍より1024倍の方が計算が簡単なんだけど、知らない?
二進化十進数なら話は別だと思うけど。
NCデータがどういう情報かはご存知ですか?
# 相変わらずな御仁だなあ
しりませんが、それが何か?通常、浮動小数点で扱ってる数値データなんでしょ?それを、固定小数点で扱いたい、って話なんでしょ?何か問題でも?
そしてキミからは、具体的には何の反論も出てこない、という相変わらずさじゃ無いといいけど。
いまどきこんなこと言ってる人いるんだなあw $ cat test.cint hoge(int n){ return 1024 * n;}
int piyo(int n){ return 1000 * n;}
$ gcc -O2 -S test.c -o - .text .globl hogehoge: movl %ecx, %eax sall $10,
目的と手段の区別がついてないから呆れられてるんだよ。
NCデータと通常称されるものは、NC工作機械に入力されるテキストデータ。テキストデータなので浮動小数点も固定小数点もない。それを読み取ったCNC側が内部でどう扱っているかは別問題としてあるが、通常外部に公開されていない。
また"G91X1;"と"G91X1.;"が同じ動きをするかどうかは設定次第。よくある設定だと小数点抜きの場合um単位、小数点をつけるとmm単位の指令と解釈される。三菱のCNCなら"#1015 cunit プログラム指令単位"の設定内容を確認する。
そもそも別の設定項目でメトリック系とインチ系が切り換えられたりするから、NCデータ単体では各数値の表す意味は不明。
# 組み込みマクロにSINとかあるけど精度調べたことなかったなあ。# 計算精度より先に位置決め精度のほうが頭打ちになる機械ばかりだしどう確認しよう。
これて浮動小数点で得られるものを、固定小数点で表したい、ってはなしだよね。なら、
int hoge(double n){ return 1024 * (int)n;} int piyo(double n){ return 1000 * (int)n;}
とかにしないと。
掛け算しようとすると、固定小数点なので、
int hogemul(int n, int m){ return ((long)n * (long)m)/1024;} int piyomul(int n, int m){ return ((long)n * (long)m)/1000;}
乗除のたびこうい計算が必要になるわけだね。
で、どうなった?
これて浮動小数点で得られるものを、固定小数点で表したい、ってはなしだよね。
0.001mmをゲタ履かせて整数の1で表したいって話でしょ。アンタとことん馬鹿だね。
「知りませんが」で調べもせず、思いつきな押し付けで押し問答。レスするたびにツッコミは倍増、ツリーのインデントは打ち止め。
ホント相変わらずだね。
> return 1024 * (int)n;ではなくて、
return (int)(1024.0 * n);
ではないの?だとしたら1024でも1000でも計算コストは変わらないよね。
> 掛け算しようとすると、固定小数点なので、> return ((long)n * (long)m)/1024;
これも、掛け算したらもはや単位は長さではなく面積なので、長さ 1unit=1/1,000 mm面積 1unit=1/1,000,000 mm2と仕様書に書いておけばすむ話。
いずれにしても、僅かな計算機リソースの節減より、十進にしたときの見やすさを優先するなあ。私だったら。
0.001mmをゲタ履かせて整数の1で表したいって話でしょ。
それなら、マイクロメートル使いなよ。できないわけじゃない [srad.jp]みたいだけど、何が問題なの?
NCデータと通常称されるものは、NC工作機械に入力されるテキストデータ。テキストデータなので浮動小数点も固定小数点もない。
つまり、二進化十進数 [wikipedia.org]ってことね。既に書いた [srad.jp]通り、それなら話は別。
で、機械に食わせる二進化十進数を1000倍して小数点を無くすかずらすかして、何か嬉しいの?小数点以下の0が9個以上連続する、とかなら判らんでもないけど、3個くらいなら人間が手を加えるにしても、大した話じゃ無いと思うけど。
数点抜きの場合um単位、小数点をつけるとmm単位
「um」って、「μm」のこと?そっちの業界では、そー書くの?
そもそも、マイクロメートルを扱えるなら、そうすればいいだけじゃん、と思うけど、違うの?
1024 * (int)nだろうと、(int)(1024.0 * n)だろうと、1024倍と1000倍でコストは変わらないね。実際、どちらの場合も、コンパイラが吐くニーモニックのステップ数は同じになる。
ただし、掛算とビットシフトが同じコストと考えるならば、だけどね。実際には同じではないので、コンパイラも1024倍の時は、掛算命令でなくビットシフト命令を吐くわけだけど。
そんなことで済むなら、そもそも#3069125 [srad.jp]は何だったのか、って話になっちゃうね。
それにもし、そうしたいのであれば、普通「長さ 1unit=1μm」だよね。マイクロメートル、学校で習ったよね?面積に至っては、そんなに0を並べちゃ、残念ながら見やすいとは言えなくなっちゃうね。もし、そんに0が並んでも見やすいって言い張るのなら、小数点以下に2つゼロが並ぶのも問題無い、ってことになって、1000倍する意味がなくなるね。
そもそも、機械に食わせるデータに、見やすさなんか関係あるの?もし、機械がmmしか扱えないとしても、適切なフィルタ書いてやれば済むんじゃね?その程度のスクリプト、キミにだって書けるでしょ?
えっと、IA-32命令 [intel.co.jp]で恐縮ですが、1024倍のほうは 0.5+4に対して、1000倍は14のレイテンシってことでいいのかな?たいぶ差が縮まったとはいえ、まだ3倍ほど"1024 * n"のほうが簡単だよね。
> コンパイラも1024倍の時は、掛算命令でなくビットシフト命令を吐く
(int)(1024.0 * n)って、ビットシフトで計算するんですか?自分のところのVisualStudioではどちらもfmul命令に変換されたんですが。
> マイクロメートル、学校で習ったよね?
業界によりますが、長さをmmで扱うのが当然のところでは、1000mmを単純に1mと略さないのと同じ程度には、0.001mmを単純に1μmと書かないところがあります。
> そもそも、機械に食わせるデータに、見やすさなんか関係あるの?
思った結果にならなかったときに、生データをその場で当たらなければならないことは往々にしてるんですよ。
floatの値から指数部を取り出して10を足し、floatの取りうる指数の範囲を超えていないかを判定、超えていなければfloatの値の指数部を書き換え、超えていれば無限大(指数部を255、仮数部を0)に書き換え、という手順になると思うけど、浮動小数点数が扱えるプロセッサなら素直に1024.0倍した方が早いと思うよ。
「簡単」をスループットかなんかと勘違いしてる人?
えっと、IA-32命令 [intel.co.jp]で恐縮ですが、1024倍のほうは 0.5+4に対して、1000倍は14のレイテンシってことでいいのかな?
いまどき「各表には、Intel Pentium 4 プロセッサに固有のデータを記載した。」なんて書かれてるドキュメントの数値を挙げてドヤ顔とは恐れ入ります。
(int)(1024.0 * n)って、ビットシフトで計算するんですか?
当然しませんが、そーゆー意味じゃないです。#3069313 [srad.jp]を受けた発言です。
そーゆー業界に身を置くなら、慣れるのが吉。業界を変えるのは超困難だけど、自分を変えることはできるので。0が二つ三つ程度の話ならなおさら。
でも、「1unit=1/1,000mm」と書くのはokって話なんだよね?キミに文句を言ってもしかたないけど、ミョーな業界ルールだねぇ。
ところで、私は機械可読なデータの話のつもりだったんだけど、設計図とかの話にズレてる気がする。気のせいですか?
それとも、データの中で「1unit=1/1,000mm」とかって宣言可能って話?だったら、最初 [srad.jp]からそれで良かったのでは?
どーしても慣れない、ってことなら、単位を変換するスクリプト書けばいんじゃね?機械可読なデータなら難しくは無いでしょ。
この人はどーして恥の上塗りを繰り返すのだろう?
なんでこの匿名の臆病者は、無根拠な一口中傷を繰り返すのだろう。→何度もRyo.Fにコテンパンにノされて悔しいのう悔しいのう、だけど、まともに議論するとまたノされちゃうから(笑)。
「顧客も自分が使っているCPUと同程度のものを使っているはず」って思い込める環境っていいよね。何のためにコンパイラがわざわざ2のべき乗の場合はシフト命令を吐くのか、みたいな思いなんていらないもんね。IA-32命令を挙げたのはそれしか86系CPUで命令毎の情報が見つからなかったからで、「○○以降なら乗算とシフトとは同じ速度で演算できる」っていうのが示せるんだったら出して欲しい。
#仕事ではARMを使っているけど、ダイに入りきらなかったのか乗算器は積んでいない環境なんですよ。
「顧客も自分が使っているCPUと同程度のものを使っているはず」って思い込める環境っていいよね。
「いまどきこんなこと言ってる人いるんだなあw」と「いまどき」の話をしてる投稿に対するレスについて何トンチンカンなこと言ってんの?
ということにしないと精神の安定が保てない人かな? 傍から見て哀れな人だなとしか。
仕事ではARMを使っているけど、ダイに入りきらなかったのか乗算器は積んでいない環境なんですよ。
そんなんで大騒ぎとは技量の低さが窺い知れますがおめでたいですねw
IA-32命令を挙げたのはそれしか86系CPUで命令毎の情報が見つからなかったからで、「○○以降なら乗算とシフトとは同じ速度で演算できる」っていうのが示せるんだったら出して欲しい。
「十分に速けりゃ議論として無意味」ということも理解できない頭なのかな?
今時Pentium4ユーザーが顧客ですか? ご愁傷様としか言えないですね。
ARMはARM2の頃から使ってるけど乗算で苦労した記憶はないなあ。ARMって何使ってんの?
古いほうはARM7だったかな?SoCなので更新もなかなかできず両方現役です。ASIC部分が大きくて高速乗算器を諦めたと推定しています。設計者に聞いたわけではないので本当のところは判りませんが、サイズがキツいのは確かですから。苦労っていうより、単にスケーリングする時のような1000倍でも1024
古いほうはARM7だったかな?SoCなので更新もなかなかできず両方現役です。ASIC部分が大きくて高速乗算器を諦めたと推定しています。設計者に聞いたわけではないので本当のところは判りませんが、サイズがキツいのは確かですから。
ARM7? MUL命令やMLA命令は普通に使えた時代ですね。正直言って何言ってんのという感じだけど、それか、レベルの低い職場なんだなあ、としか。
MUL命令自体はありますよ。それが高速乗算器を使うか反復乗算器を使うかはSoCにするときの実装しだいってことです。
苦労っていうより、単にスケーリングする時のような1000倍でも1024倍でもいいような用途に、何も気にせず"n*1000"って書く奴にがっくりするんですよ。少なくとも、何万回も廻すループで使われないかとかは気にして欲しいし、「後で逆変換でスケーリングした分を除算するかもしれない」とくらいは考慮しておいて欲しいものです。(まあ、大きいほうにスケーリングすることはそう無いと思いますが)
0.001mm を 1000倍して整数の 1 として扱いたいって話について何言ってんの?
> 当然しませんが、そーゆー意味じゃないです。> #3069313を受けた発言です。
1024 * (int)n だと、1.5mmなどを正確に変換することができないので、(int)(1024.0 * n)を使うことになります。この場合、1000.0の代わりに1024.0を使う意味がなくなります。
> どーしても慣れない、ってことなら、単位を変換するスクリプト書けばいんじゃね?
印刷された数値列を直接読むって結構ありますよ。
この場合、1000.0の代わりに1024.0を使う意味がなくなります。
そーでもないんだけどね。浮動小数点といえども、所詮二進整数の組合せなので。# コンパイラがそこまで最適化してくれるかは知りませんが。
スクリプトを噛ました後に印刷すればいいんじゃね?
なんか、「1unit=1/1,000mm」と書くとか、スクリプトを書くとか、慣れるとか、いろいろ手はありそうなのに、できない理由ばかり書いてる気がするね。
そーでもないんだけどね。
0.001mmを整数の1として扱いたいって話なんだから、1024.0を掛ける意味なんて最初っからないよ。
> # コンパイラがそこまで最適化してくれるかは知りませんが。
いやいや、コンパイラが最適化してくれないと意味がないです。コンパイラが最適化してくれないのでアセンブラで書きました、では工数もかかるしバグも潜むし可読性が低くて他の人がメンテできないです。
> スクリプトを書くとか、慣れるとか、いろいろ手はありそうなのに、できない理由ばかり書いてる気がするね。
できないことはないですが、私でない他の人が数値を読むときに、「1024で割ってください」「スクリプトを噛ましてください」なんて仕様書で指定した日には「○○君の謎仕様」と末代まで祟られることでしょう。自社の後継者のみならず他社からも。
プログラムもデータも、他人が使うもの、という意識で書く必要があると思っています。プログラミングして3日もたてば、自分ですら他人になることがありますし。
> 「1unit=1/1,000mm」と書くとか
これが単純で最適な解なんじゃないでしょうか。
自社の後継者のみならず他社からも。
そーゆー業界に居るなら、業界のルールに従って、それに慣れるのが一番です。たかが0三つくらいの話なんでしょ?
「自社の後継者のみならず他社」に至るまで、その「最適な解」を受け入れてくれれば、その通りです。で、実際受け入れてもらえるんですか?もし、受け入れてもらえないのなら、「最適な解」と言うより、非現実劇な解と言うべきでしょう。
もし、受け入れてもらえるのなら、何をここでウダウダ言ってんだよ、さっさとやりなよ、としか言いようが無いです。
0.001 を 1000回足すと 1.000になるわけだが、0.001 を 1024倍して整数にしたのを1000回足したら 1024 になると思っているのか?
コストがどーたらとか言ってるが、コスト以前の論外なバグにしか見えないが。
なんか論点がずれてきている気がします。
その原因は、二進化十進数なら話は別 [srad.jp]とあるのを読み飛ばしてるからじゃないですかね?
「1000倍がいいんじゃないの。生データを見るときもそのまま見れるし」というのが、常識というか当然だと思うんですけど。
で、業界のルールは変えることができるですか?できないなら、慣れるのが一番だし、できるなら、さっさとやれ、ってだけです。
大体、そーゆー「ボクの考えた最強の」みたいなヤツは、実現性は皆無ですけど、もしかしたら実現することもあるかもしれませんね。
扱う数値の最小単位が 1/(9^3) だったら九進数の話になるというのがあんたの主張なのか?
違いますよ。誰も言ってもいない話を持ち出されても、困惑するばかりです。
ただ、元が九進数なら、九進数のまま扱ってもいいと思いますよ。
# そんな「業界」があるか疑問ですが(笑)。
十分な長さがある浮動小数点を使うか、(9^3)倍して整数を使えばいい話だろ。
表示の話をすれば、(9^3)倍して整数に表示できるかどうかは、適用分野(業界と言い換えてもいい)によります。元々そう表示されていないのであれば、普通は許されないでしょうね。適用分野のルールを変えようとするより、慣れる方が良いです。さっさと慣れましょう。
浮動小数点で表示、というのは、まあ普通ないでしょう。そんなバイナリを表示されても、普通は読めませんしね。
まあ、通常は十進数の少数として表示するんじゃないですか?
計算の話で言うと、十分な精度が保てるのであれば、整数で扱ってもいいでしょうし、浮動小数点数でもいいですし、固定小数点数で表してもOKです。整数で扱うのと、固定小数点で扱うのは、精度を無視して計算して良いなら、基本的には同じですね。
加えて、コンピュータで計算するなら、普通は二進数で計算するでしょう。その場合に、固定小数点数で計算するなら、2^n倍するでしょうね。
二進化十進数として計算してもいいでしょう。これも単位を変えて整数で扱う方法と、固定小数点で扱う方法があります。COBOLを使うんでなければ、まあやらないと思いますが。
にあるように、定数倍の演算は整数ではなくfloatなので、二進数の整数で1024倍する、ということは考えなくていいと思われます。
浮動小数点数を、固定小数点もしくは1024倍して整数に変換するには、ビットシフトすれば十分で、乗算不要です。一方、1000倍の場合はそうはいきません。当然知ってますよね?
# Cを前提にするなら、そこまで最適化してくれるコンパイラがあるかどうかは知りませんが、Cを持ちだしたのは、私ではありません。
うーんこれは学術とか言語仕様以前の理解力の無さじゃないかって気がする…01のみでどう小数を扱ってるのかとか、わざわざ別の型として用意されていることについて、この人は20年間一切考えたことがなかったんだろうかとものすごく不安になる。
水の存在に気づかない魚のごとく、という感じでしょうか
人間の慣れの力は強力すぎて、"ひと目見てあきらかにおかしい"事にも気づかなくなる。それゆえ、人から見たら「気づかないほうがおかしい」バグの原因にもなる。
// 『ライト、ついてますか?』
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
floatで整数を数えあげちゃいけない@C言語 (スコア:1)
十数年仕事で(アマ時代を入れると20年以上)使っていたのに知らなかったので数日はまった。
バグったコードからエラー原因を簡素化したテストコードは以下。
float型(i)とint型(k)で1ずつ加算していって異なったら
標準エラーに出力。
Re: (スコア:0)
えー常識だと思っていたけどな
計算機イプシロンとかその辺で出てくる話題だと思た
Re: (スコア:0)
計算機的な講義(世代により中学なり大学なり新人研修だったりするだろうけど)でイの一番に習いそうだけど。
Re: (スコア:0)
浮動小数のバックグランドを知らない人間に浮動小数を扱わせてはいけない、の実例。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:2)
Z80用の単精度浮動小数点ライブラリを自分で書いてみたクチだから、どれくらい浮動小数点での加減算が信用できない(精度が足りなくなる)か身に染みて分かる。
今は浮動小数点形式の構造ばかりか、スタックの構造やらポインタ、果てはデータのメモリ内での記憶方法なんぞを知らなくても良い時代になったと思えばいいのかなあ。
Re: (スコア:0)
今はNCデータが割と身近にある仕事してるんだけど、それに慣れてると、小数はぜんぶ1000倍して常に整数で持たせたくなる。モノはでかくても4mくらいだし。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
なぜ1024倍でないのか?
Re: (スコア:0)
CNCだったら普通、アドレス中に小数点がない時に使用する基準単位って設定項目にあるよね。
そこでumを設定しておけば解決するでしょ?
Re: (スコア:0)
0.001mm を 1024倍して何が嬉しい?
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
二進数の整数で扱うなら、1000倍より1024倍の方が計算が簡単なんだけど、知らない?
二進化十進数なら話は別だと思うけど。
Re: (スコア:0)
NCデータがどういう情報かはご存知ですか?
# 相変わらずな御仁だなあ
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
NCデータがどういう情報かはご存知ですか?
しりませんが、それが何か?
通常、浮動小数点で扱ってる数値データなんでしょ?
それを、固定小数点で扱いたい、って話なんでしょ?
何か問題でも?
# 相変わらずな御仁だなあ
そしてキミからは、具体的には何の反論も出てこない、という相変わらずさじゃ無いといいけど。
Re: (スコア:0)
二進数の整数で扱うなら、1000倍より1024倍の方が計算が簡単なんだけど、知らない?
いまどきこんなこと言ってる人いるんだなあw
$ cat test.c
int hoge(int n)
{
return 1024 * n;
}
int piyo(int n)
{
return 1000 * n;
}
$ gcc -O2 -S test.c -o -
.text
.globl hoge
hoge:
movl %ecx, %eax
sall $10,
Re: (スコア:0)
目的と手段の区別がついてないから呆れられてるんだよ。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:2)
NCデータと通常称されるものは、NC工作機械に入力されるテキストデータ。
テキストデータなので浮動小数点も固定小数点もない。
それを読み取ったCNC側が内部でどう扱っているかは別問題としてあるが、
通常外部に公開されていない。
また"G91X1;"と"G91X1.;"が同じ動きをするかどうかは設定次第。
よくある設定だと小数点抜きの場合um単位、小数点をつけるとmm単位の指令と解釈される。
三菱のCNCなら"#1015 cunit プログラム指令単位"の設定内容を確認する。
そもそも別の設定項目でメトリック系とインチ系が切り換えられたりするから、
NCデータ単体では各数値の表す意味は不明。
# 組み込みマクロにSINとかあるけど精度調べたことなかったなあ。
# 計算精度より先に位置決め精度のほうが頭打ちになる機械ばかりだしどう確認しよう。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
これて浮動小数点で得られるものを、固定小数点で表したい、ってはなしだよね。
なら、
とかにしないと。
掛け算しようとすると、固定小数点なので、
乗除のたびこうい計算が必要になるわけだね。
で、どうなった?
Re: (スコア:0)
これて浮動小数点で得られるものを、固定小数点で表したい、ってはなしだよね。
0.001mmをゲタ履かせて整数の1で表したいって話でしょ。アンタとことん馬鹿だね。
Re: (スコア:0)
「知りませんが」で調べもせず、思いつきな押し付けで押し問答。
レスするたびにツッコミは倍増、ツリーのインデントは打ち止め。
ホント相変わらずだね。
Re: (スコア:0)
普通は固定小数点で扱うものを君みたいに浮動少数で表そうとするバカが往々にしているから困るよねって話
Re: (スコア:0)
> return 1024 * (int)n;
ではなくて、
return (int)(1024.0 * n);
ではないの?だとしたら1024でも1000でも計算コストは変わらないよね。
> 掛け算しようとすると、固定小数点なので、
> return ((long)n * (long)m)/1024;
これも、掛け算したらもはや単位は長さではなく面積なので、
長さ 1unit=1/1,000 mm
面積 1unit=1/1,000,000 mm2
と仕様書に書いておけばすむ話。
いずれにしても、僅かな計算機リソースの節減より、
十進にしたときの見やすさを優先するなあ。私だったら。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
0.001mmをゲタ履かせて整数の1で表したいって話でしょ。
それなら、マイクロメートル使いなよ。
できないわけじゃない [srad.jp]みたいだけど、何が問題なの?
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
NCデータと通常称されるものは、NC工作機械に入力されるテキストデータ。
テキストデータなので浮動小数点も固定小数点もない。
つまり、二進化十進数 [wikipedia.org]ってことね。
既に書いた [srad.jp]通り、それなら話は別。
で、機械に食わせる二進化十進数を1000倍して小数点を無くすかずらすかして、何か嬉しいの?
小数点以下の0が9個以上連続する、とかなら判らんでもないけど、3個くらいなら人間が手を加えるにしても、大した話じゃ無いと思うけど。
数点抜きの場合um単位、小数点をつけるとmm単位
「um」って、「μm」のこと?
そっちの業界では、そー書くの?
そもそも、マイクロメートルを扱えるなら、そうすればいいだけじゃん、と思うけど、違うの?
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
ではないの?だとしたら1024でも1000でも計算コストは変わらないよね。
1024 * (int)nだろうと、(int)(1024.0 * n)だろうと、1024倍と1000倍でコストは変わらないね。
実際、どちらの場合も、コンパイラが吐くニーモニックのステップ数は同じになる。
ただし、掛算とビットシフトが同じコストと考えるならば、だけどね。
実際には同じではないので、コンパイラも1024倍の時は、掛算命令でなくビットシフト命令を吐くわけだけど。
これも、掛け算したらもはや単位は長さではなく面積なので、
長さ 1unit=1/1,000 mm
面積 1unit=1/1,000,000 mm2
と仕様書に書いておけばすむ話。
そんなことで済むなら、そもそも#3069125 [srad.jp]は何だったのか、って話になっちゃうね。
それにもし、そうしたいのであれば、普通「長さ 1unit=1μm」だよね。
マイクロメートル、学校で習ったよね?
面積に至っては、そんなに0を並べちゃ、残念ながら見やすいとは言えなくなっちゃうね。
もし、そんに0が並んでも見やすいって言い張るのなら、小数点以下に2つゼロが並ぶのも問題無い、ってことになって、1000倍する意味がなくなるね。
そもそも、機械に食わせるデータに、見やすさなんか関係あるの?
もし、機械がmmしか扱えないとしても、適切なフィルタ書いてやれば済むんじゃね?
その程度のスクリプト、キミにだって書けるでしょ?
Re: (スコア:0)
えっと、IA-32命令 [intel.co.jp]で恐縮ですが、1024倍のほうは 0.5+4に対して、1000倍は14のレイテンシってことでいいのかな?
たいぶ差が縮まったとはいえ、まだ3倍ほど"1024 * n"のほうが簡単だよね。
Re: (スコア:0)
> コンパイラも1024倍の時は、掛算命令でなくビットシフト命令を吐く
(int)(1024.0 * n)って、ビットシフトで計算するんですか?自分のところのVisualStudioではどちらもfmul命令に変換されたんですが。
> マイクロメートル、学校で習ったよね?
業界によりますが、長さをmmで扱うのが当然のところでは、1000mmを単純に1mと略さないのと同じ程度には、0.001mmを単純に1μmと書かないところがあります。
> そもそも、機械に食わせるデータに、見やすさなんか関係あるの?
思った結果にならなかったときに、生データをその場で当たらなければならないことは往々にしてるんですよ。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
# IEEE754脳のまぜっかえし
Re: (スコア:0)
floatの値から指数部を取り出して10を足し、floatの取りうる指数の範囲を超えていないかを判定、超えていなければfloatの値の指数部を書き換え、超えていれば無限大(指数部を255、仮数部を0)に書き換え、という手順になると思うけど、浮動小数点数が扱えるプロセッサなら素直に1024.0倍した方が早いと思うよ。
Re: (スコア:0)
「簡単」をスループットかなんかと勘違いしてる人?
Re: (スコア:0)
えっと、IA-32命令 [intel.co.jp]で恐縮ですが、1024倍のほうは 0.5+4に対して、1000倍は14のレイテンシってことでいいのかな?
いまどき「各表には、Intel Pentium 4 プロセッサに固有のデータを記載した。」なんて書かれてるドキュメントの数値を挙げてドヤ顔とは恐れ入ります。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
(int)(1024.0 * n)って、ビットシフトで計算するんですか?
当然しませんが、そーゆー意味じゃないです。
#3069313 [srad.jp]を受けた発言です。
業界によりますが、長さをmmで扱うのが当然のところでは、1000mmを単純に1mと略さないのと同じ程度には、0.001mmを単純に1μmと書かないところがあります。
そーゆー業界に身を置くなら、慣れるのが吉。
業界を変えるのは超困難だけど、自分を変えることはできるので。
0が二つ三つ程度の話ならなおさら。
でも、「1unit=1/1,000mm」と書くのはokって話なんだよね?
キミに文句を言ってもしかたないけど、ミョーな業界ルールだねぇ。
ところで、私は機械可読なデータの話のつもりだったんだけど、設計図とかの話にズレてる気がする。
気のせいですか?
それとも、データの中で「1unit=1/1,000mm」とかって宣言可能って話?
だったら、最初 [srad.jp]からそれで良かったのでは?
思った結果にならなかったときに、生データをその場で当たらなければならないことは往々にしてるんですよ。
どーしても慣れない、ってことなら、単位を変換するスクリプト書けばいんじゃね?
機械可読なデータなら難しくは無いでしょ。
Re: (スコア:0)
この人はどーして恥の上塗りを繰り返すのだろう?
Re: (スコア:0)
なんでこの匿名の臆病者は、無根拠な一口中傷を繰り返すのだろう。
→何度もRyo.Fにコテンパンにノされて悔しいのう悔しいのう、だけど、まともに議論するとまたノされちゃうから(笑)。
Re: (スコア:0)
いまどき「各表には、Intel Pentium 4 プロセッサに固有のデータを記載した。」なんて書かれてるドキュメントの数値を挙げてドヤ顔とは恐れ入ります。
「顧客も自分が使っているCPUと同程度のものを使っているはず」って思い込める環境っていいよね。
何のためにコンパイラがわざわざ2のべき乗の場合はシフト命令を吐くのか、みたいな思いなんていらないもんね。
IA-32命令を挙げたのはそれしか86系CPUで命令毎の情報が見つからなかったからで、「○○以降なら乗算とシフトとは同じ速度で演算できる」っていうのが示せるんだったら出して欲しい。
#仕事ではARMを使っているけど、ダイに入りきらなかったのか乗算器は積んでいない環境なんですよ。
Re: (スコア:0)
「顧客も自分が使っているCPUと同程度のものを使っているはず」って思い込める環境っていいよね。
「いまどきこんなこと言ってる人いるんだなあw」と「いまどき」の話をしてる投稿に対するレスについて何トンチンカンなこと言ってんの?
Re: (スコア:0)
なんでこの匿名の臆病者は、無根拠な一口中傷を繰り返すのだろう。
→何度もRyo.Fにコテンパンにノされて悔しいのう悔しいのう、だけど、まともに議論するとまたノされちゃうから(笑)。
ということにしないと精神の安定が保てない人かな? 傍から見て哀れな人だなとしか。
Re: (スコア:0)
仕事ではARMを使っているけど、ダイに入りきらなかったのか乗算器は積んでいない環境なんですよ。
そんなんで大騒ぎとは技量の低さが窺い知れますがおめでたいですねw
Re: (スコア:0)
IA-32命令を挙げたのはそれしか86系CPUで命令毎の情報が見つからなかったからで、「○○以降なら乗算とシフトとは同じ速度で演算できる」っていうのが示せるんだったら出して欲しい。
「十分に速けりゃ議論として無意味」ということも理解できない頭なのかな?
Re: (スコア:0)
いまどき「各表には、Intel Pentium 4 プロセッサに固有のデータを記載した。」なんて書かれてるドキュメントの数値を挙げてドヤ顔とは恐れ入ります。
「顧客も自分が使っているCPUと同程度のものを使っているはず」って思い込める環境っていいよね。
今時Pentium4ユーザーが顧客ですか? ご愁傷様としか言えないですね。
Re: (スコア:0)
#仕事ではARMを使っているけど、ダイに入りきらなかったのか乗算器は積んでいない環境なんですよ。
ARMはARM2の頃から使ってるけど乗算で苦労した記憶はないなあ。ARMって何使ってんの?
Re: (スコア:0)
#仕事ではARMを使っているけど、ダイに入りきらなかったのか乗算器は積んでいない環境なんですよ。
ARMはARM2の頃から使ってるけど乗算で苦労した記憶はないなあ。ARMって何使ってんの?
古いほうはARM7だったかな?SoCなので更新もなかなかできず両方現役です。ASIC部分が大きくて高速乗算器を諦めたと推定しています。設計者に聞いたわけではないので本当のところは判りませんが、サイズがキツいのは確かですから。
苦労っていうより、単にスケーリングする時のような1000倍でも1024
Re: (スコア:0)
古いほうはARM7だったかな?SoCなので更新もなかなかできず両方現役です。ASIC部分が大きくて高速乗算器を諦めたと推定しています。設計者に聞いたわけではないので本当のところは判りませんが、サイズがキツいのは確かですから。
ARM7? MUL命令やMLA命令は普通に使えた時代ですね。正直言って何言ってんのという感じだけど、それか、レベルの低い職場なんだなあ、としか。
Re: (スコア:0)
MUL命令自体はありますよ。それが高速乗算器を使うか反復乗算器を使うかはSoCにするときの実装しだいってことです。
Re: (スコア:0)
苦労っていうより、単にスケーリングする時のような1000倍でも1024倍でもいいような用途に、何も気にせず"n*1000"って書く奴にがっくりするんですよ。少なくとも、何万回も廻すループで使われないかとかは気にして欲しいし、「後で逆変換でスケーリングした分を除算するかもしれない」とくらいは考慮しておいて欲しいものです。(まあ、大きいほうにスケーリングすることはそう無いと思いますが)
0.001mm を 1000倍して整数の 1 として扱いたいって話について何言ってんの?
Re: (スコア:0)
> 当然しませんが、そーゆー意味じゃないです。
> #3069313を受けた発言です。
1024 * (int)n だと、1.5mmなどを正確に変換することができないので、
(int)(1024.0 * n)を使うことになります。
この場合、1000.0の代わりに1024.0を使う意味がなくなります。
> どーしても慣れない、ってことなら、単位を変換するスクリプト書けばいんじゃね?
印刷された数値列を直接読むって結構ありますよ。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
この場合、1000.0の代わりに1024.0を使う意味がなくなります。
そーでもないんだけどね。
浮動小数点といえども、所詮二進整数の組合せなので。
# コンパイラがそこまで最適化してくれるかは知りませんが。
印刷された数値列を直接読むって結構ありますよ。
スクリプトを噛ました後に印刷すればいいんじゃね?
なんか、「1unit=1/1,000mm」と書くとか、スクリプトを書くとか、慣れるとか、いろいろ手はありそうなのに、できない理由ばかり書いてる気がするね。
Re: (スコア:0)
この場合、1000.0の代わりに1024.0を使う意味がなくなります。
そーでもないんだけどね。
0.001mmを整数の1として扱いたいって話なんだから、1024.0を掛ける意味なんて最初っからないよ。
Re: (スコア:0)
> # コンパイラがそこまで最適化してくれるかは知りませんが。
いやいや、コンパイラが最適化してくれないと意味がないです。
コンパイラが最適化してくれないのでアセンブラで書きました、では
工数もかかるしバグも潜むし可読性が低くて他の人がメンテできないです。
> スクリプトを書くとか、慣れるとか、いろいろ手はありそうなのに、できない理由ばかり書いてる気がするね。
できないことはないですが、私でない他の人が数値を読むときに、
「1024で割ってください」「スクリプトを噛ましてください」なんて仕様書で指定した日には
「○○君の謎仕様」と末代まで祟られることでしょう。自社の後継者のみならず他社からも。
プログラムもデータも、他人が使うもの、という意識で書く必要があると思っています。
プログラミングして3日もたてば、自分ですら他人になることがありますし。
> 「1unit=1/1,000mm」と書くとか
これが単純で最適な解なんじゃないでしょうか。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
自社の後継者のみならず他社からも。
そーゆー業界に居るなら、業界のルールに従って、それに慣れるのが一番です。
たかが0三つくらいの話なんでしょ?
これが単純で最適な解なんじゃないでしょうか。
「自社の後継者のみならず他社」に至るまで、その「最適な解」を受け入れてくれれば、その通りです。
で、実際受け入れてもらえるんですか?
もし、受け入れてもらえないのなら、「最適な解」と言うより、非現実劇な解と言うべきでしょう。
もし、受け入れてもらえるのなら、何をここでウダウダ言ってんだよ、さっさとやりなよ、としか言いようが無いです。
Re: (スコア:0)
0.001 を 1000回足すと 1.000になるわけだが、0.001 を 1024倍して整数にしたのを1000回足したら 1024 になると思っているのか?
コストがどーたらとか言ってるが、コスト以前の論外なバグにしか見えないが。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
なんか論点がずれてきている気がします。
その原因は、二進化十進数なら話は別 [srad.jp]とあるのを読み飛ばしてるからじゃないですかね?
「1000倍がいいんじゃないの。生データを見るときもそのまま見れるし」というのが、常識というか当然だと思うんですけど。
で、業界のルールは変えることができるですか?
できないなら、慣れるのが一番だし、できるなら、さっさとやれ、ってだけです。
大体、そーゆー「ボクの考えた最強の」みたいなヤツは、実現性は皆無ですけど、もしかしたら実現することもあるかもしれませんね。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
扱う数値の最小単位が 1/(9^3) だったら九進数の話になるというのがあんたの主張なのか?
違いますよ。
誰も言ってもいない話を持ち出されても、困惑するばかりです。
ただ、元が九進数なら、九進数のまま扱ってもいいと思いますよ。
# そんな「業界」があるか疑問ですが(笑)。
十分な長さがある浮動小数点を使うか、(9^3)倍して整数を使えばいい話だろ。
表示の話をすれば、(9^3)倍して整数に表示できるかどうかは、適用分野(業界と言い換えてもいい)によります。
元々そう表示されていないのであれば、普通は許されないでしょうね。
適用分野のルールを変えようとするより、慣れる方が良いです。
さっさと慣れましょう。
浮動小数点で表示、というのは、まあ普通ないでしょう。
そんなバイナリを表示されても、普通は読めませんしね。
まあ、通常は十進数の少数として表示するんじゃないですか?
計算の話で言うと、十分な精度が保てるのであれば、整数で扱ってもいいでしょうし、浮動小数点数でもいいですし、固定小数点数で表してもOKです。
整数で扱うのと、固定小数点で扱うのは、精度を無視して計算して良いなら、基本的には同じですね。
加えて、コンピュータで計算するなら、普通は二進数で計算するでしょう。
その場合に、固定小数点数で計算するなら、2^n倍するでしょうね。
二進化十進数として計算してもいいでしょう。
これも単位を変えて整数で扱う方法と、固定小数点で扱う方法があります。
COBOLを使うんでなければ、まあやらないと思いますが。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:1)
にあるように、定数倍の演算は整数ではなくfloatなので、二進数の整数で1024倍する、ということは考えなくていいと思われます。
浮動小数点数を、固定小数点もしくは1024倍して整数に変換するには、ビットシフトすれば十分で、乗算不要です。
一方、1000倍の場合はそうはいきません。
当然知ってますよね?
# Cを前提にするなら、そこまで最適化してくれるコンパイラがあるかどうかは知りませんが、Cを持ちだしたのは、私ではありません。
Re: (スコア:0)
うーんこれは学術とか言語仕様以前の理解力の無さじゃないかって気がする…
01のみでどう小数を扱ってるのかとか、
わざわざ別の型として用意されていることについて、
この人は20年間一切考えたことがなかったんだろうかとものすごく不安になる。
Re:floatで整数を数えあげちゃいけない@C言語 (スコア:2)
水の存在に気づかない魚のごとく、という感じでしょうか
人間の慣れの力は強力すぎて、"ひと目見てあきらかにおかしい"事にも気づかなくなる。
それゆえ、人から見たら「気づかないほうがおかしい」バグの原因にもなる。
// 『ライト、ついてますか?』