C++相談室 part156

**デフォルトの名無しさん** · 2021/05/19(水) 10:55:13.24

前スレ
C++相談室 part155
https://mevius.5ch.net/test/read.cgi/tech/1616555235/

**デフォルトの名無しさん** · 2021/07/12(月) 10:01:12.57

>>692
多倍長整数でどうやるんでしょうか？

>>693
確かに、改めて n 乗する意味なかったですね

>>694
後出しですみませんが、遅くて良いから短くて誤判定のないのが望ましいです

**デフォルトの名無しさん** · 2021/07/12(月) 10:11:36.07

>>693
y の小数部分が 0.9999999998 とかだと失敗しますよね？
iy = round(y) として abs(y - iy) < 1e-12 で判定しようかなと思います

**デフォルトの名無しさん** · 2021/07/12(月) 10:22:44.45

>>690
最後だけ認識おかしい、唯一ではない

**デフォルトの名無しさん** · 2021/07/12(月) 12:24:08.89

>>697 他に何かあるなら教えて。

**デフォルトの名無しさん** · 2021/07/12(月) 12:35:12.60

>>695
boost 多倍長整数冪乗で検索。
書くのは色々と面倒だから、解説ページ読め。boost はpowも対応している。

**デフォルトの名無しさん** · 2021/07/12(月) 17:41:28.01

>>698
わかりやすいとこで言えばStrict Aliasing Rulesとか
型が違おうが何だろうが、本来一度書いたものが、次別のポインタ（or参照）を読む時同じ場所だったら、さっき書いた値になってなければならない
・・・んだが、そんなこと守ってたら最適化なんかほとんど出来ないだろ
他にC++の仕様に規定されてなくとも各コンパイラは色々やってる
大抵は問題ないが、ごくまれに意図した挙動になってくれなくて困ることはあるぞ

**デフォルトの名無しさん** · 2021/07/12(月) 18:26:33.31

>>691
>>692
アホな文系の質問にアホな文系が答えるスレ？

どの値が与えられて、その値の条件（範囲、符号、...）は何か
環境は仮定していいのか、(C++の規格範囲内の)すべての環境で正しく動作する必要があるのか
コードに求めるものは何か？（可読性、速度、...）
をはじめからすべて書きなさい

**デフォルトの名無しさん** · 2021/07/12(月) 18:32:42.82

ごく一般的なPC環境で、与えられた整数がintの範囲であれば、
(ある程度の判別を行ったあと)普通に四捨五入で良い

n乗根の候補を求めたあと整数領域でn乗してもいいし
元の数を（割り切れる判別をしながら）候補で割っていってもいいし
与えられた整数が32bitの範囲であれば、2分検索やリニア検索してもいい

アホな文系が理解できる範囲で自分の頭で考えて自分の責任でコードを書きなさい

**デフォルトの名無しさん** · 2021/07/12(月) 19:47:47.34

>>701
そういった諸々の細かい調整を諦めて多倍長整数を使う、ということだよ。
そもそもの要件（n乗判定）でpowを使う乱暴さを考慮すれば、面倒な部分を処理してくれるライブラリを使用するのは有力な選択肢。それを無視して「アホな文系」とは言ってくれる。

ご高説を宣ってくれた後にどんな素晴らしい解説を>>702でしてくれるのかと思ったら、n乗判定にわざわざ割り算を持ち込んだり、対数にも触れずに検索にフッ飛ぶ滅裂ぶり。>>601が混乱するのを笑うために書き込んでいるとしか思えん。

文系､文系と馬鹿にする人間は、人間と会話のできない発達障害が多いのかね？

**デフォルトの名無しさん** · 2021/07/12(月) 20:05:16.58

ヒント
多倍長整数を使っても何も解決しない

**デフォルトの名無しさん** · 2021/07/12(月) 20:29:50.05

>>704
なんで解決しないのか解説してもらいたいねぇ。

**デフォルトの名無しさん** · 2021/07/12(月) 20:34:24.53

累乗根は浮動小数点の演算だからだよ

**デフォルトの名無しさん** · 2021/07/12(月) 20:52:49.79

いや累乗して整数同士で比較すりゃええやん

**デフォルトの名無しさん** · 2021/07/12(月) 21:00:52.19

