22/09/2019, 02:50:38 am *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.
¿Perdiste tu email de activación?

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias: Puedes practicar LATEX con el cómodo editor de Latex online
 
 
Páginas: [1]   Ir Abajo
  Imprimir  
Autor Tema: Sobre la desigualdad de Jeffrey Clark Lagarias  (Leído 2092 veces)
0 Usuarios y 1 Visitante están viendo este tema.
feriva
Pleno*
*****

Karma: +1/-0
Desconectado Desconectado

Sexo: Masculino
España España

Mensajes: 8.366



Ver Perfil
« : 04/09/2016, 08:12:40 am »


Es conocido, más o menos, un enunciado sencillo que implica la Hipótesis de Riemann a través de un pequeño cambio en la conjetura de Mertens. Desde hace pocos años (desde 2001) existe otro teorema equivalente que tiene una formulación bastante simple y fue elaborado por el matemático Jeffrey Clark Lagarias.

Explicado con palabras, viene a decir así:

Si tenemos la serie armónica

[texx]S=\dfrac{1}{1}+\dfrac{1}{2}
 +\dfrac{1}{3}+\dfrac{1}{4}...\dfrac{1}{n}
 [/texx]

y el logaritmo natural de ésta

[texx]S_{L}=log(\dfrac{1}{1}+\dfrac{1}{2}
 +\dfrac{1}{3}+\dfrac{1}{4}...\dfrac{1}{n})
 [/texx]

y siendo [texx]D[/texx] la suma de todos los divisores de “n” (los positivos nada más, es sigma de “n”) entonces la hipótesis se traduce en esta desigualdad:

[texx]D\leq S+S_{L}\cdot e^{S}
 [/texx] (donde “e” es la constante de Napier).

Y esta es la conjetura que, de ser cierta, implica la hipótesis de Riemann.

...

Dado que todos son valores positivos, lo primero que se me ocurre (para jugar con la expresión) es dividir entre [texx]S_{L}
 [/texx] y después sustituir por la función contadora de primos para el caso: [texx]\pi(S)=\dfrac{S}{S_{L}}
 [/texx]

quedaría así:

[texx]\dfrac{D}{S_{L}}\leq\pi(S)+e^{S}
 [/texx]

y seguidamente podríamos hacer

[texx]\dfrac{D}{S_{L}}-\pi(S)\leq e^{S}
 [/texx]

Multiplicando por “S” ahora, y sacando de factor común el valor de la función contadora de primos

[texx]D\cdot\pi(S)-\pi(S)\cdot S\leq Se^{S}
 [/texx]

[texx]\pi(S)\cdot{\displaystyle (D-S)}\leq Se^{S}
 [/texx]

Ese producto tiene cierto significado intuitivo : [texx]\pi(S)
 [/texx] es la cantidad (o una aproximación a la cantidad) de primos que hay hasta [texx]S
 [/texx] (concepto más “visible” mentalmente que el logaritmo) donde [texx]S
 [/texx] no es más que la suma de los inversos de “n” números naturales; [texx]D
 [/texx] es simplemente la suma de los divisores respecto del valor de la cantidad de números... Y, en fin, eso debe ser menor o igual al número “e” elevado a “S” y, ello, multiplicado por “S” para que se cumpla Riemann.

Podemos probar buscando algún ejemplo con unos pocos números tomando la verdadera cantidad de primos en vez de la aproximada que daría dicha función, ya que, esta funcion sólo sirve para números “n” muy grandes con los que no puede trabajar un ordenador:

[texx]1,2,3,4,5,6[/texx]

[texx]n=6[/texx]

Tenemos que los divisores de 6 son [texx]1, 2, 3, 6[/texx] y su suma 12; [texx]D=12
 [/texx]

Y la suma de los inversos es [texx]2,45[/texx]; [texx]S=2,45[/texx]

Hasta 2,45, redondeando, tenemos sólo un primo: hacemos, según lo dicho, [texx]\pi(S)=1
 [/texx].

