¿Qué gran número es más grande?

22

Entrada

Enteros a1, a2, a3, b1, b2, b3 cada uno en el rango de 1 a 20.

Salida

True if a1^(a2^a3) > b1^(b2^b3) and False otherwise.

^ es exponenciación en esta pregunta.

Reglas

Este es el código de golf. Su código debe terminar correctamente dentro de 10 segundos para cualquier entrada válida en una PC de escritorio estándar.

Puede generar cualquier cosa Verdad para Verdadero y cualquier cosa Falsey para Falso.

Puede asumir cualquier orden de entrada que desee siempre que esté especificado en la respuesta y siempre sea el mismo.

Para esta pregunta, su código siempre debe ser correcto. Es decir, no debe fallar debido a imprecisiones de coma flotante. Debido al rango limitado de la entrada, esto no debería ser demasiado difícil de lograr.

Casos de prueba

3^(4^5) > 5^(4^3)
1^(2^3) < 3^(2^1)
3^(6^5) < 5^(20^3)
20^(20^20) > 20^(20^19)
20^(20^20) == 20^(20^20)
2^2^20 > 2^20^2
2^3^12 == 8^3^11
1^20^20 == 1^1^1
1^1^1 == 1^20^20
Anush
fuente
Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .
DJMcMayhem

Respuestas:

16

Perl 6 , 31 29 bytes

-2 bytes gracias a Grimy

*.log10* * ***>*.log10* * ***

Pruébalo en línea!

Lo creas o no, este no es un esolang, incluso si está compuesto principalmente de asteriscos. Utiliza la fórmula de Arnauld , con log10 en lugar de ln.

Jo King
fuente
Creo que esto falla 2^3^12 == 8^3^11.
Ørjan Johansen
@ ØrjanJohansen Esto debería arreglarse ahora. avíseme si falla por algo más
Jo King
@ Grimy Gracias! Podría haber jurado que intenté eso ...
Jo King
7

R , 39 bytes

function(x,y,z)rank(log2(x)*(y^z))[1]<2

Pruébalo en línea!

Devuelve FALSO cuando a > by VERDADERO sib < a

digEmAll
fuente
44
Esto está mal paraf(2,2,20,2,20,2)
H.PWiz
Solucionado, usando su sugerencia para @Arnauld answer;)
digEmAll
Creo que esto falla 2^3^12 == 8^3^11.
Ørjan Johansen
1
Falla para ambos 1^20^20 == 1^1^1y 1^1^1 == 1^20^20.
Olivier Grégoire
6

05AB1E , 11 9 11 7 bytes

.²Šm*`›

Puerto de los enfoques de JavaScript de @Arnauld y R de @digEmAll (los vi publicar más o menos al mismo tiempo)
-2 bytes gracias a @Emigna
+2 bytes como corrección de errores después de que las respuestas de @Arnauld y @digEmAll contuvieran un error
-4 bytes ahora que se permite un orden de entrada diferente después de los comentarios de @LuisMendo

De entrada como [a1,b1], [a3,b3], [a2,b2]como tres separó entradas.

Pruébelo en línea o verifique todos los casos de prueba .

Explicación:

       # Take the logarithm with base 2 of the implicit [a1,b1]-input
  Š      # Triple-swap a,b,c to c,a,b with the implicit inputs
         #  The stack order is now: [log2(a1),log2(b1)], [a2,b2], [a3,b3]
   m     # Take the power, resulting in [a2**a3,b2**b3]
    *    # Multiply it with the log2-list, resulting in [log2(a1)*a2**a3,log2(b1)*b2**b3]
     `   # Push both values separated to the stack
        # And check if log2(a1)*a2**a3 is larger than log2(b1)*b2**b3
         # (after which the result is output implicitly)
Kevin Cruijssen
fuente
1
Su
Emigna
@Emigna Ah, bien, estaba mirando un enfoque ć, pero olvidé por completo el uso š(no estoy seguro de por qué ahora que lo veo, jaja). ¡Gracias!
Kevin Cruijssen
Esto parece ser incorrecto (porque la respuesta de Arnauld era incorrecta hasta la solución reciente).
Anush
@Anush Fijo y 4 bytes guardados al tomar las entradas en un orden diferente ahora. :)
Kevin Cruijssen
4

Wolfram Language (Mathematica) , 23 bytes

#2^#3Log@#>#5^#6Log@#4&

Pruébalo en línea!

J42161217
fuente
Esto no termina para a1 = 20, a2 = 20, a3 = 20.
Anush
@Anush arreglado ...
J42161217
1
Lástima el desbordamiento, de lo contrario, ##>0&@@(##^1&@@@#)&solo tiene 19 bytes y es aún más alucinante que Matcode que el código anterior. (formato de entrada {{a,b,c},{d,e,f}})
Greg Martin
3

J , 11 9 bytes

>&(^.@^/)

Pruébalo en línea!

