[Leonardo Guizzetti]

This discovery used to come up on the old list server about every four years, for example, here, here and here. I think that the best explanation of the design compromises is given in the first linked thread, but the second also contains discussion of the motivation behind Mata's behavior.

Thank you for posting this history, Joseph. That clears it up entirely for me. I bump into it about once a year but now I won't.

[Joseph Coveney]

. . . your code and the following finding suggest that this may be a bug with the interpreter.

This discovery used to come up on the old list server about every four years, for example, here, here and here. I think that the best explanation of the design compromises is given in the first linked thread, but the second also contains discussion of the motivation behind Mata's behavior.

[Leonardo Guizzetti]

This is a really interesting finding I was not aware of. To complete, the following works:

mata:
if (cond) {
// do something
}
(any other code)
end

To me it looks almost mata skips something at the end of the code.

thanks for reproducing this, and suggesting a work around. I was under the impression that I needed to follow it up with an intentionally empty else block, but your code and the following finding suggest that this may be a bug with the interpreter.

mata {
  if (cond) {
    // do something
  }
}

This block works just fine, no errors, but not with the mata: ... end construct.

[JanDitzen]

In Mata, if one uses the if () structure below, Mata exits with the vague error "unexpected end of line" and quits, because it expected to see an -else- (or else if) block. The existence of else-blocks should be optional, as they are for the one-line cases in Mata, and as they are fully optional in Stata's -ifcmd-.

mata:
if (cond) {
// do something
}
end

result

unexpected end of line
(# lines skipped)

This is a really interesting finding I was not aware of. To complete, the following works:

mata:
if (cond) {
// do something
}
(any other code)
end

To me it looks almost mata skips something at the end of the code.

[Leonardo Guizzetti]

In Mata, if one uses the if () structure below, Mata exits with the vague error "unexpected end of line" and quits, because it expected to see an -else- (or else if) block. The existence of else-blocks should be optional, as they are for the one-line cases in Mata, and as they are fully optional in Stata's -ifcmd-.

mata:
  if (cond) {
    // do something
  }
end

result

unexpected end of line
(# lines skipped)

[Leonardo Guizzetti]

This may have been suggested already, but a custom display format for percentages, perhaps with optional percent sign.

For example, the following might yield

. display strofreal(0.1254, "$5.1p")
 12.5

. display strofreal(0.1254, "$5.1ps")
12.5%

[Joseph Coveney]

Partially, though as far as I am aware you cannot evaluate Mata functions on the fly within a Stata command, which is possible with Stata functions.

You can evaluate Mata functions within a user-written command, and you can call Mata void functions (subroutines) on the fly from Stata's command line, but what I think you're referring to is having a Mata function perform vectorized operations on the dataset, as in something like

mata:
real scalar myfunction(real scalar input) {
    // Stuff here
}
end

generate double b = myfunction(a)

You're right, but there are other ways of achieving this programmatic need from within Mata, itself, and you can pass arguments (including variable names) directly to a Mata void function from the Stata command line.

[Ali Atia]

Partially, though as far as I am aware you cannot evaluate Mata functions on the fly within a Stata command, which is possible with Stata functions.

[Leonardo Guizzetti]

Being able to define our own functions would be very useful (whether it is feasible for StataCorp to implement is another question, which I cannot answer).

We are currently able to define functions for egen, but these are limited for a number of reasons, including the facts that they cannot be nested and that they can only be used while generating variables, as opposed to, for instance, defining macros.

Mata allows you to pretty flexibly implement your own functions, and can push/pull data and macros (etc) from Stata. Would this satisfy your request?

[William Lisowski]

Response to #262 -

The assertion from #258 disputed in #262

Stata treats missing as large, R does the same with "NA"

was taken out of context. It was in reference to sorting a Stata dataset - the equivalent of sorting an R data frame.

> df <- data.frame("Serial_number" = 1:5, "Age" = c(20, 21, NA, 18, 19), "Name" = c("Johnny","Dorian","Linda", "Cathy", "Rick"))
> df
  Serial_number Age   Name
1             1  20 Johnny
2             2  21 Dorian
3             3  NA  Linda
4             4  18  Cathy
5             5  19   Rick
> 
> # Sort by age ascending order
> newdf <- df[order(df$Age),]
> newdf
  Serial_number Age   Name
4             4  18  Cathy
5             5  19   Rick
1             1  20 Johnny
2             2  21 Dorian
3             3  NA  Linda
>

[Ali Atia]

Being able to define our own functions would be very useful (whether it is feasible for StataCorp to implement is another question, which I cannot answer).

We are currently able to define functions for egen, but these are limited for a number of reasons, including the facts that they cannot be nested and that they can only be used while generating variables, as opposed to, for instance, defining macros.

[Christopher Bratt]

Response to #258:

Stata treats missing as large, R does the same with "NA"

I don’t think that is correct. For R, missing is NA, i.e. not available - and neither lagre nor small.

if a > 2 // Stata

and

if (a > 2) # R

provide different results if variable a includes missing values.
In base R, many operations even result in an error if you do not explicitely ask R to disregard missing values:

na.rm = TRUE

——————————————

I have asked myself why I have moved to R. Apart from the open source aspect, I think there are two main reasons:

- R Markdown
- How R handles objects such as data frames, including output from analyses: very easy to manipulate/combine/subset (or convert to a different object class). So, surprisingly, I find writing code to develop a table showing results much easier and more intuitive in R than in Stata 17.

What would make me buy yet another upgrade of Stata? I guess it would be integration with R and R Markdown (from within RStudio).

I believe Stata has an excellent language (unless one needs to merge results from several “macros”) and Stata is overall strong as a statistical tool. I’m not sure it’s commercially the best solution, but for research it would be great if Stata and R could be integrated.

(Those who would like to use both R and Stata without real integration might try the R package RStata or something similar. It helped me once.)

[Fahad Mirza]

ability to read images and information stored in pixels

[Krishanu Karmakar]

An option for log to close when a do-file exits with error.

@216

Is that really needed? Just by putting the following line at the very top of any do file this can be done, is not it?

 capture log close

[Jeff Wooldridge]

The new telasso command is nice. I'd like to see it support flogit and fprobit, too, for fractional response variables -- just like teffects does.