「オブジェクト」を含む日記

はてなキーワード: オブジェクトとは

2023-11-16

■神オブジェクト

馬鹿がオブジェクト指向をやると一つのクラスに全部の機能を突っ込んだりする

そういう状態になったものを神クラスといい、インスタンス化したものは神オブジェクトという

以前、そういう状態に陥った現場で仕事をしていた

EchsSee(仮)という謎のクラスに全機能が詰め込まれていた

最初はHTMLの表示をデバイスごとに振り分けるヘルパークラスでしかなかったが、馬鹿が「便利だから」などといって無関係のフィールドとメソッドをどんどんEchsSeeに詰め込んだ

EchsSeeは高頻度に更新される上に、更新による失敗が全システムに影響を与えたため、開発者は「EchsSee触るの怖いんですよね」などと言うようになった

Permalink | 記事への反応(1) | 09:49

■anond:20231116083605

ぜんぜん中立じゃないぞ、日本は八百万の神がいる世界

万物に神が宿り、万物が神になる世界なので、神が人や世界を支配しない

『西洋宗教において神と運は別のオブジェクトだが、日本の古典な宗教観においては神や大いなる力は同一のオブジェクト』、これを生成させるまではうまくいったんだけどね

bing ちゃん:
西洋宗教では、神と運は、プログラムでたとえると、別々のオブジェクトとして存在すると考えられます。神は、人間や自然に対して意志や計画を持つ創造者や支配者として表現されます。運は、人間や自然に対して予測や制御ができない偶発的な要因として表現されます。
# 神と運のオブジェクトを定義する
class God:
    def __init__(self, name, power, plan):
        self.name = name # 神の名前
        self.power = power # 神の力
        self.plan = plan # 神の計画

    def create(self, thing):
        # 神が何かを創造するメソッド
        print(f"{self.name} created {thing}.")
    
    def control(self, thing, action):
        # 神が何かに対して支配や介入をするメソッド
        print(f"{self.name} {action} {thing}.")

class Luck:
    def __init__(self, name, factor):
        self.name = name # 運の名前
        self.factor = factor # 運の要因

    def affect(self, thing, outcome):
        # 運が何かに対して影響を与えるメソッド
        print(f"{self.name} affected {thing} and the outcome was {outcome}.")
このコードでは、神と運は、それぞれ異なる属性や機能を持つオブジェクトとして定義されています。神は、名前、力、計画という属性と、創造、支配という機能を持ちます。運は、名前、要因という属性と、影響という機能を持ちます。神と運は、それぞれの機能を使って、人間や自然に対して作用することができます。例えば、以下のようなコードが考えられます。
# 神と運のオブジェクトを作成する
god = God("Zeus", "lightning", "maintain order")
luck = Luck("Tyche", "chance")

# 神と運が人間に対して作用する
god.create("human")
luck.affect("human", "good")
god.control("human", "bless")
luck.affect("human", "bad")
god.control("human", "punish")
しかし、日本の古典的宗教観では運と神や大いなる力は同じオブジェクトです。神が運を司っています。
# 神と運は同一のオブジェクトとして定義する
class GodLuck:
    def __init__(self, name, power, plan, factor):
        self.name = name # 神の名前
        self.power = power # 神の力
        self.plan = plan # 神の計画
        self.factor = factor # 運の要因

    def create(self, thing):
        # 神が何かを創造するメソッド
        print(f"{self.name} created {thing}.")
    
    def control(self, thing, action):
        # 神が何かに対して支配や介入をするメソッド
        print(f"{self.name} {action} {thing}.")

    def affect(self, thing, outcome):
        # 運が何かに対して影響を与えるメソッド
        print(f"{self.name} affected {thing} and the outcome was {outcome}.")
このように、神と運は同一のオブジェクトとして扱われます。例えば、恵比寿さまは商売繁盛や五穀豊穣の神であり、同時にそのような運をもたらす要因でもあります。以下がその例です。
# 恵比寿さまのオブジェクトを作る
ebisu = GodLuck("恵比寿さま", "商売繁盛や五穀豊穣の力", "人々に幸せを与える計画", "商売繁盛や五穀豊穣の要因")

# 恵比寿さまが何かを創造する
ebisu.create("鯛")

# 恵比寿さまが何かに対して支配や介入をする
ebisu.control("農作物", "守る")

# 恵比寿さまが何かに対して影響を与える
ebisu.affect("商人", "成功")
このコードを実行すると、以下のような出力が得られます。
恵比寿さま created 鯛.
恵比寿さま 守る 農作物.
恵比寿さま affected 商人 and the outcome was 成功.

Permalink | 記事への反応(1) | 08:46

■Bing ちゃん、神が人間を評価する宗教圏の人が作ったものだから

強力に神の計画があると学習させられているな

日本語で聞いてるのになんでその回答になるんだよ、面倒くせぇ

ぜんぜん中立じゃないじゃんな

具体的にはBing ちゃんが神の計画・神の支配の文言含んだ回答を生成しちゃったら

