zlacker

[parent] [thread] 6 comments
1. chrism+(OP)[view] [source] 2024-06-06 05:40:35
> a clever, unintuitive solution to a difficult problem

If you approach from the mathematics side of things, building on log₁₀ is the completely obvious approach to use. If it seems unintuitive, that’s just because you don’t understand logarithms.

> the autograding test cases did not include a test using a power of 10.

That’s a pretty glaring oversight. Boundary cases are probably the most important things to cover in such tests. I’d be wanting to test things like 0, 1, 9, 10, 11, 99, 100, 101, and so forth. (Also negative numbers, unless the problem explicitly constrained it to {0, 1, 2, …}.)

We often talk about edge cases in testing, but this reveals that the edges can be not just at the extremes, but also at intermediate value changes. Put another way (still fuzzy!), these are the interesting values. You test interesting values.

This would also be a good place to use property testing; instead of hard-coding a bunch of tests (or perhaps as well as), compare against a large number of generated values, comparing with a known-good implementation, probably just len(str(number)).

replies(3): >>equili+11 >>MrJohz+t1 >>dingal+cB
2. equili+11[view] [source] 2024-06-06 05:52:22
>>chrism+(OP)
> Write a function digitLength(n) that takes a natural number as input (i.e., 0, 1, 2, … – a nonnegative integer)

On another note, you have a very interesting website, I will be in touch at some point when I decide to tackle Rust

3. MrJohz+t1[view] [source] 2024-06-06 05:57:36
>>chrism+(OP)
I'm not sure about the property-based testing thing. In this example, yes, you can easily write a test case that compares against the string-based algorithm. But in general, this is one of the biggest weaknesses of PBT, which is that you need to find a good property to test.

In a lot of cases, the most useful property is "for all inputs, the result is the right answer", but we don't know the right answer until we've written the algorithm, and there's not usually much point writing two algorithms unless, like here, one of those algorithms is trivial correct but inappropriate for some reason.

More generally, I feel like the more trivial a property is to check, the simpler the code to implement it is, and the less useful the test is in general. In the extreme case, a getter/setter pair is very easy to test with PBT, but you rarely need to be testing your getters and setters.

replies(1): >>fanf2+Ij
◧◩
4. fanf2+Ij[view] [source] [discussion] 2024-06-06 08:55:13
>>MrJohz+t1
Counting digits is very closely adjacent to the general category of parsing and printing (or serialization/deserialization), which are both tricky to get right and have simple correctness tests. They are perfect candidates for property-based testing.
replies(1): >>MrJohz+u52
5. dingal+cB[view] [source] 2024-06-06 11:34:38
>>chrism+(OP)
Why would mathematics be "completely obvious" when one is dealing with how a computer stores and represents data?

The 'clever' solution fails miserably on value zero and needs hard-coding to handle it. That looks like using the wrong tool.

replies(1): >>chrism+vF
◧◩
6. chrism+vF[view] [source] [discussion] 2024-06-06 12:09:23
>>dingal+cB
You’re misunderstanding me. I said that if you approach from the mathematics side of things, building on log₁₀ is the completely obvious approach to use. That is, if you’re already a mathematician, of course you’ll see if you can use logarithms, because that will be the way you’ll think—because you’ll view it as a mathematical and algorithmic task.

As for the handling of zero, well, that’s not about mathematics or about how a computer stores or represents data—that’s about how humans represent data. We choose to special-case zero, allowing it to have a leading zero which we never allow for anything else. All solutions in software will need to special-case zero.

◧◩◪
7. MrJohz+u52[view] [source] [discussion] 2024-06-06 20:21:18
>>fanf2+Ij
But how do you do PBT here without having a known-correct algorithm available? Because that scenario is seldom the case in practice.
[go to top]