phab

It's interesting that they state that the train was moving, but not how fast. My understanding was that one of the challenges with doing good mobile broadband on trains (esp. for VoIP applications) is how seamlessly you manage the handover between cells makes a big difference to real-world usability. If the train was going pretty slowly that would obviously make your time-per-cell a lot higher / % of time spent performing handoff a lot lower...

These are awesome. This makes me want to try hiding information as a very-low-frequency signal superimposed across a whole stream of images...

I suppose really I'm showing my DSP-training by saying that a Fourier is from a time domain, really it's just a special mapping between two domains, and it just so happens that it correlates with the physical analogues of time domain -> time frequency, space domain -> spatial frequency. In this case it's really space domain -> spatial frequency, but w/e

A Fourier transform maps a signal from a time domain into an equivalent [0] signal in the frequency domain.

This demo:

1. Performs a Fourier transform on some image pixels, taking the pixel data from the "time" domain into the frequency domain. (Think of time as "how far through the image we are", and the pixel's intensity as the signal's magnitude; frequency in this case becomes a slightly abstract concept.)

2. Visualises that frequency domain in various ways - by default you're seeing the magnitude of the transformed signal

3. applies a band-pass filter to that frequency domain - i.e. only allowing signals above a certain frequency (low-cut) and below another certain frequency (high-cut), and removing the rest. Playing with this might give you an intuitive notion of what "frequency" means here.

4. applies the inverse transform, giving you a signal back in the time domain (i.e. a normally viewable image).

You can see what the effect of bandpassing the frequency-domain signal is on the end result. Thinking about it in terms of Information, if we band-pass half of the given frequency spectrum out, we're essentially throwing away half of the Information... but yet the image is still useful to a human (this is the principle of how lossy compression algorithms work, as others have noted).

[0] In the case of a "perfect" transform, in reality most algorithms are lossy

The DFF-Mono pattern is interesting because of how if you reduce the high-cut you can see the bands disappearing step-wise in decreasing density... I assume this occurs as the Nyquist frequency is passed for those pixels?

I wonder if you could store information in the frequency-space and then inverse-transform it for some neat steganography...

Now THERE's a rabbit-hole if ever I saw one. Here's an 8-part (!) article [0] on why a physical button is in reality... nowhere near that simple.

[0]: https://www.eejournal.com/article/ultimate-guide-to-switch-d...

TeX and MetaFont [0].

Although to be fair, I also use LuaTeX quite a lot now...

[0] http://www.texfaq.org/FAQ-TeXfuture

I see the title has been modified post hoc to include a year.. but it's wrong. It should actually be 1997...

But I could just ignore/comprimise/modify your client and submit whatever I liked to the server.

I have cancelled my (paid) Zoom subscription. I will not finance companies that feel that protection from oppression is only for those that can pay.

The second page ("Coding in Metal"), illustrating how computations occur using mechanical intrinsics like differentials, is where this gets fascinating.

https://arstechnica.com/information-technology/2020/05/gears...

I completely disagree. Engineering at its core is about building useful solutions to real-world problems. If you're not considering the user (including the theory behind the user's interaction with your product), you're not embracing your role as an engineer holistically. If I was hiring engineers, that is exactly what I would be asking them to do.

> Marketing can be a real struggle for engineers ... They are also REALLY bad at the aesthetics of design.

This is a pretty sweeping generalisation.

Agreed - the majority of drivers will now be making the discrete decision "Is green or amber" not "Is amber or red".

That is to say, that the proportion of drivers having to make the risky decision (i.e. if they were to decide to accelerate through the amber) is significantly reduced... although interestingly I think the principle states that as T(amber) << T(green) the liklihood of indecision for that second case now does increase.

I think the principle would state that by always picking option 1 you are no longer making a decision based on the input.

This is discussed in the paper under section 3: "Other Asses", in the paragraph starting "One way to circumvent Buridan’s Principle is to eliminate the decision".

The paper points out that this doesn't resolve the problem in the discussion about the crossing gate; all this approach does is move the decision from "do I jump" to "have I met the point of no return yet", which is still a discrete decision over a continuous input.

