POV-Ray : Newsgroups : povray.off-topic : An explanation of what next_permutation does : Re: An explanation of what next_permutation does Server Time
4 Sep 2024 23:20:08 EDT (-0400)
  Re: An explanation of what next_permutation does  
From: Invisible
Date: 7 Dec 2009 04:50:09
Message: <4b1ccfd1@news.povray.org>
>> I *already* know that * is pointer dereference and -- is decriment. 
>> But now I have to sit here and wonder "is that pre-decriment or 
>> post-decriment?
> 
> Like I have to sit and wonder why it's (suffix,prefix) and not 
> (prefix,suffix) in your example?

No specific reason. I probably did it that way around because "split" 
takes the list in reverse order. (Working from the back towards the 
front is inefficient for a single-linked list, so I reversed the list so 
it can be processed from front to back instead.) Technically you could 
return the sublists either way around if you wanted. I just did it this 
way because if you take (x, y) and do x ++ y, you get the original 
(backwards) list. If you'd returned the components the other way around, 
you'd have to do y ++ x instead.

>> And in why is it 'not (x < y)" rather than 'x >= y'?"
> 
> Aren't they the same?

You'd certainly think so.

> (btw the only reason I can see that you would use 
> the first one is if the types being used don't have the >= operator 
> defined). IIRC quite a lot of functions and libraries only assume that 
> one of those operators is implemented, so that's probably why you'll see 
> stuff like that.

Hmm, I see.

Of course, we're working with *digits* here, for which both operators 
are definitely defined. However, it seems this part of the code is from 
a library, so presumably it's supposed to work with anything.

(In Haskell, it is impossible to define one ordering relation without 
also defining the others. Well, no, not impossible, but you'd have to 
purposely go out of your way to do it. So in Haskell it's not something 
a library needs to worry about it. But now I recall that in C++, these 
are all seperate, notionally unrelated operators.)

>> And similar questions. (Why "for (;;)" rather than "while true"? Is 
>> there some difference?)
> 
> Not that I'm aware of.

It's like when a Haskell programmer writes a new function that's 
equivilent to an existing one. You have to sit there and wonder why they 
did that. Was it personal taste, or is there actually some subtle 
difference you've missed?


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.