Formatos de float

Si es una aplicación de facturación olvídate de los double.
Usa decimal para cualquier atributo de precio.

Ahora ¿Quién hizo los formularios? Porque si los estás
programando tú, entonces no deberías tener ningún problema
con las conversiones.
Si el usuario escribe "200,55" en una caja de textos, cuando
tu programa convierta el string a decimal

decimal precio = decimal.Parse(miForm.textbox1.Text);

precio queda correctamente asignado con los 2 decimales,
siempre y cuando el ordenador tenga establecido en el
panel de control la configuración correcta para el país.

Aquí el Parse está usando la configuración regional del
usuario. Si la cambias desde el panel de control a, por ejemplo,
Estados Unidos, el usuario podría ingresar "200.55" y tu
programa correctamente interpretaría los 55 como decimales
sin necesidad de cambiar el código fuente. No haya nada
misterioso aquí.

Te recuerdo que si miras en el depurador el contenido de la
variable precio, te mostrará los decimales con "." pero eso
es un tema del depurador.

Como tu aplicación tiene muchos módulos (postgres,
active record, nhibernate, etc.) y además tu código, debes
tratar de aislar el problema porque es probable de que SI se
trate de un problema de referencia cultural quizás en los
datos que se pasan los diferentes paquetes.



On 26 dic, 09:26, "ANT1" wrote:

Gracias Hernan.

Acabo de volver de las fiestas (por cierto felices fiestas par todos) y
me estoy poniendo con lo que me has pasado.

El programa que estoy haciendo es para una aplicacion windows. Una
aplicacion de facturacion.

Yo tengo todas las culturas de los distintos elementos de mi app a la
cultura por defecto. Como tu dices, para que el usuario escoja.

El problema aparece cuando hago una busqueda en la base de datos.
Utilizo postgresql y lo manejo mediante Active Record, de Castle
Proyect. Al hacer la busqueda HQL (el SQL de NHibernate) me imagino que
esta no acepte mas que la cultura definida para la base de datos o NH y
sea la americana, con los decimales separados por punto y claro, queda
un poco raro que paa añadir datos a la base de datos si que se pueda
utilizar la coma para separar los dcimales y en cambio para la busqueda
te obligue a usar el punto.

Por ello he llegado a la conclusion que no es un problem ade culturas
propiamente dicho de los textbox. Deberia de hacer alguna cosa para que
el usuaior al escribir en el textbx el numero, por ejemplo, "11,3" a la
hora de generar el codigo de busqueda sea "11.3".

Hernan ha escrito:

> > Aún no he probado a poner la cultura a los textbox y demás. Cuando lo
> > pruebe ya les diré a ver que tal me fue y para que otros que les sirva
> > puedan usarlo.

> ¿Es una página web o un winform? En una aplicación winform deberías
> usar el formato de la cultura corriente porque se supone que es lo que
> el usuario ha especificado en el sistema operativo.

> Lo que no dices es en qué se diferencia la búsqueda de la
> modificación.

> > Pero me interesa el comentario de otif11. ¿Que bugs has encontrado tu
> > con los float? ...

> No hay ningún bug (al menos que yo conozca). Los double y float
> funcionan
> así. Es la limitación que tienen por intentar representar una
> cantidad infinita
> de números (hay infinitos números reales entre cualquier par de
> ellos)
> con una cantidad finita de bits.

> En la práctica, si quieres representar dinero o algo relativo al mismo
> porque
> estás desarrollando una aplicación financiera o contable, usa el tipo
> decimal.
> Si lo que intentas representar es otra cosa, por ejemplo temperaturas
> en tu
> aplicación para demostrar el calentamiento global de la tierra, puedes
> seguir tranquilamente con los double.

> > ... y si puedes ¿que diferencias hay entre decimal y float?

> Hay bastante literatura al respecto en la web. El problema llega hasta
> los
> inicios de la computación. Cuando los programadores se preguntaban
> ¿qué uso? ¿COBOL o FORTRAN? en realidad estaban preguntándose
> si el problema se puede computar con decimal o doubles.

> Puedes empezar por aquí:
>http://es.wikipedia.org/wiki/IEEE_punto_flotante

> > Gracias otra vez