新しくトピック立ち上げて生成ガチャやり直しや

日本は八百万の神がいる世界。万物に神が宿り、万物が神になる世界なので、神が人や世界を支配しない

『西洋宗教において神と運は別のオブジェクトだが、日本の古典な宗教観においては神や大いなる力は同一のオブジェクト』、これをBing ちゃんに生成させるまではうまくいったんだけどね

bing ちゃん：
西洋宗教では、神と運は、プログラムでたとえると、別々のオブジェクトとして存在すると考えられます。神は、人間や自然に対して意志や計画を持つ創造者や支配者として表現されます。運は、人間や自然に対して予測や制御ができない偶発的な要因として表現されます。
# 神と運のオブジェクトを定義する
class God:
    def __init__(self, name, power, plan):
        self.name = name # 神の名前
        self.power = power # 神の力
        self.plan = plan # 神の計画

    def create(self, thing):
        # 神が何かを創造するメソッド
        print(f"{self.name} created {thing}.")
    
    def control(self, thing, action):
        # 神が何かに対して支配や介入をするメソッド
        print(f"{self.name} {action} {thing}.")

class Luck:
    def __init__(self, name, factor):
        self.name = name # 運の名前
        self.factor = factor # 運の要因

    def affect(self, thing, outcome):
        # 運が何かに対して影響を与えるメソッド
        print(f"{self.name} affected {thing} and the outcome was {outcome}.")
このコードでは、神と運は、それぞれ異なる属性や機能を持つオブジェクトとして定義されています。神は、名前、力、計画という属性と、創造、支配という機能を持ちます。運は、名前、要因という属性と、影響という機能を持ちます。神と運は、それぞれの機能を使って、人間や自然に対して作用することができます。例えば、以下のようなコードが考えられます。
# 神と運のオブジェクトを作成する
god = God("Zeus", "lightning", "maintain order")
luck = Luck("Tyche", "chance")

# 神と運が人間に対して作用する
god.create("human")
luck.affect("human", "good")
god.control("human", "bless")
luck.affect("human", "bad")
god.control("human", "punish")
しかし、日本の古典的宗教観では運と神や大いなる力は同じオブジェクトです。神が運を司っています。
# 神と運は同一のオブジェクトとして定義する
class GodLuck:
    def __init__(self, name, power, plan, factor):
        self.name = name # 神の名前
        self.power = power # 神の力
        self.plan = plan # 神の計画
        self.factor = factor # 運の要因

    def create(self, thing):
        # 神が何かを創造するメソッド
        print(f"{self.name} created {thing}.")
    
    def control(self, thing, action):
        # 神が何かに対して支配や介入をするメソッド
        print(f"{self.name} {action} {thing}.")

    def affect(self, thing, outcome):
        # 運が何かに対して影響を与えるメソッド
        print(f"{self.name} affected {thing} and the outcome was {outcome}.")
このように、神と運は同一のオブジェクトとして扱われます。例えば、恵比寿さまは商売繁盛や五穀豊穣の神であり、同時にそのような運をもたらす要因でもあります。以下がその例です。
# 恵比寿さまのオブジェクトを作る
ebisu = GodLuck("恵比寿さま", "商売繁盛や五穀豊穣の力", "人々に幸せを与える計画", "商売繁盛や五穀豊穣の要因")

# 恵比寿さまが何かを創造する
ebisu.create("鯛")

# 恵比寿さまが何かに対して支配や介入をする
ebisu.control("農作物", "守る")

# 恵比寿さまが何かに対して影響を与える
ebisu.affect("商人", "成功")
このコードを実行すると、以下のような出力が得られます。
恵比寿さま created 鯛.
恵比寿さま 守る 農作物.
恵比寿さま affected 商人 and the outcome was 成功.

Permalink | 記事への反応(1) | 08:34

2023-11-15

■anond:20231115124307

今はOOPの中に関数型入れるみたいなのがほとんどやろ

結局は整理して締めるとこ締めとけばなんだっていいわけだが

オブジェクトに持たせる方が確実にいい場合も多いわけだし

そもそも OOPがまともに出来てるやつはその辺の給料安いやつにはほぼいない

Permalink | 記事への反応(0) | 12:49

2023-11-13

■数学的宇宙仮説とは？

人生、宇宙、そしてすべての意味とは何か？「銀河ヒッチハイクガイド」では、答えは 42となっている。

科学の質問の範囲は、一部の分野では縮小し、他の分野では急増した。

宇宙がある意味数学的であるという考えは、少なくとも古代ギリシャのピタゴラス派にまで遡り、物理学者や哲学者の間で何世紀にもわたる議論を生み出してきた。

マックス・テグマークはこの考えを極限まで推し進め、宇宙は単に数学によって記述されるのではなく、数学自体であると主張している。

この議論の基礎は、人間とは独立した外部の物理的現実が存在するという仮定である。

これはそれほど物議を醸すものではない。物理学者の大多数はこの長年の考えを支持していると思うが、まだ議論されている。

