469,641 Members | 1,106 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,641 developers. It's quick & easy.

float to Money cast

Hi,
I have the following:
float.Parse(myproduct.Price.Value.ToString());

myproduct.Price.Value.ToString() returns $24.00 (with the $)

Is there anyway to do the above cast, I know the float.Parse(...)
doesn't like the $, as i keep getting an invalid cast exception, is
there anyway to get this to work? Do i just need to strip out the $
with substring, or is there a better way to cast it?

Thanks.

Apr 9 '07 #1
15 3704
First off - I'd be using decimal (never float) to store money...
Second... one of the overloads to decimal.Parse accepts a number-style
param, one of which is currency, e.g.
>?decimal.Parse("ú21.12", System.Globalization.NumberStyles.Currency);
21.12
Marc

Apr 9 '07 #2
Completely out of curiosity... what is the .Price.Value typed as? Just
wondering if the ToString() is making your life harder without good
reason...

Marc

Apr 9 '07 #3
When you call the Parse method, pass the Currency value from the
NumberStyles enumeration as the second parameter. It should perform the
parse operation correctly then.

Also, technically you are not performing a cast, but you are performing
a conversion. There is a difference.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<so******@yahoo.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...
Hi,
I have the following:
float.Parse(myproduct.Price.Value.ToString());

myproduct.Price.Value.ToString() returns $24.00 (with the $)

Is there anyway to do the above cast, I know the float.Parse(...)
doesn't like the $, as i keep getting an invalid cast exception, is
there anyway to get this to work? Do i just need to strip out the $
with substring, or is there a better way to cast it?

Thanks.

Apr 9 '07 #4
so******@yahoo.com wrote:
I have the following:
float.Parse(myproduct.Price.Value.ToString());

myproduct.Price.Value.ToString() returns $24.00 (with the $)

Is there anyway to do the above cast, I know the float.Parse(...)
doesn't like the $, as i keep getting an invalid cast exception, is
there anyway to get this to work? Do i just need to strip out the $
with substring, or is there a better way to cast it?
I would think that:

Convert.ToSingle(myproduct.Price.Value)

would be a better approach.

But I warn you - a future version of .NET will contain a feature
where if a programmer ever tries to use float data type for money,
then a baseball bat will jump out of the monitor and beat you up ...

:-)

Floating point (float and double) is a no no for amounts.

Arne

Apr 9 '07 #5
Arne Vajh°j <ar**@vajhoej.dkwrote:

<snip>
Floating point (float and double) is a no no for amounts.
Small piece of pedantry - decimal is also a floating point type. It's a
floating *decimal* point type, however, rather than a floating *binary*
point type.

I completely agree that using float or double is wrong for money,
however :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 10 '07 #6
Jon Skeet [C# MVP] wrote:
Arne Vajh°j <ar**@vajhoej.dkwrote:
>Floating point (float and double) is a no no for amounts.

Small piece of pedantry - decimal is also a floating point type. It's a
floating *decimal* point type, however, rather than a floating *binary*
point type.

I completely agree that using float or double is wrong for money,
however :)
I thought decimal was fixed point.

But you are right. It is floating point. Yuck.

Arne

Apr 10 '07 #7
Arne Vajh°j <ar**@vajhoej.dkwrote:
Jon Skeet [C# MVP] wrote:
Arne Vajh°j <ar**@vajhoej.dkwrote:
Floating point (float and double) is a no no for amounts.
Small piece of pedantry - decimal is also a floating point type. It's a
floating *decimal* point type, however, rather than a floating *binary*
point type.

I completely agree that using float or double is wrong for money,
however :)
I thought decimal was fixed point.

