tinytorch - module 02 - sonarqube consistency issue #529

New Issue

GiteaMirror · 2026-03-22T15:45:16-05:00

GiteaMirror commented

2026-03-22 15:45:16 -05:00

Originally created by @asgalon on GitHub (Mar 20, 2026).

Running SonarQube precommit checks, I got the following Maintainability / Consistency issue python:S6711 (Medium impact) in 02_activation.py, line 1048:

test_data = Tensor(np.random.randn(size).astype(np.float32))

numpy.random.Generator should be preferred to numpy.random.RandomState
This rule raises an issue when legacy numpy.random.RandomState is used.
Using a predictable seed is a common best practice when using NumPy to create reproducible results. To that end, using np.random.seed(number) to set the seed of the global numpy.random.RandomState has been the privileged solution for a long time.
numpy.random.RandomState and its associated methods rely on a global state, which may be problematic when threads or other forms of concurrency are involved. The global state may be altered and the global seed may be reset at various points in the program (for instance, through an imported package or script), which would lead to irreproducible results.
Instead, the preferred best practice to generate reproducible pseudorandom numbers is to instantiate a numpy.random.Generator object with a seed and reuse it in different parts of the code. This avoids the reliance on a global state. Whenever a new seed is needed, a new generator may be created instead of mutating a global state.
Below is the list of legacy functions and their alternatives:
    [...]
numpy.random.randn -> numpy.random.Generator.standard_normal

Now, this is with the "SonarQube for IDE" local rules, it could be that the project does not use Sonar or uses different rules or that this rule should be suppressed for some reason, so this may be just a question of the right setup that I have not found yet. In general it is a good idea to take care of things that show up as Medium or higher issues in a project to improve the overall code quality. Maybe I am overthinking this again, but I am used to a very thorough pre-release QA management from my client projects, so I feel obliged to open alt least one ticket about this class of issue for someone to review it.

Originally created by @asgalon on GitHub (Mar 20, 2026). Running SonarQube precommit checks, I got the following Maintainability / Consistency issue python:S6711 (Medium impact) in 02_activation.py, line 1048: ` test_data = Tensor(np.random.randn(size).astype(np.float32))` ``` numpy.random.Generator should be preferred to numpy.random.RandomState This rule raises an issue when legacy numpy.random.RandomState is used. Using a predictable seed is a common best practice when using NumPy to create reproducible results. To that end, using np.random.seed(number) to set the seed of the global numpy.random.RandomState has been the privileged solution for a long time. numpy.random.RandomState and its associated methods rely on a global state, which may be problematic when threads or other forms of concurrency are involved. The global state may be altered and the global seed may be reset at various points in the program (for instance, through an imported package or script), which would lead to irreproducible results. Instead, the preferred best practice to generate reproducible pseudorandom numbers is to instantiate a numpy.random.Generator object with a seed and reuse it in different parts of the code. This avoids the reliance on a global state. Whenever a new seed is needed, a new generator may be created instead of mutating a global state. Below is the list of legacy functions and their alternatives: [...] numpy.random.randn -> numpy.random.Generator.standard_normal ``` Now, this is with the "SonarQube for IDE" local rules, it could be that the project does not use Sonar or uses different rules or that this rule should be suppressed for some reason, so this may be just a question of the right setup that I have not found yet. In general it is a good idea to take care of things that show up as Medium or higher issues in a project to improve the overall code quality. Maybe I am overthinking this again, but I am used to a very thorough pre-release QA management from my client projects, so I feel obliged to open alt least one ticket about this class of issue for someone to review it.

GiteaMirror added the type: bug area: tinytorch labels 2026-03-22 15:45:16 -05:00

GiteaMirror referenced this issue

2026-04-11 07:50:41 -05:00

[GH-ISSUE #529] Include a chapter about TensorRT #1468

GiteaMirror referenced this issue

2026-04-19 12:06:16 -05:00

[GH-ISSUE #529] Include a chapter about TensorRT #4088

GiteaMirror referenced this issue

2026-04-21 21:23:39 -05:00

[GH-ISSUE #529] Include a chapter about TensorRT #5430

Sign in to join this conversation.