Mercurial > repos > public > sbplib_julia

comparison Notes.md @ 379:de4746d6d126

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Add some notes and todos
author Jonatan Werpers <jonatan@werpers.com>
date Wed, 30 Sep 2020 21:30:29 +0200
parents 535f1bff4bcc
children 26e186b565b3
comparison
equal deleted inserted replaced
378:946516954c85 379:de4746d6d126
1 # Notes 1 # Notes
2 2
3 ## Known size of range and domain? 3 ## Known size of range and domain?
4 It might be a good idea let tensormappings know the size of their range and domain as a constant. This probably can't be enforced on the abstract type but maybe we should write our difference operators this way. Having this as default should clean up the thinking around adjoints of boundary operators. It could also simplify getting high performance out of repeated application of regioned TensorMappings.
5 Is there any reason to use a trait to differentiate between fixed size and unknown size? 4 Is there any reason to use a trait to differentiate between fixed size and unknown size?
6 5
7 ## Test setup 6 When do we need to know the size of the range and domain?
8 Once we figure out how to organize the subpackages we should update test folders to Project. As of writing this there seems to be and issue with this approach combined with dev'ed packages so we can't do it yet. It seems that Pkg might fix this in the future. 7 * When indexing to provide boundschecking?
8 * When doing specialised computations for different parts of the range/domain?
9 * More?
9 10
10 Some steps to imporve the situation right now is to combine everything to one package and use the `@includetests` macro from [TestSetExtensions](https://github.com/ssfrr/TestSetExtensions.jl) together with `Pkg.test(test_args="...")` to selectively run tests. 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 12
12 ## Reasearch and thinking 13 ## Reasearch and thinking
13 - [ ] Use a trait to indicate if a TensorMapping uses indices with regions. 14 - [ ] Use a trait to indicate if a TensorMapping uses indices with regions.
14 The default should be that they do NOT. 15 The default should be that they do NOT.
15 - [ ] What to name this trait? Can we call it IndexStyle but not export it to avoid conflicts with Base.IndexStyle? 16 - [ ] What to name this trait? Can we call it IndexStyle but not export it to avoid conflicts with Base.IndexStyle?
16 - [ ] Use a trait to indicate that a TensorMapping har the same range and domain? 17 - [ ] Use a trait to indicate that a TensorMapping har the same range and domain?
17 - [ ] Rename all the Tensor stuff to just LazyOperator, LazyApplication and so on? 18 - [ ] Rename all the Tensor stuff to just LazyOperator, LazyApplication and so on?
18 - [ ] 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? 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?
19 - [ ] Check how the native julia doc generator works 20 - [ ] Check how the native julia doc generator works
20 - [ ] Check if Vidars design docs fit in there 21 - [ ] Check if Vidars design docs fit in there
21 - [ ] Formalize how range_size() and domain_size() are supposed to work in TensorMappings where dim(domain) != dim(range) (add tests or document)
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. 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.
23 - [ ] Specificera operatorer i TOML eller något liknande? 23 - [ ] Specificera operatorer i TOML eller något liknande?
24 H.. H_gamma etc.) 24 H.. H_gamma etc.)
25 - [ ] Dispatch in Lower() instead of the type Lower so `::Lower` instead of `::Type{Lower}` ??? 25 - [ ] Dispatch in 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. 26 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.
28 - [ ] 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?