Underscore: __.isNumber(NaN)는 true를 반환합니다.

당신 말이 맞아, 그것은 의도적이다. 그리고 그것을 명시적으로 언급할 필요는 없다고 생각합니다. IEEE 754 부동 소수점으로 작업한 적이 있는 사람은 NaN 가 또 다른 부동 소수점 값이라는 것을 알 것입니다.

관련: #321의 토론

질문의 요점은 일반적인 웹 작업을 수행할 때 isNumber라는 함수가 발견된 값이 "이것이 숫자입니까?"라는 일반적인 사용자 정의에 응답하는지 확인하는 좋은 방법인 것 같습니다.

또한 계산을 방해하는 값을 식별하는 데 도움이 되도록 NaN 값이 처음 도입된 것 같습니다. 스펙상 "이게 숫자야?" 라고 물으면 정답인 것 같다. 사실 "숫자가 아님"입니다. 이 질문에 대한 대답이 사실이기를 원하는 일반적인 예를 말할 수 있다면 지금 입 다물겠습니다. :)

JS를 아는 사람들이 이미 알고 있어야 할 isFinite 찾고 있습니다.

좋아, 나는 간단한 문제로 시작했다. 문자열, 숫자 및 가능하면 NaN인 입력이 있습니다. parseInt 및 isFinite를 사용하여 parse int가 성공하는지 테스트하는 기본 JavaScript에 간단한 솔루션이 있습니다. 단순하지만 완전히 깨끗하지 않거나 내 목표를 설명하지 않습니다. 그래서 저는 이러한 종류의 작업을 수행하기 위해 완전히 멋진 goto 라이브러리를 사용하기로 결정했습니다. 초기 검사에서 값을 취하고 그것이 숫자인지 알려주는 함수를 찾았습니다. 이 함수는 일반적인 정의에 따라 제가 원하는 것이라고 생각합니다.

첫째, 이것으로 문서에 한 줄을 추가하면 라이브러리 사용자가 처음 작업에 적합한 기능을 얻는 데 어떻게 도움이 되는지 알 수 있습니까? 둘째, 이것이 의미 있는 예를 다시 묻습니다.

언어에 대해 알아야 할 모든 것을 알고 있는 것처럼 들립니다. 따라서 8학년 동생이 나에게 줄 수 있는 어두운 솔루션에서 맹목적인 방법을 사용하는 것보다 멋진 문서를 통해 나머지 사람들을 교육하는 데 일부를 사용할 수 있다면 좋을 것입니다. 시간 내 주셔서 감사합니다.

@jashkenas의 생각이

첫째, 이것으로 문서에 한 줄을 추가하면 라이브러리 사용자가 처음 작업에 적합한 기능을 얻는 데 어떻게 도움이 되는지 알 수 있습니까?

아마도, 확실히.

둘째, 이것이 의미 있는 예를 다시 묻습니다.

[[클래스]] == "숫자"에 대한 테스트? 그것은 분명해야합니다. 숫자와 일치합니다. 아마도 그것들은 자연수나 정수, 유한수, 실수, 유리수 또는 여러분이 기대했던 부분집합이 아닐 수도 있지만, 그것들은 분명히 모두 숫자입니다.

그렇긴 하지만 문서에 너무 많은 보풀을 추가하면 해로울 수 있는 경우가 있습니다. 하지만 지금이 그런 시기 중 하나는 아니라고 생각합니다. 이것은 현재 상태에서 숫자의 추상적인 개념에 대해 상충되는 해석을 가지고 있는 개발자에게 잠재적으로 도움이 될 수 있습니다. 귀하의 경우와 같이 테스트하려는 세트의 멘탈 모델을 이미 설정한 다음 해당 테스트를 수행하기 위해 _나타난_ 함수를 찾았습니다. +1 , 여전히 @jashkenas가 생각하는 것에 관심이 있습니다.

예 -- NaN 전달될 때 _.isNumber 가 true 또는 false 를 반환하는지 여부는 전혀 분명하지 않습니다. 나는 그것을 시도하지 않고 확실히 기억하지 않을 것입니다. 위 커밋의 문서에 메모를 추가했습니다. 감사 해요.

고마워 얘들아. 다른 누군가가 이와 같은 문제를 겪지 않을 수 있다는 사실을 알게 되어 기쁩니다.

이것은 의미론이 기술적 사실보다 우선해야 하는 경우인 것 같습니다. 예, NaN은 일부 사양에 따라 숫자일 수 있습니다. 그러나 내가 "당신은 번호입니까?"라는 질문을하면 "나는 숫자가 아닙니다"라고 하면 믿어야 합니다. Not Number – NaN – 은 확실히 숫자가 아니며 isNumber는 false를 반환해야 합니다.