> > On 21 dic, 12:56, "" wrote:

> > > Yo que tú no usaría FLOAT pues son inexactos, es preferible usar
> > > decimal, tanto en base de datos como en aplicación, con float se
> > > pierde presición y si los quieres redondear peor aún. Es debido a un
> > > bug en .net

> > > Phito
> > > Venezuela

> > > ANT1 ha escrito:

> > > > Hola a todos de nuevo.

> > > > Sigo con mi aplicacion windows encargada de gestionar una base de
> > > > datos.

> > > > Ahora mismo estaba tratando de crear un motor de busqueda para dicha
> > > > base de datos y me ha surgido esta duda:

> > > > Para un campo float que tengo en la base de datos, si deseo almacenar
> > > > el valor correctamente, en el textbox que tengo donde escribir el valor
> > > > y todo eso he de poner le valor de los decimales con una coma, por
> > > > ejemplo "10,5".

> > > > En cambio a la hora de realizar una busqueda, en el textbox que tengo
> > > > que utilizar para indicar el valor a buscar, si quiero que me lo acepte
> > > > como una busqueda he de poner el valor decimal con un punto, con el
> > > > ejemplo anterior ahora seria "10.5".

> > > > ¿Alguien sabe porque es esto?¿Hay alguna forma de indicar el formato
> > > > de esritura del float en el textbox o en un datagridview?¿tal vez con
> > > > la cultura?

> > > > Gracias a todos. Este es uno de los pocos foros donde la gente
> > > > realmente se moja y ayuda a los demas.

Todo lo he programado yo. Y la cultura es la que se tenga por defecto
en el sistema del usuario.

A la hora de introducir los datos en la base de datos no tengo ningun
problema. Tengo los textbox bindeados (con bindingsource) a las
propiedades de la clase del objeto que van a ser. Por lo tanto al
escribir en un textbox bindeado a un floar, en este solo me permite
escribir en el formato float correspondiente que seria el castellano.

Como tu dices mi aplcacion tiene varios modulos entre NH, AR, ... y el
problema esta en la busqueda del Active Record, no se si concretamente
en este, al generar el codigo HQL o al buscar en la base de datos. Pero
esta comprobado que o se escribe el float en la cultura del ".", me
imagino que americana, o da error de busqueda al no poderse realizar
con dicho valor. ¿Se podria realizar un cambio del string de "10.5" a
"10,5" programaticamente y de manera sencilla?

On 26 dic, 11:36, "Hernan" wrote:

Si es una aplicación de facturación olvídate de los double.
Usa decimal para cualquier atributo de precio.

Ahora ¿Quién hizo los formularios? Porque si los estás
programando tú, entonces no deberías tener ningún problema
con las conversiones.
Si el usuario escribe "200,55" en una caja de textos, cuando
tu programa convierta el string a decimal

decimal precio = decimal.Parse(miForm.textbox1.Text);

precio queda correctamente asignado con los 2 decimales,
siempre y cuando el ordenador tenga establecido en el
panel de control la configuración correcta para el país.

Aquí el Parse está usando la configuración regional del
usuario. Si la cambias desde el panel de control a, por ejemplo,
Estados Unidos, el usuario podría ingresar "200.55" y tu
programa correctamente interpretaría los 55 como decimales
sin necesidad de cambiar el código fuente. No haya nada
misterioso aquí.

Te recuerdo que si miras en el depurador el contenido de la
variable precio, te mostrará los decimales con "." pero eso
es un tema del depurador.

Como tu aplicación tiene muchos módulos (postgres,
active record, nhibernate, etc.) y además tu código, debes
tratar de aislar el problema porque es probable de que SI se
trate de un problema de referencia cultural quizás en los
datos que se pasan los diferentes paquetes.

On 26 dic, 09:26, "ANT1" wrote:

> Gracias Hernan.

> Acabo de volver de las fiestas (por cierto felices fiestas par todos) y
> me estoy poniendo con lo que me has pasado.

> El programa que estoy haciendo es para una aplicacion windows. Una
> aplicacion de facturacion.

> Yo tengo todas las culturas de los distintos elementos de mi app a la
> cultura por defecto. Como tu dices, para que el usuario escoja.

