Is There a Reason to Prefer Extractor Functions to Accessing Attributes with $

Is there a reason to prefer extractor functions to accessing attributes with $?

Because then the author of the package you are using is free to change the underlying structure of the model object without worrying about breaking everyone's code.

Obviously this generalizes to R Core as well. It is recommended to use those extractor functions because then you can be sure that it will always return the correct information, even if the function authors find it necessary to shuffle things around under the hood.

Maybe they add some more information to one of the elements of the model list object, and that changes the order of everything? All your code will break.

Writing functions in R, keeping scoping in mind

If I know that I'm going to need a function parametrized by some values and called repeatedly, I avoid globals by using a closure:

make.fn2 <- function(a, b) {
    fn2 <- function(x) {
        return( x + a + b )
    }
    return( fn2 )
}

a <- 2; b <- 3
fn2.1 <- make.fn2(a, b)
fn2.1(3)    # 8
fn2.1(4)    # 9

a <- 4
fn2.2 <- make.fn2(a, b)
fn2.2(3)    # 10
fn2.1(3)    # 8

This neatly avoids referencing global variables, instead using the enclosing environment of the function for a and b. Modification of globals a and b doesn't lead to unintended side effects when fn2 instances are called.

Defining a constant as a coefficient from an r regression

elasticity <- reg$coefficients[names(reg$coefficients)=="ln_price"]

Is there an advantage in using a word2vec model as a feature extractor for text clustering?

Yes, word2vec-based-features sometimes offer an advantage.

But whether & how it can help will depend on your exact data/goals, and the baseline results you've achieved before trying word2vec-enhanced approaches. And those aren't described or shown in your question.

The scikit-learn example you report as your model doesn't integrate any word2vec features. What happens if you add such features? (As one very clumsy but simple example, what if you either replace, or concatenate into, the HashingVectorizer features a vector that's the average of all a text's word-vectors.)

Do the results improve, by either some quantitative score or a rough eyeballed review?

What is so wrong with extract()?

I find that it is only bad practice in that it can lead to a number of variables which future maintainers (or yourself in a few weeks) have no idea where they're coming from. Consider this scenario:

extract($someArray); // could be $_POST or anything

/* snip a dozen or more lines */

echo $someVariable;

Where did $someVariable come from? How can anyone tell?

I don't see the problem in accessing the variables from within the array they started in, so you'd really need to present a good case for using extract() for me to think it's worth it. If you're really concerned about typing out some extra characters then just do this:

$a = $someLongNameOfTheVariableArrayIDidntWantToType;

$a['myVariable'];

I think the comments here on the security aspects of it are overblown somewhat. The function can take a second parameter that actually gives you fairly good control over the newly created variables, including not overwriting any existing variables (EXTR_SKIP), ONLY overwriting existing variables (so you can create a whitelist) (EXTR_IF_EXISTS), or adding prefixes to the variables (EXTR_PREFIX_ALL).

Extracting an attribute value with beautifulsoup

.find_all() returns list of all found elements, so:

input_tag = soup.find_all(attrs={"name" : "stainfo"})

input_tag is a list (probably containing only one element). Depending on what you want exactly you either should do:

output = input_tag[0]['value']

or use .find() method which returns only one (first) found element:

input_tag = soup.find(attrs={"name": "stainfo"})
output = input_tag['value']

Pipe `%%` the results of a regression `lm`and return one of the attributes

It is recommended here that you avoid using the $ operator to extract coefficients. To be more explicit in what you're looking for, and more robust to library changes, try this instead:

coef(summary(fit))["x","Pr(>|t|)"]

But that makes your piping tough. You could try this, if it works for your purposes:

getp <- function(coefs) { return (coefs["x","Pr(>|t|)"]) }
lm(y ~ x) %>% summary %>% coef %>% getp

That works for me, and you could even add arguments for which column you'd like to extract in your one-line function.

Extract the text in a Element then append it to an attribute with using jQuery

Try this:

$(document).ready(function() {
    $("div.child").each(function() {
        var text = "";
        $(this).next("span").contents().each(function(i) {
            if(this.nodeName == "#text") text += $(this).text();
        });
        $(this).parent().attr("ref", text);
    });
});

Note: I used the accepted answer in the linked question for obtaining the desired text from the first div.

What is the use of Comparator.comparing in respect to Comparator

is Comparator.comparing() used for converting a single argument lambda expression to a double argument?

Yes, you can sort of think of it like that.

When sorting things, you are supposed to specify "given two things a and b, which of them is greater, or are they equal?" using a Comparator<T>. The a and b is why it has 2 lambda parameters, and you return an integer indicating your answer to that question.

However, a much more convenient way to do this is to specify "given a thing x, what part of x do you want to sort by?". And that is what you can do with the keyExtractor argument of Comparator.comparing.

Compare:

/*
given two people, a and b, the comparison result between a and b is the 
comparison result between a's name and b's name
*/
Comparator<Person> personNameComparator = 
    (a, b) -> a.getName().compareTo(b.getName());

/*
given a person x, compare their name
*/
Comparator<Person> personNameComparator = 
    Comparator.comparing(x -> x.getName()); // or Person::getName

The latter is clearly much more concise and intuitive. We tend to think about what things to sort by, rather than how exactly to compare two things, and the exact number to return depending on the comparison result.

As for the declaration for comparing:

public static <T, U extends Comparable<? super U>> Comparator<T> comparing(
            Function<? super T, ? extends U> keyExtractor)

The <T, U extends Comparable<? super U>> part first declares two generic type parameters - T is what the comparator compares (Person in the above case), and U is the type that you are actually comparing (String in the above case), hence it extends Comparable.

keyExtractor is the parameter you pass in, such as x -> x.getName(), that should answer the question of "when given a T, what is a U that you want to compare by?".

If you are confused by the ? super and ? extends, read What is PECS?.

If you haven't realised already, the implementation of comparing basically boils down to:

return (a, b) -> keyExtractor.apply(a).compareTo(keyExtractor.apply(b));

---

Related Topics