El problema FizzBuzz
 

Propongo realizar este problema:

No hagas trampas y controla el tiempo que tardas en hacerlo.

Hola.

sería algo así?

Código Delphi [-]
var
  i
  ,OldVal: Integer;
  NewVal: Extended;
  Str: String;
begin

   OldVal := EdtInput.Value;  //TIntEdit

   for i := 1 to OldVal do
   begin
      Str:='';

     NewVal := i / 3;

     if round(NewVal) = NewVal then
        Str:= 'Fizz';

        NewVal:= i / 5;

       if  round(NewVal) = NewVal then
        Str:= Str+'Buzz';

       if Str = '' then
        Str:= IntToStr(i);

       MmOutput.Lines.Add(Str); //TMemo
     end;
 end;

Ummmmmmm.... ¿esto tiene trampa?

Si lo he entendido bien el código sería este:

Código Delphi [-]
procedure TForm1.Button1Click(Sender: TObject);
var
n: SmallInt;
m: Currency;
begin
  for N:=1 to 100 do begin
    if (N mod 3= 0) and (N mod 5=0) then begin
      ListBox1.Items.Add('FizzBuzz');
    end else if (N mod 3= 0) then begin
      ListBox1.Items.Add('Fizz');
    end else if (N mod 5= 0) then begin
      ListBox1.Items.Add('Buzz');
    end else begin
      ListBox1.Items.Add(IntToStr(N));
    end;
  end;
end;

el resultado sería este:



y el tiempo ha sido dos minutillos y pico. ¿Es mucho? :o

Esto es un problema que piden en algunas ocasiones las empresas que buscan programadores, se trata de ver cómo lo hacen, el tiempo que necesitan para hacerlo, la optimización, "los detalles", etc.
Por ejemplo, está más optimizado para el bucle usar un smallint que un integer, incluso mejor todavía un byte, si fuese posible.
No son necesarios decimales, así que se pueden usar tipos de datos acorde a eso.
Si el programa hace lo mismo pero con muchas menos líneas, es otro buen punto a favor.
También dicen que si se tarda al menos 10 minutos es que ese programador no es válido, sin embargo, tiempos de menos de 3 minutos es un programador muy recomendable.
No quiere decir que porque tenga menos líneas va a ser mejor, puede ser un código muy ofuscado y no convenga a la empresa, puede ser más recomendable algo intermedio.
En fin, que depende de para qué empresa, puede ser más interesante uno u otro.
Desde luego que newtron, para no ser programador, ha tardado muy poco :)
Por poner un par de ejemplos:

Programador 1:Programador 2:
Hay diferencias, ¿no creen?

Ya me ha entrado una depresión... me iré a llorar a alguna esquina. :cool:

Si tu código está muy bien, y lo has hecho rapidísimo, está muy bien, la verdad.

El código ese en lenguaje c es como lo hubiese hecho yo, seguramente, pero queda demasiado "ofuscado" para uso normal, depende de para qué puesto de trabajo optara, habría hecho casi lo mismo que has escrito tú, en delphi.

Discrepo totalmente. En realidad esto de las optimizaciones dependerá del lenguaje, del compilador y la arquitectura de la computadora en donde se compila.
En Delphi y a 32 bits, es mucho más efectivo hacer un for sobre un integer que sobre un Byte o un SmallInt.
Internamente el byte como SmallInt trabajan sobre el tipo integer, dejando en cero lo bytes restantes, y cuando se utilizan estos tipos se hacen conversiones indirectas desde y hacia el tipo integer.
El tamaño del integer corresponde justo al tamaño del registro de la CPU y las micro-operaciones para el for se valen de éstos registros... son bien aceleradas.
Utilizar byte o smallint simplemente lo hace más lento ya que debe hacer estas conversiones que le malgastan unos ciclos, y por apenas un byte no vale la pena intentar ahorrarse memoria en tipos numéricos menores... ¡porque no te la ahorras!

