Hola, Si los datos se guardan como float, usar scaled decimal despues no va a arreglar el problema de la precision porque la decision de usar punto flotante ya esta tomada. Para no tener el problema, habria que poner scaled decimals en la tabla.
O bien, se podria redondear de otra manera... por ejemplo, implementar roundedToDecimalPlaces: y que devuelva un scaled decimal redondeado mas acorde a las reglas que uno espera. Si la precision del float es bastante mas grande que las maximas cifras decimales que quieras ver, esto se podria hacer tranquilamente. Si es para mostrar un string nada mas, hasta se podria calcular el print string apropiado. No tengo muchos detalles al respecto de tu aplicacion, asi que no se bien que decir con respecto al uso de memoria. En VW, SmallDouble para las imagenes de 64 bits entra en un oop, entonces es un inmediato. El precio a pagar es que es menos que un double. Gracias, Andres. On 10/18/07, GallegO <[EMAIL PROTECTED]> wrote: > > > Andres: > > Andres Valloud escribió: > > > > Si necesitas precision, usa ScaledDecimal. > > > > Ahora que lo mencionas, siempre se dice esto. > A mi se me plantea la duda del uso teniendo en cuenta la memoria. > Por ejemplo, nosotros tenemos aplicaciones que instancian muchas filas > de una base de datos. Entre los datos típicos que guardamos hay mucho > TimeStamp y mucho Float, ademas de algunos SmallInteger (que no suman). > El problema es que muchas veces tenemos unas cuantas filas en memoria, > digamos mas de 500.000 filas e increiblemente, cuando te pones a ver el > uso detallado de la memoria (en Dolphin), te das cuenta que TimeStamp > (que tiene varios objetos más adentro) y Float se llevan gran parte de > la torta de la memoria. > > Es decir y resumiendo si uso un ScaledDecimal agrego el ScaledDecimal > más el Fraction que tiene adentro dejando de lado el scale que seguro > sea un SmallInteger, es decir más memoria, o más slots de la tabla, que > en la práctica es lo que nos jode seguramente. > > Entiendo que estos límites nos los imponemos nosotros al instanciar > tantos objetos, pero queremos ser libres de la administración de la > memoria también en la cantidad que reclamamos sin llegar tan rápido a > los límites de implementación de los Smalltalk's > > Existe alguna alternativa a esto que planteo? > Mejora la situación si usamos tipos nativos tenindo un soporte de > boxing/unboxing como en Java y .net? > Apunta a eso el small float de VW? > > No estoy planteando para nada la necesidad, solo me gustaría saber qué > piensan ya que no estoy en tema. > > Saludos > GallegO > > > > --~--~---------~--~----~------------~-------~--~----~ Has recibido este mensaje porque estás suscrito a Grupo "clubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envía un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups.google.com/group/clubSmalltalk?hl=es. -~----------~----~----~----~------~----~------~--~---
