2 cosas que pensaba que estaban pero no

Started by osk, August 23, 2009, 08:16:43 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

osk

Hola.
Cuando leí este post hace ya algún tiempo: http://forum.bennugd.org/index.php?topic=58.0
pensé que las funciones exp, log, log10...ya habían sido implementadas, pero ahora he visto que no.
¿Sería muy complicado al menos tener las tres anteriores? Lo digo porque depende de para qué pueden venir muy bien (aplicar pesos a probabilidades, por ejemplo).

Por otro lado, en el post de Avances en su momento leí que se había implementado un módulo llamado mod_ffi que permitía ejecutar funciones de dentro de librerías compiladas del sistema. Pero en la última versión de Bennu no aparece. ¿Qué es lo que ha ocurrido?

Gracias.

Drumpi

Si mi memoria no me falla a estas horas de la noche, creo que se habló de crear una librería aparte con todas las funciones matemáticas complejas. No sería difícil desarrollar una a base de series de fourier (hace aproximaciones, pero con series de sexto grado creo que se consigue un aceptable margen de error), pero hay que ponerse. Lo suyo es quitarle el trabajo a Splinter, pero ya dijo en su momento que hasta que no esté la 1.0 en marcha, no iba a dedicarse a añadir cosas nuevas.

De lo segundo, creo que el actual sistema interno de uso de librerías ya permitía usar cualquier tipo de dll, siempre que supieras las funciones que contienen (para eso creo que había un programita hecho), pero mejor que alguien te lo confirme.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

osk

Ok, tiraremos de series de Taylor.
Gracias.

Drumpi

Ups, cierto ^^U
Uno ve ya tantas cosas de matemáticas que empieza a confundir nombres.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

SplinterGU

Download Lastest BennuGD Release: http://www.bennugd.org/node/2

osk

Hola.
He intentado hacer las funciones log() y ln() a partir de Taylor, así:

[code language="bennu"]
function float ln(float numero)
private
  float aux;
end
begin
  aux=(numero-1)/(numero+1);
  return ( 2*(aux + pow(aux,3)/3 + pow(aux,5)/5 + pow(aux,7)/7 + pow(aux,9)/9 + pow(aux,11)/11 + pow(aux,13)/13 + pow(aux,15)/15 + pow(aux,17)/17 + pow(aux,19)/19 + pow(aux,21)/21 + pow(aux,23)/23 + pow(aux,25)/25 + pow(aux,27)/27 + pow(aux,29)/29 + pow(aux,31)/31 + pow(aux,33)/33 + pow(aux,35)/35 + pow(aux,37)/37 + pow(aux,39)/39 + pow(aux,41)/41 + pow(aux,43)/43 + pow(aux,45)/45 + pow(aux,47)/47 + pow(aux,49)/49 + pow(aux,51)/51 + pow(aux,53)/53 + pow(aux,55)/55 + pow(aux,57)/57) );
end

//La precisión viene determinada por la exactitud de la función ln()
function float log(float numero)
begin
  return (ln(numero)/2.302585);
end
[/code]

A pesar de los 30 términos incluidos en el valor devuelto de ln(), a partir aproximadamente
del número 20 dado como entrada, se pierde la precisión en las milésimas. No sé si esto es aceptable o no...pero lo que más me preocupa es el no controlar si en algún término de la serie me excedo del límite superior del valor posible del número y se produce un overflow...Ese pow() elevado a 57 da un poco de mala espina. ¿Con los float -porque pow() devuelve float- existe algún máximo? ¿Habría alguna otra forma de hacer la función log() "más mejor", con un algoritmo específico?
Graacias!

Drumpi

Hombre, en lugar de introducir los términos a mano, podrías haber usado un bucle para crear la serie numérica y así poder especificar el número de términos por parámetro.
Respecto a los FLOAT, los límites los marca C, aunque yo no me preocuparía por dos cosas:
a) Los float se desarrollaron para trabajar con números enormemente grandes al igual que enormemente pequeños. Ya hablé en otro hilo cómo funcionan, usan parte de sus 32 bits para especificar una potencia de 10.
b) Si las potencias se hace con números con decimales, estos salen más pequeños. Una potencia de un número menor que 1 genera números más cercanos a cero cuanto más eleves la potencia.
Vamos, que si un FLOAT no puede con ello, tendrías que llamar a algún matemático o programador de matlab.

Lo que si podemos tener problemas es con la poca precisión de los float de por si, pero vamos, que aqui no vamos a hacer simulaciones aeroespaciales ¿o si?
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

osk

Ah, buena idea eso de establecer el número de elementos de la serie por parámetro...ya sería la leche que pudiera ser opcional, pero creo que estamos pidiendo demasiado ya.