プログラミングでオブジェクトを表現すること。 - ページ 6

 

そうして、「オブジェクト」。(些細なことですが、同じレクタングルラベルをとって みましょう)。

1)基本的なオブジェクトの構成要素。

この構成要素はみんな知っているから、興味を惹かれる意味がないんです。多かれ少なかれ、複雑なオブジェクトが持っている。

  • パラメータは 最も基本的な構成要素ですが、最も単純なものではありません。私の考えでは、パラメータとは、システムや環境の構造において、何らかの名前のついたセットや値を表す実体 である、と考えています。パラメータは、集合をその番号で簡潔に表し、これらの構造を再現するコンストラクタ関数の一部である。パラメータの種類はこれだけではありませんが、ここではこのパラメータを中心に説明します。
  • プロパティのセットは、異なる機能、すなわちObjectのキー値や 複雑な構造セットで 使用される「オブジェクトメトリクス」データを統合する、パラメータの複合体である。この例では、ラベルは、x,y, (空間内の位置)、width, height (幅と高さ)、color (色)の5つのパラメータを持っており、すなわち、その初期特性のセットは、それを表す関数の入力パラメータ(引数)から始まりますが、 これに限定されるものではありません。
  • コンストラクタ関数は、オブジェクトを再現する一連の動作(別名アルゴリズム)です。ラベルを描画する関数は、上記の全てのパラメータを使用して実行される。(ラベルの基本パラメータはコンストラクタの実装方法によって決定されることに注意。ラベルの描画方法を変更した場合(例えば、2サイクルから1サイクルで描画する)、ラベルの初期パラメータセットも変更されます)。
  • - 考えうるすべての物体の例に形があることを否定することは難しい。レーベルの形はプリミティブでシンプルですが、レーベルと切っても切り離せない関係です。しかし、形状を持たない物体も存在するため、形状は物体の本質的な構成要素ではありません。形は「生命」の重要な一部であり、それを通して事象、プロセス、状態、傾向など、情報の流れを伝えることができる。
  • ステートとは、オブジェクトが存在する上での意味のある「区切り目」のことです。コーダーの用語では、 -外部環境の条件が変更されたとき、または内部プログラムの独立した実行の過程で、それが通過するオブジェクトのパラメータの値、、、。それは、どんな複雑なシステムにも存在する。この属性は、単純なラベルをシステムに変換し、一連の追加条件によって遷移の論理を形式化することを要求している。一方、ラベルのパラメータセットはまだ原始的な単純なものであるが、ステートを 追加することにより、パラメータ値の可能性が増え、そのために追加のメモリを割り当てざるを得なくなり、ラベルはコンストラクタに加えて、ステートを 切り替える機能を獲得し、原始的な単純オブジェクトから機能 システムに変わる。ステートは、様々なシステムを構成する、より複雑なオブジェクトに内在するものである。
  • イベントは、さらに複雑なレベルのObjectの属性である。しかし、イベントを追加することで、この連鎖を断ち切り、新しいトランジション・シークエンスを導入し、最終的にタグ(オブジェクト)に、より複雑な動作システムや環境との相互 作用を統合させることができます。しかし、これについては後述するとして、イベントの 定義とそのソフトウェア実装に話を移そう。

イベントとは、オブジェクト自身またはその環境に対する意味のある変化の ことである。構造的に、イベントは、変化が起こる条件であるそのオブジェクト(タグ)の背景状態の記述または表示を含むかもしれないが、イベントを記述するその主なタスクは、タグ、またはそれを統合するシステム、または変化 そのものの外部環境に起こったことを伝えることであり、特定の(初期または派生)パラメータの特定の値、システムまたはタグ環境に存在するいくつかの値の関係を通じて、またはそれ自体が変化したならば変化の性質(署名)の構築を通じて表現されることができる。これらはすべて、「イベント」として捉えることができます。*後ほど、オブジェクトの構成要素のプログラム的な記述 の問題に戻ります。

  • プロセスは、次のレベルの複雑さです。パラメータは構造化されたセットを記述し、オブジェクトのプロパティは 選択されたパラメータを複合化し、コンストラクタ機能はオブジェクトのパラメータセットを結合し、状態はパラメータセットとフォームの両方を結合することができます。イベントは、状態を組み合わせて、意味のある変化が起こった背景を記述し、その後にプロセスを記述することができます。