Sustituyendo en la fórmula

[texx]1\cdot(12-2,45)=9,55
 [/texx]

siendo [texx]e^{2,45}=28,39...
 [/texx]

vemos que se cumple en este ejemplo.

En los primeros cientos de miles de números (no sé con toda precisión pues no tuve paciencia para dejar terminar el programa que hice, dando valores de 1 hasta un millón para “n”, pero estuvo una hora más o menos) y con la modificación apuntada (tomando la verdadera cantidad de primos) tan sólo se producen cuatro fallos en la desigualdad, lo cual es muy poco; y también es curioso, porque uno se pregunta por qué el capricho de esos cuatro números entre, con casi total seguridad, cientos de miles o quizá más de un millón; estos números, como curiosidad, tienen factores primos que son consecutivos desde 2 hasta 5, desde 2 hasta 7 y desde 2 hasta 11;

Fallos:

[texx]n=720
 [/texx]

[texx]n=840
 [/texx]

[texx]n=1260[/texx]

[texx]n=55440
 [/texx]

EL programa que he hecho lo dejo en spoiler.


Spoiler (click para mostrar u ocultar)

Ya digo que no sé exactamente cuál es el próximo fallo; pero que está muy lejos seguro que sí; además, se puede ver por lo grande que es la diferencia entre el cuarto y el tercero, no siendo demasiado grande entre los tres primeros. Es más, quizá, aunque se me antoja difícil, no se produzca ya ningún fallo a partir de ahí (aspecto que de ser aclaro imagino que supondría la demostración de la hipótesis, aunque se tome la cantidad de primos verdadera en vez de la función pi).

Se puede apostar a que los fallos se distancian muchísimo, y cada vez más, y a que, dada la divergencia de la serie armónica (la desigualdad reza para el enésimo número armónico, no para cantidades accesibles) y algún otro aspecto, muy probablemente existirá un “n” a a partir del cual no encontremos ningún otro “n”, finito, para el que falle la desigualdad.

No obstante, para mí, que soy un desconocedor casi total de la hipótesis y de los entresijos que rodean este problema y muchas otras cosas relacionadas, este improvisado “test” produce cierta incertidumbre; no me atrevería a pronosticar con toda rotundidad que es cierta, como sí que lo hago con otras conjeturas.
En línea

sqrmatrix
Pleno*
*****

Karma: +0/-0
Desconectado Desconectado

Sexo: Masculino
España España

Mensajes: 172


Ver Perfil
« Respuesta #1 : 04/09/2016, 04:03:28 pm »

Saludos, Feriva.

Hacía tiempo que no pasaba por aquí. Tuve que dejar las factorizaciones que estaba haciendo para Victor Luis. A ver si las retomo.

Me ha parecido muy interesante el desarrollo que has hecho. Dada la última fórmula que muestras, se me ocurre lo siguiente.

Partimos de tu fórmula:

[texx]\displaystyle \pi(S)\cdot (D-S)\le S\cdot e^S[/texx]

Sabemos que [texx]\displaystyle \pi(S)<S[/texx], así que si demostramos que [texx]\displaystyle (D-S)\le e^S[/texx], habremos demostrado que [texx]\displaystyle \pi(S)\cdot (D-S)\le S\cdot e^S[/texx].

Por otro lado, tenemos que [texx]\displaystyle (D-S)<D[/texx], por lo que si demostramos que [texx]\displaystyle D\le e^S[/texx], habremos demostrado que [texx]\displaystyle (D-S)\le e^S[/texx].

[texx]\displaystyle D[/texx] es la suma de divisores de [texx]\displaystyle n[/texx]. El valor crecerá tanto más cuantos más divisores tenga [texx]\displaystyle n[/texx], y la cantidad de divisores de [texx]\displaystyle n[/texx] dependerá de la factorización. Si [texx]\displaystyle n=\prod p_i^{\alpha_i}[/texx], entonces el número de divisores de [texx]\displaystyle n[/texx] será [texx]\displaystyle \prod (\alpha_i+1)[/texx].

