A word for a value between 0 and 1 (inclusive) | Hacker News Reader

A word for a value between 0 and 1 (inclusive)

english.stackexchange.com

201 pointspolm23305 comments

I don't think this is a naming issue at all. In the provided example, 'Accuracy' is the correct name for the parameter, as that's what the parameter represents, accuracy. The fact that accuracy should be given as a value in an interval from 0 to 1 should be a property of parameter type. In other words, the parameter should not be a float, but a more constrained type that allows floats only in [0,1].

EDIT: Some of you asked what about languages that don't support such more constrained types, so to answer all of you here: different languages have different capabilities, of course, so while some may make what I proposed trivial, in others it would be almost or literally impossible. However, I believe most of the more popular languages support creation of custom data types? So the idea (for those languages at least) is quite simple - hold the value as a float, but wrap it in a custom data type that makes sure the value stays within bounds through accessor methods.

yeah, right, so what do you call such a type? I believe that is the actual question.

The question was about the parameter name, though. The correct answer seems to be:

    function FuncName(UnitInterval accuracy)

UnitInterval seems to contains an interval, not a single float. I don't think it's a very good name.

UnitIntervalNumber would be better, but it's too long. Something like UnitNumber or UnitFloat could maybe work.

After reading this reply twice, I realised you are right and UnitInterval type indicates an interval object instead of a single scalar number.

I have actually used intervals, and should have realised this sooner. But I just had my first cup of coffee...

Yes, UnitInterval is a really bad name for a single number. Astonishingly, it has 30 upvotes on SO.

    function FuncName(NormalizedFloat accuracy)

In languages with operator overloading you can make NormalizedFloat a proper class with asserts in debug version and change it to an alias of float in release version.

Similarly I wonder why gemoetry libraries don't define separate Point class and Vector class, they almost always use Vector class for vectors and points.

I understand math checks out, and sometimes you want to add or multiply points, for example:

    Pmid = (P0 + P1) / 2

But you could cast in such instances:

    Pmid = (P0 + (Vector)P1)/ 2

And the distinction would surely catch some errors.

    Point - Point = Vector
    Point + Point = ERROR
    Vector +/- Vector = Vector
    Point +/- Vector = Point
    Point * scalar = ERROR
    Vector * scalar = Vector
    Point */x Point = ERROR
    Vector * Vector = scalar
    Vector x Vector = Vector

I think this is the best answer.

This got me thinking: What about a situation where the accuracy is given in a real-life unit. For example, the accuracy of a GPS measurement, given in meters. I've sometimes used names like 'accuracyInMeters' to represent this, but it felt a bit cumbersome.

Edit: Thinking more about it, I guess you could typealias Float to Meters, or something like that, but also feels weird to me.

Some languages provide more than just an alias. Eg Haskell lets you wrap your Float in a 'newtype' like 'GpsInMeters'.

The newtype wrapper doesn't show up at runtime, only at compile time. It can be set up in such a way that the compiler complains about adding GpsInMeters to GpsInMiles naively.

That's what unboxed tagged types are for. Floats (e.g.) at runtime, but with compile time restrictions.

I've used "fraction" for this purpose .. but that isn't general enough. In fact a convention I've used for nearly 2 decades has been varName_unit .. where the part after the underscore (with the preceding part being camel case) indicates the unit of the value. So (x_frac, y_frac) are normalized screen coordinates whereas (x_px, y_px) would be pixel unit coordinates. Others are like freq_hz, duration_secs and so on.

More complex type systems absolutely support asserting the units of a value in the type system. For example, here's an implementation of SI types in C++: https://github.com/bernedom/SI

I usually do the "inMeters" thing.

Another thing you can do is define a "METER" constant equal to 1. You can then call your function like this: func(1.5 * METER), and when you need a number of meters, you can do "accuracy / METER". The multiplication and division should be optimized away.

Good thing about that is that you can specify the units you want, for example you can set FOOT to 0.3048 and do "5. * FOOT" and get back your result in centimeters by doing "accuracy / CENTIMETER". The last conversion is not free if the internal representation is in meter but at least, you can do it and it is readable.

If you are going to use such distances a lot, at least in C++, you can get a bit of help from the type system. Define a "distance" class operator overloads, constants and convenience functions to enforce consistent units. Again, the optimizer should make it not more costly than using raw floats if that's what you decide to use as an internal representation.

F# has 'units of measure' support, https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

That's a very good observation. We still could need a (new) term for this common type. Maybe floatbit, softbit, qubit(sic), pot, unitfloat, unit01 or just unitinterval as suggested?

This begs an interesting tangential question: Which programming languages allow such resticted intervals as types?

type percentage:=int[0,100] type hexdigit:=int[0,15] …

since this might be overkill, sane programming languages might encourage assert statements inside the functions.

floatbit is good starting idea, but maybe too long to be catchy. How about a flit?

But what do you name the variable in the languages that don't support such a constrained type feature (the majority of them)?

Object-oriented languages have equivalent constructs, so I would say that this is doable in the vast majority of languages in common use:

https://news.ycombinator.com/item?id=24374372

http://wiki.c2.com/?ValueObject

I'm envisioning a programming language in which variable names and type names can become one.

So instead of

func call(Person person){} you just have func call(person){}

where person is a known type AND the variable name.

In that scenario 'accuracy' would be a type with known value between 0 and 1.

what if you have to deal with two persons?

In that case you could have the signature

