[Mohammad Shoaib]

Thank you Sergiy and Joseph,

Sergiy Radyakin, It is possible to import a Persian language text in to Stata 14, for example I import the data set from Ms. Excel into Stata 14 it works perfect. But what is not working well, let me give you an example, assume that I have a data set in Persian language and it has variable (gender) and it is a string variable (Male and Female) when I check the data in data editor it looks fine and in good shape (Male and Female) but when I do a tabulation in result window it shows the the out put different in revers order it shows the Male "elaM" and Female "elameF".

Thank you again,




,

[Marcos Almeida]

If I understood right, I fear that 'reverting the order' in #31 just means keeping the alphabetical order. What is more, it seems to be unrelated to how unicode in Stata 'treats' Pearsian language. Among the strategies to keep the previous reference level, the factor notation 'ib#." may do the trick.

[Joseph Coveney]

The way I understood it, Persian is written right-to-left and, although the text is stored in the dataset correctly, when Mohammad executes a tabulate command on the variable, in the display of the text in the Results window is reversed, left-to-right. I played around with some Persian text (using simple translations copied and pasted into a string variable from Google Translate), and I did not find such a phenomenon to happen with tabulate. The direction of the text did not appear to be altered.

But my understanding could be wrong, and so perhaps Mohammad could list some data from a toy dataset and show the output from tabulate (or whatever command) that illustrates the problem for everyone to be clear in understanding.

[daniel klein]

But my understanding could be wrong, and so perhaps Mohammad could list some data from a toy dataset and show the output from tabulate (or whatever command) that illustrates the problem for everyone to be clear in understanding.

Perhaps, Mohammad can start his own thread for this, as it is really getting off topic here. Someone with the same or similar problems is unlikely to search the archive for "Stata 15 is here" in the future.

Best
Daniel

[Sean Fiedler]

Why is FRED Support being mentioned as a new feature? It is a great feature to be sure, but the command -freduse- has existed for some time and seems to provide the functionality described. Is there some new functionality that I'm missing?

1. Federal Reserve Economic Data (FRED) support. 470,000 U.S. and international economic and financial time series are available to registered users courtesy of the St. Louis Federal Reserve Bank. You should register. It's free and easy. If you do, Stata can browse, search, and assemble datasets for you.
    

[Alan Riley (StataCorp)]

Why is FRED Support being mentioned as a new feature? It is a great feature to be sure, but the command -freduse- has existed for some time and seems to provide the functionality described. Is there some new functionality that I'm missing?

Yes, there is new functionality. import fred is a entirely new implementation to access FRED and ALFRED series, and it includes a new and slick graphical interface for searching and browsing for series of interest. It has more new features too.

The old freduse let you specify the series that you wished to load but did not provide ability to search, ability to control aggregation level, a graphical user interface, support for wide versus long formats when importing, selection of date range, and so on. It also used a now-deprecated URL-only way of accessing the series. The old command continues to work for now, but FRED wants developers to use their API for accessing series.

In addition to the new import fred's interface, the new command includes lots of options to control date ranges imported, how series are aggregated, access to historical series, control over wide versus long format, and interacts with FRED via the official FRED API.

The old freduse was not official because it was not up to our standards. It was a placeholder until we could do something better.

[Daniel Jensen]

6. Working with several databases at the same time - I understand that this will mean a major shift in stata-philosophy, but since other stat software to this at ease, I see no reason for stata not to have this pretty basic feature - Instead the user has to juggle with multiple instances of stata, or keep clearing and using each dataset separately.?

Like Dave Airey, I have different feelings about these points. Until I own a room of servers, I'd rather take Stata's stability over the ability to juggle multiple datasets at once. merge is a pretty efficient command, so if I have multiple datasets, I just put them together in the do file, rather than juggling multiple instances.

[wbuchanan]