> El problema aparece cuando hago una busqueda en la base de datos.
> Utilizo postgresql y lo manejo mediante Active Record, de Castle
> Proyect. Al hacer la busqueda HQL (el SQL de NHibernate) me imagino que
> esta no acepte mas que la cultura definida para la base de datos o NH y
> sea la americana, con los decimales separados por punto y claro, queda
> un poco raro que paa añadir datos a la base de datos si que se pueda
> utilizar la coma para separar los dcimales y en cambio para la busqueda
> te obligue a usar el punto.

> Por ello he llegado a la conclusion que no es un problem ade culturas
> propiamente dicho de los textbox. Deberia de hacer alguna cosa para que
> el usuaior al escribir en el textbx el numero, por ejemplo, "11,3" a la
> hora de generar el codigo de busqueda sea "11.3".

> Hernan ha escrito:

> > > Aún no he probado a poner la cultura a los textbox y demás. Cuando lo
> > > pruebe ya les diré a ver que tal me fue y para que otros que les sirva
> > > puedan usarlo.

> > ¿Es una página web o un winform? En una aplicación winform deberías
> > usar el formato de la cultura corriente porque se supone que es lo que
> > el usuario ha especificado en el sistema operativo.

> > Lo que no dices es en qué se diferencia la búsqueda de la
> > modificación.

> > > Pero me interesa el comentario de otif11. ¿Que bugs has encontrado tu
> > > con los float? ...

> > No hay ningún bug (al menos que yo conozca). Los double y float
> > funcionan
> > así. Es la limitación que tienen por intentar representar una
> > cantidad infinita
> > de números (hay infinitos números reales entre cualquier par de
> > ellos)
> > con una cantidad finita de bits.

> > En la práctica, si quieres representar dinero o algo relativo al mismo
> > porque
> > estás desarrollando una aplicación financiera o contable, usa el tipo
> > decimal.
> > Si lo que intentas representar es otra cosa, por ejemplo temperaturas
> > en tu
> > aplicación para demostrar el calentamiento global de la tierra, puedes
> > seguir tranquilamente con los double.

> > > ... y si puedes ¿que diferencias hay entre decimal y float?

> > Hay bastante literatura al respecto en la web. El problema llega hasta
> > los
> > inicios de la computación. Cuando los programadores se preguntaban
> > ¿qué uso? ¿COBOL o FORTRAN? en realidad estaban preguntándose
> > si el problema se puede computar con decimal o doubles.

> > Puedes empezar por aquí:
> >http://es.wikipedia.org/wiki/IEEE_punto_flotante

> > > Gracias otra vez

> > > On 21 dic, 12:56, "" wrote:

> > > > Yo que tú no usaría FLOAT pues son inexactos, es preferible usar
> > > > decimal, tanto en base de datos como en aplicación, con float se
> > > > pierde presición y si los quieres redondear peor aún. Es debido a un
> > > > bug en .net

> > > > Phito
> > > > Venezuela

> > > > ANT1 ha escrito:

> > > > > Hola a todos de nuevo.

> > > > > Sigo con mi aplicacion windows encargada de gestionar una base de
> > > > > datos.

> > > > > Ahora mismo estaba tratando de crear un motor de busqueda para dicha
> > > > > base de datos y me ha surgido esta duda:

> > > > > Para un campo float que tengo en la base de datos, si deseo almacenar
> > > > > el valor correctamente, en el textbox que tengo donde escribir el valor
> > > > > y todo eso he de poner le valor de los decimales con una coma, por
> > > > > ejemplo "10,5".

> > > > > En cambio a la hora de realizar una busqueda, en el textbox que tengo
> > > > > que utilizar para indicar el valor a buscar, si quiero que me lo acepte
> > > > > como una busqueda he de poner el valor decimal con un punto, con el
> > > > > ejemplo anterior ahora seria "10.5".

> > > > > ¿Alguien sabe porque es esto?¿Hay alguna forma de indicar el formato
> > > > > de esritura del float en el textbox o en un datagridview?¿tal vez con
> > > > > la cultura?

> > > > > Gracias a todos. Este es uno de los pocos foros donde la gente
> > > > > realmente se moja y ayuda a los demas.

