In contrast to ffmpeg, it does not seem to be possible to adjust brightness or other "quick" settings of videos anymore using avconv, at least a grep in the manpage for brightness did not give a single result. Gamma correction seems to be hidden in some kind of LUT-filter.
Can anyone point me to some option (in ffmpeg, those where mp,eq2,later eq) that allows me to do so?
(On a sidenote, can anyone explain why this fundamental and useful functionality has been stripped or obfuscated to the user?)
Indeed as indicated in https://www.libav.org/avconv.html#lut_002c-lutrgb_002c-lutyuv you can use the following filters to change the gamma (use it with -vf):
lutyuv=y=gammaval(0.5)
or:
lutyuv="y=2*val"
If you are willing to play with RGB or YUV values you can probably get something better using formulas as in the examples of that website. For example, to increase saturation based on the formulas in https://stackoverflow.com/a/8810735/6040014:
lutyuv="y=2*val:u=(val-128)*2+128:v=(val-128)*2+128"
And an experiment with y=(val-128)*2+128 seems to get a contrast increase (but maybe "contrast" is a technical term that should follow better formulas than this).
Is there a historical precedent of internal changes to the R parser, adding new reserved words or symbols?
If I remember correctly data.table uses a serendipitous := that was once defined but left unused in R internals, but I'm not aware of others. However, as the language evolves, it would sometimes seem useful to define new symbols.
An obvious case could be made for magrittr's pipe %>% which has become ubiquitous for many, but remains a pain to type (sure, there are keyboard tricks, but still). Similarly, dplyr/rlang introduce/repurpose notations for "tidy evaluation" (!!, !!!, :=, ~, etc.).
Another case I'm seeing is the verbosity of lambda functions. Would it be possible, theoretically, to define internally something like f = λ(x) x+1 instead of f = function(x) x+1, or are there character restrictions on top of other reasons?
Why add an ergonomics feature if you risk breaking a runtime that hosts a huge ecosystem? Also, once you add one feature, you are on a slippery slope and are staring straight in the face of feature bloat.
And if you say that we can be smart and judicious about what features we add, how do we structure that decision process? R does not have a "benevolent dictator" having a final word in decisions like this so you are left with design by committee with all that it entails.
The big thing with R has always been the package ecosystem, in which if you want a feature you write it yourself -- as in your magrittr example. The language itself has remained close to its S roots and has successfully served as a stable platform for all the development that has been happening.
I am writing the documentation for a function of an R package I am building.
In order to have a moderately nice aspect for the help file, I need the equivalent of \bar{x} in ASCII:
\eqn{\bar{x}}{ASCII equivalent}
Not sure there's a consensus on the best way to do this, it's more a matter of taste and clarity.
Having faced this issue myself, two solutions I have used are:
y = \eqn{\bar{x}}{xbar}
y = \eqn{\bar{x}}{mean(x)}
The advantage of the latter is that when the help is displayed as ASCII, the user can copy/paste (send) the text to an R process, getting an example value for y. This assumes that \bar{x} is shorthand for the mean, as is often the case.
When I input any integral, say sin[x] or ln[x], all I get back is the input. And from what I understand that usually means that mathematica can't evaluate the integral...What am i missing here?
I'm new to stackoverflow so I can't post screenshots.
Read the documentation:
Sin[x] manual
Log[x] manual
Note also that by default Log function is of base e, therefore it is your Ln.
In addition, if you have further questions mathematica/wolfram has it's own subsite where you should ask related questions https://mathematica.stackexchange.com/
As of version 9 you can query wolfram alpha directly and it can even try to interpret human language (and fix syntax mistakes like this). To query wolfram alpha start line with =.
I'm maintaining code for a mathematical algorithm that came from a book, with references in the comments. Is it better to have variable names that are descriptive of what the variables represent, or should the variables match what is in the book?
For a simple example, I may see this code, which reflects the variable in the book.
A_c = v*v/r
I could rewrite it as
centripetal_acceleration = velocity*velocity/radius
The advantage of the latter is that anyone looking at the code could understand it. However, the advantage of the former is that it is easier to compare the code with what is in the book. I may do this in order to double check the implementation of the algorithms, or I may want to add additional calculations.
Perhaps I am over-thinking this, and should simply use comments to describe what the variables are. I tend to favor self-documenting code however (use descriptive variable names instead of adding comments to describe what they are), but maybe this is a case where comments would be very helpful.
I know this question can be subjective, but I wondered if anyone had any guiding principles in order to make a decision, or had links to guidelines for coding math algorithms.
I would prefer to use the more descriptive variable names. You can't guarantee everyone that is going to look at the code has access to "the book". You may leave and take your copy, it may go out of print, etc. In my opinion it's better to be descriptive.
We use a lot of mathematical reference books in our work, and we reference them in comments, but we rarely use the same mathematically abbreviated variable names.
A common practise is to summarise all your variables, indexes and descriptions in a comment header before starting the code proper. eg.
// A_c = Centripetal Acceleration
// v = Velocity
// r = Radius
A_c = (v^2)/r
I write a lot of mathematical software. IF I can insert in the comments a very specific reference to a book or a paper or (best) web site that explains the algorithm and defines the variable names, then I will use the SHORT names like a = v * v / r because it makes the formulas easier to read and write and verify visually.
IF not, then I will write very verbose code with lots of comments and long descriptive variable names. Essentially, my code becomes a paper that describes the algorithm (anyone remember Knuth's "Literate Programming" efforts, years ago? Though the technology for it never took off, I emulate the spirit of that effort). I use a LOT of ascii art in my comments, with box-and-arrow diagrams and other descriptive graphics. I use Jave.de -- the Java Ascii Vmumble Editor.
I will sometimes write my math with short, angry little variable names, easier to read and write for ME because I know the math, then use REFACTOR to replace the names with longer, more descriptive ones at the end, but only for code that is much more informal.
I think it depends almost entirely upon the audience for whom you're writing -- and don't ever mistake the compiler for the audience either. If your code is likely to be maintained by more or less "general purpose" programmers who may not/probably won't know much about physics so they won't recognize what v and r mean, then it's probably better to expand them to be recognizable for non-physicists. If they're going to be physicists (or, for another example, game programmers) for whom the textbook abbreviations are clear and obvious, then use the abbreviations. If you don't know/can't guess which, it's probably safer to err on the side of the names being longer and more descriptive.
I vote for the "book" version. 'v' and 'r' etc are pretty well understood as acronymns for velocity and radius and is more compact.
How far would you take it?
Most (non-greek :-)) keyboards don't provide easy access to Δ, but it's valid as part of an identifier in some languages (e.g. C#):
int Δv;
int Δx;
Anyone coming afterwards and maintaining the code may curse you every day. Similarly for a lot of other symbols used in maths. So if you're not going to use those actual symbols (and I'd encourage you not to), I'd argue you ought to translate the rest, where it doesn't make for code that's too verbose.
In addition, what if you need to combine algorithms, and those algorithms have conflicting usage of variables?
A compromise could be to code and debug as contained in the book, and then perform a global search and replace for all of your variables towards the end of your development, so that it is easier to read. If you do this I would change the names of the variables slightly so that it is easier to change them later.
e.g A_c# = v#*v#/r#