Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: decimal conversion looses value on lower precision #6836

Merged
merged 3 commits into from
Dec 12, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 38 additions & 18 deletions arrow-cast/src/cast/decimal.rs
Original file line number Diff line number Diff line change
Expand Up @@ -112,8 +112,19 @@ where
};

Ok(match cast_options.safe {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems strange to match on a boolean rather than just using an if statement. I know this is how the existing code was, but perhaps we could improve this while we are here.

true => array.unary_opt(f),
false => array.try_unary(|x| f(x).ok_or_else(|| error(x)))?,
true => {
array.unary_opt(|x| {
f(x).filter(|v| O::is_valid_decimal_precision(*v, output_precision))
})
}
false => {
array.try_unary(|x| {
f(x).ok_or_else(|| error(x))
.and_then(|v|{
O:: validate_decimal_precision(v, output_precision).map(|_| v)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not do this when computing the value (the code above), and only when this can fail?
(for example widening precision cannot fail, so no need to spend cycles on validating the produced values)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about it, but then there are other examples where is it done this way, so kept it there. We can also do this as part of first error check point - inside this method

let error = cast_decimal_to_decimal_error::<I, O>(output_precision, output_scale);

})
})?
}
})
}

Expand All @@ -135,11 +146,23 @@ where
.unwrap()
.pow_checked((output_scale - input_scale) as u32)?;

let f = |x| O::Native::from_decimal(x).and_then(|x| x.mul_checked(mul).ok());
let f = |x|
O::Native::from_decimal(x).and_then(|x| x.mul_checked(mul).ok());

Ok(match cast_options.safe {
true => array.unary_opt(f),
false => array.try_unary(|x| f(x).ok_or_else(|| error(x)))?,
true => {
array.unary_opt(|x| {
f(x).filter(|v| O::is_valid_decimal_precision(*v, output_precision))
})
}
false => {
array.try_unary(|x| {
f(x).ok_or_else(|| error(x))
.and_then(|v|{
O:: validate_decimal_precision(v, output_precision).map(|_| v)
})
})?
}
})
}