Argumentos dados como listas.

  • > es el izquierdo más grande?
  • &(...) pero primero, transforma cada argumento así:
  • ^.@^/reducirlo de derecha a izquierda con exponencia. Pero debido a que la exponenciación ordinaria limitará el error incluso para números extendidos, tomamos los registros de ambos lados
Jonás
fuente
3

Limpio , 44 bytes

import StdEnv
$a b c d e f=b^c/e^f>ln d/ln a

Pruébalo en línea!

Utiliza una adaptación de la fórmula de Arnauld.

Οurous
fuente
1
Creo que esto falla 2^3^12 == 8^3^11.
Ørjan Johansen
@ ØrjanJohansen fijo.
Οurous
3

Python 3 , 68 bytes

lambda a,b,c,d,e,f:log(a,2)*(b**c)>log(d,2)*(e**f)
from math import*

Pruébalo en línea!

Puerto de respuesta @Arnualds, pero con la base para el registro cambiado.

Artemisa apoya a Mónica
fuente
^se llama **en Python. Y con eso cambiado, no podrá ejecutar todos los casos de prueba del OP.
Ørjan Johansen
Ahora debería estar todo arreglado, 66 bytes sin embargo.
Artemisa apoya a Mónica el
Creo que esto falla 2^3^12 == 8^3^11.
Ørjan Johansen
@ ØrjanJohansen debería repararse
Artemisa apoya a Mónica el
Parece que. Además del cambio de base logarítmica para la solución, este se parece al método de Arnauld.
Ørjan Johansen
2

Excel, 28 bytes

=B1^C1*LOG(A1)>E1^F1*LOG(D1)

Implementación de Excel de la misma fórmula ya utilizada.

Wernisch
fuente
Tengo entendido que Excel tiene 15 dígitos de precisión, por lo que puede haber casos en los que el redondeo provoque que esto devuelva la respuesta incorrecta.
Acumulación
2

JavaScript, 51 bytes

f=(a,b,c,h,i,j)=>(l=Math.log)(a)*b**c-l(h)*i**j>1e-8

Sorprendentemente, los casos de prueba no muestran ningún error de punto flotante. No sé si alguna vez lo hace a este tamaño.

Esto solo compara el logaritmo de los números.

La tolerancia a la igualdad es igual a 1e-8.

Naruyoko
fuente
Bienvenido a PPCG! Por desgracia, esto falla con mi 2^3^12 == 8^3^11caso de prueba. De hecho, su respuesta es muy similar a la respuesta original de Arnauld (tristemente eliminada en lugar de reparada) que inspiró a la mayoría de los que fallaron.
Ørjan Johansen
@ Ørjan Johansen Se movió l(h)a la derecha, ¿y tal vez funciona ahora? Editar: Espera, no lo hace.
Naruyoko
Mayor tolerancia a la igualdad 0.01.
Naruyoko
Hice una búsqueda rápida y una tolerancia debería funcionar, pero esto es demasiado alto. Lo más alto que debe excluir es (5.820766091346741e-11,(8.0,3.0,11,2.0,3.0,12))(mi caso de prueba), y lo más bajo que debe incluir es (9.486076692724055e-4,(17.0,19.0,1,3.0,7.0,2))( 3^7^2 > 17^19^1.) Por lo tanto, algo como 1e-8debería estar de manera segura en el medio y la misma longitud de bytes.
Ørjan Johansen
@ Ørjan Johansen Ok, gracias!
Naruyoko
1

bc -l, 47 bytes

l(read())*read()^read()>l(read())*read()^read()

con la entrada leída STDIN, un número entero por línea.

bces bastante rápido maneja a = b = c = d = e = f = 1,000,000 en poco más de un segundo en mi computadora portátil.


fuente
¡Me encanta una respuesta de BC! Solo necesito uno en bash ahora :)
Anush
1

C ++ (gcc) , 86 bytes

Gracias a @ ØrjanJohansen por señalar una falla en esto y a @Ourous por darnos una solución.

#import<cmath>
int a(int i[]){return pow(i[1],i[2])/pow(i[4],i[5])>log(i[3])/log(*i);}

Pruébalo en línea!

Toma la entrada como una matriz de 6 enteros. Devuelve 1 siunasido>remiF, 0 de lo contrario.

Neil A.
fuente
La fórmula después de tomar logdos veces debe ser i[2]*log(i[1])+log(log(*i)). Por ejemplo, el actual fallará 2^2^20 > 4^2^18.
Ørjan Johansen
@ ØrjanJohansen: buena captura! Supongo que tengo que usar el powmétodo entonces.
Neil A.
La alternativa tiene el 2^3^12 == 8^3^11problema que les he señalado a otros.
Ørjan Johansen
@ ØrjanJohansen: bueno, supongo que estoy usando tu fórmula fija entonces.
Neil A.
Oh, me temo que la fórmula es matemáticamente correcta. Todavía tiene un problema de error de punto flotante, sólo con un caso diferente, 2^3^20 == 8^3^19. De hecho, en promedio, el método de potencia falla por menos, probablemente porque tiende a multiplicarse por potencias de dos exactamente. Otros han logrado hacer que funcione simplemente ajustándolo ligeramente.
Ørjan Johansen
1

