Skip to content

Maintenance: float2nr and comments - Fix numeric accuracy issues#1724

Open
claude[bot] wants to merge 2 commits intomasterfrom
maintenance/fix-comment-accuracy-and-float2nr
Open

Maintenance: float2nr and comments - Fix numeric accuracy issues#1724
claude[bot] wants to merge 2 commits intomasterfrom
maintenance/fix-comment-accuracy-and-float2nr

Conversation

@claude
Copy link
Copy Markdown

@claude claude Bot commented Apr 28, 2026

Summary

Inspected the VimScript expression operators and float function implementations, starting from BitwiseLeftShiftOperatorTest.kt.

Issues found

  1. Inaccurate comment in BitwiseLeftShiftOperatorTest.kt: The comment stated echo 1<<63 returns -long.max_value (i.e., -9223372036854775807), but the correct value is Long.MIN_VALUE (-9223372036854775808). In 64-bit two's complement, setting only the MSB gives the minimum value, which differs from -Long.MAX_VALUE by 1.

  2. Misleading comment in ArithmeticOperatorHandlers.kt (DivisionHandler): The original comment said "Doubles give NaN, which becomes 0 when converted to integer." This only described the 0/0 case. For N/0 where N≠0, doubles give ±Infinity, which converts to ±Int.MAX/MIN_VALUE — also the correct Vim behaviour for integer division by zero. The fix makes the comment accurate for all cases.

  3. Bug in Float2NrFunctionHandler: float2nr(-1.0e150) returned -2147483648 (Int.MIN_VALUE) instead of -2147483647 (-Int.MAX_VALUE). The Vim docs specify that out-of-range values are clamped to ±0x7fffffff (not ±0x80000000). The previous implementation used Double.toInt() directly, which maps very large negative doubles to Int.MIN_VALUE due to JVM conversion rules. The fix uses coerceIn(-Int.MAX_VALUE.toDouble(), Int.MAX_VALUE.toDouble()) before converting, matching Vim's specification.

Changes made

  • BitwiseLeftShiftOperatorTest.kt: Corrected -long.max_valueLong.MIN_VALUE (-9223372036854775808) in comment
  • ArithmeticOperatorHandlers.kt: Improved DivisionHandler comment to accurately describe all three division-by-zero cases
  • Float2NrFunctionHandler.kt: Use coerceIn to clamp to [-Int.MAX_VALUE, Int.MAX_VALUE] before converting to Int
  • Float2NrFunctionTest.kt: Updated expected output from -2147483648 to -2147483647, removed @VimBehaviorDiffers annotation, removed now-unused import

Why these changes improve the code

The comment fixes prevent future developers from being misled about numeric behaviour. The float2nr fix corrects a documented deviation from Vim's behaviour (it was annotated @VimBehaviorDiffers(shouldBeFixed = true)), making IdeaVim more compatible with Vim.

🤖 Generated with Claude Code

github-actions Bot and others added 2 commits April 28, 2026 07:09
- BitwiseLeftShiftOperatorTest: `1<<63` in Vim gives Long.MIN_VALUE
  (-9223372036854775808), not `-Long.MAX_VALUE` (-9223372036854775807).
  These differ by 1 due to two's complement representation.

- DivisionHandler: the previous comment only described the 0/0 → NaN → 0
  case, missing that N/0 → ±Infinity → ±Int.MAX/MIN_VALUE, which also
  matches Vim's specified integer-division-by-zero behaviour.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Vim's float2nr() truncates out-of-range floats to ±0x7fffffff
(±2147483647), not ±0x80000000.  The previous implementation used
Double.toInt() directly, which maps very large negative doubles to
Int.MIN_VALUE (-2147483648) instead of -Int.MAX_VALUE (-2147483647).

Fix by clamping the double to [-Int.MAX_VALUE, Int.MAX_VALUE] before
converting to Int, which matches the Vim documentation behaviour.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants