Merge pull request #602 from SciSharp/npalign

[Random, Alignment] Refactor np.random.* to match NumPy parity

Author: Nucs

.claude/skills/np-function/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: np-function
+description: Implement numpy np.* functions in NumSharp with full API parity. Use when adding new numpy functions, implementing np.* methods, or aligning NumSharp behavior with numpy 2.4.2.
+---
+
+We are looking to support numpy's np.* to the fullest. we are aligning with numpy 2.4.2 as source of truth and are to provide exact same API (np.* overloading) as numpy does.
+This session we focusing on: """$ARGUMENTS"""
+You job is around interacting with np.* functions (no more than a few. more than one ONLY if they are closely related).
+
+To interact/develop/create a np.* / function, high-level development cycle is as follows:
+1. Read how numpy (K:\source\NumSharp\src\numpy) exposes the np function/s you are about to implement. Remember, numpy is the source of truth and if numpy does A, we do A but in NumSharp's C# way.
+Definition of Done:
+- At the end of this step you understand to 100% how the np function both works, behaves and accepts.
+If numpy function uses other np.* functions then you are to report them to the team leader and wait for further instructions. If the function is relative to you then take ownership over it and add it to your group of functions.
+2. Implement np methods in the appropriate np class and if custom calculation/math is required via backend then follow the Tensor and IL Kernel way. You are not allowed to implement a hardcoded loop per dtype. Usually other np.* calls is all a numpy function requires. Always reuse existing architecture rather than create a new one.
+Definition of Done:
+    - What Numpy supports, we support.
+    - We support all dtypes (no hardcoded loops, use il generation via our backend if necessary).
+    - We have all the apis the np function has and all the overloads.
+    - We calculate exactly like numpy because only that way we can capture all the design edge cases and implicit behaviors.
+3. Then migrate the tests that numpy has from numpy to C# and then produce your own set of tests covering all aspects of the api that you will battletest. Any bugs should be fixed on the spot.
+Definition of Done:
+    - All numpy tests have been migrated to NumSharp C#.
+    - We used battletesting to find edge cases and other bugs in our implementation where numpy works. Our source of truth for behavior is numpy!
+4. Review the implementation, definitions of done and confirm alignment to numpy is as close as possible. Ensure documentation in code.
+5. Commit and report completion.
+
+## Tools:
+### Battletesting
+Use battletesting to test and validate assumptions or even hunt edge cases: which is using 'dotnet run << 'EOF'' and 'python << 'EOF'' to run any code for any of these purposes.
+
+## Instructions to Team Leader
+- Create at-least 4 users if the task can be parallelised to that level and if not then use less
+    - Do not wait for other teammates to complete, always have N teammates developing until all the work is completed by definition of done.
+    - If user asked for 1 of something there there is only a reason to launch one teammate and not five.
+- When the teammate have completed development all the way to last step and all definition of done: finish and shutdown the teammate.
+- You are to give the instructions to the teammates word-for-word based on this document with your own adaptation below the original version.

.claude/skills/np-tests/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: np-tests
+description: Write and migrate numpy tests for NumSharp functions. Use when adding tests for np.* methods, migrating numpy test suites, or battletesting NumSharp implementations against numpy 2.4.2.
+---
+
+We are looking to test numpy's np.* implementations to the fullest. we are aligning with numpy 2.4.2 as source of truth and are to validate exact same behavior as numpy does.
+This session we focusing on: """$ARGUMENTS"""
+Your job is around writing tests for np.* functions (no more than a few. more than one ONLY if they are closely related).
+
+To interact/develop/create tests for np.* functions, high-level development cycle is as follows:
+1. Find and read numpy's tests for the function/s you are about to test. Tests are in K:\source\NumSharp\src\numpy under numpy/_core/tests/, numpy/lib/tests/, etc. Remember, numpy is the source of truth.
+Definition of Done:
+- At the end of this step you understand 100% what numpy tests: inputs, outputs, edge cases, error conditions, dtype behaviors.
+- You have identified all test files and test methods related to your function.
+2. Migrate numpy's tests to C# following TUnit framework patterns in test/NumSharp.UnitTest. Match numpy's test structure and assertions exactly.
+Definition of Done:
+    - Every numpy test case has a corresponding C# test.
+    - We cover all dtypes NumSharp supports (Boolean, Byte, Int16, UInt16, Int32, UInt32, Int64, UInt64, Char, Single, Double, Decimal).
+    - Test names reflect what they test (e.g., Test_Sort_Axis0_Int32).
+    - Assertions match numpy's expected values exactly.
+3. Battletest to find gaps. Run python and dotnet side-by-side to discover edge cases numpy handles that we might miss.
+Definition of Done:
+    - All numpy tests pass in NumSharp.
+    - Additional edge cases discovered via battletesting are covered.
+    - Any bugs found are reported to implementation teammate or fixed on the spot.
+4. Review test coverage: empty arrays, scalar inputs, negative axis, broadcasting, NaN/Inf handling, dtype promotion, error conditions.
+5. Commit and report completion.
+
+## Tools:
+### Battletesting
+Use battletesting to validate behavior matches numpy: 'dotnet run << 'EOF'' and 'python << 'EOF'' side-by-side comparison.
+
+### Test Patterns
+```csharp
+[Test]
+public async Task FunctionName_Scenario_Dtype()
+{
+    // Arrange
+    var input = np.array(new[] { 3, 1, 2 });
+
+    // Act
+    var result = np.sort(input);
+
+    // Assert - values from running actual numpy
+    Assert.That(result.IsContiguous, Is.True);
+    Assert.That(result.GetAtIndex<int>(0), Is.EqualTo(1));
+}
+```
+
+## Instructions to Team Leader
+- Create at-least 4 users if the task can be parallelised to that level and if not then use less
+    - Do not wait for other teammates to complete, always have N teammates developing until all the work is completed by definition of done.
+    - If user asked for 1 of something there there is only a reason to launch one teammate and not five.
+- When the teammate have completed development all the way to last step and all definition of done: finish and shutdown the teammate.