dear friend,
i need to convert the following string in to integer.
"002"
i need to convert to integer then my ineger should be as follows;
002
i have tried using CInt. but it gives 2.so how can i convert this to get integer as 002.
Printable View
dear friend,
i need to convert the following string in to integer.
"002"
i need to convert to integer then my ineger should be as follows;
002
i have tried using CInt. but it gives 2.so how can i convert this to get integer as 002.
002 isn't an integer or any kind of number. If you want to keep the zeroes in front, you need to keep it as a string. Leading zeroes mean nothing in a number.
As Tom said, you can't.
One thing which you might want to do is keep the leading 0's for display purposes and i've found that pad left etc... is good for this.
(Just as a quick example)
vb Code:
dear friends
thanks for the reply.
Quote:
Originally Posted by Tom Sawyer
002 is by all means a number and an integer. VB (any programming language for that matter) just does not hold on to non significant digits in numeric data types.
002 isn't an integer = false
No, 002 is a string. 2 is an integer. When any language reads 002 as an integer, it strips off the zeros and reads it as 2.Quote:
Originally Posted by kleinma
no
"002" is a string
002 is an integer
Go find a mathematician, and tell them 002 is not an integer value
We're talking about programming, not theoretical mathematics.Quote:
Originally Posted by kleinma
Go into Visual Studio. Type:
Dim x as integer
x = 002
Then press enter and see what happens. Go find a programmer who will have anything else happen.
I guess for the purposes of programming languajes it's pointless to wheter or not 002 is an integer or string. Such discussion doesn't serve the purpose of the thread I would guess.
Tom you said 002 is not an integer or any kind of number.Quote:
Originally Posted by Tom Sawyer
Yes I know VB strips insignificant digits from numbers. That is very true. That however does NOT mean 002 is not a number. You called it a string..
However which line of code is going to give you an error?
Sorry.. we could fight over it I suppose, but what is the point?Code:Dim myInt as Integer = 002
Dim myString as String = 002
I know the message you were trying to convey to the OP, and I think you answered his question to his liking, I am just correcting what was incorrectly stated in your post.
Dim myInt as Integer = 002 becomes
Dim myInt as Integer = 2 as soon as I press enter.
What mathematicians call a number is not relevant. What the CLR interprets a System.Int32 value as is what matters, as that is the definition of an integer in visual basic. Leading zeros are not included in this interpretation, so if you want to have something with leading zeros, you cannot use this value type to store it on the stack. For the definition of a Visual Basic Integer, that's all that matters.
This is correct. I cant see why you would want to keep the leading zeros in any calculations but for displaying its just a formatting issue.Quote:
Originally Posted by kleinma
it doesn't store them because they make no difference in the math that will be done with them. It would just be wasted 0s taking up space in memory.Quote:
Originally Posted by Tom Sawyer
Just because the IDE happens to be productive and strips insignificant digits when you use them, still does not mean 002 is not a number.
If I code in notepad, and compile against the VBC I could write
Dim myInteger as integer = 002
Notepad sure isn't going to strip those 0s for me. The compiler will, but I will never see that happen.
I am not trying to fight you on what the IDE or VB language does to leading 0s. I am just saying your claim that 002 is not a number simply is not correct. If you don't want to agree with that, then that is your decision.
Crikey, I go away for 15 minutes and this simple little post has turned mental.
Tom,
Kleinma was only pointing out that your blanket sounding statement ("002 isn't any kind of number") wasn't accurate and is fair enough.
It's just a matter of scope really. You are saying when you press return the 0's won't stay there within the IDE which is fair enough. But that's not the same as saying 002 isn't a numerical type (inside or outside of any IDE) which is what your statement sort of implied.
I don't want to get caught in any cross fire here, so I'm waving my white flag and running away but i know exactly what has caused this and as Kleinma has said - it's not worth any more time.
*runs and ducks for cover*
It isn't a number. By number, I of course mean a numeric value type that the CLR can read. Which one of those allocates memory on the stack for a value that contains leading zeros? If there isn't one, then 002 is not a number inside of VB or any other .NET language.Quote:
Originally Posted by kleinma
This is a programming forum, so the programmatic definition of a number is the only one that matters. The IDE's functionality, while indictive of what happens on a lower level, is not the core issue. The core issue is what gets compiled to the IL and the CLR. A mathematician's definition of an integer is as relative to the discussion as it would be if there's some cook who calls a pound of flour an integer - it just doesn't matter as relates to a VB program.
Inside VB, 002 is not a number.
Like I said, there is no point in arguing this further. You keep your opinion, and I will keep mine.
Maybe someday you will go for some programming job and they will ask you what 002 is. Go ahead and tell them its not a number, its a string.
It's not an opinion, it's a fact. There is no System.Int32 value of 002.Quote:
Originally Posted by kleinma
Maybe someday, you will have a programming job where you will be asked to store leading zeros in a numeric data type. Good luck with that.
002 = 2 = 00000000000000000000000000000000002
insignificant digits (leading 0s) is concept.... they all equal values..
The statement you made, that prompted my comment, was when you said 002 is "NOT ANY KIND OF NUMBER". To that I said you are wrong, 002 is very much a number.
I never say you could store insignificant digits in numeric data types, all I said was 002 is a number. You called it a string.
It is a fact that you can not store insigificant digits in numeric data types, it is NOT a fact that 002 is not a number, and it is very much not a string...
It doesn't matter what it is as a concept, it matters what it is as a value on the stack. A System.Int32 value type does not store a value of 002 or 0000000002 or any other number of leading zeros and a 2. It only stores the 2. Therefore, inside of visual basic, there is no integer with a value of 002.
The fact that outside of visual basic, there are things called integers that can have a value of 002 is not relevant to the fact that there is nothing inside of it that can have that value.
but numbers exist outside visual basic, and you said 002 is not a number.
Am I taking you too literally? Maybe... but my point in posting was just to correct that generalized statement you made, because just because YOU know how VB/CLR treats numbers, and I know as well, doesn't mean a few million others who might come across this thread know.
So to make a statement like 002 is not a number, versus saying something like System.Int32 can not represent insignificant digits, I felt compelled to post and say I don't agree with the statement.
Actually you are all wrong. I am willing to bet that the system will store you integer 2 or 002 or 0000000002 as:
0x00000002
And int64 on a 64 bit operating system:
0x0000000000000002
Mathematically speaking 002 is an integer. If you want to display 002 in your program it needs to be converted to a string otherwise only significant figures will be displayed; therefore in programming speak you cannot store the number of leading zeros unless you store it as string so 002 can only be represented literally with a string. If you want to store 002 then store it as an int or a long or a byte.
Why the pointless argument?
To avoid VS interference, I created a .vb file
(notepad)Code:Module Main
Sub Main()
Dim i as Int32 = 002
Console.WriteLine(i.GetType().Name)
End Sub
End Module
And then ran vbc.exe against it.
vbc test.vb
The .exe generated gave this output:
Int32
That means that 002 is a number, although the leading 0s may be removed at runtime.
I am willing to argue in favour for the addition of this new sting data type :D
If someone asks how to do something in a loop, do you tell him how to do it while he's driving on a roundabout, or do you understand that, due to the forum he's posting in, he's referring to the programmatic definition of a loop and not some other definition of the word? Why would it be different for an integer?Quote:
Originally Posted by kleinma
Integer means System.Int32. They're synonyms. Number means numeric datatype. It doesn't refer to a song someone is playing or any other definition of the word that isn't referring to a programming concept.
Sorry, forgot the ILDASM output
Hope that doesn't help in any constructive way at all.Code:.method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 24 (0x18)
.maxstack 1
.locals init (int32 V_0)
IL_0000: ldc.i4.2
IL_0001: stloc.0
IL_0002: ldloc.0
IL_0003: box [mscorlib]System.Int32
IL_0008: callvirt instance class [mscorlib]System.Type [mscorlib]System.Object::GetType()
IL_000d: callvirt instance string [mscorlib]System.Reflection.MemberInfo::get_Name()
IL_0012: call void [mscorlib]System.Console::WriteLine(string)
IL_0017: ret
} // end of method Main::Main
So what you are saying then, is if you assign a number to an integer type in VB, and that number does not fill up all the bytes of that data type, then what fills those leading spaces in memory??? 0s???? ;)Quote:
Originally Posted by visualAd
Actually, it helps immensely:
IL_0003: box [mscorlib]System.Int32
An extra line of processing is required to convert the value you typed in into an Int32. This is all I'm saying.
Also, how come your IDE lets you put i = 002? Mine changes it to a 2.
because his IDE is notepad...
I am almost 100% certain that 2
as int32 looks like this in memory
00000000000000000000000000000010
and as Int64 like this in memory
0000000000000000000000000000000000000000000000000000000000000010
As custom we write numbers without leading zero's, but it is just a custom. No mathmatical rule or formula that I am aware of would break down if we chose not to observe the custom.
1 + 1 = 2
0001 + 0001 = 0002
Notepad isn't an IDE. IDE means Integrated Development Environment. Notepad is simply a text editor and this definition doesn't apply to it.Quote:
Originally Posted by kleinma
No, no, let me explain. In order to avoid the IDE formatting the 002 in the first place, I created the console app in notepad and then compiled it with vbc.exe to see how the compiler would handle it.
That's pretty f-ing clever. Good solution.Quote:
Originally Posted by mendhak
cough see post #13 coughQuote:
Originally Posted by Tom Sawyer
Very well. You're clever too. I didn't see that part.Quote:
Originally Posted by kleinma
I can think of a custom where leading zero's are used, military time(see below). The below list has two errors though.
12:00 AM -- 0000 hrs
1:00 AM -- 0100 hrs
2:00 AM -- 0200 hrs
3:00 AM -- 0300 hrs
4:00 AM -- 0400 hrs
5:00 AM -- 0500 hrs
6:00 AM -- 0600 hrs
7:00 AM -- 0700 hrs
8:00 AM -- 0800 hrs
9:00 AM -- 0900 hrs
10:00 AM -- 1000 hrs
11:00 AM -- 1100 hrs
12:00 PM -- 1200 hrs
1:00 PM -- 1300 hrs
2:00 PM -- 1400 hrs
3:00 PM -- 1500 hrs
4:00 PM -- 1600 hrs
5:00 PM -- 1700 hrs
6:00 PM -- 1800 hrs
7:00 PM -- 1900 hrs
8:00 PM -- 2000 hrs
9:00 PM -- 2100 hrs
10:00 PM -- 2200 hrs
11:00 PM -- 2300 hrs
Let's just agree that we're all clever and I'm 002 times as clever as both of you. :afrog:
I also have a feeling that this debate will be revisited in a few months time, these things don't go away.
002 as in little endian or big endian?
First, this thread should be in more general forum. Why just in Visual Basic.NET. Share it with everyone.
Second, this is my opinion, you may agree or not:
In mathematics: "two always equals two", otherwise "two" does not belong to a numeric/counting system. That is the uniqeness of every number in a numeric system.
In a computer system: "two may not equal two".
"Byte" number two is stored by 8 bits as 00000010
"Integer" number two is stored by 16 bits as 0000000000000010
"Long" number two is stored by 32 bits as 00000000000000000000000000000010
(You know how to write down "Int64" number two and so on)
So, actually this "two" does not equal the other "two".
"2" is the visual represent of number "two" by mean of an Arabic numeric system. Yes, that is Arabic.
For a long time the western world use Rome's sytem: I II III IV V VI ... and in this sytem "II" represents number "two".
The Chinese people use "二" to represent number "two".
The Arabic numeric system originally did not have number "0". To make it becomes a complete numeric system (when doing subtraction a-b with a=b leading to the creation of 0), that "0" was added in not long ago, just 4-5 centuries and that "0" came from India in an original form of a small dot (·).[*]
(open this thread of our forum too view the discussion on the problem of missing "ZERO" in a counting system, that is used to denote columns in Excel)
Under Arabic numeric system (with 0), traditionally on writting a number, all leading 0's are dropped, because 2 = 02 = 002 = 0002 = 0...02. That is an axiom of this system.
So, by mean of a mathematics numeric system, 002 and 2 are two of infinite ways to present the number "two".
And 002 is really a number in this system.
Added: If you want a computer system display number "two" as 002 instead of 2, just ask Bill Gates, may be he can do it.
Added again: Have you ever seen a banking accouting report that comes straight from Cobol output? Most of numbers come with leading 0's.
[*] Correction: I mixed up between 0 (·) and decimal-dot (.). That was corrected as blue text above.
Your test was crippled by the fact that you told the compiler explicitly what you demanded the number should be cast to eg...Quote:
Originally Posted by mendhak
So it really doesn't prove much of anything apart from the fact that your compiler works :DCode:Dim i as Int32 = 002
Pfaff! What's all this decimal tish tosh anyway?
I just entered
int a = 0x002;
in to my C# ide and it took it (where 0x is the denominator for hexadecimal). I think in vb it's
a = &H002
So in Hex, 002 is definetly a valid number. Next thing you'll be telling me is that A isn't a valid number! :p
No!
In term of VB's IDE, if you enter
a = &H002
then press Enter, that will be converted to
a = &H2
:wave:Quote:
Originally Posted by anhn
maybe according to your computer, but my wall clock disagrees. It doesn't have a "midnight" or "noon" display either but still somehow manages to convey the correct time.Quote:
Originally Posted by dbasnett
Ah - I have just ventured down into our dungeon and unchained our pet VB programmer and he does indeed agree with you that the VB IDE does lop off the extra digits, however that doesn't change the matter that in C# it stays as 002. :)Quote:
Originally Posted by anhn
Does your wall clock have AM and PM?Quote:
Originally Posted by Lord Orwell
yes it does. It's digital.