comparison Notes.md @ 1045:0e31b9901160 feature/dissipation_operators

Merge refactor/sbpoperators/inflation
author Jonatan Werpers <jonatan@werpers.com>
date Tue, 22 Mar 2022 22:11:11 +0100
parents 6b94663f4376
children 3bb94ce74697 396278072f18
comparison
equal deleted inserted replaced
1035:ceda69b8f27a 1045:0e31b9901160
134 134
135 Maybe if we should have dynamic sizing it could be only for the range. `domain_size` would not be implemented. And the `range_size` would be a function of a vector that the LazyTensor is applied to. 135 Maybe if we should have dynamic sizing it could be only for the range. `domain_size` would not be implemented. And the `range_size` would be a function of a vector that the LazyTensor is applied to.
136 136
137 ## Reasearch and thinking 137 ## Reasearch and thinking
138 - [ ] Use a trait to indicate that a LazyTensor har the same range and domain? 138 - [ ] Use a trait to indicate that a LazyTensor har the same range and domain?
139 - [ ] Rename all the Tensor stuff to just LazyOperator, LazyApplication and so on?
140 - [ ] Check how the native julia doc generator works 139 - [ ] Check how the native julia doc generator works
141 - [ ] Check if Vidars design docs fit in there 140 - [ ] Check if Vidars design docs fit in there
142 - [ ] Create a macro @lazy which replaces a binary op (+,-) by its lazy equivalent? Would be a neat way to indicate which evaluations are lazy without cluttering/confusing with special characters. 141 - [ ] Create a macro @lazy which replaces a binary op (+,-) by its lazy equivalent? Would be a neat way to indicate which evaluations are lazy without cluttering/confusing with special characters.
143 - [ ] Specificera operatorer i TOML eller nĂ¥got liknande?
144 H.. H_gamma etc.)
145 - [ ] Dispatch on Lower() instead of the type Lower so `::Lower` instead of `::Type{Lower}` ??? 142 - [ ] Dispatch on Lower() instead of the type Lower so `::Lower` instead of `::Type{Lower}` ???
146 Seems better unless there is some specific reason to use the type instead of the value. 143 Seems better unless there is some specific reason to use the type instead of the value.
147 - [ ] How do we handle mixes of periodic and non-periodic grids? Seems it should be supported on the grid level and on the 1d operator level. Between there it should be transparent. 144 - [ ] How do we handle mixes of periodic and non-periodic grids? Seems it should be supported on the grid level and on the 1d operator level. Between there it should be transparent.
148 - [ ] Can we have a trait to tell if a LazyTensor is transposable? 145 - [ ] Can we have a trait to tell if a LazyTensor is transposable?
149 - [ ] Is it ok to have "Constructors" for abstract types which create subtypes? For example a Grids() functions that gives different kind of grids based on input? 146 - [ ] Is it ok to have "Constructors" for abstract types which create subtypes? For example a Grids() functions that gives different kind of grids based on input?