Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix finiteness condition in IsomorphismGroups #3331

Merged
merged 1 commit into from
Mar 8, 2019

Conversation

zickgraf
Copy link
Contributor

@zickgraf zickgraf commented Mar 7, 2019

Currently, the arguments of IsomorphismGroups are not handled symmetrically:

gap> F := FreeGroup(1);
<free group on the generators [ f1 ]>
gap> IsFinite( F );
false
gap> S := SymmetricGroup( 3 );
Sym( [ 1 .. 3 ] )
gap> IsFinite( S );
true
gap> IsomorphismGroups( S, F );
fail
gap> IsomorphismGroups( F, S );
Error, cannot test isomorphism of infinite groups at /usr/lib/gap/lib/morpheus.gi:2151 called from
<function "IsomorphismGroups">( <arguments> )
 called from read-eval loop at *stdin*:5
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk>

After this commit, in both cases fail is returned.

@ChrisJefferson
Copy link
Contributor

This does improve things, thanks!

Two small things:

  1. While it is a simple case, it would be nice to add a .tst file.

  2. I wonder if, just after this check, it would be worth adding a check if IsFinite(G) <> IsFinite(H) then return fail;. Obviously in the case you give in your example this is being handled, but I wonder if an explicit test would be worthwhile (seeing as we already know if the groups are finite anyway).

Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the condition is still not correct.

lib/morpheus.gi Show resolved Hide resolved
@fingolfin fingolfin added kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements release notes: to be added PRs introducing changes that should be (but have not yet been) mentioned in the release notes labels Mar 7, 2019
@fingolfin
Copy link
Member

Yes, please add a test! And I am surprised that this change made your two tests pass -- I don't see how, given that it only triggered if both inputs were infinite?! Maybe I am misunderstanding something?

@zickgraf
Copy link
Contributor Author

zickgraf commented Mar 8, 2019

@fingolfin My change worked because later in the code there is the following check:

  if Size(G)<>Size(H) then
    return fail;

What I do not like about @fingolfin's suggestion is that one cannot easily read off in which cases the error is triggered exactly. That's why I'm in favor of @ChrisJefferson's second suggestion:

if not IsFinite(G) and not IsFinite(H) then
  Error("cannot test isomorphism of infinite groups");
fi;
if IsFinite(G) <> IsFinite(H) then
  return fail;
fi;

Do you agree or shall I implement @fingolfin's suggestion?

@wilfwilson
Copy link
Member

Both pieces of code give the same answer in all cases...

if IsFinite(G) <> IsFinite(H) then
  return fail;
fi;
if not IsFinite(G) then
  Error(...)
fi;
if not IsFinite(G) and not IsFinite(H) then
  Error("cannot test isomorphism of infinite groups");
fi;
if IsFinite(G) <> IsFinite(H) then
  return fail;
fi;

...so I don't think it matters which one you choose.

(If G and H are both finite, they both do nothing.
If G and H have different finiteness, then the first bit of code immediately returns fail; the second bit of code skips the first condition, and returns fail on the second.
If G and H are both infinite, the first bit of code skips the first condition, and gives an error on the second; the second bit of code immediately gives the error.
In other words, the two if statements "commute".)

@zickgraf
Copy link
Contributor Author

zickgraf commented Mar 8, 2019

My current commit also gives the same answer in all cases because of the existing check Size(G)<>Size(H), so of course this is only a matter of code style.

@ChrisJefferson
Copy link
Contributor

The only reason to bail earlier is there could be cases where we know group G is infinite, group H is finite (for example, H could be a permutation group), but we don't actually know H's size, and calcaulating it is expensive.

However, this is just an optimisation, and fixing the bug is obviously more important.

@codecov
Copy link

codecov bot commented Mar 8, 2019

Codecov Report

Merging #3331 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #3331      +/-   ##
==========================================
+ Coverage   85.25%   85.26%   +<.01%     
==========================================
  Files         697      697              
  Lines      344151   344150       -1     
==========================================
  Hits       293423   293423              
+ Misses      50728    50727       -1
Impacted Files Coverage Δ
lib/morpheus.gi 84% <100%> (ø) ⬆️
src/hpc/threadapi.c 46.8% <0%> (+0.03%) ⬆️

@zickgraf
Copy link
Contributor Author

zickgraf commented Mar 8, 2019

I have pushed a test file and my suggestion from above. I hope that I did put the test file in the correct directory.

@coveralls
Copy link

coveralls commented Mar 8, 2019

Coverage Status

Coverage increased (+0.0001%) to 85.075% when pulling d2f34a1 on zickgraf:fix_finiteness_condition into c07bf5e on gap-system:master.

@fingolfin
Copy link
Member

I disagree with this solution, because before the Size check, there is an IsAbelian check, and that can easily run into an infinite loop for infinite groups.

@fingolfin
Copy link
Member

Where "this solution" referred to "leave it to the Size check later on". But it seems you now did what I suggested anyway, so that should be fine.

@fingolfin
Copy link
Member

Could you please squash this into a single commit?

If one group is finite and the other is infinite, the answer is always `fail`
@zickgraf
Copy link
Contributor Author

zickgraf commented Mar 8, 2019

Done!

@fingolfin fingolfin merged commit 1213dab into gap-system:master Mar 8, 2019
@zickgraf zickgraf deleted the fix_finiteness_condition branch March 11, 2019 09:42
@DominikBernhardt DominikBernhardt added release notes: added PRs introducing changes that have since been mentioned in the release notes and removed release notes: to be added PRs introducing changes that should be (but have not yet been) mentioned in the release notes labels Aug 21, 2019
@olexandr-konovalov olexandr-konovalov added this to the GAP 4.11.0 milestone Feb 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements release notes: added PRs introducing changes that have since been mentioned in the release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants