El problema FizzBuzz
Propongo realizar este problema:
Cita:
|
Hola.
sería algo así?
|
Ummmmmmm.... ¿esto tiene trampa?
Si lo he entendido bien el código sería este:
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: Código:
public class FizzBuzz Código:
for(int i=0;i<100;printf(i%3==0?i%5==0?"Fizzbuzz":"FIZZ":i%5==0?"BUZZ":"%i",i++)); |
Cita:
|
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. |
Cita:
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! Cita:
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. |
Cita:
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í. ;);) |
Cita:
|
con Javascript
Código:
<script> |
Versión 2:
Código:
<script> |
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 ;) ):
Código:
0 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... |
Cita:
|
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
|
Cita:
|
Que vivan las palabras polisémicas. :D
|
La franja horaria es GMT +2. Ahora son las 06:36:12. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi