Re: Response to Karen and to Willem on recursive proofs
From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 01/22/04
- Next message: Fred J. Smith: "Re: Response to Karen and to Willem on recursive proofs"
- Previous message: Randy Howard: "Re: Mars Rover Controlled By Java"
- In reply to: Willem: "Re: Response to Karen and to Willem on recursive proofs"
- Next in thread: Richard Heathfield: "Re: Response to Karen and to Willem on recursive proofs"
- Reply: Richard Heathfield: "Re: Response to Karen and to Willem on recursive proofs"
- Reply: Corey Murtagh: "Re: Response to Karen and to Willem on recursive proofs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 21 Jan 2004 15:57:53 -0800
Willem <willem@stack.nl> wrote in message news:<slrnc0rnld.30ns.willem@toad.stack.nl>...
> Edward wrote:
> ) The use of the word "terminologies" reifies understanding and means,
> ) literally, that the mathematician becomes a mathematical clerk. The
> ) proof was indeed "inductive" but the problem with calling it
> ) "inductive" as a teacher is that it is then promptly confused with an
> ) *empirical* argument. That's why an alternate description is
> ) "recursive".
>
> I have never heard an empirical proof called 'inductive'.
Well, then, you need to get out more. Induction versus deduction is an
old wheezer from informal logic. Mathematical "induction" was so named
in the later 19th century as a metaphor for scientific induction as
seen in Mill. But those who named it knew full well that it isn't
"empirical", which Mills' induction IS.
>
> ) The increments and decrements are as explicit as hell, for Next
> ) intIndex1 is in effect a command to increment or decrement, context
> ) sensitive with regards to the Step clause.
>
> 'context sensitive' indeed. In other words, implicit.
Yes, C is terribly explicit and most awfully context free. To a fault.
>
> ) Not in Visual Basic. Nor in C to my knowledge. Chalk up a point in
> ) favor of Hungarian Notation!
>
> Don't you use HN to mark the return type of a function, then ?
> I think the people at microsoft do.
Nope, because in an object oriented style, you typically mention the
object and its method as in classname.method. Here, using the class
name will often prompt you, in a development environment, with a small
list of methods and properties and here, using Hungarian gets in the
way. HN is best for value objects as a way of getting the same sort of
facility (variable name prompts) to focus on the identifiers you are
interested in.
>
> ) As a layperson I would have to ask if it is not "hidden" in the max.
> ) Also, I consider my proof more elegant. Even an Intuitionist cannot
> ) get by without recursion and I don't know why delenda est.
>
> Nope, that max is just there because it's possible for n2 to be 0 at the
> beginning. Maybe there's a more elegant way but the last time I did proofs
> of correctness was over 10 years ago.
>
> ) My concern is the use of natural language because as soon as you
> ) formalize something sufficiently and you have at least one computer,
> ) there is an irresistable tendency to want to create, not
> ) knowledge-in-students, but Yet Another programming tool or programming
> ) language which in many cases is destructive of knowledge-in-students.
>
> I find it a great benefit that it's possible to have a machine-assisted
> proof of correctness. Humans make errors, you know.
> Besides, formal maths is less prone to errors anyway.
Hmm, is it? There have been huge errors in formal proofs including the
first edition of the Princeton proof of Fermat's last theorem. Whereas
the breezy, narrative style of the informal proof makes errors easier
to find.
>
> ) Instead they become a mass of claptrap because the connection with the
> ) human world (in the form of insight) has been abandoned in favor of
> ) gear.
>
> I disagree. Especially if you use the language that was designed to be
> used with this method of proving, everything is very clean and visible.
>
> ) Does it work for
> )
> ) int nFactorial(int intN)
> ) {
> ) if (intN < 1) { ... error ... };
> ) if (intN == 1) return(1);
> ) return(nFactorial(intN - 1));
> ) }
>
> Yes, obviously. I'm not sure I remember the formalities exactly, though.
> Could be that this requires something that looks a bit like an inductive
> proof (although not quite, the 'first step' is implicit).
>
The next to last line should be of course
return(intN * nFactorial(intN - 1));
This was a typo and not a "bug".
Recursion is pretty fundamental. While I remain obliged for your
instruction, I am not sure it can be non-recursively applied to the
above.
>
> SaSW, Willem
- Next message: Fred J. Smith: "Re: Response to Karen and to Willem on recursive proofs"
- Previous message: Randy Howard: "Re: Mars Rover Controlled By Java"
- In reply to: Willem: "Re: Response to Karen and to Willem on recursive proofs"
- Next in thread: Richard Heathfield: "Re: Response to Karen and to Willem on recursive proofs"
- Reply: Richard Heathfield: "Re: Response to Karen and to Willem on recursive proofs"
- Reply: Corey Murtagh: "Re: Response to Karen and to Willem on recursive proofs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
