Qual o motivo desta ocorrência

Recebi um arquivo para ajuda e deparei com o seguinte caso: Detalhe a pessoa que enviou o arquivo desconhecia a função MOD, ela estava tentando fazer a separação da parte fracionada por cálculos e não conseguia. (veja a imagem), esta usando LibO 5.2.1.2, também estou e realmente ocorre, o que pode ser?Descrição da imagem

Olá,


Segundo a ajuda da [Função MOD()](https://help.libreoffice.org/Calc/Mathematical_Functions/pt-BR#MOD):

Essa função é implementada como Dividendo - Divisor * INT(Dividendo/Divisor), e essa fórmula retorna um resultado caso os argumentos não sejam inteiros.

Exemplo

=MOD(22;3) retorna 1, o resto da divisão inteira de 22 por 3.

=MOD(11,25;2,5) retorna 1,25.

Então, imagino que o motivo esteja no fato de que a função MOD(), da forma como está implementada, apresentará o resto sempre como inteiro para argumentos (Dividendo e Divisor) inteiros. Que é diferente da forma como você implementou o cálculo na linha 3: (DIVIDENDO / DIVISOR - INT(DIVIDENDO / DIVISOR)) * DIVISOR .


Atte,

Ola, @Grafeno, a duvida em questão não é da função MOD, como eu disse, a pessoa que me enviou a planilha pedindo ajuda, não conhecia a função, ela tentou obter o mesmo resultado fazendo os cálculos na linha 2, e repare que na pratica o calculo esta certo, mas o resultado errado em F2, seria algum “Bug”. Ela queria separar do Código de Barras (13 dígitos) somente o código do produto, 6 últimos dígitos. E B2 são 13 dígitos não tem decimais ocultos.

Perdão @Gilberto Schiavinatto. Acabei interpretando a questão de forma errada. Imaginei a princípio que ocorrência estava com a função MOD(). Por isso, não refiz o primeiro cálculo. E como não existe casas decimais ocultas em B2, acredito que o problema acabe sendo um bug. Atte,

Ola @ohallot, será que é bug ???

Não sei se é bem um bug, apesar de que o LO Calc não retornar nenhum erro sobre a questão. Fiz vários testes aqui, inclusive o cálculo em específico em código C. Pelo que pude perceber existe um limite de casas decimais em que o LibreOffice trabalha, pelo que pude encontrar aqui: Códigos de erro no LibreOffice Calc Erro 514 o máximo permitido é de 6 casas decimais, e realmente diminuindo o número 7891962035529 para p. ex. 789196 o resultado fica correto, mas eu fiz um teste diminuindo uma casa decimal por vez observando o valor final até ele ficar correto e com até 7 casas o Calc faz os cálculos corretamente, passou disso ele fica “biruta”. Contudo, acredito eu, que isso se deva a limitação da linguagem de programação em que o LibreOffice (sintam-se a vontade para me corrigir) foi feito e não o erro interno dele.

O intrigante é que a função MOD() funciona perfeitamente. Para ilustrar o que disse abaixo uma imagem dos resultados diminuindo-se uma casa decimal por vez:

Descrição da imagem

Eu destaquei a linha em que o resultado se apresenta corretamente.

Uma alternativa que pesquisei aqui, caso não queira utilizar a função MOD() é utilizar a função EXT.TEXTO() que extrai parte de um texto a partir de uma posição com uma certa quantidade de caracteres.

Olá!
Com o devido respeito aos demais, não há nada de errado ao meu ver.
Trata-se de um número em ponto flutuante.
E deste modo, pode ser representado com maior ou menor precisão.
Confirmei que o procedimento computacional está correto, e se você diminuir o tamanho da coluna, você terá o valor 35529 . Todo programador deve ser cuidadoso ao trabalhar com números decimais.

Veja o exemplo da Wikipedia: o valor decimal para 1/3 é igual a: 0,3 . Ou ainda: 0,33. Ou melhor: 0,333.

No caso do códigos de barras, talvez seja melhor representá-lo como se fosse uma string (texto), e assim trabalhar pedaços do código usando as funções de texto. Depois, se for necessário trabalhar em formato de número inteiro, fazer as conversões (casting).
O resultado será mais confiável.

Observe, na imagem abaixo, que outro software de planilha trabalha também do mesmo modo:

Descrição da imagem