By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,529 Members | 1,826 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,529 IT Pros & Developers. It's quick & easy.

Coercion of a String Into a Double Doesnt work (??!!)

P: n/a
AGP
I've been scratching my head for weeks to understand why some code doesnt
work for me.
here is what i have:

dim sVal as string = "13.2401516"
dim x as double

x = sVal

debug.writeline ( x)

Now on my system (English WinXp proSP3) the debug line
is as follows
13.2401516

However, when a user in a different locale (different localized version of
Windows) the debug line prints
132401516
The same number only without the decimal. Can anyone shed some light on why
this happanes? is it because the user may have a

different format for numbers and the coercion is done according to that
format? How can i ensure that i get the proper conversion?

AGP
Aug 25 '08 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Hi AGP,

The reason is in some locales the . is used as a thousands separator much
like how , is used in others, e.g 1,000 is the same as 1.000 depending on
the locale.

To take explicit control of how the Double is parsed used the double Parse
method, e.g:

x = Double.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo)


"AGP" <si**********@softhome.netwrote in message
news:qD******************@nlpi067.nbdc.sbc.com...
I've been scratching my head for weeks to understand why some code doesnt
work for me.
here is what i have:

dim sVal as string = "13.2401516"
dim x as double

x = sVal

debug.writeline ( x)

Now on my system (English WinXp proSP3) the debug line
is as follows
13.2401516

However, when a user in a different locale (different localized version of
Windows) the debug line prints
132401516
The same number only without the decimal. Can anyone shed some light on
why this happanes? is it because the user may have a

different format for numbers and the coercion is done according to that
format? How can i ensure that i get the proper conversion?

AGP

Aug 25 '08 #2

P: n/a
AGP,

Be aware that you should avoid hard coded decimimal pointers

However, that is impossiblie in a document or a webpage.

Have therefore a look at this.
http://www.vb-tips.com/Cultures.aspx

Cor

"AGP" <si**********@softhome.netschreef in bericht
news:qD******************@nlpi067.nbdc.sbc.com...
I've been scratching my head for weeks to understand why some code doesnt
work for me.
here is what i have:

dim sVal as string = "13.2401516"
dim x as double

x = sVal

debug.writeline ( x)

Now on my system (English WinXp proSP3) the debug line
is as follows
13.2401516

However, when a user in a different locale (different localized version of
Windows) the debug line prints
132401516
The same number only without the decimal. Can anyone shed some light on
why this happanes? is it because the user may have a

different format for numbers and the coercion is done according to that
format? How can i ensure that i get the proper conversion?

AGP


Aug 25 '08 #3

P: n/a
AGP
The data that i am reading will be non-locale specific and will always be
written
as pure decimal. Example 13.58 is read as 13 and 58 hundreths. So if I read
your link properly then I should just coerce the string before assiging it
and that should
give me a pure decimal number as follows:

dim sVal as string = "13.2401516"
dim x as double
x = CDbl( sVal )

AGP

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:uN**************@TK2MSFTNGP06.phx.gbl...
AGP,

Be aware that you should avoid hard coded decimimal pointers

However, that is impossiblie in a document or a webpage.

Have therefore a look at this.
http://www.vb-tips.com/Cultures.aspx

Cor

"AGP" <si**********@softhome.netschreef in bericht
news:qD******************@nlpi067.nbdc.sbc.com...
>I've been scratching my head for weeks to understand why some code doesnt
work for me.
here is what i have:

dim sVal as string = "13.2401516"
dim x as double

x = sVal

debug.writeline ( x)

Now on my system (English WinXp proSP3) the debug line
is as follows
13.2401516

However, when a user in a different locale (different localized version
of Windows) the debug line prints
132401516
The same number only without the decimal. Can anyone shed some light on
why this happanes? is it because the user may have a

different format for numbers and the coercion is done according to that
format? How can i ensure that i get the proper conversion?

AGP



Aug 26 '08 #4

P: n/a
AGP
Im using VS2005 and noticed that secondary option doesnt come up by default
so what is the difference between
Double.Parse(sVal, Globalization.NumberStyles.Float)

and

Double.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo)

AGP

"Bill McCarthy" <Bi**@localhost.comwrote in message
news:78**********************************@microsof t.com...
Hi AGP,

The reason is in some locales the . is used as a thousands separator much
like how , is used in others, e.g 1,000 is the same as 1.000 depending on
the locale.

To take explicit control of how the Double is parsed used the double Parse
method, e.g:

x = Double.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo)


"AGP" <si**********@softhome.netwrote in message
news:qD******************@nlpi067.nbdc.sbc.com...
>I've been scratching my head for weeks to understand why some code doesnt
work for me.
here is what i have:

dim sVal as string = "13.2401516"
dim x as double

x = sVal

debug.writeline ( x)

Now on my system (English WinXp proSP3) the debug line
is as follows
13.2401516

However, when a user in a different locale (different localized version
of Windows) the debug line prints
132401516
The same number only without the decimal. Can anyone shed some light on
why this happanes? is it because the user may have a

different format for numbers and the coercion is done according to that
format? How can i ensure that i get the proper conversion?

AGP


Aug 26 '08 #5

P: n/a
AGP wrote:
Im using VS2005 and noticed that secondary option doesnt come up by default
The double.Parse method has an overload that takes an IFormatProvider.
You can use any class that implements that interface, including
NumberFormatInfo, but you won't get a complete list of those classes in
the intellisense.
so what is the difference between
Double.Parse(sVal, Globalization.NumberStyles.Float)

and

Double.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo)

AGP
The difference is that the first one still uses the default culture,
which may not use a period as decimal separator. The InvariantInfo is
culture independent and a period has been chosen as it's decimal separator.