n乗数判定は明らかに整数論の問題なんですがそれは

なお一番簡単な平方数判定でもNPなんで（一発でポンと答えが出る楽な方法は多分）ないです

**デフォルトの名無しさん** · 2021/07/12(月) 21:13:08.21

因数分解してハッシュで数えて全部6の倍数なら何かの6乗なんじゃないの

4096=2^12

h{2}→12個

12は6の倍数なので何かの6乗

3*7*3*7*3*7*3*7*3*7*3*7 = 85766121　だと

h{3}→6個
h{7}→6個

両方6だから何かの6乗

**デフォルトの名無しさん** · 2021/07/12(月) 21:14:32.03

累乗根の演算で引数の逆数をどうやって整数で表現するの？
>>691の例で言えば、n=6なら6乗根(=1/6乗)の計算を行なっている

**デフォルトの名無しさん** · 2021/07/12(月) 21:21:35.61

>>700
未定義動作となる場合はそもそも「意味」が定まらないので「意味を変える最適化」とかいう話にならないよ。

**デフォルトの名無しさん** · 2021/07/12(月) 22:14:22.14

ひさしぶりにみると
すごく
カオスなスレッド

**デフォルトの名無しさん** · 2021/07/12(月) 22:33:30.20

>>709
>>702 が言ってるのがそれじゃ無い？
> 元の数を（割り切れる判別をしながら）候補で割っていってもいいし
2で割り切れなくなるまで割り、割った回数がnの倍数で無ければNG
3で割り切れなくなるまで割り、割った回数がnの倍数で無ければNG
を繰り返すって事かと（多分）

**デフォルトの名無しさん** · 2021/07/12(月) 22:51:10.50

数値計算としては>>693,696がもっとも正統派の方法だよ
素直に累乗根を求めて誤差を評価して判定する
わざわざトリッキーな手段を採る必要性は無い

**デフォルトの名無しさん** · 2021/07/12(月) 23:38:51.54

>710
「累乗の判定」と「累乗根の演算」をごっちゃにしている？

「累乗根の演算」はあくまで「累乗の判定」の候補となる整数を
見つける手段の一つで、必ずしも必要ではない。
極端な話、候補となる整数を2から順番に数えて判定しても良い。
まあ、「できるだけコードを簡単に」という話なら素直に累乗根を
使ったほうが良いけど、その時でも(累乗/累乗根計算の誤差の問題から)
「累乗の判定」を行う必要がある。

>693 >714
よくよく>691を見たら、本質的にはintによる切り捨ての問題だな。
0.5を足して実質的に四捨五入になるようにすりゃいい。

>691の計算を下敷きにするなら
int y = pow(x, 1.0/n)+0.5;//<-これ重要
int z = pow(y, n)+0.5;//<-これも重要だと思う
として、
x == z
を判定すりゃいいんじゃね？試してないけど。

**デフォルトの名無しさん** · 2021/07/12(月) 23:48:10.49

長々と書いてやっと質問者と同レベルに追いついた
アホな回答者

全部>>702に書いてるし

**デフォルトの名無しさん** · 2021/07/12(月) 23:51:52.50

ある整数やnがマイナスの場合に言及してるのは>>701だけ
質問者も他の回答者もそこまで頭がまわらない

**デフォルトの名無しさん** · 2021/07/12(月) 23:57:47.66

そっかあ
あたまがいいんだね

**デフォルトの名無しさん** · 2021/07/13(火) 00:17:32.29

>>699
いや、
整数 x、y、n が与えられたときに x が y の n 乗であるかどうか判定する
ではなく、
整数 x、n が与えられたときに x が y の n 乗となるような整数 y があるかどうか判定する
ですよ？

多倍長整数なんて出る幕ないでしょう
もしかして y を全ての自然数について全探索するのを想定してる？
高卒？

**デフォルトの名無しさん** · 2021/07/13(火) 00:31:12.29

>>701
質問者自身が int にキャストとか round とか言ってるんだからどう見ても自然数の話でしょ
バカ

>>702
> n乗根の候補を求めたあと整数領域でn乗してもいいし
> 元の数を（割り切れる判別をしながら）候補で割っていってもいいし
なんで今更質問者(>>696)より筋の悪い方法を提案するの？笑

