アルファベット...トピックに関する考察...完了

1.アルファベット。 連想接続。



アルファベットについて多くのことが言われているので、最初にカール・ビューラーの「言語理論」を引用します。

「アルファベットは連想連鎖（機械的シーケンス）であり、それ以上のものではありません。 しかし、誰もが彼を学び、知っています。 したがって、オブジェクトのシーケンスをアルファベットにマッピングすると便利な相関関係になります。 私たちは、合理化のために常に実際にそれを使用しています。 自然言語を構成する標識のシステムには、多くの連想連鎖と織り合わせがあり、それらは心理学的な観点からアルファベット順と同じレベルにあり、私たちの知識を合理化する包括的なタスクで同じサービスを提供することを証明することは難しくありません他の人へのこの知識のオブジェクトとメッセージについて。」



そのため、アルファベットの各要素を値に合わせて配置する必要があり（実際に現在実行されています）、この質問を閉じます。 ただし、すべてがそれほど単純ではありません。 アソシエーションのセットAのアルファベットを考慮することは論理的です。iがjとaiおよびajに等しくない場合：Aの場合、AIはAJ = emptyになります。

記号セットS（Symbolクラスのオブジェクト）から言語l：L（Lは言語セット）のアルファベットへのマッピングTは、Tlで示されます。 それらは、関連のソースの一種です（リレーションTlを介して）。 Tlの符号のマッピングによって生成される関連セットは、Al（言語l自体のアルファベット）で示されます。 セットA1は有限であり、番号を付けることができます。これはアソシエーションまたはアルファベットのコードになりますが、記号のコードと呼ぶのは明確に間違っています。 言語lの符号sによって生成される関連付けは、Tl（s）で示されます。 Tl（s）：Al。 複数のキャラクターが同じ関連付けを引き起こす可能性があります。 たとえば、大文字の記号「A」と小さな「a」は同じ関連付けを生じさせます。 したがって、Tl（s1）とTl（s2）が交差するようにs1：Sおよびs2：Sが存在する可能性があります。 これが1つのポイントです。 2番目のポイントは、この関連付けが環境に依存すること、または各言語ごとに独自の関連付けのセットがあることです。 つまり 英語、フランス語、ロシア語の環境では、同じ記号が異なる関連付けを引き起こす可能性があります。 通常、マッピングTlを実装するには、関連付けテーブル（リレーションTlでもあります）を構築すれば十分ですが、たとえば、楽譜、地図作成、電気回路の構築など、より複雑なアルゴリズムを使用することもできます。

。

2.文字をグループ化します。



ただし、すべてのカテゴリの標識について、独自の関連付けテーブルを作成する必要はありません。 すべての言語に共通する関連性を呼び起こす兆候があります。 真の、さらに強力なステートメントが真です。異なる言語の異なる関連付けは、通常文字と呼ばれるオブジェクトのみを呼び出します。 このプロパティを強調するには、それらをレターグループに結合します。 そして、グループへの分割はすでに行われているため、多くの兆候をいくつかのグループに分けます。

グループは数字（デジタルグループ）であり、0、1、2、3、4、5、6、7、8、および9の記号が含まれており、現代のすべての言語で明確かつ同一の関連性が生じます。

すべての制御文字と書式設定文字を含む制御文字グループ（コマンドグループ）。 現代の標準では、このグループのアソシエーションが使用されますが、管理するアソシエーションに直接表示される標識は提供されません。 いくつかの奇妙な論理により、このグループのT文字のマッピングはありません。また、グラフィック表示では、空の関連付けを使用する文字が使用されます。 つまり 改行の関連付け（KOI8標準のコード10）に直接表示される文字はなく、改行を表す文字はKOI8標準のコード182の「文字関連付け」に表示されます。

マークグループには、角かっこ、引用符、カンマなどが含まれます。 この文字グループの基本的な違いは、字句解析に参加せず、独立したトークンであるということです。 つまり 一連の文字に参加することでトークンを形成するのではなく、独自の存在に参加します-解析に直接不在です。

文字グループには、別の機能があります。これは、このグループの文字の主な目的です。これらの文字のシーケンスは、トークンと呼ばれる独自の関連付けを形成します。 トークンは、他のグループの記号によって互いに分離されています。その記号の1つはスペースです。

