import StraightLinePrograms package #125
Commits on May 9, 2020
Commits on May 10, 2020
-
-
-
-
-
-
-
-
add an explicit uniplus (== return) to SLP with empty lines
For constants or generators for example, `.lines` was empty which was causing problems e.g. for printing. We now add an explicit "return", via `uniplus`, to all programs, so that `.lines` is never empty for valid SLPs.
-
-
add explicit return (uniplus) only for trivial programs
Or for non-trivial return (e.g. return not the result of the last instruction, but this is not tested yet).
-
-
Commits on May 11, 2020
-
conversion MPoly -> SLPoly: add option to limit exponentiations
Instead of computing all x_i^k brutely, but use recursively x^k == (x^(k/2))^2 or x*(x^(k/2))^2.
-
fix bug in conversion MPoly -> SLPoly
Was due to unexpected garbage in some inner MPoly arrays.
-
-
-
-
-
Commits on May 20, 2020
Commits on May 22, 2020
-
simplify SLP representation: constants get a bit flag
So the tmpmark flag is no longer necessary, which simplifies `pushinit!` and `pushfinalize!`
-
-
introduce basic SLProgram type
Preliminary step to untie SLPs from a Polynomial representation.
-
-
-
-
-
-
Commits on May 23, 2020
Commits on May 24, 2020
-
-
-
-
-
-
-
-
-
-
-
SLProgram: move return info out of lines, into .ret field
This brings some simplifications, and will allow two SLProgram to share the same lines but return different values. The alternative is to store the return info together with the upcoming `.ptr` field packed in the final `Line`, but then this has special status and the invariant that this must appear only at the end must be checked/enforced. Better to store separately.
-
-
SLProgram: add a .ptr field, to keep track of next store location
We want to support GAP's overwrite feature: the assign op will allow to overwrite a previous result, which means that we don't always increase the size of `res` during evaluation, which means that the current length of `.lines` during SLProgram building is _not_ necessarily matching the corresponding position in `res` which will be written. `.ptr` indicates the next write location. This will also support "deleting" (trailing) positions in `res`, to erase intermediate calculations and make it easier to convert from GAP's SLPs.
Commits on May 25, 2020
-
-
-
-
SLProgram: rename .ptr -> .len and decrease by one
`.len` now refers to the length of the result vector. It means in particular that we won't allow setting the "pointer" to a random place in the result, while keeping the values stored after it.
-
enable multiple return from evaluate (was only in evaluates)
This involves type-instability which might be OK. Alternatives: 1. set the return type in SLProgram's type 2. have a third function, e.g. evaluate1 (1), evaluate (1 or many) and evaluates (many) 3. don't enable this, but do it in specialized types, e.g. in an GAPSLP's evaluate method. For now, this offers nice flexibility without clear drawback.
-
-
-
-
-
-
-
-
GAPSLProgram: check for undef slots when ngens is passed
This tries to match the validation done in GAP.
-
-
-
-
-
-
-
-
Commits on May 30, 2020
-
-
-
-
-
SLProgram: support assign doing a push!
I.e. the destination can be anywhere in the result array (as before), or correspond to the length of this array plus 1.
-
-
-
Lazy: define trivially literal_pow
Without, `x^-2` doesn't work because `inv(x)` is not defined. Even if we defined `inv(x)` eventually, we don't want `x^-2` to be defined as `inv(x)^2`, which in this lazy setting means two operations instead of one.
-
-
-
AtlasSLProgram: add compilation -> GAPSLProgram
Mostly for consistency checks.
Commits on May 31, 2020
-
SLProgram: add support for storing integers
Can be used for exponents (not yet adjusted) or for returning integers or anything which can be constructed from an Int, via the `conv` function used in evaluate! to return the result (in particular booleans, for straight-line decisions in GAP).
-
SLProgram show: use Any instead of Lazy for res
Indeed, an SLProgram can return anything, e.g. any "constant" or any "integer". In show we must be as general as possible to not error out, so Any is a safe choice (an `Union` could probably do it too).
-
-
-
GAPSLProgram/Decision: more tolerant constructors
So that they can accept the same syntax as in GAP, i.e. the exact types don't matter.
-
Commits on Jun 5, 2020
Commits on Jun 7, 2020
-
-
-
-
-
-
-
-
GAPSLProgram: fix return value in show
If the last line was an "assign" line, we didn't update properly the "running" index for return value.
-
Commits on Jun 8, 2020
Commits on Jun 9, 2020
-
add Free SLPs (and demote Lazy as an SLP)
One reason is that when `Lazy <: AbstractSLProgram`, then concrete subtype of `Lazy` are also `<: AbstractSLProgram`, which doesn't work well. Also, combining two Lazy's can change the meaning of the `Gen`s (i.e. evaluate doesn't know the index corresponding to a specific `Gen` unless a list of symbols is passed.
-
-
-
-
-
Commits on Jun 10, 2020
-
-
-
gens(::Type{Free}, n): return a Free array
Returning Any[] was useful for the Lazy type because the evaluations would not always give a Gen but more generally a Lazy.
-
-
-
Commits on Jun 15, 2020
Commits on Jun 16, 2020
-
-
-
-
-
-
-
-
-
-
-
SLProgram: remove
convargument from evaluate[!]It was vestigial and was only converting the last result, which can be done by the caller instead. It will be repurposed to convert constants.
-
-
-
SLPoly: evaluate: don't convert result using inputs array
We were converting the result via `parent(xs[1])` where `xs` is the inputs array, but this doesn't work when `xs` is empty. This conversion is probably not needed anymore, as we can pass a `conv` converter which converts all constants.
Commits on Jun 17, 2020
Commits on Jun 18, 2020
-
show: use explicit '*' for multiplication
Otherwise, we were getting stuff like "11x" actually meaning "1*1*x", which is too confusing.
Commits on Jun 19, 2020
-
SLProgram: create "list": "integrate" multiple SLPs and return their …
…list Similar to GAP's `IntegratedStraightLineProgram`.
Commits on Jun 20, 2020
Commits on Jun 22, 2020
-
-
-
Free: compose: add "flatten-mode" to avoid getting a
ComposeobjectI.e. we use evalutate to get the result of compose directly, instead of using a "lazy" Compose structure. There is currently no "lazy" mode for SLProgram and it's unclear whether such a mode is useful, so let's have a non-lazy mode for `Free` to keep 1-1 correspondence with SLProgram (better for tests among other things).
-
-
-
-
-
-
-
-