Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Ben Bacarisse Newsgroups: comp.programming Subject: Re: A little puzzle. Date: Fri, 02 Dec 2022 00:22:08 +0000 Organization: A noiseless patient Spider Lines: 57 Message-ID: <87pmd28xjj.fsf@bsb.me.uk> References: <875yf8nijb.fsf@bsb.me.uk> <865yf79l66.fsf@linuxsc.com> <87wn7nj9mb.fsf@bsb.me.uk> <86sfi98xnx.fsf@linuxsc.com> <87leo1i5bo.fsf@bsb.me.uk> <86k03k7yqe.fsf@linuxsc.com> <87o7stisxy.fsf@bsb.me.uk> <875yf1i26r.fsf@bsb.me.uk> <86wn7b5mru.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: reader01.eternal-september.org; posting-host="42a5a6e0e897a4a4d4e38b1b1c71530b"; logging-data="3054298"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19nTkxZW8LTqnwgTPrYmpKgtQXDHCi2akA=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cancel-Lock: sha1:7rJXSOp47Z/Xk3qMxAEapj0eTTU= sha1:oMw+Haz1q9893b+3kDT4kHczkGc= X-BSB-Auth: 1.884fead00d1014a89e80.20221202002208GMT.87pmd28xjj.fsf@bsb.me.uk Xref: csiph.com comp.programming:16022 Tim Rentsch writes: > Ben Bacarisse writes: > >> "Dmitry A. Kazakov" writes: > > [...] > >>> function Flight_East_Crosses_Longitude >>> ( Start, Stop, X : Longtitude >>> ) return Boolean is >>> begin >>> if Start <= Stop then >>> return X in Start..Stop; >>> else >>> return X <= Stop or else X >= Start; >>> end if; >>> end Flight_East_Crosses_Longitude; >> >> Except for some boundary cases [ie, the region being half open] that >> have got lost in the telling, this is similar to Tim's solution. I >> chose to use a recursive call, because I though it explained the >> non-trivial case more clearly (but I bet I am pretty much the only >> one who thinks that). > > I want to add something here to my earlier comment. The idea of > using a recursive call reflects a deeper understanding of what > "circular regions" are. If one has already assimilated that > understanding then I think the recursive call is "more obvious", > in the sense that it takes less thought, or I might say less > additional thought. I didn't have that background (and didn't > develop it while solving the problem) so for me the cruder but > more direct approach was easier to see. Bottom line, I don't > think either formulation is uniformly "easier to understand" than > the other; it depends on one's background (or ability to develop > a suitable understanding on the fly, which in this case I did not > possess). For me, the negated recursive call was a sort of "ah ha!" moment. I was ploughing forwards trying to work out this and that case when a light-bulb went off. Above I say "it explained the non-trivial case more clearly" but that's lazy wording and does not capture what I meant. Rather than explaining anything, I want code that is easy to verify. I want, with just a little thought, to know it's right. > This problem provides an example where it helps to see both > approaches to solving the problem, to see how they relate to each > other, but also to give an appreciation for the power of having > more advanced tools available in the mental toolbox. I've got rather fond of it as a question. I don't conduct any interviews anymore or I would be tempted to use it. -- Ben.