|
I have to use a kind of data type that accept digits after decimal point.
so I need to choose between float and decimal.
But it is true that working with decimal is about 20 times slower than working with float ?
This is my question.
Thank you !
|
|
|
|
|
dilkonika wrote: have to use a kind of data type that accept digits after decimal point.
Not if you get a little creative. Multiple all values by 100 and You can use integer types quite easily.
If you're still thinking about using single/double/float for money values, think again. Try this and see what you get:
static void Main(string[] args)
{
float x = 12345678.33f;
Console.WriteLine(string.Format("{0:N8}", x));
}
|
|
|
|
|
It seems that nobody give a response to the question : Is true that working with decimal is several time slower that working with float ?
|
|
|
|
|
You seem to be focusing on the wrong thing.
What good is the speed of using a datatype when the type doesn't even accurately hold the values you're trying to use?
There is a very good reason why nobody in the finanical industry uses single/double/float. Being "close enough" with money values does not cut it.
|
|
|
|
|
No, not "several" times. If you want to know the difference, write a loop and TRY IT.
And as the others have already pointed out, both float and decimal are the wrong choice.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Let's try that again. We have multiple ways of displaying a number.
MSDN wrote: The Decimal[^] value type represents decimal numbers ranging from positive 79,228,162,514,264,337,593,543,950,335 to negative 79,228,162,514,264,337,593,543,950,335. The Decimal value type is appropriate for financial calculations that require large numbers of significant integral and fractional digits and no round-off errors. The Decimal type does not eliminate the need for rounding. Rather, it minimizes errors due to rounding. For example, the following code produces a result of 0.9999999999999999999999999999 instead of 1.
Dim dividend As Decimal = Decimal.One
Dim divisor As Decimal = 3
Console.WriteLine(dividend/divisor * divisor) Maps to decimal[^] in SQL Server
MSDN wrote: The Double[^] value type represents a double-precision 64-bit number with values ranging from negative 1.79769313486232e308 to positive 1.79769313486232e308, as well as positive or negative zero, PositiveInfinity, NegativeInfinity, and not a number (NaN). It is intended to represent values that are extremely large (such as distances between planets or galaxies) or extremely small (the molecular mass of a substance in kilograms) and that often are imprecise (such as the distance from earth to another solar system), The Double type complies with the IEC 60559:1989 (IEEE 754) standard for binary floating-point arithmetic. That's your float in .NET.
The floating operations are faster than the decimal operations, and, if all is well, integer operations would be even faster. You keep fixing on a formatted value of $2.53 in your wallet. With some creativity you could store those as 253 cents in your database. It is impossible to work with half-a-cent, since they do not exist. No more rounding errors, and the most optimal to work with: a bigint (Int64) to store cents.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
dilkonika wrote: I need to choose between float and decimal. No you don't, you need to use some creative thinking. Dave K's response above is a good illustration of why you should never use float. As to allowing the user to enter something like 450.37 , that is just a string of text. You can quite easily split that into two strings and convert each one to an integer. You could then multiply the first number by 100 and add the second, to use the smallest unti type, or use them separately as dollars and cents, or rupees and paisa, whatever.
|
|
|
|
|
|
I have no idea, you need to run some tests to see if decimal is appropriate.
|
|
|
|
|
Desimal re 20 slower than float.
An example :
Module Module1
Sub Main()
Dim f As Single = 123456792.0F
Dim fsw As New Stopwatch
fsw.Start()
For i = 1 To 100000000
f *= 1.00000012F
Next
fsw.Stop()
Dim dsw As New Stopwatch
dsw.Start()
Dim d As Decimal = 123456792.0F
For i = 1 To 100000000
d *= 1.00000012F
Next
dsw.Stop()
Console.WriteLine(f)
Console.WriteLine("Float (ms): " & fsw.ElapsedMilliseconds)
Console.WriteLine(d)
Console.WriteLine("Decimal (ms): " & dsw.ElapsedMilliseconds)
Console.WriteLine("Float is " & dsw.ElapsedMilliseconds / fsw.ElapsedMilliseconds & " faster")
Console.ReadLine()
End Sub
End Module
Results :
7.35348
Float <ms> : 306
123456800
Decimal <ms> : 6262
Float is 20.4640522875817 faster
|
|
|
|
|
And?
If the values being represented are not accurate, and in a financial app they BETTER BE ACCURATE, who gives a sh*t how much faster it is?
modified 18-Sep-14 7:46am.
|
|
|
|
|
Well that's irrelevant because you still cannot use float if you want accurate results. And if your results are not accurate your customers will leave you, or more likely sue you.
|
|
|
|
|
dilkonika wrote: ok , I understand why I should never choose float. ..aaah..
You should use floats when appropriate.
dilkonika wrote: But why I should not choose decimal ?
..it is slower than the non-so-precise float, but that's the trade-off. Sadly, the .NET decimal does not fit enterely into a SQL decimal.
Still accounting in cents makes more sense; as it is the mimimal nondivisible amount that the value can change.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote: ..it is slower than the non-so-precise float
It's very noticeable in a normal PC?
Quote: Still accounting in cents makes more sense; as it is the mimimal nondivisible amount that the value can change.
ok , but what about values like 2.672 ?
Yes , I have values like this because my application is going to work with multiple currency and the exchange rates .
Quote: Sadly, the .NET decimal does not fit enterely into a SQL decimal
Can explain with some more words this ?
Thank you !
Desimal re 20 slower than float.
An example :
Module Module1
Sub Main()
Dim f As Single = 123456792.0F
Dim fsw As New Stopwatch
fsw.Start()
For i = 1 To 100000000
f *= 1.00000012F
Next
fsw.Stop()
Dim dsw As New Stopwatch
dsw.Start()
Dim d As Decimal = 123456792.0F
For i = 1 To 100000000
d *= 1.00000012F
Next
dsw.Stop()
Console.WriteLine(f)
Console.WriteLine("Float (ms): " & fsw.ElapsedMilliseconds)
Console.WriteLine(d)
Console.WriteLine("Decimal (ms): " & dsw.ElapsedMilliseconds)
Console.WriteLine("Float is " & dsw.ElapsedMilliseconds / fsw.ElapsedMilliseconds & " faster")
Console.ReadLine()
End Sub
End Module
Results :
7.35348
Float : 306
123456800
Decimal : 6262
Float is 20.4640522875817 faster
modified 17-Sep-14 20:27pm.
|
|
|
|
|
Quote: but what about values like 2.672
You can still use integers. Multiple all values by 1000 or 10000 instead of 100.
So long as you consistently move the decimal point over the same number of places in all numbers your calculations will be accurate.
|
|
|
|
|
Sorry , but if always I use integers , why vbnet and sql servers have other data types like float or decimal ? Is better to tell to remove this kind of data type from their products because we can use integers.
|
|
|
|
|
Because they have their uses in other application types, such as scientific anaylsis where the float and double types excel more at representing numbers using scientific notation.
Don't blame Microsoft for this. They're just going by the IEEE standards for storing and representing numeric types.
Read this[^]
|
|
|
|
|
ok for float , but what about decimal ? when should they be used ?
|
|
|
|
|
Did you read the link to MSDN at all?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
Yeah and it still stuffs from the same limitations.
It all depends on what you're using Excel for.
You know what. Screw this. We've said everything that's going to be said.
Use whatever you want! After all, you're the sole person that's going to have to deal with your decision.
|
|
|
|
|
Ok , ok I see that you want to close this case as soon as possible.
But I think a forum is a place for discussion.
It's just a curiosity : Microsoft has included decimal in .net language programs and Sql server.
And why he not use this kind of data type in Excel ?
Or why don't use integers that you suggest ( and to multiply all the values by 100 , 1000 , 100000 .......) and as you think everything will be better.
I have the right to be against your opinion , you can be against to my opinion .. let's discuss. This is the forum.
|
|
|
|
|
Sigh...Excel is a general purpose application, not just financial, and so must support a large range of numbers, and also balance with speed.
|
|
|
|
|
dilkonika wrote: But I think a forum is a place for discussion. It is, but this is hardly a discussion.
SQL Server and Excel were not built at the same time, nor by the same people.
dilkonika wrote: Or why don't use integers that you suggest You are making assumptions without reading, kicking against the structure claiming it is bad without taking the time to ask why it was built like that. What WHERE they thinking.
Well, you ain't gonna find out.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The difficulty appears to be arising because you are comparing speed with accuracy - two things that by their very nature cannot be compared.
So you need to decide - do you want speed or accuracy?
If you really want more information regarding why floating point is used you will need to read up on computer hardware and architecture.
Basically computers are not decimal counting machines but binary counting machines. In order to maintain a decent processing speed numbers are stored as floating point,. The consequence is that repeated arithmetic operations on large numbers(numbers with many digits either side of the decimal point) can cause precision errors. Most people not running repeated arithmetic calculations with large numbers requiring a high degree of precision - Excel works perfectly well with floating point numbers.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|