Even if I'm not concerned with a malicious actor, I ought to be concerned about silly future me that accidentally introduces an infinite loop into the config, which then makes it to production and is able to wreak havoc, because silly past me had to disable the validator for this config because of "that pesky validator bug that only shows up on Tuesdays"...

Right, but if you've introduced the ability to ignore the validator then you've traded away the guarantee that your config program will be safe to execute.

My point is that the validator can't give you the safety property that is claimed as a defence against one of the inherent issues with this approach.

But if it's allowed to reject a valid terminating program it's allowed to reject arbitrary, otherwise valid, configuration programs. In other words, you can no longer trust the output of the validator - the weakened model significantly reduces the utility of the validator.

> termination checking > Anyone knows examples of conservative static analysis tools that check for termination in general purpose languages?

As this is provably impossible, this "solution" introduces exactly one of the problems the author was trying to avoid:

> can't be validated

Actual arXiv link: https://arxiv.org/abs/1811.10154

Douglas Hofstadter's book, "Gödel, Escher, Bach" is very highly recommended reading for anyone who finds this (and the theory of computability more generally) interesting.

I've lost entire days of my life to that book!

https://en.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach

Maybe I'm naive, but the key takeaway from this for me was:

> the owner of the ISBN controls where the book can be printed.

I didn't realise this - that's the crucial "why" behind the "when".

> I don't buy that a tool that's being sold for money would do that

If you work with proprietory hardware (think FPGAs), if you want to use the hardware, you have to use proprietory vendor tools, whether you want to or not.

> if the tools are internal then by definition you have the ability to make changes to them.

This misses the point. Having the technical ability to modify the tool does not equal having the real-world-practicability, business-case-defendable ability to change the tool.

> Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling

The point is that in a 20 year, n-million line codebase, neither is "easy", and the pragmatic solution is to do neither.

Because legacy.

Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. We can't change version numbering schemes because our packages already exist 'in the wild' and can't be changed mid-sequence without causing both technical and user pain.

Fundamentally: the codebase has worked perfectly well this way for the last 20 years; what's the business case for changing it (at potentially significant cost) just to be compatible with XYZ new tool that everyone is rallying behind?

Not Invented Here (https://en.wikipedia.org/wiki/Not_invented_here)

I'm curious as to why you find this unreadable... it renders pretty readably for me? (https://pasteboard.co/HlW8oMh.png).

As far as I can tell, formatdoc[0] doesn't provide a "semantically correct" method for formatting quotes. Hence, the age-old usenet quote (as codified in RFC3676[1]) seems to me to be the best way of indicating a quotation, and rendering it via a verbatim block ensures that the line-based quotation indication isn't disrupted by the text all being in a <p> tag when rendered in HTML.

[0] https://news.ycombinator.com/formatdoc [1] http://www.ietf.org/rfc/rfc3676.txt

This is a fascinating article. Footnote 8 is an especially fascinating insight;

  > One puzzling feature of the shift register is that there is no wiring between the stages!
  > How do bits get from one stage to the next? Did the chip have another layer of wiring that wasn't in
  > the photos? Was there some sort of hidden connection? Eventually I noticed that there wasn't an isolation
  > ring between the stages—a silicon barrier that separated most I2L circuits. Without this isolation ring,
  > an "invisible" PNP transistor exists between the stages, apparently allowing one stage to flip the next
  > stage to the right value. Each shift-register stage is constructed from two NAND-gate latches. When the
  > clock is low, the first latch is forced into an indeterminate state. When the clock goes high, the latch
  > ends up as 0 or 1 based on the bias it receives from the previous stage through the "invisible" PNP
  > transistors. Thus, the latch becomes edge-sensitive since it will change right on the clock's rising edge.
  > I found a paper ("Injection-Coupled Synchronous Logic", 1978) that describes a similar technique for an I2L
  > shift register9, so I think this is the right explanation, even though the circuit seems a bit sketchy.

Thanks! And thanks for taking the time to organise these competitions when you can, they're truly edifying.