사람이 이해할 수 있도록 수정하는 대신 Gotcha를 문서에 넣으면 코딩 시간이 줄어들고 문서를 살펴보는 데 시간이 더 걸립니다.

이것을 재고해 주시겠습니까?

@contentfree : NaN 는 float의 멤버입니다. JS의 모든 숫자는 부동 소수점입니다. 나는 그것이 NaN 를 그들이 얻는 만큼 숫자로 만든다고 생각합니다. NaN 는 "나는 숫자가 아닙니다"를 의미하지 않습니다. 숫자가 아닌 것을 숫자로 표현한 것입니다. 내 책에서 케이스가 닫혔습니다. NaN / Infinity / -Infinity 가 아닌 숫자를 테스트하려면 isFinite 사용하십시오.

죽은 말을 이기기 위해서가 아니라...

왜 그냥하지
obj instanceOf Number

자바 스크립트 사양에 이미 존재하는 필요한 작업을 수행하는 더 읽기 쉬운 방법이 있는 경우 알려지지 않은(조사하는 데 시간을 낭비하지 않는 한) 라이브러리가 있는 라이브러리를 사용하지 않고 그렇게 할 것입니다.

나는 이것을 의미상 올바르도록 수정하지 않으려면 라이브러리에서 불필요한 오버헤드와 골칫거리를 제거해야 한다고 투표합니다.

instanceof 연산자는 프리미티브가 아닌 객체에 대해서만 작동합니다: new Number(5) instanceof Number == true; 5 instanceof Number == false . 또한 브라우저의 프레임 간에는 작동하지 않습니다. [[Class]] 를 통해 확인 Object::toString 입니다 일반적으로 인정 된 자바 스크립트에서 가장 신뢰할 수있는 유형의 확인 방법이 될 수 있습니다.

라이브러리를 더 유용하게 만들고 같은 경우에 JavaScript를 처음 사용하는 사용자를 교육하는 데 +1입니다.

제안:
_.isNumber(객체, [isFinite]);

이것은 isFinite가 아마도 당신이 처음에 추구했던 것이었음을 배우는 동안 이 문제에 걸렸을 때 현재 구현에 true를 간단하게 추가할 수 있게 해줍니다.

내 2c

@nickl- 흥미로운 아이디어지만...이 경우 단순히 isFinite 를 사용하지 않는 이유는 무엇입니까?

또는 _.isNaN 이미 존재하므로 대칭을 위해 _.isFinite 추가할 수 있습니다.

_.isFinite = function (value) {
  return value > -1 / 0 && value < 1 / 0;
};

@kitcambridge

내가 예상하는 유일한 문제는 문자열이 유한한 "0x0", "0xF", "2" 등으로 전달된다는 것입니다. 따라서 무엇이든 _.isNumber 또는 이에 상응하는 것과 결합해야 합니다.

_.isFinite = function (obj) {
  return obj > -1/0 && obj < 1/0 && _.isNumber(obj);
};

숫자 테스트에 val === +val을 사용하여 5개의 문자를 줄일 수 있습니다.

_.isFinite = function (obj) {
  return obj > -1/0 && obj < 1/0 && obj === +obj;
};

@octatone 물론, 제 생각에는 그게 공평하다고 생각합니다...기술적으로 이러한 문자열은 숫자 비교에 사용할 수 있기 때문에 _are_ 유한하지만(인터프리터는 숫자로 강제해야 함) 제안한 제안이 기존 Underscore 유형 검사 기능과 더 일치합니다.

기존 _.isValidDate와 인라인이고 isFinite 인수를 혼동하지 않는 _,isValidNumber는 어떻습니까?

@nickl-

NaN 및 Infinity _are_ 유효한 숫자입니다. 이 함수의 이름을 isValidNumber로 지정하면 그 목적이 혼동될 수 있다고 생각합니까? 아니면 isNumber를 isValidNumber로 이름을 바꾸라는 뜻입니까?

NaN 및 Infinity _are_ 유효한 숫자입니다. 이 함수의 이름을 isValidNumber로 지정하면 그 목적이 혼동될 수 있다고 생각합니다.

나는 동의한다.

이름바꾸라는 말은 안했는데...

저도 _.isNumber(NaN) === true 알고 놀랐습니다.

나는 @contentfree의 https://github.com/jashkenas/underscore/issues/406#issuecomment -4144992에 동의하는 경향이 있다고 생각합니다. 소프트웨어 엔지니어링에서 우리는 이 특정한 경우에 대한 원칙을 가지고 있습니다: 최소 놀라움의 원칙 . ;-)

그리고 많은 사람들이 이것에 대해 혼란스러워하는 것을 본 후, 하드 코어 js 코더가 아닌 사람들이 이름을 볼 때 수행할 것으로 기대하는 기능을 수행하도록 하는 것이 합리적이라고 생각합니다.

