Qual é o melhor número (x) ou parseFloat (x)?


147

Qual é melhor?

Estou perguntando isso apenas para raspar alguns bytes, pois posso usar + x em vez de número (x). Parsefloat faz algo melhor?


2
Os números de ponto flutuante de precisão única ocupam 4 bytes em um sistema de 32 bits, bem como números inteiros simples. Não sei como o javascript lida com carros alegóricos, mas acho que é praticamente o mesmo.
Christian

5
@ Christian: Todos os números em Javascript são flutuadores de precisão dupla.
Guffa 01/09/12

1
I would've votou UP para esta pergunta se não fosse para o segmento EDIT
LaPuyaLoca

Respostas:


309

A diferença entre parseFloat e Number

parseFloat/ parseInté para analisar uma string, enquanto Number/ +é para coagir um valor a um número. Eles se comportam de maneira diferente. Mas primeiro vamos ver onde eles se comportam da mesma maneira:

parseFloat('3'); // => 3
Number('3'); // => 3
parseFloat('1.501'); // => 1.501
Number('1.501'); // => 1.501
parseFloat('1e10'); // => 10000000000
Number('1e10'); // => 10000000000

Portanto, desde que você tenha entrada numérica padrão, não há diferença. No entanto, se sua entrada começar com um número e depois contiver outros caracteres, parseFloattruncará o número da string, enquanto Numberfornece NaN(não um número):

parseFloat('1x'); // => 1
Number('1x'); // => NaN

Além disso, Numberentende a entrada hexadecimal, enquanto parseFloatnão:

parseFloat('0x10'); // => 0
Number('0x10'); // => 16

Mas Numberage de maneira estranha com cadeias vazias ou cadeias contendo apenas espaço em branco:

parseFloat(''); // => NaN
Number(''); // => 0
parseFloat(' \r\n\t'); // => NaN
Number(' \r\n\t'); // => 0

No geral, acho Numbermais razoável, então quase sempre uso Numberpessoalmente (e você verá que muitas das funções internas do JavaScript também usam Number). Se alguém digitar '1x', prefiro mostrar um erro do que tratá-lo como se tivesse digitado '1'. A única vez em que realmente faço uma exceção é quando estou convertendo um estilo para um número; nesse caso, parseFloaté útil porque os estilos vêm em uma forma como '3px', nesse caso, eu quero largar a 'px'peça e apenas obtê-la 3, então acho parseFloatútil aqui. Mas, na verdade, qual você escolhe depende de você e de quais formas de entrada você deseja aceitar.

Observe que usar o +operador unário é exatamente o mesmo que usar Numbercomo função:

Number('0x10'); // => 16
+'0x10'; // => 16
Number('10x'); // => NaN
+'10x'; // => NaN
Number('40'); // => 40
+'40'; // => 40

Então eu costumo usar apenas +para abreviar. Contanto que você saiba o que faz, acho fácil ler.


2
Eu não consideraria o comportamento de espaço em branco => 0Number() como "estranho" Eu consideraria o mais esperado, o espaço em branco é um valor vazio, mas não é nulo / indefinido => 0 é um bom resultado. Big (+) para você para as vitrines de qualquer maneira :)
jave.web

4
@ NathanWall: Pode-se mencionar isso Number('Infinity') === InfinityconsiderandoparseInt('Infinity') === NaN
sstur 18/08/14

3
Eu não usaria +(unário mais) para isso, porque se você esquecer um ponto-e-vírgula na linha anterior, uma expressão de adição poderá ser avaliada.
Jackson

1
Nos casos em que eles se comportam da mesma forma, descobri que o parseFloat é de 1% a 15% mais lento, tornando-se mais lento quando o número de dígitos decimais em uma string aumenta. Com a execução de 1 milhão no meu sistema, parseFloat ('1.501') é 5% mais lento que Number ('1.501') e parseFloat ('1.50137585467') é 15% mais lento que Number ('1.50137585467'). Então, eu vou para Number ().
bytepan

1
@ ChrisBrownie55 Uau, boa captura. Eu não sabia que o parseFloat pode fazer isso. Eu acho que o Infinito não é um número inteiro!
SSTUR

9

A diferença é o que acontece quando a entrada não é um "número adequado". Numberretorna NaNenquanto parseFloatanalisa "o máximo possível". Se chamado, a sequência vazia Numberretorna 0enquanto parseFloat retorna NaN.

Por exemplo:

Number("") === 0               // also holds for false
isNaN(parseFloat("")) === true // and null

isNaN(Number("32f")) === true
parseFloat("32f") === 32

4
Note que NaN != NaNembora
Wex

@ Wex Oh, você NaN != NaNavalia que é VERDADEIRO - obrigado pela dica!
jave.web

4
use isNaN () para testar o valor NaN, isNaN(NaN)retornatrue
jave.web 6/02/14

5

Nestes exemplos, você pode ver a diferença:

Number('') = 0;
Number(false) = 0;
Number('1a') = NaN;

parseFloat('') = NaN;
parseFloat(false) = NaN;
parseFloat('1a') = 1;

parseFloat é um pouco mais lento porque procura a primeira aparição de um número em uma sequência, enquanto o construtor Number cria uma nova instância de número a partir de sequências que contêm valores numéricos com espaço em branco ou que contêm valores falsos.

PS Se você estiver interessado em algumas soluções universais de conversão de tipos, pode ler o post sobre conversão de tipos no meu blog: http://justsimplejs.blogspot.com/2012/08/data-type-conversion.html


2

Para string vazia, eles são diferentes.

+""e Number("")retorna 0, enquanto parseFloat("")retorna NaN.


2
Eu diria que parseFloat()o resultado certo é que uma string vazia NÃO é o número 0(leia-se: NaN) enquanto uma string com o caractere "0"IS 0;
Christopher

+xretorna 0não apenas para uma cadeia vazia, mas também para cadeias somente de espaço em branco. Exemplos: +" ", +"\t\t\t", +"\n\n"- todos eles dão 0como resultado
Lukasz Wiktor

2

Tanto quanto eu sei, e isso só é ouvido pelos colegas, por isso pode estar totalmente mal informado, que a análise de flutuações é marginalmente mais rápida.

Embora em pesquisas adicionais, parece que essa diferença de desempenho depende do navegador.

http://jsperf.com/parseint-vs-parsefloat/6

Veja esses resultados do jsPerf e faça a sua ligação. (inclui também + x testes)

Conforme observado na resposta de @xdazz, +""e Number("")retorne 0while, parseFloat("")retorne- NaNo. Novamente, eu iria com parseFloat, porque uma string vazia NÃO significa o número 0, apenas uma string com o caractere "0"significa 0;


Aqui está uma pesquisa de teste mais exaustiva para uma maneira mais rápida de converter ... parseFloat()ainda é o vencedor.
mindplay.dk
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.