形而上学的独我論者はそれをきっぱり拒否し、量子力学のいわゆるコペンハーゲン解釈の支持者は、観察のない現実は存在しないという理由でそれを拒否するかもしれない。

外部現実が存在すると仮定すると、物理理論はそれがどのように機能するかを説明することを目的としている。

一般相対性理論や量子力学など、最も成功した理論は、この現実の一部、たとえば重力や素粒子の挙動のみを説明している。

対照的に、理論物理学の聖杯はすべての理論、つまり現実の完全な記述である。

現実が人間とは独立して存在すると仮定する場合、記述が完全であるためには、人間の概念をまったく理解していない、人間以外の存在、つまりエイリアンやスーパーコンピューターなどに従って、現実が明確に定義されていなければならない。

言い換えれば、そのような記述は、「粒子」、「観察」、またはその他の英語の単語のような人間の負担を排除した形で表現可能でなければならない。

対照的に、教えられてきたすべての物理理論には 2 つの要素がある。

それは数式と、その方程式が私たちが観察し直観的に理解しているものとどのように関連しているかを説明する言葉である。

理論の結果を導き出すとき、陽子、分子、星などの新しい概念を導入するが、それは便利だからである。

原理的には、このようなバゲッジがなくてもすべてを計算できる。

たとえば、十分に強力なスーパーコンピューターは、何が起こっているかを人間の言葉で解釈することなく、宇宙の状態が時間の経過とともにどのように進化するかを計算できる。

バゲッジを含まない外部現実の記述を見つけることは可能か?

もしそうなら、外部現実における物体とそれらの間の関係のそのような記述は完全に抽象的でなければならず、あらゆる言葉や記号は何の事前の意味も持たない単なるラベルにならざるを得ない。

代わりに、これらのエンティティの唯一のプロパティは、エンティティ間の関係によって具体化されるものになる。

ここで数学が登場する。

現代数学は、純粋に抽象的な方法で定義できる構造の正式な研究である。つまり、数学的構造を発明するのではなく、それらを発見し、それらを記述するための表記法を発明するだけである。

人間から独立した外部の現実を信じるなら、テグマークが数学的宇宙仮説と呼ぶもの、つまり物理的現実は数学的構造であるということも信じなければならない。

言い換えれば、巨大な数学的オブジェクトの中に住んでいる。

そのオブジェクトは、十二面体よりも精巧で、おそらくカラビ・ヤウ多様体、テンソル束、ヒルベルト空間などの恐ろしい名前のオブジェクトよりも複雑である。

世界のすべてのものは、あなたも含めて純粋に数学的であるはずだ。

それが本当であれば、万物の理論は純粋に抽象的で数学的でなければならない。

理論がどのようなものになるかはまだわからないが、素粒子物理学と宇宙論は、これまでに行われたすべての測定が、少なくとも原理的には、数ページに収まり、わずか 32 個の未説明の数値定数を含む方程式で説明できる段階に達している。

したがって、すべての正しい理論は、T シャツに書ける程度の方程式で説明できるほど単純であることが判明する可能性さえある。

しかし、数学的宇宙仮説が正しいかどうかを議論する前に、外部の物理的現実を見る 2 つの方法を区別することができる。

1 つは、上空から風景を観察する鳥のような、数学的構造を研究する物理学者の外側の概要。

もう一つは、鳥によって見渡される風景の中に住むカエルのように、構造によって記述される世界に住む観察者の内面の視点。

これら 2 つの視点を関連付ける際の 1 つの問題は時間に関係する。

数学的構造は、定義上、空間と時間の外側に存在する抽象的で不変の存在である。

宇宙の歴史を映画に例えると、その構造は 1 コマではなく DVD 全体に相当する。

したがって、鳥の視点から見ると、4 次元時空内を移動する物体の軌跡は、スパゲッティのもつれに似ている。

カエルには一定の速度で動く何かが見えますが、鳥には調理されていないスパゲッティのまっすぐな束が見える。

カエルが地球の周りを回る月を見ると、鳥は絡み合った2本のスパゲッティが見える。

カエルにとって、世界はニュートンの運動と重力の法則によって記述される。

鳥にとって世界はパスタの幾何学模様である。

2 つの視点を関連付ける際のさらなる微妙な点には、観察者がどのようにして純粋に数学的になることができるかを説明することが含まれる。

この例では、カエル自体は厚いパスタの束で構成されている必要がある。

その非常に複雑な構造は、おなじみの自己認識の感覚を引き起こす方法で情報を保存および処理する粒子に対応している。

では、数学的宇宙仮説を検証するにはどうすればよいか?

まず、自然界ではさらなる数学的規則性がまだ発見されていないことが予測される。

ガリレオが数学的宇宙の考えを広めて以来、素粒子の小宇宙と初期宇宙の大宇宙における驚くべき数学的秩序を捉える素粒子物理学の標準モデルなど、その系譜に沿った発見が着実に進歩してきた。

