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

Single float value in numba Dict #5594

Closed
oiluigio opened this issue Apr 20, 2020 · 4 comments
Closed

Single float value in numba Dict #5594

oiluigio opened this issue Apr 20, 2020 · 4 comments
Labels
question Notes an issue as a question

Comments

@oiluigio
Copy link

I am trying to set a dictionary with int64 as keys and single precision float32 as values.
For example:

from numba.typed import Dict
from numba import types

dict = Dict.empty(
key_type=types.int64,
value_type=types.float32
)

When I assign one single precision value for example to dict[0]
and check what is in dict[0] I find the double precision version of the value.
Curiously if I print with a format identifier %f a single precision value is printed,
but dict[0] is truly a double precision value.

here is a minimal reproducer, I use numba 0.49.0

numba_Dict_float32.txt

@sklam sklam added the question Notes an issue as a question label Apr 20, 2020
@sklam
Copy link
Member

sklam commented Apr 20, 2020

When returning a numba.types.float32 from compiled code, Numba will use the python float representation, which is double-precision. So when reading dict[0] from the non-compiled code, you will see a double-precision value. The reason being that there is no builtin single-precision float type in Python and the numpy.float32 type is very slow.

As for print formatting, it is not an accurate way to tell if the value is single or double precision. You are seeing the difference in decimal precision of the formatter.

@oiluigio
Copy link
Author

Are you suggesting that it is only a matter of print formatting and that numba.typeof should produce a different response? numba.typeof seems to indicate that the type has changed:
numba_Dict_float32_typeof.txt

@stuartarchibald
Copy link
Contributor

@oiluigio RE formatting in GitHub issues, for future reference triple backticks can be used to create a code block (with optional language syntax specified), for example: ```python <your code> ```. GitHub also has a basic guide to its markdown syntax available here.

This is your last posted example in such a code block:

import numpy as np
import numba as nb
from numba.typed import Dict
from numba import types


dict = Dict.empty(
    key_type=types.int64,
    value_type=types.float32
)


value = types.float32(np.random.rand()) 
value_type = nb.typeof(value)
print("value is %f, according to numba.typeof type is %s "%(value,value_type))

dict[0] = value
print("I assign value to dict[0]")
print("If I use formatted print value of dict[0] is %lf"%dict[0])
print("If I use plain print value with no formatting dict[0] is ", end ='')
print(dict[0])
print("According to numba.typeof type of dict[0] is %s" %nb.typeof(dict[0]))

@sklam
Copy link
Member

sklam commented Apr 27, 2020

RE: #5594 (comment)

@oiluigio, yes, it's mostly a matter of formatting and the change of type (float32 being returned as float64) is a quirk with Numba that will not result in a loss of precision.

When I run your script, I got:

value is 0.876713, according to numba.typeof type is float32
I assign value to dict[0]
If I use formatted print value of dict[0] is 0.876713
If I use plain print value with no formatting dict[0] is 0.8767133951187134
According to numba.typeof type of dict[0] is float64

In [2]: str(0.876713)
Out[2]: '0.876713'

In [3]: print(0.876713)
0.876713

# Formatting for float32
In [4]: str(np.float32(0.876713))
Out[4]: '0.876713'

# Formatting for float64
In [5]: str(np.float64(np.float32(0.876713)))
Out[5]: '0.8767129778862'

# Values are equal?
In [6]: np.float64(np.float32(0.876713)) == np.float32(0.876713)
Out[6]: True

@sklam sklam closed this as completed Apr 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Notes an issue as a question
Projects
None yet
Development

No branches or pull requests

3 participants