|
Member 11096018 wrote: I am making a little app and I am stuck.
Where are you stuck? Edit your message and show exactly which part you are having problems with.
|
|
|
|
|
i figured it out
Private Sub Button8_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button8.Click
Dim counter As Integer = txtNames.Lines.Length - 1
' create array to reverse line order
ReDim fileNames(counter)
For iLine = 0 To counter
fileNames(counter) = txtNames.Lines(iLine)
Next iLine
' using the array building a string starting from the end of the array
Dim list As String = ""
For iLine = 0 To counter
list = list + txtNames.Lines(counter) + vbCrLf
counter = counter - 1
Next iLine
'display results
txtNames.Text = list.Trim
End Sub
modified 20-Sep-14 4:26am.
|
|
|
|
|
Good day friends! Please, does anyone know where I can download ebook for dx 11 and vb?
|
|
|
|
|
Sorry to state the obvious, but I would try Google.
|
|
|
|
|
You're not going to find any books on VB6 any more let alone with DirectX support in them.
Managed DirectX died quite a long time ago but there are third party alternative like SlimDX and SharpDX, though, there aren't any books on those libraries as far as I can find.
|
|
|
|
|
PictureBox1.Left += And() +6
if PictureBox1.left > 1000 then
PictureBox1.location = new point (150, 140)
end if
thanks
|
|
|
|
|
That first line is not valid VB.NET code. It'll never compile so there's really nothing to convert it to.
Seriously, VB6?? It's been dead for quite a long time now.
|
|
|
|
|
Seems that line
PictureBox1.Left += And() +6
is erratic - or do you really have a function named 'And'?? If so you'll have to enclose this VB key word in square brackets like
PictureBox1.Left += [And]() +6
otherwise remove it to:
PictureBox1.Left += 6
This will move your picture box 6 pixel to the right an if resulting position exceeds 1000 pixel, the picturebox position will be reset to a default.
|
|
|
|
|
Hello !
I'm using VB.net 2013 and SQL server 2008R2.
I'm writing a financial application , and I'm not sure about which data type to use.
I know that decimal is more precise that float , but I read that using decimal can significantly decrease the speed of calculations and the speed of storing data to database , so the speed of the application.
Is this true , and if yes is there a solution or should I continue to use float ?
Thank you !
|
|
|
|
|
dilkonika wrote: writing a financial application
Are you sure that you need decimal/float here? What about storing/calculating with Cents instead of Dollars - thus avoiding fractions at all?
|
|
|
|
|
For finacial calculations SQL Server has a MONEY datatype
=========================================================
I'm an optoholic - my glass is always half full of vodka.
=========================================================
|
|
|
|
|
Never use float (or double) for financial applications, as they are base 2 numbers and cannot accurately hold base 10 values. You can sometimes use integers, depending on the currency and values you need to represent.
|
|
|
|
|
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[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