プロセスは、オブジェクトの状態とイベントをシーケンスに統合します。これは、オブジェクトの選択された一連のパラメータの値をある方向に並べた「チェーン」または「シリーズ」として表すことができます。最もよく似ているのは、セルの値がランダムまたは計画的な「過程」によって条件づけられている数値列であろう。しかし、プロセス自体は、このような数値行が多数あり、それぞれがパラメータに割り当てられている。プロセスの作成は簡単で、コンストラクタ関数などの初期パラメータを受け取り、それぞれのパラメータに対して一連の値を生成(または取得)するだけです。また、プロセスを状態、イベント、それらの間の遷移に分解することも容易である。部品と階層に分解され、部品は任意または事前に定義されたシーケンスでリンクされます。重要なのは、「プロセス」を構成要素に「分解」できること、あるいは構成要素から「組み立て」ることができることです。プロセスをモデル化し、最適化し、修正することができます。プロセスは、オブジェクト自体の中にも、オブジェクトの環境にも存在する。この場合、環境は「メタ・オブジェクト」として機能する。

ここで付け加えておくと、プロセスは、どんなに複雑に見えても、イベントとステートに組み合わされたパラメータ値のシーケンスに過ぎず、オブジェクト構造を記述するパラメータの初期セットに基づいて構築され、そのコンストラクタ関数(または、オブジェクトのライフを実装する関数)で使用される。

これで第一部は終了です。第二部では、オブジェクトの複雑さの次のレベルへと進み、システムのイベントモデルと論理モデル、その構成要素と構築原理について考察していくことにする。

第三部では、哲学的な定式化から、ソフトウェア・オブジェクトやコードの新しい実装の問題へと進んでいく(これは簡単なことではないだろうが)。

 
Реter Konow #:

非常に興味深い質問ですね。

1. 私たちの発話(あるいは他のあらゆる形式の思考表明)が時間の中で展開されるため、物理的に 線形であることは議論の余地がない。しかし、思考には 物理的次元だけでなく論理的 次元もあり その論理性の観点から線形であると同時に弁証法的でもありうるのである。例えば、私がわざわざOOPの原点に立ち返ったのは(人類がリニアであるのに対し)、論理的な 思考の非リニア性の 例であり、あなたの言うリニアは一般に認められた秩序でしかないのですね。思考は「行ったり来たり」することで、常にそれを壊している。ただ、最初に一歩下がって自分の行動を考え直すことなく、定理を証明しようとする)。

ATP SPASS/HOL/NuPRLなどの形式的な証明システムとは異なり、直感と博識によってある論理的枝から別の枝にジャンプできることには同意しますが、そうした「前後」のジャンプでさえも、例えば、あるフレームワークで疑似ランダムな仮定をしてそれを再び形式的に証明できると想像すれば、線形で(理論的には)アルゴリズム化可能なのです。

de Bruijnの原則を思い出すことができます。システムは2つの部分から構成されます。コンパクトな形式論理カーネル-検証器は、すべてのATPが行うことを行い、その隣には、外来データ(直感、シャーマニズム歌、mql5フォーラムの投稿など)に固執できる、できるだけ大きなものを配置します。

だからこの場合でも、アルゴリズムは逐次的でチューリングに収まるので、線形システムを得ることができる...。用語の使い方がゆるいかもしれませんが、私は人情派なので許します、何か立派な数学者の方が訂正してくれれば...と思います。

非決定性潜在的無限オートマトンだけでなく、多くの非同期演算を同時に実行できるオートマトンも必要かもしれない。

ランダムな数学テキストを生成するMathGenプロジェクトを思い出すと楽しいです。https://thatsmathematics.com/mathgen/。


