Mercurial > repos > public > sbplib_julia

comparison Notes.md @ 607:5883e689cd3f refactor/toml_operator_format

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Merge in default
author Jonatan Werpers <jonatan@werpers.com>
date Sat, 05 Dec 2020 14:05:15 +0100
parents 8f9b3eac128a
children d26231227b89
comparison
equal deleted inserted replaced
605:8fcf9c9afb30 607:5883e689cd3f
9 * More? 9 * More?
10 10
11 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. 11 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.
12 12
13 ## Reasearch and thinking 13 ## Reasearch and thinking
14 - [ ] Use a trait to indicate if a TensorMapping uses indices with regions.
15 The default should be that they do NOT.
16 - [ ] What to name this trait? Can we call it IndexStyle but not export it to avoid conflicts with Base.IndexStyle?
17 - [ ] Use a trait to indicate that a TensorMapping har the same range and domain? 14 - [ ] Use a trait to indicate that a TensorMapping har the same range and domain?
18 - [ ] Rename all the Tensor stuff to just LazyOperator, LazyApplication and so on? 15 - [ ] Rename all the Tensor stuff to just LazyOperator, LazyApplication and so on?
19 - [ ] 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?
20 - [ ] Check how the native julia doc generator works 16 - [ ] Check how the native julia doc generator works
21 - [ ] Check if Vidars design docs fit in there 17 - [ ] Check if Vidars design docs fit in there
22 - [ ] 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. 18 - [ ] 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.
23 - [ ] Specificera operatorer i TOML eller något liknande? 19 - [ ] Specificera operatorer i TOML eller något liknande?
24 H.. H_gamma etc.) 20 H.. H_gamma etc.)
25 - [ ] Dispatch in Lower() instead of the type Lower so `::Lower` instead of `::Type{Lower}` ??? 21 - [ ] Dispatch on Lower() instead of the type Lower so `::Lower` instead of `::Type{Lower}` ???
26 Seems better unless there is some specific reason to use the type instead of the value. 22 Seems better unless there is some specific reason to use the type instead of the value.
27 - [ ] 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. 23 - [ ] 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.
28 - [ ] Can we have a trait to tell if a TensorMapping is transposable? 24 - [ ] Can we have a trait to tell if a TensorMapping is transposable?
29 - [ ] 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? 25 - [ ] 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?
26
27 ## Regions and tensormappings
28 - [ ] Use a trait to indicate if a TensorMapping uses indices with regions.
29 The default should be that they do NOT.
30 - [ ] What to name this trait? Can we call it IndexStyle but not export it to avoid conflicts with Base.IndexStyle?
31 - [ ] 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?
32
33 ## Boundschecking and dimension checking
34 Does it make sense to have boundschecking only in getindex methods?
35 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.
36
37 Preferably dimensions and sizes should be checked when lazy objects are created, for example TensorApplication, TensorComposition and so on. If dimension checks decreases performance we can make them skippable later.
30 38
31 ## Vector valued grid functions 39 ## Vector valued grid functions
32 Från slack konversation: 40 Från slack konversation:
33 41
34 Jonatan Werpers: 42 Jonatan Werpers:
99 https://github.com/jw3126/Setfield.jl 107 https://github.com/jw3126/Setfield.jl
100 108
101 ### Test-applikationer 109 ### Test-applikationer
102 div och grad operationer 110 div och grad operationer
103 111
104 ### Alternativ: 112 Enligt Wikipedia verkar det som att `∇⋅` agerar på första dimensionen av ett tensor fält och `div()` på sista.
113 Om man generaliserar kanske `∇` i så fall bara lägger till en dimension i början.
105 114
106 #### 1.Använda tuplar 115 Kan vi implementera `⋅`(\cdot) så att de fungerar som man vill för både tensor-fält och tensor-operatorer?
107 Fördelar:
108 116
109 Nackdelar: 117 Är `∇` ett tensor-fält av tensor-operatorer? Vad är ett tensor-fält i vår kod? Är det en special-fall av en tensor-mapping?
118
119 ### Grid-funktionen
120 Grid-funktionon har typen `AbstractArray{T,2} where T`.
121 `T` kan vara lite vad som helst, tillexemel en SVector eller Array, eller tuple. TensorOperatorerna bryr sig inte om exakt vad det är, mer än att typen måste stödja de operationer som operatorn använder.
122
123 En nackdel kan vara hur man ska få ut gridfunktionen för tex andra komponenten.
110 124
111 Syntax: 125 Syntax:
112 ``` 126 ```
113 f(x,y) = x^2 + y^2 127 f(x̄) = x̄
114 gf = eval_on_grid(g,f) 128 gf = evalOn(g, f)
115 gf[2,3] # En tupel för en given gridpunkt 129 gf[2,3] # x̄ för en viss gridpunkt
116 gf[2,3][2] # Andra komponenten av vektor fältet i en punkt. 130 gf[2,3][2] # x̄[2] för en viss gridpunkt
117
118 ``` 131 ```
119 132
120 #### 2.AbstractArray{T,2} where T 133 Note: Behöver bestämma om eval on skickar in `x̄` eller `x̄...` till `f`. Eller om man kan stödja båda.
121 Låta alla saker ta in AbstractArray{T,2} where T. Där T kan vara lite vad som helst, tillexemel en SVector eller Array. Men Differens-opertorerna bryr sig inte om det.
122 134
123 En nackdel kan var hur man ska få ut gridfunktionen för tex andra komponenten. 135 ### Tensor operatorer
136 Vi kan ha tensor-operatorer som agerar på ett skalärt fält och ger ett vektorfält eller tensorfält.
137 Vi kan också ha tensor-operatorer som agerar på ett vektorfält eller tensorfält och ger ett skalärt fält.
124 138
125 Syntax: 139 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.
126 ``` 140
127 gf = eval(...) 141 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`.
128 gf[2,3] # Hela vektorn för en gridpunkt 142
129 gf[2,3][2] # Andra komponenten av vektor fältet. 143 Man kan implementera `∇` som en tensormapping som agerar på T och returnerar `StaticVector{N,T} where N`.
130 ``` 144 (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...)
131 #### 3.AbstractArray{T,2+1} where T 145
146 Skulle kunna ha en funktion `range_type(::TensorMapping, ::Type{domain_type})`
147
148 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.
149
150 ### Ratade alternativ:
151
152
153 #### 2.AbstractArray{T,2+1} where T (NOPE!)
154 Blir inte den här. Bryter mot alla tankar om hur grid funktioner ska fungera. Om de tillåts ha en annan dimension än nätet blir allt hemskt.
155
132 Man låter helt enkelt arrayen ha en extra dimension. En fördel är att man har en väldigt "native" typ. En nackdel kan vara att det eventuellt blir rörigt vilken dimension olika operatorer ska agera på. I värsta fall behöver vi "kroneckra in" de tillagda dimensionerna. Vektorfältets index kommer också att bli det första eftersom vi vill att de ska lagras kontinuerligt i minnet pga chachen. (Går kanske att lösa med en custom typ men då krånglar man till det för sig). En fördel skulle vara att man enkelt får ut olika komponenter. 156 Man låter helt enkelt arrayen ha en extra dimension. En fördel är att man har en väldigt "native" typ. En nackdel kan vara att det eventuellt blir rörigt vilken dimension olika operatorer ska agera på. I värsta fall behöver vi "kroneckra in" de tillagda dimensionerna. Vektorfältets index kommer också att bli det första eftersom vi vill att de ska lagras kontinuerligt i minnet pga chachen. (Går kanske att lösa med en custom typ men då krånglar man till det för sig). En fördel skulle vara att man enkelt får ut olika komponenter.
133 157
134 Syntax: 158 Syntax:
135 ``` 159 ```
136 gf = eval_on_grid(g,f) 160 gf = eval_on_grid(g,f)
148 ``` 172 ```
149 173
150 Påverkas detta av hur vi förväntar oss kunna skapa lata gridfunktioner? 174 Påverkas detta av hur vi förväntar oss kunna skapa lata gridfunktioner?
151 175
152 ### Komponenter som gridfunktioner 176 ### Komponenter som gridfunktioner
153 För alternativ 1 och 2 har vi problemet hur vi får ut komponenter som vektorfält. Detta behöver antagligen kunna ske lazy. 177 En viktig operation för vektor fält är att kunna få ut komponenter som grid-funktioner. Detta behöver antagligen kunna ske lazy.
154 Det finns ett par olika lösningar: 178 Det finns ett par olika lösningar:
155 * Implementera en egen typ av view som tar hand om detta. Eller Accessors.jl? 179 * Implementera en egen typ av view som tar hand om detta. Eller Accessors.jl?
156 * Använda en TensorMapping 180 * Använda en TensorMapping
157 * Någon typ av lazy-broadcast 181 * Någon typ av lazy-broadcast
158 * En lazy array som applicerar en funktion för varje element. 182 * En lazy array som applicerar en funktion för varje element.