But you are right. It is floating point. Yuck.
I don't see why that's particularly "yucky". If it were going to be
fixed point, where would you fix the point? It's okay to have it fixed
point in SQL, because every field can fix it in a different place
(well, size/precision).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 10 '07 #8
Jon Skeet [C# MVP] wrote:
Arne Vajh°j <ar**@vajhoej.dkwrote:
>Jon Skeet [C# MVP] wrote:
>>Arne Vajh°j <ar**@vajhoej.dkwrote:
Floating point (float and double) is a no no for amounts.
Small piece of pedantry - decimal is also a floating point type. It's a
floating *decimal* point type, however, rather than a floating *binary*
point type.

I completely agree that using float or double is wrong for money,
however :)
I thought decimal was fixed point.

But you are right. It is floating point. Yuck.

I don't see why that's particularly "yucky". If it were going to be
fixed point, where would you fix the point? It's okay to have it fixed
point in SQL, because every field can fix it in a different place
(well, size/precision).
With money I would prefer it to keep decimals.

1.01m / 10 to give 0.10m and not 0.101m !

Arne
Apr 10 '07 #9
On Mon, 09 Apr 2007 18:32:39 -0700, Arne Vajh├Şj <ar**@vajhoej.dkwrote:
With money I would prefer it to keep decimals.

1.01m / 10 to give 0.10m and not 0.101m !
It is trivial to accomplish that when desired, but if you have a need to
maintain fractional units of currency beyond two decimal places and the
data type doesn't offer that, it gets a lot more complicated. Better that
the language offer more functionality than you need than to unnecessarily
restrict you.

I think it makes perfect sense for decimal to be floating point. Lots of
financial applications are not naturally limited to two decimal places,
whether simply because of the nature of the transaction, or because there
is some currency exchange or conversion going on.

Pete
Apr 10 '07 #10
Arne,

I think that you are confusing what Jon is trying to say somewhat.
There is nothing wrong with a floating point type. The issue with using a
binary representation of a floating point type in computers is the
inaccuracy that results from using them.

However, the decimal type doesn't suffer from this inaccuracy. Because
of this, it shouldn't be an issue whether or not it is a floating point
type. The decimal is precise, and that is what matters in this situation
(everyone is precise with their money, no?).
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:46***********************@news.sunsite.dk...
Jon Skeet [C# MVP] wrote:
>Arne Vajh°j <ar**@vajhoej.dkwrote:
>>Jon Skeet [C# MVP] wrote:
Arne Vajh°j <ar**@vajhoej.dkwrote:
Floating point (float and double) is a no no for amounts.
Small piece of pedantry - decimal is also a floating point type. It's a
floating *decimal* point type, however, rather than a floating *binary*
point type.

I completely agree that using float or double is wrong for money,
however :)
I thought decimal was fixed point.

But you are right. It is floating point. Yuck.

I don't see why that's particularly "yucky". If it were going to be fixed
point, where would you fix the point? It's okay to have it fixed point in
SQL, because every field can fix it in a different place (well,
size/precision).

With money I would prefer it to keep decimals.

1.01m / 10 to give 0.10m and not 0.101m !

Arne

Apr 10 '07 #11
Peter Duniho wrote:
On Mon, 09 Apr 2007 18:32:39 -0700, Arne Vajh├Şj <ar**@vajhoej.dkwrote:
>With money I would prefer it to keep decimals.

1.01m / 10 to give 0.10m and not 0.101m !

It is trivial to accomplish that when desired, but if you have a need to
maintain fractional units of currency beyond two decimal places and the
data type doesn't offer that, it gets a lot more complicated. Better
that the language offer more functionality than you need than to
unnecessarily restrict you.
You think specifying length and index in the declarations is more
complicated than calling Math.Round on the expressions. I don't.
I think it makes perfect sense for decimal to be floating point. Lots
of financial applications are not naturally limited to two decimal
places, whether simply because of the nature of the transaction, or
because there is some currency exchange or conversion going on.
It does not need to be fixed at two decimals. I am not aware
of any fixed point that are so.

Arne
Apr 12 '07 #12
Nicholas Paldino [.NET/C# MVP] wrote:
Arne,

I think that you are confusing what Jon is trying to say somewhat.
There is nothing wrong with a floating point type. The issue with using a
binary representation of a floating point type in computers is the
inaccuracy that results from using them.

However, the decimal type doesn't suffer from this inaccuracy. Because
of this, it shouldn't be an issue whether or not it is a floating point
type. The decimal is precise, and that is what matters in this situation
(everyone is precise with their money, no?).
No.

There are more than just that problem with floating point.

Don't show this program to your accountant:

using System;

namespace E
{
public class MainClass
{
public static void Main(string[] args)
{
Console.WriteLine(decimal.MaxValue - (decimal.MaxValue - 0.10m));
Console.ReadLine();
}
}
}

The practical problem is not so big because decimal is so huge as it is,
but it has some of the classic floating point characteristics.

Arne
Apr 12 '07 #13
Arne Vajh°j wrote:
The practical problem is not so big because decimal is so huge as it is,
but it has some of the classic floating point characteristics.
And don't get me wrong.

I am really not saying that is a bad design.

I am just very surprised.

I always thought decimal was similar to SQL DECIMAL
and COBOL COMP-3.

Arne
Apr 12 '07 #14
On Wed, 11 Apr 2007 18:04:30 -0700, Arne Vajh├Şj <ar**@vajhoej.dkwrote:
It does not need to be fixed at two decimals. I am not aware
of any fixed point that are so.
I'm aware of plenty of fixed point types where you don't get to pick the
precision of the type.

That said, whatever. I find the .NET decimal type just fine. YMMV.
Apr 12 '07 #15
Arne Vajh?j <ar**@vajhoej.dkwrote:
It is trivial to accomplish that when desired, but if you have a need to
maintain fractional units of currency beyond two decimal places and the
data type doesn't offer that, it gets a lot more complicated. Better
that the language offer more functionality than you need than to
unnecessarily restrict you.

You think specifying length and index in the declarations is more
complicated than calling Math.Round on the expressions. I don't.
It's a complete change to the type system to be able to specify
precision/scale as part of a type declaration. That sort of type
declaration is already part of SQL, but it's nowhere to be found in C#
or .NET itself. That's a huge disruption. Calling Math.Round certainly
isn't.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 12 '07 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by jaijai_kumar | last post: by
6 posts views Thread by Dave win | last post: by
19 posts views Thread by Jon Shemitz | last post: by
4 posts views Thread by Jerry | last post: by
9 posts views Thread by Nicolas Blais | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.