nareshmlx/opencv-pr huggingface dataset:
**File:** modules/gapi/src/backends/onnx/gonnxbackend.cpp
**Change Type:** modified
**Context:** PR #25817: handling I32/I64 data types in G-API ONNX back-end

**Code Changes:**
```diff
@@ -123,7 +123,7 @@ class ONNXCompiled {
     std::vector<cv::Mat> out_data;
 
     void Run(const std::vector<cv::Mat>& ins,
-             const std::vector<cv::Mat>& outs);
+             std::vector<cv::Mat>& outs);
 
     std::vector<std::string> in_names_without_const;
 public:
@@ -322,22 +322,20 @@ inline std::vector<int64_t> toORT(const cv::MatSize &sz) {
```

Review comment:
fixed alignment
**File:** modules/imgproc/include/opencv2/imgproc.hpp
**Change Type:** modified
**Context:** PR #25252: Move API focused C++ samples to snippets - Clean Samples #25006 This PR removes 39 outdated C++ samples from the project, as part of an eff...
**Review Line:** 2841

**Code Changes:**
```diff
 An example using the cv::linearPolar and cv::logPolar operations
 */
 
@@ -2840,7 +2840,7 @@ the destination image will have the given size therefore the area of the boundin
 You can get reverse mapping adding #WARP_INVERSE_MAP to `flags`
 \snippet polar_transforms.cpp InverseMap
 
-In addiction, to calculate the original coordinate from a polar mapped coordinate \f$(rho, phi)->(x, y)\f$:
+In addition, to calculate the original coordinate from a polar mapped coordinate \f$(rho, phi)->(x, y)\f$:
 \snippet polar_transforms.cpp InverseCoordinate
 
```

Review comment:
These snippets illustrated statement before them, without snippets meaning is lost. These two paragraphs must be rewritten, maybe similar snippets could be used from other sample.
**File:** modules/imgproc/include/opencv2/imgproc.hpp
**Change Type:** modified
**Context:** PR #25252: Move API focused C++ samples to snippets - Clean Samples #25006 This PR removes 39 outdated C++ samples from the project, as part of an eff...
**Review Line:** 2841

**Code Changes:**
```diff
 An example using the cv::linearPolar and cv::logPolar operations
 */
 
@@ -2840,7 +2840,7 @@ the destination image will have the given size therefore the area of the boundin
 You can get reverse mapping adding #WARP_INVERSE_MAP to `flags`
 \snippet polar_transforms.cpp InverseMap
 
-In addiction, to calculate the original coordinate from a polar mapped coordinate \f$(rho, phi)->(x, y)\f$:
+In addition, to calculate the original coordinate from a polar mapped coordinate \f$(rho, phi)->(x, y)\f$:
 \snippet polar_transforms.cpp InverseCoordinate
 
```

Review comment:
Completely wrong way. Samples are regularly compiled. That code in comments is not build at all. We don't want to provide broken code to users. Especially during heavy API refactoring.
**File:** samples/cpp/dft.cpp
**Change Type:** removed
**Context:** PR #25252: Move API focused C++ samples to snippets - Clean Samples #25006 This PR removes 39 outdated C++ samples from the project, as part of an eff...
**Review Line:** 1

**Code Changes:**
```diff
@@ -1,86 +0,0 @@
-#include "opencv2/core.hpp"
-#include "opencv2/core/utility.hpp"
-#include "opencv2/imgproc.hpp"
-#include "opencv2/imgcodecs.hpp"
-#include "opencv2/highgui.hpp"
-
-#include <stdio.h>
-
-using namespace cv;
-using namespace std;
-
-static void help(const char ** argv)
-{
-    printf("\nThis program demonstrated the use of the discrete Fourier transform (dft)\n"
```

