larry-discuss team mailing list archive

[josef.pktd@xxxxxxxxx]

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

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.

Josef