キャラクターをグループに分割した後、それらの関連付けを対応するグループに適宜分割できます。 任意のiおよびj：L、s：文字の場合、Ti（s）= Tj（s）= Asであることに注意してください。 この事実により、これらのグループの兆候により、すべての言語に対して単一の関連テーブルが作成されます。 また、これに加えて、Letter以外のすべてのグループでは、「register」プロパティ（大、小）は意味がありません。



3.データ入力。



上記のすべてのグループは、物議を醸す1つの品質によって結合されており、それらはすべてキーボードから入力できます。 これを行うために、彼らはキーボードを発明し、文字エンコーディングとキーボードレイアウトの両方の標準を発明しました。 ここでは、関連付けではなく、キーボードから入力される記号であることを強調します。 そして、キーボードコードとアソシエーションコードを一致させようとすると、物事の実際の状態に対する頑固な抵抗に直面します。 しかし、もちろん、実際に必要なすべての兆候の導入を想定することは不可能です。 したがって、キーボードの機能を拡張する必要があります。 キーボードの目的は、押されたキーと記号を直接対応させることですが、そうすることは常にキーボードのサイズを不合理に大きくすることを意味します。 したがって、キーを組み合わせる方法（複数のキーを同時に押す）を使用すると、文字のコントロールグループにとって便利です。 そして、疑問が生じます。すでに標準になっている機能（コピー、削除など）の文字標準を拡張し、編集するために新しい文字（新しいセクション、メモなど）を追加するときではないでしょうか。 本当だと思う。 そして、このために、それぞれについてグラフィックイメージを作成します（多くの場合、既に考えられています）。 特殊なシーケンスを使用して、文字の組み合わせが引き続き可能です。 いわゆる構図。 この手法は、絵文字（コロンと括弧のシーケンス）またはsign®などに広く使用されています。 合成文字の文字を入力するためのアプリケーションは、カスタム文字と絵文字に十分な機会を提供します。

環境に応じて、文字とキーボードキーの対応を変更することをお勧めします。 キー上の文字のイメージを変更できるLebedevキーボードは、私たちの原則とよく一致しています。

4.オブジェクトとして署名します。



4.1。 エンコード。 文字のセット。



これは、モニターとプリンターのグラフィック機能に違いがなく、各文字が「鉄」でエンコードされていた時代に由来します。 たとえば、英語とロシア語の文字「a」は、同じ文字ですが、エンコード方法が異なります。 そのような例はたくさんあります。 これにはあまり意味がありません。 さらに、本当に必要なサインの多くは十分ではありません。 さらに、ロシア語と英語以外の言語を使用する場合、英語とロシア語の文字への条件付き分割は明らかに批判に耐えられません。 たとえば、ラテン語またはフランス語。 それから、誰が文字「p」がどの言語に属しているのかを教えてくれますか？..そして、私はそれが単なる記号であり、この記号をオブジェクトと見なすと、「Language」プロパティがありません。 そして、これは原則の問題です。 このプロパティを論理的に考えると、「言語」にはWordオブジェクトが必要です。 つまり 文字のシーケンス（グループ）！ その場合でも、このプロパティは記号のシーケンスによって一意に決定されるわけではありません。 文字の1つのシーケンスが異なる言語で異なる意味を持つ可能性は完全にあります。 または多分同じ。 例：「petitio principii」。 これらの文字は何ですか？それはどの言語ですか？ または、スペース ""またはコロン "："がどの言語に属するのか、完全に明らかなのは何でしょうか。 これから一つだけが続きます。 サインはサインでなければなりません。 そして、たとえ彼が例外的な性格のために言語のアルファベットに属していたとしても、これはそのような事実に過ぎません。 通常、形容詞「英語」または「ロシア語」を記号に適用するのではなく、音に適用すると、記号のイメージが正確に具体化されます。 したがって、言語で異なる文字エンコーディングを使用する一般に受け入れられているアプローチは正しくありません。 他の言語とのスペルが異なる、または一致する文字セットはレターグループのみに関連するため、このためにバイトを選択し、多言語セットを使用することでグループ内でエンコードできます。 そしておそらく、インドヨーロッパ言語のグループ全体に1セットで十分です。



4.2。 大きな手紙。 並べ替え。



