ENH: dtype argument in random.Generator.normal

[jamesbraza]

Proposed new feature or change:

It would be great to support a dtype argument in random.Generator.normal.

dtype is already supported the similar function random.Generator.standard_normal for float32 and float64 as of numpy==1.24.3. Perhaps this behavior can be easily ported over.

[DuanBoomer]

Seems like a logical path to me for enhancement.
Working on it👍

[rkern]

The omission is deliberate, but could be reconsidered. We don't want to add dtype= flexibility to all of the methods, so we restricted it to just those that are fundamental building blocks (integers(), standard_*()) where we could make use of the reduced precision to use different algorithms. I'm not particularly opposed to extending dtype= flexibility to the methods associated with the standard_*() methods, but not particularly enthusiastic about it either.

@DuanBoomer This involves a policy choice rather than just work, so it might not be a good place for a first contribution.

[DuanBoomer]

@rkern Thank you for the clarification
I didn't knew it was a deliberate omission. I just saw the issue and tried to fix it.
Can you still take some time to just see if the changes that I made would work?

I know it won't be accepted but still would love to hear your feedback.
Please take a look at it, Thank you in advance.

[rkern]

@ngoldbaum's comment on your PR is correct. That modification does not address the feature request.

[DuanBoomer]

Thank you so much for the feedback @ngoldbaum and @rkern , I will try to improve the cpython implementation on my fork just to learn something out of it.
One last request can you please guide me how to check the "numpy.Generator.normal" functions parameters if i update them.

Example: If a real user goes and types numpy.Generator.normal he will usually see the parameters to be included in it when using a editor like VS Code.
How can I see the same thing?

[bashtage]

normal makes use of some support functions that handle broadcasting and reshaping of inputs and size arguments. I believe these are only available for C double, and so implementing an effective C float path (one that would be 32-bit throughout, rather than 64 bit and then casting down) would require appropriate versions of these.