Bug WikiLogic & Control Flow BugsLoss of precision
3 examples

Loss of precision

Numeric data precision lost during calculations, causing errors.

[ FAQ1 ]

What is loss of precision?

Loss of precision occurs when numeric operations or conversions lead to inaccuracies, often because floating-point or integer types cannot exactly represent certain numbers or decimals. For instance, storing or converting decimal values to floating-point representations can introduce small rounding errors, leading to unexpected or incorrect calculations. Similarly, converting large integers into smaller numeric types or between incompatible data types can truncate significant digits or alter numeric values. These inaccuracies can accumulate, significantly impacting calculations, financial operations, or precise computations.
[ FAQ2 ]

How to prevent loss of precision

To prevent loss of precision, choose numeric data types appropriate for the required precision and scale—such as decimal or BigInt types for financial and large integer calculations. Avoid unnecessary type conversions, and perform explicit rounding or truncation carefully to maintain accuracy. When working with floating-point arithmetic, consider using specialized numeric libraries designed for high-precision arithmetic. Regularly validate numeric operations, especially during conversions, and apply rigorous testing to detect potential precision-related issues early in development.
raycast/extensions·#17703
diff block
+/**
+ * Calculates reading time based on word count and reading speed
+ * @param wordCount Number of words in the text
+ * @param wpm Words per minute reading speed
+ * @returns Formatted string representing the reading time
+ */
+export function calculateReadingTime(wordCount: number, wpm: number): string {
+ if (wordCount < 0 || wpm <= 0 || !Number.isFinite(wordCount) || !Number.isFinite(wpm)) {
+ return "0 seconds";
+ }
+ if (wordCount === 0) return "0 seconds";
+
+ // Calculate reading time in seconds
+ const timeInSeconds = (wordCount / wpm) * 60;
Greptile
greptile
style: Potential loss of precision when dividing by wpm first - consider reordering to `(wordCount * 60) / wpm`
constellation-labs/tessellation·#1159
diff block
+package io.constellationnetwork.schema
+
+import cats.syntax.all._
+import cats.{Applicative, MonadThrow}
+
+import scala.math.BigDecimal.RoundingMode
+
+import io.constellationnetwork.schema.balance.Amount
+import io.constellationnetwork.schema.transaction.TransactionAmount
+import io.constellationnetwork.utils.DecimalUtils
+
+import eu.timepit.refined.types.numeric.{NonNegLong, PosLong}
+
+/** Extension methods for Amount to provide more functional operations.
+ */
+object AmountOps {
+
+ /** Extension methods for Amount.
+ */
+ implicit class AmountOps(val amount: Amount) {
+
+ /** Safely divides this amount by another amount.
+ *
+ * @param divisor
+ * The amount to divide by
+ * @param defaultValue
+ * The default value to return if divisor is zero
+ * @return
+ * The result of division, or defaultValue if divisor is zero
+ */
+ def safeDivideBy(divisor: Amount, defaultValue: BigDecimal = BigDecimal(0)): BigDecimal =
+ if (divisor.value.value == 0) defaultValue
+ else BigDecimal(amount.value.value) / BigDecimal(divisor.value.value)
Greptile
greptile
style: Potential loss of precision when converting Long to BigDecimal. Consider using BigDecimal.valueOf() for more precise conversion.
posthog/posthog·#28651
diff block
impl MixpanelEvent {
pub fn parse_fn(
context: TransformContext,
- ) -> impl Fn(Self) -> Result<InternallyCapturedEvent, Error> {
+ skip_no_distinct_id: bool,
+ event_transform: impl Fn(RawEvent) -> Result<Option<RawEvent>, Error>,
+ ) -> impl Fn(Self) -> Result<Option<InternallyCapturedEvent>, Error> {
move |mx| {
let token = context.token.clone();
let team_id = context.team_id;
- // Getting entropy is surprisingly expensive, so don't do it a lot unless we have to
- let generated_id = Uuid::now_v7();
-
- let distinct_id = mx
- .properties
- .distinct_id
- .as_ref()
- .cloned()
- .unwrap_or(format!("mixpanel-generated-{}", generated_id));
+ let distinct_id = match (
+ mx.properties.distinct_id.as_ref().cloned(),
+ skip_no_distinct_id,
+ ) {
+ (Some(distinct_id), _) => distinct_id,
+ (None, true) => return Ok(None),
+ (None, false) => Uuid::now_v7().to_string(),
+ };
+ let generated_id = Uuid::now_v7();
// We don't support subsecond precision for historical imports
let timestamp = DateTime::<Utc>::from_timestamp(mx.properties.timestamp_ms / 1000, 0)
.ok_or(Error::msg("Invalid timestamp"))?;
Greptile
greptile
logic: Potential loss of precision by dividing timestamp_ms by 1000 without rounding. Consider using (timestamp_ms + 500) / 1000 for more accurate conversion.