I am trying to select float values as varchar strings (for flat file export).
Have found several useful examples but none that seem to exactly match.
We have many different values in the data, that should all show up correctly and remain exactly how it was
e.g.,
23.30 should not become 23.3
23.0 should not become 23. or 23
23 should not become 23. or 23.0
23.33 should not become in 23.3300
many thanks for the help&time.
So after dnoeth'S question i had another thought and I'll just use
select cast(cast(cast(1234567890.19 as float) as NUMBER) as varchar(200))
Related
I have a huge CSV data file that generates 500,000+ rows and 70+ columns, running Excel queries over this much data causes my desktop to crash.
As an alternative i've managed to import the CSV into Access.
The majority of the data fields i need to review/consider within further calculations i've imported as "double" field type.
I guess the first question is should i use single rather than double? The values i am considering will only ever report to 2 decimal places.
Within the imported table i've created some new columns, as i need to validate that the sum of underlying values equals the totals reported.
A sum of 5 underlying columns (called SUMofService)
[Ancillary Costs] + [Incidental Costs] + [One-Off Costs] + [Ongoing Costs] + [Transaction Costs]
I've not reviewed all 500,000 rows, but this formula seems to be summing the values correctly.
Using this value i've then created a new column to compare this total to the total in the report
IIF([SUMofService] = [Total Service],"Match","No Match")
This also seems to work as expected, but there are instances where this field returns a false.
Looking at the underlying numbers in [SUMofService] and [TotalService] they match, so i am confused as to why i am seeing the false results.
Could anyone review what i've detailed, and perhaps provide a steer as to whether i've considered something incorrectly.
There are probably better ways to achieve what i'm trying to do, but i haven't really used Access since school and you forget quite a bit in 30 years!!
Any responses are much appreciated - i've googled this as much as i can, but not 100% what to ask, and some responses are so far beyond my level of thinking.
should I use single rather than double?
The values I am considering will only ever report to 2 decimal places.
Neither. Use Currency.
That will also provide correct results for:
IIF([SUMofService] = [Total Service],"Match","No Match")
Using Double or, indeed, Single will cause floating point errors - as in this classic example:
? 10.1 - 10.0
9.99999999999996E-02
' thus:
? 10.1 - 10.0 = 0.1
False
My original date variable is like this 19jun2015 16:52:04. After importing, it looks like this: 1.77065e+12
The storage type for the new imported variable is str11 and display format is %11s
I wonder how I can restore it back to date format?
William Lisowski gives excellent advice in his comment. For anyone using date-times in Stata, there is a minimal level of understanding without which confusion and outright error are unavoidable. Only study of the help so that your specific needs are understood can solve your difficulty.
There is a lack of detail in the question which makes precise advice difficult (imported -- from what kind of file? using which commands and/or third party programs?), except to diagnose that your dates are messed up and can only be corrected by going back to the original source.
Date strings such as "19jun2015 16:52:04" can be held in Stata as strings but to be useful they need to be converted to double numeric variables which hold the number of milliseconds since the beginning of 1960. This is a number that people cannot interpret, but Stata provides display formats so that displayed dates are intelligible.
Your example is when converted a number of the order of a trillion but if held as a string with only 6 significant figures you have, at a minimum, lost detail irretrievably.
These individual examples make my points concrete. di is an abbreviation for the display command.
clock() (and also Clock(), not shown or discussed here: see the help) converts string dates to milliseconds since Stata's origin. With a variable, you would use generate double.
. di %23.0f clock("19jun2015 16:52:04", "DMY hms")
1750351924000
If displayed with a specific format, you can check that Stata is interpreting your date-times correctly. There are also many small variations on the default %tc format to control precise display of date-time elements.
. di %tc clock("19jun2015 16:52:04", "DMY hms")
19jun2015 16:52:04
The first example shows that even date-times which are recent dates (~2016) and in integer seconds need 10 significant figures to be accurate; the default display gives 4; somehow you have 6, but that is not enough.
. di clock("19jun2015 16:52:04", "DMY hms")
1.750e+12
You need to import the dates again. If you import them exactly as shown, the rest can be done in Stata.
See https://en.wikipedia.org/wiki/Significant_figures if that phrase is unfamiliar.
I am currently working with a large data set using R. So, I have a column called "Offers". This column contains text describing 'promotions' that companies offer on their products. I am trying to extract numeric values from these. While, for most cases, I am able to do so well using a combination of regex and functions in R packages, I am unable to deal with a couple of specific cases of text shown below. I would really appreciate any help on these.
"Buying this ensures Savings of $50. Online Credit worth 35$ is also available. So buy soon!"
1a. I want to get both the numeric values out but in 2 different columns. How
do I go about that?
1b. For another problem that I have to solve, I only need to take the value associated with the credit. It is always the case that for texts like above, the second numeric value in the text, if it exists, is the one associated with the credit.
"Get 50% off on your 3 night stay along with 25 credits, offer available on 3 December 2016"
(How should I only take the value associated with credits?)
Note: Efficiency would be important as well because I am dealing with about 14 million rows.
I have tried looking online for a solution but have not found anything very satisfactory.
I am not 100% sure about what you want but this may help you.
A <- "do 50% and whatever 23"
B <- gregexpr("\\d+",A)[[1]]
firstNum <- substr(A,B[1],B[1]+attr(B,"match.length")[1]-1)
secondNum <- substr(A,B[2],B[2]+attr(B,"match.length")[2]-1)
Hope this helps.
I have searched around a bit and found some people asking a similar question, but I have not found an answer I can make work.
I have tab delimited .txt files which I need to read in to a SAS database. The files contain a serial number which is 18 numbers long so SAS imports this as "5.2231309E17".
Ideally SAS would import all the fields as if they were text, not numbers.
To add a complexity to this, the import files have 2 different formats, these are only visible once the file is open, I cannot tell which format the file is from the name. Also there are no column names in the file. So I don't know which column is which until I have read in the file.
Currently my starting point is:
data Readin;
infile foo dsd dlm='09'x truncover;
input item1-item25;
run;
foo is the file something like 'c:\myfile.txt'
Any help is appreciated.
There are two separate issues here. One is that the "9.234E17" is displaying in scientific notation, and two that you are reading in numbers that can't be stored exactly as numbers anyway.
First, this is how the BEST12. format works, which is the default numeric format for things like this. It's not truncating it in a meaningful way; if you simply change the format, to BEST32. for example, it will display the entire number, within the limits of precision, and it will always act as if it were the full number, again within the limits of precision; if I took 12345678, formatted BEST6., it would display as 1.23e7, but if I said if x=12345678 then do; put x; end;, it would put x, as it would be exactly equal to that value.
However, that last part is important, and the second part of your problem. You can't store 18 digit number precisely; 15 digits is the largest you can store precisely in Windows and similar Intel type environments, slightly different results on mainframes. So you definitely need these to be stored as character, unless you don't care about the last few digits (sounds like you do).
If you have a (anything)-delimited file, your best bet is to simply write a data step to read them in, at which point you can assign them as character yourself. Don't use proc import for most text files, unless they're really easy impossible to screw up sorts of things. What you can do is look at your log after PROC IMPORT ran, and copy that log into a program; then make adjustments to turn the serial number into a character field (and anything else you want to fix).
I had a similar problem, I was trying to import a file that had a 20 digit long field, one workaround i found for this was, opening the file in Excel and changing the attribute of the column from general to number, then when i imported the file, it was imported as a number and not in scientific notation
I have this function that should convert them from Ole to UTC8601 standard, but I don't understand how the integer representations of time seem to work.
Can anyone give me some explanation?
the function is called: RipOf_AfxTmFromOleDate
containing statements as: nDaysAbsolute %= 146097L; Where does the value come from and how is it calculated?
where nDaysAbsolute is a long type.
This app gets values from an Oracle database and sends them to another application.
In 400 years, there are 97 leap years.
146097 = 365 * 400 + 97.
Take a look at Julian Day calculations.