Para valores parecidos de [texx]\displaystyle n[/texx], [texx]\displaystyle D[/texx] tomará el menor valor para el [texx]\displaystyle n[/texx] con menos factores primos. En particular, cuando [texx]\displaystyle n[/texx] es primo, tenemos que [texx]\displaystyle D=n+1[/texx]. Si sustituimos este valor en la desigualdad [texx]\displaystyle D\le e^S[/texx], nos queda [texx]\displaystyle n+1\le e^S[/texx], que podemos escribir como [texx]\displaystyle \log(n+1)\le S[/texx].

Consultando en la wikipedia, he visto que el valor de [texx]\displaystyle S[/texx] tiene por límite el valor [texx]\displaystyle \log(n)+\gamma[/texx], donde [texx]\displaystyle \gamma[/texx] es la constante de Euler-Mascheroni, y vale [texx]\displaystyle \gamma=0.577215...[/texx].

Así, tenemos que lo anterior podemos escribirlo como [texx]\displaystyle \log(n+1)\le S\approx \log(n)+\gamma[/texx]. Así, si escribimos [texx]\displaystyle \log(n+1)\le \log(n)+\gamma[/texx], nos queda [texx]\displaystyle \log(n+1)-\log(n)\le \gamma[/texx]. Pero [texx]\displaystyle \log(n+1)-\log(n)[/texx] se aproxima a 0 a medida que crece [texx]\displaystyle n[/texx], por lo que se cumple [texx]\displaystyle \log(n+1)-\log(n)\le \gamma[/texx]. Esto, por supuesto, sólo es válido para [texx]\displaystyle n[/texx] primo.

Todo esto seguramente no sirva para nada, pero resulta interesante (espero no haberme equivocado).

Por otro lado, realicé los cálculos para comprobar tu desigualdad, y después del último valor que indicaste, me sale otro valor, el 249480, y a partir de éste, salen bastantes más. Al parecer, el espacio entre 55440 y 249480 es una laguna bastante grande que no se repite, al menos para valores menores a 1000000. Te pongo aquí los valores para los que falla la desigualdad con el programa que he hecho (espero que no tenga fallos), por si los quieres examinar.

Spoiler (click para mostrar u ocultar)
En línea
feriva
Pleno*
*****

Karma: +1/-0
Desconectado Desconectado

Sexo: Masculino
España España

Mensajes: 8.366



Ver Perfil
« Respuesta #2 : 04/09/2016, 04:50:21 pm »

Hola, sqrmatrix, buenas noches; muy interesantes tus deducciones.

No esperaba que los fallos se produjeran tan seguidos; voy a mirar esos valores a ver qué pueden tener en común. Gracias

Saludos.

Añado:

Fíjate, todos los números que me das (los nuevos) también son múltiplos de 2,3,5,7 y de algunos primos más, aunque no todos son consecutivos; y puede que haya equivocado alguno al copiarlos a una matriz, porque sale uno con un primo enorme que contrasta


Spoiler (click para mostrar u ocultar)



En línea

sqrmatrix
Pleno*
*****

Karma: +0/-0
Desconectado Desconectado

Sexo: Masculino
España España

Mensajes: 172


Ver Perfil
« Respuesta #3 : 05/09/2016, 04:28:09 am »

Saludos, feriva.

Parece que se te coló ese entero con ese primo tan grande que indicas. He estado repasando la lista y todos tienen primos pequeños. Te pongo los enteros factorizados:

Spoiler (click para mostrar u ocultar)

Como se puede ver, todos los primos son pequeños. Esto hace que el entero tenga más divisores y, por tanto, que el valor de [texx]\displaystyle D[/texx] crezca más al haber más divisores que sumar. Seguramente éste sea el motivo de que falle la desigualdad que planteaste para estos enteros, que tengan demasiados divisores. Quizá los enteros con pocos divisores (es decir, con pocos factores primos, o lo que es lo mismo, una combinación de factores primos pequeños y grandes, o sólo primos grandes) siempre la cumplan. Sería interesante ver si hay un número mínimo de divisores que debe tener un entero para que no cumpla la desigualdad.
En línea
feriva
Pleno*
*****

