Mercurial > repos > public > sbplib_julia
comparison Notes.md @ 995:1ba8a398af9c refactor/lazy_tensors
Rename types
author | Jonatan Werpers <jonatan@werpers.com> |
---|---|
date | Fri, 18 Mar 2022 21:14:47 +0100 |
parents | 1784b1c0af3e |
children | 6b94663f4376 |
comparison
equal
deleted
inserted
replaced
994:55ab7801c45f | 995:1ba8a398af9c |
---|---|
130 When do we need to know the size of the range and domain? | 130 When do we need to know the size of the range and domain? |
131 * When indexing to provide boundschecking? | 131 * When indexing to provide boundschecking? |
132 * When doing specialised computations for different parts of the range/domain? | 132 * When doing specialised computations for different parts of the range/domain? |
133 * More? | 133 * More? |
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 TensorMapping 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 TensorMapping 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? | 139 - [ ] Rename all the Tensor stuff to just LazyOperator, LazyApplication and so on? |
140 - [ ] Check how the native julia doc generator works | 140 - [ ] Check how the native julia doc generator works |
141 - [ ] Check if Vidars design docs fit in there | 141 - [ ] 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. | 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. |
143 - [ ] Specificera operatorer i TOML eller något liknande? | 143 - [ ] Specificera operatorer i TOML eller något liknande? |
144 H.. H_gamma etc.) | 144 H.. H_gamma etc.) |
145 - [ ] Dispatch on Lower() instead of the type Lower so `::Lower` instead of `::Type{Lower}` ??? | 145 - [ ] 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. | 146 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. | 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. |
148 - [ ] Can we have a trait to tell if a TensorMapping is transposable? | 148 - [ ] 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? | 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? |
150 - [ ] Figure out how to treat the borrowing parameters of operators. Include in into the struct? Expose via function dispatched on the operator type and grid? | 150 - [ ] Figure out how to treat the borrowing parameters of operators. Include in into the struct? Expose via function dispatched on the operator type and grid? |
151 | 151 |
152 ## Regions and tensormappings | 152 ## Regions and tensormappings |
153 - [ ] Use a trait to indicate if a TensorMapping uses indices with regions. | 153 - [ ] Use a trait to indicate if a LazyTensor uses indices with regions. |
154 The default should be that they do NOT. | 154 The default should be that they do NOT. |
155 - [ ] What to name this trait? Can we call it IndexStyle but not export it to avoid conflicts with Base.IndexStyle? | 155 - [ ] What to name this trait? Can we call it IndexStyle but not export it to avoid conflicts with Base.IndexStyle? |
156 - [ ] Figure out repeated application of regioned TensorMappings. Maybe an instance of a tensor mapping needs to know the exact size of the range and domain for this to work? | 156 - [ ] Figure out repeated application of regioned LazyTensors. Maybe an instance of a tensor mapping needs to know the exact size of the range and domain for this to work? |
157 | 157 |
158 ## Boundschecking and dimension checking | 158 ## Boundschecking and dimension checking |
159 Does it make sense to have boundschecking only in getindex methods? | 159 Does it make sense to have boundschecking only in getindex methods? |
160 This would mean no bounds checking in applys, however any indexing that they do would be boundschecked. The only loss would be readability of errors. But users aren't really supposed to call apply directly anyway. | 160 This would mean no bounds checking in applys, however any indexing that they do would be boundschecked. The only loss would be readability of errors. But users aren't really supposed to call apply directly anyway. |
161 | 161 |
259 | 259 |
260 ### Tensor operatorer | 260 ### Tensor operatorer |
261 Vi kan ha tensor-operatorer som agerar på ett skalärt fält och ger ett vektorfält eller tensorfält. | 261 Vi kan ha tensor-operatorer som agerar på ett skalärt fält och ger ett vektorfält eller tensorfält. |
262 Vi kan också ha tensor-operatorer som agerar på ett vektorfält eller tensorfält och ger ett skalärt fält. | 262 Vi kan också ha tensor-operatorer som agerar på ett vektorfält eller tensorfält och ger ett skalärt fält. |
263 | 263 |
264 TBD: Just nu gör `apply_transpose` antagandet att domän-typen är samma som range-typen. Det behöver vi på något sätt bryta. Ett alternativ är låta en TensorMapping ha `T_domain` och `T_range` istället för bara `T`. Känns dock lite grötigt. Ett annat alternativ skulle vara någon typ av trait för transpose? Den skulle kunna innehålla typen som transponatet agerar på? Vet inte om det fungerar dock. | 264 TBD: Just nu gör `apply_transpose` antagandet att domän-typen är samma som range-typen. Det behöver vi på något sätt bryta. Ett alternativ är låta en LazyTensor ha `T_domain` och `T_range` istället för bara `T`. Känns dock lite grötigt. Ett annat alternativ skulle vara någon typ av trait för transpose? Den skulle kunna innehålla typen som transponatet agerar på? Vet inte om det fungerar dock. |
265 | 265 |
266 TBD: Vad är målet med `T`-parametern för en TensorMapping? Om vi vill kunna applicera en difference operator på vad som helst kan man inte anta att en `TensorMapping{T}` bara agerar på instanser av `T`. | 266 TBD: Vad är målet med `T`-parametern för en LazyTensor? Om vi vill kunna applicera en difference operator på vad som helst kan man inte anta att en `LazyTensor{T}` bara agerar på instanser av `T`. |
267 | 267 |
268 Man kan implementera `∇` som en tensormapping som agerar på T och returnerar `StaticVector{N,T} where N`. | 268 Man kan implementera `∇` som en tensormapping som agerar på T och returnerar `StaticVector{N,T} where N`. |
269 (Man skulle eventuellt också kunna låta den agera på `StaticMatrix{N,T,D} where N` och returnera `StaticMatrix{M,T,D+1}`. Frågan är om man vinner något på det...) | 269 (Man skulle eventuellt också kunna låta den agera på `StaticMatrix{N,T,D} where N` och returnera `StaticMatrix{M,T,D+1}`. Frågan är om man vinner något på det...) |
270 | 270 |
271 Skulle kunna ha en funktion `range_type(::TensorMapping, ::Type{domain_type})` | 271 Skulle kunna ha en funktion `range_type(::LazyTensor, ::Type{domain_type})` |
272 | 272 |
273 Kanske kan man implementera `⋅(tm::TensorMapping{R,D}, v::AbstractArray{T,D})` där T är en AbstractArray, tm på något sätt har komponenter, lika många som T har element. | 273 Kanske kan man implementera `⋅(tm::LazyTensor{R,D}, v::AbstractArray{T,D})` där T är en AbstractArray, tm på något sätt har komponenter, lika många som T har element. |
274 | 274 |
275 ### Ratade alternativ: | 275 ### Ratade alternativ: |
276 | 276 |
277 | 277 |
278 #### 2.AbstractArray{T,2+1} where T (NOPE!) | 278 #### 2.AbstractArray{T,2+1} where T (NOPE!) |
300 | 300 |
301 ### Komponenter som gridfunktioner | 301 ### Komponenter som gridfunktioner |
302 En viktig operation för vektor fält är att kunna få ut komponenter som grid-funktioner. Detta behöver antagligen kunna ske lazy. | 302 En viktig operation för vektor fält är att kunna få ut komponenter som grid-funktioner. Detta behöver antagligen kunna ske lazy. |
303 Det finns ett par olika lösningar: | 303 Det finns ett par olika lösningar: |
304 * Implementera en egen typ av view som tar hand om detta. Eller Accessors.jl? | 304 * Implementera en egen typ av view som tar hand om detta. Eller Accessors.jl? |
305 * Använda en TensorMapping | 305 * Använda en LazyTensor |
306 * Någon typ av lazy-broadcast | 306 * Någon typ av lazy-broadcast |
307 * En lazy array som applicerar en funktion för varje element. | 307 * En lazy array som applicerar en funktion för varje element. |
308 | 308 |
309 Skulle vara en fördel om det är hyffsat generiskt så att en eventuell användare kan utöka det enkelt om de har någon egen exotisk typ. Eller ska man vila helt på | 309 Skulle vara en fördel om det är hyffsat generiskt så att en eventuell användare kan utöka det enkelt om de har någon egen exotisk typ. Eller ska man vila helt på |
310 | 310 |
347 | 347 |
348 A different approach would be to include it as a trait for operators so that you can specify what the adjoint for that operator is. | 348 A different approach would be to include it as a trait for operators so that you can specify what the adjoint for that operator is. |
349 | 349 |
350 | 350 |
351 ## Name of the `VolumeOperator` type for constant stencils | 351 ## Name of the `VolumeOperator` type for constant stencils |
352 It seems that the name is too general. The name of the method `volume_operator` makes sense. It should return different types of `TensorMapping` specialized for the grid. A suggetion for a better name is `ConstantStencilVolumeOperator` | 352 It seems that the name is too general. The name of the method `volume_operator` makes sense. It should return different types of `LazyTensor` specialized for the grid. A suggetion for a better name is `ConstantStencilVolumeOperator` |