Mercurial > repos > public > sbplib_julia
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? |