Karma: +1/-0
Desconectado Desconectado

Sexo: Masculino
España España

Mensajes: 8.366



Ver Perfil
« Respuesta #4 : 05/09/2016, 05:02:38 am »

Sería interesante ver si hay un número mínimo de divisores que debe tener un entero para que no cumpla la desigualdad.

Hola sqrmatrix.

Exactamente, algo así estaba pensando.

 Yo me di cuenta de que existía debía de existir un problema de precisión, porque se opera con muchos decimales en estas cuentas, por eso elegí tomar la cantidad exacta de primos en en vez de la aproximación, sin embargo, sigue habiendo muchos decimales en los cálculos.

La pregunta que me hago va por ahí, por lo que dices: todos los números (de los fallos encontrados) tienen como factores comunes 2,3,5,7, ¿será así para todos los fallos hasta el infinito?

Si fuera así, diciéndole al programa que no tome en consideración los múltiplos de 210, podría hacer una comprobación mucho más rápida que usando decimales de precisión; pero habría que demostrar primero que, matemáticamente, de manera formal, eso es de verdad así, que los fallos siempre son divisibles entre los primeros cuatro primos; cosa que no se puede asegurar por muchos ejemplos que obtengamos.

Tú, que se ve que sabes de programación y de mates mucho más que yo, quizá podrías investigar en qué medida podría estar relacionado eso con el número 256 (decimal) que usa un ordenador como tamaño de un kilobyte  y la cuestión del error que se produce en el acarreo cuando el procesador hace las sumas.

Yo creo que puede ir por ahí la cosa, que sea una cuestión de precisión; ¿se podría demostrar Riemann a través de la falta de precisión en los cálculos de un ordenador? Sería algo muy bonito si llegara a ser así.

Ya imagino que sabes por dónde voy, no lo había señalado por eso de que la duda ofende :sonrisa: Pero lo pongo por si algún otro lector interesado no lo hubiera captado: 210*11 (el siguiente primo) > 256

Saludos. 
En línea

sqrmatrix
Pleno*
*****

Karma: +0/-0
Desconectado Desconectado

Sexo: Masculino
España España

Mensajes: 172


Ver Perfil
« Respuesta #5 : 05/09/2016, 11:35:11 am »

Saludos, feriva.

Yo me di cuenta de que existía debía de existir un problema de precisión, porque se opera con muchos decimales en estas cuentas, por eso elegí tomar la cantidad exacta de primos en en vez de la aproximación, sin embargo, sigue habiendo muchos decimales en los cálculos.

La pregunta que me hago va por ahí, por lo que dices: todos los números (de los fallos encontrados) tienen como factores comunes 2,3,5,7, ¿será así para todos los fallos hasta el infinito?

Si fuera así, diciéndole al programa que no tome en consideración los múltiplos de 210, podría hacer una comprobación mucho más rápida que usando decimales de precisión; pero habría que demostrar primero que, matemáticamente, de manera formal, eso es de verdad así, que los fallos siempre son divisibles entre los primeros cuatro primos; cosa que no se puede asegurar por muchos ejemplos que obtengamos.

Lo que planteas es muy interesante, aunque no se me ocurre cómo podríamos abordarlo. Por otro lado, en los valores obtenidos para [texx]\displaystyle n<1000000[/texx], aparecen siempre los primos [texx]\displaystyle 2, 3, 5[/texx], pero el [texx]\displaystyle 7[/texx] no siempre aparece, aunque aparece la mayoría de las veces.

