in Delphi XE8 I have to convert a '03213213210' string into an int64
a:=strToint64('03213213210');
I receive a = 3213213210; How can i receive? a = 03213213210;
Help me. Thank you.
An Int64 is a numeric value. It holds a number. Numbers have no concept of formatting, leading zeros, representation base etc. A number is just a number.
Concepts such as binary, octal, decimal, hexadecimal have no impact on the value of the number, just its representation. Similarly, formatting requirements such as a set number of digits are not related to the value, but are a property of formatting of the value for display.
In short, leading zeros are not a property of a number. Your Int64 variable contains the number. When you choose to display it, you may opt to enforce a set number of digits, for instance by padding with leading zeros to achieve that number. But that's not a property of the number, the Int64 variable. That's a property of how you choose to display it.
So, if you really need to send the value as an Int64, then you have nothing more to do. If it needs to be displayed with 11 digits, with zero left padding, then that formatting is the responsibility of whoever displays it. On the other hand, it is possible that you should be holding the value as a string in order to preserve the formatting.
I can't tell which of the two options above is what you need to do, but I can be quite sure that trying to store leading zeros in an Int64 is not the solution because that is not possible.
Related
In an excel program, I was debugging when I noticed that the string function of a number returned the number but with a space in front of it: str(1) returned " 1".
As far as I am aware, there is nothing much on the internet about this, so I would appreciate knowing whether it is a glitch, or if I am doing something wrong. There is a way of working around, if this may help:
Mid(Str(1), 2, 1) So what this does is take the second character of " 1", and if the number is 5 characters long, for example, change the number at the end to 5 eg Mid(Str(11111), 2, 5).
Thanks for any feedback, however, with the work-around, it is not 100% necessary that this question is answered.
If it helps, I use office 365...
From the VBA Reference:
When numbers are converted to strings, a leading space is always reserved for the sign of number. If number is positive, the returned string contains a leading space and the plus sign is implied. Use the Format function to convert numeric values you want formatted as dates, times, or currency or in other user-defined formats. Unlike Str, the Format function doesn't include a leading space for the sign of number.
Please see:
Str Function
The leading space provided by VBA's Str function to positive numbers is for alignment purposes.
Text/strings are by default left-aligned on the worksheet. Since negative numbers receive a hyphen, positive numbers receive a space to maintain alignment.
Btw, if you omit VBA's Mid function's third argument (number of characters), all remaining characters from the second argument's starting position are returned. This means that Mid(Str(<any number>), 2) will always return the full number although any negative number's sign would be omitted. This does not work with the worksheet's MID function.
I'm working with a dataset that has really terrible ID numbers that are an integer followed by a 13 digit decimal. However, the first 6-7 decimal places are zeroes. For example:
10.0000000960554
This is making my life difficult. So I want to parse the IDs apart at the decimal into two integers, drop the leading zeros, and put them back together as one giant integer. However, everything I find for how to do this in Excel keeps the numbers after the decimal after the decimal. For Stata, I've tried to convert the numeric into a string so I can then parse it, but Stata won't let me because it's a decimal:
encode ScrambledID, generate StringID
Here's the error:
not possible with numeric variable
r(107);
An added issue, I can't just split the decimal in Excel and then multiply by 1e+12 because it messes with the values (long story with how they were derived).
Like I said, I'm fine with doing this in either Stata or Excel. Either way this is driving me nuts.
In Excel:
In one column put:
=int(A1)
In the next put:
=--MID(A1,FIND(".",A1)+1,999)
As #Grade'Eh'Bacon stated, I have use a few shortcuts in the above formula. The -- at the beginning change text that are numbers into numbers. It replaces the VALUE() function.
The 999 is a superfluous number in that it is assumed the length of the string being split is not longer than 999 characters. It can be replaced with the LEN() function which would return the actual length of the string.
So putting the two together:
=VALUE(MID(A1,FIND(".",A1)+1,LEN(A1))
Where A1 is the location of the number
Your story is truly shocking.
I'd advise extreme caution in any software. For a start, numbers with decimal parts will be rendered differently depending on whether they are imported as 4-byte or 8-byte reals, in Stata terms as floats or doubles. The underlying problem is that many decimal numbers have no exact binary representation.
In Stata terms, encode is indeed out of the question for a numeric variable (and your example would also fail for other reasons). But ideally you should import the identifiers as strings in the first place. Otherwise you should try a conversion such as generate stringID = string(numid, "%16.13f").
. di %21s string(10.0000000960554, "%16.13f")
10.0000000960554
. di %21s string(10.00000009605539, "%16.13f")
10.0000000960554
. di %21s string(10.00000009605544, "%16.13f")
10.0000000960554
. di %21s string(10.00000009605535, "%16.13f")
10.0000000960554
To make the sale to my customer I need to import numbers from a report into an Excel document. For example the number coming in will be 14.182392. The only reason for my guy not to buy the product is because he only wants to view 14.182 on the Excel sheet. Okay so the other catch is, the number CANNOT be rounded in any shape or form.
So what I need is a way to just show so much of number, WITHOUT ROUNDING.
Is this possible? Any ideas of how I could get around this would be fantastic.
Please try:
=TEXT(INT(A1)+VALUE(LEFT(MOD(A1,1),5)),"00.000")
Firstly =TRUNC is a better answer (much shorter). My version was connected with uncertainty in your requirement (it is odd!) and in the hope it might be easier to adjust if not exactly what you/your boss wanted.
TRUNC literally just truncates the decimals (no rounding!) to a length to suit (ie 3 if to show nn.182 given nn.182392 or say nn.182999).
LEFT may also be a better choice, but that depends upon knowing how large the integer part of your number is. =LEFT(A1,6) would display 14.189 given say 14.189999 in A1. However it would show 1.4189 given 1.4189999 in A1 (ie four decimal places).
The formula above combines text manipulation with number manipulation.:
INT takes just the integer value (here 14.)
MOD takes just the modulus – the residual that is not an integer after division, in this case by 1. So just the .182392 part. LEFT is then applied here in a similar way to as used above, but without needing to concern oneself with the length of the integer part of the source value (ie 14 or 1 etc does not matter).
VALUE then converts the result back into numeric format (string manipulation functions such as LEFT always return text format) so our abbreviated decimal string can then be added to our integer.
Finally, the TEXT part is for formatting but is hard or impossible to justify! About the only use is that it displays the result left-justified in the cell – perhaps a little warning that the number displayed is not the “true” value (eg it won’t SUM) because, as a result of a formula, it won’t be marked with a little green warning triangle.
The displayed values can use the TRUNC function like this,
=TRUNC(A1, 3)
But you must use A1 in any calculations to retain the precision of the raw value.
Easiest way I know:
=LEFT(A1; x)
where x = the amount of characters You want. Mind that the dot counts as a character as well.
I have this number
111100000000000010001000
I want to extend it to 32 bits with leading zeros. In other words:
00000000111100000000000010001000
So I found this suggestion here:
Add leading zeroes/0's to existing Excel values to certain length
is to use the Right function. So I do:
=RIGHT("00000000000000000000000000000000"+A1,32)
I end up getting a number in Engineering notation. So as suggested somewhere else I add:
=TEXT(RIGHT("00000000000000000000000000000000"+A1,32), "0")
I still get
111100000000000000000000
Not 32-bit and the trailing 10001000 has become zeros.
Any idea what's happening here??
Excel takes that as a decimal number, not a binary number.
111100000000000010001000 as a decimal number is too much for the number precision Excel has to offer, so that is rounded to 111100000000000000000000 before you apply your zeros (which you can see yourself if you apply a numeric format to A1 that disallows scientific notation).
The solution is the same, treat all numbers as string. Prefix the source number in A1 with an apostrophe to make it a string, the RIGHT will then work as you expect.
Well, it actually won't, because I used + when I should have used &, so Excel will try to convert to numbers and actually make the addition. So correct the formula:
=RIGHT("00000000000000000000000000000000"&A1,32)
I know you can set date formatting, but how do you set other locale specific stuff like decimal number formatting? (I mean comma vs. dot)
Short answer: you don't.
You seem to be somewhat confusing the textual representation of a number and an actual numeric value.
While JSON is a text-based data interchange format, a number (vs. a string) in JSON is a numeric value and is not affected by locale. Section 2.4 of the JSON specification provides the specific definition (emphasis mine):
2.4. Numbers
The representation of numbers is similar to that used in most
programming languages. A number contains an integer component that
may be prefixed with an optional minus sign, which may be followed by
a fraction part and/or an exponent part.
Octal and hex forms are not allowed. Leading zeros are not
allowed.
A fraction part is a decimal point followed by one or more digits.
An exponent part begins with the letter E in upper or lowercase,
which may be followed by a plus or minus sign. The E and optional
sign are followed by one or more digits.
Numeric values that cannot be represented as sequences of digits
(such as Infinity and NaN) are not permitted.
Given the above, something such as {"my_double":3,2} is not valid JSON. {"my_double":3.2} is.
When parsing JSON, a parser is going to store numbers to a primitive data type (int or double). Your locale will then display those properly using the normal methods for converting them to strings; Integer.toString(myInt),String.valueOf(myDouble), etc.