This is a dumb position though because all logic would suggest the two ratios are proportional. Civilians are not significantly more likely to die of their injuries than non-civilians. While 12 is a bit of a small sample, it's not unreasonably small to make extrapolations.
> What if we could somehow design systems so that the people who use them evolve to use them in better ways?
I hate when people suggest that there is something insecure about using the password reset feature. Whether I chose to use it to get into my account without a password has no impact on the security of the account. The mere presence of this feature is what’s determining the security of my account.
Similarly, some services I use prompt me to verify via SMS or Email after I input the password, but oddly imply that using SMS is more secure than email. Makes no sense to me since either way the OTP should only be usable on this one session, and even if one is a less secure channel, it’s the presence of the weaker option in the first place that’s the problem, not the choice made by the user.
> Furthermore, what audience and level of mathematics education are we discussing?
I wonder this too, I think they might mean university-level as well. For younger audiences, I feel one of the biggest problems for most people to understand math is they don't understand why any of it is relevant. If educators can make it seem more like teaching general problem solving abilities, that will likely improve the overall acceptance and lead to better overall math skills as a result.
As a specific example, our high-school math curriculum taught a lot of calculus, but framed it incorrectly as being a useful tool that people would use. Eg as if a business man would write down an equation for their revenue based on inputs, and then take the derivative to compute the maximum. I'm assuming they told students this to try and get them motivated, but it clearly was a lie since everybody knows you could just plot a graph and look at it to find the maximum. If they instead were honest that the point of learning calculus was to help with understanding more advanced concepts in math/engineering/science, while also being a valuable learning tool for general problem solving, I think that would have been a better result.
> As a specific example, our high-school math curriculum taught a lot of calculus, but framed it incorrectly as being a useful tool that people would use.
One day at FedEx the BoD (board of directors) was concerned about the future of the company and as part of that wanted an estimate of the likely growth of the company.
In the offices there were several efforts, free-hand, wishes, hopes, guesses, what the marketing/selling people thought, etc., and none of those efforts seemed to be objective or with a foundation or rationality.
We knew the current revenue. We could make an okay estimate of revenue when all the airplanes were full. So, the problem was essentially to interpolate over time between those two numbers.
For the interpolation, how might that go? That is, what, day by day, would be driving the growth? So, notice that each day current customers would be shipping packages, and customers to be would be receiving packages and, thus, learning about FedEx and becoming customers. That is, each day the growth would be directly proportional to (1) the number of current customers creating publicity and (2) the number of customers to be receiving that publicity.
So, for some math, let t be time in days, y(t) the revenue on day t, t = 0 for the present day, and b the revenue when all the planes were full. Then for some constant of proportionality k, we have
y'(t) = k y(t) (b - y(t))
where y'(t) = dy/dt the calculus first derivative of y(t) with respect to t.
Seeing how the growth goes for several values of k, pick one that seems reasonable. Draw the graph and leave it for the BoD.
That was a Friday, and the BoD meeting started at 8 AM the next day, Saturday.
First thing at the meeting, two crucial BoD members asked how the graph was drawn. For several hours, no one had an answer. The two members gave up on FedEx, got plane tickets back to Texas, returned to their rented rooms, packed, and as a last chance returned to the BoD meeting. FedEx was about to die.
I did all the work for the graph, the idea, calculus, arithmetic (HP calculator), but didn't know about the BoD meeting. Someone guessed that I did know about the graph, and I got a call and came to the meeting. The two crucial BoD members were grim, standing in the hallway with their bags packed, and their airline tickets in their shirt pockets.
I reproduced a few points on the graph, and FedEx was saved.
Interesting, but I still think most problems like that are solvable via Excel. Put some formulas in some cells, tweak some variables until you find a way to maximize something. Possibly use graphs or pivot tables or other advanced features to help if needed.
Once you’ve figured out the solution, then you build a pretty graph for the BoD proving it. Make sure to keep the spreadsheet around as evidence.
Sure, for some applications of calculus
can use just discrete steps. That is,
instead of the calculus dy/dt just use
something like (y)dt.
Then, for the arithmetic, some code can be
short and, compared with cells in a
spreadsheet, easier and with more control
over the time steps, e.g., in Rexx with cf
for customer fraction:
Say ' ==== Growth ===='
Say ' '
Say ' Customer'
Say ' Year Fraction'
max_years = 5
steps_per_year = 10 * 365
cf = 1 * ( 1 / 100 )
year = 1
k = 1 * ( 1 / 2000 )
Do Forever
Do i = 1 To steps_per_year
cf = cf + k * cf * ( 1 - cf )
End
Say Format(year,9) Format(100*cf,10,2) || '%'
If year = max_years Then Leave
year = year + 1
End
So, get a 'lazy S curve'. I've since
learned that the curve has a name, the
'logistic curve'. And, right, can also
consider that curve for other cases of
growth, e.g., for a first, rough estimate,
COVID.
Adjust some of the constants in the
program and can get more output, say, for
each month, day, etc. The code above uses
10 steps per day.
For more, someone could use the calculus
solution and compare.
In a sense, for the FedEx problem and the
assumptions about what was driving the
growth, the calculus solution is a
smooth version of the somewhat more
appropriate discrete time version.
But when I did the calculation at FedEx,
my best source of arithmetic was an HP
calculator in which case the calculus
solution was a lot easier.
Of course, this FedEx calculation was just
one example and there are many others.
My view from 10,000 feet up is that in
business, at times some math can be an
advantage if not the work of a steady job.
If some math is an advantage, then that
advantage tends to go to the owners of the
business. If a mathematician wants to get
paid for some math they have in mind,
maybe they should start a business and be
the owner.
> The blog post states “BigDecimal is a class in Java used to represent floating-point numbers with arbitrary precision”
That doesn’t mean BigDecimal is used exclusively for that purpose… If you ask an engineer if 2.5 and 2.50 are the same, they will say no. It’s clear from the implementation that BigDecimal was meant for more than just representing arbitrary precision floating points, which is why there is a pitfall if that’s all you use it for.
Btw that’s the reason it’s got Decimal in the class name - it’s modeling base10 strings, not numbers. If the strings are different it shouldn’t be equal.
>If you ask an engineer if 2.5 and 2.50 are the same, they will say no
They will say it depends on the context. If you don't look into the implementation, the class name and maybe a short summary provides that context and clearly misleads people
Right, but in this case the short summary being posted is poor. In the context of a language like Java, floating point is synonymous with IEEE base-2 floats. BigDecimal is not used to store arbitrary precision floats, but rather fixed precision decimals. Otherwise it would be called BigFloat.
Also the scale parameter really isn’t an implementation detail. Virtually every non-trivial method defined in the class requires you to understand the scale parameter in order to get the result you want.
Especially since the board is clearly unfazed by this. Words like this really need to be reserved for situations where something actually got destroyed/damaged.
I don't think they're going to let you claim a donation to an open source developer as some sort of charitable donation, which means the tax write off would be no different here from any other business expense.
But listening on port 80 and revoking the key also won’t help either as the active MitM would have been smart enough to internally proxy to port 443 or return some other fake response.
The real point is to break the application during development before the first MitM. Either approach does that equally well.
In my experience (full stack web development), unit tests are mostly useless and it is the high-level system tests which add real value. Unfortunately it can take a fair amount of work or skill to architect the test suite in the first place, but once it’s working you can write elegant tests that verify large swathes of code with fairly few lines of test code.
I think UI testing in general is hard though, and given how large a part of games involves UI, that’d be the real reason games don’t have much tests.
Agreed. We don't have a lot of UI unit tests in our software in our day job (almost none), but we have extensive tests for utility and data processing functions.
And that's pretty much the same for me in the game I'm making in my spare time. I have no unit tests for UI (it's not worth it, I can easily see when something in the UI isn't working, it's more important for me to just log the bug so I don't forget about it).
But for game logic, like verifying calculations for A.I. are happening as expected, or functions that manipulate numbers on the screen in different ways (scores, power adjustment, etc), yeah I write unit tests for those. And to the article's point, sometimes I have to significantly adjust or redo or even scrap them because I happened to think of a different mechanism and it seems to play better.
There was a long time (over about a dozen games I made) where I never bothered to write a unit test, and I still might not for a tiny game. But for my most recent bigger game (which I started a few years ago), I finally decided to write a few for some tricky numeric logic in the game, and it immediately helped me resolve a logic bug I was seeing periodically but was having a hard time pinning down the cause of it with breakpoints and logs. So I do try to do it more often for checking those things.
Part of it is terminology. You get "unit testing" and "functional testing" and "integration testing" and "system testing" thrown around, often with people meaning different things by these, and vague definitions that partially or wholly overlap.
My rule of thumb is really simple: a test should always be defined in terms of what the user expects. Thus for most apps you should, at the minimum, have tests corresponding to their functional specification. In addition, if the app contains functionality that is consistently reused inside (i.e. embedded libraries), then users of those libraries are the code that calls into them, and so there should also be tests at that boundary (but only after you wrote the high-level tests). Repeat recursively until you get to the bottom.