Los fallos en la desigualdad creo que no son debidos a la precisión de los cálculos, sino que son debidos a haber considerado la equivalencia [texx]\pi(S)=\dfrac{S}{S_L}[/texx], dado que [texx]\dfrac{S}{S_L}[/texx] es una función que crece regularmente, mientras que [texx]\pi(S)[/texx] crece irregularmente (crece a saltos). Los fallos en la desigualdad imagino que se deben a un cambio de signo en la diferencia entre [texx]\pi(S)[/texx] y [texx]\dfrac{S}{S_L}[/texx].

He hecho los cálculos para [texx]n<10000000[/texx] (te adjunto el archivo con los resultados; al final del mismo están los enteros y sus factorizaciones en una lista), y ocurren varias cosas curiosas. El último entero que falla en este intervalo es [texx]3603600[/texx], bastante alejado de [texx]10000000[/texx]. No sé si es una laguna (como la primera), o es el último de los enteros que fallan. El motivo por el que dudo es el siguiente. Creo que la causa de estas lagunas es que [texx]\pi(S)[/texx] crece más lentamente que [texx]S[/texx]. No sólo eso, el valor de [texx]\pi(S)[/texx] permanece constante durante bastante tiempo, lo que hace que el crecimiento de la parte izquierda de la desigualdad dependa principalmente de [texx]D[/texx], el cual es un valor irregular. Mientras tanto, la parte derecha de la desigualdad va creciendo. De esta forma, hasta que [texx]\pi(S)[/texx] no se incrementa, cada vez se va favoreciendo el cumplimiento de la desigualdad. Me pregunto si el crecimiento de [texx]S\cdot e^S[/texx] puede superar el de [texx]\pi(S)\cdot(D-S)[/texx] hasta el punto de que, a partir de cierto momento, siempre se cumple la desigualdad.

Otra observación curiosa, relacionada, es que, hasta más o menos el valor [texx]1441440[/texx], la aparición de enteros que no cumplen la desigualdad es relativamente frecuente, aunque poco a poco la frecuencia va disminuyendo. Pero a partir de ese valor, la frecuencia decrece repentinamente. Seguramente esté relacionado con lo que he dicho antes, sobre el valor [texx]3603600[/texx].

Otra observación curiosa es que a medida que los valores crecen para los enteros que no cumplen la desigualdad, empieza a aumentar la frecuencia de aparición del [texx]11[/texx] como factor primo de los enteros que fallan. Igual ocurre con el [texx]13[/texx]. Puede que la tendencia en este conjunto de enteros es a ir acumulando los primeros factores primos a medida que crecen, de forma que, cuanto más grande es un entero de los que fallan, más probable es encontrar un primo en su factorización. Si la tendencia se mantiene, para cualquier [texx]k[/texx], existirá un número infinito de enteros que no cumplan la desigualdad y que tendrán en su factorización los primeros [texx]k[/texx] primos. Esto, por supuesto, es una suposición. Habría que demostrarlo formalmente, lo cual no se me ocurre cómo hacer. Eso sí, los que siempre aparecen (en los cálculos que he hecho) son [texx]\displaystyle 2, 3, 5[/texx], lo que lleva a pensar si todos los enteros que no cumplen la desigualdad son divisibles por [texx]\displaystyle 2\cdot 3\cdot 5=30[/texx].

Y algo que también observamos es que los enteros que no cumplen la desigualdad están formados por el producto de primos pequeños, lo que lleva a pensar que estos enteros son enteros con muchos divisores, ya que esto hace que [texx]D[/texx] tome valores más grandes, condición que favorece que no se cumpla la desigualdad.

Tú, que se ve que sabes de programación y de mates mucho más que yo, quizá podrías investigar en qué medida podría estar relacionado eso con el número 256 (decimal) que usa un ordenador como tamaño de un kilobyte  y la cuestión del error que se produce en el acarreo cuando el procesador hace las sumas.

Yo creo que puede ir por ahí la cosa, que sea una cuestión de precisión; ¿se podría demostrar Riemann a través de la falta de precisión en los cálculos de un ordenador? Sería algo muy bonito si llegara a ser así.

