pysparse-users

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

[Toine B. <tb...@iv...>]

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

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

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

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
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Pysparse-users mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysparse-users
>
>



-- 
Daniel Wheeler

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

[Roman G. <rom...@gm...>]

- 1_1_x and branch_rel_1_0 are obsolete and should be removed.
- PSI can be deleted as well
- class_branch and python-2_4 I don't know

Thanks for your cleaning efforts!

Roman

On Aug 4, 2010, at 6:00 PM, Daniel Wheeler wrote:

> 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
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://p.sf.net/sfu/dev2dev-palm
>> _______________________________________________
>> Pysparse-users mailing list
>> Pys...@li...
>> https://lists.sourceforge.net/lists/listinfo/pysparse-users
>> 
>> 
> 
> 
> 
> -- 
> Daniel Wheeler
> 
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Pysparse-users mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysparse-users