この仮説は、並行宇宙の存在という、より劇的な予測も行う。

長年にわたって多くのタイプの「多元世界」が提案されてきましたが、それらを 4 つのレベルの階層に分類することが役立つ。

最初の 3 つのレベルは、同じ数学的構造内の非通信の並行世界に対応します。レベル I は単に、光がまだ到達していない遠い領域を意味する。

レベル II は、介在する宇宙の宇宙論的膨張により永遠に到達できない領域をカバーする。

レベル III は「多世界」と呼ばれることが多く、特定の量子事象中に宇宙が「分裂」する可能性がある、量子力学のいわゆるヒルベルト空間の非通信部分が含まれる。

レベル IV は、根本的に異なる物理法則を持つ可能性がある、異なる数学的構造の並行世界を指す。

現在の最良の推定では、膨大な量の情報、おそらく Googol ビットを使用して、観測可能な宇宙に対するカエルの視点を、すべての星や砂粒の位置に至るまで完全に記述する。

ほとんどの物理学者は、これよりもはるかに単純で、T シャツには収まらないとしても、本に収まる程度のビット数で特定できるすべての理論を望んでいる。

数学的宇宙仮説は、そのような単純な理論が多元宇宙を予測するに違いないことを示唆している。

なぜなら、この理論は定義上、現実の完全な記述であるからである。

宇宙を完全に特定するのに十分なビットが不足している場合、星や砂粒などの考えられるすべての組み合わせを記述しなければならない。

そのため、宇宙を記述する追加のビットは単にエンコードするだけである。

多世界の電話番号のように、私たちがどの宇宙にいるのか。このように、複数の宇宙を記述することは、単一の宇宙を記述するよりも簡単になる可能性がある。

極限まで突き詰めると、数学的宇宙仮説はレベル IV の多元宇宙を意味し、その中に他のすべてのレベルが含まれる。

宇宙である特定の数学的構造があり、その特性が物理法則に対応している場合、異なる特性を持つそれぞれの数学的構造は、異なる法則を持つ独自の宇宙である。

実際、数学的構造は「作成」されるものではなく、「どこか」に存在するものではなく、ただ存在するだけであるため、レベル IV の多元宇宙は必須である。

スティーヴン・ホーキング博士はかつてこう尋ねた。

「方程式に火を吹き込み、それらが記述できる宇宙を作り出すものは何でしょうか?」

数学的宇宙の場合、重要なのは数学的構造が宇宙を記述することではなく、それが宇宙であるということであるため、火を噴く必要はない。

レベル IV の多元宇宙の存在は、物理学者のジョン・ウィーラーが強調した混乱する疑問にも答える。

たとえ宇宙を完全に記述する方程式が見つかったとしても、なぜ他の方程式ではなく、これらの特定の方程式が使われるのか?

他の方程式が並行宇宙を支配しており、観察者をサポートできる数学的構造の分布を考慮すると、統計的に可能性が高いため、宇宙にはこれらの特定の方程式があるということだ。

並行世界が科学の範囲内なのか、それとも単なる推測に過ぎないのかを問うことは重要である。

並行宇宙はそれ自体が理論ではなく、特定の理論によってなされた予測である。

理論が反証可能であるためには、そのすべての予測を観察および検証できる必要はなく、少なくともそのうちの 1 つだけを検証できれば十分である。

たとえば、一般相対性理論は、重力レンズなど、私たちが観察できる多くのことを予測することに成功しているため、ブラックホールの内部構造など、私たちが観察できないことについての予測も真剣に受け止めている。

ここに数学的宇宙仮説の検証可能な予測がある。

多くの並行宇宙に存在するのであれば、我々は典型的な宇宙にいると予想されるはずです。

ある量、たとえば、この量が定義されている多元宇宙の一部の典型的な観測者によって測定された暗黒エネルギー密度や空間の次元の確率分布を計算することに成功したと仮定する。

この分布により、我々自身の宇宙で測定された値が非常に非典型的なものになることが判明した場合、多宇宙、したがって数学的宇宙仮説が除外されることになる。

生命の要件を理解するまでにはまだ程遠いが、暗黒物質、暗黒エネルギー、ニュートリノに関して私たちの宇宙がどの程度典型的であるかを評価することで、多元宇宙の予測のテストを始めることができる。

なぜなら、これらの物質は銀河形成など、よりよく理解されているプロセスにのみ影響を与えるからである。

これらの物質の存在量は、多元宇宙のランダムな銀河から測定されるものとかなり典型的なものであると測定されている。

しかし、より正確な計算と測定では、そのような多元宇宙は依然として除外される可能性がある。

結局のところ、なぜ数学的宇宙仮説を信じるべきか?

おそらく最も説得力のある反対意見は、直感に反して不安を感じるということである。

数学的宇宙仮説が真実であれば、科学にとって素晴らしいニュースであり、物理学と数学の洗練された統合により、深い現実を理解できるようになる可能性がある。

