Indexing: Use Param/Array::strides instead of toStrides
Indexing: Use Param/Array::strides instead of toStride
umar456 previously approved these changes Oct 11, 2018
facebook-github-bot pushed a commit to flashlight/flashlight that referenced this pull request
Apr 17, 2019
Summary: When testing CUDA ForceAlign, I encountered NaNs that seemed unrelated to ForceAlign. After investigation I discovered the NaNs were introduced during GLU. During one particular forward pass, in one particular GLU layer, the array `input.array()(fhalf[0], fhalf[1], fhalf[2], fhalf[3])` had NaNs, whereas `input.array()` did not have any NaNs. This seems to be due to an ArrayFire 3.6.1 bug: - issue: arrayfire/arrayfire#2273 - PR: arrayfire/arrayfire#2311 This diff applies the `af::moddims` workaround I mentioned in the issue. It does appear to be resolved in ArrayFire 3.6.2. But we can use this workaround until we update ArrayFire in TP2 to 3.6.2. Reviewed By: vineelpratap Differential Revision: D14961937 fbshipit-source-id: dcd455b82e7ce6888a2d35cba868718a55789f04
jacobkahn pushed a commit to flashlight/text that referenced this pull request
Mar 25, 2022
Summary: When testing CUDA ForceAlign, I encountered NaNs that seemed unrelated to ForceAlign. After investigation I discovered the NaNs were introduced during GLU. During one particular forward pass, in one particular GLU layer, the array `input.array()(fhalf[0], fhalf[1], fhalf[2], fhalf[3])` had NaNs, whereas `input.array()` did not have any NaNs. This seems to be due to an ArrayFire 3.6.1 bug: - issue: arrayfire/arrayfire#2273 - PR: arrayfire/arrayfire#2311 This diff applies the `af::moddims` workaround I mentioned in the issue. It does appear to be resolved in ArrayFire 3.6.2. But we can use this workaround until we update ArrayFire in TP2 to 3.6.2. Reviewed By: vineelpratap Differential Revision: D14961937 fbshipit-source-id: dcd455b82e7ce6888a2d35cba868718a55789f04
jacobkahn pushed a commit to flashlight/text that referenced this pull request
Mar 25, 2022
Summary: When testing CUDA ForceAlign, I encountered NaNs that seemed unrelated to ForceAlign. After investigation I discovered the NaNs were introduced during GLU. During one particular forward pass, in one particular GLU layer, the array `input.array()(fhalf[0], fhalf[1], fhalf[2], fhalf[3])` had NaNs, whereas `input.array()` did not have any NaNs. This seems to be due to an ArrayFire 3.6.1 bug: - issue: arrayfire/arrayfire#2273 - PR: arrayfire/arrayfire#2311 This diff applies the `af::moddims` workaround I mentioned in the issue. It does appear to be resolved in ArrayFire 3.6.2. But we can use this workaround until we update ArrayFire in TP2 to 3.6.2. Reviewed By: vineelpratap Differential Revision: D14961937 fbshipit-source-id: dcd455b82e7ce6888a2d35cba868718a55789f04
jacobkahn pushed a commit to flashlight/text that referenced this pull request
Mar 25, 2022
Summary: When testing CUDA ForceAlign, I encountered NaNs that seemed unrelated to ForceAlign. After investigation I discovered the NaNs were introduced during GLU. During one particular forward pass, in one particular GLU layer, the array `input.array()(fhalf[0], fhalf[1], fhalf[2], fhalf[3])` had NaNs, whereas `input.array()` did not have any NaNs. This seems to be due to an ArrayFire 3.6.1 bug: - issue: arrayfire/arrayfire#2273 - PR: arrayfire/arrayfire#2311 This diff applies the `af::moddims` workaround I mentioned in the issue. It does appear to be resolved in ArrayFire 3.6.2. But we can use this workaround until we update ArrayFire in TP2 to 3.6.2. Reviewed By: vineelpratap Differential Revision: D14961937 fbshipit-source-id: dcd455b82e7ce6888a2d35cba868718a55789f04
jacobkahn pushed a commit to flashlight/sequence that referenced this pull request
Oct 13, 2022
Summary: When testing CUDA ForceAlign, I encountered NaNs that seemed unrelated to ForceAlign. After investigation I discovered the NaNs were introduced during GLU. During one particular forward pass, in one particular GLU layer, the array `input.array()(fhalf[0], fhalf[1], fhalf[2], fhalf[3])` had NaNs, whereas `input.array()` did not have any NaNs. This seems to be due to an ArrayFire 3.6.1 bug: - issue: arrayfire/arrayfire#2273 - PR: arrayfire/arrayfire#2311 This diff applies the `af::moddims` workaround I mentioned in the issue. It does appear to be resolved in ArrayFire 3.6.2. But we can use this workaround until we update ArrayFire in TP2 to 3.6.2. Reviewed By: vineelpratap Differential Revision: D14961937 fbshipit-source-id: dcd455b82e7ce6888a2d35cba868718a55789f04
jacobkahn pushed a commit to flashlight/sequence that referenced this pull request
Oct 13, 2022
Summary: When testing CUDA ForceAlign, I encountered NaNs that seemed unrelated to ForceAlign. After investigation I discovered the NaNs were introduced during GLU. During one particular forward pass, in one particular GLU layer, the array `input.array()(fhalf[0], fhalf[1], fhalf[2], fhalf[3])` had NaNs, whereas `input.array()` did not have any NaNs. This seems to be due to an ArrayFire 3.6.1 bug: - issue: arrayfire/arrayfire#2273 - PR: arrayfire/arrayfire#2311 This diff applies the `af::moddims` workaround I mentioned in the issue. It does appear to be resolved in ArrayFire 3.6.2. But we can use this workaround until we update ArrayFire in TP2 to 3.6.2. Reviewed By: vineelpratap Differential Revision: D14961937 fbshipit-source-id: dcd455b82e7ce6888a2d35cba868718a55789f04