新しいものを表示
orange さんがブースト

というか花粉の有無はともかくとして,花粉症になるならないって何で決まるんだろう

orange さんがブースト

北海道の人が関東に来たら花粉症の症状出るんだろうか

難しい内容のCopilotとのやり取り、まるで2chでの議論><;

CopilotさんにBCDを使用する事例としない事例の回路の規模の差を聞いたら「BCDを使う方が大きくなるはずです!」って来たので
超要約すると
「じゃあ、100で割れるかを判定する回路はどう作るの?><」
Copilot「BCDを使ってこういう風に・・・」
「は?>< さっきはBCD使わないって言ったよね?>< 言ってる事が矛盾してないか?><」
的なバチバチなやり取りを30分くらいして、
Copilot「真理値表を作る方法ならばBCDを使わずに作れるはずです。どっちが大きくなるかはわかんない。ごめんなさい(意訳)」
まで持ってった><

Copilotさんが壊れた><(止まらなくなった)

Microsoft Copilotさん、原理を考えれば当然かもだけど、メジャーなアルゴリズムを提案することはできても、アクロバティックな条件にあうアルゴリズムをその場で考えるなんてことはできないっぽさ><

試しにCopilotさんに条件分岐と論理演算を使わないで閏年を判定するコードを聞いてみたら、普通にPythonのよくある閏年判定コードを出してきて「and と or を使わないやつです!><」
「すみません(さっきと同じコードを出す)」
「含まれてます!><;」
「すみません andとorが含まれていないコードにandとorが含まれていました。正しいコードはこちらです(さっきと同じコード)」
「ふくまれてます!><;」
ってループに入った><:

誰だよAIがやってくれるからプログラマはもう不要とか言ったやつ><(?)

Copilotさんに聞いたら、頑なに「4で割れるか見て100で割れるか見て400で割れるか見れる回路を作ればいいです!」
BCDを使わない場合は、その回路はどうやって作ればいいですか?><;
「BCDを使わない場合は、4で割れるか見て100で割れるか見て400で割れるか見れる回路を作ればいいです!」
だからそれをどう作るのか聞いてるんだけど!?><;

大学でBCDに変換する教え方してるって事は、つまり2進のままで閏年を検出する回路はBCD変換して行う回路より小さくするのは不可能って事?><;

デジタル回路で閏年検出、英語のどっかの大学の授業の資料みたいなのみつけたけど、「まず年をBCDに変換して」ってなってて、「2進のままじゃ無理ですか?><;」ってなった><;

そのものずばりの答えっぽいもの見つけた><

LEAP YEAR - COMBINATIONAL CIRCUIT | VLSI & Embedded Projects
linus5.blogspot.com/2016/06/le

わかんないからあきらめて先人の知恵をググろう><;

そもそも(10進の)100で割れるかどうかの判断をシフトと論理演算だけで高速に行うってどうやるんだろ?><;

シフトと論理演算のみでやろうとするとどうやってもものすごく遅くなりそうな気がしてきた><

逆に(?)、閏年判定を加減乗除MODを一切使わずシフトと論理演算のみで計算してなおかつそれなりに速いカコイイアルゴリズムってあるんだろうか?><

オレンジが書いた閏年を論理演算も条件分岐も使わずに計算するやつ、DateTime.IsLeapYear()と比べると、最適化コンパイル有効時で約3.7倍くらい時間かかって、最適化無しでの比較だと10倍以上時間かかるっぽい><;

特になんとかCopilotみたいなのを追加も契約もしてないのになんでここまで賢い補完が出るのかわけがわからない><

VS2022、Stopwatchの宣言を書き始めたら開始コードが補完されて「そうそう!><;」って思って確定したら、
次の行にストップウォッチの停止コードが補完されて「そうです!><;」って確定して、
次の行にConsoleって打ったらWriteLineが補完されて「そうそう!><;」って確定したらさらにElapsedMillisecondsを出力するコードが補完されて、
「なるほどこれがプログラマが不要になる21世紀とかいうやつか!><;」
ってなった><(?)

オレンジが書いた閏年を論理演算も条件分岐も使わずに計算するやつ、作ったときに速度は測らなかったけど速いんだろうか?><;

古いものを表示
:realtek:

思考の /dev/null