Knowing where the transmitters are is vital. So wonder if you build in a positioning system to them. Each transmitter transmits a signal, but also rebroadcasts the signals it receives from the other transmitters on separate bands (these can be at lower power). If you can pick up a few transmitters, is that enough to build a model of where they are relative to each other, and then where they are relative to you?
If each transmitter picks up the rebroadcasts if its own signals, then with some assumptions about the rebroadcast lag (or measurements of it added to the signal!), that's enough to know the range to each other transmitter, right? So maybe they do that and then just broadcast the ranges (tagged on to their main signal), then any remote receiver can work it all out from there.
> that's enough to know the range to each other transmitter, right?
Only in a flat environment without too much atmospheric distortions. As soon as you get multipath effects from eg waves bouncing off buildings and mountains then the computational complexity goes through the roof. Also I don't think you should underestimate how much the signal degrades in a "target path" vs the "direct path". The article mentions -60 dB and I think that is fairly optimistic. The transmitter power needs to be HUGE to make it work, so it would be much easier to have stationary transmitters. Normal radars manage to do this because they are highly directional, but multistatic radars need to look in all directions at once and need to up the power as a result.
You're completely right. I've got an idea for an investment strategy. We start a company, and issue shares. We use the money to buy Teslas, and hold them as assets. As the value goes up, the value of the company will rise. Then we issue more shares, at a higher valuation, and use the money to buy more Teslas. Infinite money glitch. I call it a Drivable Asset Treasury company.
My version of this workflow is, i take digital photos, and don't edit them.
Turns out, it's fine! The photos aren't perfect, but no amount of editing could make them perfect anyway. They look like the thing they're a picture of. That does the job. And with the time i save by not doing any editing, i have time to take more photos! Or read a book! Or sleep!
Having gone from multi-repo to monorepo recently, I'd say the opposite. A multi-repo lets you do those things incrementally. A monorepo forces you to do them in one go.
I think we need to see a few non-contrived examples, because i think in every case where you might take advantage of currying like this, you actually want to make it explicit, as you say.
The flip side of your example is that people see a function signature like getClosest, and think it's fine to call it many times with a set and a point, and now you're building a fresh quadtree on each call. Making the staging explicit steers them away from this.
Consider a function like ‘match regex str’. While non-lazy languages may offer an alternate API for pre-compiling the regex to speed up matching, partial evaluation makes that unnecessary.
I couldn't agree more. Having spent a lot of time with a language with currying like this recently, it seems very obviously a misfeature.
1. Looking at a function call, you can't tell if it's returning data, or a function from some unknown number of arguments to data, without carefully examining both its declaration and its call site
2. Writing a function call, you can accidentally get a function rather than data if you leave off an argument; coupled with pervasive type inference, this can lead to some really tiresome compiler errors
3. Functions which return functions look just like functions which take more arguments and return data (card-carrying functional programmers might argue these are really the same thing, but semantically, they aren't at all - in what sense is make_string_comparator_for_locale "really" a function which takes a locale and a string and returns a function from string to ordering?)
3a. Because of point 3, our codebase has a trivial wrapper to put round functions when your function actually returns a function (so make_string_comparator_for_locale has type like Locale -> Function<string -> string -> order>), so now if you actually want to return a function, there's boilerplate at the return and call sites that wouldn't be there in a less 'concise' language!
I think programming languages have a tendency to pick up cute features that give you a little dopamine kick when you use them, but that aren't actually good for the health of a substantial codebase. I think academic and hobby languages, and so functional languages, are particularly prone to this. I think implicit currying is one of these features.
> in what sense is make_string_comparator_for_locale "really" a function which takes a locale and a string and returns a function from string to ordering?
In the sense that "make_string_comparator" is not a useful concept. Being able to make a "string comparator" is inherently a function of being able to compare strings, and carving out a bespoke concept for some variation of this universal idea adds complexity that is neither necessary nor particularly useful. At the extreme, that's how you end up with Enterprise-style OO codebases full of useless nouns like "FooAdapter" and "BarFactory".
The alternative is to have a consistent, systematic way to turn verbs into nouns. In English we have gerunds. I don't have to say "the sport where you ski" and "the activity where you write", I can just say "skiing" and "writing". In functional programming we have lambdas. On top of that, curried functions are just a sort of convenient contraction to make the common case smoother. And hey, maybe the contraction isn't worth the learning curve or usability edge-cases, but the function it's serving is still important!
> Because of point 3, our codebase has a trivial wrapper to put round functions when your function actually returns a function
That seems either completely self-inflicted, or a limitation of whatever language you're using. I've worked on a number of codebases in Haskell, OCaml and a couple of Lisps, and I have never seen or wanted anything remotely like this.
> I think programming languages have a tendency to pick up cute features that give you a little dopamine kick when you use them, but that aren't actually good for the health of a substantial codebase.
That's not the case with Haskell.
Haskell has a tendency to pick up features that have deep theoretical reasoning and "mathematical beauty". Of course, that doesn't always correlate with codebase health very well either, and there's a segment of the community that is very vocal about dropping features because of that.
Anyway, the case here is that a superficial kind of mathematical beauty seems to conflict with a deeper case of it.
I always felt Monads were an utterly disgusting hack that was otherwise quite practical though. It didn't feel like mathematical beauty at all to me but like a hack to fool to the optimizer to not sequence out of events.
OCaml has a neat little feature where it elides the parameter and variable name if they're the same:
let warn_user ~message = ... (* the ~ makes this a named parameter *)
let error = "fatal error!!" in
warn_user ~message:error; (* different names, have to specify both *)
let message = "fatal error!!" in
warn_user ~message; (* same names, elided *)
The elision doesn't always kick in, because sometimes you want the variable to have a different name, but in practice it kicks in a lot, and makes a real difference. In a way, cases when it doesn't kick in are also telling you something, because you're crossing some sort of context boundary where some value is called different things on either side.
Yeah, especially in F#, a language that means to interpolate with .Net libraries (most not written with "data input at last" mindset.) now I'm quite surprised that F# doesn't have this feature.
If each transmitter picks up the rebroadcasts if its own signals, then with some assumptions about the rebroadcast lag (or measurements of it added to the signal!), that's enough to know the range to each other transmitter, right? So maybe they do that and then just broadcast the ranges (tagged on to their main signal), then any remote receiver can work it all out from there.
reply