Jalea , 8 bytes

l⁵×*/}>/

Pruébalo en línea!

Basado en la respuesta JS de Arnauld . Espera como entrada [a1, b1]como argumento izquierdo y[[a2, b2], [a3, b3]] como argumento derecho.

Ahora se ha cambiado para utilizar el registro en la base 10, que en la medida de lo posible maneja correctamente todas las entradas posibles en el rango especificado. ¡Gracias a Ørjan Johansen por encontrar el problema original!

Nick Kennedy
fuente
1
Creo que esto falla 2^3^12 == 8^3^11.
Ørjan Johansen
Tu Python TIO es incorrecto. Tienes en 8*lugar de 8**. @ ØrjanJohansen tiene razón, 2**(3**12) > 8**(3**11)es falsey, ya que son iguales.
Kevin Cruijssen
@KevinCruijssen oops. Sí, de hecho son iguales. La razón por la cual los dos originales están marcados como diferentes se relaciona con el error de coma flotante.
Nick Kennedy
1

TI-BASIC, 27 31 bytes

ln(Ans(1))Ans(2)^Ans(3)>Ans(5)^Ans(6)(ln(Ans(4

La entrada es una lista de longitud 6 6en Ans.
Salidas verdaderas si el primer gran número es mayor que el segundo gran número. Salidas falsas de lo contrario.

Ejemplos:

{3,4,5,5,4,3
   {3 4 5 5 4 3}
prgmCDGF16
               1
{20,20,20,20,20,19       ;these two lines go off-screen
{20 20 20 20 20 19}
prgmCDGF16
               1
{3,6,5,5,20,3
  {3 6 5 5 20 3}
prgmCDGF16
               0

Explicación:

ln(Ans(1))Ans(2)^Ans(3)>Ans(5)^Ans(6)(ln(Ans(4   ;full program
                                                 ;elements of input denoted as:
                                                 ; {#1 #2 #3 #4 #5 #6}

ln(Ans(1))Ans(2)^Ans(3)                          ;calculate ln(#1)*(#2^#3)
                        Ans(5)^Ans(6)(ln(Ans(4   ;calculate (#5^#6)*ln(#4)
                       >                         ;is the first result greater than the
                                                 ; second result?
                                                 ; leave answer in "Ans"
                                                 ;implicit print of "Ans"

Nota: TI-BASIC es un lenguaje tokenizado. El recuento de caracteres no es igual al recuento de bytes.

Tau
fuente
No estoy tan familiarizado con TI-BASIC, pero esto parece ser log(x) × y × z más que log(x) × y ^ z. Esto no conducirá necesariamente al mismo orden que la desigualdad original.
Nick Kennedy
@NickKennedy Sí, ¡tienes razón en eso! Actualizaré la publicación para dar cuenta de esto.
Tau
1

APL (NARS), caracteres 36, bytes 72

{>/{(a b c)←⍵⋄a=1:¯1⋄(⍟⍟a)+c×⍟b}¨⍺⍵}

A continuación, la función z en (abc) z (xyt) devolvería 1 si a ^ (b ^ c)> x ^ (y ^ t) sino devolvería 0; prueba

  z←{>/{(a b c)←⍵⋄a=1:¯1⋄(⍟⍟a)+c×⍟b}¨⍺⍵}
  3 4 5 z 5 4 3
1
  1 2 3 z 3 2 1
0
  3 6 5 z 5 20 3
0
  20 20 20 z 20 20 19
1
  20 20 20 z 20 20 20
0
  2 2 20 z 2 20 2
1
  2 3 12 z 8 3 11
0
  1 20 20 z 1 1 1
0
  1 1 1 z 1 20 20
0
  1 4 5 z 2 1 1
0

{(abc) ← ⍵⋄a = 1: ¯1⋄ (⍟⍟a) + c × ⍟b} es la función p (a, b, c) = log (log (a)) + c * log (b ) = log (log (a ^ b ^ c)) y si aa = a ^ (b ^ c) con a, b, c> 0 y a> 1 bb = x ^ (y ^ t) con x, y, t> 0 y x> 1 que

aa>bb <=> log(log(a^b^c))>log(log(x^y^t))  <=>  p(a,b,c)>p(x,y,t)

Hay un problema con la función p: cuando a es 1, log log 1 no existe, así que elijo representarlo con el número -1; cuando a = 2, entonces log log a es un número negativo pero> -1.

PD. Visto la función en su conjunto más grande en el que se define

p(a,b,c)=log(log(a))+c*log(b)

parece que el rango para a, b, c en 1..20 es muy poco ... Si uno ve cuando se desborda con la base de registro 10, el rango para a, b, c podría ser 1..10000000 o mayor para un 64 bit tipo de flotador

RosLuP
fuente