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

BUG: pm.Data does not accept dtype argument #7277

Open
ricardoV94 opened this issue Apr 22, 2024 · 1 comment
Open

BUG: pm.Data does not accept dtype argument #7277

ricardoV94 opened this issue Apr 22, 2024 · 1 comment
Labels

Comments

@ricardoV94
Copy link
Member

ricardoV94 commented Apr 22, 2024

@michaelosthege and I found out that the latest changes create issues when using pm.ConstantData (or pm.Data) and setting a dtype explicitly. We don't understand why because pytensor.shared has no problem with the dtype argument.

Here is an example:

with pm.Model():
    pm.Data("b", [True, False], dtype=bool)
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "C:\Users\osthege\AppData\Local\mambaforge\envs\dibecs_6.13.0\lib\site-packages\pymc\data.py", line 420, in Data
    x = pytensor.shared(arr, name, **kwargs)
  File "C:\Users\osthege\AppData\Local\mambaforge\envs\dibecs_6.13.0\lib\site-packages\pytensor\compile\sharedvalue.py", line 202, in shared
    var = shared_constructor(
  File "C:\Users\osthege\AppData\Local\mambaforge\envs\dibecs_6.13.0\lib\functools.py", line 889, in wrapper
    return dispatch(args[0].__class__)(*args, **kw)
TypeError: tensor_constructor() got an unexpected keyword argument 'dtype'

Do you have any idea why this is happening? Thanks in advance for your help!

Originally posted by @lhelleckes in #7047 (comment)

@ricardoV94 ricardoV94 added the bug label Apr 22, 2024
@michaelosthege michaelosthege changed the title pm.Data does not accept dtype argument BUG: pm.Data does not accept dtype argument May 2, 2024
@michaelosthege
Copy link
Member

This conversion given in #7257 is a good example for the solution that @lhelleckes and I just discussed:

Adding a convert_observed_data(value, dtype: Optional=None) option which gets priority would allow the line linked above to enforce the type and thereby avoid the casting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants