zlacker

> No programmatic reason what given for why a string solution couldnt be used, only an arbitrary reason

The entire problem is arbitrary. It's not a real-world problem looking for a solution. It's a programming exercise.

>>lilyba+(OP)
I think it is more of a math exercise solved via programming. Which is somehing I am not particularly fond of.

These crop up all the time in those online programming challenge things.

They are usually maths problems (e.g. Find the combined area of two partially intersecting squares based on their coordinates of a,b,c,d and w,x,y,z) where the solution is done via programming but most of the work is, in my opinion, figuring out the maths which is testing for the wrong thing.

>>ruroun+82
Many things people consider "programming" but not mathematics are things we actually study in mathematics classes. They're just unaware.

>>ruroun+82
This particular problem (number of digits in a number) is actually monumentally important for performance reasons for e.g. json generation. See https://m.facebook.com/notes/facebook-engineering/three-opti... for details.

That said, I do agree that as stated the problem is a toy. The problem statement could at least motivate the lack of string operations - i.e. pretend you’re the language designer and you’re tasked with implementing str(int) in C. Just saying “don’t do that” isn’t helpful. Gaining an understanding that nothing is magical is useful though.

>>NightM+hf
That link has a very insightful discussion (and incidentally provides a nice fast correct solution, and use case, for the initial problem!).

>>lilyba+(OP)
Actually, this problem does occur in practice. When one needs to output some numbers in a column it can be important how wide the widest one is. Ironically, in that case the numbers are going to be converted to text anyway so you might as well use the string size....

>>NightM+hf
Probably the students do not know about big O notation at this point, but requiring a solution that uses at most O(1) additional space would be enough. Then again, automatic bignums in python make it hard to evaluate the space complexity.

>>cjfd+uD
Except string size isn't co-determinate with output size either. Number of code points is sometimes an approximation of number of glyphs after text rendering, more usefully approximate with ASCII, and a lot less usefully approximate with a large amount of Unicode.

>>WorldM+6x1
We're talking about converting numbers to strings, for which none of that matters.

>>ruroun+82
It's not a math exercise. The problem is stringly - find the length of the string that conventionally represents the given number. The problem is that 0 is a special case, because we write something rather than nothing. Using len(str(n)) is the correct, idiomatic way to solve this. Consider what happens when the problem domain expands to include negative numbers...

Notice that all the straightforward solutions the author rejects, they reject because it fails on 0. Then, with the oh-so-clever log10 solution... surprise! They special-case 0. I'm not sure what the lesson here is supposed to be.

>>ghusba+MX1
Because there are no numbers other than Arabic numerals? Numbers are never localized?

Even within just Arabic numbers, it possible for localization systems to add digit separators such as commas, underscores, or periods depending on region.

Sure, str() of an out-of-the-box number in Python won't do localization by default, but Python is a highly dynamic language and I've seen __str__() handlers that do localization, even on things that otherwise act like numbers.

"Simple" string conversion-based "math" rarely is simple in the real world, and ignoring localization and the complexities of Unicode in situations where you are assuming they can't possibly happen is a jungle of mistakes that programmers continue to make every day. The world doesn't run on EBCDIC or ASCII alone anymore, and localization is a thing that matters to a lot of people. The correspondence between code points reported by len(str()) and either input to str() and output to a display device is tenuous at best in anything but the best ASCII circumstances, and handwaving it away is an exercise in your particular bias.

[ETA: And the parent discussion was explicitly about table formatting the output, and that itself specifically is a scenario where you should want to localize the output first and not just rely on str(yourNumber).]