Review comment:
`cv::dft()` has code snipped, but it's embedded into header. It means that it's not built by CI. I propose to move the file to snippets, but change it's content to `convolveDFT` from core.hpp header file.
**File:** modules/dnn/src/layers/elementwise_layers.cpp
**Change Type:** modified
**Context:** PR #25147: dnn: accelerate gelu via vectorized erf

**Code Changes:**
```diff
@@ -813,20 +813,82 @@ struct BaseDefaultFunctor : public BaseFunctor
     static const char* const ocl_kernel_name;
 };
 
-struct GeluFunctor : public BaseDefaultFunctor<GeluFunctor>
-{
-    typedef GeluLayer Layer;
+namespace {
+    // Refer to v_erf in modules/core/include/opencv2/core/hal/intrin_math.hpp
+    constexpr float c_erf_coef0 = 0.3275911f;
```

Review comment:
please, use fabsf, fmaf, expf, otherwise compiler will use double precision for intermediate values
**File:** modules/dnn/src/layers/elementwise_layers.cpp
**Change Type:** modified
**Context:** PR #25147: dnn: accelerate gelu via vectorized erf

**Code Changes:**
```diff
@@ -813,20 +813,82 @@ struct BaseDefaultFunctor : public BaseFunctor
     static const char* const ocl_kernel_name;
 };
 
-struct GeluFunctor : public BaseDefaultFunctor<GeluFunctor>
-{
-    typedef GeluLayer Layer;
+namespace {
+    // Refer to v_erf in modules/core/include/opencv2/core/hal/intrin_math.hpp
+    constexpr float c_erf_coef0 = 0.3275911f;
```

Review comment:
I suggest not to use pytorch_math namespace, because it may look confusing. It's enough to put the link to PyTorch code and use v_erf without any namespace (just use cv, cv::hal or cv::dnn)
**File:** modules/dnn/src/layers/elementwise_layers.cpp
**Change Type:** modified
**Context:** PR #25147: dnn: accelerate gelu via vectorized erf

**Code Changes:**
```diff
@@ -813,20 +813,82 @@ struct BaseDefaultFunctor : public BaseFunctor
     static const char* const ocl_kernel_name;
 };
 
-struct GeluFunctor : public BaseDefaultFunctor<GeluFunctor>
-{
-    typedef GeluLayer Layer;
+namespace {
+    // Refer to v_erf in modules/core/include/opencv2/core/hal/intrin_math.hpp
+    constexpr float c_erf_coef0 = 0.3275911f;
```

Review comment:
please, put a short description that we took this algorithm in Wikipedia and it's also implemented in PyTorch, provide the link.
**File:** modules/dnn/src/layers/elementwise_layers.cpp
**Change Type:** modified
**Context:** PR #25147: dnn: accelerate gelu via vectorized erf

**Code Changes:**
```diff
@@ -813,20 +813,82 @@ struct BaseDefaultFunctor : public BaseFunctor
     static const char* const ocl_kernel_name;
 };
 
-struct GeluFunctor : public BaseDefaultFunctor<GeluFunctor>
-{
-    typedef GeluLayer Layer;
+namespace {
+    // Refer to v_erf in modules/core/include/opencv2/core/hal/intrin_math.hpp
+    constexpr float c_erf_coef0 = 0.3275911f;
```

Review comment:
it's quite heavy function inside. 1) does it make sense to unroll the loop by vlanes*4? 2) with such aggressive unrolling there is a risk that we will have very long tail which will slow down performance significantly. I suggest to make unrolling less aggressive. 2) it's element-wise operation. Often in NCHW the product of H and W may be quite odd number far from power-of-two. You should process `(cn1-cn0)*planeSize` as a single 1D array, so that you will have just one tail, not many tiles
**File:** modules/dnn/src/layers/elementwise_layers.cpp
**Change Type:** modified
**Context:** PR #25147: dnn: accelerate gelu via vectorized erf