Ya imagino que sabes por dónde voy, no lo había señalado por eso de que la duda ofende :sonrisa: Pero lo pongo por si algún otro lector interesado no lo hubiera captado: 210*11 (el siguiente primo) > 256

No creo que sepa más que tú, pero gracias por tus palabras :sonrisa:.

Con respecto al valor que me indicas, [texx]256[/texx], no afecta a los cálculos, ya que se utilizan varios bytes, en el caso de los cálculos con variables de tamaño fijo, los cuales tienen un límite de precisión bastante bueno para estos cálculos (salvo que calculemos hasta valores de [texx]n[/texx] muy grandes, lo que llevaría meses de cálculo, y no creo que llevemos a cabo estos cálculos tan largos :sonrisa: ). Además, en caso necesario, siempre se pueden usar librerías que usen precisión arbitraria, los cuales pueden reducir los errores de precisión a valores que no afecten de forma apreciable al resultado final (eso sí, son más lentos a la hora de hacer cálculos).

* sqrmatrix_Desigualdad_20160905.txt (28.08 KB - descargado 55 veces.)
En línea
feriva
Pleno*
*****

Karma: +1/-0
Desconectado Desconectado

Sexo: Masculino
España España

Mensajes: 8.366



Ver Perfil
« Respuesta #6 : 05/09/2016, 01:40:43 pm »


Hola otra vez, sqrmatrix.

No lo recuerdo bien, porque estudié un poco de ensamblador (muy poco) cuando lo inventaron, cuando salió el primer Spectrum de todos, pero creo que operaba módulo 260 256; tenía una cosa que se llamaba indicadores de flag para el complemento a dos, los acarreos y demás...  Pero todo lo tengo muy olvidado.

Me parece bien el análisis que haces, sin embargo, sigo teniendo mis dudas sobre si no es una cuestión debida en cierta medida al ordenador; habría que mirar más casos, no obstante; y si siguen saliendo múltiplos de los primos de una sola cifra en base 10 (lo cual ya es una particularidad) a mí me extrañaría demasiado que fuera una cosa “natural”

Saludos
En línea

sqrmatrix
Pleno*
*****

Karma: +0/-0
Desconectado Desconectado

Sexo: Masculino
España España

Mensajes: 172


Ver Perfil
« Respuesta #7 : 19/09/2016, 11:04:33 am »

Saludos, feriva.

Disculpa que no te haya respondido antes. Me despisté y se me olvidó responderte. Cuando leí tu respuesta, dejé el escribir mi respuesta para luego, y ese "para luego" se ha convertido en dos semanas  :avergonzado: .

Las dudas que planteas respecto a si la precisión del ordenador puede darnos resultados equivocados, no sé hasta qué punto puede afectar a este problema con los valores que hemos manejado. Yo diría que con los cálculos que hemos hecho no hay error salvo, quizá, alguno de los decimales menos significativos. Para cálculos con valores mayores, habría que ver qué precisión sería necesaria. Pero me da que con las precisiones que ofrecen los lenguajes de programación de ahora es suficiente para las pruebas que estamos haciendo. En todo caso, si se necesitara más precisión, siempre se puede utilizar una librería de precisión arbitraria.

Lo que sí es cierto es que a medida que aumenta el valor de [texx]\displaystyle n[/texx], aumentan los decimales. No sé a partir de qué valor de [texx]\displaystyle n[/texx] pueden empezar a producirse errores importantes en los cálculos que estamos haciendo.

No lo recuerdo bien, porque estudié un poco de ensamblador (muy poco) cuando lo inventaron, cuando salió el primer Spectrum de todos, pero creo que operaba módulo 260 256; tenía una cosa que se llamaba indicadores de flag para el complemento a dos, los acarreos y demás...  Pero todo lo tengo muy olvidado.

