Fix irregular Timestamp arithmetic types #6543 #6544
Conversation
|
no exactly sure why travis doesn't run your branch (its supposed to)...but this fails under numpy < 1.7 https://travis-ci.org/jreback/pandas/jobs/20093901 need to put a conditional not to test under 1.7 (search for |
|
@jreback this reminds me: I was looking at This seems an obvious application of single responsibility principle, did anyone consider/start doing this before? Were there any pitfalls that prevented that? |
|
I stand corrected: single responsibility principle is more about OOP, I meant separation of concerns. |
|
@immerrr and how would this be different than the more interesting would be to cythonize |
|
This is not really about This would require proxying all objects and function imports that may relate to numpy via some |
|
@immerrr makes sense. Though one could argue that these are these are actually conventions that pandas uses to deal with numpy. Not bugs per se, but more 'workarounds' to treat things in a nicer manner (e.g. taking views on datetime64[ns] and such). IMHO this would only be useful as a layer above numpy, but I am not sure of the utilitiy for non-pandas (my 2c). Centralizing this would be a very nice feature as they are pretty scattered. I am all for elegant code, so I would be +1 on this. Their was some code in |
|
I am new to Travis, hopefully I got it right this time - looks like the same build works after my latest change? |
|
yep looks good pls rebase and squash to a single commit, see here: https://github.com/pydata/pandas/wiki (I can do it for you when you merge, but its nice to try to do it yourself, makes a clean workflow) essentially squash |
|
Ok, I hope I got it right. The command you posted has me rebasing on my own fork, but not incorporating the latest upstream commits, right? So you may need to do a tiny bit of work to merge release.rst ..? |
|
you can pull in the master changes by doing
or do
|
|
I think you mean "upstream/master" for me to incorporate new items from others? "origin/master" is my fork and doesn't have anything new. Sadly while the change (using upstream/master) looks good to my eyes, Travis seems to be upset. I don't understand why. |
|
yes.. |
…s dtypes in Series creation (GH6529)
Preserve .names in df.set_index(df.index) Check that df.set_index(df.index) doesn't convert a MultiIndex to an Index Handle general case of df.set_index([df.index,...]) Cleanup Add to release notes Add equality checks Fix issue on 2.6 Add example to whatsnew
…s (GH6335) BUG: Changes types used in packing structs Corrected incorrect data type conversion between pandas and Stata Remove unnecessary, potentially precision degrading cast to Series when writing data Added function to cast columns from NumPy data types to Stata data types Corrected tests for correct Stata datatypes Fixed formatting in comparison after casting Added docstring for new function and warning class BUG: Fixes and tests for extreme values in all data types The extreme values of float and double (Stata, pandas eqiv: float 32 and float64) were not correct. This resulted in incorrect truncation. The handling of missing values have been improved and code to convert missing values in any format has been added. The improvement differentiated between valid ranges for data and missing values. Additional issues were found when handling missing Dates, where missing Dates (NaT) were converted to non-missing dates when written. A test has been added for extreme numeric values as well as missing values. Fixed legacy date issue with format 114 files Added test for 114 files Added format 114 (Stata 9/10/11) data file Add test for Stata data with file format 114 Added additional data files for testing alternative Stata file formats Added expected result to test Renamed Stata data files to include file format Types used for integer conversion where always half the size they should be. Produced a bug when exporting data tables with long integer data (np.int64). Added test for integer conversion bug Added test for incorrect integer conversion from int16, int32 and int64 Added additional data files for testing alternative Stata file formats Added expected result to test Renamed Stata data files to include file format Disabled the big endian skips
BUG/TST: fix handling of slice.stop < -len, obj.iloc[:-len(obj)] should be empty BUG/TST: fix exceptions raised by Series.iloc when slice.start > len CLN: remove unused _check_slice_bound function and raise_on_error params
|
Ok, I am confused now. Not sure why a second rebase did anything, though it did, and now this PR shows everyone's commits instead of just my own (probably because my branch is now "ahead" of my origin/master). I guess I would have expected this result after my first rebase. Meanwhile, Travis is still upset. |
closes #6543
This is my first PR so I may have done a few things wrong. If I should have added my tests to a different file/location, please let me know.
I should point out that this code is also tested by many other sections of the pandas codebase, on my first pass I hadn't captured the "Timestamp - datetime" case and all sorts of things blew up. Better now. :)