Objetivo

Dado um número de entrada, arredonde-o para o número mais próximo com um número significativo.

Exigências

Entrada

• Um número de ponto flutuante.
• Suponha que o número da entrada resulte em uma saída dentro dos limites do tipo de dados (por exemplo, ignore erros de estouro).
• 0 é uma entrada inválida.
• Números que não podem ser representados com precisão no tipo de dados de ponto flutuante (por exemplo, "0.35"sendo armazenados como 0.3499999) não precisam ser suportados.

Resultado

• O número mais próximo que consiste em um dígito diferente de zero e qualquer número de zero dígitos.
• O resultado deve suportar números negativos e números fracionários.
• Quando a entrada estiver exatamente entre duas saídas possíveis, arredonde para zero.

Apresentação

O foco está no cálculo, e não na apresentação. A saída pode ser um tipo de dados de ponto flutuante. Pode ser texto na íntegra ou em notação científica. Se você encontrar uma brecha na qual a apresentação de uma certa maneira reduz a contagem de bytes, parabéns!

Exemplos

9
-3000
.2
0.2
-.2
7e12
5e-15
1e0

Casos de teste

Input     Output
1         1
10        10
17        20
99        100
54321     50000
56789     60000
-123      -100
-789      -800
0.23      0.2
0.25      0.3
-0.25     -0.3
4.56e23   5e23
4.56e-23  5e-23

Pontuação

O código com o menor número de bytes após uma semana vence.

MATL , 3 bytes

1&V

Experimente online! Ou verifique todos os casos de teste .

O caso de teste 0.25falha para o compilador em execução no Octave no TIO, mas funciona no Matlab no Windows:

O comportamento diferente é causado pela função da Octave / Matlab sprintfusando o arredondamento "banqueiro" ou ".5 longe de zero", dependendo da plataforma. Mais informações e testes podem ser encontrados aqui .

Por 6 bytes ,

1t3$Yo

funciona tanto no Octave quanto no Matlab. Verifique todos os casos de teste .

C # (.NET Core) , 19 bytes

n=>n.ToString("G1")

Experimente online!

Exemplos:

Input     Output
----------------
 54321     5E+04
-56789    -6E+04
 99        1E+02
 0.23      0.2
 0.25      0.3
-0.25     -0.3
 4.56e23   5E+23
 4.56e-23  5E-23

Javascript, 19 bytes

x=>x.toPrecision(1)

Retina , 63 62 bytes

1`[1-9]
$*#
#\.?[5-9]
#$&
T`d`0`#[\d.]+
0(\.?)#{10}
1$1
#+
$.0

Experimente online!

PHP , 45 bytes

<?=round($x=$argv[1],-floor(log10(abs($x))));

Experimente online!

O mesmo método da minha resposta python 2.

Também parece manipular corretamente 0.35, o que o coloca também acima da resposta JS: D

T-SQL, 27 bytes

SELECT FORMAT(i,'G1')FROM t

Usando o mesmo código de formatação .Net da resposta C # de Carlos Alejo . A entrada é da coluna flutuante i na tabela t existente , de acordo com nossos padrões de IO

Casos de teste:

Input         Output
------------ --------
1             1
10            1E+01
17            2E+01
99            1E+02
54321         5E+04
56789         6E+04
-123         -1E+02
-789         -8E+02
0.23          0.2
0.25          0.3
-0.25        -0.3
4.56E+23      5E+23
4.56E-23      5E-23

(É muito útil que eu possa pré-carregar a tabela de entrada com todos esses valores e executá-los de uma só vez.)

Python 2 , 62 bytes

lambda x:round(x,-int(floor(log10(abs(x)))))
from math import*

Experimente online!

Não é usado para jogar python, mas isso funciona.

Falha 0.35devido a imprecisões de ponto flutuante.

Agradecemos a Anders Kaseorg por apontar que isso funciona corretamente no Python 2

Guile , 23 bytes

(format #t"~,0e"(read))

Experimente online!

Excel, 14 bytes

=ROUNDUP(A1,1)

Perl 5 , 15 bytes

printf"%.1g",<>

Experimente online!

Zsh , 14 bytes

Porta da resposta perl. Experimente Online!

printf %.1g $1

Quarto (gforth) , 24 bytes

: f 1 set-precision f. ;

Experimente online!

A entrada é esperada na pilha de ponto flutuante. A saída é para stdout

Não gosto de fazer alterações na precisão global (para esta instância) das funções de saída de ponto flutuante, mas economiza muitos bytes para não precisar restaurar o valor anterior no final. Não produz em notação científica ou de engenharia, independentemente da entrada.

Nota: Por alguma razão, o intérprete tio é convertido 0.25em 0.2, enquanto minha instalação local é convertida 0.25em 0.3. Não sei ao certo por que isso ocorre, mas como obtenho o resultado correto localmente, estou deixando minha resposta como está.

: f                   \ start a new word definition
  1 set-precision     \ set the floating point output words to use 1 significant digit
  f.                  \ output the top of the floating point stack
;                     \ end the word definition