Ver la Versión Completa : Help!
Soy nuevo programando en este lenguaje, y tengo un gran problema. El miercoles necesito entregar un programa y no tengo ni P... idea de como plantearlo con :confused: Sentencias Repeat-Until o cualquiera de las variantes.
El Programa es el siguiente.
Determine si un numero "N" Entero y Positivo, leido como dato es o no un numero primo, sin emplear la multiplicacion, ni la división en ninguna de sus variantes, ni una funcion o procedimiento estandar de Turbo Pascal.
Si alguien logra realizar el programa, le agradeseria que me envie los Algoritmos a mi mail atomo_bg@hotmail.com
Thanks ;)
Julià T.
03-06-2003, 00:03:09
Sin utilizar ninguna variante de división (ni "/" ni "div" ni "mod") lo único que se me ocurre es ir restando un número hasta que sea 0 o negativo
function esdivisiblepor(num, divisor):boolean;
begin
While Num>0 do Num:=Num-divisor;
//supongo que no se puede utilizar dec(num,divisor)
if Num=0 then Result:=True //es divisible por "divisor"
else result:=false;
end;
esdivisiblepor(10, 5) daria como resultado true
esdivisiblepor(49, 5) daria como resultado false
Ahora tan solo te queda emplar un bucle, para ir comprovando para cada divisor que sea necesario
delphi.com.ar
03-06-2003, 00:29:47
Hola zeox, te propongo que escribas la solución en el lenguaje que mejor conozcas, y seguramente muchos foristas, en los cuales me incluyo, van a estar gustosos de traducirla.
Saludos!
roman
03-06-2003, 00:49:25
Posteado originalmente por delphi.com.ar
Hola zeox, te propongo que escribas la solución en el lenguaje que mejor conozcas...
¿Español? :D
marto
03-06-2003, 01:03:36
function EsPrimo(Num: Integer): integer;
var
temp, i, integer;
enc: boolean;
begin
i := 2;
enc := false;
while (i < N - 1) and not Enc do begin
temp := N;
while Temp > 0 do Temp := N - i;
if N = 0 enc := true;
Inc(i);
end;
return Enc;
end;
No lo he probado, pero eso debería funcionar.
marto
03-06-2003, 01:14:43
Joer, estos problemas siempre me divirtieron, si te quieres quedar con tu profe preséntale esto:
function EsPrimo(Num: Integer): Boolean;
var
temp, i, integer;
enc: boolean;
begin
i := 3;
enc := N and 1 = 0;//es par
while (i < N - 1) and not Enc do begin
temp := N;
while Temp > 0 do Temp := N - i;
if N = 0 enc := true;
i := i + 2;
end;
return Enc;
end;
Bueno, las sugerencias estan muy buenas, voy a dapurar los posibles errores. Gracias.
P.D: Basicamente la lógica de programacion es igual en todos los lenguajes (incluyendo el Español jajaja) tu comentario no estuvo acertado Moderador. See u
Julià T.
03-06-2003, 02:15:46
La solución de marto, es muy buena, no le veo ningún fallo. Tan decir que 1 y 2 son primos (esto según criterio).
Releyendo creo que el 3 no le considera primo
Julià T.
03-06-2003, 02:18:20
ignorar mi respuesta anterior, se me ha ido la mano cuando estaba revisando el código de marto.
para solucionar, pongo el código depurado que incluye el dos como primo
function EsPrimo(N: Integer): Boolean;
var
temp, i: integer;
enc: boolean;
begin
i := 3;
enc := N and 1 = 0;//es par
while (i < N - 1) and not Enc do begin
temp := N;
while Temp > 0 do Temp := Temp - i;
if Temp = 0 then enc := true;
i := i + 2;
end;
result:=(not Enc) or (N=2);
end;
delphi.com.ar
03-06-2003, 02:51:47
Hola zeox, acerca de esto:
Posteado originalmente por zeox
tu comentario no estuvo acertado Moderador.
Te recomiendo que leas la Guía de Estilo (http://www.clubdelphi.com/users/llsoft/Docs/GuiaEstilo.php), y el debate aquí (http://www.clubdelphi.com/foros/showthread.php?s=&threadid=971) planteado y entenderás el porqué de mi mensaje. ;)
Saludos!
Si que se considera el 2 como primo en la sentencia
Enc := N And 1
Esto lo que hace es aplicar una máscara de bits al numero. Como en binario todos los numeros pares acaban en 0, Enc valdrá 0 si es par, y 1 si es impar.
y si quieres ahorrarte la mitad de vueltas en el bucle, puedes transformar:
while (i < N - 1) and not Enc do begin
en:
while (i < (N>>1)) and not Enc do begin
Esto divide N entre 2, ya que seguro que no habrá numeros que puedan dividir a n entre n/2 y n. El >> (right shift, o decalado) es un operador de C, seguro que delphi tambien lo tiene, pero no me acuerdo que pinta tenia. Es una division encubierta, pero válida.
Para hacerlo del todo chulo se podria ir hasta la raiz cuadrada de n (ya que hay una propiedad que dicta que n tiene todos los primos entre 2 y sqrt(n)). Pero no se hacer raices cuadradas de una forma mas o menos decente con las restricciones impuestas.
Seguiré pensando... ;)
He mirado como era el decalado en Delphi/Pascal. la instruccion es shr (y shl tambien para el decalado a la izquierda)
asi que quedaria como (N shr 1) en vez de (N >> 1)
Salu2
roman
03-06-2003, 16:16:24
Posteado originalmente por pplu
while (i < (N>>1)) and not Enc do begin
Esto divide N entre 2...
Exacto, pero los requisitos originales indican que no se puede usar la división en ninguna de sus variantes.
// Saludos
No creo que desplazar a la derecha sea una variante de dividir... es simplemente desplazar los digitos en base 2, pero por esas casualidades de la vida... estamos dividiendo entre 2. Igual que si en decimal desplazas los digitos a la derecha una posicion: lo que consigues es dividir entre 10
Si lo miramos bien, en el fondo éste bucle esta dividiendo
while Temp > 0 do Temp := Temp - i
si lo escribimos asi (que es equivalente, pero que dá una vuelta menos, que ya de paso seria una optimizacion posible de este bucle)
while Temp > i do Temp := Temp - i
resulta que restamos un numero [i] [x] veces. Y un numero n se puede expresar como n = i x + r . que es una division si lo escribimos asi:
n |__i___
r x (esto pretende ser un esquema de division)
en el algoritmo perdemos x (que es el numero de vueltas que da el bucle), y temp acaba siendo r (que si es 0, hemos encontrado un multiplo), por lo que quieras que no, estas dividiendo de una forma encubierta.
No encuentro ninguna diferencia entre hacer esta operacion y un desplazamiento de bits. Todo es dividir de una forma u otra. ¿estais de acuerdo conmigo?
Otra pequeña optimización que nos ahorraria una vuelta en el bucle seria:
while Temp >= i do Temp := Temp - i;
if Temp = i then enc := true;
Esto nos ahorra una vuelta en caso de que el n sea divisible entre i.
Y aqui llegará la discusión ¿estamos dividiendo, o solo restando / desplazando bits?
Por la misma regla de tres, el (n and 1) tambien es dividir de una forma encubierta.
Solo estamos quitando los bits que son multiplos de 2 dentro del numero n (que son las posiciones 1 a 31 de un numero binario de 32 bits. Eso, a mi entender es dividir. Si lo queremos enfocar de otra manera, la operacion (N and 1) esta haciendo un (N mod 2). Y un mod es el resto de la división entera, por lo que tambien estamos dividiendo....
¿Que opinais? ¿El algoritmo está mal de base?, y ya por curiosidad... ¿alguien conoce algun metodo más sano (y mas optimo) de resolver el problema?
Salu2
roman
03-06-2003, 17:45:34
Como digas pplu. Me queda la curiosidad de ver qué dice el maestro en caso de que zeox decida utilizar tus argumentos ya que lo que de ellos se deduce es que la tarea es imposible.
:D
// Saludos
Yo lo que entiendo del enunciado es que no dividas mi multipliques. Como variantes de division entiendo el div y el mod. Como variantes de multiplicacion entiendo la exponenciación. Quizas para el maestro lo que estamos haciendo es dividir (aunque no lo creo).
Tampoco creo que dados mis arguentos el problema sea imposible. Quizas solo estemos emperrandonos en querer dividir de formas alternativas sin pensar en otros metodos. Quizas solo lo hemos atacado el problema desde un angulo incorrecto.
andres1569
03-06-2003, 18:34:38
Hola:
Recapitulando un poco. Tomando los ejemplos que se han mostrado aquí y retocando algo, queda este código:
function EsPrimo(Num: Integer): Boolean;
var
temp, i : integer;
begin
i := 2;
result := TRUE;
while result AND (i < Num - 1) do
begin
temp := Num;
while Temp > 0 do Temp := Temp - i;
result := Temp < 0;
i := i + 1;
end;
end;
No vale incrementar i en 2, puesto que eso esquiva la prueba para algunos números que sí dan múltiplo.
pplus escribió:
while Temp > i do Temp := Temp - i
resulta que restamos un numero [i] [x] veces. Y un numero n se puede expresar como n = i x + r . que es una division si lo escribimos asi:
n |__i___
r x (esto pretende ser un esquema de division)
Está claro que cualquier algoritmo simulará una división, puesto que lo que define a un número primo es que no sea divisible exacto salvo por 1. Pero de lo que se trata es de no emplear operadores de división.
No encuentro ninguna diferencia entre hacer esta operacion y un desplazamiento de bits. Todo es dividir de una forma u otra. ¿estais de acuerdo conmigo?
...
Que opinais? ¿El algoritmo está mal de base?,
El algoritmo es bueno, pensé en un momento que habría alguna fórmula recursiva, pero no se me ocurre. Quizás una optimización sería que solo probáramos de restar con números ya primos (lo cual parece una optimización pero nos llevaría quizás mas tiempo el buscar esos números cada vez).
La cuestión es que no se deben utilizar operadores de división, ni /, ni sus variantes para números enteros (Div y Mod), pero tampoco "AND 1" ni "shr", que hacen lo mismo. De todas formas, estos operadores se utilizan para reducir el número de bucles, afectan al rendimiento, no a la validez del algoritmo, así que soy partidario de suprimirlos, no sea que eso le cueste la prueba.
Además, zeox dice que no tiene "ni P*** idea", creo que le conviene presentar un algoritmo que funcione pero que no parezca tomado de ningún foro.
Un saludo
Andres, estoy de acuerdo con tu solucion. Es más academica y menos retorcida que la mia, pero tambien es mas lenta. Te comento la mia, que al final queda asi:
function EsPrimo(Num: Integer): Boolean;
var
temp, i, integer;
enc: boolean;
begin
Enc := (N and 1) = 0; //Aqui se dice si es divisible entre 2 y de paso se inicializa Enc
i := 3; // ya hemos comprobado los pares
while (i < (N shr 1)) and not Enc do begin //Aqui vamos hasta n/2
temp := N;
while Temp >= i do Temp := Temp - i; //Aqui "dividimos"
enc := (Temp = i); //Es divisible por i
i := i + 2;
end;
return Enc;
end;
y ya estaria la cosa resuelta
Comentarios: Si que se puede incrementar [i] de 2 en 2 porque antes ya has descartado todos los posibles multiplos de 2 con:
Enc := (n and 1) = 0
La mia es basicamente la tuya pero con las siguientes optimizaciones
- primero comprobar que sea multiplo de 2 (para asi poder incrementar i de 2 en 2)
- solo comprobar [i]s hasta n/2 (en ausencia de un sqrt(n)
- cambiar la condicion del while interno para que se ahorre una vuelta (y modificar la comprobacion de acuerdo con el cambio).
Y como ultima optimizacion que se me ocurre de momento es sacar una operacion que se mantiene invariante dentro del bucle
function EsPrimo(Num: Integer): Boolean;
var
temp, i, hasta, integer;
enc: boolean;
begin
Enc := (N and 1) = 0; //Aqui se dice si es divisible entre 2 y de paso se inicializa Enc
i := 3; // ya hemos comprobado los pares
hasta := N shr 1; // sacamos la condicion invariante
while (i < hasta) and not Enc do begin //Aqui vamos hasta n/2
temp := N;
while Temp >= i do Temp := Temp - i; //Aqui "dividimos"
enc := (Temp = i); //Es divisible por i
i := i + 2;
end;
return Enc;
end;
Sacando el (N shr 1) de la condicion del while, no se evaluará en cada vuelta del bucle, ahorrando asi, un poquito de tiempo (aunque los procesadores de hoy en dia ejecutan un shr en un ciclo...)
Algo es algo... :)
Julià T.
03-06-2003, 19:37:45
pplu no nos podemos olvidar del 2. A mí me eseñaron que el 2 era primo (también me eseñaron que el 1 era primo pero he sentido versiones para todos los gustos).
En cualquier casos creo que zeox deberia publicar el código que entregará al maestro y els resultado para quedarnos todos tranquilos
El dos no se me olvida:
Enc := (N and 1) = 0; //Aqui se dice si es divisible entre 2 y de paso se inicializa Enc
Esto hace un (n mod 2) encubierto... que es lo mismo que comprobar que n es divisible entre 2
Lo he razonado en un reply arriba.
andres1569
03-06-2003, 20:01:29
Hola:
Faltan dos cosas, aparte de que devuelva también el 2 como primo:
While Temp >= i ... debe cambiarse por
while Temp > i ..., para que cuando sea Temp = i no siga decrementando, si no falla la sentencia siguiente.
La última sentencia de la función debe ser result := NOT Enc (puesto que enc es TRUE si se ha encontrado un múltiplo).
Con esto el algoritmo funciona perfectamente y es bastante bueno, lo de dividir por 2 el número de comprobaciones nadie lo discute, reduce el tiempo de resolución, sólo que el interesado nos puso algunas condiciones en el primer mensaje.
Saludos
Posteado originalmente por andres1569
Faltan dos cosas, aparte de que devuelva también el 2 como primo:
While Temp >= i ... debe cambiarse por
while Temp > i ..., para que cuando sea Temp = i no siga decrementando, si no falla la sentencia siguiente.
Jejeje... pues si... muchos ojos (y cerebros) son mejor que uno :p
La última sentencia de la función debe ser result := NOT Enc (puesto que enc es TRUE si se ha encontrado un múltiplo).
Con esto el algoritmo funciona perfectamente y es bastante bueno, lo de dividir por 2 el número de comprobaciones nadie lo discute, reduce el tiempo de resolución, sólo que el interesado nos puso algunas condiciones en el primer mensaje.
[/B]
Tambien tienes razón.
Pues creo que ya tenemos una solucion bastante guapa
Salu2
Bueno, gracias por todos sus comentarios, aqui les muestro los algoritmos que use para salucionar el problema.
Var
A,B,C:longint;
D:boolean;
begin
A:= strtoint(edit1.text);
D:=False;
for B:=2 to (A div 2) do Begin
C:=A;
Repeat
C:=C-B;
Until C<=0;
if C=0 then
D:=True;
end;
if D then
label2.caption:='El Número no es Primo'
else
label2.caption:='El Número es Primo';
end;
{Recuerden que soy nuevo en el Mundo de la Programación, soy estudiante de Ingeniería de Petróleo y también soy nuevo en el mundo de la programación.}
//Thanks! ;)
Julià T.
03-06-2003, 23:42:39
Lo siento zeox pero el div es una forma de división
Cuando Utilizo el operador Div lo estoy haciendo como condicion del contador del Ciclo, no para alla el numero primo como tal como tal
delphi.com.ar
04-06-2003, 00:19:11
No creo que sea una respuesta válida, el enunciado excluye categóricamente el uso de la división, sin importar el uso de la misma.
No te parece algo así:function IsPrime(ANumber : Integer) : Boolean;
var
iDiv,
iTmp : Integer;
begin
Result := True;
for iDiv := 2 to ANumber - 1 do
begin
iTmp := ANumber;
while iTmp > 0 do
iTmp := iTmp - iDiv;
if iTmp = 0 Then {Si el "Resto" es cero}
begin
Result := False;
Break;
end;
end;
end;
Podrías optimizarlo agregando la comprobación del último Bit como te informaron anteriormente, y evitarías un procesamiento innecesario para los números pares.
En vez de hacer (n div 2) haz (n shr 1) son equivalentes a nivel funcional, y nadie se podra quejar que el shr es un derivado de la division
Me ha parecido un poco ofensivo que pusieras alli ese div despues de lo que se ha llegado a discutir en el foro :(
Como ultimo, y para comentar una variante cachonda (y posiblemente imposible a nivel físico), pero poco practica (a todos los niveles). Pero que demuestra que para optimizar en velocidad a veces has de "desoptimizar" en memoria ocupada....
// v sera un vector de booleanos
v := [true, true, true, false, true, false, true, false, false, false, true, .......................................]
EsEntero:= v[n - 1]; //tengamos en cuenta que las tablas empiezan en indice 0
Se puede tener una tabla estática de booleanos en la que cada posicion de la tabla representa si esa posición es prima. La longitud de la tabla es el rango máximo de un Integer
Esta solucion no requiere dividir ni nada parecido... eso si... requiere tiempo... para picar la tabla ;)
(Siento esta enorme ida de olla)
¿comentarios?
andres1569
04-06-2003, 01:21:49
pplu escribió:
Esta solucion no requiere dividir ni nada parecido... eso si... requiere tiempo... para picar la tabla
¿Picar la tabla? Se puede inicializar, recorriendo todos los integers y mirando si son primos; hay una decena de rutinas por ahí circulando que devuelven si un número es primo, la de Julián, la de pplu, la de Delphi.Com.Ar ..., la de zeox (lo malo de esta última es que emplea la instrucción Div pero a lo mejor eso da igual).
:D :eek: :eek: :D
Saludos cordiales
marto
04-06-2003, 01:45:18
Posteado originalmente por andres1569
¿Picar la tabla? Se puede inicializar, recorriendo todos los integers y mirando si son primos;
Estoooooo andres, tu tienes muuuuuuuuuuuucha memoria en tu PC, no? :D
Julià T.
04-06-2003, 02:16:10
para generar la tabla se requerirá una función para determinar si el numero es primo o no, por lo que volvemos al principio de todo, ... como calcular si un número es primo o no
por cierto ¿esta cadena de mensajes acabará en número primo ?
Calcular si un numero es primo o no es lo más facil del asunto. Hay mil algoritmos más eficientes que el propuesto en el foro.
Incluso hay una función con la que es posible calcular el [n]esimo numero primo. (Aunque creo que está por demostrar, pero que funciona hasta numeros muuuuy gordos (estamos hablando de mas de 32 bits)
Una función genera la tabla en forma de código de Pascal (yo sinceramente paso de inicializar la tabla cada vez que arranque el programa, porque seguramente se tarde muuucho).
Ahora solo nos queda editar ese fichero y ponerle la funcion EsPrimo...
Parece fácil, pero creo que hemos de pensar en la cantidad de datos que estamos manejando. Sobre el papel, y en la cabeza la cosa va bien... pero...
Cuanto ocupa un Boolean en Deplhi? Ahora no lo recuerdo bien, pero os voy a exponer los posibles casos
- 1 bit
Esto es lo primero que se nos ocurre (pero tambien lo menos probable, ya que las memorias, como unidad mínima leen bytes (o grupos de bytes))
Tenemos que almacenar 2^32 booleanos dentro de la tabla
por lo tanto 2^32 bits que ocupamos en memoria.
2^32 bits = 4294967296
4294967296 / 8 bits por byte = 536870912 bytes
536870912 bytes = 524288 KBytes
524288 KBytes = 512 MBytes
No esta mal... eso solo es la tabla... pero de momento es posible... porque el codigo ocupa muy poco
Ahora pongamonos en el caso de que un Booleano ocupara 1 Byte. Sacamos la 'calcu' y sorpresa! 4GBytes justos... Ni más ni menos...
Esta cifra ya me suena fatidica... Nuestros queridos PC's pueden direccionar como máximo 4GB de memoria RAM. No nos queda espacio para el código (ni el SO):mad:
Y ya no hablemos si son words (Enteros 16bits (2 bytes)) o dwords (Enteros de 32 bits (4 bytes)).
Me direis: Como puede un booleano derrochar tantos bits cuando solo necesita uno? Pues facil... es más cómodo para nuestros procesadores leer un byte, word o dword que 1 bit de la memoria... porque la memoria solo transfiere bytes, words, o dwords y despues se ha de hacer la comprobacion del bit de la posición que toca
Se que la palabra reservada packed sirve para comprimir estos booleanos de forma que no derrochen bits... pero no me acuerdo en que casos es aplicable...
Por cierto... si alguien genera la tabla, que me la queme en CD, y me la envie :p
Salu2
Julià T.
05-06-2003, 01:29:48
calculando los números primos que hay del 1 al 1.000.000 he encontrado 78500-1 (78499) los he dejado en
http://juliatorrijos.wanadooadsl.net/primos.rar
Cuanto tardaste en generar todos estos primos?
Con que algoritmo?
Salu2
Julià T.
05-06-2003, 23:48:38
Tarda unos 10 segundos en un portátil PIII celeron 1100
function TForm1.esprimer(Num: integer): boolean;
Var
Temp,Cont:integer;
begin
Result:=True;
if Num in [1..2] then exit;
if (num and 1)=0 then Result:=false;
Temp:=Round(Sqrt(Num));
Cont:=3;
while (Cont<=Temp) and Result do
begin
if (Num mod Cont)=0 then Result:=false;
inc(cont,2);
end;
end;
procedure TForm1.Button1Click(Sender: TObject);
Var
Min,Max,i:integer;
begin
memo1.Lines.Clear;
Min:=StrToIntDef(Edit1.Text,1);
Max:=StrToIntDef(Edit2.Text,1000000);
memo1.Visible:=false;
for i:=Min to Max do
if EspRimer(i) then memo1.Lines.Add(inttostr(i));
memo1.Visible:=True;
label1.Caption:=Inttostr(Memo1.Lines.count);
end;
gatosoft
06-06-2003, 00:14:29
Los matematicos mantienen un discusión "erudita" sobre la "Primalidad" del uno... ser primo o no ser primo...
pero indiscutiblemente el 2 es primo... siempre, toda la vida... es inconsebible decir que no lo es...
Julià T.
06-06-2003, 00:20:39
la función que he realizado considera tanto al 1 como al 2 primos
Julià, ¿te atreves a generar todos los primos hasta el (2^32)-1?
A mi me da un poco de miedo porque el tiempo me parece que crece exponencialmente. Tendriamos que llegar al 4.294.967.295. Y solo hemos generado hasta el 1.000.000
Resulta que solo llevamos el 0,02% de la tabla hecha...
Podriamos intentar con un algoritmo que fuera guardando los primos encontrados dentro de un array y ir dividiendo solo entre esos..
Podemos inicializar tranquilamente el array con el 2 y 3 en la primera y segunda posicion (ya vereis porque no meto al 1 en el saco)
procedure EncuentraPrimos()
arrayPrimos := [2,3];
arrayPrimosLibre := 2;
For probando:=5 to 4294967295 step +2 do begin
i = 0
while (arrayPrimos[i]<sqrt(probando)) And (not Divisible) do
if (probando mod arrayPrimos[i] = 0)
Divisible: = true;
else
i++;
end
if not Divisible begin
arrayPrimos[arrayPrimosLibre] = probando;
arrayPrimosLibre++;
(*)
end
end
end;
Cuidado: Tenemos que usar unsigned integers. para llegar a (2^32)-1
Se que el codigo no es perfecto... lo he escrito tal y como me salia... y posiblemente haya mezclado lenguajes... pero creo que se entiende lo suficiente
Intento recorrer la tabla de primos desde la posicion 0 hacia delante, porque me parece más probable que el numero que estemos probando sea divisible por los numeros más bajitos. Estais de acuerdo conmigo?
He sacado el 1 fuera de la tabla de primos por razones obvias, y ya puestos podriamos sacar el 2, porque no vamos a caer nunca en numeros pares :)
Y ya se que los arrays no son tan genersos... habria que redimensionarlo cada tanto en cuanto... yo lo haria de 1000 en 1000 posiciones de golpe... asi ahorramos tiempo precioso... y solo tenemos que hacer
if (arrayPrimosLibre mod 1000 = 0) SetLength(arrayPrimos, arrayPrimosLibre + 1000);
donde he puesto el (*)
Si no, podemos intentar estimar el tamaño final que tendrá la tabla, y redimensionar en caso de "urgencia"
Os gusta?
Julià T.
06-06-2003, 02:22:45
hola pplu te animo a intentarlo con algún consejo
Te animo ya que he comprovado que no crece de manera "muy" exponencial 1.000.000 10-12 segundos 5.000.000 72 segundos
1- asegurarte que las funciones que escribes funcionen para números enters sin signo DWORD o Cardinal (si cuando llegas a la mitad se fastidia no veas)
2- utiliza la funcion sqrt para no realizar demasiados cálculos (así como màximo tendrás que comparar hasta el 65536) (o bien inicializa primero un array con los números primos del 2 al 65536 y comprueba con esta)
3- si lo guardas antes en un componente gráfico ponlo primero en visible:=fasle y visible al final ya que si tiene que redibujar aproximadamente unas 300.000.000 te vas hacer viejo (te va a tardar bastante en ponerse visible)
4- puedes dividir el trabajo en partes y guardar por ejemplo 400 ficheros de numeros entre 10.000.000 cada uno y parar cuando quieras y continuar otro dia
creo que mi enfermedad todavía es curable!!!
roman
06-06-2003, 04:52:06
Posteado originalmente por gatosoft
Los matematicos mantienen un discusión "erudita" sobre la "Primalidad" del uno... ser primo o no ser primo...
Quienes discuten la primalidad del uno son los no matemáticos. Para nosotros los matemáticos queda perfectamente claro que no es primo. Jamás he conocido matemático alguno que defina al uno como primo. Sin embargo es cierto que las razones por las que no se le considera primo no son esenciales:
Por un lado el término "primo" esta relacionado con "materia prima"- Los números primos son la materia prima para generar al resto mediante el producto (así pensaban los griegos) Dime, ¿cuántos números puedes generar con el uno mediante el producto?
La otra razón es para poder enunciar de forma "elegante" el teorema fundamental de la aritmética, a saber:
Todo número entero mayor que uno se puede expresar de manera única como el producto de un número finito de números primos salvo por el orden de los factores
Si el número uno se considerase primo, la unicidad que declara el teorema no sería posible y tendría que enunciarse así:
Todo número entero mayor que uno se puede expresar de manera única como el producto de un número finito de números primos distintos de unosalvo por el orden de los factores
// Saludos
roman
06-06-2003, 05:00:07
Posteado originalmente por pplu
...Si no, podemos intentar estimar el tamaño final que tendrá la tabla, y redimensionar en caso de "urgencia"
Esta parte la veo difícil. La distribución de los números primos es absolutamente arbitraria (teorema de Wilson)
A menos claro, que como parte del algoritmo busquemos en internet tablas ya hechas para saber cuántos hay menores que 2^32 :)
// Saludos
roman
06-06-2003, 05:04:23
Julià T
Una pregunta, el algoritmo que utilizaste ¿es como lo que se pedía o ya usaste productos?
// Saludos
andres1569
06-06-2003, 15:31:53
Hola:
Roman escribió:
Todo número entero mayor que uno se puede expresar de manera única como el producto de un número finito de números primos salvo por el orden de los factores.
Según este teorema, los números primos a partir del 1, (2, 3, 5, 7, 11 ...) no son "enteros mayores que uno" (es decir, quedan fuera del dominio del teorema) puesto que el único producto que nos permite obtenerlos es:
NumeroPrimo = NumeroPrimo x 1
Por favor, explícamelo, no dudo que tu respuesta será convincente.
Julià T.
06-06-2003, 16:30:46
hola roman: el algoritmo que utilizé no era el que pedia zeox, que era le que tenia que entregar el miercoles (anteayer). El codigo esta unos (6-10) mensajes arriba.
roman
06-06-2003, 17:13:44
Posteado originalmente por andres1569
Según este teorema, los números primos a partir del 1, (2, 3, 5, 7, 11 ...) no son "enteros mayores que uno" (es decir, quedan fuera del dominio del teorema) puesto que el único producto que nos permite obtenerlos es:
NumeroPrimo = NumeroPrimo x 1
Por favor, explícamelo, no dudo que tu respuesta será convincente.
Bueno, quizá no te guste la respuesta pero es que así se maneja en matemáticas:
Cuando se dice "un producto de un número finito" ese número puede ser uno, es decir, se consideran productos con un sólo factor. De la misma forma se consideran sumas con un sólo sumando.
// Saludos
andres1569
06-06-2003, 17:29:43
OK
chutipascal
06-06-2003, 21:06:41
....BRRR.....
Las matematicas están muertas...... :cool: y cada vez que se intenta justificar algo al final se encuentran con un callejón sin salida.
Lo tipico.....se ha tenido que redefinir el concepto de producto para que cuadre el bonito teorema....
Define el producto. :D
Un saludo.
Pascal.
Nota:¿ Lo de la suma de un solo sumando...es cosa de mi jefe... para hacerme creer que me ha subido el sueldo.?
Posteado originalmente por chutipascal
....BRRR.....
Las matematicas están muertas...... :cool: y cada vez que se intenta justificar algo al final se encuentran con un callejón sin salida.
Lo tipico.....se ha tenido que redefinir el concepto de producto para que cuadre el bonito teorema....
Define el producto. :D
Un saludo.
Pascal.
Nota:¿ Lo de la suma de un solo sumando...es cosa de mi jefe... para hacerme creer que me ha subido el sueldo.?
Respeto tu opión, pero no estoy de acuerdo en absoluto:
Si no quieres las matematicas para nada, ¿que haces delante de una calculadora sobredimensionada (entiendase PC)?
Si te niegas a ver una suma de un sumando, súmale 0 y ya estás apañado, tienes una suma de dos sumandos.
Sin las matemáticas no hubieramos llegado muy lejos como civilización y no veo que estén muy muertas. Que tu no veas como evolucionan no quiere decir que estén muertas.
Salu2
andres1569
07-06-2003, 13:51:31
Hola:
La informática se basa en las matemáticas. Si a Boole no se le hubiese ocurrido el álgebra binaria, quizás hoy estaríamos dedicándonos a ... ... bueno, se le habría ocurrido a otro, quizás a nuestro compañero Roman.
Ya me esperaba la respuesta de Roman, sólo deseo que esa definición de producto se aplique a todos los teoremas y no sólo donde convenga. No sabía que la raiz de "número primo" fuera "materia prima", me sonaba lo de números generatrices (aunque semánticamente no se parezca). De todas formas, tal como él mismo aclara, la definición de número primo no responde a razones esenciales.
Por eso que no son razones esenciales se hubiera podido enunciar el siguiente teorema, no referido a los números primos, sino al "número padre", el "1", así no se le relega a un lugar marginal que creo que no se merece:
"Todo número entero mayor que cero (sea primo o hermano) se puede expresar de manera única como la suma de un número finito del número padre sin importar el orden de los sumandos".
1 = 1
2 = 1 + 1
3 = 1 + 1 + 1
...
Así tenemos que el uno puede generar a todos los demás pero de una forma más lenta, muy parecida a la forma en que se han implementado en este hilo las funciones EsPrimo.
roman
07-06-2003, 18:22:46
Algunas aclaraciones:
Lo que no es esencial es si el uno es primo o no, pero la definición de número primo sí que es esencial (para las matemáticas)
Por otra parte lo de que si las matemáticas están muertas bueno, pues ¿qué se puede comentar? Como muestra un simple botón:
Sin las matemáticas (y sin la física, la ingeniería, la astronomía, etc., etc.) el hombre jamás habría llegado a la luna. En fin que, difícilmente habrá un área del conocimiento humano que se pueda desechar tan sólo por que no la entendemos, no nos gusta o no nos interesa.
Y, Andrés, bien podrías ser matemático. Lo del "número padre" más que un teorema, es, en esencia, la construcción formal de los números naturales tal como se hace en matemáticas. En realidad se usa el cero más que el uno pero corresponde a la construcción de Peano quien axiomatiza los números naturales como sigue:
1. El cero es número natural
2. Todo número natural tiene un sucesor que también es un número natural
3. El cero no es sucesor de ningún número natural
4. Distintos números tiene distintos sucesores
5. Si el cero tiene una propiedad y si cada vez que un número tiene la propiedad entonces el sucesor la tiene, se concluye que todos los números naturales tienen la propiedad.
La palabra clave aquí es sucesor. No se define ya que se trata de axiomas pero corresponde a la idea natural de sumar 1 al número anterior:
Sucesor(n) = n +1
(Incluso Delphi tiene la función sucesor :) )
¿Y por qué hay que axiomatizar esto?
Porque hay una infinidad de números naturales y no podemos describir todos ellos más que con los puntos suspensivos que escribe Andrés
1 = 1
2 = 1 + 1
3 = 1 + 1 + 1
...
El quinto axioma (el axioma de inducción) es la base para formalizar estos puntos suspensivos.
Este axioma es fundamental para la demostración de un sin número de teoremas en matemáticas (teoremas que van mucho más allá que simples números)
Luego de este breviario cultural le mando
// Saludos
roman
07-06-2003, 18:28:48
Por cierto, regresando a lo de las sumas de un sólo sumando. Vamos a suponer que en efecto, es tan absurdo que mejor lo desechamos. ¿Se imaginan cuántas consultas SQL
select sum(...) group by ...
tendríamos que desechar debido a los grupos con un sólo registro?
// Saludos
chutipascal
09-06-2003, 12:59:11
Posteado originalmente por pplu
Respeto tu opión, pero no estoy de acuerdo en absoluto:
Si no quieres las matematicas para nada, ¿que haces delante de una calculadora sobredimensionada (entiendase PC)?
El comentario que he hecho más arriba era simple provocación, no he dicho que no quiero las mates para nada, simplemente he dicho que estaban muertas, esperaba que con este comentario sobre esas 'modificaciones' de postulados donde se accepta que un número contenga una operación en si mismo (algo bastante axiomatico para ser un teorema), el tema derivara hacia otro teorema "El teorema de incomplitud de Goedel" que frena las formulaciones axiomaticas de las matematicas, ese mismo teorema ha convulcionado el mundo cientifico y también la filosofia porque ese anelo que tenemos de explicarlo todo con un lenguage matematico formal (como quiso hacer Bertrand Russell) no es posible, podemos a lo sumo ampliar nuestro conocimiento redefiniendo constantemente nuestras bases axiomaticas pero siempre encontraremos paradojas en nuestro camino.
El post era para eso...discutir y aprender todos juntos... :D
Si te niegas a ver una suma de un sumando, súmale 0 y ya estás apañado, tienes una suma de dos sumandos.
Si pero ahora me estas hablando de la suma de dos sumandos de nuevo y no de uno (aúnque uno de ellos es el elemento neutro de la adición tambien es un sumando) y no de la suma de un sumando......Asi que como sabemos todos contar .... 1 y 2 ..... yo veo dos sumandos.....
Un saludo.
Y a pesar de que mantengo de que las matematicas están muertas aúnque sigan progresando, no significa que no debamos jugar con ellas, ni que no seán utiles (el mundo y mis puntos de vista, no son aritmeticas booleanas que obliguen a abandonar un excelente camino aúnque tenga 'fallitos' :) ).
¿Jo, tal vez nos gusta la Necrofilia? :D
chutipascal
09-06-2003, 13:44:58
[quote]
Roman escribio esto:
1. El cero es número natural
2. Todo número natural tiene un sucesor que también es un número natural
3. El cero no es sucesor de ningún número natural
4. Distintos números tiene distintos sucesores
5. Si el cero tiene una propiedad y si cada vez que un número tiene la propiedad entonces el sucesor la tiene, se concluye que todos los números naturales tienen la propiedad
[quote]
No tengo a mano ningún libro junto a mi y hablo de vagos recuerdos de cuando estudiaba, por lo que si me equivoco es absolutamente culpa mia... :)
En el primer axioma (dices que de Peano) este incluye el 0 como número Natural, en mis tiempos el 0 no formaba parte de los naturales, se introducia en el conjunto Z.
¿ Hay varias definiciones para los naturales (conjunto N)?
¿ Significa que en un examen de fac. puedo poner: 0 pertenece a N o tengo que poner lo que se dio en las clases?
En el segundo axioma en lugar de generar todos los números naturales a partir de uno (como yo lo aprendi y como esta expuesto por Andres) con algo por el estilo de: si tenemos un conjunto A en el cual 1 pertenece a A y n pertenece a A, (n+1) pertenecera A y por lo tanto A=N (o algo por el estilo) y que creo recordar era la base de la inducción matematica, esto se vuelve interesante en el sentido de que ese axioma toma el concepto sucesor como 'algo evidente' y no como axioma que viene despues de la definición de N (lo mismo se puede decir de sumar 1).
El quinto axioma me deja también algo k.o. supongamos la propiedad representar algo o representar nada. Si cero representa nada 1,2,3....... ¿Tambien representan nada? (algo me 'induce' a pensar de que es un poco como el de las rectas paralelas este axioma.....)
Gracias.
roman
09-06-2003, 16:35:13
Posteado originalmente por chutipascal
¿ Significa que en un examen de fac. puedo poner: 0 pertenece a N o tengo que poner lo que se dio en las clases?
Pues no sé, depende de como sea tu profesor. Se que algunos profesores que no están en el área de matemáticas aún acostumbran excluir al 0 de los números naturales, pero esto, a diferencia de si el uno es primo o no, no está a discusión. Los numeros naturales forman lo que se llama un grupo respecto de la adición y una de la propiedades de un grupo es la existencia de un elemento neutro, en este caso, el cero.
Posteado originalmente por chutipascal ...esto se vuelve interesante en el sentido de que ese axioma toma el concepto sucesor como 'algo evidente' y no como axioma que viene despues de la definición de N...
Esa es la idea de los axiomas: representar algo que es o parece evidente.
Lo que dices del conjunto A, aunque mal enunciado es lo mismo que el axioma de inducción que establece Peano. Lo que pasa es que el axioma no dice que si n pertenece a A entonces n+1 también. Dice que si el cero (o el uno si gustas) pertenece a A y si cada vez que n pertenece entonces n+1 pertenece, entonces A contiene a todos los naturales. Observa el condicional que se aplica a lo siguiente que dices. La conclusión no es aplicable ya que no es cierto que si cade vez que n representa nada entonces n+1 representa nada.
Velos asi: Suponte que tienes una fila infinita de personas cada una de las cuales tiene el compromiso de pasar la noticia al de atrás. Si la primera se entera de una noticia entonces todas las demás se enterarán. Pero si nadie le dice nada al primero, nadie se entera de nada o bien, si alguien rompe el compromiso los restantes no se enteran.
// Saludos
pd: No entendí a que te refieres con lo de las paralelas.
vBulletin v3.6.8, Derechos ©2000-2024, Jelsoft Enterprises Ltd.