> 与えられた整数が32bitの範囲であれば、2分検索やリニア検索してもいい
これしきの問題で何を探索することがあるんだよバァ～～～カ
つーかわざわざ二分探索とかするならそれこそ桁数めっちゃ多いときの方が有効だろ
なぜ32bitに限った？

**デフォルトの名無しさん** · 2021/07/13(火) 00:34:18.46

>>707
えっっっっ
やっぱり根を探索するつもりだったんだ
ヤベーなお前

**デフォルトの名無しさん** · 2021/07/13(火) 00:38:55.05

>>708
何と勘違いしてんのか知らんが、ここで与えられてる問題は桁数 n に対して明らかに O(n) で解けるだろ
アホ

**デフォルトの名無しさん** · 2021/07/13(火) 00:45:05.26

>>715
質問者より数歩後ろを歩いてるのにすごく堂々としていてかっこいいです

**デフォルトの名無しさん** · 2021/07/13(火) 00:54:56.07

構ってほしいなら昨日のID教えてよ

**デフォルトの名無しさん** · 2021/07/13(火) 01:00:26.91

ウーン、質問者！ｗ

**デフォルトの名無しさん** · 2021/07/13(火) 01:00:52.89

>>711
アホだろお前

**デフォルトの名無しさん** · 2021/07/13(火) 01:02:39.35

そうでもないよ。

**デフォルトの名無しさん** · 2021/07/13(火) 01:28:13.49

>716
あれ？もしかして>702？
>702は回答としてもヒントとしても全然駄目じゃない？

>695の問題の本質はstd::powの誤差の発生の仕方（プラスマイナス両方出る）と
double -> int キャスト時の誤差切り捨て（0に近づく方に切り捨て）の
ミスマッチなのに、>702ではそんなこと何も言及していないよね。

もしこれで「書いている」と感じるようなら、もっと人間に説明する方法を
勉強したほうが良いと思うよ。

**728** · 2021/07/13(火) 01:31:47.96

自己フォロー
>695の問題の本質はstd::powの誤差の発生の仕方
1.0/nでも誤差発生しているか。std::powとどっちの誤差がデカイかね？

**デフォルトの名無しさん** · 2021/07/13(火) 01:38:26.00

もしかしてっつーかモロID一緒じゃん
あとみんな分かってることを周回遅れで「本質」として宣言すんなって
あと安価間違いし過ぎ

ホント迷惑だからもうやめとけ

**デフォルトの名無しさん** · 2021/07/13(火) 01:39:24.44

boost多倍長整数クン顔真っ赤でワロ

**デフォルトの名無しさん** · 2021/07/13(火) 02:08:48.23

この中のどれがQZがコテ外して書き込みしているのか想像したら(*´艸｀*)

**デフォルトの名無しさん** · 2021/07/13(火) 02:10:33.69

>>668
これとか完全に荒らしのやり口だもんな

**デフォルトの名無しさん** · 2021/07/13(火) 02:30:29.04

>730
誤差の発生の仕方と誤差切り捨てのミスマッチが問題ということが分かっているなら、
なんで>691への回答でそれを指摘しないの？
この話で重要な「切り捨て」という単語すらスレで３回しか出てきてないし。
それにdoubleに0.5足して/引いてからintにキャストとかCで誤差を扱うときの
定石だろうに、0.5ｂﾆいう数字自体ｂﾙとんど出てこｂﾈい。

結局>691に助言したいんじゃなくてマウントしたいだけだから当然か。
分かってて余計な説明しかしないんだから、なんとまぁ不親切なやつなんだろうかね。

さて、書きたいこと書いたので風呂入って寝るかね。

**デフォルトの名無しさん** · 2021/07/13(火) 02:42:44.22

>>734
round という語が出た回数とその場所も調べたまえ
指摘するまでもなく質問者は>>691,696にして早々それに気付いている

**デフォルトの名無しさん** · 2021/07/13(火) 03:09:56.56

そもそも>>696の処理であれば切り捨て誤差は発生しない
round() と abs() の2段構えで対策はされてるよ
0.5 を加算するよりずっとスマートな記述だな

