On Fri, Jan 23, 2009 at 1:03 PM, Robert Bradshaw
<rober...@math.washington.edu> wrote:
>
> On Jan 23, 2009, at 12:41 PM, William Stein wrote:
>
>> On Fri, Jan 23, 2009 at 9:24 AM, Martin Albrecht
>> <m...@informatik.uni-bremen.de> wrote:
>>> On Friday 23 January 2009, you wrote:
>>>> Hi Martin,
>>>>
>>>> I don't like the hash doctest changes you introduced in #4965.
>>>> They should be
>>>>
>>>> sage: hash(GF(3^4),'a')
>>>>
>>>> or
>>>>
>>>> sage: h = hash(GF(3^4),'a')
>>>>
>>>> instead of
>>>>
>>>> sage: {GF(3^4, 'a'):1} #indirect doctest
>>>> {Finite Field in a of size 3^4: 1}
>>>
>>> I disagree. h = hash(GF(3^4,'a')) encodes no information
>>> whatsoever except
>>> that the function actually returns something. Printing the
>>> explicit values is
>>> weird also because it just doesn't matter what that value is if it is
>>> sufficiently pseudo-random.
>>>
>>> sage: {GF(3^4, 'a'):1} #indirect doctest
>>> {Finite Field in a of size 3^4: 1}
>>>
>>> tests one very important use-case.
>>>
>>> Martin
>>
>> I disagree. {GF(3^4, 'a'):1} also tests nothing whatsover except
>> that the
>> hash function actually returns something. Using a dictionary with
>> key 1
>> is weird also because it just doens't matter what hash was computed.
>>
>> I think we are both wrong. Doctesting of __hash__ should be done by
>> a function:
>>
>> sage: test.hash(GF(3^4, 'a'))
>> 'ok' # or not raise exception
>>
>> The advantages of doing this:
>>
>> (1) It is readable -- it's clear what is being done -- a function
>> made for testing hashing is read.
>>
>> (2) it centralizes the design decision about what the actual test
>> should be. One huge objection to you changing all the doctests in
>> your files, is that they are now inconsistent with the rest of sage,
>> which is very jarring for readers (it certainly was for me).
>>
>> (3) it enables all kinds of interestings tests to be put in
>> test.hash. For example, suppose I wonder if there are any objects in
>> Sage with the property that calling hash multiple times doesn't get
>> "very fast" after the first call (e.g, the bug in your
>> finite_field_givaro.pyx hash that I fixed). I can easily just change
>> test.hash to test for that, run the test suite, and it will tell me
>> everywhere this happens. Or suppose I want to hunt for instances
>> where hashing is inconsistent (doesn't always return the same thing on
>> 10 calls say) -- again that's easy. Suppose we decide that
>> set([GF(3^4,'a'))]) is a good test -- we could trivially add that.
>
> This sounds like an interesting proposal, but where does test come
> from? I guess it's some global variable of some sort.
>
> I don't like how it obscures what is actually being tested, i.e. the
> desirable properties and design decisions of the hash. nor are there
> ways to overwrite it (e.g. one might want hash(5) == hash(R(5)) for
> most rings R, but if R=GF(3) this will fail.)
One can just include all that too if you want.
William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