Solo una duda mas.

Como mencione mi aplicacion windows esta relacionada con una base de
datos y mapeo todos los objetos con AR y NH.

PostgreSQL, la base de datos que utilizo, no tiene el formato decimal
que me comentan. ¿Que formato tendria que dar a las columnas de mi
base de datos que quiero usar como decimales? ¿float?

Como mencione mi aplicacion windows esta relacionada con una base de
datos y mapeo todos los objetos con AR y NH.

PostgreSQL, la base de datos que utilizo, no tiene el formato decimal
que me comentan. ¿Que formato tendria que dar a las columnas de mi
base de datos que quiero usar como decimales? ¿float?

¿Estás seguro que no tiene? Está en el estándar de SQL, me parece
raro que no lo tenga. ¿Y el tipo NUMERIC no te sirve?
Googleando un poco sale:
http://www.postgresql.org/docs/7.3/...atype.html

De todas formas nunca usé PostgreSQL así que puedo estar
equivocado.

Eso sí, en tu caso no solo tendrás que ver la documentación del
motor
de base de datos, también deberías ver cuál es la equivalencia de
tipos
entre el motor y .net. Eso debería estar en la doc del conector
ADO.NET <-> PostgreSQL.

Como tu dices mi aplcacion tiene varios modulos entre NH, AR, ... y el
problema esta en la busqueda del Active Record, no se si concretamente
en este, al generar el codigo HQL o al buscar en la base de datos. Pero
esta comprobado que o se escribe el float en la cultura del ".", me
imagino que americana, o da error de busqueda al no poderse realizar
con dicho valor.

Entonces algunas de esas capas te está haciendo un lío con la
referencia cultural, porque no te está respetando la del usuario.

¿Se podria realizar un cambio del string de "10.5" a
"10,5" programaticamente y de manera sencilla?

Claro que se puede (aunque suena a parche). Conviertes el string
a un decimal o double temporal suponiendo que viene en "ingles"
y lo vuelves a transformar en string con la referencia cultural
por defecto (la del usuario). En dos pasos y sin probar:

double tempval = double.Parse("10.5", new CultureInfo("en-US"));
string valor = tempval.ToString();

On 26 dic, 11:36, "Hernan" wrote:

> Si es una aplicación de facturación olvídate de los double.
> Usa decimal para cualquier atributo de precio.

> Ahora ¿Quién hizo los formularios? Porque si los estás
> programando tú, entonces no deberías tener ningún problema
> con las conversiones.
> Si el usuario escribe "200,55" en una caja de textos, cuando
> tu programa convierta el string a decimal

> decimal precio = decimal.Parse(miForm.textbox1.Text);

> precio queda correctamente asignado con los 2 decimales,
> siempre y cuando el ordenador tenga establecido en el
> panel de control la configuración correcta para el país.

> Aquí el Parse está usando la configuración regional del
> usuario. Si la cambias desde el panel de control a, por ejemplo,
> Estados Unidos, el usuario podría ingresar "200.55" y tu
> programa correctamente interpretaría los 55 como decimales
> sin necesidad de cambiar el código fuente. No haya nada
> misterioso aquí.

> Te recuerdo que si miras en el depurador el contenido de la
> variable precio, te mostrará los decimales con "." pero eso
> es un tema del depurador.

> Como tu aplicación tiene muchos módulos (postgres,
> active record, nhibernate, etc.) y además tu código, debes
> tratar de aislar el problema porque es probable de que SI se
> trate de un problema de referencia cultural quizás en los
> datos que se pasan los diferentes paquetes.

> On 26 dic, 09:26, "ANT1" wrote:

> > Gracias Hernan.

> > Acabo de volver de las fiestas (por cierto felices fiestas par todos) y
> > me estoy poniendo con lo que me has pasado.

> > El programa que estoy haciendo es para una aplicacion windows. Una
> > aplicacion de facturacion.

> > Yo tengo todas las culturas de los distintos elementos de mi app a la
> > cultura por defecto. Como tu dices, para que el usuario escoja.