**デフォルトの名無しさん** · 2021/07/13(火) 03:11:08.93

被った
すまん

**デフォルトの名無しさん** · 2021/07/13(火) 07:55:39.92

>>728
四捨五入ってわかるかな？
質問者が分かってることがわかるからそれだけ書けば十分
分かってないのはお前だけ

>>720
小数の誤差を見積もれない、見積もるのが面倒
というなら整数領域だけで答えを導く方法もある
頭の悪い文系にはそういう発想は出てこないかな？

intも整数もマイナスの数を含むんだよね定義的には
範囲を確認するのは当然
質問者も含め勝手な思い込みはバグの元

**デフォルトの名無しさん** · 2021/07/13(火) 09:33:54.05

Pow(x, n) ... n乗
Pow(x, 1.0/n) ... n乗根
Pow(x, -n) ... n乗の逆数
Pow(x, -1.0/n) ... n乗根の逆数

**デフォルトの名無しさん** · 2021/07/13(火) 12:07:43.02

>>712
どんなときでも共通するのは声が大きい香具師が勝つ
その場の空気を支配した香具師が勝つ
そしてマスゴミによって印象操作された世界の完成

**デフォルトの名無しさん** · 2021/07/13(火) 12:13:28.49

>>740
その発想は朝鮮人の考え方
最終的には真実が勝つ

**デフォルトの名無しさん** · 2021/07/13(火) 12:25:14.06

整数の問題なら実数近似せず
y=x^n で(n=1,2,3,4,5....)を比較してくのが基本だろ

高速化するなら多少のテクニックはあるけどたかだか32～64bitの範囲
どうってことない

**デフォルトの名無しさん** · 2021/07/13(火) 12:33:54.00

>>742
癪だが>>719が問題を一番正確に表現できているからもう一回よく読め

**デフォルトの名無しさん** · 2021/07/13(火) 12:34:17.81

規格には拘りがあるが数値計算やアルゴリズムの知識はまるでない基地外の狂宴

**デフォルトの名無しさん** · 2021/07/13(火) 12:49:36.15

>>743
えーなんだこれ
つまり
x,nが与えられたときx^1/nが整数かどうか？を示すってことか

y^n=xに変換すればなんにせよ整数の探索問題
実数にする必要もない

**デフォルトの名無しさん** · 2021/07/13(火) 13:03:24.24

>>745
それ、キミの言ってる32～64bitの範囲だと尚更>>696と比べたときにメリットないよね？？？笑笑笑

**デフォルトの名無しさん** · 2021/07/13(火) 13:07:00.03

上にも「32bitくらいなら探索すれば～」とか言ってるアホいたが、なぜ多倍長でもない限り探索するメリットなんてないってわからないんだキミたちは(泣)

**デフォルトの名無しさん** · 2021/07/13(火) 13:25:56.92

>>741
朝鮮人に詳しいんですね！！
感動しました！！！

**デフォルトの名無しさん** · 2021/07/13(火) 14:47:47.54

つまりそれってint型の整数の範囲でn乗がなんであってもεは1E-12で充分だと保証してから使うの？
要するにεは絶対にそれでいいのか？

**デフォルトの名無しさん** · 2021/07/13(火) 15:54:31.17

>>744
QZか？MZか？片山か？

**デフォルトの名無しさん** · 2021/07/13(火) 18:43:03.58

>>747
整数ドメインで行うメリットはいろいろとある

・アホな文系でも理解できる (誤差の見積もりが不要)
・整数演算の方が圧倒的に速い環境 (ARM-M3など)
・浮動小数点演算ライブラリによるコードサイズ増加を防ぐ (チープなマイコン対応)
・doubleが32bitな環境への対応
・64bit整数への対応

選択肢は多いほど良い

**デフォルトの名無しさん** · 2021/07/13(火) 18:48:11.59

> ごく一般的なPC環境で、与えられた整数がintの範囲であれば、
> (ある程度の判別を行ったあと)普通に四捨五入で良い

ごく普通の環境、ごく普通の頭ならこれで終わり

**デフォルトの名無しさん** · 2021/07/13(火) 19:39:45.09

昔"文系"にいじめられてた可愛そうな子なんです

**デフォルトの名無しさん** · 2021/07/13(火) 19:58:16.23

