| Commit message (Collapse) | Author | Age | |
|---|---|---|---|
| * | D2[Array] now has a Maybe instead of zero-size for zero | Tom Smeding | 5 days |
| | | | | | Remaining problem: 'add' in Compile doesn't use the D2 stuff | ||
| * | Much process with accumulator revamp | Tom Smeding | 2025-03-14 |
| | | |||
| * | Clean up code organisation a little | Tom Smeding | 2025-03-09 |
| | | |||
| * | Compile: Implement EWith (TODO EAccum) | Tom Smeding | 2025-03-05 |
| | | | | | That's going to be a mess | ||
| * | Complete GMM implementation | Tom Smeding | 2024-11-10 |
| | | |||
| * | Some more primitive operators | Tom Smeding | 2024-11-09 |
| | | |||
| * | WIP better zero/plus, fixing Accum (...) | Tom Smeding | 2024-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. | |||
 |
index : chad-fast | |
| [no description] | git daemon user |
| summaryrefslogtreecommitdiff |