はてなキーワード: 整数とは
はい、だから、 u^n + v^n = 1 という美しいかたちをしている楕円関数、え? 楕円関数っていうのは、高校数学3Cに出て来る奴です、演習問題は大量にあります、楕円関数の
焦点とかが決まってる奴です、ただの楕円関数です、それの、u,v の値が、格子点っていうのは、両方とも整数であるか有理数であるようなデカルトの上の座標をそう言います
フェルマーの言っている美しい主張というのは、上の関数が、その格子点を通らないというだけの、そういう状態のものであるということです。なんでそうなるのかの証明をしなければいけませんが
そういうのはできないのでここではやりません。あのー、ワイルズがちゃんと証明したっていうのは、専門的な議論をしてるので、何が書いているのか分からないので、
歴史的に見ても見なくても、一夫一妻じゃない例なんていくらでもあるし。
子育てなんて今の時代、一夫一妻じゃ無理ゲーだよ。だいたい子どもを二人だけで育てるなんて正気の沙汰じゃない。夫が非協力的だから~とかそんな問題じゃない。夫が3年ぐらい育休取ってずっと家にいない限り無理。みんな無理を通して道理を引っ込めてるだけでしょ。
でもこれが例えば同時に子どもを見られる人が二人になれば大分違う。ずっと交代で見られるなら子どもが例えば3人とか4人とかいても見られるよ。
人間性を8ビットの数値で判断することは適切ではありません。 以下にその理由を説明します。
1. 制約された範囲:
- 8ビットは、整数を表現するための非常に制約された範囲です。符号付きcharは通常-128から127までの範囲で値を持ちます。
- 人間の多面性や複雑さを8ビットの数値で捉えることはできません。感情、思考、行動、文化的背景、経験など、人間性は非常に多様であり、単一の数値で表現できるものではありません。
2. 多次元性:
- 人間性は多次元的であり、単一の指標では十分に評価できません。感情、知性、道徳、社会的スキル、創造性、共感、信念など、さまざまな側面が組み合わさっています。
- これらの側面を8ビットの数値で捉えることは、人間の複雑さを過小評価することになります。
3. 文脈と状況:
- 人間性は文脈と状況によって異なります。同じ人でも異なる状況で異なる側面を示すことがあります。
- 8ビットの数値は、人々の行動や意思決定の背後にある深層的な要因を理解するのに不十分です。
したがって、人間性を8ビットの数値で判断することは、その複雑さを無視するものであり、適切ではありません。人間性は多面的であり、数値だけでは表現できないものです。
プログラミング言語側に組み込まれている「型」だけでなく、プログラマーが独自に「型」を定義する方法も用意されています。
struct、class、interface、type, enumなどを使って独自の「型」を定義します。
開発しているソフトウェア独自の「型」は、ドメインモデルの要素になります。
多数の「型」を分類し、組織化するために名前空間を利用します。
近年「クラス」が「型」の定義であるという基本概念を理解していないエンジニアが増えているので、エンジニアを採用する際には注意しましょう。
ソフトウェアを起動すると、メモリ上には、たくさんのデータを読み込まれます。各データには、データの種類を表す「型」が割り当てられています。
例えば、ゲームならばCartという大分類の「型」を用意し、その要素としてMarioCart, LuigiCartという「型」を用意します。
業務システムならば、Reportという大分類の「型」を用意し、その要素としてCostReport, SalesReportのような「型」を用意することになります。
これらの大分類の「型」と、要素の「型」は、is-a関係にある、といいます。
CPUは機械語しか理解できません。一方で人間は機械語でプログラミングすることは困難です。
人間が「1ドル」のつもりで、メモリに「1」と記憶させても、CPUは「ドル」だとは扱ってくれません。
CPUは、「円」のつもりで記憶させた「1」と、ドルの「1」を区別出来ないので、そのまま足し算などの演算を実行してしまいます。
そこで、人間にとってプログラムを読みやすくすることと、CPUに意図しない演算をさせないために、データの種類を表す「型」という概念がプログラミング言語に用意されるようになりました。
金融やECサイトなどのお金の計算間違いが致命的なシステムでは、1ドル、1円を整数型などで扱うのではなく、予期せぬ演算が実行されないように「ドル型」、「円型」という「型」を定義します。
メモリ上のデータがどの「型」に属しているのか、という集合論の話でもあります。
例えば、猫型のデータは、動物型という大分類に属する、という集合の話です。
オブジェクト指向プログラミングの「is-a関係」は、集合論に由来するメモリ上のデータ(オブジェクト)の分類の話です。
alignmentとは 意味・読み方・使い方
https://ejje.weblio.jp/content/alignment
サイズが64ビットになることはさすがに認識していたような雰囲気でしたので、やはりアラインメントの考慮もれのように思います。— 徳丸 浩 (@ockeghem) December 2, 2023
全銀ネットの障害原因、開発言語はやはりC言語だったそうです(インプレスの質問ナイス)。64ビット化によって(整数の?)サイズが増えるが、計算上メモリ割り当て量を増やさなくても足りると見て再コンパイルのみしたが、そのサイズ計算が間違っていたhttps://t.co/jHk6ecZKli— 徳丸 浩 (@ockeghem) December 2, 2023
ChatGPT
1対1のトーナメント戦を行います、例えばサッカーのワールドカップみたいなものですね。
引き分けは無しとするよ。
1対1のトーナメント形式で、引き分けがない場合、各試合には勝者が1人おり、その勝者が次のラウンドに進みます。したがって、チーム数がnの場合、全試合数はn-1となります。なぜなら、トーナメントの最後には1チームだけが残るため、n-1チームが敗退しなければならないからです。
def calculate_total_matches(n):
if isinstance(n, int) and n >= 2:
return n - 1
else:
return "チーム数は2以上の整数で入力してください。"
try:
teams = int(input("トーナメントに参加するチーム数を入力してください: "))
print("全試合数:", calculate_total_matches(teams))
except ValueError:
ワイ:
真面目な顔の人間の男の人の顔の絵を描いてください。
GPT:
*イメージ省略*
ワイ:
GPT:
*イメージ省略*
ワイ:
その整数が 3 か 5 の倍数の場合、ふざけた顔の男の顔(一枚目の顔)を表示してください。
GPT:
了解しました。以下は、指定された条件に基づいて動作するPythonのGUIアプリのコードです。このアプリは、tkinterを使用しています。まず、必要なライブラリをインストールしてください:
pip install tkinterimport tkinter as tk from tkinter import Entry, Label, PhotoImage def display_image(): num = entry.get() if num.isdigit(): num = int(num) if num % 3 == 0 or num % 5 == 0: label.config(image=goofy_face) else: label.config(image=serious_face) entry.delete(0, tk.END) def on_close(): root.quit() root.destroy() root = tk.Tk() root.title("Face Display App") # ふざけた顔と真面目な顔の画像をロードします # 以下の部分は、DALL-Eで生成された画像のパスに置き換える必要があります goofy_face = PhotoImage(file="path_to_goofy_face_image.png") serious_face = PhotoImage(file="path_to_serious_face_image.png") entry = Entry(root) entry.bind('<Return>', lambda event=None: display_image()) entry.pack(pady=20) label = Label(root) label.pack(pady=20) root.protocol("WM_DELETE_WINDOW", on_close) root.mainloop()このコードには、2つのPhotoImageオブジェクトがあります。これは、ふざけた顔の画像と真面目な顔の画像をロードするためのものです。path_to_goofy_face_image.pngとpath_to_serious_face_image.pngは、DALL-Eで生成された画像の実際のパスに置き換える必要があります。
このアプリは、ユーザーが整数を入力してReturnキーを押すと、指定された条件に基づいて画像を表示します。エスケープキーまたはウィンドウを閉じることでアプリを終了できます。
ワイ:
GPT:
道具の使い方とは何かという話である。
ChatGPTは想像とは異なる仮説を作って最初にぶん投げるとよい。増田なら帰無仮説は得意のはず(偏見)
掛け算の交換法則について教えてください
掛け算の交換法則とは、数の掛け算において、数の順序を変えても掛け算の結果が変わらないという法則です。具体的には、任意の実数aとbに対して、以下の式が成り立ちます。
a×b =b×a
...
掛け算の交換法則は、算数や数学の基本的な計算において非常に役立ちます。これを知っていることで、計算がシンプルになったり、計算の手順を変更できることがあります。
では、かけ算の順序には意味がありますか?
掛け算自体の結果には順序が影響を与えないため(交換法則により)、数値のみを単純に掛け合わせる場合、順序に意味はありません。
しかし、数学や実世界の問題の文脈においては、順序が意味を持つことがあります。
ベクトルにおいては、外積(またはクロス積)の順序は重要です。ベクトル a と b に対して、a × b と b×a は方向が逆のベクトルになります。
2. 行列の掛け算:
行列の乗算では、掛ける順序が非常に重要です。2つの行列 A と B に対して、AB と BA は一般的に異なる結果をもたらします。
3. 実世界の状況:
例えば、ある商品の元の価格に対して10%の割引を受けた後に8%の消費税がかかる場合と、消費税をかけた後に10%の割引を受ける場合では、最終的な価格が異なります。このような状況では、計算の順序が結果に影響を与えます。
これらの例を考慮すると、数値だけの単純な掛け算では順序は意味を持たないものの、特定の文脈や状況においては掛け算の順序が重要となることがあります。
はてぶの上位にちょいちょい載ってるTBS系のニュースサイト、newsdig.tbs.co.jpについて。
https://b.hatena.ne.jp/site/newsdig.tbs.co.jp/
何がヤバいかって、くっそ巨大なCookie(LocalStorageとかも含むのか知らんけど)をしこたま保存してんのよ。
気付いた時点では640MBも占有してた。別に巡回チェックしてるわけでもなく、話題に挙がってたら見てみることもある程度のアクセス頻度なのだが。
Chromeユーザーはアドレスバーに↓コピペして確認してみてくれ。
chrome://settings/content/all?searchSubpage=tbs.co.jp&search=cookie
試しにCookie消去してから、ただ開いただけでサイト上で何の遷移もしてないのに279MBも保存された。
次点ではpresident.jpが553MB消費してた。(こっちも話題に挙がってたら見てみることもある程度。)
(その次にはGoogleが数百MBオーダーで消費してたけど、これはGoogleドライブのオフラインキャッシュとか考えれば妥当。他に数百MBオーダーで消費してるサイトは無かった。)
多くのサイトは数バイト~KBオーダーなのに、こいつら何保存してんのか不気味すぎる。
(追記)
各自の環境の消費量を教えてくれた方々や有意義なコメントを下さった方々ありがとうございます。
始めにお断りしておくべきだったかもしれませんが、自分はソフトウェア系ではありますが、Webエンジニアではありません。認識が浅かったり、古かったり、そもそも間違ってる可能性もあります。
CookieじゃなくてCacheStorageやんけと突っ込みもいただいていますが、「LocalStorageとかも含むのか知らんけど」と書いておいた意図は(どのような技術要素かはどうでもよくて)ユーザー端末に保存されるデータボリュームについての話を意図しています。ChromeのCookie絡みの設定画面での表示なのでこのような書き方をしましたが、解り難かったのならごめんなさいね。冗長ながらも認識齟齬を招かないように平易な表現で書くと、「ユーザの明示的な承諾なくユーザー端末に保存されるデータがデカイんだが」って話です。
で、各自の環境で「ユーザの明示的な承諾なくユーザー端末に保存されるデータ」が数GBオーダーにも及ぶという事例が少なからず報告されて、自分の環境だけではない事象だということが判りました。
さらにtbsとpresident以外にもいくつかのサイトが同様に肥大化していることも知れました。
結果的にはid:hinaloeさんの解説が解りやすかったです。ありがとうございます。
https://blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/
CacheStorageがChromeの表示と、実際のディスク消費量と一致していないことが原因であると理解しました。
追試してみたところ私の環境ではChromeの開発者ツールでの表示が74MBで実際のWindowsのファイルシステム上は33.9MB消費されました。
実際のストレージの消費は表示値の半分程度ということになり、id:hinaloeさんの1.4GBに対して5MBのように実際の約0.3%という結果とは大きく乖離がありますので、各環境で大きく違いそうな気がします。
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage
※配下のどのディレクトリが対象サイトのものなのか一意に特定する情報が無さそうなので、Chrome開発者ツールのApplicationタブの左上の方にあるService Workersを選択すると、右側にReceived YYYY/M/D HH:MM:SSみたいな表記が有るので当該時刻に変更されたタイムスタンプを持つディレクトリを特定するような感じになるかと思います。
ついでに開発者ツールを触っていて気付いたベースで書いておくと、
といった感じで、ユーザが見たものをキャッシュしているのではなくて、先読みしてるような挙動に思えます。
ロード時間短縮でUX改善を狙ったものかもしれませんが、個人的にはそれを1か月も保持し続けるのは過剰な感じがしますが世の中的にはどうなんでしょうね?
(追記2)
hinaloe氏の投稿で紹介されているStackOverflowの投稿やそのリンク先のChromiumのバグレポートのやり取りまで目を通してみると、特に理由の説明なく平均7MBがパディングされると書かれた投稿があります。
https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses
https://bugs.chromium.org/p/chromium/issues/detail?id=796060
該当するソースコードは↓のようです。
この中で、ComputeRandomResponsePadding()という関数を呼び出しておりその実体は↓のようです。
この関数は符号無し64bit整数の乱数(つまり、0~18446744073709551615のいずれか)を14431 * 1024 = 14777344で割った剰余(つまり、0~14777343≒約14MiB)を返却します。
これがパディング値として採用されることになりますが、乱数が正規分布している前提で、平均すると(最大値14MiBの半分で)約7MBになるよねってことだと思われます。
故にChromeの設定画面から確認できるCookie等(LocalStorageとかCacheStorageとか諸々含む)のサイズは、概算してCacheStorageに存在するファイル数×平均7MBが過大計上されていることになりそうです。
これでChromeの設定画面から確認できるサイズと、実際のファイルシステム上で消費されているサイズの違いは合理的に説明できますが、TBS等の特定のサイトだけデカくみえる理由の説明にはならないのです。
なんなんすかね?