내 작은 2¢...™

_.isNaN 도 혼란스럽습니다. 문서에서:

참고: 이것은 기본 isNaN 함수와 동일하지 않으며, undefined와 같은 다른 많은 숫자가 아닌 값에 대해서도 true를 반환합니다.

정상적인 의미에서 undefined 는 실제로 Not-A-Number입니다.

나는 의미론적 구성성에 투표합니다. isNumber == Not a number lol. 부동 소수점 값 확인에 대해 자세히 설명해야 하는 경우 다른 방법을 사용하시겠습니까?

나는 의미론적 건설성에 투표한다.

아니, -Infinity , Infinity , & Object(2) 처럼 [[Class]] 의 숫자입니다. 함수도 객체인 것처럼 개발자가 배우는 것 중 하나입니다. 이 방법의 범위를 벗어나는 번호에 대해 어떤 형식의 유효성 검사를 원할 가능성이 있습니다. 예를 들어 -1 보다 크거나 Math.pow(2,32) 보다 작거나 정수입니다. -Infinity , Infinity 또는 NaN 경우 _.isFinite 를 유효성 검사기로 사용합니다. 마찬가지로 _.isDate 는 날짜 개체가 유효한 날짜를 나타내는지 확인하지 않습니다.

"see also: isFinite" 및 "see also: «어떤 것이 실제로 사용할 수 있는 숫자 값인지 결정하는 방법을 열거하는 에세이»"로 문서를 업데이트하는 것은 어떻습니까?

@michaelficarra 사양에서 NaN이 숫자 유형

우리 대부분이 알고 싶어하는 것은 대부분의 경우 이것을 기본 산술에 사용할 수 있느냐는 것입니다. 따라서 isNumber(x) && isFinite(x)로 이동해야 합니다. 그리고 괜찮습니다. 그러나 이것은 새로운 프로그래머에게 큰 문제이고 잘 읽히지 않습니다.

엄격한 영어 관점에서 isNumber라는 테스트에서 true를 반환하는 Not a Number(NaN)는 전혀 의미가 없습니다. isNumeric 또는 isNumericType이라는 이름이 더 낫지 않을까요?

나는 이것이 버그를 추가하고 많은 시간을 낭비할 것이라는 데 의심의 여지가 없습니다.

따라서 isNumber(x) && isFinite(x)로 이동해야 합니다.

최근에 ES6 Number.isFinite 를 따르도록 _.isFinite 구현을 정렬했습니다.
값이 숫자 프리미티브이고 유한하며 이 일반적인 경우를 처리해야 합니다.

다른 [[Class]] 검사 방법과 일치하는 _.isNumber 의 동작을 변경할 필요가 없습니다.

엄격한 영어 관점에서 isNumber라는 테스트에서 true를 반환하는 Not a Number(NaN)는 전혀 의미가 없습니다. isNumeric 또는 isNumericType이라는 이름이 더 낫지 않을까요?

유효성 검사, _.isNumber 및 _.isDate 에 대한 내 의견을 참조하십시오.

@jdalton _.isDate로 동작이 일정하다는 것은 맞습니다. 그리고 여러분은 밑줄을 사용하여 훌륭한 작업을 수행하므로 결정은 전적으로 여러분에게 달려 있다고 생각합니다.

그러나 숫자가 아닌 것이 숫자라는 것은 너무 직관적이지 않은 것 같습니다.

@Walms 100% 동의합니다. 이 경우 프로그래머와 직관이 NaN이 _기술적으로_ 숫자인 진술의 절대적인 "정확성"을 무시해야 한다고 생각합니다.

그러나 숫자가 아닌 것이 숫자라는 것은 너무 직관적이지 않은 것 같습니다.

그 상황에서, 그것은보다 더 카운터 직관 _.isNumber 복귀 true , 수 개체 Object(2) 타입의 것을 object ?

[[Class]] 메소드입니다. 문서에서 더 명확하게 설명해야 할 수도 있습니다.

나는 이미 _.isFinite 가 ES6 Number.isFinite 따르도록 하는 실행 가능한 대안을 제안했습니다. 기본 is-number 를 원하면 typeof x == 'number' . 값이 NaN , Infinity 또는 -Infinity , 모든 [[Class]] of Number 가 아닌지 확인하려면 _.isFinite 는 갈 길입니다.

더 세분화된 숫자 방법에 대해서는 underscore-contrib 를 참조하십시오. _.isNumeric , _.isInteger , _.isZero , _.isEven , _.isOdd , _.isFloat , _.isNegative , & _.isPositive .

@jdalton 마지막 두 댓글이 왜 이것이 혼란스럽다고 생각하는지 명확히 하는 데 도움이 되었다고 생각합니다.

