--- a/Notes.md	Wed Dec 02 13:36:54 2020 +0100
+++ b/Notes.md	Wed Dec 02 09:35:14 2020 +0100
@@ -11,23 +11,31 @@
  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.
 
 ## Reasearch and thinking
- - [ ] Use a trait to indicate if a TensorMapping uses indices with regions.
-    The default should be that they do NOT.
-        - [ ] What to name this trait? Can we call it IndexStyle but not export it to avoid conflicts with Base.IndexStyle?
  - [ ] Use a trait to indicate that a TensorMapping har the same range and domain?
  - [ ] Rename all the Tensor stuff to just LazyOperator, LazyApplication and so on?
- - [ ] 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?
  - [ ] Check how the native julia doc generator works
     - [ ] Check if Vidars design docs fit in there
  - [ ] 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.
  - [ ] Specificera operatorer i TOML eller något liknande?
  H.. H_gamma etc.)
- - [ ] Dispatch in Lower() instead of the type Lower so `::Lower` instead of `::Type{Lower}` ???
+ - [ ] Dispatch on Lower() instead of the type Lower so `::Lower` instead of `::Type{Lower}` ???
  	Seems better unless there is some specific reason to use the type instead of the value.
  - [ ] 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.
  - [ ] Can we have a trait to tell if a TensorMapping is transposable?
  - [ ] 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?
 
+## Regions and tensormappings
+- [ ] Use a trait to indicate if a TensorMapping uses indices with regions.
+    The default should be that they do NOT.
+        - [ ] What to name this trait? Can we call it IndexStyle but not export it to avoid conflicts with Base.IndexStyle?
+ - [ ] 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?
+
+## Boundschecking and dimension checking
+Does it make sense to have boundschecking only in getindex methods?
+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.
+
+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.
+
 ## Vector valued grid functions
 Från slack konversation:
 
@@ -101,34 +109,50 @@
 ### Test-applikationer
 div och grad operationer
 
-### Alternativ:
+Enligt Wikipedia verkar det som att `∇⋅` agerar på första dimensionen av ett tensor fält och `div()` på sista.
+Om man generaliserar kanske `∇` i så fall bara lägger till en dimension i början.
+
+Kan vi implementera `⋅`(\cdot) så att de fungerar som man vill för både tensor-fält och tensor-operatorer?
 
-#### 1.Använda tuplar
-Fördelar:
+Ä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?
 
-Nackdelar:
+### Grid-funktionen
+Grid-funktionon har typen `AbstractArray{T,2} where T`.
+`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.
+
+En nackdel kan vara hur man ska få ut gridfunktionen för tex andra komponenten.
 
 Syntax:
 ```
-f(x,y) = x^2 + y^2
-gf = eval_on_grid(g,f)
-gf[2,3] # En tupel för en given gridpunkt
-gf[2,3][2] # Andra komponenten av vektor fältet i en punkt.
-
+f(x̄) = x̄
+gf = evalOn(g, f)
+gf[2,3] # x̄ för en viss gridpunkt
+gf[2,3][2] # x̄[2] för en viss gridpunkt
 ```
 
-#### 2.AbstractArray{T,2} where T
-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.
+Note: Behöver bestämma om eval on skickar in `x̄` eller `x̄...` till `f`. Eller om man kan stödja båda.
 
-En nackdel kan var hur man ska få ut gridfunktionen för tex andra komponenten.
+### Tensor operatorer
+Vi kan ha tensor-operatorer som agerar på ett skalärt fält och ger ett vektorfält eller tensorfält.
+Vi kan också ha tensor-operatorer som agerar på ett vektorfält eller tensorfält och ger ett skalärt fält.
+
+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.
+
+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`.
 
-Syntax:
-```
-gf = eval(...)
-gf[2,3] # Hela vektorn för en gridpunkt
-gf[2,3][2] # Andra komponenten av vektor fältet.
-```
-#### 3.AbstractArray{T,2+1} where T
+Man kan implementera `∇` som en tensormapping som agerar på T och returnerar `StaticVector{N,T} where N`.
+(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...)
+
+Skulle kunna ha en funktion `range_type(::TensorMapping, ::Type{domain_type})`
+
+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.
+
+### Ratade alternativ:
+
+
+#### 2.AbstractArray{T,2+1} where T (NOPE!)
+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.
+
 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.
 
 Syntax:
@@ -150,7 +174,7 @@
 Påverkas detta av hur vi förväntar oss kunna skapa lata gridfunktioner?
 
 ### Komponenter som gridfunktioner
-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.
+En viktig operation för vektor fält är att kunna få ut komponenter som grid-funktioner. Detta behöver antagligen kunna ske lazy.
 Det finns ett par olika lösningar:
 * Implementera en egen typ av view som tar hand om detta. Eller Accessors.jl?
 * Använda en TensorMapping

--- a/TODO.md	Wed Dec 02 13:36:54 2020 +0100
+++ b/TODO.md	Wed Dec 02 09:35:14 2020 +0100
@@ -9,11 +9,18 @@
  - [ ] Add 1D operators (D1, D2, e, d ... ) as TensorOperators
  - [ ] Create a struct that bundles the necessary Tensor operators for solving the wave equation.
  - [ ] Add a quick and simple way of running all tests for all subpackages.
- - [ ] Replace getindex hack for flatteing tuples with flatten_tuple.
+ - [ ] Replace getindex hack for flatteing tuples with flatten_tuple. (eg. `getindex.(range_size.(L.D2),1)`)
  - [ ] Use `@inferred` in a lot of tests.
  - [ ] Make sure we are setting tolerances in tests in a consistent way
  - [ ] Add check for correct domain sizes to lazy tensor operations using SizeMismatch
- - [ ] Write down some coding guideline or checklist for code convetions. For example i,j,... för indecies and I for multi-index
+ - [ ] Write down some coding guideline or checklist for code convetions. For example i,j,... for indecies and I for multi-index
+ - [ ] Add boundschecking in TensorMappingApplication
+ - [ ] Start renaming things in LazyTensors
+ - [ ] Clean up RegionIndices
+    1. [ ] Write tests for how things should work
+    2. [ ] Update RegionIndices accordingly
+    3. [ ] Fix the rest of the library
+ - [ ] Add posibility to create tensor mapping application with `()`, e.g `D1(v) <=> D1*v`?
 
 ## Repo
  - [ ] Add Vidar to the authors list