Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panel constructor ignores dtype #797

Closed
CRP opened this issue Feb 17, 2012 · 3 comments

Comments

@CRP
Copy link
Contributor

commented Feb 17, 2012

I thought this was fixed(see issue 411), but it appears to keep resurfacing ;)

In [27]: a=Panel(items=range(2),major_axis=range(10),minor_axis=range(5),dtype=np.float32)

In [28]: a[0].dtypes
Out[28]:
0 float64
1 float64
2 float64
3 float64
4 float64

A quick debug shows that the routine form_blocks just considers generic "float", "int" etc datatypes, so maybe it does not distinguish between float32 and float64?

@adamklein

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2012

This is an analog of another issue #622

Which currently we don't really have short-term plans to attack. In short, it converts to float64 as a "feature" to keep the API simpler

@wesm

This comment has been minimized.

Copy link
Member

commented Mar 16, 2012

More work is needed in the core infrastructure to enable the use of the full NumPy dtype hierarchy without allowing the complexity to leak through to the average user

jreback added a commit to jreback/pandas that referenced this issue Feb 8, 2013
ENH: allow propgation and coexistance of numeric dtypes (closes GH pa…
…ndas-dev#622)

     construction of multi numeric dtypes with other types in a dict
     validated get_numeric_data returns correct dtypes
     added blocks attribute (and as_blocks()) method that returns a dict of dtype -> homogeneous Frame to DataFrame
     added keyword 'raise_on_error' to astype, which can be set to false to exluded non-numeric columns
     fixed merging to correctly merge on multiple dtypes with blocks (e.g. float64 and float32 in other merger)
     changed implementation of get_dtype_counts() to use .blocks
     revised DataFrame.convert_objects to use blocks to be more efficient
     added Dtype printing to show on default with a Series
     added convert_dates='coerce' option to convert_objects, to force conversions to datetime64[ns]
     where can upcast integer to float as needed (on inplace ops pandas-dev#2793)
     added fully cythonized support for int8/int16
     no support for float16 (it can exist, but no cython methods for it)

TST: fixed test in test_from_records_sequencelike (dict orders can be different on different arch!)
       NOTE: using tuples will remove dtype info from the input stream (using a record array is ok though!)
     test updates for merging (multi-dtypes)
     added tests for replace (but skipped for now, algos not set for float32/16)
     tests for astype and convert in internals
     fixes for test_excel on 32-bit
     fixed test_resample_median_bug_1688 I belive
     separated out test_from_records_dictlike
     testing of panel constructors (GH pandas-dev#797)
     where ops now have a full test suite
     allow slightly less sensitive decimal tests for less precise dtypes

BUG: fixed GH pandas-dev#2778, fillna on empty frame causes seg fault
     fixed bug in groupby where types were not being casted to original dtype
     respect the dtype of non-natural numeric (Decimal)
     don't upcast ints/bools to floats (if you say were agging on len, you can get an int)
DOC: added astype conversion examples to whatsnew and docs (dsintro)
     updated RELEASE notes
     whatsnew for 0.10.2
     added upcasting gotchas docs

CLN: updated convert_objects to be more consistent across frame/series
     moved most groupby functions out of algos.pyx to generated.pyx
     fully support cython functions for pad/bfill/take/diff/groupby for float32
     moved more block-like conversion loops from frame.py to internals.py (created apply method)
       (e.g. diff,fillna,where,shift,replace,interpolate,combining), to top-level methods in BlockManager
@jreback

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2013

@wesm this should be closable for 0.11

@jreback jreback closed this Mar 14, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.