整数演算の最大のメリットがリストに挙がってないのは何でかな

**デフォルトの名無しさん** · 2021/07/13(火) 20:18:44.42

>>753
「アホな文系」≠「文系」

>>754
ぜんぜん最大のメリットじゃないからだな

**デフォルトの名無しさん** · 2021/07/13(火) 20:20:09.92

>>750
団子のことも忘れないでください

**デフォルトの名無しさん** · 2021/07/13(火) 20:25:35.22

>>755
あー・・・何のことか分からねえで言ってるな

**デフォルトの名無しさん** · 2021/07/13(火) 20:29:09.24

最大のメリットって何だ？

**デフォルトの名無しさん** · 2021/07/13(火) 20:35:59.66

からかいたくなったから焦らすぜ
アホかどうかは関係ないことさ

**デフォルトの名無しさん** · 2021/07/13(火) 22:54:45.19

>>755
アホな文系に虐められてたんだね…😢

**デフォルトの名無しさん** · 2021/07/13(火) 23:05:28.90

>>752
それは質問者が質問時に自分で言ってることなので……(苦笑)

**デフォルトの名無しさん** · 2021/07/14(水) 05:08:53.51

hoge がビルドされてて hoge.h があるシステムでは hoge を呼び出し、そうでなければ何もしない関数 call() ってどう書くべきてすかね？

これまでは
#if __has_include(<hoge.h>)
#endif
で分岐してたんですが、これだと if に該当しなくてもコンパイラは #if #endif で囲まれてる部分を読み込むし、そこに hoge(); という文があれば「hoge() なんてないよ」というエラーが出ます
該当しない場合は if の中を読み飛ばすとかできますかね？

**デフォルトの名無しさん** · 2021/07/14(水) 07:18:49.74

__has_includeはインクルードされたかどうかじゃなくて、
そのファイルが存在するかどうかを判定するやつだからね

hoge.hの中で
#define HOGE_LOADED
して、呼び出し側で
#if defined(HOGE_LOADED)
call();
#endif
って感じかな

**デフォルトの名無しさん** · 2021/07/14(水) 07:40:27.18

hoge.hの中を編集できないなら、

読み込み：
#if __has_include(<hoge.h>)
#include <hoge.h>
#define HOGE_LOADED
#endif

呼び出し：
#if defined(HOGE_LOADED)
call();
#endif

**デフォルトの名無しさん** · 2021/07/14(水) 08:03:52.87

>>761
だったらコーナーケースが無いこととその理由を解説したら？

**デフォルトの名無しさん** · 2021/07/14(水) 11:41:16.26

>>765
お前QZだろ
コテ外すな

**デフォルトの名無しさん** · 2021/07/15(木) 00:20:47.29

>>763
ありがとうございます。

hogeがそのシステムでビルドされてるかどうかの判定は、外部ツールか自分の目に頼らないと無理ですよね？

**デフォルトの名無しさん** · 2021/07/15(木) 00:40:53.25

自作自演ｗ

**デフォルトの名無しさん** · 2021/07/15(木) 05:48:49.27

>>767
> hogeがそのシステムでビルドされてるかどうか
hoge.lib, hoge.dllとかが存在するかどうかを調べればいいだけだとすると
見つかったかどうかをコンパイル時にフラグ(-DHOGE_LIB_FOUND)として渡せれば
C++内で#if defined(HOGE_LIB_FOUND)みたいにして使える。
（これはコンパイル時のことだからC++だけでは普通無理だとおもう）

**デフォルトの名無しさん** · 2021/07/15(木) 06:31:17.96

C++よりcmakeとかビルドツールのお仕事だと思う

**デフォルトの名無しさん** · 2021/07/15(木) 09:10:44.89

>>769-770
あざす！

**デフォルトの名無しさん** · 2021/07/15(木) 18:30:18.77

Unifyde Call Syntax FOREVER!!!!!!!

**ハノン** ◆QZaw55cn4c · 2021/07/15(木) 20:57:38.68

>>695
多倍長なら是非是非、こちらを参照あれ、一応 C++ で完結している多倍長演算ライブラリです！
https://mevius.5ch.net/test/read.cgi/tech/1434079972/37

