#13814: LazyFamily.__eq__ gives false positives.
------------------------------------+---------------------------------------
       Reporter:  cnassau           |         Owner:  sage-combinat
           Type:  defect            |        Status:  needs_review 
       Priority:  major             |     Milestone:  sage-5.6     
      Component:  combinatorics     |    Resolution:               
       Keywords:                    |   Work issues:               
Report Upstream:  N/A               |     Reviewers:               
        Authors:  Christian Nassau  |     Merged in:               
   Dependencies:                    |      Stopgaps:               
------------------------------------+---------------------------------------

Comment (by nthiery):

 Replying to [comment:10 cnassau]:
 > This has some really bad consequences if (as I believe) we're __not__
 able to reliably test functions for equality. We would then have to live
 with
 >
 >    {{{
 >    sage: LazyFamily([1,2,3], lambda i:i) == LazyFamily([1,2,3], lambda
 i:i)
 >    False
 >    }}}

 That is perfectly fine for me: if the caller asked explicitly for a
 lazy family, then (s)he should expect the comparison to be lazy, and
 thus cheap but incomplete. If she is willing to pay the price of
 computing the function on all indices, then a FiniteFamily is what she
 wants.

 > As noted in `src/categories/enumerated_sets.py` a set can choose to not
 implement `list` if it is probably too large to be useful.

 Yup. But there are a lot of sets, like Permutations(n) that can be
 very small or very large, and such sets cannot make a good decision.
 At the end of the day, it's better to take the decision upon building
 the family (by asking explicitly for a lazy family or not).

 > I've changed my mind: this is not at all a good idea: in my tests an
 `unpickle_function(lambda i:i)` includes a reference to the doctest where
 it was defined. That's not good at all if we want to test for function
 equality... for similar reasons it seems bad to use the bytecode
 disassembly from the dis module...

 Ok!

 Kind regards,
                             Nicolas

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13814#comment:11>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to