Page 1 of 1

std::find == problem, probably obvious

Posted: Fri Jun 10, 2011 12:55 am
by short
Hey guys, couldn't figure this out before I went to sleep. Probably make more sense in the morning (yawn, finished my last final today!), but if anyone is bored and sees the problem, let me know!


Code: Select all

 //determine if shape contains a point
	inline bool ContainsPoint(const Point2D& point) { 
		return std::find(_relativePoints.cbegin(), _relativePoints.cend(), point)  != _relativePoints.cend() ? true : false; 
	}

Code: Select all

// decleration of _relativePoints
private:
	// array of shape vertices
	Point2D _centralPoint;
	std::vector<Point2D> _relativePoints;
And the Point2D class:

Code: Select all

#ifndef _POINT2D_H_
#define _POINT2D_H_	
class Point2D
{
public:
	explicit Point2D(void);
	Point2D(float x, float y);
	~Point2D(void);

	inline float X() { return _x; }
	inline float Y() { return _y; }

	inline void X(float x) { _x = x; }
	inline void Y(float y) { _y = y; }

private:
	float _x;
	float _y;

};

#endif

Code: Select all

#include "Point2D.h"


// default constructor
Point2D::Point2D(void)
{
	_x = _y = 0.0f;
}

// constructor taking x and y
Point2D::Point2D(float x, float y)
{
	X(x);
	Y(y);
}

Point2D::~Point2D(void)
{
}
// error message

Code: Select all

Error	1	error C2678: binary '==' : no operator found which takes a left-hand operand of type 'Point2D' (or there is no acceptable conversion)	c:\program files\microsoft visual studio 10.0\vc\include\algorithm	41
ty ty ty

Re: std::find == problem, probably obvious

Posted: Fri Jun 10, 2011 2:52 am
by qpHalcy0n
You must define operator== for non-native types.

You want to define the binary operator== for const types since you're using constant iterators. Observe const correctness, lest ye compiler become upset:

Code: Select all

inline float X() const { return _x; }
inline float Y() const { return _y; }
Define binary operator== (however it is you want to equate them)

Code: Select all

bool operator== (const Point2D l, const Point2D r)
{
      // Dont ever compare floats like this...but for purposes of illustration ...here's horrifying code //
      if(l.X() == r.X() && l.y() == r.Y())
           return true;
      return false;
}


Should then be hunky dory.

Re: std::find == problem, probably obvious

Posted: Fri Jun 10, 2011 10:46 am
by short
ty qp, worked beautifully

Here's the final result for anyone else who may do something similar:

Code: Select all

#include <float.h>
#include <cmath>

....

inline friend const bool operator==(const Point2D& l, const Point2D& r) {
		return abs(l.X() - r.X()) < FLT_EPSILON && abs(l.Y() - r.Y()) < FLT_EPSILON;
	}

Re: std::find == problem, probably obvious

Posted: Sat Jun 11, 2011 7:49 am
by Ginto8
I'm curious why you should never use == on floats... Is it because there's more than one bit pattern that can produce the same value?

Re: std::find == problem, probably obvious

Posted: Sat Jun 11, 2011 10:54 am
by qpHalcy0n
No, its because for practical purposes it's significantly unlikely that two discrete calculations that should theoretically yield the exact same value will ever happen. Very significantly unlikely.
You do this in science. If you've taken chem lab or physics lab or what have you, you'll be expected to find and accurately determine measurement inconsistencies and find the standard deviation, standard error and things like that. Failure to account for these can really make your experiment go sour. Same idea here, we can repeat an experiment over and over (SOMETHING will be slightly slightly different every time) the standard deviation MAY be 0.000001 off, but alas that IS off. We can perform two calculations that should theoretically yield the exact same value over and over and over, and we may only be FLT_MIN away (very small), but alas, we ARE off.

For purposes of disambiguity, the programmer has to define an acceptable range of "How close is close enough?" given the scale, repeatability, and so forth.

I have 3 intersecting planes, what's the equation of the line (in float)? I determine the first two intersect with some slope....the third however, is 0.0000001 off. Do they intersect?
The answer is "Yea, probably".

:)