Updated GetCurrentArray to use chunkstrides#607
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request resolves a critical bug in the analysis workflow that caused incorrect values at the edges of datasets. By updating Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
The pull request addresses an issue in GetCurrentArray() where a global stride value was being used instead of individual chunkstrides, leading to incorrect values on the edges of certain datasets. The changes involve modifying GetCurrentArray() to pass chunk-specific strides to copychunk2array() and removing an unnecessary length check in AnalysisWG.tsx. These adjustments ensure accurate data analysis across different datasets.
| copyChunkToArray( | ||
| thisData, | ||
| chunkShape, | ||
| chunkStride, | ||
| chunk.shape, | ||
| chunk.stride, |
There was a problem hiding this comment.
By directly passing chunk.shape and chunk.stride to copyChunkToArray, you ensure that the correct chunk-specific parameters are used for copying data. This resolves the original issue where a global stride value was causing incorrect data analysis on the edges of certain datasets.
| copyChunkToArray( | |
| thisData, | |
| chunkShape, | |
| chunkStride, | |
| chunk.shape, | |
| chunk.stride, | |
| copyChunkToArray( | |
| thisData, | |
| chunk.shape, | |
| chunk.stride, | |
| typedArray, | |
| dataShape, | |
| strides as [number, number, number], |
|
|
||
| // --- 2. Dispatch GPU computation based on the operation --- | ||
| const inputArray = analysisMode ? analysisArray : dataArray; | ||
| const inputArray = GetCurrentArray(analysisStore) |
There was a problem hiding this comment.
By calling GetCurrentArray(analysisStore) directly, you ensure that the inputArray always reflects the most up-to-date data based on the current state of analysisStore. This eliminates the need for a conditional assignment based on analysisMode and ensures that the correct data is used for GPU computation.
| if (!operation || dataArray.length <= 1) { | ||
| if (!operation) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
The check for dataArray.length <= 1 is no longer needed because GetCurrentArray is always called, and the function itself handles cases where the data might be invalid or empty. Removing this check simplifies the logic and avoids potential issues if dataArray is unexpectedly empty or has a length of 1.
|
|
||
| for (let z = zStartIdx; z < zEndIdx; z++) { |
GetCurrentArray()was using a global stride value but thecopychunk2array()function wants individual chunkstrides. This was the cause for when analyzing certain datasets would produce completely wrong values on the edges.