[Criticismo contra JavaScript] Explicação matemática sobre inteiro 1 mais constante ser igual a constante mais inteiro 1, sem alterar valor da constante, estar matematicamente correto

[fititnt]

Esta discussão se iniciou em no grupo NodeJS onde uma pessoa começou a dizer com argumentos rasos que o design da linguagem JavaScript era ruim por motivos que não são matematicamente errados. Link: https://www.facebook.com/groups/nodejsbrasil/permalink/916210161845605/

Proponho aqui que seja adicionado ao curso maiores explicações sobre lógica matemática relacionada a soma de inteiros e constantes exibir um resultado com a soma da constante aos respectivos inteiros não é um erro de lógica.

Caso haja exercícios de aula, levar em consideração que é opcional a linguagem de programação exibir com incrementador ou decrementador o resultado da operação. O único erro de lógica seria se a constante verdadeira pudesse ser alterada.

[fititnt]

Do link usado como referência para dizer que JavaScript é do mal:

https://dutrahacking.blogspot.com.br/2016/11/why-javascript-is-evil.html

[alexsmonte]

PS: minhas críticas ao JS nunca foram matemáticas hahahahaha
Tenho mtas... Sou contra como estão usando esses FWjs, sou contra a esses remendos q estão fazendo no javascript para torna-lo algo para o qual ele não foi pensando...

[fititnt]

@alexsmonte Não é sobre você esse issue. Olha o resto da discussão que você vai entender.

[alexsmonte]

Eu sei q nao mas meu comentário deu origem haha hahahahaha comentário fora de contexto neh hahahahhaha

[suissa]

QUE TRETAAA!!!

No caso do Math.PI ele ateh aceita ++ pq não foi criada como const, porém NAO MODIFICA seu valor nunca, mas uma const criada não aceita ++, apenas + 1

Adoro as loucuras do JS, só ver o JS WAT. Isso só é ruim quando o programador não sabe dessas coisas e aí faz merda.

Até C tem seus problemas e não vai ser uma linguagem feita em menos de 10 dias que será né amiguinhos.

[robertopc]

O ++ Math.PI não é um problema. Como o @suissa falou é uma operação inplace sem modificar o valor.

O que achei grave foi a conta (0.1 + 0.2) + 0.3 == 0.1 + (0.2 + 0.3).
Fiz os testes no console. E (0.1 + 0.2) + 0.3 retorna 0.6000000000000001 e 0.1 + (0.2 + 0.3) retorna 0.6.

Só não entendi o porque desse erro na precedência. Alguém sabe porque isso acontece?

[robertopc]

A reposta do meu questionamento, foi respondida em https://stackoverflow.com/questions/588004/is-floating-point-math-broken .

Várias linguagens têm o mesmo problema, testei em JS, Python, PHP e Ruby:

$ node -p '0.1 + 0.2 == 0.3'
false
$ python -c 'print 0.1 + 0.2 == 0.3'
False
$ ruby -e 'print 0.1 + 0.2 == 0.3'
false
$ php -r 'var_dump(0.1 + 0.2 == 0.3);'
bool(false)

[MatheusMinguini]

Sobre a issue do: (0.2 + 0.1) != 0.3

Computadores não entendem o conceito de dízimas periódicas ou não-periódicas.
Por exemplo: Nós, seres humanos usamos a base 10. Ao tentarmos fazer 1/3 isso retorna 0.3333... (Aliás, qualquer número que não seja múltiplo de 3, quando dividido por 3, causa uma dízima).
Computadores tem 32 bits ou 64 bits e operam na base 2
Então, pro computador divivir por 10 é equivalente a nós humanos dividirmos por 3, porém o computador não entende o conceito de dízima

Como os computadores tem 64 bits, isso significa que eles conseguem guardar 64 dígitos binários

Ao dividir 2/10 o computador vai chegar em um número tipo 01110011100111.... atingindo os 64 bits disponíveis, ou seja, isso é um erro de floating number

Logo, pro computador, algo que tende ao infinito nunca vai ser igual a outra coisa que tende ao infinito porque ele nao consegue determinar essa equivalência

Exemplo final:
Nós humanos pensamos assim porque sabemos o conceito da significância do número
1/3 + 1/3 + 1/3 = 3/3 = 1

Mas se fossemos expressar a mesma operação em decimal, ficaria:
1/3 = 0.333...

.•. 1/3 + 1/3 + 1/3 = 0.999

0.999 é muito próximo de 1, mas não equivale, de fato, a 1

Acontece a mesma coisa com o computador, porém, ao dividir por 10