最初のモニターとプリンターはグラフィック機能が制限されていたため、大文字用に別のエンコードが提供され、これに関する質問は終了しました。 このコードの値は、比較操作のパラメーターとして機能し、大文字と小文字を区別する問題と区別しない問題を簡単に解決できます。 サインをオブジェクトと見なすと、レジスタがどうなりますかという疑問が生じます。 これはプロパティですか、それとも新しいサインですか？ 実際、質問は次のとおりです。大文字を同じ文字と見なしますか、それとも別の文字と見なしますか？ 回答：これらは同じことを示す異なる兆候です。 言うまでもなく、それらをグループにまとめることができます。 質問は結合するだけですか？ ここで再び疑問が生じます、サインとは何ですか？ それは単なるイメージですか？ または、セマンティックロードに興味がありますか？ むしろ、セマンティックロードが重要です。 次に、このセマンティックコンテンツの下で、画像オプションを組み合わせる必要があります。 しかし、画像がどうですか？ 次に、イメージはセマンティックロードに移動する必要があります。 したがって、画像は実際には記号であり、それ以上ではありません（象形文字を思い出してください）。 この画像で私たちが述べたポイントは、2番目の質問です。 これがサインである場合、新しいオブジェクトの作成は論理的であり、エンコーディング標準の作成者は、大小の各文字に個別のコードを定義することで正しいことをしました。

このプロパティの意味は何ですか？ それとも、プロパティではなく、別の記号ですか？ 実際、別の文字については、グラフィックイメージで区別できる場合を除いて、それが大きいか小さいかを言うことはできません。 つまり 実際、この概念は大小に関係なく、隣接する文字またはデフォルトのフォントサイズに依存します。 したがって、これは独立したプロパティであり、フォントサイズまたは隣接する文字に基づいてグラフィックイメージ（および並べ替え）に明らかに影響します。 これで、文字のサイズを好きなように変更できるようになったため、大文字を個別にエンコードする必要がなくなり、文字にそのようなプロパティ（ケース）を提供する必要があります。 ここでは、制御文字も、マークグループのマークも、カスタム文字もこのプロパティを持たないことに注意してください。 彼らには意味がありません。 考える時間ですが、記号から継承されたクラスですか？



4.3。 並べ替え。



通常、文字をソートする必要性は疑いの余地はありません。 しかし、それは引き起こした。 まず、記号をオブジェクトと見なす場合、この質問の解決策はオブジェクトを並べ替える特殊なケースであり、本質的にはオブジェクトのクラスで比較演算を定義することです。 この問題を解決したと仮定しますが、比較操作を決定するための基準が必要です。 現在の状況では、シンボルコードがそのような基準として機能します。 同じコードが画像形成のパラメーターであり、これらは完全に異なる機能負荷です。

第二に、キャラクター自体はすでにソートされています。 現時点で受け入れられている状況では、シンボルコードは、このシンボルに関連付けられたテーブル内の位置のシリアル番号です。 私たちの場合、Symbolオブジェクトはいくつかのグループで定義され、独自のロケーションインデックスも持っています。これは比較演算の引数にはなりません。

したがって、シンボルコードには3つの異なる機能があります。それは、配列インデックス、グラフィックイメージのパラメーターの1つ、比較操作のパラメーターの1つです。 動的なユーザー生成の文字形成を実行する場合、これらは3つの異なるプロパティであり、1つのプロパティではありません。 したがって、関連付けとの比較の操作について

しかし、大文字と小文字を区別して、または区別せずに比較操作を実行する方法の問題に加えて、潜んでいる質問もあります。 文字に「言語」プロパティがない場合、異なる言語の文字をどのように比較しますか？ そして、答えは頼みます。 しかし、トークンのソート時にはソートの必要性が生じます。 個々の文字を並べ替えることは意味がありません。 そして、トークンには言語プロパティがあり、トークンはいくつかのクラスに属します!!! つまり、ソートは記号ではなく意味に適用されるという結論に達しました。 同じことがデジタル帯域でも言えます。 記号ではなく、値で並べ替えます！



5.逆マップ。



関連付けから署名まで、逆マッピングが必要です。 前述したように、1つの関連付けは異なる記号によって生成されます。 ただし、実際には、関連付けは内部のニーズにのみ使用され、常に何らかの記号によって生成されます。 現代のアプローチでは、管理アソシエーションを使用する必要がある場合、そのような必要性が生じます。それは、アソシエーションに独自のサインがないためです。 つまり 新しい行に移行するか、何らかの方法で出力用に情報をフォーマットする必要がある場合は、VBまたはCのようにトピックchr（10）で何かを構成する必要があります。必要な文字を安全に配置できます。必要です。 予想どおり、彼はテキストの外観を変更します。 ただし、制御文字がテキスト定数である場合、その制御機能は機能しません。 つまり 引用符で囲まれた制御文字は、その制御プロパティを失います。