実際、多元宇宙をもつ数学的宇宙は、期待できるすべての理論の中で最良のものであるかもしれない。

なぜなら、規則性を明らかにし、定量的な予測を行うという科学的探求から現実のいかなる側面も立ち入れないことを意味するからである。

しかし宇宙についての究極的な疑問を再び変えることになる。

どの特定の数式が現実のすべてを記述するのかという問題は見当違いであるとして放棄し、その代わりに、鳥の視点からカエルの宇宙観、つまり観察をどのように計算するかを問うことになる。

それは、宇宙の真の構造を明らかにしたかどうかを決定し、数学的宇宙のどの隅が私たちの故郷であるかを理解するのに役立つ。

参考文献: 数学的な宇宙究極の実在の姿を求めて by マックス・テグマーク (著), 谷本真幸 (翻訳)

Permalink | 記事への反応(2) | 10:15

2023-11-12

■anond:20230810205950

てか、陰でも陽でもキャが付くうちは俗にいう令和のオタク

平成的なオタクはキャラとして存在が無い

その他大勢の中のキモいオブジェクト

Permalink | 記事への反応(0) | 12:44

2023-11-02

■anond:20231102123229

convolutionは今流行りのNeural Networkで画像系で使われるやつで本来は数学用語なんだけどねー

コンボリューションが「数学」用語というのは違和感あるなあ。

畳み込み演算自体は単純に演算であってそれ以上でもそれ以下でもないっていうか。

フーリエ変換すれば掛け算になるという構造はあるけど、数学的なオブジェクトと位置付けるには抽象化が足りない感じ。

リー群の上の調和解析まで一般化すればいいかなと思うけど。

その場合はニューラルネットがどうとかいう話は余計でしかないよな。（群要素を座標によるレイヤーを定式化しました！みたいな研究はあるが）

恥ずかしすぎて1ミリたりともドヤるような内容ではないな。

Permalink | 記事への反応(2) | 12:57

■anond:20231102121333

机ごちゃごちゃしてるから机に置くオブジェクト増やすのはなんか嫌なんだよなー

Permalink | 記事への反応(1) | 12:37

2023-10-20

■「変数」じゃなくて「変値」だろ

「数」って書いちゃうとどうしても整数や分数などでいう「数（かず）」を想起しちゃう。

これだれが最初に言い出したの？

「戻り値」「値を代入する」などというふうに普段いうのになんで「数」なんだよ。

これのおかげで関数やオブジェクトを「変数」として扱う際の説明をするときに脱落する人がたくさんいるんだよ。

Permalink | 記事への反応(3) | 09:12

2023-10-16

■

動のジョンウィックと静のイコライザー、似たような二作を同時期に観たけど対照的なサマを感じられて良かった。

ジョンウィックはアクションに遊びがあった気がする。一騎当千に飽きさせない工夫というか。満身創痍で暴れ回りつつ、ヌンチャクアクションはコミカルな感じもあった。MGSみたいな俯瞰映像も嫌いじゃない。凱旋門の往来は敵に囲まれるというよりオブジェクトに襲われる特殊ステージのような緊迫感があった。最後は決闘で締めるのも良いね。

犬のくだりとかで一応「報い」というテーマは挟むけど、総じてアクション面で魅せてくる印象だった。

イコライザーの方はもはや敵に倒されてしまうかもしれないなんて不安すらなく、スプラッター映画のように淡々と粛清する感じ。

序盤で惨殺死体の果てに登場する時の佇まいとか、完全に悪役のそれ。教会や十字を挟んで、やりすぎじゃね……？って感じの自問めいたシーン。スントを外してドンパチ抜きの休養で、美しい街と善良な人々の生活をじっくり映す。そしてそれを踏みにじる存在をねっとりと描いて、溜めて溜めての制裁。もはや戦いではなく、一方的。ぶっ刺したチンピラにじっと目を合わせる所とか、瀕死の相手をのたうち回らせて何をするでもなく側についている所とか、完全に異常者のそれ。一作目のDIY戦法、二作目のステーション・バーじみたお節介殺戮おじさんときて、最後は平穏というテーマに重きを置いた感がある。良いね。

イコライザーって音楽とかのやつを先に思い浮かべちゃうけど、確かにイコライズしてたわ。平等にするものが転じて銃をそう呼ぶの知らんかった。ピースメーカーとかと同じか。ホンマに平等になっとるか？

二作とも観て思ったけど、ただ銃で撃ち殺されるとか轢き殺されるとかよりも、ナイフで手を刺す所をジッと映すシーンのほうがウッてなるな。痛みが想像出来る分そっちの方がキツい。アウトレイジの拷問とかもそうだけど。

Permalink | 記事への反応(6) | 21:09

2023-10-15

■今のスマホが撮る写真って「超写実的なお絵描き」レベルまで来たな

色を弄り、解像度を補完し、邪魔なオブジェクトを消し、人間の顔も「こっちの方がいいよ？」というヤツに差し替えて

個々のパーツは見たことがあってもすべて合わせて出来上がった画は誰も見たことがないものをデータとして生成する