**Code Changes:**
```diff
@@ -813,20 +813,82 @@ struct BaseDefaultFunctor : public BaseFunctor
     static const char* const ocl_kernel_name;
 };
 
-struct GeluFunctor : public BaseDefaultFunctor<GeluFunctor>
-{
-    typedef GeluLayer Layer;
+namespace {
+    // Refer to v_erf in modules/core/include/opencv2/core/hal/intrin_math.hpp
+    constexpr float c_erf_coef0 = 0.3275911f;
```

Review comment:
Ok, anonymous namespace is used. In this case, `erf` needs to be changed to `erf_approx` to avoid redef of the one from std library.
**File:** modules/dnn/src/layers/elementwise_layers.cpp
**Change Type:** modified
**Context:** PR #25147: dnn: accelerate gelu via vectorized erf

**Code Changes:**
```diff
@@ -813,20 +813,82 @@ struct BaseDefaultFunctor : public BaseFunctor
     static const char* const ocl_kernel_name;
 };
 
-struct GeluFunctor : public BaseDefaultFunctor<GeluFunctor>
-{
-    typedef GeluLayer Layer;
+namespace {
+    // Refer to v_erf in modules/core/include/opencv2/core/hal/intrin_math.hpp
+    constexpr float c_erf_coef0 = 0.3275911f;
```

Review comment:
This is from PyTorch. A link to the source has been provided next line to the namespace.
**File:** modules/dnn/src/layers/elementwise_layers.cpp
**Change Type:** modified
**Context:** PR #25147: dnn: accelerate gelu via vectorized erf

**Code Changes:**
```diff
@@ -813,20 +813,82 @@ struct BaseDefaultFunctor : public BaseFunctor
     static const char* const ocl_kernel_name;
 };
 
-struct GeluFunctor : public BaseDefaultFunctor<GeluFunctor>
-{
-    typedef GeluLayer Layer;
+namespace {
+    // Refer to v_erf in modules/core/include/opencv2/core/hal/intrin_math.hpp
+    constexpr float c_erf_coef0 = 0.3275911f;
```

Review comment:
I tested with unrolling by 2 but did not observe significant difference. --- > You should process (cn1-cn0)*planeSize as a single 1D array, so that you will have just one tail, not many tiles It is not completely correct. The loops and parallel look like the following: ``` for b in batch: for c in channel: for i in h * w: (this most inner loop is parallelled by the number of threads) // ... ``` So for each thread the workload should be `b * c * stripeSize` (planeSize is the step to the next segment), which is `(cn1 - cn0) * len` using terms in the code. This parallelism is used across all activations in the file.
**File:** modules/dnn/perf/perf_layer.cpp
**Change Type:** modified
**Context:** PR #25147: dnn: accelerate gelu via vectorized erf
**Review Line:** 1020

**Code Changes:**
```diff
+                          /* withCpuOCV= */          true,
+                          /* withVkCom= */           false,
+                          /* withCUDA= */            true,
+                          /* withNgraph= */          true,
+                          /* withWebnn= */           false,
+                          /* withCann= */            false) // only test on CPU
+));
+
 } // namespace
```

Review comment:
M.b. we need to enable ngraph and opencl?
**File:** cmake/OpenCVFindLibsGUI.cmake
**Change Type:** modified
**Context:** PR #22836: Explicitly prefer legacy GL in cmake on Linux?

**Code Changes:**
```diff
@@ -60,6 +60,7 @@ if(WITH_QT)
 endif()
 
 # --- OpenGl ---
+ocv_update(OpenGL_GL_PREFERENCE LEGACY)
 ocv_clear_vars(HAVE_OPENGL HAVE_QT_OPENGL)
 if(WITH_OPENGL)
   if(WITH_WIN32UI OR (HAVE_QT AND QT_QTOPENGL_FOUND) OR HAVE_GTKGLEXT)
```

Review comment:
`ocv_update` is preferable to allow external control.
**File:** modules/dnn/src/registry.cpp
**Change Type:** modified
**Context:** PR #25880: 🐛 Fix CUDA for old GPUs without FP16 support

