Mercurial > repos > public > sbplib_julia

comparison Notes.md @ 436:cffdac9c612d bugfix/tensor_application_multiplication

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Close branch before merge
author Jonatan Werpers <jonatan@werpers.com>
date Mon, 19 Oct 2020 20:54:23 +0200
parents 1c41f4fd3e61
children 8f9b3eac128a
comparison
equal deleted inserted replaced
422:f0d6906d8937 436:cffdac9c612d
95 Det vore skönt att inte behöva skriva såhär varje gång man testar mot en tupel :smile: @test [gp[i]...] ≈ [p[i]...] atol=5e-13 95 Det vore skönt att inte behöva skriva såhär varje gång man testar mot en tupel :smile: @test [gp[i]...] ≈ [p[i]...] atol=5e-13
96 96
97 Jonatan Werpers: 97 Jonatan Werpers:
98 https://github.com/JuliaArrays/ArraysOfArrays.jl 98 https://github.com/JuliaArrays/ArraysOfArrays.jl
99 https://github.com/jw3126/Setfield.jl 99 https://github.com/jw3126/Setfield.jl
100
101 ### Test-applikationer
102 div och grad operationer
103
104 ### Alternativ:
105
106 #### 1.Använda tuplar
107 Fördelar:
108
109 Nackdelar:
110
111 Syntax:
112 ```
113 f(x,y) = x^2 + y^2
114 gf = eval_on_grid(g,f)
115 gf[2,3] # En tupel för en given gridpunkt
116 gf[2,3][2] # Andra komponenten av vektor fältet i en punkt.
117
118 ```
119
120 #### 2.AbstractArray{T,2} where T
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
123 En nackdel kan var hur man ska få ut gridfunktionen för tex andra komponenten.
124
125 Syntax:
126 ```
127 gf = eval(...)
128 gf[2,3] # Hela vektorn för en gridpunkt
129 gf[2,3][2] # Andra komponenten av vektor fältet.
130 ```
131 #### 3.AbstractArray{T,2+1} where T
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.
133
134 Syntax:
135 ```
136 gf = eval_on_grid(g,f)
137 gf[:,2,3] # Hela vektorn för en gridpunkt
138 gf[2,2,3] # Andra komponenten av vektor fältet i en punkt.
139 gf[2,:,:] #
140 ```
141
142 ### Evaluering av funktioner på nät
143 Hur ska man skriva funktioner som evalueras på nätet? `f(x,y) = ...` eller `f(x̄) = ...`? Eller båda? Kan eval_on_grid se skillnad eller får användaren specificera?
144
145 ```
146 f(x,y) = [x^2, y^2]
147 f(x̄) = [x̄[1]^2, x̄[2]^2]
148 ```
149
150 Påverkas detta av hur vi förväntar oss kunna skapa lata gridfunktioner?
151
152 ### 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.
154 Det finns ett par olika lösningar:
155 * Implementera en egen typ av view som tar hand om detta. Eller Accessors.jl?
156 * Använda en TensorMapping
157 * Någon typ av lazy-broadcast
158 * En lazy array som applicerar en funktion för varje element.
159
160 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å
161
162 Syntax:
163 ```
164 gf = eval(...)
165 component(gf,2) # Andra komponenten av en vektor
166 component(gf,2,3) # (2,3) elementet av en matris
167 component(gf,:,2) # Andra kolumnen av en matris
168 @ourview gf[:,:][2]
169 ```