HN user
Making sure the Direction flag is clear on entry and return is a somewhat hidden requirement of stdcall (Windows calling convention), but it didn't crash if you set it in WindowProc and forgot to clear it until Windows XP.
More recently, Vista had (accidentily?) 16-byte aligned stacks when using OpenMP with MingW, but the exact same binary crashes on Windows 10 when it tries to use unaligned SSE instructions.
5. WWJBQD?
This refers to Jean-Baptiste ‘JBQ’ Quéru, who responded: put users first.
https://plus.google.com/+JeanBaptisteQueru/posts/jjwjobbMUY8
I was expecting a "Django SQL" Explorer, for example a Django ORM -> SQL compiler playground, but got a Django "SQL Explorer".
No, but let me quote Jaynes (Probability Theory: the Logic of Science, 10.10):
‘When I toss a coin, the probability for heads is one-half.’ [...] the issue is between the following two interpretations:
(A) ‘The available information gives me no reason to expect heads rather than tails, or vice versa – I am completely unable to predict which it will be.’
(B) ‘If I toss the coin a very large number of times, in the long run heads will occur about half the time – in other words, the frequency of heads will approach 1/2.’
These are not the same except for special circumstances like controlled experiments. Frequentism usually assumes or restricts itself to those special circumstances. The long run here means `for any ε > 0, the probability that the observed frequency n/N lies in the interval (1/2±ε) goes to 1 as N goes to infinity'.
There is no such thing as an intrinsic probability, a coin only has a chance of landing heads when tossed. If we know everything about the coin and how it is tossed we could calculate the result. Some ways of tossing a fair coin are biased. Some coins are biased when tossed in fair ways. A fair coin toss exaggerates factors that are difficult to know and control exactly, like the force that we apply on the coin with our finger.
Jaynes thinks that `true randomness' such as is postulated by conventional quantum physics is unscientific (10.7). In any case it doesn't matter for calculating, and I don't think many Bayesians lose sleep over whether it's unknown, unknowable or `true randomness'.
If the Bayesian has an informative prior, they won't be mislead too much. If a Bayesian is 100% sure beforehand with a δ(x - 0.5) prior they won't be mislead at all, but of course no one is ever 100% sure (Cromwell's rule). On the other hand a frequentist might say p<0.05 and be mislead.
No, no, the cool thing to do now is to defend it. You claim that critics just don't understand its purpose, even if they mention it multiple times and are only criticising misuse. Then you use it ironically in your professional presentations to show that you are above the hoi polloi, both of today and of 15 years ago.
He actually discusses it a bit in the previous paragraph, which does not seem to be online anywhere:
When programming languages emerged, the "dynamic" nature of the assignment statement did not seem to fit too well into the "static" nature of traditional mathematics. For lack of an adequate theory mathematicians did not feel to easy about it, and, because it is the repetitive construct that creates the need for assignment to variables, mathematicians did not feel to easy about repetition either. When programming languages without assignments and without repetition --such as pure LISP-- were developed many felt greatly relieved. They were back on familiar grounds and saw a glimmer of hope of making programming an activity with a firm and respectable mathematical basis. (Up to this very day there is among the more theoretically inclined computing scientists still a widespread feeling that recursive programs "come more naturally" than repetitive ones.)
Continued https://tinyletter.com/programmingphilosophy/letters/i-don-t...
Just use n = max(a, b). Of course that doesn't help you much unless you're adhering to strict safety standards (e.g. power of ten rules), it just shifts the burden of proof from termination to correctness. And there's no such trick with the Ackermann function.
I'm really just advocating a rule of least power. Don't go into full general recursion just because you can.
Yes, that is the point I tried to make. Use simple, constrained forms such as (C) "for(int i = 0; i < n; i++) { ... }" with n an int and no modification of i in the body, or (Python) "for e in l:" where l is a list that is not modified in the body. Then your code is very easy to analyze, not just in theory but also in practice for compilers, tools and people reading your code. Many language designers have realized this and provide special syntax for this very common case. I'm not aware of any language that has special syntax for primitive recursion, but it's an interesting idea.
My apologies for making an absolute statement with unclear terms, thus inviting uncharitable interpretations.
Iterative loops are much easier to analyze and reason about, by humans and by computers. For example, they always terminate. To paraphrase Dijkstra, "I regard general recursion as an order of magnitude more complicated than just repetition, and I don't like to crack an egg with a sledgehammer."
https://tinyletter.com/programmingphilosophy/letters/i-don-t...
A similar project is ProtobufDumper from SteamRE[1]. It's tailored to Valve games and Steam.
[1] https://github.com/SteamRE/SteamKit/tree/master/Resources/Pr...
They helped a local 30-year-old coffeehouse by buying them and their neighbor at above market rate. Backed by illegal secret tax deals, as it turned out.
To summarize and paraphrase the paper:
Every upvote should increase the score, every downvote should decrease the score and the more votes there are the less an additional vote should matter. Only "adding pretend votes" satisfies this.
That really puts into words why "adding pretend votes" just felt right to me in practice.
There was a good talk about deployments at DjangoCon US 2015.
Django Deployments Done Right by Peter Baumgartner: https://www.youtube.com/watch?v=SUczHTa7WmQ&list=PLE7tQUdRKc...
I agree that the staircasing effect is definitely the biggest drawback of Total Variation. In the "Smoothed" picture the noise is removed but the results are blocky.
The first way to deal with it is to take into account higher powers of the differences, e.g. using a linear combination p-norms or a Huber function.
The second way is to take into account second order differences. This promotes piecewise affine instead of piecewise constant functions. You can go further and look at third order differences, but the improvement is minimal.
Other than being more complex, the biggest downside is that all of these methods have some new parameter(s) to tune.
Let me share my experience with chroma upsampling and smooth jpeg decoding.
At first, I optimized each channel, then upsampled the chroma channels using replication. This works terribly as you can see in the article.
So then I changed to linear interpolation. Briefly:
+---+---+
a x b y c
+---+---+
This worked decently, but it still showed fringes around sharper edges. I considered using more complicated upsampling methods like Lanczos or Mitchell, but instead went with optimizing a full size image with constraints on the downsampled image. By avoiding upsampling I got my optimized high resolution image for each channel.
But there were still fringes! As it turns out, just because each channel was optimized seperately doesn't mean that the image as a whole is optimized. So I switched to optimizing the three YCbCr channels together, not looking at the differences abs(x_{i+1} - x_i) but looking at the differences sqrt((Y_{i+1} - Y_i)^2 + (Cb_{i+1} - Cb_i)^2 + (Cr_{i+1} - Cr_i)^2). This actually eliminated the fringes.
The final result is https://github.com/victorvde/jpeg2png
If you start with the most general form you won't always get an optimal solution, because two jumps may be blocking each other from optimizing. TASM does it that way. Consider (16-bit NASM):
a:
times 124 nop
jmp b
jmp a
times 125 nop
b:The term to search for papers is "span-dependent instruction", which goes back to 1978.
Another thing that can produce out-of-gamut colors in JPEG is chroma subsampling. http://www.glennchan.info/articles/technical/chroma/chroma1.... has a good overview.
Clipping is required by JFIF, so you can't implement spilling in the decoder by default, even if you assume the source was 0-255 RGB. So implementing this in the encoder like the article does is best. but I have mixed feelings about it since it's most helpful for images that shouldn't be saved as JPEG at all.
If you want gory details, try G'MIC[1]. It has plugins for GIMP and Krita, an online version[2], a ridiculous number of filters[3] and features, and a command language. On the other hand, it makes things like imagemagick look simple and user friendly. My favorite quote from the "Beginner's Cookbook":
The image of a finger or a brush pushing along paint immediately brings to mind tensor fields, produced by -diffusiontensors, which directs asymmetrical smoothing kernels in the -smooth command to diffuse noise parallel to detected edges
[1] http://gmic.eu/ [2] https://gmicol.greyc.fr/ [3] http://gmic.eu/gimp_filters.txt
Programmers respond by attempting to stamp out the gets() function in working code, but they refuse to remove it from the C programming language's standard input/output library, where it remains to this day.
gets was deprecated in C99 and removed in C11.
House for the Feeble Minded.
I was working in YCbCr and I found it noticable. Compare the bottom-right tile in https://github.com/victorvde/jpeg2png/commit/64bf10789092ccf... with swipe. It's worst with green around the top of the left black line, but there's green and red fringing everywhere. And this is a normal use case.
In my experience[1] code is available maybe half of the time, if you really search for it: checking the academic and personal pages of every author, and scouring the code of every framework mentioned. You're lucky when the code is in C or C++ using a framework nobody uses (e.g. MegaWave), but half of the time the code is in MATLAB. All uncommented, using single character variables and under some restrictive or just weird license.
And then it only works on grayscale images. Maybe because it's easier to get funding for medical images. Just applying the algorithm to each color channel separately leads to color fringing when they get out of sync.
Finally, usability, distribution, and performance are afterthoughts. I don't disagree but it makes a huge difference.
https://rust.godbolt.org/ has that and more disassembly options
It's probably insecure, because you don't want to do 75,850,000 sequential evaluations over a network. It would take over a week for a single track with even just 10ms response time.
The domain is the unit cube [0, 1]^d using double precision floating point, see the documentation.
Making assumptions and testing them is very much part of the contest. You are even allowed to do this interactively.
Why you shouldn't use the Lesser GPL for your next library https://www.gnu.org/licenses/why-not-lgpl.html