IEEE 754 sort-of has that as a part of a float, too (https://en.wikipedia.org/wiki/Significand), and people use the term “mantissa” for it, but it has to special-case 0.
⇒ barring better suggestions, I think I would stretch the definition of mantissa a bit further.
Thing is, whilst a mantissa is indeed between 0 and 1, not every number between 0 and 1 is a mantissa. Specifically, a mantissa suggests the existence of a significant.
I would actually call this a bit of an antipattern.
`accuracy` seems fine to me -- although a more descriptive function name than `FuncName` might suggest a better parameter name as well.
Digging through the dictionary to find the perfect word means that whoever reads this code is likely going to have to do the same -- why would you ask them to do that?
If you aren't referring to a common mathematical or physical concept, and the word you need it isn't a part of your domain language, you're better off with "accurate but slightly vague" over "almost precise" or "precise but obscure".
It seems like the author's need would be better met by readable tests, guard conditions, and -- if this is part of an API -- documentation that describes how `accuracy` is used.
If you can't express it using the features of the language itself (custom domain-specific type, compile contracts?), limit yourself to putting this info into the docs, but keep naming simple.
Don't come up with fancy names. One of the commenters already declared (jokingly??) they'd "call it PropUnity, for proportion of unity, unity being 1".
Holy smokes Batman. As a code maintainer, I imagine encountering "accuracy" (even though it isn't fully accurately named itself) would confuse me somewhat less than "propUnity".
I'd personally go with "percent", but because there's so many correct options, it shouldn't matter as long as it's consistent in the code base. Otherwise it just becomes bike-shedding bait.
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 can focus on more important things.
fwiw, this post was inspired by a twitter thread i created yesterday (https://twitter.com/v21/status/1301451641699340288), where i collected examples of people getting annoyed that this term doesn't exist... and most of those were inspired by frustration at this being called a percentage when it wasn't. so if you want a nice collection of people stubbing their toe on the word percentage, it's out there.
Technically even that's incorrect - percentages can be negative and greater than 100 as well.
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.
The real answer to this XY is comments and documentation, imo. If you want to make it obvious without reading docs or code, get an IDE with doxygen-aware completion.
Edit: also, put it into typename, not into argname.
From a practical point of view, a new/academic word would still require serp lookup in most cases. If it were in a type, like float01, one could easily jump to the function definition and then to the type definition, described by a comment. In the case of argument naming, there is no place to jump to, only googling remains.
I typically use "_fraction" to indicate this in floating point variable names, along with a comment explicitly mentioning the range from 0 to 1 somewhere. Seems to minimize confusion pretty well.
I’ve also seen “fraction” used for this concept in Apple/NeXT APIs. E.g., “-[NSImage drawInRect:fromRect:operation:fraction:]” and “-[UIViewPropertyAnimator fractionComplete]”.
FWIW, that's not dependent typing, because the type doesn't depend on run-time values. A bool is either true or false, a [0...1] is either 0 or, ..., or 1.
Perhaps I'm misunderstanding you, but with floating point, denormalized/denormal numbers aren't just numbers with a magnitude less than 1, they're numbers so small that it's no longer possible to adjust the exponent in the usual way, so leading zeroes are used in the mantissa. This reduces precision.
You could also call that centred to clear up confusion, or mean-subtracted to be more specific. I think if you're specifically dealing with statistical quantities it should be obvious, e.g. standardised if you also scale to unit variance.
Personally if I saw normalised I would assume scaled by a constant, not offset (as in subtraction).
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?
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.
I think it's the opposite way round: normalisation results in units being dropped.
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.
Hmm when I think of 'normalizing' I don't think of dividing by a max at all - in my experience it is more taking a quantity (perhaps in English measurement) and transferring to a more 'standard' unit (say metric).
In general I don't think normalization always includes a sense of being in a bounded interval. From a mathematical perspective you could perhaps say normalization is achieved by multiplying your quantity by a 1D operator. You can't change the dimensionality this way, but are certainly changing 'units' a la mm in the x direction -> m in the x direction for example. I guess what I'm saying is that 'normalized' and the like are not the best fit for the SO question.
If I could take my own shot at the SO challenge from a mathematical perspective it would perhaps be sigmoid. Where the result of a normalization function takes a 1D value and maps it to a similar 1D value, the sigmoid takes a 1D value and maps it to a similar 1D value between (0, 1). So if I want to drop the previous information and only keep the resulting map, I can say 'this is my sigmoided value' - IE it is impossible for it to be outside of that range. Unfortunately sigmoid also connotates a differentiable curve which is extraneous information...
Of course the literal meaning of "normalisation" is to make more "normal", and that can mean almost anything at all. Even the Wikipedia article you linked to starts with "normalization can have a range of meanings". If you have heard that word most used with one meaning and I have heard it most used with another meaning then that doesn't invalidate either of those definitions.
The Wikipedia article you linked to gives two very broad definitions in the lead. The definition covered in the first paragraph is "adjusting values measured on different scales to a notionally common scale", which seems to be what you're talking about.
The definition covered in the second paragraph is "the creation of shifted and scaled versions of statistics", in particular "some types of normalization involve only a rescaling, to arrive at values relative to some size variable". I'm not comfortable with the use of "of statistics" in that second definition: the very first example is in the article standard score [1], which is about a rescaled element of the population, not a rescaled statistic. In any case, outside of statistics, a rescaling is a common meaning for this word, and a rescaled statistic is clearly just a special case of this. I think it was clear from the context that we were talking about this meaning originally. By far the most common case of this is a linear rescaling (including translation) to [0,1] but I was already up front that this is just a special case.
As for your sigmoid comment, I may have misunderstood but it sounds like you're saying that if you have a variable in the range in [0,1] then it can be described as the result of a sigmoid function. My objection to this is the same as my original objection to calling such as variable "normalised": it is a confusing variable name to use unless you actually did get it by applying a sigmoid function to something, not just because it holds a value that could hypothetically be obtained from a sigmoid function (but you didn't).
> if you're using the value by multiplying it with some other value, does that not imply it qualifies as normalised
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.
And so, even though we aren't necessary calculating the normal in the second equation, we can still name our variable a 'normal' as rearranging proves that is indeed what the value is.
That's a good suggestion. 'Normalizing' is also used to refer to taking a vector and scaling it to make its length equal to 1. Google tells me it's also used in an analogous way elsewhere in maths.
That's what I use, too: "normalized floats." I would prefer a better word, though. I work a lot with audio, and "signed normalized floats" doesn't exactly roll off the tongue.
I use this term for https://github.com/VCVRack/Rack. Sometimes I say "`x` is a normalized float between 0 to 1" to somewhat reveal the definition of the term.
That isn't the right term. The standard meaning of "normalisation" in most scientific and engineering domains is shifting and scaling to get the sample mean to 0 and sample standard deviation to 1. I.e. it will almost always include both negative numbers and numbers larger than 1.
I don't think "normalised" is specific enough. Normalising can refer to division by values other than the maximum. I'm also not convinced it implies non-negativity.
This would be like calling numbers constrained between 0 and 100 "multiplied". Yes, in some common situations you normalize data and it ends up between 0 and 1. And in some common situations you multiply and end up with numbers between 0 and 100 (like percentages).
But normalization doesn't always result in numbers between 0 and 1 and multiplication doesn't always result in numbers between 0 and 100.
Similarly, not all numbers constrained between 0 and 1 have been normalized and not all numbers constrained between 0 and 100 have been multiplied.
Add in the fact that the normalization statisticians most commonly use is z-score standardization (subtracting by the mean and dividing by standard deviation, resulting in data centered around 0), and you're going to end up with a lot of confusion. In fact, this example highlights that while normalization does mean "to scale" it doesn't mean that the result will always be bounded to a particular interval.
I think I like portion. It is one of the only nouns that suggests an upper limit of 1. The other contender is 'unitized'. I don't like normalized because it feels too much like something that was actively normalized.
This is the correct answer IMHO. (The variable name could also be "proportion" or "probability" depending on context, and the type name could more precisely be ClosedUnitInterval, but the idea of putting it in the type is IMHO correct.)
I don't know much about C (? I assume that's what this is), but in other languages you can even build a wrapper type and enforce invariants in construction if really necessary.
Of course, all that ceremony only makes sense if this is really a type you use multiple times. Otherwise I wouldn't bother.
ClosedUnitInterval surely describes the interval itself, not a member of that interval. The member would be ClosedUnitIntervalValue or something. This is the thing it would be nice to have a short name for.
Just as we say an integer is a member of the set called the integers.
We say our "X" (the word we are looking for) is a member of the set called the closed unit interval.
It's still not really "correct" IMO, I think it needs to be "UnitIntervalValue" as someone said above. I'd expect that things of type "UnitInterval" would be intervals, not values. "UnitInterval" would be like calling the type "Int32Range" instead of "Int32".
(NB: "In real life" I would never "correct" someone for calling it "UnitInterval", it's good enough -- but given this is a pure discussion of semantics...)
Names of types usually refer to individual members thereof: number, integer, vector, string, list… A variable of a UnitInterval type would one that holds unit intervals. This is no fix.
"Belongs to the unit interval" is correct, but I like to think most of us have gotten enough exposure to cognitive science to know that the brain prefers to have a word or adjective for everything, and that's the problem here.
Also, Unit Interval is only an answer to this exact question, not a class of questions to which this one belongs. If the range was [0,5] then you couldn't even shorten it with Unit Interval.
Is there a dictionary or thesaurus or something similar specifically designed to help programmers name things? I run into questions like this all the time. “There has to be a commonly used word for this concept, but I don’t know what it is”
Since they didn't want to document, I think `float Accuracy0to1` is a nice compromise that most people would understand instantly. Add `Incl` or `Excl` if you really need to disambiguate that.
324 comments
[ 4.3 ms ] story [ 156 ms ] threadIEEE 754 sort-of has that as a part of a float, too (https://en.wikipedia.org/wiki/Significand), and people use the term “mantissa” for it, but it has to special-case 0.
⇒ barring better suggestions, I think I would stretch the definition of mantissa a bit further.
[0] https://www.curtiswmoore.com/image_detail.php?title=manta.jp...
And really one mantissa is just the log of the other.
The linked Wikipedia article just says that the mantissa is “the fractional part.”
Hence the fractional part is always less than 1. Since 0.999... = 1, it is not less than 1, so cannot be the fractional part of any number.
pls no
`accuracy` seems fine to me -- although a more descriptive function name than `FuncName` might suggest a better parameter name as well.
Digging through the dictionary to find the perfect word means that whoever reads this code is likely going to have to do the same -- why would you ask them to do that?
If you aren't referring to a common mathematical or physical concept, and the word you need it isn't a part of your domain language, you're better off with "accurate but slightly vague" over "almost precise" or "precise but obscure".
It seems like the author's need would be better met by readable tests, guard conditions, and -- if this is part of an API -- documentation that describes how `accuracy` is used.
If you can't express it using the features of the language itself (custom domain-specific type, compile contracts?), limit yourself to putting this info into the docs, but keep naming simple.
Don't come up with fancy names. One of the commenters already declared (jokingly??) they'd "call it PropUnity, for proportion of unity, unity being 1".
Holy smokes Batman. As a code maintainer, I imagine encountering "accuracy" (even though it isn't fully accurately named itself) would confuse me somewhat less than "propUnity".
Or at very least an absolute normalized float
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 can focus on more important things.
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.
Percent is a fancy way to 0.01, just as ‘dozen’ is a fancy way to say 12.
Percent has some strong norms around its usage (no-one buys 1200% eggs at the supermarket) but you can’t ignore the mathematical meaning.
In both cases, if someone used them as a type name, conversion to floats should involve multiplying by the unit.
Edit: also, put it into typename, not into argname.
As for which languages allow it. I'm not sure for floats, but Pascal let you do it for ints for sure. https://wiki.freepascal.org/subrange_types
That's what we call data that have been scaled to fit on a tidy axis.
https://en.wikipedia.org/wiki/IEEE_754-1985#Examples
https://wiki.sei.cmu.edu/confluence/display/c/FLP05-C.+Do+no...
Personally if I saw normalised I would assume scaled by a constant, not offset (as in subtraction).
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?
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.
In general I don't think normalization always includes a sense of being in a bounded interval. From a mathematical perspective you could perhaps say normalization is achieved by multiplying your quantity by a 1D operator. You can't change the dimensionality this way, but are certainly changing 'units' a la mm in the x direction -> m in the x direction for example. I guess what I'm saying is that 'normalized' and the like are not the best fit for the SO question.
If I could take my own shot at the SO challenge from a mathematical perspective it would perhaps be sigmoid. Where the result of a normalization function takes a 1D value and maps it to a similar 1D value, the sigmoid takes a 1D value and maps it to a similar 1D value between (0, 1). So if I want to drop the previous information and only keep the resulting map, I can say 'this is my sigmoided value' - IE it is impossible for it to be outside of that range. Unfortunately sigmoid also connotates a differentiable curve which is extraneous information...
https://en.wikipedia.org/wiki/Normalization_(statistics)
https://en.wikipedia.org/wiki/Sigmoid_function
The Wikipedia article you linked to gives two very broad definitions in the lead. The definition covered in the first paragraph is "adjusting values measured on different scales to a notionally common scale", which seems to be what you're talking about.
The definition covered in the second paragraph is "the creation of shifted and scaled versions of statistics", in particular "some types of normalization involve only a rescaling, to arrive at values relative to some size variable". I'm not comfortable with the use of "of statistics" in that second definition: the very first example is in the article standard score [1], which is about a rescaled element of the population, not a rescaled statistic. In any case, outside of statistics, a rescaling is a common meaning for this word, and a rescaled statistic is clearly just a special case of this. I think it was clear from the context that we were talking about this meaning originally. By far the most common case of this is a linear rescaling (including translation) to [0,1] but I was already up front that this is just a special case.
As for your sigmoid comment, I may have misunderstood but it sounds like you're saying that if you have a variable in the range in [0,1] then it can be described as the result of a sigmoid function. My objection to this is the same as my original objection to calling such as variable "normalised": it is a confusing variable name to use unless you actually did get it by applying a sigmoid function to something, not just because it holds a value that could hypothetically be obtained from a sigmoid function (but you didn't).
[1] https://en.wikipedia.org/wiki/Standard_score
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.
I'm very clumsily trying to say that if:
then: And so, even though we aren't necessary calculating the normal in the second equation, we can still name our variable a 'normal' as rearranging proves that is indeed what the value is.Edit: formatting
https://mathworld.wolfram.com/NormalizedVector.html
(My vote's with "proportion" BTW.)
https://en.wikipedia.org/wiki/Normalization_(statistics)
But normalization doesn't always result in numbers between 0 and 1 and multiplication doesn't always result in numbers between 0 and 100.
Similarly, not all numbers constrained between 0 and 1 have been normalized and not all numbers constrained between 0 and 100 have been multiplied.
Add in the fact that the normalization statisticians most commonly use is z-score standardization (subtracting by the mean and dividing by standard deviation, resulting in data centered around 0), and you're going to end up with a lot of confusion. In fact, this example highlights that while normalization does mean "to scale" it doesn't mean that the result will always be bounded to a particular interval.
Why yes.
https://en.wikipedia.org/wiki/Unit_interval#:~:text=In%20mat...
If you google accuracy, you'll get the noun. If you use a made up term, it'll probably return useless results.
Unit Interval Value is nice but still a bit cumbersome. I mean if we all agreed right now it were called a "poog" then we could just say poog.
I don't know much about C (? I assume that's what this is), but in other languages you can even build a wrapper type and enforce invariants in construction if really necessary.
Of course, all that ceremony only makes sense if this is really a type you use multiple times. Otherwise I wouldn't bother.
Just as we say an integer is a member of the set called the integers.
We say our "X" (the word we are looking for) is a member of the set called the closed unit interval.
(NB: "In real life" I would never "correct" someone for calling it "UnitInterval", it's good enough -- but given this is a pure discussion of semantics...)
UnitIntervalValue would be the type name for the thing we are interested in.
Values of that type should of course have descriptive names.
Represent it internally as either fixed or floating point and divide to convert in and out if needed.
With a nice type system you could even genericize the type over integer constants
(A unit interval is the set [0, 1], whereas the asker wants to know a name for an element of it.)
Also, Unit Interval is only an answer to this exact question, not a class of questions to which this one belongs. If the range was [0,5] then you couldn't even shorten it with Unit Interval.