--
Göran Andersson
_____
http://www.guffa.com
Aug 26 '08 #6

P: n/a
AGP
ok here is what i have

dim sVal1 as string = "13.2401516"
dim sVal2 as string = "53.2168183"
a = CDbl(sVal1)

b = Double.Parse(sVal2, Globalization.NumberFormatInfo.InvariantInfo)

and the debug line from the user

132401516

53,2168183

He is using a German Windows XP version. In that locale the number 1300 and
24/100 would be written 1300,24 so it seems to me that the second is the
correct way to writre it as suggested. Double.Parse(sVal2,
Globalization.NumberFormatInfo.InvariantInfo) seems to correctly interpret
the number. But my question is...that is how the user sees the number that
is calculated but internally is it still 53 and 2168183/10000000? In other
words, if i pump that value to another process will it still be seen as 53
and 2168183/10000000?

Im going to install the German MUI and do some testing here but i think Im
learning something that I never paid much attention to in the past.

AGP
"Göran Andersson" <gu***@guffa.comwrote in message
news:e9**************@TK2MSFTNGP02.phx.gbl...
AGP wrote:
>Im using VS2005 and noticed that secondary option doesnt come up by
default

The double.Parse method has an overload that takes an IFormatProvider. You
can use any class that implements that interface, including
NumberFormatInfo, but you won't get a complete list of those classes in
the intellisense.
>so what is the difference between
Double.Parse(sVal, Globalization.NumberStyles.Float)

and

Double.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo)

AGP

The difference is that the first one still uses the default culture, which
may not use a period as decimal separator. The InvariantInfo is culture
independent and a period has been chosen as it's decimal separator.

--
Göran Andersson
_____
http://www.guffa.com

Aug 27 '08 #7

P: n/a
Pure,

Pure decimal, only 2% of the world population is using the dot as decimal
seperator, the rest is using a comma.
Even in at least one country where English is used is the comma the decimal
seperator.

Cor

"AGP" <si**********@softhome.netschreef in bericht
news:Ku*******************@nlpi064.nbdc.sbc.com...
The data that i am reading will be non-locale specific and will always be
written
as pure decimal. Example 13.58 is read as 13 and 58 hundreths. So if I
read
your link properly then I should just coerce the string before assiging it
and that should
give me a pure decimal number as follows:

dim sVal as string = "13.2401516"
dim x as double
x = CDbl( sVal )

AGP

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:uN**************@TK2MSFTNGP06.phx.gbl...
>AGP,

Be aware that you should avoid hard coded decimimal pointers

However, that is impossiblie in a document or a webpage.

Have therefore a look at this.
http://www.vb-tips.com/Cultures.aspx

Cor

"AGP" <si**********@softhome.netschreef in bericht
news:qD******************@nlpi067.nbdc.sbc.com. ..
>>I've been scratching my head for weeks to understand why some code
doesnt work for me.
here is what i have:

dim sVal as string = "13.2401516"
dim x as double

x = sVal

debug.writeline ( x)

Now on my system (English WinXp proSP3) the debug line
is as follows
13.2401516

However, when a user in a different locale (different localized version
of Windows) the debug line prints
132401516
The same number only without the decimal. Can anyone shed some light on
why this happanes? is it because the user may have a

different format for numbers and the coercion is done according to that
format? How can i ensure that i get the proper conversion?

AGP



Aug 27 '08 #8

P: n/a
Cor Ligthert[MVP] wrote:
Pure decimal, only 2% of the world population is using the dot as
decimal seperator, the rest is using a comma.
Cite? I present to you the countries of China and India, which I suggest
between them make up somewhat more than 2% of the world's population ;-)

http://en.wikipedia.org/wiki/Decimal_separator

Andrew
Aug 27 '08 #9

P: n/a
Suggest y'all use TryParse() rather than Parse(). The former will return a
zero value if the input is bad whereas TryParse() will return a zero value
but not throw an exception.

-bwr-

"AGP" <si**********@softhome.netwrote in message
news:YE******************@flpi147.ffdc.sbc.com...
ok here is what i have

dim sVal1 as string = "13.2401516"
dim sVal2 as string = "53.2168183"
a = CDbl(sVal1)

b = Double.Parse(sVal2, Globalization.NumberFormatInfo.InvariantInfo)

and the debug line from the user

132401516

53,2168183

He is using a German Windows XP version. In that locale the number 1300
and 24/100 would be written 1300,24 so it seems to me that the second is
the correct way to writre it as suggested. Double.Parse(sVal2,
Globalization.NumberFormatInfo.InvariantInfo) seems to correctly interpret
the number. But my question is...that is how the user sees the number that
is calculated but internally is it still 53 and 2168183/10000000? In other
words, if i pump that value to another process will it still be seen as 53
and 2168183/10000000?

Im going to install the German MUI and do some testing here but i think Im
learning something that I never paid much attention to in the past.

AGP
"Göran Andersson" <gu***@guffa.comwrote in message
news:e9**************@TK2MSFTNGP02.phx.gbl...
>AGP wrote:
>>Im using VS2005 and noticed that secondary option doesnt come up by
default

The double.Parse method has an overload that takes an IFormatProvider.
You can use any class that implements that interface, including
NumberFormatInfo, but you won't get a complete list of those classes in
the intellisense.
>>so what is the difference between
Double.Parse(sVal, Globalization.NumberStyles.Float)

and

Double.Parse(sVal, Globalization.NumberFormatInfo.InvariantInfo)

AGP

The difference is that the first one still uses the default culture,
which may not use a period as decimal separator. The InvariantInfo is
culture independent and a period has been chosen as it's decimal
separator.

--
Göran Andersson
_____
http://www.guffa.com


Aug 29 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.