larry-discuss team mailing list archive

[Keith Goodman <kwgoodman@xxxxxxxxx>]

On Fri, Feb 5, 2010 at 10:28 AM,  <josef.pktd@xxxxxxxxx> wrote:
> On Fri, Feb 5, 2010 at 1:15 PM, Keith Goodman <kwgoodman@xxxxxxxxx> wrote:
>> 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.
>>
>
> datetime objects are also copied in lists, not sure why
>
>>>> dd = [datetime.date(2001,1,1)]
>>>> dd2  = [dd[0]]
>>>> dd
> [datetime.date(2001, 1, 1)]
>>>> dd2
> [datetime.date(2001, 1, 1)]
>>>> dd is dd2
> False
>>>> dd[0] is dd2[0]
> True
>>>> dd[0] = 4
>>>> dd2
> [datetime.date(2001, 1, 1)]
>>>> dd[0]
> 4
>
> so it doesn't look like there is a problem with datetimes,
>
> there could be problems with other objects that are labels, since
> labels can be arbitrary objects

Looks like scalars, strings, datetime.date, and tuples of those are
OK. That should cover most every case.

> I think we could ignore this for now (and stick with the current
> function) and look at it again when we have tests for the flattened
> larrys with labels that are tuples.

Yes, once assert_larry_equal is rolled out, we can change the
internals of the function and see what breaks.