**Code Changes:**
```diff
@@ -18,6 +18,10 @@
 #include "backend.hpp"
 #include "factory.hpp"
 
+#ifdef HAVE_CUDA
+#include "cuda4dnn/init.hpp"
+#endif
+
 namespace cv {
 namespace dnn {
```

Review comment:
It works well with single gpu configuration. The current GPU may be old and does not support FP16, but the second one does. It's popular case, if one GPU is used for rendering another one - for compute.
**File:** modules/dnn/src/registry.cpp
**Change Type:** modified
**Context:** PR #25880: 🐛 Fix CUDA for old GPUs without FP16 support

**Code Changes:**
```diff
@@ -18,6 +18,10 @@
 #include "backend.hpp"
 #include "factory.hpp"
 
+#ifdef HAVE_CUDA
+#include "cuda4dnn/init.hpp"
+#endif
+
 namespace cv {
 namespace dnn {
```

Review comment:
It is fine to check the **CURRENT** CUDA device. Lets left the caller responsibility to properly select used device via `cudaSetDevice` before these calls. BTW, OpenCL backend has similar problems but looks like they are handled in another place.
**File:** modules/dnn/src/registry.cpp
**Change Type:** modified
**Context:** PR #25880: 🐛 Fix CUDA for old GPUs without FP16 support
**Review Line:** 136

**Code Changes:**
```diff
+            if (cuda4dnn::isDeviceCompatible(i))
+            {
+                hasCudaCompatible = true;
+                if (cuda4dnn::doesDeviceSupportFP16(i))
+                {
+                    hasCudaFP16 = true;
+                    break; // we already have all we need here
+                }
+            }
+        }
+
```

Review comment:
There's no need to continue checking GPUs once we found one that supports FP16. ```suggestion { hasCudaFP16 = true; break; // we already have all we need here } ```
**File:** modules/dnn/src/cuda4dnn/init.hpp
**Change Type:** modified
**Context:** PR #25880: 🐛 Fix CUDA for old GPUs without FP16 support
**Review Line:** 94

**Code Changes:**
```diff
 
         int version = major * 10 + minor;
-        if (version < 53)
-            return false;
-        return true;
+        return (version >= 53);
     }
 
 }}} /* namespace cv::dnn::cuda4dnn */
```

Review comment:
Taking into account that the `version` is an integer variable, I think it would be a bit cleaner if we use `> 52` for this check. ```suggestion return (version > 52); ```
**File:** modules/dnn/src/cuda4dnn/init.hpp
**Change Type:** modified
**Context:** PR #25880: 🐛 Fix CUDA for old GPUs without FP16 support
**Review Line:** 94

**Code Changes:**
```diff
 
         int version = major * 10 + minor;
-        if (version < 53)
-            return false;
-        return true;
+        return (version >= 53);
     }
 
 }}} /* namespace cv::dnn::cuda4dnn */
```

Review comment:
I prefer to stay with 53. It's well known constant in CUDA world. Also it's easier to "grep".
**File:** modules/imgproc/test/test_color.cpp
**Change Type:** modified
**Context:** PR #25842: imgproc: remove C-API usage from tests - Final cleanup will be done in 5.x after regular merge. Some tests have been reworked, some require...
**Review Line:** 1733

**Code Changes:**
```diff
@@ -76,7 +76,6 @@ class CV_ColorCvtBaseTest : public cvtest::ArrayTest
     bool inplace;
     bool custom_inv_transform;
     int fwd_code, inv_code;
-    bool test_cpp;
     int hue_range;
     bool srgb;
 };
@@ -97,7 +96,6 @@ CV_ColorCvtBaseTest::CV_ColorCvtBaseTest( bool _custom_inv_transform, bool _allo
 
     fwd_code_str = inv_code_str = 0;
 
-    test_cpp = false;
     hue_range = 0;
     blue_idx = 0;
```

