@xiam Relacion recursiva mmm ciertamente el poco matemático que llevo dentro de mi no hubiera llegado a ella.

@izaac Muy interesante tus soluciones de Python, supongo que mientras mas grande el rango mas te beneficias de xrange porque siempre utiliza la misma memoria.

@Yeru Aaaamén.

@mamasan Este emo se va a ver a Radiohead en 10 dias y no llevara a mamasan :D

ha si…

pablasso es emo!

http://pastebin.com/m51e96ae1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <stdio.h>
 
main()
{
    int  a = 1, b = 2, c = 0;
    int sum=b;
 
   do 
    {
          sum += c;
          c=3*b+2*a;
          a=2*b +a;
          b=c;
    }while ( c < 4000000 );
 
    printf("resultado: %d\n", sum);
    return 0;
}

Explico:

a=1
b=2
sum=2;

como dije no hace falta calcular los impares, pero no quiere decir que no los ocupemos.
el siguiente numero es el 3 y se calcula c= a+b =3;
pero yo no quiero el 3, quiero el 8, entonces calculo el siguiente del siguiente.

c= (a+b) +((a+b)+b);
…factorizamos;
c=b+b+b+a+a;
c=3b+2a; <—–Siguiente número par;
y al anterior que es a.
a=((a+b)+b);
a=2b+a;<—–Anterior.

Entonces nos ahorramos 2/3 de las iterraciones, y solamente calculamos los pares(aun asi como que tengo una espinita que se puede mejorar mas).

Lo de resolver el problema mas optimo o no, pues en este y en el anterior problema realmente ami manera de ver, cualquier chavo de prepa que estudie programacion los puede hacer, por eso digo que tiene mas merito proponer una solucion optima que la mas obvia y que cuando ves el problema es la primera que se te viene a la mente, que ni siquiera hace falta programarla para saber que estas bien.

Conozco estos restos y conforme avanzas , los problemas son tan dificiles que ahora si encontrar la solución es lo que vale la pena.

Digo, ami no se me hace dificil sumar dos numeros y comprobar si son par.

Además quiero refutar mi propia teoría usando itertools, utilizando profile pude bajar el tiempo bajar a la mitad el tiempo de ejecución:

De 0.018 a 0.009 segundos, usando el primer código del primer post que amablemente Juan Pablo coloreó, pero utilizando xrange(). Principalmente porque se reducen las llamadas a métodos de 28 a 15 (restando las utilizadas para el profiling).

Además utilizando pyrex para generar código para el Python C API se reduce a 0.008 pero el código es idéntico al de Juan Pablo con lo cual sólo hace dos llamadas a métodos.

Aún así la respuesta más simple, casi siempre es la más acertada, por lo tanto el código de Pablo debe ser mucho más rápido por ser ANSI C y no depender de algún intérprete. Pero creo que es el approach adecuado.

1
2
3
4

#include <stdio.h>
int main() {
  printf("%ld\n", 4613732);
}

Sin tantos rodeos >:-)

Pero por otro lado:

@Michoacano,
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946 17711 28657 46368 75025 121393 196418 317811 514229 832040 1346269 2178309 3524578 5702887

Esos son los números de la secuencia, creo que optimizar 36 condiciones no haría tu programa más rápido de lo que ya es.

Te sugiero que observes 2, 8, 34, 144, 610, 2584, 10946… el patrón es (comenzando con el 2), un número par seguido de dos impares. O lo que es lo mismo, un par cada posición divisible por 3 (comenzando en 1). La forma “óptima” de resolverlo, la forma matemática, sería primero definiendo la función f como:

f(1) = 1, f(2) =1, f(n) = f(n-1) + f(n-2)

Después iterando naturales de la forma 3k, comenzando con 1 y mientras f(3k) < 4000000 que no se cual k corresponda pero debe ser como ~10.

Esa es la solución matemática mas “limpia” que se me ocurre y la baso en que el patrón que observamos en el que cada f(3k) es par, sin embargo, para computación la recursión es cara y sería más lenta en éste caso. La optimización en el programa de pablasso sería cambiar la c%2 por un i%3 donde i es entero, es un módulo a un número más pequeño y practicamente no tendría diferencia en velocidad.

Lo de f(3k) es verdadero y se puede demostrar por inducción. Como es parte de mi carrera y además me gustan mucho esas ñoñerías, lo acabo de demostrar en papel, si alguien está interesado en los detalles de la demostración podría transcribirla ya que no es muy larga.

La cosa es solucionar el problema en menos del tiempo que establecen en el proyecto (y si una solución en 1 milésima de segundo con las condiciones del problema, vamos, mala no es), y entonces puedo optimizarlo para situaciones extremas.

En fin, cualquier punto de vista es válido :-)

@izaac Gracias por la versión pythonesca, te lo pongo con las tags correctas para código (pre con atributos lang)

http://dpaste.com/hold/52192/