Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Large integer precision error in Bash command output rendering

github.com

Post reply on HN
Print view View original

11–20 of 41 posts

Re: Large integer precision error in Bash command output rendering

#11

Post by DecoPerson »

CGamesPlay wrote: post #6

Claude Code is simultaneously the most useful and lowest quality app I use. It's filled with little errors and annoyances but succeeds despite them. Not to mention the official documentation is entirely vibe-copywritten and any quality control is cursory at best. It forcibly installs itself to ~/.local/bin. Do you already have a file at that location? Not anymore. When typing into the prompt, EACH KEYSTROKE results i…

Ha, interesting. Using Claude Code in Zed, I never encountered any of these defects.

I just open a Claude Code Thread, tell it what I want, bypass permissions (my remote is a container), and let it work. And it works wonderfully!

I guess the “integrated” part of IDE is pretty important.

Re: Large integer precision error in Bash command output rendering

#12

Post by alyxya »

cyral wrote: post #8

Typing "348555896224571969" into your browser's dev console will also return 348555896224571970

I don't think this is a bug specifically with Claude Code, rather it's due to Claude Code having javascript in the backend. The interesting thing to me is that the numeric string was interpreted as an integer.

Re: Large integer precision error in Bash command output rendering

#13

Post by ec109685 »

fulafel wrote: post #5

Smells like floating point. Python prompt: >>> int(float('348555896224571969')) 348555896224571968 It just exceeds the mantissa bits of doubles: >>> math.log2(34855589622457196) 54.952239550875795 JavaScript (in)famously stores all numbers as floating point resulting in silent errors also with user perceived integers, so this might be an indication that Claude Code number handling uses JS native numbers for this.

They wrap bash with python.

Re: Large integer precision error in Bash command output rendering

#14

Post by CGamesPlay »

ec109685 wrote: post #10
CGamesPlay wrote: post #6

Claude Code is simultaneously the most useful and lowest quality app I use. It's filled with little errors and annoyances but succeeds despite them. Not to mention the official documentation is entirely vibe-copywritten and any quality control is cursory at best. It forcibly installs itself to ~/.local/bin. Do you already have a file at that location? Not anymore. When typing into the prompt, EACH KEYSTROKE results i…

Are you sure about the one char thing? I’d expect a huge flash if that was the case.

No, I'm not sure about the precise mechanics of it, but I noticed it because of the huge flash when using it over a somewhat laggy SSH connection. It doesn't happy in all contexts. I've definitely seen it when typing into the new-ish Claude "ask questions about the plan" flow, and I've also noticed that it redraws the entire conversation history when each new line of output is presented in a long-running tool call.

Re: Large integer precision error in Bash command output rendering

#17

Post by sevg »

rrwright wrote: post #16

Why did Hacker News rename the title of this post? It was originally: "Claude Code Introduces Off-by-One Errors" Original: https://pasteboard.co/xTjaRmnkhRRo.png Unilaterally Edited: https://pasteboard.co/rDPINchmufIF.png

Looks like mods changed the title to the title of the GitHub Issue. This from HN guidelines is probably why:

> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

Re: Large integer precision error in Bash command output rendering

#18

Post by rrwright »

sevg wrote: post #17
rrwright wrote: post #16

Why did Hacker News rename the title of this post? It was originally: "Claude Code Introduces Off-by-One Errors" Original: https://pasteboard.co/xTjaRmnkhRRo.png Unilaterally Edited: https://pasteboard.co/rDPINchmufIF.png

Looks like mods changed the title to the title of the GitHub Issue. This from HN guidelines is probably why: > Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

Good catch on the guidelines. But that github issue title obviously misses the point. The whole point is that it's a silent error in Claude Code.

Re: Large integer precision error in Bash command output rendering

#19

Post by fulafel »

ec109685 wrote: post #13
fulafel wrote: post #5

Smells like floating point. Python prompt: >>> int(float('348555896224571969')) 348555896224571968 It just exceeds the mantissa bits of doubles: >>> math.log2(34855589622457196) 54.952239550875795 JavaScript (in)famously stores all numbers as floating point resulting in silent errors also with user perceived integers, so this might be an indication that Claude Code number handling uses JS native numbers for this.

They wrap bash with python.

I still suspect JS. It's much harder to shoot yourself in the foot with Python. Even if you use JSON:

  >>> json.loads('{"nr": 348555896224571969}')
  {'nr': 348555896224571969}
  >>> type(_['nr'])

Re: Large integer precision error in Bash command output rendering

#20

Post by kazinator »

Note that the number is 18 digits long.

If there is a conversion to IEEE 64 bit double involved, that type is only guaranteed to record 15 decimal digits of precision, so this number cannot be represented with enough precision to recover all of its original digits.

In C implementations, this value is represented as DBL_DIG, which is typically 15 on systems with IEEE floating point.

(There is also DBL_DECIMAL_DIG which is typically 17; that's the opposite direction: how many decimal digits we need to print a double such that the exact same double can be recovered by parsing the value. DBL_DIG existed in C90, but DBL_DECIMAL_DIG didn't appear until, it looks like, C11.)

Post reply on HN