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?
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:
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:
Olá,
Segundo a ajuda da Função 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,
Perguntadas: 2016-09-04 01:31:31 +0200
Lidas: 118 vezes
Última atualização: Sep 29 '16
Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
