Re: [Pysparse-users] Has the keys() method changed behavior?

[Daniel W. <dan...@gm...>]

Merged source:branches/keys to source:branches/version-1_1 and
source:trunk and removed source:branches/keys.

Cheers

On Fri, Aug 6, 2010 at 7:40 AM, Toine Bogers <tb...@iv...> wrote:
> Thanks, that seems to have done the job! Thanks for the speedy response!
>
> -Toine
>
>> I reverted keys() back to its old behavior. I don't know why I changed
>> it in the first place.  It's on branches/keys right now, so check it
>> out and make sure it does what you want and I'll merge back to
>> branches/version-1_1 and trunk.
>>
>> Can we tidy up branches by removing some of the dead wood in there?
>> Can I delete 1_1_x, PSI, branch_numpy, branch_rel_1_0, class_branch,
>> python-2_4?
>>
>> On Tue, Aug 3, 2010 at 5:21 AM, Toine Bogers <tb...@iv...
>> wrote:
>>> Dear PySparse maintainers,
>>> First of all: thanks for creating PySparse! It's been extremely useful in
>> writing my Python code for my collaborative filtering experiments. Up till
>>> now I never really had any problems with it, but after I migrated to
>>> v1.1.1 I ran into a peculiar 'bug/feature' with the keys() method.
>>> I used to run v1.0 of PySparse on OS X 10.5 without any problems. I tried
>>> installing the later versions, but they would never compile and the .dmg
>>> of
>>> v1.0 on SourceForge worked fine for me. I recently migrated to Snow
>>> Leopard
>>> (clean install) and to my surprise I could compile and install the latest
>>> version of PySparse (v1.1.1) without any problems.
>>> At first glance everything seemed to work just fine until I ran one of my
>>> larger scripts. It returned a very peculiar error: the keys() method no
>>> longer works as it should. Instead of returning a list of tuples of (row,
>>> column)-indices it now returns a list containing two lists, one
>>> containing
>>> all row indices, the other containing all column indices
>>> The following example shows what I mean. I've created a small 3x3 sparse
>>> matrix A:
>>>>> print A
>>> ll_mat(general, [3,3]):
>>>  1.000000  2.000000  --------
>>>  1.000000  1.000000  2.000000
>>>  4.000000  5.000000  4.000000
>>> Then when I print out the keys, it returns this:
>>>>> print A.keys()
>>> [[0, 0, 1, 1, 1, 2, 2, 2], [0, 1, 0, 1, 2, 0, 1, 2]]
>>> whereas it used to return:
>>> [[0, 0], [0, 1], [1, 0], [1, 1], [1, 2], [2, 0], [2, 1], [2, 2]]
>>> And of course all of my code is expecting that method to work like that.
>>> The
>>> online documentation still says that keys() returns "[...]a list of
>>> tuples
>>> (i,j) of the nonzero matrix entries." Which is also what I expected it to
>>> do, but not what it does anymore.
>>> The strange thing is that the items() method still returns a list of
>>> tuple-value pairs:
>>>>> print A.items()
>>> [((0, 0), 1.0), ((0, 1), 2.0), ((1, 0), 1.0), ((1, 1), 1.0), ((1, 2),
>>> 2.0),
>>> ((2, 0), 4.0), ((2, 1), 5.0), ((2, 2), 4.0)]
>>> In a way this is good, since it means I can, with some relatively minor
>>> adjusments, use the items() method instead. But I would prefer not to
>>> have
>>> to use items() when keys() is enough.
>>> Do you have an explanation for the change in behavior I've observed? Is
>>> it
>>> perhaps some sort of compilation option that I didn't set properly (which
>>> makes the underlying Fortran/C-code return its results in a different
>>> format
>>> to the keys() method)?
>>>
>>> Kind regards,
>>> Toine Bogers
>>
>> --
>> Daniel Wheeler
>
> ----
> Toine Bogers
> Royal School of Library & Information Science
> Birketinget 6 | 2300 Copenhagen S | Denmark
> http://itlab.dbit.dk/~toine/
> Phone: +45 32 34 13 67 | Room: C4.02
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Pysparse-users mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysparse-users
>
>



-- 
Daniel Wheeler