One idea for mid-level college math classes (i.e. after calculus, before highly proof based courses) which I've seen people speak very positively of is to have a portion of the course consist of students producing conjectures on their own by coming up with examples and counterexamples until they have a viable conjecture.

This sounds like a great fit with, for instance, a discrete math course, where engaging with lots of examples is important to grasping the topic.

However every time I've tried this, I find myself serving as an oracle, because there's no "stopping point" if they get the answer right: if there's a counterexample, they might be able to find it if they looked harder, but once they have a right conjecture, the only tool they have for verifying it is asking me whether or not it's right. So every time they have a new conjecture, they ask me if it's right. (And, at its worst, we alternate between me giving a counterexample and them producing a new conjecture taking into account that one additional counterexample and then asking again.)

One thing I like about the concept is that it starts to move away from "professor as arbitrary decider of right and wrong" which many of my students have internalized. But when the definition of correct conjecture is "professor says you can stop now", it ends up reinforcing that notion instead.

My question is how to avoid this: for students who can't be asked to prove their conjectures, how do they know when to stop looking for counterexamples?

  • $\begingroup$ I would think that a discrete math class would be a wonderful place to have them do "informal" proofs. i.e. When they get to a correct conjecture, ask them: "Why do you think that?" $\endgroup$
    – Adam
    Commented Feb 28, 2017 at 15:07
  • 5
    $\begingroup$ My answer: That's what a proof is for. $\endgroup$ Commented Feb 28, 2017 at 15:13
  • $\begingroup$ @Adam: And then what? In particular, how do you avoid being the arbiter of correct explanations: either you say "okay, that's good enough", or "no, your explanation overlooked a case, here's a counterexample"? (And how does one respond to incorrect explanations of correct conjectures? In other words, what's the difference between a good conjecture and a good explanation?) $\endgroup$ Commented Feb 28, 2017 at 15:50
  • 2
    $\begingroup$ This is why such courses require very careful planning so that students can, in fact, verify their conjectures (if that is in fact your goal). $\endgroup$
    – kcrisman
    Commented Feb 28, 2017 at 16:24
  • 3
    $\begingroup$ This is hardly a useful solution, but if you can find a problem on which students can make conjectures, and you yourself have no idea what might be the correct answer, you can turn a class into interactive work on an open problem. The hard part is identifying such a problem. $\endgroup$ Commented Mar 1, 2017 at 15:22

1 Answer 1


If you absolutely don't want to introduce your students to proof methods yet, I think you should set a clear timeline. Give them a day or two to work on their conjectures (preferably in groups) before bringing them to class. You could look at this as an iterative design problem, where the testing-redesign cycle is out of whack. While an engineer ideally wants their product to be perfect, they'll often settle for something workable if time-to-market is an issue. I'd say give them something workable to shoot for (like: "your fellow students shouldn't be able to find counterexamples within a specified time frame") and something that's a "moonshot" (like: "Your professor shouldn't be able to find counterexamples within a specified timeframe") and then let them loose.

That way, you take yourself somewhat out of the equation and you avoid the "time-sinkiness" that is in my opinion the greatest pitfall of an inquiry-based mathematics approach. To have this as a multi-day group project would also allow the students to engage with their own "mathematical community" or even with larger communities like SX. You could even offer rewards (like extra credit points) for students who are able to stump you or their fellow students.

  • $\begingroup$ I'm in fact thinking of a class where I am introducing students to proof methods (as I think is common in introductory discrete math), but that's rather far from asking them to produce novel proofs on their own. $\endgroup$ Commented Feb 28, 2017 at 23:30
  • $\begingroup$ I'm curious. When you discuss counterexamples, do you discuss them in general terms (as in "here's why this kind of thing is a counterexample") or in specific terms (as in "here's why this particular thing is a counterexample")? $\endgroup$ Commented Mar 1, 2017 at 0:09
  • $\begingroup$ A particular thing. Say, asking students to come up with a conjecture for when a graph has an Euler path, and if they suggest that all vertices have even degree, drawing (say) a line with a few vertices. $\endgroup$ Commented Mar 1, 2017 at 1:29
  • $\begingroup$ Do you think it would be useful to discuss conterexamples in a more general sense? As in: "here's why this particular kind of graph doesn't have an Euler path"? I'm thinking that if you discuss the counterexamples in general terms and if you explicitly discuss student misconceptions, as in: "it seems that you were thinking all vertices must be of even degree" that might help students come up with a more general statement. $\endgroup$ Commented Mar 2, 2017 at 16:07
  • $\begingroup$ Have you found that makes a difference with students at this level? My experience has been that they have no trouble seeing what hidden pattern their examples all had once they've seen one that breaks the pattern. (And I wouldn't call it a "misconception": coming up with examples that don't have hidden patterns is hard, especially without much experience - which is, after all, what I'm trying to help them get.) $\endgroup$ Commented Mar 3, 2017 at 2:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.