> > El problema aparece cuando hago una busqueda en la base de datos.
> > Utilizo postgresql y lo manejo mediante Active Record, de Castle
> > Proyect. Al hacer la busqueda HQL (el SQL de NHibernate) me imagino que
> > esta no acepte mas que la cultura definida para la base de datos o NH y
> > sea la americana, con los decimales separados por punto y claro, queda
> > un poco raro que paa añadir datos a la base de datos si que se pueda
> > utilizar la coma para separar los dcimales y en cambio para la busqueda
> > te obligue a usar el punto.

> > Por ello he llegado a la conclusion que no es un problem ade culturas
> > propiamente dicho de los textbox. Deberia de hacer alguna cosa para que
> > el usuaior al escribir en el textbx el numero, por ejemplo, "11,3" a la
> > hora de generar el codigo de busqueda sea "11.3".

> > Hernan ha escrito:

> > > > Aún no he probado a poner la cultura a los textbox y demás. Cuando lo
> > > > pruebe ya les diré a ver que tal me fue y para que otros que les sirva
> > > > puedan usarlo.

> > > ¿Es una página web o un winform? En una aplicación winform deberías
> > > usar el formato de la cultura corriente porque se supone que es lo que
> > > el usuario ha especificado en el sistema operativo.

> > > Lo que no dices es en qué se diferencia la búsqueda de la
> > > modificación.

> > > > Pero me interesa el comentario de otif11. ¿Que bugs has encontrado tu
> > > > con los float? ...

> > > No hay ningún bug (al menos que yo conozca). Los double y float
> > > funcionan
> > > así. Es la limitación que tienen por intentar representar una
> > > cantidad infinita
> > > de números (hay infinitos números reales entre cualquier par de
> > > ellos)
> > > con una cantidad finita de bits.

> > > En la práctica, si quieres representar dinero o algo relativo al mismo
> > > porque
> > > estás desarrollando una aplicación financiera o contable, usa el tipo
> > > decimal.
> > > Si lo que intentas representar es otra cosa, por ejemplo temperaturas
> > > en tu
> > > aplicación para demostrar el calentamiento global de la tierra, puedes
> > > seguir tranquilamente con los double.

> > > > ... y si puedes ¿que diferencias hay entre decimal y float?

> > > Hay bastante literatura al respecto en la web. El problema llega hasta
> > > los
> > > inicios de la computación. Cuando los programadores se preguntaban
> > > ¿qué uso? ¿COBOL o FORTRAN? en realidad estaban preguntándose
> > > si el problema se puede computar con decimal o doubles.

> > > Puedes empezar por aquí:
> > >http://es.wikipedia.org/wiki/IEEE_punto_flotante

> > > > Gracias otra vez

> > > > On 21 dic, 12:56, "" wrote:

> > > > > Yo que tú no usaría FLOAT pues son inexactos, es preferible usar
> > > > > decimal, tanto en base de datos como en aplicación, con float se
> > > > > pierde presición y si los quieres redondear peor aún. Es debido a un
> > > > > bug en .net

> > > > > Phito
> > > > > Venezuela

> > > > > ANT1 ha escrito:

> > > > > > Hola a todos de nuevo.

> > > > > > Sigo con mi aplicacion windows encargada de gestionar una base de
> > > > > > datos.

> > > > > > Ahora mismo estaba tratando de crear un motor de busqueda para dicha
> > > > > > base de datos y me ha surgido esta duda:

> > > > > > Para un campo float que tengo en la base de datos, si deseo almacenar
> > > > > > el valor correctamente, en el textbox que tengo donde escribir el valor
> > > > > > y todo eso he de poner le valor de los decimales con una coma, por
> > > > > > ejemplo "10,5".

> > > > > > En cambio a la hora de realizar una busqueda, en el textbox que tengo
> > > > > > que utilizar para indicar el valor a buscar, si quiero que me lo acepte
> > > > > > como una busqueda he de poner el valor decimal con un punto, con el
> > > > > > ejemplo anterior ahora seria "10.5".

> > > > > > ¿Alguien sabe porque es esto?¿Hay alguna forma de indicar el formato
> > > > > > de esritura del float en el textbox o en un datagridview?¿tal vez con
> > > > > > la cultura?

> > > > > > Gracias a todos. Este es uno de los pocos foros donde la gente
> > > > > > realmente se moja y ayuda a los demas.