**ハノン** ◆QZaw55cn4c · 2021/07/15(木) 20:58:44.86

>>712
なに、いつものことですよ‥‥

**ハノン** ◆QZaw55cn4c · 2021/07/15(木) 21:00:08.01

>>732
残念ながらハズレ

**ハノン** ◆QZaw55cn4c · 2021/07/15(木) 21:02:01.21

>>756
私は忘れていませんよ

**ハノン** ◆QZaw55cn4c · 2021/07/15(木) 21:02:27.40

>>766
ちがうよね‥

**デフォルトの名無しさん** · 2021/07/15(木) 22:53:15.98

QZ現る

**デフォルトの名無しさん** · 2021/07/16(金) 00:17:25.62

>>773
積の実装はどのアルゴリズムで？

**ハノン** ◆QZaw55cn4c · 2021/07/16(金) 04:05:20.77

>>779
筆算法‥‥1 bit × 1 bit を筆算するやりかた、非乗数をシフトしながら乗数のビットが1 のときアーキュムレータに足す、というO(n^2) のものです、「乗法を加法の繰り返しにする」よりはましかと
課題はカラツバ法に直すことですが、まだ出来ていません

**デフォルトの名無しさん** · 2021/07/16(金) 04:11:57.42

>>780
では、話になりませんのでそんなもの勧めないでいただけますか

**ハノン** ◆QZaw55cn4c · 2021/07/16(金) 04:43:48.91

>>781
他の方が優れたソースコードを提示していただければ、私のは引っ込めますけれどもね

**デフォルトの名無しさん** · 2021/07/16(金) 04:57:11.80

多倍長整数ならそれこそboostで良いでしょ
高速な畳み込み演算がしたいなら整数環上でFFTします
つーか精度の観点から言っても速さの観点から言っても一択でしょ（なんでカラツバ？）

そもそも、話の流れからして多倍長整数勧めるのもおかしいし
話わかってないなら出張るなよ

せっかく隔離用の個人スレ (本来ならこれも甚だ迷惑な存在だが) があるんだから、そこで永久に一人でやっててよ

**デフォルトの名無しさん** · 2021/07/16(金) 05:01:00.91

>>782
https://www.google.com/search?q=%E5%A4%9A%E5%80%8D%E9%95%B7%E6%95%B4%E6%95%B0+FFT

**デフォルトの名無しさん** · 2021/07/16(金) 05:06:07.44

カラツバ法はやばい
せめてフーリエだ　
すでにあるmpirとかいうやつでいいだろ

**ハノン** ◆QZaw55cn4c · 2021/07/16(金) 05:16:00.53

>>784
ちゃんとコンパイルできるコードはどれですか？

**デフォルトの名無しさん** · 2021/07/16(金) 05:18:43.72

ワロチ
既知の事柄のサーベイ能力も低いときた

**ハノン** ◆QZaw55cn4c · 2021/07/16(金) 05:36:01.54

>>787
サーベイ能力が低いのは認めます、お願いですから、そのままコンパイルすれば動くコードを教えてください

**デフォルトの名無しさん** · 2021/07/16(金) 05:58:14.27

>>783は読めねーのかよ気狂い

**デフォルトの名無しさん** · 2021/07/16(金) 06:18:07.75

こんなスレまで来てC++の話してるくせにboost知らないってマジかよ…

**デフォルトの名無しさん** · 2021/07/16(金) 09:21:02.78

QZというコテは叩かれやすいからカノンにしたのか

**デフォルトの名無しさん** · 2021/07/16(金) 09:57:20.84

略してQアノン

**デフォルトの名無しさん** · 2021/07/16(金) 11:50:57.63

コテを変えても頭の悪さは相変わらずなんだな
まあ中の人が同じなんだから当然だけど

**デフォルトの名無しさん** · 2021/07/16(金) 12:07:04.82

頭悪いのは別にいいんだが、マナー違反が深刻に多いんだよ
・質問に頓珍漢なレスをつける (そもそも回答側に立つのがおこがましいし)
・話題に関係なく自分の創作物を押し付ける
・個人用としてしか機能していないスレを保守し続ける
・都合悪いレスは当然無視
・>>668

人間性が劣悪なのが透けて見えるから本当にキツい