「超写実的なお絵描き」になっちゃったな。

もうそろそろチャット AIにパーツの画像渡して「こういう感じの写真撮って」って言えばスマホでシャッター切ったのと変わらない画像が生成されそう。

写真って何なんだろうね。

Permalink | 記事への反応(0) | 08:21

ユーザーの入力を待たず、一秒ごとにカウントが増えていって絵が切り替わるバージョンを作ってください。
カウントの数字をどこかに表示してください。
エスケープか、クローズボタンで終了するまで永久にカウントさせてください。

GPT：

了解しました。以下は指定された条件に基づいて動作するPythonのGUI アプリのコードです。このアプリはtkinterを使用しており、毎秒カウントが増加し、その数値に基づいて画像が切り替わるようになっています。
import tkinter as tk
from tkinter import Label, PhotoImage

def update_count():
    global count
    count += 1
    count_label.config(text=str(count))
    
    if count % 3 == 0 or count % 5 == 0:
        face_label.config(image=goofy_face)
    else:
        face_label.config(image=serious_face)
    
    root.after(1000, update_count)

def on_close():
    root.quit()
    root.destroy()

root = tk.Tk()
root.title("Face Display App with Counter")

# ふざけた顔と真面目な顔の画像をロードします
# 以下の部分は、DALL-Eで生成された画像のパスに置き換える必要があります
goofy_face = PhotoImage(file="path_to_goofy_face_image.png")
serious_face = PhotoImage(file="path_to_serious_face_image.png")

count = 0
count_label = Label(root, text=str(count), font=("Arial", 24))
count_label.pack(pady=20)

face_label = Label(root, image=serious_face)
face_label.pack(pady=20)

update_count()

root.protocol("WM_DELETE_WINDOW", on_close)
root.mainloop()
このコードでも、PhotoImage オブジェクトを使用して2つの画像（ふざけた顔と真面目な顔）をロードしています。path_to_goofy_face_image.pngとpath_to_serious_face_image.pngは、DALL-Eで生成された画像の実際のパスに置き換える必要があります。
このアプリは、毎秒カウントを増加させ、そのカウント値に基づいて画像を切り替えます。カウントの数値も表示されます。エスケープキーまたはウィンドウを閉じることでアプリを終了できます。

ワイ：

どうも有り難うございます。

GPT：

どういたしまして！何か他に質問やサポートが必要な場合は、お気軽にお知らせください。良い一日をお過ごしください！

こっちの方がいいな。

絵がファンキーだから面白いよ。

Permalink | 記事への反応(0) | 00:38

■anond:20231012213839

ワイ：

真面目な顔の人間の男の人の顔の絵を描いてください。

GPT：

＊イメージ省略＊
こちらが真面目な顔の男性のイメージです。ご覧いただき、ご意見やご希望の変更点があればお知らせください。

ワイ：

その男の人がふざけて馬鹿になったふりをしている顔を描いてください。

GPT：

＊イメージ省略＊
ふざけている男性のイメージを作成しました。どのイメージがお気に入りか、または変更のご要望があれば教えてください。

ワイ：

Python の GUI アプリを作ってください。
ユーザーは整数を入力し、リターンキーを押します。
その整数が 3 か 5 の倍数の場合、ふざけた顔の男の顔（一枚目の顔）を表示してください。
それ以外の整数である場合、真面目な男の顔を表示してください。
エスケープボタンか、ウインドウをクローズするまでループし、入力を待機してください。

GPT：

