51–60 of 88 posts
Earlier quoted context omitted.
Which floating point operator is not commutative? Addition is.
(small number)+(small number)+ ... +(small number)+(much bigger number) may not give the same result as (much bigger number)+(small number)+(small number)+ ... +(small number)
Earlier quoted context omitted.
Which floating point operator is not commutative? Addition is.
Adding smaller magnitude first gives a different result than adding larger magnitudes first due to mixing precisions.
I believe this is incorrect. Feel free to show me a counterexample.
Earlier quoted context omitted.
(small number)+(small number)+ ... +(small number)+(much bigger number) may not give the same result as (much bigger number)+(small number)+(small number)+ ... +(small number)
You are confusing associativity with commutativity. The IEEE floating point standard guarantees commutativity for addition.
To sum (haha) up, I am no n00b. However, I've looked over the page a couple times and still can't figure out the use of this, let alone what "superpowers" it may grant. It's just comments? The best parts I can see are the mostly-prose ones farther down that just say what the loop's supposed to do, but even those are just repeating the "input" and "output" info, really, which are sort of also comments I think. Some of…
For most of us, this isn't a big deal. But let's say you're writing a subroutine that will control part of a pacemaker, rocket, fighter jet, satellite- anything where bugs are deadly or expensive- then this is a Very Big Deal.
Earlier quoted context omitted.
Why is 'totalUpToPrevious' better than 'sum' or 'total'? I could see it being good for explaining what a reduce does, but once you know how they work, 'sum' tells you exactly which argument is the accumulator.
Because it underlines that it's the sum of all elements seen so far. It does not just say "yo, this one here is the accumulator", it also implicitly defines the meaning of "accumulator" by saying "and the code that follows will guarantee that it is always the sum of the elements that have been seen so far". It's almost like a spec for the body of the combining function. I recognize that in a codebase where every 10 l…
I do normally call this sort of thing acc or accumulator though. I feel like an understanding of what that specific term means comes with the field expertise, sort of like we can say "LinkedList" and not "ObjectWithPointerToNextObject" and know exactly what that pattern should look like. A lot of CS skill comes down to expanding simple standard names.
That's not to say that your approach doesn't have value. It might just be that the toy example doesn't show it off very well. But if you were juggling that 3-way partition, for example, your naming scheme starts making a lot of sense for naming the boundary variables.
Invariants like this allow one to prove the correctness of their code. That may not seem like a big deal most of the time, but imagine you're working on a satellite that's going to Jupiter, where a bug in the code could mean 10 years from now a billion dollar project gets scuttled. Imagine you're building subroutines that will go into 10,000 pacemakers next year. Imagine you're writing the navigation logic for a cruise missile.
There are many times where proving your code correct is taken very, very seriously. Invariants are a tool to do so more easily.
Earlier quoted context omitted.
Adding smaller magnitude first gives a different result than adding larger magnitudes first due to mixing precisions.
If I read you right, you are saying that if you compute a+b, you'll get a different result than if you compute b+a, if a is tiny and b is huge. I believe this is incorrect. Feel free to show me a counterexample.
Earlier quoted context omitted.
Which floating point operator is not commutative? Addition is.
(small number)+(small number)+ ... +(small number)+(much bigger number) may not give the same result as (much bigger number)+(small number)+(small number)+ ... +(small number)
(((b + s) + s) + s) + s
b + (s + (s + (s + s)))
Earlier quoted context omitted.
Adding smaller magnitude first gives a different result than adding larger magnitudes first due to mixing precisions.
If I read you right, you are saying that if you compute a+b, you'll get a different result than if you compute b+a, if a is tiny and b is huge. I believe this is incorrect. Feel free to show me a counterexample.
>>> 0.1+0.2+0.3
0.6000000000000001
>>> 0.2+0.3+0.1
0.6
[1] https://www.quora.com/Is-floating-point-addition-commutative...
Earlier quoted context omitted.
Not sure what you mean by your comment. You can use loop invariants when solving problems that call for an iterative solution.
“Can you write code to reverse a linked list in place?” “Sure, I’ll just implemment a loop according to this invariant ... “ Would be nice to have the invariant ready then.