 |
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
Re: RE: st: Appending several excel data sets into one
Dear all,
I agree that this thread has gone for a long time, I have to say this
problem still exists, I have received various ideas which I have been trying
to implement, but all without any success. I am not a good stata programer,
I am trying to teach myself this. So far, the thread that has been most
helpful as far as I am concerned is that from Joseph. In fact I have been
contacting individual people that have given me help that I think will work
and I have tried to run their advice. But in some parts, I am getting error
messages that I don't know how to solve them. Anyway, as soon as I get
something working properly, I will get back and summarise the help. Most
advice is assuming high level programing that I am getting to grips with.
Anyway, I will post back what I am doing and what error messages I am
getting, hopefully other people may notice may problem as opposed to the
indivuduals who gave me the advice in the first place. So keep throwing some
ideas if you have any other interesting ideas. Ideas with some examples arel
particularly helpful, because I can use them with respect to my problem.
Best wishes,
Patrick.
From: "Sergiy Radyakin" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: RE: st: Appending several excel data sets into one
Date: Mon, 17 Sep 2007 19:28:36 +0200
Ups! First and most important, my apologies to Mr. Coveney, who was
incorrectly cited in my previous posting.
I think this thread is gone far away from the original question, and
unless the author of the question (Patrick Musonda, if I can trace the
conversation back correctly) still experiences difficulties, it looks
like its time to wrap it up.
2Michael: Wikipedia defines Reproducibility "refers to the ability of
a test or experiment to be accurately reproduced, or replicated, by
someone else working independently." It never demands the results to
be obtained with one click of a button, or using only one programming
language, though it might be convenient in some cases it need not be
always like that.
2Neil: the code that I posted was a VBA code. Open any workbook in
excel, open Visual Basic Editor (Alt+F11), click "this workbook" and
paste the code. F5 to run and create an index page, which Mr. Reese
desired. (Perhaps I should write a manual for it, box it and sell for
$39.99 :) Regarding single/multiple languages: SQL statement SELECT
used by Mr. Coveney is, as he admits himself, from "Structured Query
Language". "Language" is important, and books comparable to the Stata
manuals (at least by kg weight) where written about SQL.
After looking at the first paragraphs on the webpage you've pointed, I
can say that:
1. REPRODUCIBILITY: point-and-click working with menus in Stata will
create the same problem unless the log file is opened. And it is the
whole idea of macros recording in Excel, that the clicks, changes and
all other actions _are reproducible_! All you need to do is to start
recording your actions _before_ you start changing your data
(analogous to opening a log file in Stata). With the arrival of the
new Stata 10 Graph Editor, reproducibility is lost to a certain degree
in Stata too. Or am I wrong? and the Graph Editor can yield a command
that reproduces the changes to the graph that the user has done with
the mouse? (in contrast to Excel)
2. SORTING: Explaining to colleagues/students the difference between
"sort x" and "sort x, stable" is a pain worth being counted as a
problem (why isn't "stable" a default option? Speed? Then why is
"meanonly" an optional option for "summarize"?)
3. SOURCE CODE: I haven't seen the source code for _regress yet. And
until I see it, I have the same moral right to declare that Stata �
---- abused quote ----
"is proprietary software and it is therefore impossible to view the
source code that implements the statistical routines, and you
therefore do not know if they have been implemented correctly."
---- end of abused quote ----
I have looked at some of the links from this page as well, e.g. here
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind01&L=allstat&P=R31997
I guess every one of us has once hit machine precision, but not with
such a big fuss about it.
100 and 13 decimals make it 16. So it is no surprise that Excel will
screw up the further decimals, because its limit is 15:
http://office.microsoft.com/en-gb/excel/HP051992911033.aspx?pid=CH062527721033&mode=print
Same happens to the Stata users as well. I guess it is a topic in the
FAQ, how should one compare floating-point numbers (or it ought to
be).
Of course there are some problems with Excel, but same applies to any
other software.
Best regards,
Sergiy Radyakin
On 9/17/07, Neil Shephard <[email protected]> wrote:
> On 9/17/07, Sergiy Radyakin <[email protected]> wrote:
> > Here is a quote from Mr. Coveney
> >
> > "If workbooks contain multiple sheets, you would like to access the
sheet
> > names. Excel doesn't provide this facility, but an add-in called
> > ASAP-utilities http://www.asap-utilities.com/ includes one to create
an
> > index sheet listing all sheets in the workbook. "
> >
>
> Pedantic, but it was actually Allan Reese who you are quoting there
> (see http://www.stata.com/statalist/archive/2007-09/msg00508.html).
>
> > And this is exactly where my comment was pointed to (index sheet).
> > Otherwise I would have posted a VBA code that appends 200 sheets
together.
>
> I would hazard that Micheal was pointing out that there is a solution
> which requires the user to learn only one language (i.e. Stata) as
> this is the package that analysis is to be performed in, as
> demonstrated by the code posted by Joseph Coveney (see
> http://www.stata.com/statalist/archive/2007-09/msg00510.html)
>
> Its useful that you have demonstrated that it is possible to achieve
> something in Excel with a relatively small number of lines rather than
> having to fork out for a third-party application (although I'm at a
> loss as to what the code you posted is for as there was no indication,
> and it didn't look like Stata code at all), but this would require
> that the original poster spent time learning Stata _and_ whatever
> language you posted in (which you are obviously already familiar and
> proficient in), which is clearly more time consuming than the ODBC
> solution that was provided.
>
> No doubt judicious programming of Excel does make reproducibility a
> mute point, but the crux is that this rarely happens. Excel is
> popular not because of how programmable it is via macros or Visual
> Basic, but because its a simple and intuitive point and click
> interface. This is itself the very downfall of the software. (Aside
> from the "black-box" of tricks that are hidden under the bonnet).
>
> For my own reference I have collated links to various expositions of
> problems associated with Excel at
> http://slack.ser.man.ac.uk/progs/stata/avoid_excel.html
>
> Regards
>
> Neil
>
> --
> "In mathematics you don't understand things. You just get used to
> them." - Johann von Neumann
>
> Email - [email protected] / [email protected]
> Website - http://slack.ser.man.ac.uk/
> Photos - http://www.flickr.com/photos/slackline/
> *
> * For searches and help try:
> * http://www.stata.com/support/faqs/res/findit.html
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
>
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
_________________________________________________________________
Can you see your house from the sky? Try Live Search Maps
http://maps.live.com
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/