パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

スラドに聞け:いま使っている言語の仕様、把握している?」記事へのコメント

  • 十数年仕事で(アマ時代を入れると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;
    }

    • by Anonymous Coward

      えー常識だと思っていたけどな
      計算機イプシロンとかその辺で出てくる話題だと思た

      • by Anonymous Coward

        計算機的な講義(世代により中学なり大学なり新人研修だったりするだろうけど)でイの一番に習いそうだけど。

        • by Anonymous Coward

          浮動小数のバックグランドを知らない人間に浮動小数を扱わせてはいけない、の実例。

          • Z80用の単精度浮動小数点ライブラリを自分で書いてみたクチだから、どれくらい浮動小数点での加減算が信用できない(精度が足りなくなる)か身に染みて分かる。
            今は浮動小数点形式の構造ばかりか、スタックの構造やらポインタ、果てはデータのメモリ内での記憶方法なんぞを知らなくても良い時代になったと思えばいいのかなあ。

            • by Anonymous Coward

              今はNCデータが割と身近にある仕事してるんだけど、それに慣れてると、小数はぜんぶ1000倍して常に整数で持たせたくなる。モノはでかくても4mくらいだし。

              • なぜ1024倍でないのか?

              • by Anonymous Coward

                0.001mm を 1024倍して何が嬉しい?

              • 二進数の整数で扱うなら、1000倍より1024倍の方が計算が簡単なんだけど、知らない?

                二進化十進数なら話は別だと思うけど。

              • by Anonymous Coward on 2016年08月24日 22時57分 (#3069313)

                二進数の整数で扱うなら、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, %eax
                                ret
                                .globl piyo
                piyo:
                                imull $1000, %ecx, %eax
                                ret

                親コメント
              • これて浮動小数点で得られるものを、固定小数点で表したい、ってはなしだよね。
                なら、

                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;
                }

                乗除のたびこうい計算が必要になるわけだね。

                で、どうなった?

                親コメント
              • by Anonymous Coward

                これて浮動小数点で得られるものを、固定小数点で表したい、ってはなしだよね。

                0.001mmをゲタ履かせて整数の1で表したいって話でしょ。アンタとことん馬鹿だね。

              • by Anonymous Coward
                違うよ
                普通は固定小数点で扱うものを君みたいに浮動少数で表そうとするバカが往々にしているから困るよねって話
              • by Anonymous Coward

                > 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]みたいだけど、何が問題なの?

                親コメント
              • ではないの?だとしたら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しか扱えないとしても、適切なフィルタ書いてやれば済むんじゃね?
                その程度のスクリプト、キミにだって書けるでしょ?

                親コメント
              • by Anonymous Coward

                えっと、IA-32命令 [intel.co.jp]で恐縮ですが、1024倍のほうは 0.5+4に対して、1000倍は14のレイテンシってことでいいのかな?
                たいぶ差が縮まったとはいえ、まだ3倍ほど"1024 * n"のほうが簡単だよね。

              • by Anonymous Coward

                > コンパイラも1024倍の時は、掛算命令でなくビットシフト命令を吐く

                (int)(1024.0 * n)って、ビットシフトで計算するんですか?自分のところのVisualStudioではどちらもfmul命令に変換されたんですが。

                > マイクロメートル、学校で習ったよね?

                業界によりますが、長さをmmで扱うのが当然のところでは、1000mmを単純に1mと略さないのと同じ程度には、0.001mmを単純に1μmと書かないところがあります。

                > そもそも、機械に食わせるデータに、見やすさなんか関係あるの?

                思った結果にならなかったときに、生データをその場で当たらなければならないことは往々にしてるんですよ。

              • intの1024倍はビットシフトですが、floatの1024.0倍は(型変換を除けば)整数の足し算で表現できますよねっ
                # IEEE754脳のまぜっかえし
                親コメント
              • by Anonymous Coward

                floatの値から指数部を取り出して10を足し、floatの取りうる指数の範囲を超えていないかを判定、超えていなければfloatの値の指数部を書き換え、超えていれば無限大(指数部を255、仮数部を0)に書き換え、という手順になると思うけど、浮動小数点数が扱えるプロセッサなら素直に1024.0倍した方が早いと思うよ。

              • by Anonymous Coward

                「簡単」をスループットかなんかと勘違いしてる人?

              • by Anonymous Coward

                えっと、IA-32命令 [intel.co.jp]で恐縮ですが、1024倍のほうは 0.5+4に対して、1000倍は14のレイテンシってことでいいのかな?

                いまどき「各表には、Intel Pentium 4 プロセッサに固有のデータを記載した。」なんて書かれてるドキュメントの数値を挙げてドヤ顔とは恐れ入ります。

              • (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]からそれで良かったのでは?

                思った結果にならなかったときに、生データをその場で当たらなければならないことは往々にしてるんですよ。

                どーしても慣れない、ってことなら、単位を変換するスクリプト書けばいんじゃね?
                機械可読なデータなら難しくは無いでしょ。

                親コメント
              • by Anonymous Coward

                この人はどーして恥の上塗りを繰り返すのだろう?

              • by Anonymous Coward

                なんでこの匿名の臆病者は、無根拠な一口中傷を繰り返すのだろう。
                →何度もRyo.Fにコテンパンにノされて悔しいのう悔しいのう、だけど、まともに議論するとまたノされちゃうから(笑)。

              • by Anonymous Coward

                いまどき「各表には、Intel Pentium 4 プロセッサに固有のデータを記載した。」なんて書かれてるドキュメントの数値を挙げてドヤ顔とは恐れ入ります。

                「顧客も自分が使っているCPUと同程度のものを使っているはず」って思い込める環境っていいよね。
                何のためにコンパイラがわざわざ2のべき乗の場合はシフト命令を吐くのか、みたいな思いなんていらないもんね。
                IA-32命令を挙げたのはそれしか86系CPUで命令毎の情報が見つからなかったからで、「○○以降なら乗算とシフトとは同じ速度で演算できる」っていうのが示せるんだったら出して欲しい。

                #仕事ではARMを使っているけど、ダイに入りきらなかったのか乗算器は積んでいない環境なんですよ。

              • by Anonymous Coward

                「顧客も自分が使っているCPUと同程度のものを使っているはず」って思い込める環境っていいよね。

                「いまどきこんなこと言ってる人いるんだなあw」と「いまどき」の話をしてる投稿に対するレスについて何トンチンカンなこと言ってんの?

              • by Anonymous Coward

                なんでこの匿名の臆病者は、無根拠な一口中傷を繰り返すのだろう。
                →何度もRyo.Fにコテンパンにノされて悔しいのう悔しいのう、だけど、まともに議論するとまたノされちゃうから(笑)。

                ということにしないと精神の安定が保てない人かな? 傍から見て哀れな人だなとしか。

              • by Anonymous Coward

                仕事ではARMを使っているけど、ダイに入りきらなかったのか乗算器は積んでいない環境なんですよ。

                そんなんで大騒ぎとは技量の低さが窺い知れますがおめでたいですねw

              • by Anonymous Coward

                IA-32命令を挙げたのはそれしか86系CPUで命令毎の情報が見つからなかったからで、「○○以降なら乗算とシフトとは同じ速度で演算できる」っていうのが示せるんだったら出して欲しい。

                「十分に速けりゃ議論として無意味」ということも理解できない頭なのかな?

              • by Anonymous Coward

                いまどき「各表には、Intel Pentium 4 プロセッサに固有のデータを記載した。」なんて書かれてるドキュメントの数値を挙げてドヤ顔とは恐れ入ります。

                「顧客も自分が使っているCPUと同程度のものを使っているはず」って思い込める環境っていいよね。

                今時Pentium4ユーザーが顧客ですか? ご愁傷様としか言えないですね。

              • by Anonymous Coward

                #仕事ではARMを使っているけど、ダイに入りきらなかったのか乗算器は積んでいない環境なんですよ。

                ARMはARM2の頃から使ってるけど乗算で苦労した記憶はないなあ。ARMって何使ってんの?

              • by Anonymous Coward

                #仕事ではARMを使っているけど、ダイに入りきらなかったのか乗算器は積んでいない環境なんですよ。

                ARMはARM2の頃から使ってるけど乗算で苦労した記憶はないなあ。ARMって何使ってんの?

                古いほうはARM7だったかな?SoCなので更新もなかなかできず両方現役です。ASIC部分が大きくて高速乗算器を諦めたと推定しています。設計者に聞いたわけではないので本当のところは判りませんが、サイズがキツいのは確かですから。
                苦労っていうより、単にスケーリングする時のような1000倍でも1024

              • by Anonymous Coward

                古いほうはARM7だったかな?SoCなので更新もなかなかできず両方現役です。ASIC部分が大きくて高速乗算器を諦めたと推定しています。設計者に聞いたわけではないので本当のところは判りませんが、サイズがキツいのは確かですから。

                ARM7? MUL命令やMLA命令は普通に使えた時代ですね。正直言って何言ってんのという感じだけど、それか、レベルの低い職場なんだなあ、としか。

              • by Anonymous Coward

                MUL命令自体はありますよ。それが高速乗算器を使うか反復乗算器を使うかはSoCにするときの実装しだいってことです。

              • by Anonymous Coward

                苦労っていうより、単にスケーリングする時のような1000倍でも1024倍でもいいような用途に、何も気にせず"n*1000"って書く奴にがっくりするんですよ。少なくとも、何万回も廻すループで使われないかとかは気にして欲しいし、「後で逆変換でスケーリングした分を除算するかもしれない」とくらいは考慮しておいて欲しいものです。(まあ、大きいほうにスケーリングすることはそう無いと思いますが)

                0.001mm を 1000倍して整数の 1 として扱いたいって話について何言ってんの?

              • by Anonymous Coward

                > 当然しませんが、そーゆー意味じゃないです。
                > #3069313を受けた発言です。

                1024 * (int)n だと、1.5mmなどを正確に変換することができないので、
                (int)(1024.0 * n)を使うことになります。
                この場合、1000.0の代わりに1024.0を使う意味がなくなります。

                > どーしても慣れない、ってことなら、単位を変換するスクリプト書けばいんじゃね?

                印刷された数値列を直接読むって結構ありますよ。

              • この場合、1000.0の代わりに1024.0を使う意味がなくなります。

                そーでもないんだけどね。
                浮動小数点といえども、所詮二進整数の組合せなので。
                # コンパイラがそこまで最適化してくれるかは知りませんが。

                印刷された数値列を直接読むって結構ありますよ。

                スクリプトを噛ました後に印刷すればいいんじゃね?

                なんか、「1unit=1/1,000mm」と書くとか、スクリプトを書くとか、慣れるとか、いろいろ手はありそうなのに、できない理由ばかり書いてる気がするね。

                親コメント
              • by Anonymous Coward

                この場合、1000.0の代わりに1024.0を使う意味がなくなります。

                そーでもないんだけどね。

                0.001mmを整数の1として扱いたいって話なんだから、1024.0を掛ける意味なんて最初っからないよ。

              • by Anonymous Coward

                > # コンパイラがそこまで最適化してくれるかは知りませんが。

                いやいや、コンパイラが最適化してくれないと意味がないです。
                コンパイラが最適化してくれないのでアセンブラで書きました、では
                工数もかかるしバグも潜むし可読性が低くて他の人がメンテできないです。

                > スクリプトを書くとか、慣れるとか、いろいろ手はありそうなのに、できない理由ばかり書いてる気がするね。

                できないことはないですが、私でない他の人が数値を読むときに、
                「1024で割ってください」「スクリプトを噛ましてください」なんて仕様書で指定した日には
                「○○君の謎仕様」と末代まで祟られることでしょう。自社の後継者のみならず他社からも。

                プログラムもデータも、他人が使うもの、という意識で書く必要があると思っています。
                プログラミングして3日もたてば、自分ですら他人になることがありますし。

                > 「1unit=1/1,000mm」と書くとか

                これが単純で最適な解なんじゃないでしょうか。

              • 自社の後継者のみならず他社からも。

                そーゆー業界に居るなら、業界のルールに従って、それに慣れるのが一番です。
                たかが0三つくらいの話なんでしょ?

                これが単純で最適な解なんじゃないでしょうか。

                「自社の後継者のみならず他社」に至るまで、その「最適な解」を受け入れてくれれば、その通りです。
                で、実際受け入れてもらえるんですか?
                もし、受け入れてもらえないのなら、「最適な解」と言うより、非現実劇な解と言うべきでしょう。

                もし、受け入れてもらえるのなら、何をここでウダウダ言ってんだよ、さっさとやりなよ、としか言いようが無いです。

                親コメント
              • by Anonymous Coward

                なんか論点がずれてきている気がします。

                #3069049(AC) 浮動小数点変数で予期しないエラーに嵌った
                #3069125(AC) 小数はぜんぶ1000倍して常に整数で持たせたくなる。桁あふれの心配はない
                #3069222(Ryo.F) なぜ1024倍でないのか?
                #3070132(私) (int)(1024.0 * n)はどちらもfmul命令
                #3071599(私) 1000.0の代わりに1024.0を使う意味がなくなります
                #3072255(私) 「1024で割ってください」は謎仕様

                「小数は定数倍して整数の変数で持たせたい。精度や桁あふれが問題なく、予期しないエラーも起きにくい」という要望に対して、
                「1000倍にしましょうか、1024倍

              • なんか論点がずれてきている気がします。

                その原因は、二進化十進数なら話は別 [srad.jp]とあるのを読み飛ばしてるからじゃないですかね?

                「1000倍がいいんじゃないの。生データを見るときもそのまま見れるし」というのが、常識というか当然だと思うんですけど。

                で、業界のルールは変えることができるですか?
                できないなら、慣れるのが一番だし、できるなら、さっさとやれ、ってだけです。

                大体、そーゆー「ボクの考えた最強の」みたいなヤツは、実現性は皆無ですけど、もしかしたら実現することもあるかもしれませんね。

                親コメント
              • by Anonymous Coward

                そこで二進化十進数を持ち出すところがあんたの無知を証明しているね。扱う数値の最小単位が 1/(9^3) だったら九進数の話になるというのがあんたの主張なのか?十分な長さがある浮動小数点を使うか、(9^3)倍して整数を使えばいい話だろ。

                扱う数値の最小単位が決まっているからそれを前提にすることで誤差を抑えながら計算ができるという話は、二進化十進数とは全く別の話だよ。

                まあ、return 1024 * (int)n; とか書いた人に何を期待しても無駄という当然の結論ではあるが。

              • by Anonymous Coward

                > 二進数の整数で扱うなら、1000倍より1024倍の方が計算が簡単

                の部分ですか?

                #3069558 return (int)(1024.0 * n); ではないの?

                にあるように、定数倍の演算は整数ではなくfloatなので、二進数の整数で1024倍する、ということは考えなくていいと思われます。

                > で、業界のルールは変えることができるですか?

                そもそもが

                #3069049(AC) 浮動小数点変数で予期しないエラーに嵌った
                #3069125(AC) 小数はぜんぶ1000倍して常に整数で持たせたくなる。桁あふれの心配はない
                #3069222(Ryo.F) なぜ1024倍でないのか?

                で始まっているので、ここでは「x倍で整数化」という業界ルール変更を受け入れられるかどうか、は考えなくてよく、
                x=1000にするか1024にするかを計算コストや利便性等を考慮して選択、
                という前提ととらえています。

              • 扱う数値の最小単位が 1/(9^3) だったら九進数の話になるというのがあんたの主張なのか?

                違いますよ。
                誰も言ってもいない話を持ち出されても、困惑するばかりです。

                ただ、元が九進数なら、九進数のまま扱ってもいいと思いますよ。

                # そんな「業界」があるか疑問ですが(笑)。

                十分な長さがある浮動小数点を使うか、(9^3)倍して整数を使えばいい話だろ。

                表示の話をすれば、(9^3)倍して整数に表示できるかどうかは、適用分野(業界と言い換えてもいい)によります。
                元々そう表示されていないのであれば、普通は許されないでしょうね。
                適用分野のルールを変えようとするより、慣れる方が良いです。
                さっさと慣れましょう。

                浮動小数点で表示、というのは、まあ普通ないでしょう。
                そんなバイナリを表示されても、普通は読めませんしね。

                まあ、通常は十進数の少数として表示するんじゃないですか?

                計算の話で言うと、十分な精度が保てるのであれば、整数で扱ってもいいでしょうし、浮動小数点数でもいいですし、固定小数点数で表してもOKです。
                整数で扱うのと、固定小数点で扱うのは、精度を無視して計算して良いなら、基本的には同じですね。

                加えて、コンピュータで計算するなら、普通は二進数で計算するでしょう。
                その場合に、固定小数点数で計算するなら、2^n倍するでしょうね。

                二進化十進数として計算してもいいでしょう。
                これも単位を変えて整数で扱う方法と、固定小数点で扱う方法があります。
                COBOLを使うんでなければ、まあやらないと思いますが。

                親コメント
              • にあるように、定数倍の演算は整数ではなくfloatなので、二進数の整数で1024倍する、ということは考えなくていいと思われます。

                浮動小数点数を、固定小数点もしくは1024倍して整数に変換するには、ビットシフトすれば十分で、乗算不要です。
                一方、1000倍の場合はそうはいきません。
                当然知ってますよね?

                # Cを前提にするなら、そこまで最適化してくれるコンパイラがあるかどうかは知りませんが、Cを持ちだしたのは、私ではありません。

                親コメント
              • by Anonymous Coward

                C言語が前提とは考えていませんが、
                自分だけで作って自分だけで利用して捨てるものでない業務目的のプログラムなら、
                アセンブラは無しだと思います。
                可読性、メンテナンス、バグを出さないこと、引き継ぎ、他機種への移植の可能性、
                また当該部分の実行回数が多くないこと(自然単位系と内部単位系のインタフェース部分のみ)からくる計算コストのごくわずかしかない削減と手間のバランスを考慮すると
                高級言語の利用は前提と言えるでしょう。
                その上で、浮動小数点数から1024倍と整数部分取り出しをシフト演算に最適化するメジャーな高級言語があれば、
                また、#3069125がそのような言語を使っているといえるのならば、そうなのでしょうね。

Stay hungry, Stay foolish. -- Steven Paul Jobs

処理中...