2.世界を理解し、認識する人間の能力の限界という説には賛成です。自分の限界を見つけるのは、それほど難しいことではありません。例えば、人間は大きな集合に到達して処理することができない、エントロピーの高い動的なカオスを予測できない、などなど...。でも、どのくらい必要なんだろう?人間は、「普遍的なもので実存を包み込む」能力をうまく拡張する技術を生み出す。カントはこのことについて何も言っていないと思う)。

例えば、メタオブジェクトのモデルを作っていて、ある時(例えば50年頑張った後)自己検証オートマトンが必要になった時、ゲーデルが飛び出してきて、「そんなのダメだ!」と言ったとする。- 第2水準以上の述語を持つ形式的な公理系では、(私が間違っていなければ)形式的には正しいが、証明にも反論にもならない文が必ず見つかるはずで、どうしたらいいのだろう?- 工場に戻る?

興味深いことに、いくつかの暗号通貨プロジェクトはチューリング完全性を達成すると主張していますが、ここでも純粋にマーケティング策略として、彼らは欺いているかもしれません。特にEtherプラットフォームはチューリング完全であると主張し、Bitcoinなどは逆にデザイン的にチューリング完全でないことが知られていますが、誰かが実際にこれを確認したのか、それが問題で、どの程度までそれが本当なのか・・・。


3.ハイパーオブジェクトやメタオブジェクトといった概念については、いろいろなところで何度か言及されていますね。この点については、次回の記事で、私のコンセプトにおけるオブジェクトの中身を公開したいと思います。

最終目標は新しいAIエンジンを作ることなので、コンセプトはできるだけプログラミング志向で作ったので、説明も例もすべてコーダー志向になることを付け加えておきます。

私がティモシー・モートンの解釈に従って使ったハイパーオブジェクトとは、時間と空間の中に大量に分布し、特定の局在を超越した物体であり、ここで興味深いのは、数学や技術科学が芸術、神話、魔法に触れ始める領域であることだ......」。腹心の部下たちは、たとえばカオス・マジックの禁断の儀式におけるハイパーシグルの概念についてよく知っている。それは現実に複雑な影響を与える方法だが、このテーマについて発表されるものはたいてい最も黒い猥雑さと不吉な悪魔主義の厚いベールに包まれているが、もしそれを捨てれば。となると、現代の地政学におけるハイブリッド戦争や分散型抗議行動に似た、情報を受け取ることのできるオブジェクト/サブジェクトに対する情報的影響を含む複合的影響の原理が残る。メタオブジェクトはおそらく、ハイパーオブジェクトの一般化で、非局所の時間外だが依然として特定できるプロセス、ほとんどアーキタイプに似たものと考えることができるだろう。

 
昨日も言いましたが、19年から始まって、今また話題になっていますね。
 
Реter Konow #:

そうして、「オブジェクト」。

すぐにバッカス・ナウル形式で書き留める。既に存在するバリアントとの整合性や同型性を確認することが可能となる。

 

これはすべて、トレードをする上でとても重要なことなのです

文脈依存型形式文法の氾濫を打破しよう

 
Aleksey Nikolayev #:

ベックス・ナウル形式ですぐに書き出す。既に存在するバリアントとの整合性や同型性を確認することが可能になる。

例を示してください。

 
transcendreamer #:

これはすべて、トレードをする上でとても重要なことなのです

文脈依存型形式文法の優位性を打ち破れ!

価格は文脈依存の確率的文法と考えることができると思います)。

 
Aleksey Nikolayev #:

価格は文脈依存の確率文法と考えることもできると思います)。

あの...たぶん、その後、確率的なルールを持つシーケンス:用語/シグネチャWXYZのようなとそのような観察されたシーケンスがあった場合、さらに多分ABC、ABC、BAC、ABC、CAB、CBAのいくつかの確率でそのベクトルは確率空間の聖杯を指すことになる。😁

 
Aleksey Nikolayev #:

価格は文脈依存の確率的文法と考えることができると思います)。

しかし、根幹はマルコフモデルであり、明らかに市場背景への依存は考慮されていませんよね。

 
Реter Konow #:

例を示してください。

整数とカンマで区切られた整数のリスト(リストは空でも可)

<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

<integer> ::= <digit>|<integer><digit>.

<リスト> ::= <"">|<整数><","> <リスト