191–200 of 325 posts
Earlier quoted context omitted.
Looked it up, and a 'perunage' is defined as 'a percentage divided by a hundred'.
Which is indeed technically correct, and even an easy way to explain it the first time. Of course this rather undersells the elegance and simplicity of perunages, but I'll take it.
Does anyone know of a good site for these kind of questions other than the English stack exchange. I frequently run into programming related naming issues (who doesn't eh?). But I struggle to find accurate search terms to help answer them...and the results are usually downed out by non-technical related language Q&A's E.g. I was trying to name a table yesterday that would store events related to boxes, pallets, conta…
Earlier quoted context omitted.
One problem with the word normalised is that it implies that there is some true original value from before normalisation that isn't necessarily between 0 and 1. Of course if that's true then the word is ideal, but if not then it's confusing.
Genuine question, i'm no math expert: if you're using the value by multiplying it with some other value, does that not imply it qualifies as normalised? i.e. say you have a width of 500 and you want to move half way across so you have this value of 0.5 to get 250. By dividing 250 by 500, aren't we in fact normalising it?
Certainly, "normalisation" can mean something more general than "rescale to the interval [0,1]".
For example, "rescaling to the interval [0, 20]" might make sense in some contexts and would usually count as a type of normalisation, and would still involve muliplying by a number. But that would be multiplying by (20 / max possible value) rather than the typical case of multiplying by (1 / max possible value).
So normalisation can mean something more general than the most usual common case, but it's not just any old "multiplying it with some other value". It has to specifically for the purpose of rescaling to some fixed, more useful/sensible range.
> say you have a width of 500 and you want to move half way across so you have this value of 0.5 to get 250
This is a great example of multiplication that isn't normalisation! You've multiplied by 0.5 to get the midpoint, but that process isn't normalisation because you've not ended up with some more sensible range. You started with [0,infinity) (the set of all possible widths) and ended up with that same infinite range.
> By dividing 250 by 500
Hang on, I'm confused about your example: are you asking about 500*0.5 (=250) or 250/500 (=0.5)? If it's the latter than that's normalisation, and not even something fancy or general but classic linear rescaling to the interval [0,1]. Yes, that's certainly normalisation.
----
Going back to my original comment: I was talking about values that were in the range 0 to 1 that hadn't reached that range by being multiplied by anything at all; they were just naturally in that range to begin with. For example, a probability would fit this bill.
Case fatality ratio - but not restricted to any interval
Case fatality rate - but doesn't have a time or derivative (rate of change) component, which rates usually have
Case fatality risk - akin to probability, definitely between 0 and 1. That would be my choice.
It's shorter than the word "probability", and somewhat less frequently used, so it could be adopted for this purpose.
Edit to add: Though "accuracyRisk" does seem weird. Better than "accuracyUnitInterval" though maybe.
I use "alpha" for this, as in A in RGBA. Obviously won't work for everyone, but it's a simple convention that's easy to grok and explain.
Earlier quoted context omitted.
Genuine question, i'm no math expert: if you're using the value by multiplying it with some other value, does that not imply it qualifies as normalised? i.e. say you have a width of 500 and you want to move half way across so you have this value of 0.5 to get 250. By dividing 250 by 500, aren't we in fact normalising it?
I think generally normalized quantities maintain their original units whereas in your ratio case the unit is dropped. Units in the abstract sense I guess, such as this is a measurement along this vector or this is a ratio of any vector.
The typical, most common, definition of normalisation is value ÷ max possible value, giving a result in [0,1]. (More general definitions of normalisation exist e.g. if you rescale so the standard deviation is a fixed value, or even use non linear rescaling, that could count, but never mind all that.) The parent comment's example of "position along width ÷ total width" certainly fits that bill.
Whenever you divide something by the max of that something, the max is going to have the same units as the original value and you're bound to end up cancelling them. Or put another way, if you rescale 10cm into 0.5, it's certainly not 0.5cm so the units are either dropped or, at least, changed e.g. you could argue you've got 0.5x where x is the unit equal to 20cm.
Ratio? Probability? Proportion? Out of the answers there I like AccuracyNormalized best. That immediately conveys (to me at least) what it is and what its magnitude will be bounded by. Or...if you were writing Java or Swift NonNegativeMagnitudelessFractionalQuantity
Does anyone know of a good site for these kind of questions other than the English stack exchange. I frequently run into programming related naming issues (who doesn't eh?). But I struggle to find accurate search terms to help answer them...and the results are usually downed out by non-technical related language Q&A's E.g. I was trying to name a table yesterday that would store events related to boxes, pallets, conta…
Programmers who think like this frighten me a lot. Those parameter names are not self explanatory at all, and cannot be assumed readily understood by developers picking up the code.
If you think “this is obvious” you need to add “to me” on the end, and “not necessarily to other people.”
This can go off the rails when people start making braindead claims that code should be self-documenting and need for comments or docstrings indicates poor code. But it can also just lead to bad documentation where you think a word is clear enough and you don’t realize others will cone into that segment of code with totally different use cases or contexts in mind, assumptions about the code’s usage constraints, different levels of skill and experience, different levels of comfort with the natural language that comments are written in.
Over-communicating within documentation is a hugely beneficial thing. It only costs a small amount of hassle for the person writing it and a small amount of hassle dealing with the eyesore of it for people already familiar, but it saves so much cognitive load for everyone else.
The main downside is keeping it up to date, but the false adage that wrong documentation is worse than no documentation is no excuse.
Earlier quoted context omitted.
Again, this is bike shedding bait. I'm going by my own experience with basic mathematics in my American education where "percent" is something you multiply a number by, and usually ranges from 0 to 1. Ex. 50% of 12 marbles is 6 (*.5, 50%). But just looking at all the different answers in the comments here means there's no consensus on a "right" way. Hence bike shedding. A decent code base should be consistent so it c…
> "percent" ... usually ranges from 0 to 1 That’s not a percentage. A percentage is between 0 and 100.
A doubling expressed as a percentage of a given baseline would be 200%; economic growth during a recession is typically expressed by a negative percentage.