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.
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.
Ok, tiraremos de series de Taylor.
Gracias.
Ups, cierto ^^U
Uno ve ya tantas cosas de matemáticas que empieza a confundir nombres.
es un tema pendiente...
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!
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?
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.