Re^6: Best Hash Practices?

I think there is a better example than 0.0, 0E0.

I don't see why. Everything you said about "0E0" applies to "0.0".

Folks using the DBI should be aware of this 0E0 stuff.

Totally irrelevant. "0E0" is not the exception, "0" is. All strings are true except for "0". You hadn't mentioned "0". It's rather important because I often see people think "The var can either be a string or undef, so a simple truth test will differentiate the two."

Comment on Re^6: Best Hash Practices?

Replies are listed 'Best First'.
Re^7: Best Hash Practices? by Marshall (Canon) on Oct 12, 2009 at 00:01 UTC
When I said, Your point about 0.0 is well taken. That meant that you are correct about 0.0. Quite correct, an omission on my part. The reason why I mentioned the 0E0 case is: If I write code that can return a float like 0.001 or 0.0 (or a string that represents a float), usually the logical test is gonna involve more that just: if ($var), the test will have some `>= or <=` operators that will force the $var comparison into a numeric context and the "if" test is upon that numeric comparison. Often a range of values to decide that the number is "close enough" to be considered zero for this application's purposes. However, I could imagine some application where the test is a regex. 0E0 is a bit different in that this value is returned when an integer is expected. I have no idea of what say 0.5 of a DBI result would be! So the reason for the mention is that this is a common value from the DBI and therefore there more chance for a coding mistake. if ($num_results) just says that the operation succeed, to find out how many results, if ($num_results >0) would be more appropriate. Probably both tests are needed to decide that "operation worked" and "returned no results". I didn't think that 0E0 was totally irrelevant. When I said: But it seems that we have tripped over something in a different direction. Folks using the DBI should be aware of this 0E0 stuff. I was trying to re-enforce your point with a common situation in DBI code that may trip up some folks who would otherwise nonchalantly navigate the floating point comparison pitfalls. I don't intentionally use T/F comparisons of (000.000) float values and figured that situation is much less common than this strange "integer" return from the DBI. Thanks for your addition of 0.0. It was correct and helpful.	[reply] [d/l]

Replies are listed 'Best First'.

Re^7: Best Hash Practices?
by Marshall (Canon) on Oct 12, 2009 at 00:01 UTC

Your point about 0.0 is well taken.

The reason why I mentioned the 0E0 case is: If I write code that can return a float like 0.001 or 0.0 (or a string that represents a float), usually the logical test is gonna involve more that just: if ($var), the test will have some >= or <= operators that will force the $var comparison into a numeric context and the "if" test is upon that numeric comparison. Often a range of values to decide that the number is "close enough" to be considered zero for this application's purposes. However, I could imagine some application where the test is a regex.

0E0 is a bit different in that this value is returned when an integer is expected. I have no idea of what say 0.5 of a DBI result would be! So the reason for the mention is that this is a common value from the DBI and therefore there more chance for a coding mistake. if ($num_results) just says that the operation succeed, to find out how many results, if ($num_results >0) would be more appropriate. Probably both tests are needed to decide that "operation worked" and "returned no results".

I didn't think that 0E0 was totally irrelevant. When I said: But it seems that we have tripped over something in a different direction. Folks using the DBI should be aware of this 0E0 stuff. I was trying to re-enforce your point with a common situation in DBI code that may trip up some folks who would otherwise nonchalantly navigate the floating point comparison pitfalls. I don't intentionally use T/F comparisons of (000.000) float values and figured that situation is much less common than this strange "integer" return from the DBI.

Thanks for your addition of 0.0. It was correct and helpful.

[reply]
[d/l]