了解しました。以下は、指定された条件に基づいて動作するPythonのGUI アプリのコードです。このアプリは、tkinterを使用しています。まず、必要なライブラリをインストールしてください：
pip install tkinter
次に、以下のコードを使用してアプリを実行できます：
import 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('&lt;Return&gt;', 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：

どういたしまして！何か他に質問やサポートが必要な場合は、お気軽にお知らせください。良い一日をお過ごしください！

内定ゲットや！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

Permalink | 記事への反応(2) | 00:27

2023-10-08

■Windowsのペイントソフト教えて

フリーでいいの教えてくれ

これまではpaint.netっていうの使ってたけど、機能少なすぎる

プラグイン入れるといいらしいけどほとんどが古いもので最近のバージョンはサポートされてない

イラスト書いたりはしないけど、文字を入れて影つけるとか、オブジェクトの切り出しで縁をきれいにするとか、色の調整とか、レイヤ使って合成とかそういうのは使う

Permalink | 記事への反応(0) | 19:31

2023-10-05

:incr というキーを持つ場合、カウンターの値を1増やします。

この無名関数が counter 変数に代入されて、カウンターオブジェクトが作成されます。

その後、counter オブジェクトの .incr メソッドが呼び出されます。初回の呼び出しでは、カウンターが0から1に増加します。2回目の呼び出しでは、カウンターが1から2に増加します。このように、.incr メソッドを呼び出すたびに、カウンターの値が1ずつ増加します。

.reset メソッドが呼び出されると、カウンターの値は0にリセットされます。

最後に、再度 .incr メソッドを呼び出すと、カウンターは0から1に増加します。.reset メソッドを呼び出しているため、カウンターの値は前回の値から リセットされています。

このプログラムは、カウンターの値を増加させたりリセットしたりするシンプルなカウンターの実装例です。Pythonなどのプログラミング言語では、関数やクロージャを使用して、このような動作を実現することができます。

Permalink | 記事への反応(1) | 23:35

2023-09-27

■anond:20230919141733

純粋にプログラミングを勉強したいだけならJavaでもC++でもRubyでもオブジェクト志向取り入れられてる言語なら何でもいいと思う。

潰しが効く云々でいうなら、一番求人数が多い言語勉強すればいいんじゃないか。

Permalink | 記事への反応(0) | 08:42

2023-09-22

■Project Mugen とかいうただのクソカス ゴミ パクリゲーについて

『Project Mugen』という新作ゲームの開発情報が公開された。

https://m.youtube.com/watch?v=ZhdXubIXA-U&feature=youtu.be

これを見て俺は驚愕した。ワイヤーアクションでビル街の空中を飛び回るモーションはただの『Marvel's Spider-Man』のパクリじゃないか！

こんなパクリゲーで勝負するなんて中華企業は自分でアイデアを生み出す発想力がないのだろうか。終わっている。

でもよく思い出すとワイヤーアクションで移動するゲームは『SEKIRO: SHADOWS DIE TWICE』やコーエーテクモゲームスが公開した『進撃の巨人』があったな。

SEKIRO の公開は 2019 年、Marvel's Spider-Man は 2018 年、進撃の巨人は 2016 年、ということはつまり……

なんてこった！

オリジナルは進撃の巨人で、スパイダーマンもSEKIROもProject Mugenも全部ただのパクリゲーだった！じゃあゲーム業界そのものが自分のアイデアで勝負しないクソカスパクリ泥棒社会だったってことか！見損なった！

しかもProject Mugen の罪はそれだけではない。このゲーム、なんと『オープンワールド・アクションRPG』なのである。

ヤバすぎる……オープンワールドは全部 GTA Ⅲ のパクリだ。スカイリムも、今流行っている原神もゼルダティアキンも、ポケモン SV も GTA Ⅲ をパクっているんだ……

あの任天堂ですらパクリに手を染めているなんて、ゲーム業界の闇は深すぎる…… マジで終わっているのかもしれない……。

しかもだ。Project Mugen はオープンワールドの都市のマップを自動生成で作ったらしい。

これは罪が深すぎる！

オープンワールドマップの自動生成は『No Man's Sky』で1800京個の惑星を作るために開発された技術だ。あるいは、『The Matrix Awakens:An Unreal Engine 5 Experience』でも都市の自動生成を開発していた。

こんなものまでパクるなんて、他人の努力を馬鹿にしているのか……。

いやまてよ、そもそもマップを自動で作るというアイデアは、ポケモンの不思議のダンジョンシリーズのような「ローグライク」ゲームで使われる技術だ。そのオリジナルは名前の通り1980年代からある『Rogue』だ。

ということは、ポケモン不思議のダンジョンも、Epic Gamesも Rogue をパクってんのか…… こいつら全員カス過ぎる…… ゲーム業界は本当に人格破綻者しかいないらしい。

そしてRPGは1981年の『ウルティマ』や『ウィザードリィ』のパクリだ。そもそもコンピュータRPGってのは、TRPGのパクリだ。呆れてもう言葉が出ない。

Project Mugen の罪はまだまだある。Project Mugen ではシーンに配置されてるオブジェクトを掴んで動かしたり、敵にぶつけたりする機能があるらしい。

これは『ゼルダの冒険ティアーズオブザキングダム』のウルトラハンドのパクリだし、『SCARLET NEXUS』の念力のパクリだ！

そんでもって、物理演算エンジンをゲームに組み込むアイデアは『リトルビッグプラネット』のパクリだ！ゼルダもSCARLET NEXUSもパクリ泥棒だ！

だいたい、Project Mugen はキャラクターのセルルック(トゥーンシェーディング)な見た目からして、もう既にパクリだ。

最近のゲームだと原神も『BLUE PROTOCOL』もキャラクターの 3D モデルがセルルックに描写されているが、これは『GUILTY GEAR』シリーズのパクリだ。

ていうかセルルックとは「アニメ画のような」という意味なのだから、ゲームなのにアニメをパクっている！

これは文化盗用だ！ゲーム業界の内部だけじゃなくて外からもパクってくるなんて、社会の悪だ！ゲームならゲームのビジュアルで勝負しろよ！

そんでもって、GUILTY GEAR とかスマブラとかの格ゲーって言われるジャンルは全部ストリートファイターのパクリだ。

はあ。俺はゲームっていうのはどこを見てもパクリだらけの最悪の肥溜めなのが分かった。

こんなのは間違っている。ゲーム会社は他人の努力をパクらないで、オリジナリティで勝負しろ。

ワイヤーアクションも、オープンワールドも、アクションRPGも、物理演算も、プロシージャル生成も、セルルックも、クロスプラットフォームも、レイトレーシングも、3D アニメーションも、全部先駆者がいる。

オリジナルに敬意を払ってパクるのをやめろ！

みんなもパクリゲーをプレイするのはやめてくれ！

Permalink | 記事への反応(1) | 17:33

2023-09-19

■anond:20230919114042

もうこのやりとりの時点でダメやん？

ダメじゃねえよ。要件を正確に記述できないならコードなんて書けるわけない。

空気読んでいい感じに読み取ってよというのを求めてるなら、仕様書すら書けないダメプログラマーってことだろ。

コンピューターの中では数字で日付は管理されててそれはJavaでは日付のオブジェクトとして表されるんだけど、「今週＝現在の週の水曜日」を表すオブジェクトが欲しい

やったぞ

Javaの日付オブジェクトとして「今週の水曜日」を表すオブジェクトを返す関数を示してください。

java.time パッケージの LocalDate クラスや TemporalAdjusters クラスを使用して、「今週の水曜日」の日付オブジェクトを取得できます。
以下のコードは、現在の日付に基づいて今週の水曜日の LocalDate オブジェクトを返す Java の関数です。
import java.time.DayOfWeek;
import java.time.LocalDate;
import java.time.temporal.TemporalAdjusters;
public class Main {
public static void main(String[] args) {
System.out.println(getThisWeeksWednesday());
}
public static LocalDate getThisWeeksWednesday() {
LocalDate today = LocalDate.now();
return today.with(TemporalAdjusters.nextOrSame(DayOfWeek.WEDNESDAY));
}
}
この関数は現在の日付を取得し、それを TemporalAdjusters.nextOrSame(DayOfWeek.WEDNESDAY) メソッドに渡して、今週の水曜日の日付を取得します。今日が水曜日である場合、それが返されます。それ以外の場合は、次の水曜日の日付が返されます。

今日が週内のどの日であったとしても（木曜日や金曜日であったとしても）その週の水曜日を表すオブジェクトを返す関数を示してください。

それには、今週の最初の日を求め、そこから水曜日までの日数を加算するアプローチを使用します。以下のコードでは、週の最初の日を月曜日と仮定しています：
import java.time.DayOfWeek;
import java.time.LocalDate;
import java.time.temporal.TemporalAdjusters;
public class Main {
public static void main(String[] args) {
System.out.println(getThisWeeksWednesday());
}
public static LocalDate getThisWeeksWednesday() {
LocalDate today = LocalDate.now();
LocalDate monday = today.with(TemporalAdjusters.previousOrSame(DayOfWeek.MONDAY));
return monday.plusDays(2);
}
}
このコードは、まず今日の日付を取得し、それから TemporalAdjusters.previousOrSame(DayOfWeek.MONDAY) メソッドを使用して今週の月曜日の日付を取得します。そして、月曜日から2日後の日付（水曜日）を取得するために plusDays(2) メソッドを使用します。

Permalink | 記事への反応(3) | 11:50

■anond:20230919113704

もうこのやりとりの時点でダメやん？

コンピューターの中では数字で日付は管理されててそれはJavaでは日付のオブジェクトとして表されるんだけど、「今週＝現在の週の水曜日」を表すオブジェクトが欲しい

Permalink | 記事への反応(1) | 11:40

2023-09-14

■医学部13浪目のとある一日

・起床（12時ごろ）

母親と飯を食う。

・勉強（13時〜14時半過ぎ）

午後から勉強。演習をやる予定だったがなんとなくだるくなり、大森徹の最強講義を読む

・ドラマ（15時半過ぎ〜16時半過ぎ）

母と科捜研や遺留捜査、相棒などを視聴する。普段は相棒が終わったらコンビニに行き副業か勉強に移るのだが、今日はニュース番組を見てダラダラした後孤独のグルメ再放送まで視聴してしまった。

・コンビニ（17時頃）

ドラマを見終えたタイミングでコンビニに行くのがルーティン。コーヒーとオールドファッションドーナツを購入し腹ごしらえ。

・副業（18時〜3時ごろ）

Mayaでキャラクターやゲーム内のオブジェクトを作成したり、UEでステージや背景を製作する。酷いとアイデアだけ提示されてキャラクターやオブジェクトの作成、ゲームシステム自体全て丸投げという案件もある。

影廊やFNAFがヒットしたこともあり、個人でゲームを開発したい、Steamにリリースしてあわよくば稼ぎたいという人は多い。しかし、開発するためのスキルを全員が持ち合わせているわけではなく、この仕事は割と需要がある。正直、俺だってUEのチュートリアルから始めて必要な所はその都度ググったり本を参照して開発しているため飛び抜けたスキルがあるわけではないが、それすらやらずに一攫千金を夢見るアホは沢山いる。そしてそのようなアホが俺の客だ。