6.グループマーク。



6.1。 記号「=」。



一般に、この問題の歴史は古く、論理的関係と意味の適切な割り当てに関連して、異なる記号の基準がまだ登場していない理由は私には明らかではありません。 原則として、この記号のさまざまな用途を文脈で区別する翻訳者を作成することができます。 しかし、これには、翻訳中のリソースのオーバーヘッドと、構文構造の制限が伴い、翻訳者がコンテキストを一意に識別します。 異なる言語では、この質問はさまざまな方法で解決されます。 クラスC言語では、通常、割り当ては等号「=」で示され、論理関係は二重記号「==」で示されます。 Pascalクラス言語では、割り当ては二重の "：=" a、単一の "="との論理関係によって示されます。 VB言語は、両方のアプリケーションに1つの「=」記号を使用し、いくつかの制限とデフォルトを受け入れます。 その1つは、同じ行での演算子のコロン区切りです。

私は思うし、同じサインの3回目のアポイントメントでなければ、これから何かを思いつくだろう。 ラダシステムで宣言された統一フォーマットとオブジェクトパラダイムのさらなる開発に関連して疑問が生じました。 オブジェクトプロパティの値（または式）を決定するために使用される「=」記号は、（Dim演算子によって）動的に作成されたオブジェクトに値を割り当てる操作においてまったく異なる意味を持ちます。 実際、違いは、エディターでオブジェクトを作成するとき（たとえば、現在グラフィックウィザードで行われているが、同じ割り当てにはテキストタイプがある）、たとえばTop = 2などのプロパティを割り当てると、この値2は作成された要素のストレージ形式に保存されることです、この要素を読み込むとき、この値は既に対応するメモリ位置にあります。 Moveコマンドを使用してこの値を入力する必要はありません。 割り当てコマンドTop = 2を直接実行し、したがって、トランスレーターによって対応するコードを生成します。 HTMLでも同様の状況に直面しています。 そこでは、割り当ては割り当てコマンドにはなりませんが、何らかの価値があります。 オブジェクトがタグ付きで作成されていると仮定すると、トランスレーターがプロパティを割り当てるためのコマンドは生成されません。 対応する値は、単にブロードキャスト後に適切な場所にバイナリ形式ですでに存在しています。

コンセプトでは、.Netは静的プロパティの一種です。 つまり オブジェクトを作成する必要のないアクセスのプロパティ。 しかし、.Netの概念はプログラム、つまり クラスを作成するオブジェクトについてのみ。 また、プログラミング言語は（プログラムの作成方法という意味で）オブジェクトを作成しません。 また、Ladaの概念では、オブジェクトの作成はプログラムの作成と同じプロセスです（プログラムはオブジェクトでもあります）。 さらに、オブジェクトは、書き込み中、デバッグ中、実行中の両方でプログラム内に配置できます。 これは、プログラムの設計プロセスと運用の両方のメンテナンスに非常に役立ちます。 例で説明しましょう。



例1.オブジェクト「プログラムの締め切り」のプログラムのテキストでの作成。



タグ「プログラム完了日」：日付

{

値=ポインター「TZレシート」：データ。 ¤Value+ 2Month

}

TZの受信日を含むタグがある場所を想定します...この例では、プログラム実行時間の値の割り当てが実行されます。 割り当ては、翻訳の段階（オブジェクトの作成中）で技術的に行われ、その後追加操作が実行され、この追加の結果が「プログラム配信期間」オブジェクトのValueプロパティの値に保存されます。 この値は、プロジェクト管理の情報として役立ちます。 プログラムを起動し、「プログラムの締め切り」オブジェクトにアクセスするためのクラスを作成する必要はありません。 ソーステキストが付随する場所に保存されていれば十分です。 このような割り当てでは、プログラムで行われているように、オブジェクトの作成時に追加および割り当てコマンドを生成し、データのアドレスを生成し、それらにスペースを割り当てる必要がないことは明らかです。 新しい日付値は、プログラムの実行中ではなく、ブロードキャスト中に生成および割り当てられます。 作成されたオブジェクトがプログラムではない可能性があることは言うまでもありません。 そして、プログラムで同様のことが起こります。



例2.プログラムの納期の計算。



