Fix bug when provided arrays having different orders

Author: kgryte

lib/node_modules/@stdlib/ndarray/base/unary/src/dispatch.c

@@ -335,7 +335,7 @@ int8_t stdlib_ndarray_unary_dispatch( const struct ndarrayUnaryDispatchObject *o
 	io2 = stdlib_ndarray_iteration_order( ndims, s2 ); // +/-1
 
 	// Determine whether we can avoid blocked iteration...
-	if ( io1 != 0 && io2 != 0 ) {
+	if ( io1 != 0 && io2 != 0 && stdlib_ndarray_order( x1 ) == stdlib_ndarray_order( x2 )) {
 		// Determine the minimum and maximum linear byte indices which are accessible by the array views:
 		mib1 = stdlib_ndarray_offset( x1 ); // byte offset
 		mab1 = mib1;
@@ -370,14 +370,14 @@ int8_t stdlib_ndarray_unary_dispatch( const struct ndarrayUnaryDispatchObject *o
 		// At least one ndarray is non-contiguous, so we cannot directly use strided array functionality...
 
 		// Determine whether we can use simple nested loops...
-		if ( stdlib_ndarray_order( x1 ) == stdlib_ndarray_order( x2 ) && ndims < (obj->nfunctions) ) {
+		if ( ndims < (obj->nfunctions) ) {
 			// So long as iteration for each respective array always moves in the same direction (i.e., no mixed sign strides), we can leverage cache-optimal (i.e., normal) nested loops without resorting to blocked iteration...
 			obj->functions[ ndims ]( arrays, fcn );
 			return 0;
 		}
 		// Fall-through to blocked iteration...
 	}
-	// At this point, we're either dealing with non-contiguous n-dimensional arrays and/or high dimensional n-dimensional arrays, so our only hope is that we can still perform blocked iteration...
+	// At this point, we're either dealing with non-contiguous n-dimensional arrays, high dimensional n-dimensional arrays, and/or arrays having differing memory layouts, so our only hope is that we can still perform blocked iteration...
 
 	// Determine whether we can perform blocked iteration...
 	if ( ndims <= (obj->nblockedfunctions)+1 ) {