WIP Allow lists to be indexed by multiple values #83
Conversation
… bit of old commented out code relating to the equivalent change for access some time ago.
Moreover, - use of IS_POS_INTOBJ in multiple places for readability and efficiency - enforce consistent behavior for ELM/ASS/ISB/UNB, and also between interpreted and compiled code: positive integers as before, while anything else (including non-positive integers) is sent through method dispatch - some code cleanup (indention, uniform whitespace in comments, etc.)
This provides parser interpreter and coder support for multi-index access to lists At the moment all such accesses are translated into calls to ELM_LIST with a single argument which is a plain list of the indices, but there is kernel support for a fast-path for two arguments later if one is needed. At this stage printing of coded expressions, assignment, IsBound and Unbind are all to do, as are nested list accesses. l[...][x,y].
mohamed-barakat
added
the
gapdays2015-spring
This reverts commit 3b00d9f.
This is obsoleted by GapDOC.
Alexander moved this to the gap-distribution repository
etc/install-tools.sh is a script to unpack etc/tools.tar.gz archive included in the GAP distribution and described in etc/README.tools.
Added: - IsNonAtomicComponentObjectRep - IsReadOnlyPositionalObjectRep - IsAtomicPositionalObjectRep - FixedAtomicList - MakeWriteOnceAtomic
1. when -K is given and -s is larger then reduce -s option, it is useless to pre-map memory which we never want to use. 2. fixed the output of 'gap -h': '-p' was mentioned twice and '-s' was not mentioned at all.
…e' the rank needs also to be lowered to avoid overranking the special pc/perm methods.
This is an attempt at fixing an issue reported by Chris Wensley on GAP Support on the 30th of June. The code that exhibits the problem is the following ``` gap> F := Rationals;; gap> m := [ [0,1,2], [0,0,3], [0,0,0] ];; gap> A := Algebra( F, [m] );; gap> basA := Basis(A);; gap> vecA := BasisVectors(basA);; gap> dimA := Dimension(A);; gap> ## now replace m^2 with m^3, the zero matrix: gap> S := Subalgebra( A, [m^3] ); <algebra over Rationals, with 1 generators> gap> basS := Basis(S);; gap> vecS := BasisVectors(basS);; gap> dimS := Dimension(S); 0 gap> homS := AlgebraGeneralMappingByImages( S, S, vecS, vecS ); [ ] -> [ ] gap> B := Algebra( F, [homS] ); <algebra over Rationals, with 1 generators> gap> map := AlgebraGeneralMappingByImages( A, B, vecA, [homS,homS] ); ``` And the problem is caused by not handling the zero mapping/zero matrix in NiceFreeLeftModule and the element test \in for vector spaces handled by a nice basis.
This provides parser interpreter and coder support for multi-index access to lists At the moment all such accesses are translated into calls to ELM_LIST with a single argument which is a plain list of the indices, but there is kernel support for a fast-path for two arguments later if one is needed. At this stage printing of coded expressions, assignment, IsBound and Unbind are all to do, as are nested list accesses. l[...][x,y].
Merge branch 'sl/multi-index' of https://github.com/stevelinton/gap into sl/multi-index
|
Tried to rebase this onto current master. Clearly I messed up horribly. Can anyone advise? |
|
Hi Steve, not entirely sure what you did there. It looks like the patches are applied twice, so maybe you tried rebasing and then merging? I think I fixed it in https://github.com/markuspf/gap/tree/rebase-pr-83 by first resetting to f4aed5e and then rebasing on master. There were three small confilcts, two in src/vars.c and one in src/code.c. @fingolfin might give more insight into what actually happened. Not sure whether I should open a new PR or overwrite this one... |
|
Woah, that's quite a mess :-). This looks indeed as if there were both merges and rebases, possibly even across multiple branches. If you then do a plain rebase, things get messy, simply because git cannot possible read your mind and know what exactly you want to rebase where (this is maybe one point where the Mercurial branch system can be helpful -- there, each commit in a hg branch is "colored" (i.e. the name of that branch is integral part of the commit record, unlike git, where branch names are just ephermal labels pointing to a single commit at the tip of a branch). Thus it "knows" what is part of that branch and what was merged into that branch from elsewhere. Of course that still doesn't make everything work magically, but, well... @stevelinton To really figure out what happens, we'd have to know the precise steps you followed over time, when working with that branch... |
|
BTW, the rebased version Markus created looks fine to me. @stevelinton To recover, you coud first fetch Markus work into your clone. Then you can reset your messed up branch to that: And then force push it to your repos to update this PR: |
This PR provides kernel support for giving multiple indices to lists.
m[1,2] is translated into m[[1,2]] although there is scope to do more for the special case of two arguments.
assignment, unbind and isbound are all supported.
It lacks testing, any library functionality and it depends on a pending PR from @fingolfin so it should not be merged as is.