ORNL / ORNL/cpp-proposals-pub

P3050R2: LEWG review 2024-08-27 and 2024-09-03

Open
#471 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
29
Forks
26
PR merge metrics
No merged PRs in 30d

Description

LEWG review of P3050R2

LEWG started reviewing P3050R2 (Fix C++26 by optimizing linalg::conjugated for noncomplex value types) on 2024-08-27 but didn't finish.

Summary of LEWG's 2024-08-27 discussion

Definition of a (non)complex number type

P3050 follows [linalg], specifically conj-if-needed(E), which is defined as

  1. ADL-found conj(E) if type of E is not an arithmetic type, else
  2. E.

conj already is not ADL-findable for double, etc., which is what we want anyway.

Custom real types and conj

What happens if a user defines conj for their custom real type?

Results will be mathematically correct if user defined it mathematically correctly.

  • Best case: return type same as input type: custom_real conj(const custom_real&)

    • Avoids mixed-type computations if all matrices and vectors are custom_real
  • Worst case: user imitates std::conj by defining custom_complex<custom_real> conj(custom_real)

    • Code may fail to compile if user did not define the right mixed arithmetic operators and/or implicit conversions (but that's the user's fault; they did ask for conjugate_transposed(A))

    • Users are already outside the space of typical std::linalg optimizations. Best they can expect is std::execution::par_unseq.

    • Users may have custom linear algebra algorithms and may use them with std::linalg::conjugated and/or std::linalg::conjugate_transposed, though.

Consider a follow-on proposal to deprecate and replace std::conj

I am not bothered if users write a custom real number type and they define ADL-findable conj to return the custom complex of their real type because that’s weird.... The existing behavior of the Standard is broken. Anyone who works with complex numbers hates this.

  • Consider a follow-on proposal to deprecate std::conj and define a new std::conjugate more rationally

  • Should this wait for language support for customization points?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the issue's summary of the unfinished LEWG review of P3050R2, including the discussion of noncomplex types, ADL-found conj, and a possible replacement for std::conj. There are no files or tests named. Done would require a recorded decision or a clearly defined follow-up proposal, neither of which is specified here.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.