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.
Related
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.
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
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 want to give a pattern in cognos. like this
my number : 12.20
my wanted number : 12.2 i want to delet 0 how I give pattern.
If no data format is mentioned, then the default format will take care of trailing zeros.
But if you are using some data format (number, currency) then the trailing zeros will be added till the mentioned decimal places in your format.
To suppress a digit if the value is zero, you can use pattern attribute in the Data Format property.
In your example, to suppress 2nd decimal place zero, you can mention the pattern as
.0#
With this pattern, first decimal place digit will be shown even if the value is zero. Whereas, second decimal place digit will not be shown even if the value is zero.
Please refer to IBM Cognos inforcenter for Decimal Format Symbols for the Pattern. http://publib.boulder.ibm.com/infocenter/c8bi/v8r4m0/index.jsp
How do you compare strings binary (not alphanumeric) ??
Torrent spec:
Keys must be strings and appear in sorted order (sorted as raw
strings, not alphanumerics). The strings should be compared using a
binary comparison, not a culture-specific "natural" comparison.
So i need to sort a dict by key... but i dont get this spec..
Explanations ..anyone?
Update: acordingly to: http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch5lingsort.htm
Using Binary Sorts
One way to sort character data is based on the numeric values of the
characters defined by the character encoding scheme. This is called a
binary sort. Binary sorts are the fastest type of sort. They produce
reasonable results for the English alphabet because the ASCII and
EBCDIC standards define the letters A to Z in ascending numeric value.
Note: In the ASCII standard, all uppercase letters appear before any
lowercase letters. In the EBCDIC standard, the opposite is true: all
lowercase letters appear before any uppercase letters.
When characters used in other languages are present, a binary sort
usually does not produce reasonable results. For example, an ascending
ORDER BY query returns the character strings ABC, ABZ, BCD, ÄBC, when
Ä has a higher numeric value than B in the character encoding scheme.
A binary sort is not usually linguistically meaningful for Asian
languages that use ideographic characters.
So basically it the same result for english as alfabetically sorting..
Nice..
Any standard sort routine should work, as long as you ensure the characters are treated as bytes.