I came across the goog.math.isFiniteNumber function in the Google Closure Library. What it does is checking whether a given number is both finite and not NaN.
The underlying code is:
goog.math.isFiniteNumber = function(num) {
return isFinite(num) && !isNaN(num);
};
So, first it checks whether the number is finite using the native isFinite function, and then does an additional check to make sure the number isn't NaN using isNaN.
However, isFinite already returns false in case the argument is NaN. So, what advantages does the check for isNaN provide?
The only difference is this:
!isNan(1/0) // --> true
isFinite(1/0) // --> false
isNaN checks whether the argument is a number or not. The Infinities (+/-) are also numerical, thus they pass the isNaN check, but don't pass the isFinite check.
** Note that any string which can be parsed as a number ("2", "3.14") will cause isNaN to return false.
Hope this helps.
PS: The answer given by user1170379 was very nearly perfect.
you might reason out [Why?] after reading this:
NaN doesn't check if the passed value is infinite or not - it checks if the input val evaluates into a "Type: Number" end-result. Because isNaN(string) is accepted, so the: isNaN("3.14") //false (which means true, the given token is duck converted into a type Number successfully )
You may understand that the input value may happen to be an unresolved brute number, even a math operation as simple as:
(x/y); which in turn might yield a (+/-infinity) number.
Here x=1, y=0; meaning (1/0).Then isNaN(x/y) will first evaluate to isNaN(1/0); then to
isNaN(infinity) //false. Since (1/0)=infinity is of type: "number" ie typeof(1/0) //"number" isNaN should and will return false.
You don't want to put "infinity" where an end result number is expected.
Probably for the same reason that I have implemented (isfinite(num) && isfinite(-num)) - I was getting errors from mysql complaining about putting "-nan" into the database even though I had a check for isfinite(field)...
A useful article on this subject is http://jacksondunstan.com/articles/983 which provides an optimization ((d*0.0)==0.0)
isNaN() returns true if the argument is not a number or if the argument is a non-numeric value such as a string or an object.Otherwise, It returns false.
Example: isNaN(0/0) =>true;
isNaN(2-1) =>false;
isFinite() returns true if the argument is a number other than NaN,Infinity or -Infinity.Otherwise, It returns false.
Example: isFinite("2000") =>false;
isFinite(200/2) =>true;`
If isFinite worked the way isFiniteNumber did, then there would be no reason to write isFiniteNumber. There's probably some browser out there somewhere that treats NaN as finite.
Related
I ran the below code in JavaScript
let i = 3;
while (i) {
console.log(i--);
}
since the while(i) is not like while(i>0) then I expected the result as 3,2,1,0,-1,-2,...
but the actual result is 3,2,1. Could anyone explain this case to me? I am confused.
The while loop runs until the check condition is false.
In this case, it is the value of i.
Since Javascript is dynamically typed(ie - we don't define the types when defining the variables) the value of i is converted into a boolean from the type it is currently in.
In this case, you are setting numerical values to i. And the number 0 is considered to be falsely. Therefore, breaking the while loop.
You can refer here for a full list of falsely value.
While loops run until its condition is set false. Note that all statements such as while, if and ternaries all handle conditions in the same way. To have a better understanding on how the simplest and quickest way is to test them with ternaries.
I usually run something such as the following on a js console such as chrome (ctrl + j)
1?2:3;
0?2:3;
5?2:3;
"Hello"?2:3;
""?2:3;
And so on. These are conditional statements, the first number is taken as a condition, the second (2) is what will be returned if it were true, and the third (3) is what it will return if it were false. Note that 2 and 3 are just random numbers.
In the example you have shown, i is an integer. For an integer, only 0 is taken as a false.
I've been trying to teach myself Javascript lately and I'm noticing several slightly quirky syntax choices used by various different authors. Usually I can figure them out, but this one's stumped me a bit.
The author of the post here creates an empty object, colors, which will contain a set of properties for each background color in the page. Each color property will have a value equal to the total area covered by that color. To do this, he uses the following syntax:
// ...set or override it in the colors object,
// adding the current element area to the
// existing value.
colors[bgColor] = (colors[bgColor] >> 0) + nodeArea;
At this point, the property named by the value of bgColor may or may not be present in the object. The intent of the expression in the parenthesis is presumably to return the running total or 0 if this is the first time the color is seen. My question is, is this the right shift operator being overloaded and I'm searching for the wrong name, or why does the right shift behave this way?
The intent of the expression in the parenthesis is presumably to return the running total or 0 if this is the first time the color is seen. My question is, is this the right shift operator being overloaded and I'm searching for the wrong name, or why does the right shift behave this way?
It's not overloaded (JavaScript doesn't have operator overloading). It's relying on the fact that undefined >> 0 is 0 and anyNumber >> 0 is anyNumber (caveats to follow). If the property doesn't exist yet, looking it up yields undefined, and so >> 0 turns that into 0. If the property is defined and contains a whole number that fits in 32 bits, >> 0 returns the number without changing it. (If the number has a fractional part, it's truncated, and if it doesn't fit in 32 bits, it's wrapped if I'm reading that right, but I don't think that's what the coder is trying to do.) So by doing that, then adding the area, they are indeed adding to a running total (or initializing it if it isn't there yet).
It's mostly a shorthand version of:
if (colors[bgColor]) {
colors[bgColor] += nodeArea;
}
else {
colors[bgColor] = nodeArea;
}
...(as any falsey value >> 0 is 0) but with the added feature that it will always result in a non-NaN number provided nodeArea is a non-NaN number, whereas with some truthy non-number values for colors[bgColor] ({}, for instance), the "long" version above would result in a string or in NaN.
It is just one of the tricks to avoid an if condition. When you create the property with the value in bgColor, you might do something like this
if (colors[bgColor] === undefined) {
colors[bgColor] = 0;
}
colors[bgColor] += nodeArea;
This is is to make sure that the initial value is 0, if the bgColor is not there in colors, otherwise undefined will be the value. So, to avoid that, if we can convert undefined to 0 we can simply avoid that if condition.
console.log(undefined >> 0);
# 0
So, colors[bgColor] >> 0 will be 0 if bgColor is not already defined, otherwise the actual value as it is, since right shifting by zero doesn't change the actual value.
It might be an attempt to cast the color value as a 32-bit value, since Javascript normally stores all values as IIRC 64-bit floats (with 53 bit precision), but on bitwise operations it treats them as 32-bit integers. This might be an attempt to force the value to be treated as such before adding NodeArea.
I think it also forces it to be interpreted as a Number, but the implicit type of NodeArea would have that effect as well, normally.
edit - T.J. Crowder also makes another point which I tried to find from MDN but didn't: the return value of the operation if the property doesn't exist would be 0, thus setting the value as well). In face his whole post makes a good point :P.
I find the code below , but I can't understand this.
if (!-[1, ] && !window.XMLHttpRequest) {
document.execCommand("BackgroundImageCache", false, true);
}
What does if(!-[1,]) mean ? Thanks
It's a hack to detect old Internet Explorer. -[1,] is -1 in modern browsers (so false with !) but NaN in old IE (true negated). The first version to return correct result is IE9.
That exact code will never yield anything other than false, so it is nonsensical as entered. I assume that this is rendered output and that depending on some serverside variable, it may sometimes be something different.
Seeing as it uses window.XMLHttpRequest, I realize it could also be some poor form of browser check. [1,] creates an array, but the trailing comma will make the array treated differently in Chrome and Internet Explorer. Chrome will recognize this as an array of only one number, which could be implicitly cast to a number, whereas IE will consider it to be an array containing two items, which can't be cast to a number.
-[1,0] will yield NaN in all browsers. -[1] will yield -1 in all browsers. Hence -[1,] will yield NaN in IE (and hence execute the code), and -1 in other browsers (and not execute the code).
This is a terrible hack. Don't use it.
If you want to find out whether window.XMLHttpRequest will work, test for that specifically, and not for anything else.
This is particularly bad code:
-[1, ] Results to the number -1.
!-[1, ] would always be false.
Since the [] implies an array, this is bad, cause if you had more than one value in that array, the - would give you a NaN.
long story short, i was trying to validate a phone field. ive added
the isNaN and parseInt for checking the " " in the field but that said
This below never validates to true..what am i missing?
if(isNaN(parseInt(phone))){
error.text("Sorry but this phone field requires numbers only");
return false;
} else {
return true;
}
it always fails...it never reads true even when i enter a number in the field and submit.
i always get the error mssg.
EDIT: I am testing input values from a form, phone is the name of the field.
Various ways to coerse JS strings to numbers, and their consequences:
(source: phrogz.net)
I personally use *1 as it is short to type, but still stands out (unlike the unary +), and either gives me what the user typed or fails completely. I only use parseInt() when I know that there will be non-numeric content at the end to ignore, or when I need to parse a non-base-10 string.
Edit: Based on your comment, if using phone.val() fixed it then
You were using jQuery (which you never mentioned, and should have), and
You actually had/have a jQuery object, wrapping one or more DOM elements (probably just one).
Whenever you do var foo = $('…'); then the foo variable references a jQuery object of one or more elements. You can get the first actual DOM element from this via var fooEl = foo[0]; or var fooEl = foo.get(0);…but even then you still have a DOM element and not a particular property of that.
For form inputs, you need to get the .value from the DOM element, which is what the jQuery .val() method does.
parseInt is a bit odd at times:
> parseInt("123-456-789")
123
Fortunately you can probably solve your case with:
> Number("123-456-789")
NaN
parseInt only returns NaN if the first character cannot be converted to a number.
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/parseInt
I've seen Number() suggested, but that will still allow things like -21 or 123.456. The best way to check for the absence of non-digits in a string is like this:
function hasNonDigit(str){
return /\D/g.test(str.toString());
}
console.log(hasNonDigit("123-456-7890"));
console.log(hasNonDigit("1234567890"));
This question already has answers here:
Why does a RegExp with global flag give wrong results?
(7 answers)
Closed 6 years ago.
I have code similar to this filtering entries in an Array of Objects:
var filterRegex = new RegExp(".*blah.*","ig");
if (filterRegex.test(events[i].thing) && events[i].show) {
console.log("SUCCESS: filtering thing " + i + " " + events[i].thing);
events[i].show = false;
numevents--;
}
I get inconsistent results with this if condition (checking with Firebug, both conditions are true individually, but sometimes the whole expression evaluates to false). HOWEVER, if I actually put an alert() called inside this if statement (like line 4), it becomes consistent and I get the result I want.
Can you see anything wrong with this logic and tell me why it's not always producing what is expected?
Ok, i see it now. The key to your problem is the use of the g (global match) flag: when this is specified for a regex, it will be set up such that it can be executed multiple times, beginning each time at the place where it left off last time. It keeps a "bookmark" of sorts in its lastIndex property:
var testRegex = /blah/ig;
// logs: true 4
console.log(testRegex.test("blah blah"), testRegex.lastIndex);
// logs: true 9
console.log(testRegex.test("blah blah"), testRegex.lastIndex);
// logs: false 0
console.log(testRegex.test("blah blah"), testRegex.lastIndex);
The above example creates an instance of a very simple regex: it matches "blah", upper or lower case, anywhere in the string, and it can be matched multiple times (the g flag). On the first run, it matches the first "blah", and leaves lastIndex set to 4 (the index of the space after the first "blah"). The second run starts matching at the lastIndex, matches the second blah, and leaves lastIndex set to 9 - one past the end of the array. The third run doesn't match - lastIndex is bogus - and leaves lastIndex set to 0. A fourth run would therefore have the same results as the first.
Now, your expression is quite a bit more greedy than mine: it will match any number of any characters before or after "blah". Therefore, no matter what string you test on, if it contains "blah" it will always match the entire string and leave lastIndex set to the length of the string just tested. Meaning, if you were to call test() twice, the second test would always fail:
var filterRegex = /.*blah.*/ig;
// logs: true, 9
console.log(filterRegex.test("blah blah"), filterRegex.lastIndex);
// logs: false, 0
console.log(filterRegex.test("blah blah"), filterRegex.lastIndex);
Fortunately, since you create your regex immediately prior to calling test(), and never call test() more than once, you'll never run into unexpected behavior... Unless you're using a debugger that lets you add in another call to test() on the side. Yup. With Firebug running, a watch expression containing your call to test() will result in intermittent false results showing up, either in your code or in the watch results, depending on which one gets to it first. Driving you slowly insane...
Of course, without the g flag, livin' is easy:
var filterRegex = /.*blah.*/i;
// logs: true, 0
console.log(filterRegex.test("blah blah"), filterRegex.lastIndex);
// logs: true, 0
console.log(filterRegex.test("blah blah"), filterRegex.lastIndex);
Suggestions
Avoid the global flag when you don't need it.
Be careful what you evaluate in the debugger: if there are side effects, it can affect the behavior of your program.
I just can't imagine there is any situation where two JavaScript expressions evaluate to true individually, but not when combined.
Are you sure both expressions actually produce a boolean value every time? (Okay, to make regex.test() not produce a boolean value is difficult, but how about event.show. Might that be undefined at times?
Do you refer to the correct index when saying event[0].show, wouldn't you mean event[i].show?
That's seems you are facing some kind of race conditions with the event array, that's why when you use the alert() everything works fine.