皆さんどうも、訳のわからない平均順位を書いてしまいまして、すみませんでした、
この度の平均順位の件ですが同順位が生じる場合は
Ex：
2と3位の対象が同じ値ならば，これらの対象に平均順位 (2+3)/2=2.5位を与える。
これが正解と言いますか、私の望むものですよって
επιστημηさん、たいちうさん、yoh2さんのご指摘はごもっともです。
それからyoh2さん
STLの説明ありがとうございます、平均順位の件とあわせてもう一回見直します。

> 2と3位の対象が同じ値ならば，これらの対象に平均順位 (2+3)/2=2.5位を与える。

だったら2,3,4位の対象が同じなら　(2+3+4)/3 = 3位 でしょ?
同様に2位が4人いたら (2+3+4+5)/4 = 3.5位ですよね?
だとすると↓コレはマチガイちゃいます?
> double result = greater_items + 1.0 + (1.0 / (double)num_same_vals);

>だったら2,3,4位の対象が同じなら　(2+3+4)/3 = 3位 でしょ?
>同様に2位が4人いたら (2+3+4+5)/4 = 3.5位ですよね?
その通りです
>だとすると↓コレはマチガイちゃいます?
はい大マチガイです、嘘を書いてしまいましたm(。－＿－。)m ゴメンナサイ

そんじゃx位がn人いたらその平均順位は
(2x+n-1)/2 ですわな。
てことは小数点以下は0または0.5だから、
順位の2倍を納めておくことにすればdoubleである必要はありませんな。

> てことは小数点以下は0または0.5だから、
> 順位の2倍を納めておくことにすればdoubleである必要はありませんな。

ですが、わざわざ2倍にしてまで整数型にする必要もないですよね。
今回の例で整数型で持つ大きなメリットってありましたっけ？

0.5きざみの結果になるということを書いているだけですか？

επιστημη さんたいちうさんお世話になります。
ソイレントグリーンです。
向学のために、double型以外の表記（整数型？）で0.5という数値を表す手法?を
教えて頂ければ幸いです、そのことにより多少なりとも演算速度が
向上すればなおよろし
是非是非ご教示願います。

> 向学のために、double型以外の表記（整数型？）で0.5という数値を表す手法?を
> 教えて頂ければ幸いです、そのことにより多少なりとも演算速度が
> 向上すればなおよろし

例） >同様に2位が4人いたら (2+3+4+5)/4 = 3.5位ですよね?

int x = 2, n = 4;
int juniNoNibai = (2 * x + n - 1) / 2;
double juni = juniNoNibai / 2.0;

私が思い描いたのはこの方法です。手法というほどのことではありません。
あえてメリットを上げれば、私が思いつく限りでは

・double型と比較してメモリの節約になる。juniNoNibaiがchar型でも良い場合だと特
に。
・整数型のほうが演算が速い。
・小数点以下の数値を誤差なく表現できる。
（IEEEでは元々0.5単位を誤差なく表せるけど、誤差がないことを明示的に示せる）

ま、メモリや演算速度の違いが意味を持つことはまずないでしょう。

> double型以外の表記（整数型？）で0.5という数値を表す手法?を教えて頂ければ幸いです、

...僕なんか難しいこと言うてるでしょうか?

x位がn人いたらその平均順位は(2x+n-1)/2 ですから、平均順位の2倍は 2x+n-1、
これならintだからintの集合に放り込んでおいて、表示のときに2で割ります。
手法もヘッタクレもないんですけど。

小数点一位までしか必要ないなら全部10倍してintで扱うのと同じリクツです。

その時にしなくて良い処理は後でまとめてしまうと言う考え方って
ロジック組む時は割りと自然にやっているような気がしますね。
なので、επιστημηさんの話も特に違和感は覚えませんでした。
貧乏性と言ってしまうとそれまでですけれど、なるべく軽くしようと
思ったらdouble演算はやはりint演算より重いわけですし、
軽いに越した事は無いかな。
あと、doubleを使った時に付きまとう表現上避けられない誤差と言うのも
回避できますからねぇ。

個人的にはdoubleを使わずに済むなら使わない方がベターを考えているので
その程度の話ではないかなと。

あとは、プログラム上での扱いやすさとのトレードオフでしょうか。

ちょんぼを訂正。判ると思うけど。

× int juniNoNibai = (2 * x + n - 1) / 2;
○ int juniNoNibai = (2 * x + n - 1);

皆さんお世話になります。
επιστημη さん
>...僕なんか難しいこと言うてるでしょうか?
επιστημη さんなので、STLとシフト演算のロジックを絡め目が点になるような
種明かしがあるかと期待していたんですがww

PAITOさん
>貧乏性と言ってしまうとそれまでですけれど、なるべく軽くしようと
>思ったらdouble演算はやはりint演算より重いわけですし、
>軽いに越した事は無いかな。
そう思います、常々疑問に思うことなのですが、情報処理関連の資格試験に出てくる頻度
の高い、シフトを利用した演算方法とかって、日常業務で使うライブラリィでは余り目に
しないのがなんか不思議に感じていました、まぁ私の場合、核反応のシュミレーションと
かやってないので関心が無いからかもしれませんがww

>たいちうさん
OKです、ありがとう

ってなとこですかね、あとSTLの辺りでダメだしがあれば、お願い致します。

シフト演算に関しては可読性の方の問題かなと
私の場合、組込み系とか とにかくパフォーマンス重視のソフトだと
最終的に少しでも早くする為にシフト演算を入れたりしますけれど、
PC上で組む場合はその部分の速度アップよりも可読性の方を取る
場合が多いです。
この辺は結局トレードオフの関係になるのでそのソフトが何処に重きを
おいているかによると思います。
実際の話、携帯電話で動くようなソフトを開発している時は
シフト演算を入れたりしてましたよ。そのくらいパフォーマンスに
重きを置いていましたから。但し、その分だけ可読性は落ちてますね。
チューニングに走るとどうしても可読性が落ちるのは致し方ないかと。

今日はPAITOさん
>実際の話、携帯電話で動くようなソフトを開発している時は
>シフト演算を入れたりしてましたよ。
そうなんですか、その様な分野ではいかされているんですね。
それから、みなさんどうもありがとうございました
お陰さまでまで解決にいたりました。