Review comment:
The flag may be removed then.
**File:** modules/imgproc/test/test_imgwarp.cpp
**Change Type:** modified
**Context:** PR #25842: imgproc: remove C-API usage from tests - Final cleanup will be done in 5.x after regular merge. Some tests have been reworked, some require...
**Review Line:** 928

**Code Changes:**
```diff
     bool test_cpp;
 };
 
@@ -925,13 +927,8 @@ void CV_GetRectSubPixTest::fill_array( int test_case_idx, int i, int j, Mat& arr
 
 void CV_GetRectSubPixTest::run_func()
 {
-    if(!test_cpp)
-        cvGetRectSubPix( test_array[INPUT][0], test_array[INPUT_OUTPUT][0], center );
-    else
-    {
```

Review comment:
`test_cpp` could be removed then
**File:** modules/imgproc/test/test_convhull.cpp
**Change Type:** modified
**Context:** PR #25842: imgproc: remove C-API usage from tests - Final cleanup will be done in 5.x after regular merge. Some tests have been reworked, some require...

**Code Changes:**
```diff
@@ -39,2026 +39,93 @@
 //
 //M*/
 
+#include "opencv2/core/hal/interface.h"
+#include "opencv2/ts.hpp"
+#include "opencv2/ts/cuda_test.hpp"
 #include "test_precomp.hpp"
 
 namespace opencv_test { namespace {
```

Review comment:
The branches are the same besides convertTo/copyTo. Let's extract common part.
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25796: Use `hfloat` instead of `__fp16`.
**Review Line:** 823

**Code Changes:**
```diff
 {
 public:
 #if CV_FP16_TYPE
-
-    hfloat() : h(0) {}
+    hfloat() = default;
     explicit hfloat(float x) { h = (__fp16)x; }
     operator float() const { return (float)h; }
+#if defined __ARM_FP16_FORMAT_IEEE
 protected:
     __fp16 h;
```

Review comment:
This doesn't guarantee zero value.
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25796: Use `hfloat` instead of `__fp16`.
**Review Line:** 387

**Code Changes:**
```diff
@@ -384,8 +384,10 @@ typedef union Cv16suf
 {
     short i;
     ushort u;
-#if CV_FP16_TYPE
+#if CV_FP16_TYPE && defined __ARM_FP16_FORMAT_IEEE
     __fp16 h;
+#elif CV_FP16_TYPE // Other platforms suggested to use _Float16
+    _Float16 h;
 #endif
 }
```

Review comment:
We should not limit that to ARM only
**File:** modules/core/include/opencv2/core/hal/intrin.hpp
**Change Type:** modified
**Context:** PR #25796: Use `hfloat` instead of `__fp16`.
**Review Line:** 169

**Code Changes:**
```diff
@@ -166,7 +166,7 @@ CV_INTRIN_DEF_TYPE_TRAITS(schar, schar, uchar, uchar, short, int, int);
 CV_INTRIN_DEF_TYPE_TRAITS(ushort, short, ushort, ushort, unsigned, uint64, unsigned);
 CV_INTRIN_DEF_TYPE_TRAITS(short, short, ushort, ushort, int, int64, int);
 #if CV_FP16_TYPE
-CV_INTRIN_DEF_TYPE_TRAITS(__fp16, short, ushort, __fp16, float, double, float);
+CV_INTRIN_DEF_TYPE_TRAITS(hfloat, short, ushort, hfloat, float, double, float);
 #endif
 CV_INTRIN_DEF_TYPE_TRAITS_NO_Q_TYPE(unsigned, int, unsigned, unsigned, uint64, unsigned);
 CV_INTRIN_DEF_TYPE_TRAITS_NO_Q_TYPE(int, int, unsigned, unsigned, int64, int);
@@ -370,7 +370,7 @@ template<typename _Tp> struct V_RegTraits
     CV_DEF_REG_TRAITS(v, v_uint16x8, ushort, u16, v_uint16x8, v_uint32x4, v_uint64x2, v_int16x8, void);
```