Alan Riley (StataCorp)
I haven't had a chance to dig into this yet, but have there been corresponding changes to scheme files to support the alpha levels? I'm definitely glad that there is alpha layer transparency since it will help quite a bit with overplotting and making it easier to spot density differences. I definitely am liking the new features that were added (particularly since I asked about some of them for a bit). Would a bayes prefix for (G)SEM/IRT be something in the foreseeable future that you could comment on?

[Sergio Correia]

merge is a pretty efficient command, so if I have multiple datasets, I just put them together in the do file, rather than juggling multiple instances.

I am under the impression it is not very efficient, both in terms of memory and speed. (Try merging large datasets and things will slow down to a crawl; I've had merges that took hours..)

[Jesse Wursten]

I am under the impression it is not very efficient, both in terms of memory and speed. (Try merging large datasets and things will slow down to a crawl; I've had merges that took hours..)

I'm not sure if the memory thing is still true, I think they changed the merge command over the years (e.g. if you use keep(match master), the report will no longer list the cases from using, which I think it used to do).

[Orvalho Augusto]

Thank you for the version 15 release. And today there is an upgrade already!
I am pleased to note that the command proportion includes the exact confidence intervals now as the nice ci.
As always there is an unusual circumstances such as:
. ci proportion lbw_cor if site == 2 & exp_conf ==2

-- Binomial Exact --
Variable | Obs Proportion Std. Err. [95% Conf. Interval]
-------------+---------------------------------------------------------------
lbw_cor | 4 0 0 0 .6023646*

(*) one-sided, 97.5% confidence interval

. proportion lbw_cor if site == 2 & exp_conf ==2, citype(exact)

Proportion estimation Number of obs = 4

--------------------------------------------------------------
| Exact
| Proportion Std. Err. [95% Conf. Interval]
-------------+------------------------------------------------
lbw_cor |
0 | 1 0 . .
--------------------------------------------------------------

ci did report one-sided interval when the proportion is zero. It would be nice to have the same behavior on proportion as well.

Thank you

[Eric Haavind-Berman]

I wanted to bring up a small bug that I have found and see if other users see it too.

When running the code:

sysuse gnp96
line gnp96 date, xline(100, lpattern(l) lwidth(*70))
line gnp96 date, yline(7000, lpattern(l) lwidth(*70))

I get graphs with clear breaks in the solid pattern.

This does not happen if lpattern is specified with no arguments or if it is omitted.

Do other users see this same issue? I know it is a pretty small bug, but I wanted to point it out.

[Clyde Schechter]

Yes, I can replicate Eric Haavind-Berman's problem in my setup as well. (Stata 15 MP2, 64 bit, Windows 7).

Perhaps it might have been better to raise this issue in a separate thread.

[Chinh Nguyen (StataCorp)]

I wanted to bring up a small bug that I have found and see if other users see it too.

What you're seeing is an artifact of what's known as antialiasing. In Stata 15 for Windows, we improved graphics rendering by using Direct 2D for on screen rendering of graphs and GDI+ for copying graphs to the Clipboard. Direct 2D and GDI+ support antialiasing which is a type of rendering that makes diagonal lines and curves look smooth.

I won't bore you with too many details but basically, the new graphics renderer supports fractional coordinates and uses antialiasing to simulate drawing part of a pixel (using transparency). If you put two rectangles that butt up to each other at fractional coordinates, you'll get two transparent colors that may not blend to create a fully opaque color which is what makes the pattern look like it has breaks. The graphics renderer in previous versions of Stata for Windows only supported integer coordinates and always fully colored a pixel (which is why diagonal lines and curves looked jagged).

FWIW, Stata for the Mac and Stata for Unix(GUI) have had this problem in previous versions as well since they've long supported antialiasing. You can also see this behavior in vector drawing applications like Adobe Illustrator and viewers like Acrobat Reader.

We will put out an update that'll avoid this limitation of antialiasing when using -lpattern(l)-.

[Kirin_Guess]

According to the introduction webpage of Stata15, one new feature of the do-file editor is:

Column-mode selection and editing

What does it mean, and is there any demonstration of this feature in Stata blog or Stata website?