薄暗いDateTZ：日付

... ...

薄暗い値：日付

値=日付。 ¤Value+ 2Month



この例のまったく異なる図。 これは一般的な状況です。 どこかで、T.Z。の受領日を持つ変数。 （DateTZ）。 変換の結果、Dimオブジェクトと、オペランドアドレスを持つ割り当てオブジェクトと式オブジェクトが作成されます。 プログラムが実行されると、データ用のデータ領域が（Dim演算子によって）割り当てられ、この一連のコマンドを実行するときが来ると、追加が実行されてから割り当てが行われます。

翻訳者によるコンテキスト分析への割り当てを決定するタスクを再び行うことができますが、静的クラスの無効な割り当てを分析する機会を奪います。 そして、さらに進んで、静的クラスなどのパラダイムを放棄することができます。 実際、それらの役割は、定義のある領域での関数またはメソッドのパフォーマンスです。 新しい概念を作成し、その目的を説明しようとするために、より直感的に明確なカテゴリを放棄する理由はないと思います。

したがって、「=」記号の3つの異なる目的を識別するために、単に新しい記号を導入することを強制されます。 さまざまな種類の割り当てに2つの矢印を使用し、論理関係には「=」記号を残したいと思います。

参照オブジェクトに対して定義された等価性（または同一性）の操作を追加したいと思います。その後、中括弧または括弧で、2つの参照オブジェクトを比較するプロパティのリストになります。 例えば



AB {場所、サイズ}



異なるクラスのオブジェクトであっても、同じプロパティを持つことができます。



割り当て 次に、正しい割り当てを次のように定義できます。

または、一般的に定義可能な関係をさらに進めることができます。



6.2。 交換のサイン。 「> <」。



そのような兆候はありません。 「>」と「<」の2つの記号で構成しました。 しかし、便利な演算子。 2つの変数の値を変更する必要がある場合は、3番目の変数を決定して中間値を保存する必要があります。 もちろん、そのようなマシンコマンドはありません。 しかし、プロシージャ（およびプログラム）の形式には、式を計算するときに（中間結果を保存するために）この目的で使用する場所が予約されていることが以前からわかっています。 この操作に使用しないでください。 はい 適切なサインがないことは大きな問題です!!! 双方向矢印が非常に適しています。 またはそのように。



6.3。 関係オペレーション。 「=>」、「<=」、「！=」。



言葉なし。 モデルデザイナーは、ある種のデザイナーです。 しかし、適切な兆候を考え出す時が来ました。 感嘆符が拒否を示すCのアプローチに特に感銘を受けました。 セマンティックロードに対応しない記号でオーバーロードされたテキストを読むことは、非常に刺激的なアクティビティです。 このような貧弱なグラフィックス機能はありますか？ 結局のところ、長い間、より少ない、等号、より重要なものを指定するための確立された指定があります。 ダッシュの下部にあるより多くの等号を示すため。 不等式はバツ印で示されます。

いわゆる組成標識を適用することが適切です。 文字がオブジェクトと見なされる場合、字句解析を使用して（または編集中の字句解析の前でも）、複合文字を1つに結合できます。 たとえば、「：=」の文字「：」および「=」。 または3つのドット。 「...」では、同じように絵文字やその他の何らかの記号であるグラフィック要素を取得します。 構成文字はグループにアルファベットを追加し、標準文字と一緒に解析に参加できます。



6.4。 操作＆および|。 量指定子。



この記号は、一部の言語では論理演算を示し、他の言語ではテキスト連結を示すために使用されます。 両方の兆候が必要な場合はどうすればよいですか？ または、データ型ごとに操作を終了して決定します。 操作または|記号を適用します。 決める必要があります。 数学的論理で長い間使用されてきた記号は、実際に適合するでしょう。 そして（または（否定（¬）、含意（）および等価の2つの符号（、≡）。ただし、演​​算+および*は各タイプに対して定義されているため、演算およびORでそれらを使用することはかなり可能です。

従来、ロジックでは、普遍性（）と存在（）の2種類の数量詞が使用されます。 Fが単一の変数xを含む式である場合、（x：F）は、Fが問題のすべてのオブジェクトを保持することを主張する文であり、（x：F）-それらの少なくとも1つについて。 したがって、述語間の関係を記述することが可能になります。 たとえば、（x：person（x）mortal（x））や（x：y：manager（x）person（y）friend（x、y））などの有名なステートメントを作成します。



