Nonononoooo, I understood why there are two copies of what appears to
be a "zero", and I think it's fine like that !
My question was about the number of vertices as remembered by the graph :

in one case, it says 21, but g.vertices() is only long of 20 elements.
Why aren't there two zeroes in g.vertices() ? I would expect to see
one 0, which is the integer, and one zero which is actually the member
of Z/20Z !

Sorry for this misunderstanding :-)

Nathann

On 25 July 2010 20:49, Robert Miller <r...@rlmiller.org> wrote:
> Nathann,
>
>> I understood from your explanation why Mod(1,n) is considered
>> different from 0, and it is to me the correct behaviour... But what
>> about this
>>
>> g has 21 vertices
>> len(g.vertices) == 20 ?
>>
>> Sorry if you answered already ! :-)
>
> I think the information was there, but I was not very clear. It is
> better if you just look at the code:
>
> {{{
> cdef int get_vertex(object u, dict vertex_ints, dict vertex_labels,
>                    CGraph G) except ? -2:
>    if u in vertex_ints:
>        return vertex_ints[u]
>    if (not isinstance(u, (int, long, Integer)) or
>        u < 0 or u >= G.active_vertices.size or
>        u in vertex_labels):
>        return -1
>    return u
> }}}
>
> When int(0) is input, it returns 0. When Mod(0, 20) is input, however,
> it returns -1, meaning that the object is not yet in the translation
> dictionaries (since the second block only tests for three types of
> integer). So when int(0) is input to check_vertex(), nothing gets
> added to the dictionaries. However, when Mod(0, 20) is input, it does
> add an entry to the dicts, and since 0 is already taken up (as defined
> in a bitset of which ones are used), it gets a different int. This is
> how we get two zeros in the vertex dicts.
>
> It is not clear to me how to solve this problem. One could add
> IntegerMod to the list of types to check, but that's a slippery
> slope... One very silly option is to simply make the behavior of
> adding Python ints and IntegerMods at the same time undefined, but
> there *must* be a better fix...
>
>
>
> --
> Robert L. Miller
> http://www.rlmiller.org/
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to