나는 처음에 _.isNumber가 유형 검사라는 것을 의미하는 is가 접두사로 붙었다는 사실로 인해 컨텍스트가 주어진다는 것을 알지 못했습니다. 이 컨텍스트를 사용하면 _.isNumber가 NaN에 대해 false를 반환하는 것은 의미가 없습니다.

그러나 underscore-contrib 및 isFinite는 이 컨텍스트를 깨는 것 같습니다. 처음에는 is로 시작하지만 유형보다는 가치를 찾고 있습니다. 그리고 여기에서 함수 이름에서 컨텍스트를 결정할 수 있는 명확한 방법이 없다는 것이 혼란스럽다고 생각합니다.

이 모든 것은 내가 이것을 고칠 방법이 없다고 말했습니다.

여기서 문제는 Numbers에 대해 직관적이지 않은 몇 가지 사항이 있다는 것입니다. 그러나 그들은 일관된 방식으로 행동합니다. 이 경우 _.isNumber 덜 일관성 있게 만들어 더 직관적으로 만들 수 있으며, 결국 다른 경우에는 덜 직관적이 됩니다.

다음은 몇 가지 구체적인 예입니다.

# If you add two Numbers together you always get another Number back
# This function should always return true no matter what you pass it
closedUnderAddition = (a, b) -> !isNumber(a) || !isNumber(b) || isNumber(a + b)

closedUnderAddition(1,1) == true
closedUnderAddition(Number.MAX_INT,2**970) == true # false if isNumber checks finiteness

# If you divide two Numbers you always get another Number back
closedUnderDivision = (a, b) -> !isNumber(a) || !isNumber(b) || isNumber(a / b)

closedUnderDivision(1, 2) == true
closedUnderDivision(1, 0) == true # false if isNumber checks finiteness
closedUnderDivision(0, 0) == true # false if isNumber checks finiteness or NaN-ness

# Anything you cast to a Number is a Number
castsToNumber = (x) -> isNumber(Number(x))

castsToNumber(1) == true
castsToNumber(Infinity) == true # false if isNumber checks finiteness
castsToNumber("bees") == true # false if isNumber checks finiteness or NaN-ness
castsToNumber("3") == true

마이클피카라가 말했듯이:

NaN은 "나는 숫자가 아닙니다"를 의미하지 않습니다. 숫자가 아닌 것을 숫자로 표현한 것입니다.

또는 달리 말하면 "숫자"와 숫자가 있습니다. NaN은 "숫자"가 아닐 수도 있지만 Infinity, -Infinity 및 -0과 같은 우스꽝스러운 것과 함께 절대적으로 숫자입니다. 그러나 거칠고 털털한 것처럼 Number의 정의는 잘 지정되고 일관되게 행동합니다.

반면에 "숫자"는 대화 상대 에 따라 위의 항목 중 일부를 포함하거나 포함하지 않을 수 있으며 숫자 문자열, bool, 자정 및 모든 종류의 것을 포함할 수 있는 잘못 정의된 개념입니다. 괜찮습니다. 하지만 모든 사람의 정의를 따르는 솔루션은 절대 없을 것입니다.

그런 이유로 이것이 본질적으로 문서 문제라고 생각합니다.

또한 "숫자"가 다른 사람의 단어처럼 보이지 않습니까?

좋은 지적, @sgentle. 나는 직관적인 것보다 일관성에 투표합니다. 왜냐하면 전자는 객관적인 척도이지만 우리 모두가 직관적인 것에 동의하지는 않을 것이기 때문입니다(이 스레드가 보여주듯이).

NaN을 "Not Number"로 취급하지 마십시오. NaN은 특별한 값입니다.

NaN을 "Not Number"로 취급하지 마십시오. NaN은 특별한 값입니다.

네, 하지만 "Not Number"라고 합니다.
나에게는 이런
var _false = "참";
예, _false가 사실이라는 것을 알 수 있지만 정당한 이유 없이 혼란스럽습니다.

@Walms 그것은 나쁜 이름이지만 JS의 잘못은 아닙니다. 우리는 그것을 "NaN"으로 명명한 사람을 비난할 수 있습니다. http://en.wikipedia.org/wiki/NaN

아아, 나는 _.isNumber(NaN) 가 false 반환하기를 바랍니다 ... 이것이 이유라는 것을 깨달을 때까지 심각한 머리 긁힘.

if (isNaN(Number(value))) {
  alert('Number required.');
}

@pspi 동의합니다. _.isNumber() 가 _의미적_ 의미에서 올바르게 작동하도록 하는 것은 실제로 사용하지 않을 것임을 의미합니다. ._isFinite() 는 내가 예상한 대로 작동하는 기능인 것 같습니다.

그리고 물론 이것을 게시한 후 어느 날 인수가 숫자가 아니더라도 _.isFinite('1') 가 true 임을 발견했습니다.