func call(person#1 person#2){}

Wouldn't it be better if we could give meaningful names instead of 1 and 2?

    function call(person#sender person#receiver)

And at that point we're back to the square one, just remove the # :)

Combine with the JS/TS syntax sugar for objects and

{person}

Is an object person with key person and value person of type Person

While true, if your language doesn’t support such a type, then the burden for such a name goes to the parameter, does it not?

Usually that would go to the documentation of the parameter, plus a run-time assertion to check that received values are valid.

But the best documentation is the code itself that is documentation. I mean, well that’s kind of a cliché, but names can carry a lot of meaning.

Joel, on the original purpose of Hungarian notation:

https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

Very insightful article. I wasn't aware of "Apps Hungarian", which indeed seems like a much better idea of the redundant "System Hungarian".

> While true, if your language doesn’t support such a type

You'd be surprised where the support is. In C#, you would declare a struct type with one read only field of type double, and range validation (x <= x <= 1) in the constructor.

this is the "value object" pattern. http://wiki.c2.com/?ValueObject

Yes there's a bit of boilerplate - especially since you might want to override equality, cast operators etc. But there is support. And with a struct, not much overhead to it.

I don't think runtime validation is that special. You can bend most languages into this pattern one way or another. The real deal is having an actual compile-time-checked type that resembles a primitive.

Actually what I want is just the reading experience of seeing

"public Customer GetById(CustomerId id)" instead of "public Customer GetById(string id)" when only some strings (e.g. 64 chars A-Z and 1-9) are valid customer ids.

Compile-time validation would be ideal, but validation at the edges, well before that method, is good enough.

See: "Primitive Obsession" https://wiki.c2.com/?PrimitiveObsession

Usually cured by using Value objects. I wish this done more in OO code.

Could it be better supported in these languages? Yes, for sure. But is it true that "these language do not support such a type" at all? No.

Or you could approach it another way, store the data using the full range of the system float type and normalize it to [0,1] through accessor methods.

Can float types even support 0, 1 inclusive? You just can't represent natural numbers like that with floats...

The main issue with techniques such as this, which are certainly easy to do, is that if it’s not in the type system and therefore not checked at compile time, you pay a run time cost for these abstractions.

You can't represent the interval from 0 to 1 inclusive without significant run time cost just because of the way floats work.

Unfortunately, creating a constrained type like this isn't easy (or even doable) in all programming languages.

Fortunately, my preferred programming language, Raku, makes creating this sort of subset trivially easy[0]:

  subset UnitInterval of Real where 0 ≤ * ≤ 1

[0]: https://docs.raku.org/language/typesystem#index-entry-subset...

Is there a difference between ≤ and <= in Raku? Curious why you used ≤ in your example.

They're equivalent, Raku defines both Ascii compatible and Unicode names for typical operators. I expect they used ≤ because it looks nicer.

Yep, correct on both counts

In C, I wonder if you could do something with functions and macros?

Say you need to represent velocity in a transportation simulation. You could have a function, velocity, that looks like this:

  double velocity(double v, char * of_what)

You use it to wrap constrained values. E.g.,

  double v_jogger = velocity(8.0, "human");
  double v_car = velocity(65.0, "city car");

velocity() simply returns the first argument, after doing validity checking based on the second argument.

You probably couldn't reasonably use this everywhere that you would use actual constrained types in a language that has them, but you could probably catch a lot of errors just using them in initializers.

The problem you'd have is that doing any operations on such a value could take it outside the bounds of the "type".

In Swift you can achieve this with Property Wrappers:

  @Clamping(0...14) var pH: Double = 7.0

https://nshipster.com/propertywrapper/#implementing-a-value-...

Stan, a probabilistic programming language where this thing comes up a lot, makes it easy to declare such constrained parameters:

  real<lower = 0, upper = 1> accuracy;

Great that you like typed languages, and ones that allow for such constrained/dependent typing as well.

It seems disingenuous to me to suggest that anyone using other languages do not have this problem. And really, there are quite a few languages to not have this form of typing, and even some reasons for a language to not want this form of typing.

So please, don't answer a question by saying "your questions is wrong" it is condescending and unhelpful.

"your question is wrong" is indeed unhelpful, especially as a direct response to someone asking a question.

"here is what seems like a better question" is helpful, especially in a discussion forum separate from the original Q/A.

But if "here is what seems like a better question" is the _only_ response or drowns out direct responses, then thats still frustrating.

> condescending

As a man who sometimes lacks knowledge about things, when I ask a question, please please please err on the side of condescending to me rather than staying silent. (No, I don't know how you should remember my preferences separately from the preferences of any other human)

I'm genuinely sorry if I came across as condescending, that was not my intention at all.

I merely wanted to point out that, in my opinion, this property should be reflected in parameter type, rather than the name. Just like, if we wanted a parameter that should only be a whole number, we wouldn't declare it as a float and name it "MyVariableInteger" and hope that the callers would only send integers.

You mentioned that there are quite a few languages that do not permit what I proposed, would you mind specifying which ones exactly? The only one that comes to my mind is assembly?

So, then the user calling the library with foo(3.5) will get a runtime error (or, ok, maybe even a compile time error).

To avoid that, you need to document that the value should be between 0 and 1, and you could do that with a comment line (which the OP wanted to avoid), or by naming the variable or type appropriately: And that takes us back to the original question. (Whether the concept is expressed in the parameter name or parameter type (and its name) is secondary.)

so, basically hungarian notation

> So, then the user calling the library with foo(3.5) will get a runtime error (or, ok, maybe even a compile time error).

I'm not sure I understand this. See below, but the larger point here is that the type can never lie -- names can and often do because there's no checking on names.

I think what is being proposed is something similar to

    newtype Accuracy = Accuracy Float

and then to have the only(!) way to construct such a value be a function

    mkAccuracy :: Float -> Maybe Accuracy

which does the range checking, failing if outside the allowable range.

Any functions which needs this Accuracy parameter then just take a parameter of that type.

That way you a) only have to do the check at the 'edges' of your program (e.g. when reading config files or user input), and b) ensure that functions that take an Accuracy parameter never fail because of out-of-range values.

It's still a runtime-check, sure, but but having a strong type instead of just Float, you can ensure that you only need that checking at the I/O edges of your program and absolute assurance that any Accuracy handed to a function will always be in range.

You can do a similar thing in e.g. C with a struct, but unfortunately I don't think you can hide the definition such that it's impossible to build an accuracy_t without going through a "blessed" constructor function. I guess you could do something with a struct containing a void ptr where only the implementation translation unit knows the true type, but for such a "trivial" case it's a lot of overhead, both code-wise and because it would require heap allocations.

You're solution is the ideal one and safest, although in the interest of maximum flexibility since the goal here seems more documentative than prescriptive, it could also be as simple as creating a type alias. In C for example a simple `#define UnitInterval float`, and then actual usage would be `function FuncName(UnitInterval accuracy)`. That accomplishes conveying both the meaning of the value (it represents accuracy) and the valid value range (assuming of course that UnitInterval is understood to be a float in the range of 0 to 1).

Having proper compile time (or runtime if compile time isn't feasible) checks is of course the better solution, but not always practical either because of lack of support in the desired language, or rarely because of performance considerations.

That's fair, but I do personally have a stance that compiler-checked documentation is the ideal documentation because it can never drift from the code. (EDIT: I should add: It should never be the ONLY documentation! Examples, etc. matter a lot!)

There's a place for type aliases, but IMO that place is shrinking in most languages that support them, e.g. Haskell. With DerivingVia, newtypes are extremely low-cost. Type aliases can be useful for abbreviation, but for adding 'semantics' for the reader/programmer... not so much. Again, IMO. I realize this is not objective truth or anything.

Of course, if you don't have newtypes or similarly low-cost abstractions, then the valuation shifts a lot.

EDIT: Another example: Scala supports type aliases, but it's very rare to see any usage outside of the 'abbreviation' use case where you have abstract types and just want to make a few of the type parameters concrete.

Equally condescending is saying "It's great that you like X, but I don't so I'm going to ignore the broader point of your argument."

The point remains that the fact a given parameter's valid values are [0,1] is not a function of it's name. You can check the values within the method and enter various error states depending on the exact business rules.

'disingenuous' seems to imply that it was an intentional omission. -- which i doubt it was.

you have a very valid point but it would come across even more effectively without that part, i believe.

Sure, such other languages have the problem too, it's just that they are missing the best solution. It's possible for a solution to be simultaneously bad and the best available.

>However, I believe most of the more popular languages support creation of custom data types?

No, most don't, except if you go into building custom classes.

So, most don't support custom types unless you...use the mechanism they have for defining a custom type?

That seems a very elaborate way to say “No" when the answer is really “Yes”.

It's a succint way to say "No, not types that will automatically work as primitive types (which normally the variable passed for 0 to 1 would be), and that will work with numeric operators".

Or in other words, a succint way to say "Technically yes, but practically useless, so no".

Is there an example, in any language, showing how you would represent this at the type level? I can’t see how you would do it.

Typescript:

    type NormalisedFloat = number

Admittedly it doesn't add any actual value checking, but it does convey the information when you look at the parameter definition.

In Elm (and many other languages, I assume, I'm just most familiar with Elm) there's a pattern called "opaque data type". [0] You make a file that contains the type and its constructor but you don't export the constructor. You only export the getter and setter methods. This ensures that if you properly police the methods of that one short file, everywhere else in your program that the type is used is guaranteed by the type system to have a number between zero and one.

-- BetweenZeroAndOne.elm

module BetweenZeroAndOne exposing (get, set)

type BetweenZeroAndOne = BetweenZeroAndOne Float

set : Float -> BetweenZeroAndOne set value = BetweenZeroAndOne (Basics.clamp 0.0 1.0 value)

get : BetweenZeroAndOne -> Float get (BetweenZeroAndOne value) = value

[0] https://en.wikipedia.org/wiki/Opaque_data_type#:~:text=In%20....

You would just make the constructor return a possible error if it's not in range, or maybe some specialty constructors that may clamp it into range for you so they always succeed.

It's the same question of, how can you convert a string to a Regexp type if not all strings are valid Regexps?

Right, so there's no way to do this:

> In other words, the parameter should not be a float, but a more constrained type that allows floats only in [0,1]

It's a value check, not a type check.

I agree that it's a question of type: what would you call that type though?

I propose "pun" - proportion of unity, or "p(er) un".

Between0And1Inclusive

I like verbosity!

Or use a dependent type language. Maybe Idris? Then something like Between(0,1) I guess.

Nothing wrong with the name ZeroToOneInclusive. Seems like a great type to have around, and a great name for it. UnitFloat or UnitIntervalFloat or other ideas ITT are cuter but not much clearer.

I think this is right, but it's still IMO basically a natural language semantics issue. For instance in haskell (which has a pretty advanced static type system), I would still probably be satisfied with:

  -- A float between 0 and 1, inclusive.
  type UnitInterval = Float
  
  foo :: UnitInterval -> SomeResultPresumably
  foo accuracy = ...

i.e. I think the essential problem in the SO question is solved, even though we have no additional type safety.

A language without type synonyms could do just as well with CPP defines

Looks like it’s actually possible to string something like this together in Python; custom types are of course supported, and you can write a generic validation function that looks for your function’s type signature and then asserts that every UnitInterval variable is within the specified bounds.

You’d have to decorate/call manually in your functions so it’s not watertight, but at least it’s DRY.

I would simply put this in the description of the parameter. That’s what it is for; after all, not every constraint is computable or easy to check.

I don’t understand why having the ability to describe such a type removes the need to be able to name it.

Even if you could created constrained types like this, don't you still need to worry about what to call it?

I work in games where these values are extremely common and 'accuracy' wouldn't be very descriptive in a lot of circumstances: explosion radius falloff damage, water flow strength, positional/rotational lerps or easing, and more.

I wish I were commenting here with an answer, but I don't have one. "brightness01" is a common naming convention for values of this type in computer graphics programming, but niche enough that it got raised in review comments by another gameplay programmer.

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, containers and vessels and was looking for a generic name to group them, e.g. goods_events, entity_events, object_events, domain_object_events etc. but I had no idea how to phrase my question and not get a bunch of junk back

Would be awesome if you could tweak some suggestion algo to be trained on repo's specific to your domain and have it spit out suggestions based on human language questions, e.g. gpt3 but focussed on some domain.

Yes naming things is difficult and we would all benefit from shared names for the same things.

> boxes, pallets, containers and vessels

Woo, that's a tough one. Even as a native speaker, I'd be hard-pressed to find one word in English that describes all these similar but different terms.

I looked up some of these in a dictionary for definitions and synonyms. OK, the word "holder" seems to be the most general term that includes all these types of objects.

So I'd name it "holder_events_table", with a column "holder_type" being box, pallet, etc.

This issue of finding precise naming is related to "ontologies", how to establish an organization of agreed-upon terms to classify objects in the world. I agree with you, it would be valuable if there was a community-developed reference where we could search for the most appropriate names of things.

yeah I ended up leaning towards something similar, but avoided the whole issue of naming the "thing" by instead naming it based on the class of events contained in the table...ended up calling it tracking_events, and making it reference the "thing" as trackable_type,trackable_id (ala polymorphic relation in Rails world).

but yeah, naming things...wonder how much time I've spent pondering over names in my career (probably too much haha)

If you aren't leaning on the English Language at large, then you should ask the community of people who will use your software. Who are your stakeholders?

If you don't have a relationship with your stakeholders because your company has paid lots of money to become Agile[1][2], then you are indeed in trouble.

[1] https://www.youtube.com/watch?v=a-BOSpxYJ9M

[2] https://www.fgcquaker.org/resources/form-without-substance

> boxes, pallets, containers and vessels

So you keep info about these separately already or in some common table with discriminator? Then maybe:

boxes -> box_events, containers -> container_events,...

Or:

units(type:{box, container,...}) -> unit_events

I use Power Thesaurus[1], which is crowd-sourced and frequently has words that are well suited to technical use-cases.

In your case, I looked at synonyms for "containers" and found some likely candidates such as "holders" or "receptacles", so `receptacle_events`.

[1] https://powerthesaurus.com/

Woah, this looks like an incredible site.

Thanks for the recommendation!

Vessels like drums or like ships?

cargo events? freight events? shipment events? transport events? manifest events? payload events? package events?

> events related to boxes, pallets, containers and vessels

Think about why these 4 things are of interest. What aspect of them is it you're working with?

If that aspect has a name, that might be the basis if a good name that reflects the purpose of your code.

Not quite what you're asking, but I keep a list of useful words when I get stuck trying to come up with a variable name:

https://github.com/Mister-Meeseeks/words-for-variables

(Pull requests are welcome, if anyone else has good suggestions for candidates on the list.)

> Does anyone know of a good site for these kind of questions other than the English stack exchange.

Well, I was inspired enough by this idea to create a sub-reddit for the discussion of specific variable naming challenges. Hopefully it catches on.

https://www.reddit.com/r/namemyvariable/

Haha awesome! Sounds like something you could print on a tshirt

r/namemyvariable

Hmm feels a bit weird, maybe r/namingvariables haha already think'n bout re-naming the naming sub lolz

It is the English Language and Usage Stack Exchange (for linguists and etymologists), as distinct from the English Language Learners Stack Exchange (for people learning English), and indeed from the Computer Science Stack Exchange (for computer scientists) and the Software Engineering Stack Exchange (for software engineers).

* https://cs.stackexchange.com/

* https://softwareengineering.stackexchange.com/

So the question to ask onesself is whether one wants answers to a programming language question on how to name a variable from an audience of linguists or from an audience of software engineers. (-:

I like that the top-voted answer is a wrong one.

(A unit interval is the set [0, 1], whereas the asker wants to know a name for an element of it.)

Yeah, this is a pretty significant difference between a set and an element.

The fix is simple: Put the type of the variable in the type name. Then "UnitInterval proportion" tells you everything you need to know.

That's three words though, and the SO OP asked for a single word.

I like this idea of using the type name to define the domain, and variable name to define the purpose.

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.

I guess this is like "mammal" vs "mammalia".

"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.

“mantissa” (https://en.wikipedia.org/wiki/Common_logarithm#Mantissa_and_...) comes close, but excludes 1.

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.

Off-topic, but the wonderfully specific word "mantissa" comes up so infrequently that I just have to share this painting [0] of mine that features it.

[0] https://www.curtiswmoore.com/image_detail.php?title=manta.jp...

So the word mantissa has two different meanings that show up in really similar contexts. In

  log(120) = log(1.2 × 10²) = 2.079,

you could call both the .079 and the 1.2 a mantissa. The first is in the range [0,1) and the second, aka significand, is in [1,10) for base 10.

And really one mantissa is just the log of the other.

Can we just represent 1 here as 0.999...?

There are many ways to represent 1, but it’s still 1.

It’s 1, but is it a mantissa?

The linked Wikipedia article just says that the mantissa is “the fractional part.”

The fractional part of x is what you have left after you subtract the largest integer k ≤ x.

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.

Makes sense, thanks.

There is an answer by someone who suggested a neologism, check the link for source.

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.

"Normalized".

That's what we call data that have been scaled to fit on a tidy axis.

This has a nice confusion factor because IEEE calls such floats denormalized. Because they may have extra precision and different format.

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.

https://en.wikipedia.org/wiki/IEEE_754-1985#Examples

https://wiki.sei.cmu.edu/confluence/display/c/FLP05-C.+Do+no...

Normalized could also imply demeaned.

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...

https://en.wikipedia.org/wiki/Normalization_(statistics)

https://en.wikipedia.org/wiki/Sigmoid_function

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).

[1] https://en.wikipedia.org/wiki/Standard_score

> 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.

> If it's the latter than that's normalisation.

I'm very clumsily trying to say that if:

  width / maxWidth = normalWidth

then:

  normalWidth * maxWidth = width.

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

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.

https://mathworld.wolfram.com/NormalizedVector.html

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 am trying to think of what the opposite word is of normalization.

In the spaces I work in, people just say denormalized / denormalization.

That was easier than I imagined, thanks :)

Weirdization or maybe WeirdAlization if you like Weird Al.

"Normalized from 0 to 1" is what I say as a non-native english speaker

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.

FWIW, I'd call that the z-score.

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.

(My vote's with "proportion" BTW.)

https://en.wikipedia.org/wiki/Normalization_(statistics)

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 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]”.

Shoot. I thought "Proportion" was the One True Correct word, but it's not.

Float values between 0 and 1 are very very useful, and I use them all over the place, and I actually thought everyone did (and everyone called them 'Proportions')

Unlike percentages, you can just multiply them with the number you want the 'proportion' of,

Quick, how do you calculate 20% of 50% of 12345!?

(it's (20/100) * (50/100) * 12345)

Ok, now with 'proportions' 0.2 of 0.5 of 12345 :

Why, that's 0.2 * 0.5 * 12345 .

Am I actually the odd one out here?

It makes most sense in formulas:

Instead of x=(foo/100) * (bar/100) * baz

you can do x=foo * bar * baz.

Which is rather more readable!

Probabilities in statistics are also expressed in this manner.

Meanwhile I found out that the Dutch dictionary actually has Perunage for this usage, especially in finance. So maybe that's he term I'll start using?

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.

Not constrained to the interval [0,1], though: The change in the stockmarket was -5 percent or -0.05 perunage today, but +300 percent or +3 perunage over the last xyz years.

So it is synonymous with 'ratio'?

Latin for one is ūnus, so percent -> perun would be logical, those sensible Dutch ...

This the right answer! permyriad -> per 1000. percent -> per 100. perunage -> per 1. I now have another way to impress/irritate my peers!

I like it, but as I do not work in a Dutch-speaking environment, if I were to do this, someone would eventually come along and 'fix' it (assuming I could get it through review in the first place.)

I thought this too, so you’re not alone. I’ve been very surprised to learn what a small minority we are.

One of the answers was edited to “portion”, which is the same idea, I think either portion or proportion is elegant and simple. If anyone has been using proportion then I’d stick with that, though portion is nice and succinct.

In general usage, 'proportion' is not limited to the unit interval [1][2]. Offhand, however, I cannot think of a use of 'portion' that does not refer to part of a whole [3]. I think this is the best suggestion so far.

[1] https://www.dictionary.com/browse/proportion

[2]https://www.merriam-webster.com/dictionary/proportion (3rd. entry)

[3] https://www.merriam-webster.com/dictionary/portion

This is weird, someone in the OP thread said what you have.

A portion of fries can be 80 individuals, the proportion of all fries in the fryer might be 0.1; proportions are often expressed in percentages.

So "the proportion of the population using my tool is 1%" means 1/100, ie 0.01 of a population normalised to unity.

Pro-portion is like pro-rated, it's taken as in comparison to the whole (normalised to the whole, if you like).

"What proportion did you contribute" == what share of the whole did you contribute.

[en-gb native]

I too am surprised "proportion" was not the obvious answer.

Here's another recent HN/Twitter discussion [0] that surprised me and made me think a lot of programmers haven't done much numerical programming.

[0]: https://news.ycombinator.com/item?id=24223033

As the logic dealing with {0, 1} is named after its founder George Boole, a boolean or bool for short.

I'd suggest we call a fuzzy truth value in the interval of [0,1] after its founder Lotfi A. Zadeh, a zadehan or zade for short.

Edit: Fixed Bool to Boole thanks to globular-toast, my internal syntax checker must have auto corrected that one ;)

*George Boole.

I like this idea, although I don't think English speakers would know how to pronounce "zadehan" by default. "Zadean" might be better. I don't think it will catch on, though, because "boolean" is really easy to say but "zadean" isn't.

"Zad" means "rear" or "behind" in slavic languages and it's closely related to "butt" and "ass". So the appeal of your suggestion, as clever as it is, is definitely not universal :)

I'd only use Zadehan if it not only was a value on the interval [0, 1] but a fuzzy membership value on that interval to which the Zadeh fuzzy logic operators apply.

If it was a probability value to which Bayesian operators apply, Zadehan would be a singularly inappropriate name for the type. Types aren't just ranges but they also define the valid operations (whether syntactically functions, methods, or operators) on the type.

Sure, we can have both a zadeh, and a bayes ;)

I'm not sure if I find Koskos argument convincing, however one could also argue that a bayes is a subtype of a zadeh ;) http://sipi.usc.edu/~kosko/Fuzziness_Vs_Probability.pdf

Bayesian probability is, from a certain perspective, a fuzzy logic but the operators of Bayesian logic are not the operators Zadeh’s fuzzy logic. Since types define operators as well as values, I'd argue that a “bayes(ian)” type should be distinct from a “zadeh(an)” type, even if they might usefully have a common “fuzzy_membership” supertype.

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.

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.

You're not wrong but it would be nice to have a word for this incredibly common type of value still.

As a mathematician, I heartily agree.

I couldn't agree more.

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".

Weird that it's been flagged as off-topic with no explanation. "I'm looking for a word" seems very on-topic for an stack exchange about a human language.

Among the comments:

> Naming variables is expressly off-topic here. This question, and the answers to it, are the perfect showcase of why. – RegDwigнt

The link "off-topic" in the notice eventually takes you to the help center which states:

> But please, don’t ask any questions about the following topics. They are out of scope for this site.

> * Naming, including naming programming variables/classes

The question was edited, but the original version was about how to name a variable.

That said, the reason why they're not allowed is not as apparent to me as it is to the mod that made the comment quoted above.

It seems every StackExchange site is overrun by sophomoric gatekeepers, searching for (& competing with each other?) to find any possible reason to shoot-down questions.

It's so much easier to hit that 'downvote' or 'close' button than to actually try to understand the asker, or compose a meaningful answer, or even explain clearly why a question might truly need work.

So, I see a lot of 'closes' from people who hardly ever answer any questions, and plenty by people who simply don't understand the question's domain enough to see that yes, that is a meaningful question with a compact, well-matched answer. And once closed, it seems no one really looks at 'reopen' requests, even after the question text improved.

Not speaking to this question... but I largely don't even participate in stackoverflow anymore as most questions seem to be what should be an RTFA, have an existing answer, or homework help for what is way beyond the scope of the site.

It's frustrating when 9/10 of the questions aren't even deserving of an answer (at least that's my opinion) for the above reasons.

Gotcha on the edit... I saw a question that was more pertaining to documenting what a parameter is, which seems to be a valid question. Like other answers, portion or proportion seem like the most appropriate answer as part of a whole.

Given that no existing word is quite right for this common problem, a neologism is best. And "primantissa" delights: I will smile every time I use it.

Naming the variable "accuracyPrimantissa" doesn't seem delightful to me, though.

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.

I like this a lot, given how often it's used in scenarios similar to alpha blending, like "reducing the proportion of X".

Sounds a bit too much like alphabet or alphanumeric?

Not to me. Especially when preceded by "float".

I also have the name "alpha" for numbers like this. I don't think i got it from graphics.

Anyone inclining towards the view that comments are harmful, as good code is always self-documenting, should ponder the amount of debate that has already gone into this one tiny issue.

In times of COVID-19, I've seen quite some discussion about what the "R" in CFR stands for. Whatever it stands for, that's the right answer :-)

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.

If 0-100 is a percent, then wouldn't 0-1 be a perun(something)?

I don't know latin, but perun, perune, peruni?

Perunage, yes. Lamentably that is not restricted to [0,1], just as a percentage isn't restricted to [0%, 100%] (look at the stock market return over the last few days, and the last decade).

"float zero_to_one" is pretty short and obvious. The caller can maybe even guess by the context of the function name that it probably accepts 0 and 1.

> between 0 and 1 (inclusive) [closed]

Why yes.

lol. really a ''closed'' interval.

If they had only asked about the interval without the endpoints, then we could still discuss the question.

I've called this 'unit real' in the past, but wasn't happy with it. 'Portion' is good, from one of the answers. ('Proportion' and 'fraction' unfortunately both suggest a ratio of integers instead of a unit real. It'd sure be convenient if these two different words weren't fixed to that same meaning.)

For neologisms, 'tweening' comes to mind. (Think of the coefficient of a convex combination. 'Tweenness' feels just a little too long.) 'Fractile' from the stackexchange thread would also work.

Booleans have the same problem that we lack a plain English short word for "yes or no answer". I think we ought to start pushing 'bool' or 'boole' out of our jargon and into common English.

> Booleans have the same problem that we lack a plain English short word for "yes or no answer".

"Binary" is the term I use. E.g., "It's not a binary proposition" to call out a false dichotomy.

Binary means that there are exactly two choices, not that the choices are yes or no.

I understand, but context typically gets you the rest of the way. We're talking about natural languages after all; this is about as good as you can hope for.

>'Proportion' and 'fraction' unfortunately both suggest a ratio of integers instead of a unit real.

I don't mean to pick on you in particular abecedarius, but I find it amusing to be worried about signalling that irrational numbers are OK given the context is computing and all the numbers are rational anyway.

You got me there, but I think this kind of discussion is "you know what I mean" territory: ratios aren't limited to 0..1, and the central examples the terms evoke involve small integers.

A fraction or proportion in general doesn't have to be representable as a ratio of natural numbers. That's called a "common fraction", and as it happens, floating point representation stores the value as a ratio of natural numbers anyway. It's like asking someone to cut you 1/pi of a pie. It isn't total nonsense, but it is weird and you're going to get an approximation. They might get confused by your odd request and give you half a pie instead a third of a pie though!

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”

Maybe there should be an IRC group #namingthings on Freenode?

Creating a type that is defined as being between one and zero would be more helpful and then the name can reflect the usage of the value

Sure, but then you still have to name the type.

UnitInterval

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

Others have already said it, but that name is for a type whose values are intervals, not a type whose values are numbers within an interval.

I heard percentage (0-100), promillage (0-1000, per mille) and perunage (0-1) in school. This was not in an English speaking country.

So for me "perunage" sound very logical. "Un" means one in French (cent=100 and mille=1000).

Perunage seems to occur in the Dutch dictionary too.

While percentages are denoted as numbers between 0-100, they actually represent numbers between 0-1. Though you can have things like 120% so it's not perfect.

I did not mean it cannot exceed 1/100/1000.

> they actually represent numbers between 0-1

Not really. The often represents, for instance, a population of 100M, then 0 means 0, 1 (or 100%) means 100M and 1.2 (or 120%) means 120M (in case of population growth).

We are really arguing unimportant semantics here but I don't agree with you, when you say 50% of the population, you are saying 0.5 of the population or 0.5 of 100M. The 50% always represents 0.5 when used correctly, in fact the % sign is a different way of writing "/100" (with some artistic freedoms).

Really the percentage sign just denotes a centi-1. Just like a centi-meter is 1 hundreths of the unit 'a meter', a percentage is 1 hundreths of the a (unitless) unit '1'.

I'd agree with "portion" or "part" -- describes a percentage in decimal notation, to me at least.

What about "fraction"? That's what I tend to use in my own code, although it could be greater than 1 potentially.

That's a feature, in case you need to crank the power up to 11.

Wouldn’t this be a normalized / unitized float?

Or at very least an absolute normalized float

In my code, rather than use a generic term to describe the number, I try to name what it actually represents in context. For example, if I'm scoring items so I can rank them, and I need to normalize some number to do that, I'll call it a "score" or a "rank".

Calling it a "proportion" or "ratio" or "normalized" is like calling a variable "myinteger" or "myfloat". Your naming convention should be related to a variable's purpose, not its data type.

Is there a resource for "help naming stuff"? Naming is hard. Especially so when you dabble in domains you're not learned in. I have almost no math background so sometimes I really struggle to know what to name things.

My latest example is, "I need to provide a flag to switch if this element is positive or negative. What do I name the flag?" (came up with simply: sign, or polarity)

For booleans I generally stick to the `isX` format. So in your case, `isPositive` (or `isNegative` depending on your preference)

Good ideas.

But I messed up my own example. The one I was reaching for was a flag to set “clockwise or anti clockwise or neither”

I was looking for the terminology for clockwiseness

In mathematics, by a widely used convention, a clockwise rotation is negative.

LISP had the convention of appending "p" for predicate:

(evenp x) would return true if x was even.

So, "positivep". Though, yeah, that would be the name for a function that checks whether the argument was positive, not a flag.

Common Lisp calls it plusp.

Depending on context I would use

  ratio
  saturated (if something is clamped to 0-1)
  normalized (if it is scaled down using a max value)

I don't like "ratio" because, though this might just be me, I already have a bad habit of assuming, incorrectly, that every ratio in my code is meant to stay smaller than +1.

That sounds valid, no reason for ratio to be <= 1. It usually is but not always I guess

Better languages will let you call the variable just "accuracy", but with type "float 0 to 1 inclusive" with some literal syntax; so from

    function FuncName(float AccuracySOMETHING)

    function FuncName([0...1] accuracy)

Which languages allow this? It looks suspiciously like dependent typing to me

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.

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

Isn't that just the decimal part? In my mother tongue (Serbo-Croatian) it's common to call this just the decimals - e.g. in 12.34 the decimals would be 34... I'm really surprised that English doesn't have a similar short name for this?

Would that include 1 however? If you take the decimal part of something then there is no difference between 0.00 and 1.00 which is I think part of the problem here

'Proper fraction' is very close in meaning.

https://en.wikipedia.org/wiki/Fraction#Proper_and_improper_f...

Related question: what would be the best way to store such a value? A float would only use the mantissa-bits, so it would be rather inefficient. Perhaps as a uint16 with a representation of uint16 / (2^16)?

Practically? float/double. You probably don’t need any more precision and maintaining easy interoperability is more important.

Otherwise you just want the mantissa stored as an int or byte[] until you need it to be converted to a floating point number.

I'm not an expert on the ins-and-outs of floating-point numbers, but I've always heard fp types have a disproportionately large amount of their accuracy at values < 1. My guess is that it's not that wasteful sticking with floats or doubles.

What I do wish the languages I used had support for, is number types that the user could clamp to a specific range. It would be nice to have my code throw an error if some function resulted in clipped audio, for example. I mean, without the programmer writing any extra code, of course.

You're likely thinking of subnormal or denormal numbers, which helps floating point representation better represent tiny numbers near zero. The typical floating point number is normalized so that it's 1.xxxx*base^exponent. Since the 1 is always there, it is made implicit as a rule and only xxxx and exponent is stored in memory. There's a limit to the range of the exponent, though, and so for very tiny numbers near zero, the exponent is capped at its smallest value and the rule changes to have an implicit 0 instead of 1. Then, you can get a few more orders of magnitude 0xxx, 00xx, 000x, etc. You gradually trade significant digits for more negative exponents.

I don't think it really helps for the interval 0 to 1, but rather for the interval 0 to 0.000000000000000000000000000000000001 or whatever. It doesn't give you more significant digits, but rather a gradual degradation of significant digits as they get used for exponents.

Subnormal numbers are a bit controversial because of their relative utility vs. added complexity to implement them, especially in hardware.

I would want to keep this stored as a float.

Because chances are, I am going to be multiplying other floats by this number. And the performance penalty (not to mention the maintenance penalty) of converting back-and-forth between whatever you choose and floats will probably out-weigh the gains of storing it efficiently.

That said something like a uint would probably be most efficient if you did care. At that point, allignment issues also start cropping up performance wise.

It depends on how you intend to use it. For example, in digital signal processing (audio), most processing is done using uint32 values. It would make no sense to receive the value as a float, only to convert it back to int before using it.

Case in point: most software volume controls allow to specify the output volume (or rather, control the attenuation) using the full uint16 range. In this case, the entire volume range is expressed from 0x0000 to 0xFFFF. But in practice, this is just an amplification (multiplier) value between 0 and 1.

I think it depends on the audience. As a programmer I'd be happy with zero_to_one, while a semitechnical audience might like better normalized_ratio.

If your language supports it you could do

  function FuncName(Bound<float, 0, 1> Accuracy)

...or if it doesn't

  function FuncName(BoundFloat0_1 Accuracy)

...or if it's dynamically typed

  function FuncName(AccuracyBoundFloat0_1)

...or if mentioning the bounds explicitely is too verbose/YAGNI for your taste

  function FuncName(UnitIntervalFloat Accuracy)

Probability

This is the right answer for anyone in data science

I propose "pun", as a neologism, for brevity. Easy to postfix.

"Proportion of Unity" "Proportion of Unity, Normalized". "P(er) Un" or "Perunage" contracted.

Short, doesn't clash hard with other meanings, is its own mnemonic.

AccuracyPun would be accuracy as a proportion of one. femPop might be 8000, but femPopPun would have to be [0,1].

That violates my organization's NAP, or "No Acronym Policy". No way I'll get an LGTM on any PR that includes that!

Isn't that simply a decimal fraction? https://en.wikipedia.org/wiki/Fraction#Decimal_fractions_and...

Decimal fraction can be greater than one.

Proper decimal fraction?

Exactly, in order to sufficiently specify the thing we are talking about we seem to need at least three words.

Fractional seems workable but it is exclusive. fractional-unit-scalar seems to work (domain, clarity) but it’s a mouthful:

Enter a fractional-unit-scalar value for the bias parameter

Enter a fractional-unit-scalar value for probability p0

How about just oTo1InclusiveVal ? I know very simple, but would get the job done ?

> substituting o for a '0'

pls no

sorry must have typed by mistake in mobile

we can put underscore before the 0 so that it is a valid name

Floating point boolean: It can convey True, False and all the grey in between.

This is about as good as it gets for the concept, but lacks as a name. I propose boof.

But actually there's two "natural" hardware implementations for this. First is like floating point with no sign bits (mantissa is positive or zero, exponent is negative). The other is fixed point, basically re-interpreting unsigned ints as being implicitly divided by 0xfff...f -- both have advantages and drawbacks. And then comes the operations. Multiplication is the only closed operation -- addition, subtraction and division need special cases: should they be clamped, or wrap around? Both, probably -- wrapping is useful for trig functions, for example.

My arbitrary suggestion for what I sometimes use in coding is "stage". As in "what stage has the animation reached?". At least it's short! Crops up a lot in gaming and graphic code.

I would love to have a symbol that represents this unit scale as an analogue to '%'. I.e. you could say 33% or 0.33x where where 'x' indicates a normalized decimal from 0.0 to 1.0.

There was the "uno" proposal.

https://en.wikipedia.org/wiki/Parts-per_notation#Uno

I'm glad it never caught on.

Interesting, although that goes the other way, indicating different degrees of implied scaling (rather than none). If you were labeling a header or axis on a chart, or naming a variable you'd probably include the word "decimal", "fraction", or "scalar".

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.

extrapolating from "per-million" to "per-thousand" to "percent", how about "perone" or "perunit". foo_perunit = foo_percent/100.

Closed, of course

Modoverflow strikes again

I propose "tegritage", combining "(in)tegrity" with "-age". A concrete number by analogy would be "0.753 tegrent".

I use fraction. Better than any of the answers there.

Not true if the value refers to something like RGB color components.

A unit value is a value in the unit interval.

Given the lack of common language, IMHO describe it instead of being clever.

Example: FractionInclusive

First, use a better language. This is the syntax as I remember it from Ada:

subtype Probability is Float range 0.0 .. 1.0;

I use proportion in this context.

"zeroToOne" includes both values. "Given a number from zerotoone..."

zeroToOne doesn’t include one

Perhaps a word that means “Almost Nothing”.

Piddling: amounting to very little; trifling; negligible

We could call it a "Thiel", after his book "Zero to One".

Percentage.

But in the code I'd probably use X_range depending on what 0..1 represents

percentage is 0 to 100, though. (Or even more, saying 200% is not technically wrong depending on context)

Depends how you look at it, I guess. 0 to 100% translates to 0 to 1.

edit: but I guess it is wrong, because % is ambiguous - it can mean fraction, it can mean growth

That's like saying that inches are the same thing as yards because you can convert from one to the other.

What I was taught in school is that "percent" doesn't refer to 0 - 100, it refers to 0% - 100% which is equal to 0 - 1 (not really a conversion, actually equal).

As 0% and 100% aren't floats (they're more like formatted values), seeing AccuracyPercent in the question had me thinking there was nothing more accurate.

So if you build a tax calculator and add a field with the label "Please add your tax rate in percent" you expect people to enter a value between 0 and 1?

No, but you're defining a unit here; I'd expect people to put in values as 0..100 with unit being percent. So if a person puts in 20, and you'll want to multiply it by 3, you'd not expect 60 as end result; you'd expect 60% which is 0.6

You're still raising valid point with the ambiguity - if I were to see a variable named `population_percentage = 0.01` I'd still need to ask the author if the intended value here is 1 or 0.01, which I'd say disqualifies this naming.

I'd call it PropUnity, for proportion of unity, unity being 1.

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.

How about we coin it now? We could call it a Thiel.

Looks like it could be a "probability".

function FuncName(float ShouldBeAccurate)

function FuncName(float AccuracyBoolean)

function FuncName(float BoolAccuracy)

function FuncName(float IsAccurate)

Onecentage

Factor

Perunit

it's called a share

perunum

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

I always use ratio for this kind of number. Though it could be bigger than 1 since 120% == 1.2

Yes, I was thinking something like proper ratio but I don't think that's standard plus I think it's getting pedantic.

The takeaway is words are mostly a leaky abstraction, imperfect model for math concepts.

But I guess if you're a clever programmer you could call it a ThielAccuracy, or ThielRatio

Maybe part_ratio? Because you can never take a bigger part than 100%.

Yeah, I like that. Or fractional_ratio. With part_ratio tho I'm still not sure which part... (the lesser or greater than 1) part. But I like it because it's shorter. Frac_ratio feels like cheating a bit.

But I guess a number that's always between 0 and 1 is an integer reciprocal. But again that's probably getting too deep for this.

I guess another way is UnitIntervalPoint or ProperFraction

I guess in Java we don't have to choose

FractionalPartRatioForAccuracyNormalized hehehe

I suppose we could make up a word

bition, or bitum

anabit or cobit - analog bit (continuous on 0 to 1)

proratio - proper ratio

Making up a word seems easier than the rest because it's more concise. :)

> “ Most things I can name easy enough, such as "Name" or "URL" or "MaxSizeN". The first 2 are self explanatory, the last one is the maximum size of something in relevant data units(as opposed to bytes or some other unit) but that one is easily understood by other programmers too.”

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.

Since it's a value in the unit interval, I call it "unance".

"Probability". This question would have a single word answer if it was posted on math.stackexchange.com.

literally copy/pasted from wikipedia:

> A probability is a way of assigning every event a value between zero and one,

A probability has to lie between 0 and 1 but not every value between 0 and 1 is a probability.

the probability of a "value between 0 and 1" to be an actual probability is very close to 1.

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.

Right but it’s specifically not, and liable to make people think “3” is an acceptable input

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.

There might be bike shedding for the best answer, but this is just incorrect. Percent literally means "for one hundred"

> "percent" ... usually ranges from 0 to 1

That’s not a percentage. A percentage is between 0 and 100.

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.

‘Per’ means ‘divided by’, ‘cent’ means 100. Units implicitly multiply, and x/100 == x*0.01.

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.

Why is everybody else suggesting things like 'accuracy', and 'between_0_1" when there exists an actual term: "unit interval" (the top answer)

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 is the interval between 0 and 1. We need a word for a value within that interval.

Then "unitIntervalValue"

Right. That's the thing we need a word for :)

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.

UnitInterval is the type. The name of the value should reflect its specific use.

Exactly. The best usage for this would be something like:

    typedef float UnitInterval;

    void do_something_accurately(UnitInterval accuracy);

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...)

Sure, that's fair. I was more talking about it being better to name the type a particular thing, rather than encoding the type in the variable name.

    typedef float UnitIntervalValue;

    void do_something_accurately(UnitIntervalValue accuracy);

FTFY

UnitInterval isn't a type, it's a value of type Range, specifically the range [0,1].

UnitIntervalValue would be the type name for the thing we are interested in.

Values of that type should of course have descriptive names.

Reply on news.ycombinator.com