Skip to content

GitLab

  • Menu
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 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ift
  • NIFTy
  • Issues
  • #250

Closed
Open
Created Jun 26, 2018 by Martin Reinecke@mtrOwner

[post Nifty6] new design for the `Field` class?

I'm wondering whether we can solve most of our current problems regarding fields and multifields by introducing a single new Field class that

  • unifies the current Field and MultiField classes (a classic field would have a single dictionary entry with an empty string as name)
  • is immutable
  • can contain scalars or array-like objects to describe field content (maybe even functions?)

If we have such a class we can again demand that all operations on fields require identical domains, and we can still avoid writing huge zero-filled arrays by writing scalar zeros instead.

@reimar, @kjako, @parras please let me know what you think.

Edited Dec 02, 2019 by Martin Reinecke
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking