  |
はてなキーワード: 整数とは
alignmentとは 意味・読み方・使い方
https://ejje.weblio.jp/content/alignment
サイズが64ビットになることはさすがに認識していたような雰囲気でしたので、やはりアラインメントの考慮もれのように思います。— 徳丸 浩 (@ockeghem) December 2, 2023
全銀ネットの障害原因、開発言語はやはりC言語だったそうです（インプレスの質問ナイス）。64ビット化によって（整数の?）サイズが増えるが、計算上メモリ割り当て量を増やさなくても足りると見て再コンパイルのみしたが、そのサイズ計算が間違っていたhttps://t.co/jHk6ecZKli— 徳丸 浩 (@ockeghem) December 2, 2023
ワイ：
真面目な顔の人間の男の人の顔の絵を描いてください。
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は想像とは異なる仮説を作って最初にぶん投げるとよい。増田なら帰無仮説は得意のはず（偏見）
掛け算の交換法則について教えてください
掛け算の交換法則とは、数の掛け算において、数の順序を変えても掛け算の結果が変わらないという法則です。具体的には、任意の実数ａとｂに対して、以下の式が成り立ちます。
ａ×ｂ =ｂ×ａ
...
掛け算の交換法則は、算数や数学の基本的な計算において非常に役立ちます。これを知っていることで、計算がシンプルになったり、計算の手順を変更できることがあります。
では、かけ算の順序には意味がありますか？
掛け算自体の結果には順序が影響を与えないため（交換法則により）、数値のみを単純に掛け合わせる場合、順序に意味はありません。
しかし、数学や実世界の問題の文脈においては、順序が意味を持つことがあります。
ベクトルにおいては、外積（またはクロス積）の順序は重要です。ベクトル ａ と ｂ に対して、ａ × ｂ と ｂ×ａ は方向が逆のベクトルになります。
2. 行列の掛け算：
行列の乗算では、掛ける順序が非常に重要です。2つの行列 Ａ と Ｂ に対して、ＡＢ と ＢＡ は一般的に異なる結果をもたらします。
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等の特定のサイトだけデカくみえる理由の説明にはならないのです。
なんなんすかね？
1. C++はプログラミング言語として有名であり、ブラのカップ数をC++と表記することで、テクノロジーに精通していることをアピールできる。
2. C++はCよりも高度な機能を持っており、ブラのカップ数をC++と表記することで、自分のバストの質や機能性を高めることができる。
3. C++はオブジェクト指向プログラミングをサポートしており、ブラのカップ数をC++と表記することで、自分のバストをオブジェクトとして扱うことができる。オブジェクト指向プログラミングでは、オブジェクトに属性やメソッドを持たせることができるので、自分のバストにも色や形や大きさなどの属性や、揺れるや揉むや吸うなどのメソッドを持たせることができる。
4. C++は多重継承をサポートしており、ブラのカップ数をC++と表記することで、自分のバストを複数のクラスから継承することができる。多重継承では、複数のクラスの特徴や機能を組み合わせることができるので、自分のバストにも様々な特徴や機能を組み合わせることができる。例えば、自分のバストを芸能人やアニメキャラクターなどのクラスから継承することで、その人物やキャラクターのバストに似せることができる。
5. C++はテンプレートをサポートしており、ブラのカップ数をC++と表記することで、自分のバストをテンプレート化することができる。テンプレートでは、型や値などのパラメータを指定することで、汎用的なコードを生成することができるので、自分のバストにも型や値などのパラメータを指定することで、汎用的なバストを生成することができる。例えば、自分のバストをint型やdouble型などの型に指定することで、整数や小数などの値に変換することができる。
6. C++は例外処理をサポートしており、ブラのカップ数をC++と表記することで、自分のバストに発生する可能性のある例外に対処することができる。例外処理では、エラーや異常などの例外が発生した場合に、適切な処理を行うことができるので、自分のバストにもエラーや異常などの例外が発生した場合に、適切な処理を行うことができる。例えば、自分のバストが垂れたり痛んだりした場合に、修正したり治療したりする処理を行うことができる。
これの続きで理系科目版
もう一度言うが子を持つ親へ。難関国公立に行ってほしいなら中学受験させろ。
国公立ギリギリ合格ライン層への配慮が復活し、教科書に毛が生えたレベルの問題も散見された。去年はこの層の選抜としてほぼ意味をなさない難易度だったので良い傾向。しかし整数問題では中学受験でおなじみの問題が出題され、今年も中学受験経験者とそうでない人で差がついた。これで2年連続出題だから、大学入試センターは明確に中学受験経験者を優遇するつもりだろう。世知辛い。
本質を理解している人には笑いが止まらないほど簡単に見えるが、公式暗記と典型問題演習で乗り切ってきた人には難しく見えたはず。しかしほとんどの高校のカリキュラムは公式丸暗記と演習を前提とした作りになってるから、泣きそうになりながら解いた子も少なくないはず。予備校関係者が言うのも何だが、学校外で課金して物理を学べるエリートを優遇するというメッセージか。これも世知辛い
時間が厳しいと感じた人が多かったのでは。帰り道で「化学終わったｗｗｗ」という声がちらほら聞こえてきた。物理or生物→化学で解いた人と、逆の人で差が出てしまいそう。こういう不平等というか運ゲー要素は共通テストの理念に反しないか？と思う。
実質、情報処理能力試験になっていることへの批判は多いが、個人的には賛成派である。各科目における情報処理能力は、長期記憶に蓄積された知識や経験の量が物を言う。つまり勉強を頑張ってきた人は早いし、そうでない人は基本的に遅いからだ。
まだ共通テストという新しいテストの試行錯誤の途中で、色々実験してデータを取っている段階という印象だが、今回は国公立ギリギリ層の選抜としても機能するような問題構成が多くなったのは良かったと思う。
