float to Money cast

[soni2926]

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.

 

[Marc Gravell]

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

 

[Marc Gravell]

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

 

[Nicholas Paldino [.NET/C# MVP]]

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.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

 

[Jon Skeet [C# MVP]]

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

 

[Jon Skeet [C# MVP]]

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).

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

 

[Peter Duniho]

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

 

[Nicholas Paldino [.NET/C# MVP]]

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]
- (e-mail address removed)

Jon Skeet [C# MVP] wrote:
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

 

[Guest]

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

 

[Peter Duniho]

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.

 

[Jon Skeet [C# MVP]]

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.