Review comment:
SIMD intrinsics are low level and they should not use `hfloat`-like shim types. OpenCV intrinsics should provide own type via `typedef` depending on backend (with helper functions). We are not expecting that intrinsics work with "ushort" (we already had that mess in DNN module).
**File:** modules/core/include/opencv2/core/hal/intrin.hpp
**Change Type:** modified
**Context:** PR #25796: Use `hfloat` instead of `__fp16`.
**Review Line:** 169

**Code Changes:**
```diff
@@ -166,7 +166,7 @@ CV_INTRIN_DEF_TYPE_TRAITS(schar, schar, uchar, uchar, short, int, int);
 CV_INTRIN_DEF_TYPE_TRAITS(ushort, short, ushort, ushort, unsigned, uint64, unsigned);
 CV_INTRIN_DEF_TYPE_TRAITS(short, short, ushort, ushort, int, int64, int);
 #if CV_FP16_TYPE
-CV_INTRIN_DEF_TYPE_TRAITS(__fp16, short, ushort, __fp16, float, double, float);
+CV_INTRIN_DEF_TYPE_TRAITS(hfloat, short, ushort, hfloat, float, double, float);
 #endif
 CV_INTRIN_DEF_TYPE_TRAITS_NO_Q_TYPE(unsigned, int, unsigned, unsigned, uint64, unsigned);
 CV_INTRIN_DEF_TYPE_TRAITS_NO_Q_TYPE(int, int, unsigned, unsigned, int64, int);
@@ -370,7 +370,7 @@ template<typename _Tp> struct V_RegTraits
     CV_DEF_REG_TRAITS(v, v_uint16x8, ushort, u16, v_uint16x8, v_uint32x4, v_uint64x2, v_int16x8, void);
```

Review comment:
Discussed offline. It seems fine to use `hfloat` as **external** interface for scalar/pointer FP16 types of universal SIMD intrinsics.
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25796: Use `hfloat` instead of `__fp16`.
**Review Line:** 387

**Code Changes:**
```diff
@@ -384,8 +384,10 @@ typedef union Cv16suf
 {
     short i;
     ushort u;
-#if CV_FP16_TYPE
+#if CV_FP16_TYPE && defined __ARM_FP16_FORMAT_IEEE
     __fp16 h;
+#elif CV_FP16_TYPE // Other platforms suggested to use _Float16
+    _Float16 h;
 #endif
 }
```

Review comment:
Looks like `__fp16` works well with ARM only. Other platforms suggested to use `_Float16`: - https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html - https://releases.llvm.org/16.0.0/tools/clang/docs/LanguageExtensions.html - https://en.cppreference.com/w/cpp/types/floating-point
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25796: Use `hfloat` instead of `__fp16`.
**Review Line:** 823

**Code Changes:**
```diff
 {
 public:
 #if CV_FP16_TYPE
-
-    hfloat() : h(0) {}
+    hfloat() = default;
     explicit hfloat(float x) { h = (__fp16)x; }
     operator float() const { return (float)h; }
+#if defined __ARM_FP16_FORMAT_IEEE
 protected:
     __fp16 h;
```

Review comment:
Yes, I didn't want to change this code, but `hfloat() : h(0) {}` will cause an error at compile time: ```bash opencv/modules/core/include/opencv2/core/hal/intrin.hpp:169:1 error: call to implicitly-deleted default constructor of 'union CV_INTRIN_DEF_TYPE_TRAITS(hfloat, short, ushort, hfloat, float, double, float); ^ opencv/modules/core/include/opencv2/core/hal/intrin.hpp:126:43: note: expanded from macro 'CV_INTRIN_DEF_TYPE_TRAITS' union { type l; int_type i; } v; \ ^ note: default constructor of '' is implicitly deleted because variant field 'l' has a non-trivial default constructor ``` Any suggestions?
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25796: Use `hfloat` instead of `__fp16`.
**Review Line:** 387

**Code Changes:**
```diff
@@ -384,8 +384,10 @@ typedef union Cv16suf
 {
     short i;
     ushort u;
-#if CV_FP16_TYPE
+#if CV_FP16_TYPE && defined __ARM_FP16_FORMAT_IEEE
     __fp16 h;
+#elif CV_FP16_TYPE // Other platforms suggested to use _Float16
+    _Float16 h;
 #endif
 }
