I want to show amount like this format 100,000,000.00. In my code i defined variable like this
DEFINE VARIABLE mAMOUNT AS INTEGER FORMAT "999,999,999,999,99.99".
and mAMOUNT = 100,000,000.00and how ever i got amount like this 100000000 Plz help me
define variable amount as decimal ">>>,>>>,>>>,>>9.99" no-undo.
amount = 123456789.01.
display amount.
"9" in a FORMAT phrase forces a digit to be shown -- you might have an "all 9s" format if you wanted leading zeros but that is unusual.
If you intend to have decimal places you need to use the DECIMAL datatype, not INTEGER.
Related
I want to apply data validation to my column so as to only accept whole numbers.
However I want these to be displayed with a dot so as to make it easier to read later on.
e.g. input = 14354 which is valid and then displayed 14.354
the data validation regular expression I am ussing is:
=regexmatch(to_text(A2);"^\d+\.*\d+$")
and the custom formatting is:
#,##
for most this working fine, large numbers are displayed with the '.' and things it shouldnt accept it is rejecting.
However, in the case of numbers which are entered with a decimal point as these are hidden, it is accepting it as valid.
It is also changing the format to auto atic and reading as date such entries like: 15.4
I should point out that I am using sheets in spanish and therefore the , is the marker for decimal places.
What am i missing here??
Select the cell range then go to Data > Data validation...
Add a custom formula rule:
=mod(A1;1)=0
Try this one:
=and(regexmatch(to_text(A2);"^\d+(\.\d{3})*$");mod(A2;1)=0)
Improved your formula to only accept a dot when it is followed by 3 numbers (this way, we invalidate the date e.g A2)
Combining the improved formula of yours and Aresvik's modulo answer, we need to check if the value does not have decimal. (this way, we invalidate the decimal e.g A6)
When both returns true, this shall confirm that the number inputted is a whole number with no decimal and not a date.
Output:
Invalid inputted values:
A2 - 15.4
A6 - 16412,212
I am looping over a set of scalars which contain quarterly sif values. I would like to convert them to hrf format and keep them stored in scalars.
However, I found that format %tq only accepts variables. Hence, the only workaround seems to i) convert the scalar to a variable ii) apply format %tq iii) convert the variable to a scalar.
Is there a more elegant and faster way to do this? (I am using Stata MP 15.1.)
You can have string scalars, so you can do this. I can't see why it would be useful, but that could be failure of imagination; you could enlighten us on why you want this.
. scalar foo = yq(2018, 4)
. scalar foo = string(scalar(foo), "%tq")
. scalar list
foo = 2018q4
What is quite different for scalars is that there is no sense whatsoever in which a display format is attached to or associated with a scalar. You can hold a numeric date or a string date in a scalar, but those are the only choices. You can't have a numeric value with a format on the side that Stata will use for display when suitable. You found that out when you attempted to format a scalar.
Goodness knows whether this is faster (than what?) or more elegant (who decides?). The major difference is that a variable manifestly can contain many dates and a changed format made just once with format can apply to them consistently, whereas changing how you show a bunch of scalars requires a loop every time you do it so far as I can see. Further, it follows from above that you might need to keep two sets of scalars, one numeric for calculation and one string for display.
I've used date constants and typically found that either I use them directly (subtracting 2000 as base doesn't requiring putting it into anything) or I use local macros to hold them. But I can't see anything wrong with using scalars, except possibly indirection.
I have a text filed which allows user to input numbers. This is what I did:
[_textfield setText:[NSString stringWithFormat:#"%d", [_textfield.text intValue]]];
Basically, I convert text in text filed to integer, then convert back to string. This will ensure the text is numbers only.
Now I need to store the text in _textfield into core data. I was wondering wether should use string as the attribute type or integer.
I know integer is a more sensible option. But to this case, every time the view is loaded, I need fetch this data and set to the _textfield. If I use integer as the attribute type, I have to convert to string each time. I know what I need to do is simply:
_textfield.text = [numberFromCoreData stringValue];
I don't need to compare, sort or do any arithmetic computation with that number, so should I just use string as the attribute type?
Integer searching is significantly faster than string searching. That is the single most compelling reason to use numbers in your persistence layer. Numbers also can sort differently than strings.
For performance reasons I would never use a string when I know the value is always going to be an integer. Control the input, force it to only accept numbers and keep your data integrity.
It depends how you need to use that field. In almost every case, integer data should be stored as an integer type, but not always. You definitely want an integer type if you'll ever be using that field in a case where its numeric value counts in some way. That includes sorting (because it's a hell of a lot faster with numeric fields), comparing numeric values, or any kind of mathematical operation.
But there's are exceptions. For example, in some cases fields which initially seem to be inherently numeric turn out not to be so. Like a "size" field which is normally an integer. But on closer inspection it turns out that some sizes are specified as "8 - 10", "12 - 14", etc. This happened in one app I worked on a couple of years ago. In that case I ended up using two fields for the data-- a numeric "sortSize" that could be used for sorting, and a string "displaySize" that included the full string.
It's probably not what you want but why don't you use a keyboard type "number Pad" for your textfield?
With that, you would be sure that you have only numbers into your textfield.
Honestly I can't think of a compelling reason. Strings in general take up more storage space than Integers but in the modern world of computing this isn't much of an issue. If you aren't really pushing you processor too hard I'd go with what is convenient.
From the most basic way of thinking about it an integer is a number but for a string the computer needs to know when the string ends, starts, and what is in it so its a little bigger.
I am trying to read in the following in line:
110134458.602 7 20957861.900
My format line is currently as follows:
READ(7,110,END=999) L1,C1,D1
write(*,*) L1,C1,D1
110 FORMAT(F14.3,1x,F1.0,2x,F14.3)
However the output I am receiving is:
110134458.60200000 7.0000000000000000 20957861.899999999
Why do I have so many decimal places and why is the final value not match?
Thank you!
It looks that you are reading the values correctly. With list-directed IO for the output the compiler will typically use the maximum number of digits for the numeric type. Not all decimal values will have exact finite precision binary equivalents -- that is probably what you are seeing for the 3rd number. If you use a format statement for the output, specifying fewer digits, the value will get rounded and appear correct.
I am maintaining an app for a client that is used in two locations. One in England and one in Poland.
The database is stored in England and uses the format £1000.00 for currency, but the information is being gathered locally in Poland where 1000,00 is the format.
My question is, in VB6 is there a function that takes a currency string in a local format and converts to another, or will I just have to parse the string and replace , or . ?
BTW I have looked at CCur, but not sure if that will do what I want.
The data is not actually stored as the string "£1000.00"; it's stored in some numeric format.
Sidebar: Usually databases are set up to store money amounts using either the decimal data type (also called money in some DBs), or as a floating point number (also called double).
The difference is that when it's stored as decimal certain numbers like 0.01 are represented exactly whereas in double those numbers can only be stored approximately, causing rounding errors.
The database appears to be storing the number as "£1000.00" because something is formatting it for display. In VB6, there's a function FormatCurrency which would take a number like 1000 and return a string like "£1000.00".
You'll notice that the FormatCurrency function does not take an argument specifying what type of currency to use. That's because it, along with all the other locale-specific functions in VB, figures out the currency from the current locale of the system (from the Windows Control Panel).
That means that on my system,
Debug.Print FormatCurrency(1000)
will print $1,000.00, but if I run that same program on a Windows computer set to the UK locale, it will probably print £1,000.00, which, of course, is something completely different.
Similarly, you've got some code, somewhere, I can't tell where, in Poland, it seems, that is responsible for parsing the user's string and converting it to a number. And if that code is in Visual Basic, again, it's relying on the control panel to decide whether "." or "," is the thousands separator and whether "," or "." is the decimal point.
The function CDbl converts its argument to a number. So for example on my system in the US
Debug.Print CDbl("1.200")
produces the number one point two, on a system with the Control Panel set to European formatting, it would produce the number one thousand, two hundred.
It's possible that the problem is that you have someone sitting a computer with the regional control panel set to use "." as the decimal separator, but they're typing "," as the decimal separator.
What database are you using? And what data type is the amount stored in?
As long as you are always converting from one format to another, you do not need to do any parsing, just replace "." with "," or the other way around. You may need to remove the "£"-sign as well if that is stored in your string.
There's probably a correct answer dealing with culture objects and such, but the easiest way would be to taken the input from the polish input, and replace the , with a ., and then store it in your database as type "money" or "decimal". If you know they (possibly configurable per user) are always entering numbers in either Polish or English, you could have a function that you run all the input numbers through to convert the string to a proper "decimal" typed variable. Also, for display purposes you could run it through another similar function to ensure that the user always sees the number format they are comfortable with. The key here is to switch it to a decimal as soon as you get it from the user, and only switch it back to a string at the last step before sending it out to the user.
#KiwiBastard yes i would think so. Are you storing your amount in an "(n)varchar" field or are you using a currency/decimal type field? If the latter is the case, the currency-symbols and separators are added by your client, and there would be no need to replace anything in the database.