Figure 1.7: 'numpy.int64' error

84 views
Skip to first unread message

mason leist

unread,
Jan 25, 2021, 8:34:02 PM1/25/21
to astroML-general
Hello,

I am following along with the code from the astroML website, along with the figures in the book to become a better python coder and for the 'Phased LINEAR Light Curve' example for figure 1.7 I have received the following error code:

          AttributeError: 'numpy.int64' object has no attribute 'decode'

this error is being thrown on the following line of code:

       genevaIDs = [ID.decode('utf-8').lstrip('0') for ID in geneva['LINEARobjectID']]

I was wondering if there was someone who might be able to help me walk through resolving this issue? Thank you!

Mason Leist
University of Texas at San Antonio
Teacher Assistant 1

Kyriakos Stylianopoulos

unread,
Jan 26, 2021, 4:13:06 AM1/26/21
to mason leist, astroML-general
Hello,

I am not one of the actual contributors of astroML, let alone an astronomer, so take what I say with a grain of salt. That line of code looks like it expects the 'LINEARobjectID' column of the geneva data array to be of type byte that is intended to be decoded to a string. But that column is actually of type int (the numpy.int64 to be exact), so it does not have a .decode() method. It seems that there is a mismatch happening in the stored data as the source code of the fetch_LINEAR_geneva() function used for getting the data assumes that this column is of some sort of string type.

Anyway, since those values are integers, I tried to explicitly convert them into strings (without the need of decoding) and I was able to reproduce the plot. Essentially, I changed the error line to the same form as the one above that uses the targets['objectID']:
genevaIDs = [str(ID).lstrip('0') for ID in geneva['LINEARobjectID']]

Does this work for you? Just keep in mind that I do not know what kind of followup errors this fixup might introduce, even though it seems foolproof enough. It could always be the case that there are some weird cases in the data that are not handled properly this way.
Hope this helps.

Kind regards
--
Kyriakos Stylianopoulos
PhD Student
National and Kapodistrian University of Athens
Greece

Brigitta Sipocz

unread,
Jan 26, 2021, 8:25:53 PM1/26/21
to Kyriakos Stylianopoulos, mason leist, astroML-general
Hi Mason and Kyriakos,

Thank you for reporting this. I'm sorry about it, it hasn't been noticed when some of the internals of the data fetching was changed. I feel it's a bit more consistent now, given that the IDs are interegs for the other data file as well, so I would suggest to go ahead with the fix Kyriakos suggested.

I would not expect the proposed change to bring in any other issues, the scripts generating the figures are very much work in a standalone fashion.

I'll make a fix for this both in the repo and on the website along with a few other things that are related to this same data file.

Cheers,
 Brigitta



--
You received this message because you are subscribed to the Google Groups "astroML-general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astroml-gener...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/astroml-general/CA%2BSef20xreGvUd%3DWFKJfMrJZY%2BZRpQbnCgnKS-yrhVRsZSn-%2Bg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages