[
https://issues.apache.org/jira/browse/TINKERPOP-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18019706#comment-18019706
]
ASF GitHub Bot commented on TINKERPOP-3173:
-------------------------------------------
Cole-Greer commented on code in PR #3195:
URL: https://github.com/apache/tinkerpop/pull/3195#discussion_r2342523650
##########
docs/src/dev/provider/gremlin-semantics.asciidoc:
##########
@@ -144,67 +144,10 @@ Key differences include handling of numeric types and NaN.
Both Equality and Equivalence can be understood as complete, i.e. the result
of equality and equivalence checks is
always either `TRUE` or `FALSE` (in particular, it never returns `nulltype` or
throws an exception). Similarly,
Orderability can be also understood as complete - any two values can be
compared without error for ordering purposes.
-Comparability semantics are not complete with respect to binary boolean
semantics, and as such, Gremlin introduces a
-ternary boolean semantics for Comparability that includes a third boolean
state - `ERROR`, with its own well-defined
-semantics.
-
-=== Ternary Boolean Logics
-
-When evaluating boolean value expressions, we sometimes encounter situations
that cannot be proved as either `TRUE` or
-`FALSE`. Common `ERROR` cases are Comparability against `NaN`, cross-type
Comparability (e.g. `String` vs `Numeric`), or
-other invalid arguments to other boolean value expressions.
-
-Rather than throwing an exception and halting the traversal, we extend normal
binary boolean logics and introduce a
-third boolean option - `ERROR`. How this `ERROR` result is handled is Graph
provider dependent. For the reference
-implementation, `ERROR` is an internal representation only and will not be
propagated back to the client as an
-exception - it will eventually hit a binary reduction operation and be reduced
to `FALSE` (thus quietly filters the
-solution that produced the `ERROR`). Before that happens though, it will be
treated as its own boolean value with its
-own semantics that can be used in other boolean value expressions, such as
Connective predicates (`P.and/or`) and
-negation (`P.not`).
-
-==== Ternary Boolean Semantics for `AND`
-
-|===
-|A|B|AND|Intuition
-
-| `TRUE` | `TRUE` | `TRUE` |
-| `TRUE` | `FALSE` | `FALSE` |
-| `TRUE` | `ERROR` | `ERROR` | `TRUE && X == X`
-| `FALSE` | `TRUE` | `FALSE` |
-| `FALSE` | `FALSE` | `FALSE` |
-| `FALSE` | `ERROR` | `FALSE` | `FALSE && X == FALSE`
-| `ERROR` | `TRUE` | `ERROR` | `X && TRUE == X`
-| `ERROR` | `FALSE` | `FALSE` | `X && FALSE == FALSE`
-| `ERROR` | `ERROR` | `ERROR` | `X && X == X`
-|===
-
-==== Ternary Boolean Semantics for `OR`
-
-|===
-|A|B|OR|Intuition
-
-| `TRUE` | `TRUE` | `TRUE` |
-| `TRUE` | `FALSE` | `TRUE` |
-| `TRUE` | `ERROR` | `TRUE` | `TRUE \|\| X == TRUE`
-| `FALSE` | `TRUE` | `TRUE` |
-| `FALSE` | `FALSE` | `FALSE` |
-| `FALSE` | `ERROR` | `ERROR` | `FALSE \|\| X == X`
-| `ERROR` | `TRUE` | `TRUE` | `X \|\| TRUE == TRUE`
-| `ERROR` | `FALSE` | `ERROR` | `X \|\| FALSE == X`
-| `ERROR` | `ERROR` | `ERROR` | `X \|\| X == X`
-|===
-
-==== Ternary Boolean Semantics for `NOT`
-
-The `NOT` predicate inverts `TRUE` and `FALSE`, respectively, but maintains
`ERROR` values. The key idea is that, for an
-`ERROR` value, we can neither prove nor disprove the expression, and hence
stick with `ERROR`.
-|===
-|Argument | Result
-
-|`TRUE` | `FALSE`
-|`FALSE` | `TRUE`
-|`ERROR` | `ERROR`
-|===
+Comparability semantics are not complete with respect to traditional binary
boolean semantics, as certain comparisons
+cannot be proved as either `TRUE` or `FALSE`. Common examples of such cases
are Comparability against `NaN`, cross-type
+Comparability (e.g. `String` vs `Numeric`). For the purposes of Comparability
within Gremlin, any such incomputable
Review Comment:
I'd prefer to leave this out of this section of the docs. The parsing of
Strings is really a special implementation detail of the Integer IdManager in
TinkerGraph. As far as gremlin itself is concerned, `g.V("1")` is looking for a
vertex with a String id `"1"`. If this needs documentation I would rather it be
listed as some special sugar in TinkerGraph, rather than an exception outlined
here in the comparability semantics docs.
> Simplify Comparability Semantics
> --------------------------------
>
> Key: TINKERPOP-3173
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3173
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.7.3
> Reporter: Cole Greer
> Priority: Major
>
> As recently discussed on the
> [devlist|https://lists.apache.org/thread/hsqw2tvc72dw4z40nnbbdmygrqx43syr],
> our current system of ternary boolean logic should be simplified to binary
> boolean logic where invalid comparisons simply return false.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
