aboutsummaryrefslogtreecommitdiff
path: root/src/CHAD
Commit message (Collapse)AuthorAge
* Multihot cotangents WIP (doesn't work)multihot-cotangentsTom Smeding9 hours
| | | | | | | | | | | | | | | | | | | The idea is sound but for a smaller source language. Notes also in Obsidian, but the theory so far is that dropping support for nested arrays makes this possible, although making the result type-safe (i.e. not have partial functions in a bunch of places) would require making the lack of nested array support explicit in the embedded type system, i.e. have Accelerate-like stratification. The point is that multihots can be added heterogeneously using plusSparseS but not homogeneously with EPlus or plusSparse, because the indices might differ between the summands. Thus as long as we never need to homogeneously sum multihot cotangents, we're golden. Now the crucial observation is that we only need plus to be homogeneous on array elements. So if array elements cannot themselves be arrays, i.e. we drop support for nested arrays, no homogeneous plus of multihot array cotangents is needed, and we can have static multihots.
* Optimise eflattenHEADmasterTom Smeding9 hours
|
* Import CHAD.Language also qualified as L in ExampleTom Smeding2025-12-10
|
* APIv1: Some fixesTom Smeding2025-11-26
|
* Add a simplify ruleTom Smeding2025-11-22
|
* Fix typoTom Smeding2025-11-22
|
* UnMonoid: Use eunPairTom Smeding2025-11-13
|
* Sparse: Maybe prevent another SpSparse introductionTom Smeding2025-11-13
|
* User-facing API suggestionTom Smeding2025-11-11
|
* hlint cleanupTom Smeding2025-11-10
|
* Use ImportQualifiedPostTom Smeding2025-11-10
|
* Move module hierarchy under CHAD.Tom Smeding2025-11-10
|
* WIP fold: Implement D[fold1i]Tom Smeding2025-10-23
| | | | Still need to handle the new primitives in the rest of the library
* Complete occCountXTom Smeding2025-10-08
|
* Put smart accumulator redirection behind config flagTom Smeding2025-06-18
|
* Give DeepZero to WithTom Smeding2025-06-18
|
* Tests pass, should check if output is sensibleTom Smeding2025-06-18
|
* CHAD.hs compilesTom Smeding2025-06-16
|
* WIP mixed static/dynamic sparsityTom Smeding2025-06-06
|
* Reorder TLEither to after TEitherTom Smeding2025-04-29
|
* Complete monoidal accumulator rewriteTom Smeding2025-04-29
|
* WIP revamp accumulators again: explicit monoid typesTom Smeding2025-04-27
| | | | | | | | No more D2 in accumulators! Paving the way for configurable sparsity of products and arrays. The idea is to make separate monoid types for a "product cotangent" and an "array cotangent" that can be lowered to either a sparse monoid or a non-sparse monoid. Downsides of this approach: lots of API duplication.
* An unused function (descrPrj)Tom Smeding2025-04-18
|
* Populate accumMapTom Smeding2025-04-06
|
* Split product lets before chadTom Smeding2025-04-05
|
* Pass around an accumMap (but it's empty still)Tom Smeding2025-03-28
|
* D2[Array] now has a Maybe instead of zero-size for zeroTom Smeding2025-03-26
| | | | Remaining problem: 'add' in Compile doesn't use the D2 stuff
* Much process with accumulator revampTom Smeding2025-03-14
|
* Clean up code organisation a littleTom Smeding2025-03-09
|
* Compile: Implement EWith (TODO EAccum)Tom Smeding2025-03-05
| | | | That's going to be a mess
* test: Simplify and make it a bit fasterTom Smeding2025-02-28
|
* Pretty-printer that supports extension fieldsTom Smeding2025-01-28
|
* Add ext field to remaining AST constructorsTom Smeding2025-01-27
|
* WIP accum top-level argsTom Smeding2024-11-26
|
* Prepare for introducing top-level args in accum modTom Smeding2024-11-23
|
* Configuration for CHADTom Smeding2024-11-14
|
* BenchmarkTom Smeding2024-11-07
|
* Towards a test suiteTom Smeding2024-10-07
|
* WIP better zero/plus, fixing Accum (...)Tom Smeding2024-09-13
The accumulator implementation was wrong because it forgot (in accumAdd) to take into account that values may be variably-sized. Furthermore, it was also complexity-inefficient because it did not build up a sparse value. Thus let's go for the Haskell-interpreter-equivalent of what a real, fast, compiled implementation would do: just a tree with mutable variables. In practice one can decide to indeed flatten parts of that tree, i.e. using a tree representation for nested pairs is bad, but that should have been done _before_ execution and for _all_ occurrences of that type fragment, not live at runtime by the accumulator implementation.
generated by cgit v1.2.3-70-g09d2 (git 2.52.0) at 2026-01-27 08:27:09 +0100