Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • N NIFTy
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 17
    • Issues 17
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 15
    • Merge requests 15
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

On Thursday, 2nd February from 9 to 10.00 am there will be a maintenance with a short downtime of the GitLab service.

  • ift
  • NIFTy
  • Merge requests
  • !500

WIP: More restrictive scaling operator

  • Review changes

  • Download
  • Email patches
  • Plain diff
Closed Reimar H Leike requested to merge more_restrictive_scaling_operator into NIFTy_6 May 25, 2020
  • Overview 10
  • Commits 2
  • Pipelines 3
  • Changes 2

ScalingOperators do not know the dtype, on which theyu operate. This can lead to problems if complex scalingOperators act on real fields, as this causes it to cast the input to a complex number. However, the adjoint then does not cast this number back, leading to inconsistencies. This branch therefore raises an error whenever a ScalingOperator with complex factor acts on a real input, forcing the User to use an adjoint Realizer to cast the field to a complex one first. The DiagonalOperator should probably do the same check.

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: more_restrictive_scaling_operator