Live data from Hacker News

Large integer precision error in Bash command output rendering

github.com

31–40 of 41 posts

Re: Large integer precision error in Bash command output rendering

#31

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.

It happens over ssh on cellular when the history gets long. Drives me nuts as I'm a heavy claude-over-ssh-on-phone user.

Re: Large integer precision error in Bash command output rendering

#32

Earlier quoted context omitted.

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.

Honestly, most of the problems I have with Claude Code are frontend problems, so this wouldn't surprise me. I wonder if it's possible to make an alternative CLI frontend to it.

Crystal is one I know of: https://github.com/stravu/crystal

Re: Large integer precision error in Bash command output rendering

#33

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…

I'm working on a fix for the terminal UI.

https://www.youtube.com/watch?v=OGGVdPZTc8E&t=2s

Re: Large integer precision error in Bash command output rendering

#35
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.

It seems like it, but it can't be only that. A float64 representation of an int in the range 2^58 to 2^59 should be rounded to multiples of 2^6, i.e. 348555896224571968 as you found (3.48555896224571968E17) (the final digit 9 in the math.log2() expression was lost, it's 2^58 not 2^54) The unexpected output (according to the bugreport) arises from javascript, it does NOT round like everything else for reasons I don't understand. It seems to prefer rounding to arbitrary multiples of 10 in my limited testing.

Re: Large integer precision error in Bash command output rendering

#36
post #33

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…

I'm working on a fix for the terminal UI. https://www.youtube.com/watch?v=OGGVdPZTc8E&t=2s

Neat!

Re: Large integer precision error in Bash command output rendering

#37

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.

Terminal emulators are fast.

Re: Large integer precision error in Bash command output rendering

#39

We merged a fix for this that'll go out in the ~next release. Also, for clarification, this bug was only impacting the display of numbers in the TUI, not what the model sees. The model sees raw results from bash.

This symptom was affecting display of numbers in the TUI, but the real bug/design flaw is using jq or JSON as a transport mechanism between components or between tools. JSON's number range is famously poor and it even architecture-dependent. So if you use jq or JSON to connect components or tools, you will have this same problem silently occurring elsewhere without visibility in the UI.

This is a bigger deal than it seems like! A confidence-inducing fix would include a blog post describing a top-to-bottom audit of jq/JSON used as a transport layer between tools and components. Not just a patch to the most visible problem.

Re: Large integer precision error in Bash command output rendering

#40
post #12
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.

I agree with what I think you meant: it is not a bug in Claude. However "javascript on the backend" is exactly what Claude Code is! It's a node.js implementation of automation components that feed and pull from the Claude model.

I have a VERY hard time believing that they only use JSON serialization between the model and the TUI. If they're seriealizing JSON between agents, tools, or other components, then this problem is going to continue to persist for a very long time.

Post reply on HN