Skip to content

RFC: Experimental neutrosophic operator layer for QuMat #1372

@SeCuReDmE-main-dev

Description

@SeCuReDmE-main-dev

Description

This issue proposes an experimental operator-layer discussion for QuMat, not a production backend rewrite.

QuMat already provides a meaningful gate-oriented API and backend dispatch across qiskit, cirq, and amazon_braket. However, it currently assumes standard qubit-oriented state semantics. That makes it difficult to explore a non-binary reference carrier for indeterminacy-bearing operators in a disciplined, testable way.

The proposed direction is to discuss whether QuMat could eventually host a narrowly scoped experimental operator layer above the current backend model, starting with local reference semantics and comparison scaffolding rather than native backend execution.

Problem Statement

Current QuMat supports standard qubit-oriented gates and backend execution, but it does not provide:

  • a non-binary state carrier for indeterminacy-bearing operators
  • an experimental namespace for non-standard operator families
  • a structured comparison surface between standard qubit execution and a richer reference-state model
  • a formal measurement contract for a local chain such as Df -> dF -> i_fractal

Without that, the following cannot be explored faithfully:

  • neutrobit semantics
  • neutrosophic W/X/Y/Z/H gates over a 3x3 carrier
  • structured fractal-carried observability
  • comparison studies that preserve the distinction between:
    • qubit-compatible subspace behavior
    • genuinely 3-state neutrosophic behavior

Proposed Direction

The first increment should stay conservative and local-first.

Suggested shape:

  • a NeutroBit reference carrier over |0>, |1>, and |I>
  • a NeutroGate abstraction for named 3x3 operators
  • a first operator family:
    • W
    • X
    • Y
    • Z
    • H
  • local normalization and measurement utilities
  • a projection / comparison harness against standard QuMat qubit circuits where comparison is mathematically valid

The first goal is observability and reference semantics, not backend replacement.

Expected Behavior

If QuMat is a suitable host for this kind of exploration, the long-term result would be:

  • an opt-in experimental surface for non-standard operator research
  • strict separation from the production backend model
  • comparison tooling that can test where standard qubit subspace behavior ends and richer reference-state behavior begins
  • a path to discuss kernel-method or data-encoding relevance later, if the operator layer proves technically useful

Actual Behavior

Today there is no explicit place in QuMat for this class of experiment. Any such work would either be forced into qubit semantics prematurely or remain completely external to QuMat.

Environment

  • Host project: Apache Mahout / QuMat
  • Current QuMat public direction: unified quantum API, multi-backend support, kernel-method interest
  • Research constraint: first phase should remain reference-only and should not claim native 3-state execution on current backends

Suggested Fix

Discuss whether QuMat would accept a narrowly scoped experimental operator-extension direction with these constraints:

  1. no production backend rewrite in the first pass
  2. no public API break
  3. no false claim that qiskit, cirq, or amazon_braket natively execute a 3-state neutrosophic carrier
  4. local reference semantics first
  5. comparison scaffolding second
  6. upstream-facing discussion only if the extension story stays small and reviewable

Academic / Technical Foundation

Relevant published sources:

Relevant Mahout / QuMat project context:

Additional Context

This proposal is intentionally narrow.

It does not ask Mahout to adopt a new production quantum model immediately.
It asks whether QuMat could be a technically reasonable host for a conservative, opt-in experimental operator layer that remains separate from current backend semantics.

Checklist

  • I have searched the existing issues for duplicates.
  • I have provided the information as clearly and concretely as possible.
  • I have included relevant technical and academic references.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions