[Sintaxis] sumar numeros de una lista

[Joseg]

❞ @Joseg, reto conseguido y muy curiosa la solución. ---------- Post añadido : 14:35 ---------- Post anterior : 14:17 ---------- Va analizando cada combinación en binario. Es decir: 0 1 01 11 001 101 011 111 * * * 1111111111111 (hasta las posiciones que se configuren, en este caso 12) Y va sumando en cada combinacion con los elementos de la lista dada y comprobando si da el resultado buscado. ¡ Muy Curioso ! pero eficiciente. Ya lo he modificado para 30 elementos y lo he puesto en un windows y en un linux, a ver lo que tarda ¡¡¡ ---------- Post añadido : 20:18 ---------- Post anterior : 14:35 ---------- Para vuestra información y curiosidad. (buscando con 30 elementos) ( 2^30-1 combinaciones) Compilado en RM/cobol y ejecutado en windows y linux. Después de 7 horas esperando: 1) el proceso de windows 10 (64 bits) lleva un 30% 2) el proceso en linux (virtual) con 8 CPUs lleva un 45% He realizado lo mismo en C. Lo he ejecutado en el linux. Ha tardado 2,5 minutos. Ya lo esperaba pero me ha sorprendido tan poco tiempo. Me gustaria que hicierais lo mismo en otros COBOL para ver como son de rápidos en estas cosas. Hacedlo para 30 elementos, modificando el programa de @joseg o os lo envio. Por este motivo yo muchas veces implemento rutinas en C para obtener mejores resultados aunque no sean valorados.

Experimente o GnuCobol (traduz de cobol para C). É muito rápido.
Mas a rotina acima que mandei pode ser muito mais optimizada e não fazer tantos cálculos.
Substituir os CPMP-3 por COMP-5 (formato decimal é mais lento que o formato binário).
Se usar apenas números inteiros, deve de ajustar o PIC (aumenta a velocidade).

[JCantero]

❞ @JCantero, el problema de rendimiento debe venir del hecho que la rutina de @Joseg (a diferencia de tu rutina en C) no usa campos nativos. Los COMP y COMP-3 deben reemplazarse por unos COMP-5 (de 2-4-8 bytes) para corresponder con la plataforma. Esto acelerará mucho el asunto.

Si, eso fue lo primero que hice pero ese no es el problema.

El problema es que rmcobol es interpretado, pongas lo que pongas es lento. Luego probare con Acucobol que seguro que va mas rápido.

C es practicamente lenguaje maquina (como ensamblador) y no se puede comparar con ningún lenguaje excepto con ensamblador en cuestión de rapidez.

[Kuk]

@JCantero, todo depende del compilador. Si el compilador obtiene código máquina optimo, no importa el lenguaje.

Efectivamente se necesitaría un binario nativo, yo nunca he usado RM (aunque sabía que produce una especie de bytecode, como Java, y por ello los ejecutables son válidos en cualquier SO).