Project

General

Profile

Feature #587

port to CoCoALib: Homomorphism pkg (ker, IsInjective, IsSurjective..)

Added by Anna Maria Bigatti almost 10 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
John Abbott
Category:
New Function
Target version:
CoCoALib-0.99600
Start date:
14 Jul 2014
Due date:
% Done:

100%

Estimated time:
18.80 h
Spent time:
18.60 h

Description

Translate the package HomomorphismFns.cpkg5 into CoCoALib.
The related "utility representation" of a homomorphism as an ideal into a bigger ring should be stored inside the RingHom as a "mutable".

Related issues

Related to CoCoA-5 - Feature #273: Package for Polynomial Algebra HomomorphismsClosed2012-11-12

Related to CoCoA-5 - Bug #1140: ImplicitModular: too many bad primesClosed2017-12-14

Related to CoCoA-5 - Support #242: CoCoA-5 Projects for students (e.g. crediti F and tesi)In Progress2012-09-28

History

#1 Updated by Anna Maria Bigatti over 9 years ago

  • Estimated time changed from 4.00 h to 16.00 h

#2 Updated by John Abbott almost 7 years ago

  • Status changed from New to In Progress
  • Assignee set to John Abbott
  • % Done changed from 0 to 30

Since I had to assign some student projects after the CoCoALib mini-course (here in Kassel),
I gave the task of translating HomomorphismFns.cpkg5 into C++ to two students.

They seem to have done a good job (including finding some test cases).

Outstanding matters:
  1. incorporate the RichHom structure into the data structure(s) representing the homomorphism
  2. the students noticed that KerRichHom sometimes produces an answer with redundant generators (if domain is a quotient)
  3. the students also implemented a new fn PreimageAndKer
  4. the internal fn MakePreimageRichHom always computes the ker even when the arg is not in the image, right?

For point (2) we could take CanonicalRepr of the generators, add the gens of the DefiningIdeal of the quotient, compute RGB then take those elements of RGB which are not in the DefiningIdeal. This would give a more "canonical" answer, but it could also be "wasted effort" in some cases??

#3 Updated by John Abbott almost 7 years ago

Should I log the time the students spent on this project? If so, how? (and where?)

#4 Updated by John Abbott almost 7 years ago

  • Description updated (diff)

#5 Updated by John Abbott almost 7 years ago

  • % Done changed from 30 to 60

My "clever idea" in comment 2 for cleaning the gens of the kernel does not work well.

I have cleaned the students' code, and it is almost ready for public release, but... I have a question.

The return value of preimage does not convince me much: currently it returns a flag IsInImage, and possible 2 other fields (a particular preimage, and the ker). I think the argument is that determining whether the value lies in the image involves computing the RGB of "idealRS" (since an NF must be computed), and a set of generators for the ker can be read off this RGB.

If we plan to store the "RichHom" structure inside the datastructure for the homomorphism then the RGB of "idealRS" should be remembered from one call to another. So there is no real gain in returning a compound result... after the integration has been performed.

I propose a new fn preimage0 which returns either a preimage or the zero element of the domain. The only "ambiguity" is when asking for the preimage of zero, but that is easy for a user to handle.

What do you think?

#6 Updated by Anna Maria Bigatti almost 7 years ago

John Abbott wrote:

I propose a new fn preimage0 which returns either a preimage or the zero element of the domain. The only "ambiguity" is when asking for the preimage of zero, but that is easy for a user to handle.

I like this idea. In fact I had a similar problem in another situation.
The "real" function preimage returns error when input is unsuitable, whether preimage0 does something special with/to 0 (and the user is warned by the 0).

This approach could be useful in other situations.

#7 Updated by John Abbott over 6 years ago

  • Target version changed from CoCoALib-1.0 to CoCoALib-0.99560

What is the status of this issue? Isn't it nearly finished?

Related to thi is the use of PreImage in some CoCoA-5 packages: I think we need to revise subalgebra.cpkg5 and also obsolescent.cpkg5 (which prints out a misleading advisory message).

#8 Updated by Anna Maria Bigatti over 6 years ago

Improve the code adding weights and homogenization...
should be trivial...
(I will do it)

#9 Updated by Anna Maria Bigatti over 6 years ago

After doing some experiments we (Lorenzo Robbiano and I) are now convinced that it is always worth giving weights and homogenizing (as for ImplicitHypersurface/ImplicitModular).

We discussed the mathematics (all ok) and implemented the first function ker_H modifying minimally (even though painfully ;-) the code for ker.
The point is that the ideal representing the homomorphism is homogenous (with an extra homogenizing indet), so all functions should deal with what this implies: ker_H just dehomogenizes the output (and will be eventually replace ker).

#10 Updated by Anna Maria Bigatti over 6 years ago

ker should use implicit, and implicit should return (if not otherwise indicated) the answer in a ring with a compatible ordering, so that the result is a GBasis.

#11 Updated by Anna Maria Bigatti over 6 years ago

  • Target version changed from CoCoALib-0.99560 to CoCoALib-0.99600

#12 Updated by Anna Maria Bigatti over 6 years ago

  • Related to Bug #1140: ImplicitModular: too many bad primes added

#13 Updated by Anna Maria Bigatti over 6 years ago

  • Subject changed from port to CoCoALib: ker, IsInjective, IsSurjective.. to port to CoCoALib: Homomorphism pkg (ker, IsInjective, IsSurjective..)

#14 Updated by Anna Maria Bigatti over 6 years ago

bug in IsInImage (from cocoa5).

/**/  QQxyz ::= QQ[x,y,z];
/**/  QQab  ::= QQ[a,b];

/**/  use QQab;
/**/  phi := PolyAlgebraHom(QQxyz, QQab, [a+1, a*b+3, b^2]);
/**/  IsInImage(phi, b);

Assertion failed: (px != 0), function operator->, file ../../configuration/ExternalLibs/include/boost/smart_ptr/intrusive_ptr.hpp, line 174.

Process cocoa5 abort trap: 6

#15 Updated by Anna Maria Bigatti over 6 years ago

Anna Maria Bigatti wrote:

bug in IsInImage (from cocoa5).
[...]

working on it, very strange: code looks honest

#16 Updated by Anna Maria Bigatti over 6 years ago

  • Related to Support #242: CoCoA-5 Projects for students (e.g. crediti F and tesi) added

#17 Updated by Anna Maria Bigatti over 6 years ago

Fixed: it was just an "ARG ( 3)" instead of "ARG ( 1)" in BuiltinFunctions...

#18 Updated by John Abbott over 5 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 60 to 100
  • Estimated time changed from 16.00 h to 18.80 h

Also available in: Atom PDF