Jump to content

  • Log In with Google      Sign In   
  • Create Account

Brother Bob

Member Since 26 Nov 2001
Offline Last Active Today, 08:41 AM

Posts I've Made

In Topic: how good is rand() ?

04 May 2016 - 01:05 PM

 

 

"The rand function returns a pseudorandom integer in the range 0 to RAND_MAX (32767). "  so it returns 0 thru 32766, but not 32767, right?

 

Correct.  In modern math notation this type of function works with [0,x)  meaning it includes zero but stops just short of x.  This is also common in many other systems.  Graphics, for example, typically draw segments in the [A,B) form, starting exactly at A and ending the instant before B.

 

 

I tried this in VS2015 and it does return RAND_MAX.. is it not supposed to?

#include <iostream>
int main() {
	for(int i = 0; i < 200000; ++i) {
		int r = rand();
		if(r == RAND_MAX)
			std::cout << "MAX\n";
		else if(r == (RAND_MAX - 1))
			std::cout << "ALMOST\n";
		else if(r == 0)
			std::cout << "ZERO\n";
	}
}

The range for both rand() and the <random> library (at least the uniform integer distributions when comparing with rand) are inclusive at both ends. The range is therefore [0, RAND_MAX], not [0, RAND_MAX). This is different from, for example, iterator ranges in the standard library which are half-open.


In Topic: Generate this kind of 2d burst or pulse

28 April 2016 - 12:52 PM

Don't post in multiple forums, your other posts have been removed. If you want it in some other sub-forum then ask a moderator to move it instead.


In Topic: Template-related compiler bug or... ?

14 April 2016 - 04:57 AM

That may explain why I was surprised there wasn't much information about it. It's in VS 2013 at least where I tried it, but if it was actually removed then it should be fairly easy to make the necessary types to handle the particular problem raised in this thread.

template<typename T>
struct identity {
    using type = T;
};

The idea of making the second parameter a non-deduced one still applies.


In Topic: Template-related compiler bug or... ?

14 April 2016 - 03:25 AM

 

There's a few other ways to write that function, but that's probably the least crazy.

 

A third and not-so-crazy option is to make the type of the second parameter a non-deduced type.

#include <type_traits>
 
Foo<T>& operator*=(Foo<T>& left, typename std::identity<T>::type right) {
    ...
}

Passing the type through a dependent type like that excludes that T from the deduction process. The parameter instead participates in conversion once the actual type has been resolved.


In Topic: Opengl culling confusion

25 January 2016 - 04:45 PM

Assuming that "top" point upwards, the quad (A, EndA, EndB, B) is clockwise, since if you look at it from above face the vertices are in clockwise order. If you rotate the cube slightly around the X-axis so that the "bottom" face is visible, you'll see that (EndD, EndC, C, D) is counter clockwise if you look at it from below. Thus, the "bottom" and the "top" face of that cube has inconsistent winding order.

 

Two faces with the same winding order that shares and edge between two vertices must share that edge in opposite order. For example if "front" has the edge from A to B (in that order) then "top" must connect from B to A. And, indeed, that is the case; the last vertex B in your list connects back to the first vertex A. However, this is not the case for the "bottom" face and the edge between C and D; both the "front" and the "bottom" face shares the edge from C to D in the same direction and therefore they have different winding orders.


PARTNERS