The original low code app is the spreadsheet; a very useful abstraction that people have bolted together all kinds of critical workflows with. Low code is meant to be for a similar audience of nontechnical DIYers in the process automation space.
For python specifically, I've found my base anaconda environment to be plenty powerful enough! Sure, it's slow to install packages and create new environments, but anything I'm hacking away on for an hour will probably not be using some crazy specific pip library that I don't already have (at least not the way I prefer to write such projects it won't)
This is definitely not my area of expertise, but my understanding was that the mantissa was actually the source of inexactness in floats? I know the power bits (10 bits?) are pretty close to actual twos complement ints, and you could always do things in a C-like union, but I wasn't aware you could directly treat the mantissa like an int
I know the industry has moved on to WebAssembly, but I thought it might be worth mentioning that I just recently finished a personal project to compile an arbitrary NodeJS script in QuickJS and call the code from C - all* in a statically or dynamically linked library, no support files.
By "naive" random walk, I'm referring to how one would _implement_ a random walk that's restricted to a given range. The most straightforward way to do it is to "clip" any values that would exit the given range by simply coercing them to the bound, eg:
if next_value > upper_bound:
next_value = upper_bound
if next_value < lower_bound:
next_value = lower_bound
This works fine, but serves to concentrate probability mass near the boundaries, so it's no longer uniformly distributed. By reflecting across boundaries rather than coercing, you're effectively flattening that concentration. If you coerce, you also reduce the expected value, which may or may not be a desirable property.
Martingales with barrier reflections are a fantastic way to model all kinds of parameters that are randomly distributed over time, but stay roughly the same value in the short haul. They're also very well studied, so you can make strong guarantees about their expected values and distributions, unlike naive random walks that stay within a given range.
Splines are also a great tool to know about when you're trying to approximate smooth curves from sparse data! I reached for splines and martingales a ton when we were developing a patient simulator.
As you said, at the end of the day it's an ethical guideline that must be upheld, more than something based in economics. We do compensate participants as well as we're allowed within these guidelines!
I agree with your points, but compensation must be approved by the independent institutional review board, who is accountable to national ethical review boards and thus acts very conservatively.
Perhaps I was being too self deprecating! We worked closely with the FDA through multiple QSub meetings to make sure it was up to snuff, and did a lot of legwork on the backend to make sure we understood what they were asking for. 3 or 4 revisions later, we had an approval!
When we started putting the trial together, we were still self funded. In medical device, to get to series A you need human data, so by doing the trial protocol ourselves, we avoid the chicken and egg problem of needing money in order to raise money. Once you get human data, your valuation skyrockets.
Patient compensation is intentionally limited to prevent economic incentives from interfering with informed consent; pay people too much and they may participate in research that they would have passed on. Also, speaking from experience, patient compensation is a very small amount (5% or less) of overall cost. The vast majority goes to clinical staff costs, room costs, hospital overhead, labs etc.
There's a reason why we ended up putting our trials together essentially by trial and error! You learn a lot by writing your own clinical protocol, interacting with the FDA etc. It's an intimidating process at the outset, but if you can save $200k on a first-in-man study by not contracting a CRO, that's gonna extend your runway by a lot!
We were just discussing how to do this today! How would you say your offering compares to, eg, Redox Engine, in terms of pricing and overall compatibility? Will you be open sourcing the entire stack, or keeping some parts proprietary?
Back in the day, the work you might dream of computing might be as simple as a matrix multiplication, which while difficult to implement, is certainly not impossible for a beginner; we did exactly that for our first machine language MP in Computer Engineering 190 my freshman year of college. The use cases were just far simpler back then for computers!
Phased array antennas are mostly for getting programmable beam forming, and don’t have much to do with jamming, which works by destructively interfering with incoming waves. Starlink operating on a different frequency means that GPS jammers won’t be able to jam them out of the box, but presumably if they’re jammers built in the last 20-30 years they’d have onboard SDRs which can dynamically hop frequencies. It’s a neat trick to get GPS from Starlink, but won’t stop nation state attackers from jamming access to GPS.
It’s under the new “digital well-being” menu in settings. Quickest way to get there is to tap and hold YouTube’s app icon, then click the little (I) or gear, which will take you to YouTube’s individual settings. One of them should be the app timer.
You actually can have Vanced be the default! Set an app timer for 0hr 0 min on YouTube, and go into the app link behavior in settings to default to Vanced. After that, links should open in Vanced. In apps that have browsers, view the link in the internal browser if it brings you to YouTube.com, and it should redirect.
I do small projects statically all the time! Writing a simple bf interpreter can be done so statically that you don't even need to store the program in its own array; program text can just be taken directly as const char*
You can also do ergonomically nice things using static allocation in many data structures, like linked lists (as a tiny example: https://github.com/ijustlovemath/linked-list/blob/master/ll....). That way you can focus on the concepts that matter; the data structures, and not frustrate newbies with opaque and difficult-to-reason allocation issues (at least not at first!)
One reading which might be valid is that testing on hardware that lives in the happy path will lead you to think your code has less issues than it actually has on real user systems.
Anyone can do higher level math, the problem is that math education is generally done by people who see math as a tool for computation, rather than a study of deep connections bordering on philosophy, and beautiful insights resembling poetry. I've been in arguments before where someone didn't believe me that the underpinnings of modern philosophy are essentially the same as math!
If the teachers don't love math, how can we expect students to?
There's certainly no doubt in my mind that they save your "top" match, based on your swipe history and whether or not they've already matched you, to show up right after you use your last free swipe. Wait 12h and hope they show up again? Maybe, or maybe I'll spend the $2 to get that super like. Very scummy.
The problem really happens when you do algorithmic price setting, which incentivizes you as the developer to get people addicted to the experience of swiping, regardless of whether or not the swiping has the desired outcome for the end user. A user base with just the right levels of dopamine from interactions and loneliness will probably end up buying one of the weekly promotional deals.
That's why when you first start on any dating service, you're (typically) inundated with activity, so that you can always chase that high, and when you can't get it, you try to pay for it.
Online dating is a tough problem to solve, tougher still when profit incentives misalign with user success incentives! I'm not even sure what an equitable but also successful dating service would look like, because there's this fundamental mismatch in values.
Tossing out insulin = 0 (which is too vague... hepatic? Supplemented? Total daily dose? Average dose in units per hour?) will bias your dataset to having more diabetics.