Using R, what are the equivalents of methods in other languages [closed] - r

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
In languages such as Java and Eiffel, there is a divide between functions (returning a value) and methods, groups of transformative statements. So a method would be something like:
public main blah NAMEOFMETHOD(x) {
STATEMENT/COMMAND
STATEMENT/COMMAND
STATEMENT/COMMAND
}
R has functions as basic to the language, but there is no obvious way of making a method (I think). Do I just put groups of commands in a class? (I programmed years ago with Eiffel and Java, but am now using R for statistics and am extending my work with some programming - or is it coding you call it now?!)
Old guy relearning. Please be gentle.

R is a functional programming language. It's important to understand that there is technically no real difference between a function (with possible side-effects such as generating a plot) and a method.
The only difference is the absence of a "return value".
A Java method with signature
void doSomething()
(wich misses a return) can be implemented in R as
doSomething <- function(){
# Do something here
return(invisible(NULL))
}
where NULL is the return value ("nothing") and invisible instructs R not to automatically print this result to the console.
return(invisible(NULL)) is equivalent to the shorter statement return(invisible()) and, if it's the last line of code in your function, as it should be, also equivalent to invisible() because R auto-returns the result of the last computation in the function body.

Related

Coding style: Is this a good way to write a function [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Is the following code example, calling a function in the parameters line of another function, acceptable? Or will I run in problems somehow?
newfunction <- function(df = merge_two_df(), size = define_size()){
... do something
}
This is basically a question of what you gain and lose compared to the alternatives.
So first let's look at the alternatives:
Option1
newfunction <- function(){
df = merge_two_df(), size = define_size()
... do something
}
Option2
newfunction <- function(df,size){
... do something
}
newfunction(merge_two_df(),define_size())
Comparing your status-quo to option 1 shows that your current way is more flexible. You have defined default values for each parameter but retain the option to use other parameters. So there is nothing to gain hard-coding the parameter definition into the body of the function.
Now comparing to option 2, your current way is actually more standardized because you have defined defaults. You can simply and cleanly call your function without any parameters while having the same flexibility of switching up parameters if you want. However on the flip side you are a bit less explicit in calling these parameters which might be bad in terms of documentation and clarity when rereading the code.
If this function is part of a module that might be used/exported across several projects some even done by someone other then yourself, then I'd argue for option 2 to be simpler and clearer.
Otherwise what you do right now works best.

When to kill a running script R [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am having a larger data set with more than 1 million entries. If I am running scripts it sometimes takes up a while till I get an output. Sometimes it seems that there is no output what so ever, even if I let it run for hours. Is there a way to track the progress of the computation (or maybe just see if it is not stuck)?
1. Start small
Write your analysis script and then test it using trivially small amounts of data. Gradually scale up and see how the runtime increases. The microbenchmark package is great at this. In the example below, I compare the amount of time it takes to run the same function with three different sized chunks of data.
library(microbenchmark)
long_running_function <- function(x) {
for(i in 1:nrow(x)) {
Sys.sleep(0.01)
}
}
microbenchmark(long_running_function(mtcars[1:5,]),
long_running_function(mtcars[1:10,]),
long_running_function(mtcars[1:15,]))
2. Look for functions that provide progress bars
I'm not sure what kind of analysis you're performing, but some packages already have this functionality. For example, ranger gives you more updates than the equivalent RandomForest functions.
3. Write your own progress updates
I regularly add print() or cat() statements to large code blocks to tell me when R has finished running a particular part of my analysis. Functions like txtProgressBar() let you add your own progress bars to functions as well.

Why is 'DO LOOP' missing in 328eForth? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I’m trying to learning Forth directly in an embedded system and using Starting Forth by Leo Brodie as a text. The Forth version I’m using is 328eForth (a port of eforth to the ATmega328) which I’ve flashed into an Arduino Uno.
It appears that the DO LOOP words are not implemented in 328eForth - which puts a kink in my learning with Brodie. But looking at the dictionary using “WORDS” shows that a series of looping words exist e.g. BEGIN UNTIL WHILE FOR NEXT AFT EXIT AGAIN REPEAT amongst others.
My questions are as follows:
Q1 Why was DO LOOP omitted from 328eForth?
Q2 Can DO LOOP be implemented in other existing words? If so, how please and if not why? (I guess there must be a very good reason for the omission of DO LOOP...)
Q3 Can you give some commented examples of the 328eForth looping words?
Q1: A choice was made for a different loop construct.
Q2: The words FOR and NEXT perform a similar function that just counts down to 0 and runs exactly the specified number of times, including zero.
The ( n2 n1 -- ) DO ... LOOP always runs at least once, which requires additional (mental) bookkeeping. People have been complaining
about that as long back as I can remember.
Q3: The 382eforth documentation ForthArduino_1.pdf contains some examples.
Edit: Added some exposé to Q2

Why is code writen in functional programming language shorter than code writen in other programming paradigm languages? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Many people say that code writen in functional programming language is shorter than code writen in other programming paradigm languages.But why?
One big reason is the greater use of higher-order functions. A simple example is map. The following are equivalent:
# Procedural psuedocode
result = []
for value in other_list:
add somefunc(value) to result
# Functional pseudocode
let result = map(somefunc, other_list)
The higher-order function map abstracts away the code that iterates over the first list and sequentially adds the function return value to the new list. Other higher-order functions can be used to implement other techniques that are commonly spelled out (whether by necessity or not) in more detail in other paradigms.
Another less commonly seen higher-order function is composition. In many languages, you write code like
def new_function(x):
return func2(func1(x))
value = new_function(5)
or
lambda x: func2(func1(x))
In a functional style, you would write (or have) a compose function to handle the details, instead of having to write each composed function individually.
def compose(f, g):
def _(x):
return f(g(x))
value = compose(func2, func1)(x)
Some languages, like Haskell, even provide a composition operator:
value = (func2 . func1)(x)

Use 'not' instead of '!' in R [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I would like R to be more pythonic. One of the steps for transforming it would be the use of 'not' instead of '!'. I hope this does not need writing of C++ and compiling etc, or does it?
Functionality: "!TRUE" should equal "not TRUE".
If you know where to start, please point me there.
You better embrace the R way. Why all the effort for such a small thing? If you want Python, stick with Python. Besides, it is REALLY common to have ! act as "not" in other programming languages.
Anyway, this is something that allows the use of "not", but it will involve parentheses (the Arrr! way)
not <- function(x) { !x }
if (not(FALSE)) { print(1) }
[1] 1
In my opinion this is far worse than !.
And I can hear you thinking "but I would like to have if x is not in y:", but please, that would be the same as suggesting I'd want a way for Python not to need indenting.
The idea is that you learn a language, you do not change a language to suit an individual's needs. What will happen with others using your code?

Resources