As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Why doesn't C have a ||= operator, or any other language for that matter? Is there some technical reason, or is it for language aesthetics?
Edit Apparently Perl and Ruby have this, I didn't know that when asking.
In C this operator would be utterly nonsense. Think about the following example:
char ind = 0;
ind |= 1;
ind |= 0;
// ind is still 1
This is doing exactly what ||= would achieve. For all types that are non-castable to bool this would be stupid anyways. Am I missing something?
In all other programming languages without type inference this operator would only be valid for booleans.
I would venture to guess it wasn't included in c ( unlike |= ) because it wouldn't make a lot of since in 99% of circumstances. || is a Boolean operator. While zero and not zero pass for Booleans in the language, what should the assignment to an integer or pointer of true actually be. 1, -1, 42? It introduces an awful lot ambiguity for not much benefit.
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 days ago.
Improve this question
I have to prove that not all ternary linear codes contain the all zero codeword.
Some term explanations:
A linear code is a code that the sum or difference of any two codewords must also be a codeword. In other words, for all x, y in C, x +/- y is also in C.
A ternary codeword in this exercise is a codeword containing 0, 1 or 2. Eg, 1011, 1012, 012, ...
An all zero codeword is something like 0000, 000, 00000, ...
My attempt:
The addition of codewords must be done MOD 3 which means there are three allowable numbers in this MOD 3 world including 0, 1 and 2. For any ternary linear codes, there are cases when all the additions of any two codewords yeild non-zero codewords.
I am not sure about the proof. I have an idea that it must deal with the MOD 3 but not sure how to explain.
Thank you so much!
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
Improve this question
Can anyone help me with the Mathematics of sparse categorical cross entropy loss function? I have searched for the derivation, explanation (Mathematical) but couldn't find any
I know it is not the right place to ask question like this. But I am helpless.
It is just cross entropy loss. The "sparse" refers to the representation it is expecting for efficiency reasons. E.g. in keras it is expected that label provided is an integer i*, an index for which target[i*] = 1.
CE(target, pred) = -1/n SUM_k [ SUM_i target_ki log pred_ki ]
and since we have sparse target, we have
sparse-CE(int_target, pred) = -1/n SUM_k [ log pred_k{int_target_k} ]
So instead of summing over label dimension we just index, since we know all remaining ones are 0s either way.
And overall as long as targets are exactly one class we have:
CE(target, pred) = CE(onehot(int_target), pred) = sparse-CE(int_target, pred)
The only reason for this distinction is efficiency. For regular classification with ~10-100 classes it does not really matter, but imagine word-level language models where we have thousands of classes.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Why not simply evaluate Left to Right? Can someone explain how precedence makes code more readable? To me it seems to require more thought and more possibility for error. Einstein said, "Everything should be made as simple as possible, but no simpler." I guess he wasn't a programmer.
because in Mathematics, before the invention of any computer language, there was operator precedence, e.g.
2 + 5 * 3 = 17 (and not 21)
A language not having a higher precedence for the * operator than for the + operator would generate confusion.
Another example from C++:
std::cout << 7 * 8 << std::endl;
If the * operator did not have precedence over the << operator, this would not compile:
std::cout << 7 would be evaluated first, yielding std::cout as a result (with the side effect that 7 would be printed)
then one would want to evaluate std::cout * 8 which -- unless somebody defines a really weird operator * for multiplying an outputstream by an integer -- is not defined.
Operator precedence allows not having to put unnecessary parentheses 'within common sense' (although I agree that in some cases people introduce bugs because they are not aware of the actual precedences)
Now you might ask: why does Mathematics have operator precedence ? This wikipedia article mentions some historical facts and links to a discussion forum. For me, an imporant argument is the one that when writing polynomials, e.g.
ax^2 + bx + c
without operator precedence, one would have to write them as:
(a(x^2)) + (bx) + c
The purpose of precedence is not to make it more readable, its to (a) standardize and (b) keep with standards set in mathematics, such as PEMDAS.
APL does not have operator precedence (except parentheses); code reads right to left (like Hebrew or Arabic). That said, APL is a niche language and this is one reason why. Most other languages, as other answers already point out, mimic the long-established precedence rules of arithmetic, which in turn appear to me to arise from how typical use cases (i.e., real-world problems) can be modeled with a minimum number of parentheses.
The digital world simply follows the old-school "real" world where the BEDMAS rules: Brackets, Exponents, Division, Multiplication, Addition, Subtraction.
Better to follow the real world, than try to refedefine reality and end up with programmers doing
1 + 2 * 3
as
(1 + 2) * 3 = 9
v.s. a realworlder doing
1 + (2 * 3) = 7
and sending your multimillion dollar probe into an invalid atmospheric descent profile because someone "carried the 1" wrong.
It is possible to do away with precedence rules - or more correctly, have just one such rule - as APL demonstrates.
"It has just one simple, consistent, and recursive precedence rule: the right argument of a function is the result of the entire expression to the right of that function."
For example, in "J" (an APL variant):
1+2*3 => 7 Computed as 1+(2*3)
2*3+1 => 8 Computed as 2*(3+1)
APL (and J) has so many operators, it would be difficult to remember the precedence and associativity rules of each and every one of them.
The reason why there is an operator precedence is because you should see a sum like 2*4 as a WHOLE number.
So you could think of it in a way that 2*4 doesn't exist. It's simply 8.
So what you're basically doing is "simplifying" the sum, like: 2+10*2 This basically says: 2+20.
As in the following sum: 2143+8^2+6^9. You don't want to write out 2143+262144+10077696. (And imagine how this could look like if you have a much larger formula)
It's basically to simplify the look of the sum. And both addition and subtraction are the most basic form of operations. So that's why there is a precedence, it is to increase the readbility of the sum.
And like i said, since the + and - operators are the most basic operators there are, then it makes sense to first solve the more "complicated" operators.
For example, with operator precedence the following evaluates to 14:
2 + 3 * 4
without it would evaluate to 20 which is unexpected, imho.
Take an example , if there were no operator precedence how would you evaluate this expression :
1+2/3
Well , some would say that you want to divide the sum of 1+2 by 3 . Others that you want to add 2/3 to 1 !
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Across I have seen many questions of why the unary plus exists in the specific language like:Why does F# have a unary plus operator?
What is the purpose of Java's unary plus operator?
What's the point of unary plus operator in Ruby?
Use of unary plus operator
And they all say that the '+' is only for overloading if you need it,
or it is for performing some rare/unnecessary language-specific task.
But why isn't there any actual use of it?
It would make sense (atleast to me) that a unary '+' should act as an absolute value like:
int x = -5; //x is -5
x = +x; //x is now 5
Is there any specific reason why this hasn't been done?
or is it because this only makes sense to me?
It's not implemented that way because math doesn't work that way.
In math:
note: the following is math on a blackboard, not a programming language
+ -5 = -5
- -5 = 5
Doing it any other way will confuse anyone who's ever finished highschool.
Obviously, the above is fairly weak answer since you can indeed implement the action taken by the ASCII character '+' in the code to work differently from math. In Lisp for example, the + operator does not work like regular highschool math:
;;; Adding two numbers:
+ 1 2
And on TI calculators, it's even reversed:
1 2 +
You could argue that implementing + the way you describe in your programming language makes sense. There are a number of different arguments on why it should not be done including the principle of least surprise, a language should model the problem domain, it's what we've been taught at school etc. All of them are essentially weak arguments because they don't provide a fundamental reason for a machine to treat + the same way as math.
But here's the thing, humans are emotional creatures. We like what's familiar and cringe at something that goes against something we've been taught. And programmers don't like being surprised by + behaving differently from normal. And programmers are the ones who create programming languages so it makes sense that they implement + the way they do.
One programmer may not think like that, or a small group, and they are free to create a programming language that implements + differently. But they'll have a hard time convincing the programming community at large they what they did was right.
So it doesn't matter so much that all the arguments that can be made against + acting as abs() are essentially weak. As long as the majority feels it's right + will behave the same as regular math.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the clearest explanation of what computer scientists mean by "the naive implementation"? I need a good clear example which will illustrate — ideally, even to non-technical people — that the naive implementation may technically be a functioning solution to the problem, but practically be utterly unusable.
I'd try to keep it away from computers altogether. Ask your audience how they find an entry in a dictionary. (A normal dictionary of word definitions.)
The naive implementation is to start at the very beginning, and look at the first word. Oh, that's not the word we're looking for - look at the next one, etc. It's worth pointing out to the audience that they probably didn't even think of that way of doing things - we're smart enough to discount it immediately! It is, however, about the simplest way you could think of. (It might be interesting to ask them whether they can think of anything simpler, and check that they do really understand why it's simpler than the way we actually do it.)
The next implementation (and a pretty good one) is to start in the middle of the dictionary. Does the word we're looking for come before or after that? If it's before, turn to the page half way between the start and where we are now - otherwise, turn to the page half way between where we are now and the end, etc - binary chop.
The actual human implementation is to use our knowledge of letters to get very rapidly to "nearly the right place" - if we see "elephant" then we'll know it'll be "somewhere near the start" maybe about 1/5th of the way through. Once we've got to E (which we can do with very, very simple comparisons) we find EL etc.
StackOverflow's Jeff Atwood had a great example of a naive algorithm related to shuffling an array.
Doing it the most straightforward, least tricky way available. One example is selection sort.
In this case naive does not mean bad or unusable. It just means not particularly good.
Taking Jon Skeet's advice to heart you can describe selection sort as:
Find the highest value in the list and put it first
Find the next highest value and add it to the list
Repeat step 2 until you run out of list
It is easy to do and easy to understand, but not necessarily the best.
another naive implementation would be the use of recursion in computing for an integer's factorial in an imperative language. a more efficient solution in that case is to just use a loop.
What's the most obvious, naive algorithm for exponentiation that you could think of?
base ** exp is base * base * ... * base, exp times:
double pow(double base, int exp) {
double result = 1;
for (int i = 0; i < exp; i++)
result *= base;
return result;
}
It doesn't handle negative exponents, though. Remembering that base ** exp == 1 / base ** (-exp) == (1 / base) ** (-exp):
double pow(double base, int exp) {
double result = 1;
if (exp < 0) {
base = 1 / base;
exp = -exp;
}
for (int i = 0; i < exp; i++)
result *= base;
return result;
}
It's actually possible to compute base ** exp with less than exp multiplications, though!
double pow(double base, int exp) {
double result = 1;
if (exp < 0) {
base = 1 / base;
exp = -exp;
}
while (exp) {
if (exp % 2) {
result *= base;
exp--;
}
else {
base *= base;
exp /= 2;
}
}
return result * base;
}
This takes advantage of the fact that base ** exp == (base * base) ** (exp / 2) if exp is even, and will only require about log2(exp) multiplications.
I took the time to read your question a little closer, and I have the perfect example.
a good clear example which will illustrate -- ideally, even to non-technical people -- that the naive implementation may technically be a functioning solution to the problem, but practically be utterly unusable.
Try Bogosort!
If bogosort were used to sort a deck of cards, it would consist of checking if the deck were in order, and if it were not, one would throw the deck into the air, pick up the cards up at random, and repeat the process until the deck is sorted.
"Naive implementation" is almost always synonymous with "brute-force implementation". Naive implementations are often intuitive and the first to come to mind, but are also often O(n^2) or worse, thus taking too long too be practical for large inputs.
Programming competitions are full of problems where the naive implementation will fail to run in an acceptable amount of time, and the heart of the problem is coming up with an improved algorithm that is generally much less obvious but runs much more quickly.
Naive implementation is:
intuitive;
first to come in mind;
often inffective and/or buggy incorner cases;
Let's say that someone figures out how to extract a single field from a database and then proceeds to write a web page in PHP or any language that makes a separate query on the database for each field on the page. It works, but will be incredibly slow, inefficient, and difficult to maintain.
Naive doesn't mean bad or unusable - it means having certain qualities which pose a problem in a specific context and for a specific purpose.
The classic example of course is sorting. In the context of sorting a list of ten numbers, any old algorithm (except pogo sort) would work pretty well. However, when we get to the scale of thousands of numbers or more, typically we say that selection sort is the naive algorithm because it has the quality of O(n^2) time which would be too slow for our purposes, and that the non-naive algorithm is quicksort because it has the quality of O(n lg n) time which is fast enough for our purposes.
In fact, the case could be made that in the context of sorting a list of ten numbers, quicksort is the naive algorithm, since it will take longer than selection sort.
Determining if a number is prime or not (primality test) is an excellent example.
The naive method just check if n mod x where x = 2..square root(n) is zero for at least one x. This method can get really slow for very large prime numbers and it is not feasible to use in cryptography.
On the other hand there are a couple of probability or fast deterministic tests. These are too complicated to explain here but you might want to check the relevant Wikipedia article on the subject for more information: http://en.wikipedia.org/wiki/Primality_test
Bubble sort over 100,000 thousand entries.
The intuitive algorithms you normally use to sort a deck of cards (insertion sort or selection sort, both O(n^2)) can be considered naive, because they are easy to learn and implement, but would not scale well to a deck of, say, 100000 cards :D . In a general setting, there are faster (O(n log n)) ways to sort a list.
Note, however, that naive does not necessarily mean bad. There are situations where insertion sort is a good choice (say, when you have an already sorted big deck and few unsorted cards to add).
(Haven't seen a truly naive implementation posted yet so...)
The following implementation is "naive", because it does not cover the edge cases, and will break in other cases. It is very simple to understand, and can convey a programming message.
def naive_inverse(x):
return 1/x
It will:
Break on x=0
Do a bad job when passed an integer
You could make it more "mature" by adding these features.
A O(n!) algorithm.
foreach(object o in set1)
{
foreach(object p in set1)
{
// codez
}
}
This will perform fine with small sets and then exponentially worse with larger ones.
Another might be a naive Singleton that doesn't account for threading.
public static SomeObject Instance
{
get
{
if(obj == null)
{
obj = new SomeObject();
}
return obj;
}
}
If two threads access that at the same time it's possible for them to get two different versions. Leading to seriously weird bugs.