Yo aprendí ensamblador con un 8088. El microprocesador era más avanzado que el del Spectrum, que creo que era un Z80. El 8088 permitía trabajar con 16 bits. Tenía instrucciones que facilitaban las operaciones aritméticas con enteros de más de 16 bits. Con los nuevos microprocesadores, ahora se pueden realizar cálculos en ensamblador con coma flotante (antes había que añadir un coprocesador matemático a la placa del ordenador, o emular dichas operaciones por software. Ahora el coprocesador matemático ya viene integrado en el microprocesador). De todas formas, cuando trabajamos con lenguajes de alto nivel (en tu caso, Python, y en el mío, Java), no tenemos que preocuparnos por esas cosas, pues el lenguaje facilita todas las operaciones de forma transparente, independientemente del microprocesador con el que estemos trabajando. Además, estos lenguajes incorporan librerías de precisión arbitraria que, en caso necesario, podemos usarla. Yo no la he usado porque no he visto la necesidad en los cálculos que he realizado. Además, los cálculos son más lentos con estas librerías. En todo caso, he utilizado la mayor precisión que permite Java en sus tipos nativos para reducir errores (precisión "double"). Creo que sólo sería necesario utilizarlas para valores muy grandes de [texx]\displaystyle n[/texx], valores que se escapan de las posibilidades de cálculo de nuestros PCs.
En línea
feriva
Pleno*
*****

Karma: +1/-0
Desconectado Desconectado

Sexo: Masculino
España España

Mensajes: 8.366



Ver Perfil
« Respuesta #8 : 19/09/2016, 11:47:12 am »


Hola, sqrmatrix.

Ya ni me acordaba de esto :sonrisa:

Se me ocurre una cosa, por si la quieres investigar, que tú haces programas más eficientes que los míos.

Podríamos tomar

[texx]\pi(S)\cdot{\displaystyle (D-S)}\leq S\left((1+\dfrac{1}{m})^{m}\right)^{S}[/texx]
 

y hacer que un bucle dé valores a “m” (para cada “n” a probar) hasta que se cumpla la desigualdad (hallando el mínimo valor para “m” que la cumpla) y guardar esos valores en un array, por ejemplo, para después mirar a ver en qué medida necesita ir creciendo “m” respecto de las otras variables que intervienen (o respecto de alguna de ellas, o respecto del producto de algunas de ellas... no sé, inventos que se nos ocurran; y mejor si tienen un poco de sentido, aunque sea sólo por intuición).

Si se pudiera sustituir “m” por alguna función de “S” o de “D” (o de ambas) de manera que la desigualdad se siga cumpliendo, quizá se pudiera simplificar la desigualdad o extraer alguna conclusión que sirva para inventar más cosas.

Saludos.
En línea

sqrmatrix
Pleno*
*****

Karma: +0/-0
Desconectado Desconectado

Sexo: Masculino
España España

Mensajes: 172


Ver Perfil
« Respuesta #9 : 20/09/2016, 05:34:12 am »

Saludos, feriva.

Podríamos tomar

[texx]\pi(S)\cdot{\displaystyle (D-S)}\leq S\left((1+\dfrac{1}{m})^{m}\right)^{S}[/texx]
 

y hacer que un bucle dé valores a “m” (para cada “n” a probar) hasta que se cumpla la desigualdad (hallando el mínimo valor para “m” que la cumpla) y guardar esos valores en un array, por ejemplo, para después mirar a ver en qué medida necesita ir creciendo “m” respecto de las otras variables que intervienen (o respecto de alguna de ellas, o respecto del producto de algunas de ellas... no sé, inventos que se nos ocurran; y mejor si tienen un poco de sentido, aunque sea sólo por intuición).

Si se pudiera sustituir “m” por alguna función de “S” o de “D” (o de ambas) de manera que la desigualdad se siga cumpliendo, quizá se pudiera simplificar la desigualdad o extraer alguna conclusión que sirva para inventar más cosas.

Interesante lo que propones. A ver si encuentro un hueco para probarlo.
En línea
Páginas: [1]   Ir Arriba
  Imprimir  
 
Ir a:  

Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.4 | SMF © 2006, Simple Machines LLC XHTML 1.0 válido! CSS válido!