Re: [fricas-devel] Additive Abelian Groups
Hallo Martin I've been glancing over your code @github...algebraictopology.spad and I'm quite impressed how elaborate it is. Although I didn't perform any calculations yet, I can see that one can already solve some simple problems. I'm using an embedding of Kenzo at the moment -- https://www-fourier.ujf-grenoble.fr/~sergerar/Kenzo/ -- because I'm not aware of any algtop code in Fricas. It would be nice of course to have the "power" of Kenzo (natively) in spad ;) I'd be content if only cubical homology (à la http://www.springer.com/la/book/9780387408538) would be available, what seems to be computationally (more) feasible in Fricas. Regarding CoChainComplex'es, I think this will become of interest only in connection with some topological assumptions, e.g. DeRham currents vs. differential forms. DeRhamComplex in Fricas should be completed by its "dual", DeRhamCurrent(s), then we had at least "integration over simple manifolds" (glueing of elementary surfaces/chains, e.g. pushing forward simplices or cubes). Of course abstract and/or algebraic homology/cohomology is also useful, however, the laboured problems usually come from topological duality (I'm quite aware that we cannot implement 'continuity', 'compact support' and so on, but at least one could circumvent a lot of tedious calculations). I will have an eye on the progress of your code :) Best regards Kurt Am 26.03.2016 um 11:47 schrieb Martin Baker: > On 15/03/16 13:31, Ralf Hemmecke wrote: >> For the other stuff I first have to read your explanation, but just from >> your mail I understand that elements in your "additive abelian group" >> are of the form >> >>z1 * m1 + z2 * m2 + ... + zn * mn >> >> where the mi are from some set with at least equality on it, i.e. you >> want to add and subtract such Z-linear combinations). >> >> Maybe the following session helps, see below. >> >> However, look at >> https://www.mail-archive.com/fricas-devel@googlegroups.com/msg08952.html >> Waldek is about to remove FreeAbelianGroup. >> But it's good that you posted your example. The replacement >> "IndexedDirectProductObject" should then work for your case. >> Currently it doesn't since it would require "Matrix Integer has >> Comparable", which is currently false. > > Its been a couple of weeks and so I thought I would check if anyone has > any thoughts on this? > > I have already implemented simplicial complexes and delta complexes > which appear to work well as far as I can tell. They are here: > https://github.com/martinbaker/multivector/blob/master/algebraictopology.spad > > > I now want to add chain complexes and co-chain complexes which are an > algebriation of the complexes implemented above. > > I am reluctant to do too much work on this without knowing how this > potentially interacts with the existing zoo of largely unexplained > categories and domains. > > The ChainComplex domain would be contain a sequence free abelian groups: > C0,C1,C2 ... 0 > Which are defined like this: > > C0 = Zero dimensional chain > = free abelian group on vertices. > Elements of C0 are intergral linear combinations of vertices such as: > 2x+7y+5z > > C1 = One dimensional chain > = free abelian group on directed edges (1-cells). > Elements of C1 are intergral linear combinations of edges such as: > 2xy+7xz+5yz > These don't necessarily need to be a cycle or even connected. > > C2 = two dimensional chain > = free abelian group on directed triangles (2-cells). > > It seems to me that, at this stage we are mostly interested in the > linear algebra structure so it would seem to be an unnecessary overhead > to carry around the vertex representation, perhaps we can just think of > vertexes as indexes and implement each chain like this: > Rep := List(Integer) > > However, what gives it its structure is the mappings between these free > abelian groups. So we also need (non-free) abelian groups as quotients > of free abelian group. > So the chain complex holds a set of free abelian groups (chains) and a > set of group homomorphisms. > > Rep of ChainComplex needs to be represented by: > C0,C1,C2 ... 0 > delta1:(C1) -> C0 , delta2:(C2) -> C1 ... > > where delta is a group homomorphism which respects the group structure: > > delta(u+v) = delta u + delta v > delta(u^-1) =(delta u)^-1 > > I think these group homomorphisms need to be represented by: > Matrix(Integer) > so that we can solve using IntegerSmithNormalForm? > > So the types of function that I would like to implement on ChainComplex > are: > image: (ChainComplex,delta) -> chain > kernel: (ChainComplex,delta) -> chain > > and we need to find cycles by finding null space of augmented matrix, > presumably using IntegerSmithNormalForm? > > Beyond this I would like to implement the (co)homology so it needs a way > to test if a given abelian group is isomorphic to the integers (Z) or > some sum of Z or similar structure. > > Also for a potential CoChainComplex domain, how would this relate to >
[fricas-devel] length and magnitude
Another thing which we should probably clean up. In vector.spad we have: if R has RadicalCategory and R has Ring then length : % -> R ++ length(v) computes the sqrt(dot(v, v)), i.e. the magnitude magnitude : % -> R ++ magnitude(v) computes the sqrt(dot(v, v)), i.e. the length and they are exactly the same. IMO we should have only one. My preference would go to 'length', however it seems that documentation uses 'magnitude'. Looking at uses of 'length' I have found some inconsitencies: usually number of elements is given by '#', however QueueAggregate and Tuple use 'length' (in QueueAggregate 'length' is just a synonym for '#', but in Tuple there is only 'length'). -- Waldek Hebisch -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
[fricas-devel] passing functors to a package
Hello Waldek,
the code below is a cut down version of what I would like to have.
In fact, the code works if I replace the line
Y: (E: EuclideanDomain, A: QEtaAlgebra E) -> QEtaComputationCategory(E, A)
by
Y: QEtaComputationCategory(C, F)
and use Y instead of Y(C, F) in the body of algebraBasis.
However, I would like Y to be a functor, because, roughly speaking,
there would be another parameter F2: QEtaAlgebra(C) and I would like to
call a function from Y(C, F2).
I've seen a similar construction in Aldor.
https://github.com/pippijn/aldor/blob/master/aldor/lib/algebra/src/multpoly/multpolydom/sm_rmp.as#L28
=
RecursiveMultivariatePolynomial0(_
UP: (R: Join(ArithmeticType, ExpressionType), avar: Symbol == new()
) -> UnivariatePolynomialAlgebra(R), _
R :Ring, _
V : VariableType): RecursiveMultivariatePolynomialCategory0(R,V) with {
univariate: % -> UP %;
++ `univariate(p)' returns `p' as a univariate polynomial
++ w.r.t. its main variable. This assumes that `p'
++ is not a constant.
multivariate: (UP(%), V) -> %;
++ `multivariate(p,v)' returns `p' as a multivariate
++ polynomial whose main variable is `v'. An error
++ is raised if one coeffcient of `p' does not have
++ degree zero w.r.t. `v'.
} == add {
import from Boolean, R, V, Z, MI, NNI;
RVU ==> Record(var:V,terms:U);
U ==> UP(%);
Rep == Union(base:R,poly:RVU);
..
}
=
There, the R in the definition of the argument UP is local and not the
same as the R: Ring (second argument of RecursiveMultivariatePolynomial0).
When I compile the attached qq.spad, I get the following...
initializing NRLIB QETAPKG1 for QEtaPackage1
compiling into NRLIB QETAPKG1
compiling exported algebraBasis : (F,List F) -> List F
** comp fails at level 4 with expression: **
error in function algebraBasis
(SEQ
(LET (|:| |y| (Y C F))
(|initialize| | << m >> |))
(|exit| 1 (|return| 1 (|basisElements| |y|
** level 4 **
$x:= m
$m:= (List A)
$f:=
|y| #) (|m| # . #1=#) (|t| # #) (|m| . #1#) ...)))
>> Apparent user error:
Cannot coerce m
of mode (List F)
to mode (List A)
Replacing A by F in the specification of Y, is not an option, since
eventually, I like to call Y(C, F2) and it doesn't work anyway. It gives
initializing NRLIB QETAPKG1 for QEtaPackage1
compiling into NRLIB QETAPKG1
compiling exported algebraBasis : List F -> List F
Internal Error
Error while instantiating type YCF
Any idea how I can pass a functor in SPAD?
Ralf
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
)abbrev category QETAALG QEtaAlgebra
QEtaAlgebra(C: CommutativeRing): Category == CoercibleTo OutputForm
)abbrev category QETACAT QEtaComputationCategory
QEtaComputationCategory(C: EuclideanDomain, F: QEtaAlgebra C): Category == with
initialize: List F -> %
basisElements: % -> List F
)abbrev package QETAPKG1 QEtaPackage1
QEtaPackage1(C, F, Y): Exports == Implementation where
C: EuclideanDomain
F: QEtaAlgebra C
Y: (E: EuclideanDomain, A: QEtaAlgebra E) -> QEtaComputationCategory(E, A)
Exports ==> with
algebraBasis: List F -> List F
Implementation ==> add
algebraBasis(m: List F): List F ==
y: Y(C, F) := initialize(m)
return basisElements y
Re: [fricas-devel] Additive Abelian Groups
Am 27.03.2016 um 21:04 schrieb Waldek Hebisch: > > I will not rush removal of FreeAbelianGroup. AFAICS > FreeModule and IndexedDirectProductObject should be improved > to serve as replacement for FreeAbelianGroup. Also, > Comparable should propagate to more domains to > allow efficient implementation. > In the meantime I had the same idea as you suggested below: to use a macro, and indeed, it seems not to be a big deal fixing my code this way. After the first shock I think I could live without FAG :) > Concerning nomenclature: I fell some sympathy to this argument. > But mathemetically free abelian groups and free modules are > isomorphic and structure of Z-module is helpful even if you > want to work with group. Having different type creates > artificial barrier for code reuse. IME in similar situation > it is better to have single type. Probably true, however, IMO it depends on the level of expertise, you know the "types", I have to look for them (what's admittedly much simpler since we have Ralf's API search function ...). > > Concerning breaking code: you should be able to write > something like: > > FreeAbelianGroup(S : SetCategory) == FreeModule(Integer, S) > Yes, it worked in most cases. > and then use your code as nothing happened. Of course this > assumes improved FreeModule and may require a bit more code > above to handle changed function names. > > Currently for programmer FreeModule and FreeAbelianGroup > differ in "accidental" way: type allowed for S, names and > extra convenience functions. IMO such "accidental" differences > should be eliminated. If possible, by all means. > > >> FrameVector(R,s,r) : Exports == Implementation where >> >> R:Field >> s:Symbol >> r:Segment(NonNegativeInteger) >> >> OF ==> OutputForm >> NNI ==> NonNegativeInteger >> CARD ==> CardinalNumber >> >> Exports == Join(CoercibleTo OutputForm, VectorSpace R) with >> >> getFrame : () -> List(%) >> dim : % -> NNI >> coerce : % -> OutputForm >> coerce : % -> Vector R >> coerce : Vector(R) -> % >> >> Implementation == FreeModule(R,OrderedVariableList _ >> [subscript(s,[j::OF]) for j in lo(r)..hi(r)]) add >> >> >> B:=OrderedVariableList [subscript(s,[j::OF]) for j in lo(r)..hi(r)] >> L:List(B):= enumerate()$B >> n:NNI:=#L >> >> Rep := FreeModule(R,B) > > Hmm, I do not see why you need Rep here. If you really need > this code and simpler without Rep will not work we probably > should think about improvements to compiler or Spad language. > You're probably right, it might work without 'Rep', but it's not so important to me anymore. I used the code just for convenience (sparse vectors/covectors with n>17), just to avoid long lists in the types. Thank you Kurt -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
