Wow. this is one of the reasons I hated school. No programmatic reason what given for why a string solution couldnt be used, only an arbitrary reason. Here students may have knowledge from self teaching or whatever, but they are unallowed to use that knowledge because "reasons".
To any teacher that thinks its a good idea to punish students for thinking outside the box: shame on you. All youre going to end up doing is crushing enthusiasm and/or creating drones. Please dont.
This also fails my personal rule to always need to have a reason to do something mean - like failing someone on a problem, and no reason to do something nice - like saying it’s fine since it works.
I've taught CS courses before, and have seen plenty of self-proclaimed self-taught know-it-alls who seem to be more stackoverflow-copy-pasters than anything else.
Thankfully this TA agreed with you (as do I). He said it looked good, and I think that's the shortest lab I ever had.
the division examples are not necessary either, thats the point. you can solve it different ways, that doesnt mean one way is not necessary, it just means its different. one may be faster, one may be more readable. If you dont allow different solutions you cant explore the tradeoffs between them.
personally, when something is to basic to hold my interest, i try to find ways to make it more challenging.
In an operating systems class we had a little project to create a command line calculator in C, with the added hoop of using x86 ASM for all control flow and calculations. As this was not a programming class we had a very brief overview of the very basics needed to get this done. I assumed using floating point arithmetic would make this easier, but knew that was not part of the early spec, so I asked the professor in class what version of x86 and he said pentium 1.
I then found and read intel’s documentation for the first generation Pentium. Which completely changed my mental model of CPU’s. Honestly, it was probably the closest collage assignment to how real world coding works and much more useful long term than just implementing some simple algorithms by hand.
Sometimes you actually have to do arithmetic when programming. It's useful to teach people these sort of things so they don't cook up half baked solutions in the future.
I wonder what would happen if you implemented itoa and then counted digits. It’s pretty much the same thing.
The entire problem is arbitrary. It's not a real-world problem looking for a solution. It's a programming exercise.
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.
for larger numbers it is probably faster.
Regarding itoa(), the first implementation provided in the article actually match it's implementation, without the unnecessary bits (building the output).
I think if you tell stuff like this upfront it is totally acceptable: “Reduce the number of digits in a given float without converting it to a String”.
Even students with previous knowledge could take this as a challenge where they learn something.
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.
I'd just picked up python and was having so much fun going through the project Euler problems.
I can't remember which question it was for but we had to know the length of an integer. At that point I hadn't learnt about type conversion so had to implement it the way the author wants his students to do it.
I remember fondly as well that I hadn't learnt about the modulo operator and had to implement that by myself as well.
I couldn't believe it when I got the answer and progressed to the forum where others shared their answers and they were doing it on one line with %!
Good times!
They should consider the upper bound of their algorithm. Because it uses floating point, it doesn't work for all natural numbers, as required by their specification.
To address your point, counting digits in base 2 is much simpler than in base 10, because the internal representation of the number on the computer is already base 2. You can use numeric calculations, but you can also just look at your digits.
(Edited for fewer tangents and to be more positive.)
The thing I did learn, and which I think has paid more dividends in my career than knowing the definition of the Fibonacci sequence, is that knowing your tools well can save you time and effort and reduce the amount of your own code you need to maintain and put effort into.
Thinking outside the box is of course valuable, but the teachers have specific concept they want to teach and constraints like that help them accomplish that.
When it comes to tests, it’s not as easy. At tests it’s is more about solving the actual problem, but one could still argue that the test is meant to test how well one has learned what was thought, not to solve the problem.
I think this is totally fair in this case.
If you prefer, you can view the problem restrictions as a means to encourage students to develop a more general algorithm for solving the problem, rather than a programmatic implementation specific to Python. Hopefully this makes them seem less arbitrary.
In this case, even though the solution is disallowed for grading purposes, there is an opportunity to discuss it during the lesson.
Since the discussion takes place in a low-pressure, guided group lesson, students will certainly not be penalized for suggesting the string method in that setting. Also, students trying to use strings on homework will fail tests in the linter and autograder before they finally submit, so they will have plenty of opportunity to fix their mistake before receiving a grade on their work.
I once got points taken off for using a recursive function as part of my solution. I didn't know the language before, nor did I have much experience with recursive functions as a formal concept.
I didn't even know at that time that recursive functions were a special thing that had to be taught to me.
Blocking off a generic "anything you haven't been taught yet" is a hellfire of ambiguous egg shells.
Strictly speaking you might not have been taught to use division with loops. Maybe you haven't been taught about the log10 function, or you have but you haven't been taught about combining the log10 function with the round/ceil functions, are you sure you were taught about putting if's before these exact functions?
The issue is every programming question requires by its very nature that you use something you haven't been taught to solve it. So you have to know what the teacher counts as acceptable vs unacceptable, and this comes into weird edge cases where the logic behind why something would be considered part of the "you must be taught first" category vs the "you are to assume figuring this out is part of the question" category requires knowing an overview of how to teach computer science, something the students would not have.
I once got points taken off for using a recursive function as part of my solution because that wasn't taught until the next quarter. I didn't know the language before, nor did I have much experience with recursive functions as a formal concept. We knew how to make functions, call functions, do loops, and even do gotos.
I didn't even know at that time that recursive functions were a special thing that had to be taught to me, it just came to me as the way to solve the problem.
Also, counting digits in base 2 is not the log2. The former gives you the latter but not the reverse. Finding the number of decimal digits in a number given in base 2 is not a simplification.
constraints should be spelled out explicitly.
The issue is every programming question requires by its very nature that you use something you haven't been taught to solve it
that, i don't agree with. it's entirely possible to state programming questions in such a way that they only require things you have already been taught. (in its simplest form "being taught" means "being told about". most (if not all) freecodecamp exercises work like that.
For example, if early in an elementary number theory class the student is asked to prove that there are in infinite number of primes of the form 4n+3, a solution that just invokes Dirichlet's theorem on primes in arithmetic progressions would probably not be acceptable. That approach does work to show that there are an infinite number of 4n+3 primes, but completely fails to show that that the student understood the material actually taught in class.
It's the exact same thing with the digit counting problem. Solving it by just invoking the built in string length function does little to demonstrate that the student understands the material taught so far.
...and then checks for and corrects the potential off-by-one thus incurred.
If you do these calculations by hand, the complexity will be more obvious because each operation will be smaller.
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.
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).]