```

Review comment:
Agree, should we add `_Float16` part in `#else` block via this PR, or via the RISC-V PR https://github.com/opencv/opencv/pull/25743 after this PR has been merged?
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25796: Use `hfloat` instead of `__fp16`.
**Review Line:** 387

**Code Changes:**
```diff
@@ -384,8 +384,10 @@ typedef union Cv16suf
 {
     short i;
     ushort u;
-#if CV_FP16_TYPE
+#if CV_FP16_TYPE && defined __ARM_FP16_FORMAT_IEEE
     __fp16 h;
+#elif CV_FP16_TYPE // Other platforms suggested to use _Float16
+    _Float16 h;
 #endif
 }
```

Review comment:
Let's try to add it for x86_64 platforms in this PR and extend to RISC-V later in #25743. If we make it in a separate commit, then it would be easy to cherry-pick or revert it if something goes wrong.
**File:** modules/core/include/opencv2/core/cvdef.h
**Change Type:** modified
**Context:** PR #25796: Use `hfloat` instead of `__fp16`.
**Review Line:** 390

**Code Changes:**
```diff
     ushort u;
-#if CV_FP16_TYPE
+#if CV_FP16_TYPE && defined __ARM_FP16_FORMAT_IEEE
     __fp16 h;
+#elif CV_FP16_TYPE // Other platforms suggested to use _Float16
+    _Float16 h;
 #endif
 }
 Cv16suf;
@@ -818,12 +820,16 @@ class hfloat
 {
```

Review comment:
If I understand correctly, currently there is no x86_64 platform satisfying this case because `CV_FP16_TYPE` is enabled only for `__ARM_FP16_FORMAT_IEEE`. And in order to test this branch we need to also add support for `-mavx512fp16` and maybe some other option for RISC-V. Am I correct?
**File:** modules/core/include/opencv2/core/hal/intrin_cpp.hpp
**Change Type:** modified
**Context:** PR #25872: core: add v_erf
**Review Line:** 267

**Code Changes:**
```diff
 
 ### Other math
 
-- Some frequent operations: @ref v_sqrt, @ref v_invsqrt, @ref v_magnitude, @ref v_sqr_magnitude, @ref v_exp
+- Some frequent operations: @ref v_sqrt, @ref v_invsqrt, @ref v_magnitude, @ref v_sqr_magnitude, @ref v_exp,
+                            @ref v_erf
 - Absolute values: @ref v_abs, @ref v_absdiff, @ref v_absdiffs
 
 ### Conversions
@@ -761,6 +762,13 @@ OPENCV_HAL_IMPL_MATH_FUNC(v_exp, std::exp, _Tp)
 OPENCV_HAL_IMPL_MATH_FUNC(v_log, std::log, _Tp)
```

Review comment:
/build/precommit_docs/4.x/opencv/modules/core/include/opencv2/core/hal/intrin_cpp.hpp:269: warning: unable to resolve reference to 'v_erf' for \ref command
**File:** modules/python/src2/gen2.py
**Change Type:** modified
**Context:** PR #25810: python: attempts to fix 3d mat parsing problem for dnn

**Code Changes:**
```diff
@@ -488,6 +488,10 @@ def export_name(self):
             return self.name + '_'
         return self.name
 
+    @property
+    def nd_mat(self):
+        return '/ND' in self._modifiers
+
     @property
     def inputarg(self):
```

Review comment:
use `misc/python` instead.