Closed sean-schaefer closed 8 years ago
@sean-schaefer I did test everything on 7 and 10. I wonder if it is some conflict with the C libraries? Let me know if you are able to replicate or let me know exactly what code was throwing the bad values.
@azbones I have a hunch it has something to do with the datatypes numpy is using under the hood for those particular environments. If it was thinking for some reason the datatype was a signed integer, it would explain some of the negative values I was seeing when running my_array.prod().
Will keep you posted when I can test at home.
So it wasn't the C libraries representing signedness in a strange way like I thought, just not determining the bitness accurately. I replicated at home; installing Anaconda on Windows 10 64-bit, creating a Numpy array by default sets the array dtype to int32. On my Mac it sets to int64. The value of the array product in the notebook is too large for int32, and causes overflow -- but manually setting the dtype to int64 on the array gives the correct value.
Since I can't see any easy way to go about changing the default data types Numpy will select, to manage this in the future anytime there will be very large numeric values those running Windows 10 will need to make sure the dtype is set to int64. When I have more time I'll do some research to see if there is a better alternative.
Yea, I think the only option is setting dtype to int64. I changed week 1 and 2 to make this note, so if you can review that would be great.
Several students running Windows 10 64-bit received incorrect values (large negative numbers) when running an array product through local IPython notebooks.