Humans can’t survive being hit by a car at 25 mph.
The primary purpose of most speed limits is tax revenue, which is why most speed limits are not based on safety evidence. The local authorities just tweak the limits to maximize profits.
The article you linked doesn’t say what you claim it says. It discusses a 25moh car hitting a pedestrian, which is wildly different from a true 25mph impact in general, because most pedestrians will try to dodge.
Learning to deal with “unmaintanable” codebases is a pretty good skill. It taught me good documentation and refactoring manners. It’s only a problem for you if management does not accept that their velocity has gone down as a result of tech debt pilling up.
Code should scream it’s intent (business-wise) so as to be self-documenting as much as possible As much as possible is not 100%, so add comments when needed. Comments should be assumed to be relevant when written, at best. Git comment should be linked to your work ticket so that we can figure out why the hell you would do that, when looking at the code file itself. I swear some people seem to think we only read them in PRs (we don’t). Overall concepts used everyday, if they need to be reexplained, should probably be written down (at least today’s version). Tests are documentation. Often the only up to date one?
You lost me on the section when you started going into different calculators, but I read the rest of the post. Well written even if I ultimately disagree!
The reason imo there is ambiguity with these math problems is bad/outdated teaching. The way I was taught pemdas, you always do the left-most operations first, while otherwise still following the ordering.
Doing this for 6÷2(1+2), there is no ambiguity that the answer is 9. You do your parentheses first as always, 6÷2(3), and then since division and multiplication are equal in ordering weight, you do the division first because it’s the left most operation, leaving us 3(3), which is of course 9.
If someone wrote this equation with the intention that the answer is 1, they wrote the equation wrong, simple as that.
There has apparently been historical disagreement over whether 6÷2(3) is equivalent to 6÷2x3
As a logician instead of a mathemetician, the answer is “they’re both wrong because they have proven themselves ambiguous”. Of course, my answer would be RPN to be a jerk or just have more parens to be a programmer
The calculator section is actually pretty important, because it shows how there is no consensus. Sharp is especially interesting with respect to your comment because all scientific Sharp calculators say it’s 1. For all the other brands for hardware calculators there are roughly 50:50 with saying 1 and 9.
So I’m not sure if you are suggesting that thousands of experts and hundreds of engineers at Casio, Texas Instruments, HP and Sharp got it wrong and you got it right?
There really is no agreed upon standard even amongst experts.
Hi, expert here, calculators have nothing to do with it. There’s an agreed upon “Order of Operations” that we teach to kids, and there’s a mutual agreement that it’s only approximately correct. Calculators have to pick an explicit parsing algorithm, humans don’t have to and so they don’t. I don’t look to a dictionary to tell me what I mean when I speak to another human.
Thanks for putting my thoughts into words, that’s exactly why I hate math. It was supposed to be the logical one, but since it only needs to be parsed by humans it failed at even that. It’s just conventions upon conventions to the point where it’s notably different from one teacher/professor to the next.
I guess you can tell why I went into comp-sci (and also why I’m struggling there too)
No, those companies aren’t wrong, but they’re not entirely right either. The answer to “6 ÷ 2(1+2)” is 1 on those calculators because that is a badly written equation and you(not literally you, to be clear) should feel bad for writing it, and the calculators can’t handle it with their rigid hardcoded logic. The ones that do give the correct answer of 9 on that equation will get other equations wrong that it shouldn’t be, again because the logic is hardcoded.
That doesn’t change the fact that that equation worked out on paper is absolutely 9 based on modern rules of math. Calculate the parentheses first, you then have 6 ÷ 2(3). We could solve from here, but to make the point extra clear I’m going to actually expand this out to explicit multiplication. “2(3)” is the same as “2 x 3”, so we can rewrite the equation as “6 ÷ 2 x 3”. All operators now inarguably have equal precedence, which means the only factor left in which order to do the operations is left to right, and thus division first. The answer can only be 9.
If you’d ever taken any advanced math, you’d see that the answer is 1 all day. The implicit multiplication is done before the division because anyone taking advanced math would see 2(1+2) as a term that must be resolved first. The answer still lies in the ambiguity of the way the problem is written though. If the author used fractions instead of that stupid division symbol, there would be no ambiguity. It’s either 6/2 x 3 = 9 or [6/(2x3)] = 1. Comment formatting aside, if someone put 6 in the numerator, and then did or did NOT put all the rest in the denominator underneath a horizontal bar, it would be obvious.
TL;DR It’s still a formatting issue, but 9 is definitely not the clear and only answer.
At the simplest, it takes in a vector of floating-point numbers, multiplies them with other similar vectors (the “weights”), sums each one, applies a RELU* the the result, and then uses those values as a vector for another layer with it’s own weights (or gives output). The magic is in the weights.
This operation is a simple matrix-by-vector product followed by pairwise RELU, if you know what that means.
Where modelWeights is [[[Float]]], and so layer has type [Float] -> [[Float]] -> [Float].
RELU: if i>0 then i else 0. It could also be another nonlinear function, but RELU is obviously fast and works about as well as anything else. There’s interesting theoretical work on certain really weird functions, though.
Less simple, it might have a set pattern of zero weights which can be ignored, allowing fast implementation with a bunch of smaller vectors, or have pairwise multiplication steps, like in the Transformer. Aaand that’s about it, all the rest is stuff that was figured out by trail and error like encoding, and the math behind how to train the weights. Now you know.
Assuming you use hex values for 32-bit weights, you could write a line with 4 no problem:
That’s cool, though honestly I haven’t fully understood, but that’s probably because I don’t know Haskell, that line looked like complete gibberish to me lol. At least I think I got the gist of things on a high level, I’m always curious to understand but never dare to dive deep (holds self from making deep learning joke). Much appriciated btw!
Yeah, maybe somebody can translate for you. I considered using something else, but it was already long and I didn’t feel like writing out multiple loops.
No worries. It’s neat how much such a comparatively simple concept can do, with enough data to work from. Circa-2010 I thought it would never work, lol.
programming.dev
Top