What do following snippets of code do in Math ML files? I removed those lines and it still worked fine for me.
<mo></mo>
<mo></mo>
<mo></mo>
Answering to any of them or just letting me know what they are would be very much appreciated.
The first two are function application and invisible times. They help indicate semantic information, see this Wikipedia entry
The last one, , could be anything since it lies in the Unicode Private Use Area which is provided so that font developers can store glyphs that do not correspond to regular Unicode positions. (Unless it's a typo and really 6349 in which case it's a a Han character.)
Related
How would I make a 2D raycast? Also, how would I check if 2 line segments intersect (relativity the same thing in my eyes, probably different though). I am not using unity or anything, I am just using plain python (I can translate from most languages to python so I don't really care what language you use) and don't want to use a library so I can learn. But every article I look at has no actual explanation, it just shows code. I've looked at the Geeks4Geeks one and that also really only shows code and does not explain what it does. So if someone could explain it that would be helpful.
I've seen regex patterns that use explicitly numbered repetition instead of ?, * and +, i.e.:
Explicit Shorthand
(something){0,1} (something)?
(something){1} (something)
(something){0,} (something)*
(something){1,} (something)+
The questions are:
Are these two forms identical? What if you add possessive/reluctant modifiers?
If they are identical, which one is more idiomatic? More readable? Simply "better"?
To my knowledge they are identical. I think there maybe a few engines out there that don't support the numbered syntax but I'm not sure which. I vaguely recall a question on SO a few days ago where explicit notation wouldn't work in Notepad++.
The only time I would use explicitly numbered repetition is when the repetition is greater than 1:
Exactly two: {2}
Two or more: {2,}
Two to four: {2,4}
I tend to prefer these especially when the repeated pattern is more than a few characters. If you have to match 3 numbers, some people like to write: \d\d\d but I would rather write \d{3} since it emphasizes the number of repetitions involved. Furthermore, down the road if that number ever needs to change, I only need to change {3} to {n} and not re-parse the regex in my head or worry about messing it up; it requires less mental effort.
If that criteria isn't met, I prefer the shorthand. Using the "explicit" notation quickly clutters up the pattern and makes it hard to read. I've worked on a project where some developers didn't know regex too well (it's not exactly everyone's favorite topic) and I saw a lot of {1} and {0,1} occurrences. A few people would ask me to code review their pattern and that's when I would suggest changing those occurrences to shorthand notation and save space and, IMO, improve readability.
I can see how, if you have a regex that does a lot of bounded repetition, you might want to use the {n,m} form consistently for readability's sake. For example:
/^
abc{2,5}
xyz{0,1}
foo{3,12}
bar{1,}
$/x
But I can't recall ever seeing such a case in real life. When I see {0,1}, {0,} or {1,} being used in a question, it's virtually always being done out of ignorance. And in the process of answering such a question, we should also suggest that they use the ?, * or + instead.
And of course, {1} is pure clutter. Some people seem to have a vague notion that it means "one and only one"--after all, it must mean something, right? Why would such a pathologically terse language support a construct that takes up a whole three characters and does nothing at all? Its only legitimate use that I know of is to isolate a backreference that's followed by a literal digit (e.g. \1{1}0), but there are other ways to do that.
They're all identical unless you're using an exceptional regex engine. However, not all regex engines support numbered repetition, ? or +.
If all of them are available, I'd use characters rather than numbers, simply because it's more intuitive for me.
They're equivalent (and you'll find out if they're available by testing your context.)
The problem I'd anticipate is when you may not be the only person ever needing to work with your code.
Regexes are difficult enough for most people. Anytime someone uses an unusual syntax, the question
arises: "Why didn't they do it the standard way? What were they thinking that I'm missing?"
I didn't know before about artistic or artwork QR codes, while checking some of these codes, they are completely different from the regular standard QR code, but how is it possible to create this kind of QR code without loosing it's value (the scan result is the same) ?
These QR Codes are the most ones that amazed me:
http://www.hongkiat.com/blog/qr-code-artworks/
The only thing in common is the 3 corners, and they're different in style.
So my question is, what are the elements that we should preserve while creating such QR Codes ?
The most important things are:
Dark-on-light
Very nearly square modules
Modest light border
Substantially preserve the three-finder patterns
... and the first line of modules around them, which carries format info
... and the bottom-right alignment pattern, is helpful
The rest, the interior, can be substantially obscured and still be readable, certainly with high error correction. But messing with the elements above will tend to make it unreadable much more rapidly
Hello this is my question:
I am currently working on an introductory course on R programming for people with zero background on programming (this is people studying biology, veterinary, medicine, economics, ...), so they tend to be not very tech savvy and to use Windows. After they download and open the R scripts that I prepared, they are going to find every now and then badly encoded characters (as the course is in spanish and has many accents). This happens because my scripts are made with UTF-8 encoding and is not supported by default in Windows.
The options to avoid this nuisance are:
change all my scripts to the encoding WINDOWS-1252
instruct everyone to change their encoding to UTF-8
The first option is more annoying for me and helps prevents the students to be distracted with a quite minor detail.
The second option has no clear advantages from the pedagogic point of view, so I'd like to ask which virtues do you think it has...
Thanks in advance!
I would highly recommend instructing them to change their encoding to UTF-8. I've had the same issue on numerous occassions with web-app scripting and generally speaking it's alot more hassle to go through the code than to instruct the customer (or in your case, student) to use the UTF-8 encoding.
Afterall the course you're holding is an introductionary course, you might want to consider briefly covering the topic and explain the differences between the two - and more specifically: What happens when it doesn't work?
You have a golden opportunity to save yourself some time later down road, and possibly avoid the "Why is there question marks all over my screen"-question altogether!
Maybe you can avoid non-ASCII characters in your scripts. For example, to represent the greek "mu" character, you could use
> mu <- "\u03BC"
> Encoding(mu) <- "UTF-8"
> mu
[1] "μ"
Now if you print mu on the console, it is displayed correctly. In the script, you did not use any non-ASCII character at all.
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#