larry-discuss team mailing list archive

[Keith Goodman <kwgoodman@xxxxxxxxx>]

On Fri, Feb 5, 2010 at 10:14 AM,  <josef.pktd@xxxxxxxxx> wrote:
> On Fri, Feb 5, 2010 at 1:06 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>> On Fri, Feb 5, 2010 at 9:57 AM,  <josef.pktd@xxxxxxxxx> wrote:
>>> On Fri, Feb 5, 2010 at 12:37 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>>>> On Fri, Feb 5, 2010 at 9:19 AM,  <josef.pktd@xxxxxxxxx> wrote:
>>>>> On Fri, Feb 5, 2010 at 12:01 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>>>>>> On Fri, Feb 5, 2010 at 8:52 AM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>>>>>>> On Fri, Feb 5, 2010 at 7:28 AM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>>>>>>>> On Fri, Feb 5, 2010 at 7:24 AM,  <josef.pktd@xxxxxxxxx> wrote:
>>>>>>>>> The current signature
>>>>>>>>>
>>>>>>>>> assert_larry_equal(actual, desired, msg='', dtype=True, original=None,
>>>>>>>>>                       noreference=True, nocopy=False)
>>>>>>>>>
>>>>>>>>> has 3 keywords, original, noreference, nocopy for the option to check
>>>>>>>>> whether a larry is a view or a copy.
>>>>>>>>>
>>>>>>>>> This makes 8 binary options, only 3 are relevant cases, the other 5
>>>>>>>>> combinations raise errors or are redundant. This was quite confusing
>>>>>>>>> when I used the tests, since I often forgot to use, reset a keyword,
>>>>>>>>> e.g. nocopy=True also requires setting noreference = False
>>>>>>>>>
>>>>>>>>> I think a more compact signature would be
>>>>>>>>> assert_larry_equal(actual, desired, msg='', dtype=True, original=None,
>>>>>>>>> noref=True)
>>>>>>>>>
>>>>>>>>> if not original is None:
>>>>>>>>>    if noref:
>>>>>>>>>       check noreference
>>>>>>>>>    else:
>>>>>>>>>       check nocopy
>>>>>>>>>
>>>>>>>>> otherwise don't do any reference/copy check
>>>>>>>>>
>>>>>>>>> the presence of original would indicate that we want the view check,
>>>>>>>>> `noref` would tell which one.
>>>>>>>>
>>>>>>>> This is how larry gets improved---with cleaning like that.
>>>>>>>>
>>>>>>>> I'll make the change in the trunk.
>>>>>>>
>>>>>>> I changed the function signature as you suggested. I also changed
>>>>>>> noref to iscopy. The change in the kw name will mess up your unit
>>>>>>> tests :(
>>>>>
>>>>> I will change them
>>>>>
>>>>>>>
>>>>>>> And I change the name of assert_noreference to assert_iscopy and
>>>>>>> assert_nocopy to assert_isview.
>>>>>>
>>>>>> Here's a potential problem if the label contains objects:
>>>>>>
>>>>>>>> import datetime
>>>>>>>> x = larry([1, 2] , [[9, datetime.date(2009,1,1)]])
>>>>>>>> y = larry([1, 2] , [[7, x.label[0][1]]])
>>>>>>>> x.label[0][1] is y.label[0][1]
>>>>>>   True
>>>>>>>> la.util.testing.assert_iscopy(x, y)
>>>>>>>>
>>>>>>
>>>>>> assert_iscopy and assert_isview only compare the entire axis at once:
>>>>>>
>>>>>>    for i in xrange(larry1.ndim):
>>>>>>        if larry1.label[i] is larry2.label[i]:
>>>>>>            msg.append('The labels along axis %d share a reference.' % i)
>>>>>>
>>>>>> So I should change that to loop over each label element, right?
>>>>>
>>>>> Yes. Because this is for the tests, we want to catch all cases, even
>>>>> if they don't show up in common usage.
>>>>>
>>>>> Do we have the same problem with nested labels, e.g. tuples after
>>>>> flatten?  Maybe then a recursive helper function is useful.
>>>>
>>>> Now I know why I didn't check each label element:
>>>>
>>>>>>> 9 is 9
>>>> True
>>>>
>>>> So I need to check if the object is immutable. Do you know how to do
>>>> that? A tuple is immutable, but not the elements inside. Seems
>>>> complicated.
>>>
>>> this might be a question for the python user mailinglist. I don't know
>>> what the behavior for many different types is.
>>>
>>>>>> 5.9 is 5.9
>>> True
>>>>>> np.array(5.9) is np.array(5.9)
>>> False
>>>>>> np.pi is np.pi
>>> True
>>>
>>> next mail:
>>> if we use it for test of equality of larrys as in assert_larry_equal
>>> then we can assume that the larry is aligned, otherwise we get a big
>>> test failure already and we can save the time comparing all possible
>>> combinations.
>>
>> Good point. Yes, assuming it is aligned is the way to go.
>>
>>> Does flattening solve the mutable/ nonmutable numbers problem?
>>
>> It should take care of scalars and strings. But what if some of the
>> labels are already tuples? We would need to look inside the tuples to
>> compare the elements and then the problem occurs again. Maybe as a
>> first pass I won't look inside tuples.
>
> Maybe we should check first what the different cases are, before you
> reorganize the entire function.

TDD? Never!

OK, that is a good idea. I won't do anything until you break it.