WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™)
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
How else could this be interpreted?
"Test count monitoring is way too high-level, coarse-grained and unspecific to be a useful tool in checking whether TDD process is being followed." For example.
I see. So you're firmly in the camp of the good is the enemy of the perfect.
No again. I'm firmly in a camp of "if a tool coincidentally has a second-order side effect of, among other things, making it a tiny bit more likely to catch the most egregious cases of not using TDD, then it's not a TDD tool, and using it doesn't make your TDD a tool-assisted TDD."
LOL. "Tool that helps doesn't help." Yes, a very good position to maintian.
Is work time tracker a TDD tool or not? Because it helps with seeing if people do TDD just as much as test tracker does.
I can't understand why anyone would have that line of thought
Maybe because no one has and you're just imagining things? Instead of, you know, actually reading my posts? Something you repeatedly accuse me of not doing?
Yeah, it's weird. I read your stuff and you seem to read mine and yet you never address the things I'm saying.
And you don't address the things I'm saying. Like, right now you didn't even register I said there's a difference between "the tool coincidentally has a second-order side effect of, among other things, making it a tiny bit more likely to catch the most egregious cases of not using TDD" and "its a TDD tool".
-
@Jaloopa said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
The only automated tooling I can think of that would enforce strict TDD rather than the weaker requirement for high test coverage would be to have checkin requirements, even on local commits, that enforced each commit either introducing new failing tests, or fixing existing failing tests. That would be an incredibly annoying workflow, I imagine even the most zealous TDD fans are mainly going to want to commit test and implementation together most of the time
Flagged for sanity
-
@Jaloopa said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
The only automated tooling I can think of that would enforce strict TDD rather than the weaker requirement for high test coverage would be to have checkin requirements, even on local commits, that enforced each commit either introducing new failing tests, or fixing existing failing tests. That would be an incredibly annoying workflow, I imagine even the most zealous TDD fans are mainly going to want to commit test and implementation together most of the time
Well, if you actually practice TDD, you naturally end up committing both tests and implementation together anyway.
-
Oh, another one if you think at an earlier stage than VCC. An IDE that doesn't allow you to modify source files unless there's a failing test covering that line
-
@Jaloopa that would actually be tool-assisted TDD. It would also be absolutely insane because TDD itself is absolutely insane.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
How else could this be interpreted?
"Test count monitoring is way too high-level, coarse-grained and unspecific to be a useful tool in checking whether TDD process is being followed." For example.
I see. So you're firmly in the camp of the good is the enemy of the perfect.
No again. I'm firmly in a camp of "if a tool coincidentally has a second-order side effect of, among other things, making it a tiny bit more likely to catch the most egregious cases of not using TDD, then it's not a TDD tool, and using it doesn't make your TDD a tool-assisted TDD."
LOL. "Tool that helps doesn't help." Yes, a very good position to maintian.
Is work time tracker a TDD tool or not? Because it helps with seeing if people do TDD just as much as test tracker does.
Not really. As a proxy, it's too vague and doesn't really address the issue.
I can't understand why anyone would have that line of thought
Maybe because no one has and you're just imagining things? Instead of, you know, actually reading my posts? Something you repeatedly accuse me of not doing?
Yeah, it's weird. I read your stuff and you seem to read mine and yet you never address the things I'm saying.
And you don't address the things I'm saying. Like, right now you didn't even register I said there's a difference between "the tool coincidentally has a second-order side effect of, among other things, making it a tiny bit more likely to catch the most egregious cases of not using TDD" and "its a TDD tool".
I'm saying that it's useful from a process control perspective. It looks at one aspect which is necessary but not sufficient. And it's very easy to check. Also, I'm assuming that you'll get people who forget or get lazy or who think TDD is dumb and intentionally resist.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
How else could this be interpreted?
"Test count monitoring is way too high-level, coarse-grained and unspecific to be a useful tool in checking whether TDD process is being followed." For example.
I see. So you're firmly in the camp of the good is the enemy of the perfect.
No again. I'm firmly in a camp of "if a tool coincidentally has a second-order side effect of, among other things, making it a tiny bit more likely to catch the most egregious cases of not using TDD, then it's not a TDD tool, and using it doesn't make your TDD a tool-assisted TDD."
LOL. "Tool that helps doesn't help." Yes, a very good position to maintian.
Is work time tracker a TDD tool or not? Because it helps with seeing if people do TDD just as much as test tracker does.
Not really. As a proxy, it's too vague and doesn't really address the issue.
You know what else is just a proxy, too vague and doesn't really address the issue?
TESTS TRACKER.
Also, I'm assuming that you'll get people who forget or get lazy or who think TDD is dumb and intentionally resist.
The rebels will just put implementation and tests in the same commit and you'd be none the wiser.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Jaloopa said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
The only automated tooling I can think of that would enforce strict TDD rather than the weaker requirement for high test coverage would be to have checkin requirements, even on local commits, that enforced each commit either introducing new failing tests, or fixing existing failing tests. That would be an incredibly annoying workflow, I imagine even the most zealous TDD fans are mainly going to want to commit test and implementation together most of the time
Well, if you actually practice TDD, you naturally end up committing both tests and implementation together anyway.
That was my point. It would technically enforce it but at the cost of breaking the workflow of even people who are super into it
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
How else could this be interpreted?
"Test count monitoring is way too high-level, coarse-grained and unspecific to be a useful tool in checking whether TDD process is being followed." For example.
I see. So you're firmly in the camp of the good is the enemy of the perfect.
No again. I'm firmly in a camp of "if a tool coincidentally has a second-order side effect of, among other things, making it a tiny bit more likely to catch the most egregious cases of not using TDD, then it's not a TDD tool, and using it doesn't make your TDD a tool-assisted TDD."
LOL. "Tool that helps doesn't help." Yes, a very good position to maintian.
Is work time tracker a TDD tool or not? Because it helps with seeing if people do TDD just as much as test tracker does.
Not really. As a proxy, it's too vague and doesn't really address the issue.
You know what else is just a proxy, too vague and doesn't really address the issue?
TESTS TRACKER.
At least you're on the right subject. But I guess we'll just have to disagree here.
Also, I'm assuming that you'll get people who forget or get lazy or who think TDD is dumb and intentionally resist.
The rebels will just put implementation and tests in the same commit and you'd be none the wiser.
So...make it a policy not to do that? In any case, you're back to "the good is the enemy of the perfect." Which is bad.
-
@boomzilla you want broken code in vcs?
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Also, I'm assuming that you'll get people who forget or get lazy or who think TDD is dumb and intentionally resist.
The rebels will just put implementation and tests in the same commit and you'd be none the wiser.
So...make it a policy not to do that?
That would prevent TDD to start with, as the entire point of TDD is to write tests and implementation roughly at the same time. Unless you like having commits every 5 minutes.
In any case, you're back to "the good is the enemy of the perfect."
No I'm not. I'm back to "tests monitoring doesn't actually help with TDD any more than work time monitoring, and we don't call the work time tracker a TDD tool".
But yes, I guess we have to agree to disagree, if only to stop wasting any more time trying to show you why you're wrong.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Also, I'm assuming that you'll get people who forget or get lazy or who think TDD is dumb and intentionally resist.
The rebels will just put implementation and tests in the same commit and you'd be none the wiser.
So...make it a policy not to do that?
That would prevent TDD to start with, as the entire point of TDD is to write tests and implementation roughly at the same time. Unless you like having commits every 5 minutes.
- Have you met @TheCPUWizard?
- Commits are free.
In any case, you' back to "the good is the enemy of the perfect."
No I'm not. I'm back to "tests monitoring doesn't actually help with TDD any more than work time monitoring, and we don't call the work time tracker a TDD tool".
But yes, I guess we have to agree to disagree, if only to stop wasting any more time trying to show you why you're wrong.
LOL.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Commits are free.
-
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Also, I'm assuming that you'll get people who forget or get lazy or who think TDD is dumb and intentionally resist.
The rebels will just put implementation and tests in the same commit and you'd be none the wiser.
So...make it a policy not to do that?
That would prevent TDD to start with, as the entire point of TDD is to write tests and implementation roughly at the same time. Unless you like having commits every 5 minutes.
- Have you met @TheCPUWizard?
- Commits are free.
In any case, you' back to "the good is the enemy of the perfect."
No I'm not. I'm back to "tests monitoring doesn't actually help with TDD any more than work time monitoring, and we don't call the work time tracker a TDD tool".
But yes, I guess we have to agree to disagree, if only to stop wasting any more time trying to show you why you're wrong.
LOL.
Commits that would definitely break a later bisect aren't. Commits that fuck up the history aren't either.
-
@Gribnit said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Also, I'm assuming that you'll get people who forget or get lazy or who think TDD is dumb and intentionally resist.
The rebels will just put implementation and tests in the same commit and you'd be none the wiser.
So...make it a policy not to do that?
That would prevent TDD to start with, as the entire point of TDD is to write tests and implementation roughly at the same time. Unless you like having commits every 5 minutes.
- Have you met @TheCPUWizard?
- Commits are free.
In any case, you' back to "the good is the enemy of the perfect."
No I'm not. I'm back to "tests monitoring doesn't actually help with TDD any more than work time monitoring, and we don't call the work time tracker a TDD tool".
But yes, I guess we have to agree to disagree, if only to stop wasting any more time trying to show you why you're wrong.
LOL.
Commits that would definitely break a later bisect aren't. Commits that fuck up the history aren't either.
They're free at the point of use, they just have externalised costs
-
@Jaloopa said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gribnit said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@boomzilla said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Also, I'm assuming that you'll get people who forget or get lazy or who think TDD is dumb and intentionally resist.
The rebels will just put implementation and tests in the same commit and you'd be none the wiser.
So...make it a policy not to do that?
That would prevent TDD to start with, as the entire point of TDD is to write tests and implementation roughly at the same time. Unless you like having commits every 5 minutes.
- Have you met @TheCPUWizard?
- Commits are free.
In any case, you' back to "the good is the enemy of the perfect."
No I'm not. I'm back to "tests monitoring doesn't actually help with TDD any more than work time monitoring, and we don't call the work time tracker a TDD tool".
But yes, I guess we have to agree to disagree, if only to stop wasting any more time trying to show you why you're wrong.
LOL.
Commits that would definitely break a later bisect aren't. Commits that fuck up the history aren't either.
They're free at the point of use, they just have externalised costs
Sshh, there's libertarians around.
-
@Gribnit said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Commits that would definitely break a later bisect aren't.
If you're Doing TDD Properly™ then you have everything fully tested all the time and never need to do bisect. QED.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Well, if you actually practice TDD, you naturally end up committing both tests and implementation together anyway.
I had to look up the definition of TDD, and apparently it entails:
- Write a test
- Verify that the test fails
- Write the shittiest possible code that could make the test pass
- Verify that the test passes
- Refactor the code into something less shitty
Now, if you want to strictly embed this into CI, you have to check the intermediate stages and thus you cannot commit everything in one go. So, the CI should only allow the following types commits:
- 1+2: A test is added. The added test fails.
- 3+4: Code is added. A test that failed before, now passes. The added code is shitty (e.g. returning a hard-coded value that the test expects instead of doing anything useful).
- 5: Code is modified. All tests that passed before, still pass. The code quality has been improved.
Maybe some kind of AI needs to be integrated into the CI enviroment to prevent the developer from doing 5) in one go with 3)+4).
-
@Grunnen said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Write the shittiest possible code that could make the test pass
And this, I think, is the fundamental problem with the idea. It doesn’t allow you to write sensible code from the start.
I think the rationale for that is to ensure that your tests are actually strong enough to be able to distinguish “theshittiestsimplest implementation of the spec” from “the shittiest code that passes all tests”, and if the latter doesn’t fulfill the former you need more tests.But if you would actually do that mindlessly you’d just add yet another hard-coded return after you added a test.
-
@topspin said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
It doesn’t allow you to write sensible code from the start.
It's also really horrid at the stage that you're building out the data model for the application. OTOH, the reason that TDD is specified like that is because some programmers (including several of my cow-orkers) have a massive tendency to over-engineer things from get-go “because someone sometime somewhere might possibly need that!”. Don't put lots of effort into writing things that you never actually need, and can't see the actual benefit from. YAGNI.
TDD goes on to claim that if you can't see the benefit in tests, then you shouldn't do a thing. The deepest actual problem with that is that performance testing is required to really establish whether things are good enough, and that's intensely difficult to do quantitatively. But otherwise, it's a very good plan to use TDD, especially during the maintenance phase of a project.
-
@topspin said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
But if you would actually do that mindlessly you’d just add yet another hard-coded return after you added a test.
Technically, you could implement something like
sin()
forfloat
s using in the order of a billion or so branches + return statements. Max 1 ulp error too.Point is, taking an idea like TDD (or really most other ideas), interpreting it in the narrowest possible way and then taking that to an extreme almost never ends up being anything useful or interesting.
As this thread has amply demonstrated.
-
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Technically, you could implement something like sin() for floats using in the order of a billion or so branches + return statements. Max 1 ulp error too.
More usual to use a table and (probably quadratic) interpolation.
-
@dkf said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
More usual to use a table and (probably quadratic) interpolation.
Yes, but that would be a useful implementation, which wasn't what I was aiming at. (That was a billion as in ~2^30.)
-
@Grunnen said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Now, if you want to strictly embed this into CI, you have to check the intermediate stages and thus you cannot commit everything in one go.
Are you replying to the right person? Because I believe that @Gąska was basing at least one point of his argument about CI and TDD being entirely different things on this exact premise.
-
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@topspin said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
But if you would actually do that mindlessly you’d just add yet another hard-coded return after you added a test.
Technically, you could implement something like
sin()
forfloat
s using in the order of a billion or so branches + return statements. Max 1 ulp error too.Point is, taking an idea like TDD (or really most other ideas), interpreting it in the narrowest possible way and then taking that to an extreme almost never ends up being anything useful or interesting.
As this thread has amply demonstrated.
That was mostly the example I had in mind too. Take any kind of function like that and at no point does adding yet another test value get you from list of hard-coded shit to a real implementation.
That’s surely taking the TDD approach too literal, but it still exemplifies the problem.
-
@topspin randomized tests can break the hardcoding regress
-
@Gribnit said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@topspin randomized tests can break the hardcoding regress
But how do you do that with, say, the example of
sin
? You’d have to know the value to test the value.Maybe if you test sin and cos together you can test geometric identities.
-
@topspin Generate random value. Use an accurate but slow method like the Taylor Series to calculate the sine of the random value to a high degree of precision. (Use a Math Guru™ to make sure your calculation is implemented in a way to minimize round-off and other numerical errors.) Compare to the result returned by the function you're checking. If it matches the Taylor Series result (within expected floating-point round-off), it passes; if not, it fails. Repeat for many random values.
-
@HardwareGeek said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Use an accurate but slow method like the Taylor Series to calculate the sine of the random value to a high degree of precision.
Remember that sin(π) ≈ π for very small values of π. I don't remember the exact range that that approximation covers at 1ulp, but it's a fair chunk of possible float values around zero.
-
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
very small values of π
-
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@HardwareGeek said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Use an accurate but slow method like the Taylor Series to calculate the sine of the random value to a high degree of precision.
Remember that sin(π) ≈ π for very small values of π. I don't remember the exact range that that approximation covers at 1ulp, but it's a fair chunk of possible float values around zero.
X.
But, testing the well know periods on random multiple is decent for any periodic.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I'm just ranting
On that topic, I really wanted to preserve the look of the main page listing for future viewers:
I find that the goose avatar with the all-caps title immediately ups the rant's value.
-
@JBert wbn if the Re: were "Gobble gobble gobble gobble gobble" tho
-
@HardwareGeek said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
very small values of π
Yep, for floats it seems to hold for π < 0.0004436, or about 926 million float numbers. (Floats and sin are both symmetric, so there should be another 926 million just below zero.)
Code
int main() { std::size_t count = 0; float π = 0.f; while( std::sin(π) == π ) { π = std::nextafter( π, 10000.f ); ++count; } std::printf( "Held for π < %g (%zu numbers)\n", π, count ); return 0; }
-
@cvi well demonstrated.
-
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
it seems to hold for π < 0.0004436
I'm used to π being in vicinity of 3.14...
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
it seems to hold for π < 0.0004436
I'm used to π being in vicinity of 3.14...
It's important to expand your experiences in order to grow as a programmer.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
it seems to hold for π < 0.0004436
I'm used to π being in vicinity of 3.14...
It's 2021, nothing means what it used to
-
@loopback0 that's been since 2016. Now everything means anything but what it is.
-
@loopback0 I thought about making a joke along those lines, but this isn't the , so I didn't, because it definitely would have belonged there.
-
@HardwareGeek Well I didn't actually mean anything that automatically belongs there, so...
-
@loopback0 What I was thinking of does.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I'm used to π being in vicinity of 3.14...
We have way more numbers than letters (even if we add the greek and arabic alphabets to the latin one), so some overloading and reuse should be expected.
-
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I'm used to π being in vicinity of 3.14...
We have way more numbers than letters (even if we add the greek and arabic alphabets to the latin one), so some overloading and reuse should be expected.
I thought you’re making a joke about the similar identity of sin(pi+x)=-x for small values of
pix, which can also be used to generate more significant digits of pi.
Reminded me of this (probably been linked somewhere here before):
-
@topspin said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
Reminded me of this (probably been linked somewhere here before):
FWIW- hardware
fsin
instructions aren't really used anymore on modern x86, from what I've seen. Standardsin()
calls a function that contains a pile of SSE/AVX code.It's been a while since I looked at it in depth and I for sure didn't cover all the different implementations. The one that I looked at did some argument reduction, exploited symmetries to get down to ~pi/4 ranges (IIRC) and then used a polynomial to compute the value on that range. At that point, the polynomial was of quite low degree; a lot of the code was down to the argument reduction and the mapping to the right range. I think the small-angle approximation was in there as well.
-
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
I'm used to π being in vicinity of 3.14...
We have way more numbers than letters (even if we add the greek and arabic alphabets to the latin one), so some overloading and reuse should be expected.
There are approximately 99 letters you could've used that wouldn't have caused confusion, including 23 lowercase Greek. But you've had to pick the only one that's ambiguous in that context.
By the way - I wonder what happens to the sine function when you do change the value of π (by using non-euclidean geometry). Is it just going to change period/amplitude, or is the shape of the wave going to be different?
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
There are approximately 99 letters you could've used that wouldn't have caused confusion, including 23 lowercase Greek
But those wouldn’t have been funny.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
There are approximately
99π letters you could've used that wouldn't have caused confusion
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
There are approximately 99 letters you could've used that wouldn't have caused confusion, including 23 lowercase Greek. But you've had to pick the only one that's ambiguous in that context.
What @topspin said.
I wish I'd gotten the t-shirt many years ago with that joke. Now I can just find the "2+2=5 for large values of two", which is not as funny IMO.
By the way - I wonder what happens to the sine function when you do change the value of π (by using non-euclidean geometry). Is it just going to change period/amplitude, or is the shape of the wave going to be different?
IIRC, the equivalent of geometric pi (ratio of radius to circumference) is no longer a constant in hyperbolic geometry. It becomes larger as the radius becomes larger.
But standard pi and
sin
etc don't cease to existing there. However if you look at the ratios of sides of/angles in triangles, you'll encounter a bunch of hyperbolic functions, e.g.cosh
and such. This is probably a better source than what I remember half-assedly. Has a link to the spherical space variant too.
-
@Gąska said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
@cvi said in WRITING TESTS IS NOT TDD!!!!!!!!!! (Re: The Official Funny Stuff Thread™):
it seems to hold for π < 0.0004436
I'm used to π being in vicinity of 3.14...
πostmodernism!!!1