Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


isNearZero( Vector)


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Aliii   Members   -  Reputation: 1448

Like
0Likes
Like

Posted 23 April 2013 - 10:04 PM

How do you check that a vector is so short that it should be considered as null? Like when calculating cross-product or scalar product of 2 vectors ...when do you consider the result null, so the 2 vectors are parallel or perpendicular? etc. Should it depend on the length of the input vectors?

 

Now I just check all 3 coordinates if all of them are between a -eps and +eps value. And what should this epsilon value be in general, ...that I use for telling if a number is "zero" or not? Should it be different for 4 and 8 byte float/double? Thanks!



Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 9262

Like
0Likes
Like

Posted 24 April 2013 - 04:33 AM

Well, first, why do you need such a function? These kinds of manipulations usually hide a deeper design problem which means your code is fragile. Ignoring that, as for using epsilons, it seems to be a reasonable approach, and provided you don't lose any precision (dot and cross products are only multiplications and additions so it should be fine) then you could use 1e-6 for floats and 1e-13 for doubles (I'm sure you can push it a bit farther and I have no idea what the ideal value is but it's worked pretty well for me so far in most cases). Due to the nature of floating-point arithmetic I don't think there is an ideal epsilon value, actually, it depends on the input values..


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 Aliii   Members   -  Reputation: 1448

Like
0Likes
Like

Posted 24 April 2013 - 03:22 PM

These kinds of manipulations usually hide a deeper design problem which means your code is fragile

 

Thanks! Yes, ...thats my philosophy too but I prefer throwing assert messages and write logs, instead of seeing that the geometry blew up or disappeared:)



#4 Trienco   Crossbones+   -  Reputation: 2223

Like
1Likes
Like

Posted 24 April 2013 - 10:21 PM

If it's just for assertions, why pepper the code with a ton of if's, instead of just doing "return dot(v,v) < eps"? I'd imagine a dot product and one comparison to be not just shorter and easier to read, but also a good bit faster. Only thing to keep in mind is that this returns the squared length, but that shouldn't really matter much.


f@dzhttp://festini.device-zero.de




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS