The problem is that you do not do any type conversion of the numpy array. You calculate a float32 variable and put it as an entry into a float64 numpy array. numpy then converts it properly back to float64

Try someting like this:

a = np.zeros(4,dtype="float64") 
print a.dtype
print type(a[0])
a = np.float32(a)
print a.dtype
print type(a[0])

The output (tested with python 2.7)

float64
<type 'numpy.float64'>
float32
<type 'numpy.float32'>

a is in your case the array tree.tree_.threshold

The tolist() method should do what you want. If you have a numpy array, just call tolist():

In [17]: a
Out[17]: 
array([ 0.        ,  0.14285714,  0.28571429,  0.42857143,  0.57142857,
        0.71428571,  0.85714286,  1.        ,  1.14285714,  1.28571429,
        1.42857143,  1.57142857,  1.71428571,  1.85714286,  2.        ])

In [18]: a.dtype
Out[18]: dtype('float64')

In [19]: b = a.tolist()

In [20]: b
Out[20]: 
[0.0,
 0.14285714285714285,
 0.2857142857142857,
 0.42857142857142855,
 0.5714285714285714,
 0.7142857142857142,
 0.8571428571428571,
 1.0,
 1.1428571428571428,
 1.2857142857142856,
 1.4285714285714284,
 1.5714285714285714,
 1.7142857142857142,
 1.857142857142857,
 2.0]

In [21]: type(b)
Out[21]: list

In [22]: type(b[0])
Out[22]: float

If, in fact, you really have python list of numpy.float64 objects, then @Alexander's answer is great, or you could convert the list to an array and then use the tolist() method. E.g.

In [46]: c
Out[46]: 
[0.0,
 0.33333333333333331,
 0.66666666666666663,
 1.0,
 1.3333333333333333,
 1.6666666666666665,
 2.0]

In [47]: type(c)
Out[47]: list

In [48]: type(c[0])
Out[48]: numpy.float64

@Alexander's suggestion, a list comprehension:

In [49]: [float(v) for v in c]
Out[49]: 
[0.0,
 0.3333333333333333,
 0.6666666666666666,
 1.0,
 1.3333333333333333,
 1.6666666666666665,
 2.0]

Or, convert to an array and then use the tolist() method.

In [50]: np.array(c).tolist()
Out[50]: 
[0.0,
 0.3333333333333333,
 0.6666666666666666,
 1.0,
 1.3333333333333333,
 1.6666666666666665,
 2.0]

If you are concerned with the speed, here's a comparison. The input, x, is a python list of numpy.float64 objects:

In [8]: type(x)
Out[8]: list

In [9]: len(x)
Out[9]: 1000

In [10]: type(x[0])
Out[10]: numpy.float64

Timing for the list comprehension:

In [11]: %timeit list1 = [float(v) for v in x]
10000 loops, best of 3: 109 µs per loop

Timing for conversion to numpy array and then tolist():

In [12]: %timeit list2 = np.array(x).tolist()
10000 loops, best of 3: 70.5 µs per loop

So it is faster to convert the list to an array and then call tolist().

1. If the dataframe (say df) wholly consists of float64 dtypes, you can do:

df = df.astype('float32')

2. Only if some columns are float64, then you'd have to select those columns and change their dtype:

# Select columns with 'float64' dtype  
float64_cols = list(df.select_dtypes(include='float64'))

# The same code again calling the columns
df[float64_cols] = df[float64_cols].astype('float32')

Will numpy.float32 help?

>>>PI=3.1415926535897
>>> print PI*PI
9.86960440109
>>> PI32=numpy.float32(PI)
>>> print PI32*PI32
9.86961

If you want to do math operation on float32, convert the operands to float32 may help you.

20140131.0 can't be represented as a 32 bit integer.

32 bit float

64 bit float

With floats, within each range, the numbers are evenly spaced.

So it's (1+M) * 2^(E)

so 20140131.0 is in the range of 2^24 to 2^25. There are 16,777,216 numbers in that range, but only 8,388,608 representable floats. So you can only represent even numbers.

Since in 32bit floats, there are only 23 bits for the mantissa, integers can only be represented up to 2^24. Above that, epsilon > 1. Where epsilon is the difference between two adjacent floating point numbers.

As for python floats, i believe they work like this:

Floats in python are typically not 32 bit, or 64 bit, so this isn't a problem. The length is adjusted automatically. Buy you're casting them to specific types, so you see the lack of resolution. With 64bit integers, there are 52 bits in the mantissa, so you will not see this problem until you go above 2^53.

Also, the way the number is rounded to the nearest float is normally defined in a system wide manner (i think), but python's casting may over rule this, i'm not completely familiar with it.