Si alguien pretendiera utilizar un tipo de dato real, sea de punto fijo o flotante, para este ejercicio es un semerendo tonto; por no decir algo más pesado :D Si no hay siquiera alguna pizca de referencia o indicio de que se requiera de números reales, ¿quien se pondría a agregar variables de estos tipos?
Discúlpame por mi falta de tacto, pero creo que hasta un recién iniciado se da cuenta.... hay que ser muy bestia. :D

Saludos,

Era sólo un ejemplo por darlo a entender :)

Creo que necesitas otras vacaciones, amigo Delphius :D



p.d.: aunque está bien la aclaración, por supuesto.

¿Tu crees? Y ya decía yo en FB si era válido tomarse unas vacaciones para descansar de las vacaciones :D :p Esto me pasa por llevarme parte del trabajo conmigo... y a NewDelphius. Ese cuate me está llevando por mal camino :D

Bueno, es que el ejercicio es muy elemental... mientras no te avientes retos como los de Al y de Roman, estamos bien. :rolleyes: :D

Saludos,

Hola.

Aún siendo de el grupo de los "bestias" sé que algo nuevo aprendí. ;);)

Pues sí, siempre se aprende algo nuevo :)

con Javascript

Versión 2:

Un lenguaje que inventé hace un tiempo y que, por fin, le he encontrado una aplicación (si aceptan un presupuesto que he hecho, claro ;) ):

"Ahora vas y lo cascas" :cool::D

Explicación:

Este lenguaje es, en realidad, el "Ensamblador" de una máquina virtual basada en pilas, al estilo FORTH. DUP duplica el elemento en la cima de la pila, mientras que SWAP intercambia los dos valores de la cima. Los operadores extraen uno o dos elementos de la pila, lo operan y lo devuelven a la pila; y son los normales (+, -, >, <...) siendo "%" el cálculo del resto en una división entera. "CALL" llama a una rutina (WRITE y WRITELN en este caso). @ apila en la pila de código (separada de la pila de datos, como en FORTH) la dirección de dicha arroba, mientras que RET desapila la cima de la pila de código en el registro de ejecución.

Vamos, muy sencillo.:rolleyes:

El código puede optimizarse duplicando e intercambiando los resultados de las operaciones (que en principio es más rápido que calcular el módulo y hacer comparaciones), pero entonces ya te lías...

Sí, ya se ve que es muy sencillo :o :D

Ya dije en otro sitio lo de que sencillo no significa fácil y tal... De todas formas, a los que les guste el Ensamblador deberían entenderlo puesto que, aunque casi todos los microprocesadores están basados en registros, el manejo de pilas está al orden del día. Es más, casi todas las instrucciones de mi lenguaje tienen correspondencia directa con instrucciones ensamblador de casi cualquier micro, aunque eso de usar dos pilas separadas, una para datos y otra para direcciones de retorno, puede dar algún que otro dolor de cabeza.

No, si no es que me parezca complicado, es sólo que no me veo programando una gestión de stock de almacenes con ese lenguaje :)

Y digo yo.. ¿pa que lo haces a pilas puediendolo hacer a corriente? XDD

Oyes, pues yo pensaba que estabas hablando de pilas de lavar. :D

Que vivan las palabras polisémicas. :D

Eso te pasa por no usar "stack", que queda más 'pofesional' y finolis :)

Pues yo ya estaba viendo las "stacks" de lavar unos encima de otras. :p

No es por nada, pero nos estamos desviando del tema un poco así y eso... :D

¿Cuál tema? :confused: Ah, sí. El tema. :p

Yo también inventé un lenguaje, muy humano e intuitivo. Así sería la solución:

Se llama Turbo Patrás. :p

Pues parece el sonido de una granja, distingo a las vacas, los perros, los gatos, las gallinas poniendo huevos y algún caballo relinchando por ahí atrás :)