Expand All @@ -156,19 +179,9 @@ where
T::Native: DecimalCast + ArrowNativeTypeOp,
{
let array: PrimitiveArray<T> = match input_scale.cmp(&output_scale) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be changed to <=

Ordering::Equal => {
// the scale doesn't change, the native value don't need to be changed
array.clone()
}
Ordering::Greater => convert_to_smaller_scale_decimal::<T, T>(
array,
input_scale,
output_precision,
output_scale,
cast_options,
)?,
Ordering::Less => {
// input_scale < output_scale
Ordering::Equal | Ordering::Less => {
// input_scale <= output_scale
// the scale doesn't change, but precision may change and cause overflow
Copy link
Member

@viirya viirya Dec 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't we also check precision and skip convert_to_bigger_or_equal_scale_decimal if it won't overflow?

Copy link
Contributor Author

@himadripal himadripal Dec 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

won't it still has to go through the convert_to_bigger_or_equal_scale_decimal to add the zero at the end for bigger precision conversion. IMO, we can only skip the call if precision is less and scales are equal. Please correct me here.
we can do check at the beginning like this

if (array.validate_decimal_precision().is_err()) 

but we need to return null for safe=true and throw error for safe=false
is that what you are suggesting?

Copy link
Member

@viirya viirya Dec 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, original code simply returns the original array for same scale. If the new precision is bigger, I think we can still do that, no?

Copy link
Contributor Author

@himadripal himadripal Dec 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets assume, we are converting 12.345 from (5, 3) to (6,3), then it needs to be 123450 - if we do array.clone() as per original code- wondering how it will add the 0 at the end.. Then it should still be 12.345

Copy link
Contributor Author

@himadripal himadripal Dec 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is correct, then we can return original array if precision is bigger and scale is equal.

select arrow_typeof(cast(cast(1.23 as decimal(10,3)) as decimal(12,3))),
       cast(cast(1.23 as decimal(10,3)) as decimal(12,3));
----
Decimal128(12, 3) 1.23

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

12345 in (5, 3) is 12.345. When casting to (6, 3), it is still 12345, why it needs to be 123450? 123450 in (6, 3) is 123.45. If I understand it correctly.

Copy link
Contributor Author

@himadripal himadripal Dec 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are right. fn signature only has output_precision, I can get the input_precision from the calling fn, it's available there and change the signature to include input_precision. would that be fine?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. @viirya please check.

convert_to_bigger_or_equal_scale_decimal::<T, T>(
array,
input_scale,
Expand All @@ -177,6 +190,13 @@ where
cast_options,
)?
}
Ordering::Greater => convert_to_smaller_scale_decimal::<T, T>(
array,
input_scale,
output_precision,
output_scale,
cast_options,
)?
};

Ok(Arc::new(array.with_precision_and_scale(
Expand Down
68 changes: 68 additions & 0 deletions arrow-cast/src/cast/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -9827,4 +9827,72 @@ mod tests {
"Cast non-nullable to non-nullable struct field returning null should fail",
);
}

#[test]
fn test_decimal_to_decimal_throw_error_on_precision_overflow_same_scale(){
let array = vec![Some(123456789)];
let array = create_decimal_array(array, 24, 2).unwrap();
println!("{:?}", array);
let input_type = DataType::Decimal128(24, 2);
let output_type = DataType::Decimal128(6, 2);
assert!(can_cast_types(&input_type, &output_type));
let mut options = CastOptions::default();
options.safe = false;

let result = cast_with_options(&array, &output_type, &options);

assert_eq!(result.unwrap_err().to_string(),
"InvalidArgumentError(123456789 is too large to store in a Decimal128 of precision 6. Max is 999999)");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error message format needs updating:

  left: "Invalid argument error: 123456789 is too large to store in a Decimal256 of precision 6. Max is 999999"
 right: "InvalidArgumentError(123456789 is too large to store in a Decimal256 of precision 6. Max is 999999)"

}

#[test]
fn test_decimal_to_decimal_throw_error_on_precision_overflow_lower_scale(){
let array = vec![Some(123456789)];
let array = create_decimal_array(array, 24, 2).unwrap();
println!("{:?}", array);
let input_type = DataType::Decimal128(24, 4);
let output_type = DataType::Decimal128(6, 2);
assert!(can_cast_types(&input_type, &output_type));
let mut options = CastOptions::default();
options.safe = false;

let result = cast_with_options(&array, &output_type, &options);

assert_eq!(result.unwrap_err().to_string(),
"InvalidArgumentError(123456789 is too large to store in a Decimal128 of precision 6. Max is 999999)");
}

#[test]
fn test_decimal_to_decimal_throw_error_on_precision_overflow_greater_scale(){
let array = vec![Some(123456789)];
let array = create_decimal_array(array, 24, 2).unwrap();
println!("{:?}", array);
let input_type = DataType::Decimal128(24, 2);
let output_type = DataType::Decimal128(6, 3);
assert!(can_cast_types(&input_type, &output_type));
let mut options = CastOptions::default();
options.safe = false;

let result = cast_with_options(&array, &output_type, &options);

assert_eq!(result.unwrap_err().to_string(),
"InvalidArgumentError(123456789 is too large to store in a Decimal128 of precision 6. Max is 999999)");
}

#[test]
fn test_decimal_to_decimal_throw_error_on_precision_overflow_diff_type(){
let array = vec![Some(123456789)];
let array = create_decimal_array(array, 24, 2).unwrap();
println!("{:?}", array);
let input_type = DataType::Decimal128(24, 2);
let output_type = DataType::Decimal256(6, 2);
assert!(can_cast_types(&input_type, &output_type));
let mut options = CastOptions::default();
options.safe = false;

let result = cast_with_options(&array, &output_type, &options);

assert_eq!(result.unwrap_err().to_string(),
"InvalidArgumentError(123456789 is too large to store in a Decimal256 of precision 6. Max is 999999)");
}
}
Loading