6.5。 進歩的な手術。



多くの操作のために標準表記が開発されました。 これは、インデックス、積分、微分、その他の多くによる合計と積です。 言語で高次関数が許可されている場合、いくつかの（およびそれらは長い間形成されている）記号で定義してこれらの操作を実行することは大きな問題ではありません。 私たちの言語は次のとおりです。



例3.プログレッシブ合計。



i = n∑mA [I] 2または



例4.プログレッシブ製品。



I =0n-1A[I2または



あなたは積分で同じことをすることができます、そして微分と他の問題について忘れないでください。



7.グループマーク。



同じ「鉄」の時代から、「改行」と「復帰」のコードは伸び続けています。 タイプライターが自動化されたとき、これは理にかなっています。 その後、関連性がありました。 しかし、今、なぜこれらの2つの制御コードですか？ ここでは、タブが役立ちます。 制御コードとしてではなく、スペースの数（スペースだけではないかもしれません）を含むトークンとして、そしてもちろん、デフォルトで何らかの値（量）を持ちます。 実際、タブのインデントの長さはピクセル単位、または相対単位であり、スペースの数ではありません。 そして、テキストの配置が不可能になります。 矢印は、Wordで使用されるラインフィードのタブレンダリングに非常に適しています。 一般に、制御文字には、制御コードの表示モードで開く視覚的表現が必要です。 結局のところ、個別の改行コードと改行を視覚化する個別の符号コードを持つことは完全に論理的ではありません。 実際、これは私が言及したものだけでなく、すべての制御コードに適用されます。結局のところ、制御コードの意味は何ですか？はい、テキストの編集と書式設定！また、タイプライターレベルではなく編集できるようになった場合、ラインフィードやページ翻訳だけでなく、新しいセクション、メモ、コメントなどの制御コードの標準化をやめたのはなぜですか？グラフィック編集のレベルまで機能を拡張してみませんか？

ギャップについて。位置と標準サイズの看板で、すべての文字がカスタマイズされている場合がありました。しかし、今では兆候ではなく、占有されていないスペースのサイズを持つことはかなり可能です。各フォントとフォントサイズの最小値でみましょう。

ハイフネーションと書式設定を許可しないスペースも考えます。フォーマットを禁止した式を書きたい場合。たとえば、テキストの外観（または場合によっては意味）を変更することで、書式設定が作者のアイデアに違反する可能性がある特別な方法で検索する必要がある数式または例です。または、いくつかの単語で単一の意味を示す記号「_」を使用する場合に役立ちます。例：Calling_to_function。実際、これは単一の概念またはオブジェクトの指定です。もちろん、下線の代わりにスペースを使用する方が便利です。これは、文字のように、フォーマット時にこの文字シーケンスを分割できないようにします。つまりスペースにしたいのですが、これは文字に似ていますが、スペースのように見えます（つまり、まったく見えません）。

したがって、4つのスペースが推奨されます。タブ機能を実行する1つ。 2番目のものは単語の区切りとして機能し、フォーマットすることができます（特定の最小値から増加する方向にスペースをサイズ変更します）。 3番目のスペースは編集時のみサイズ変更を許可し、フォーマット時には変更されません。4番目のスペースは3番目に似ていますが、セパレーターではありません。機能的には、背景色を使用してスペースを区別できます。

このアプローチを記号に適用し、制御コードがグラフィカルな表現を持つ場合、テキスト変数に対して文字をコードに、またはその逆に変換する機能（韻をおizeびします）を使用するトリックは必要ありませんが、グラフィックイメージはテキストをフォーマットするための制御文字。そして、エディターだけでなく。



8.希望する標識。

集合論からの兆候：

所属の兆候。 

属さないサイン

看板の空白を。

スイッチオン

サインlockロック付き

スイッチオンサインright右にスイッチオン

サイン右にロック付きスイッチ

オン

サインsign ターンオンサインなし 無限大サインmaximum最大値として

Union

交差点

符号角

平方根√ ほぼ

同じ

約

場合

場合かつ、

その後のみ



メンバーシップ記号は、配列またはコレクション内にこのオブジェクトが存在するかどうかの埋め込みチェック付きのループではなく、論理式として実装できます。

ブール値のTrueとFalseには、はるかに先に別の文字を推奨できます。

たとえば、TrueおよびFalse。



ポインタ用に別の記号を作成するとよいでしょう。