Is there a term to represent a set of all possible values a variable can assume?
Analogy:
In mathematics a domain of a function is a set of values a function is defined on (function can take as an argument).
Examples:
A variable of type UInt16 can hold values in range [0-65536).
Completion status (represented by a double value) can hold a value in range [0-100].
Gender (represented by an Enum) can hold one of { Male, Female }.
Q:
What is a term to describe all possible values a variable can (contextually) assume?
Basically need a short version of "set of values for a variable". I have seen term type being used to describe such a range, but Type often encompasses other bits of information (e.g. a name, operations, module).
value set
domain
value range
I've also heard "value space" as a term for this.
I would just call it the "range", or "range of values".
Domain would be the math term.
I don't know of programming-specific jargon with that meaning, but "domain" itself seems like a pretty good one...
[EDIT] Read the comments to this, and I actually prefer "range".
I don't know if this is the exact terminology (if it even has one) but I have always referred to it as a range or in the case of enums options.
Range is the proper term, as in "this method will return values within the range of..."; "The expected range of this variable is:..." etc.
For atomic types, the type itself describes the range (e.g. int has a range of -2,147,483,648 to 2,147,483,647).
Anything that is a custom type may or may not have a range because custom types (e.g. struct, class, interface) are composite types that can be made up of atomic or other custom types.
The definition of a type will also vary between different languages.
The long and short of it is generally you will only be able to apply a range to atomic types based on a specific language.
It depends on the type system. In some programming laguages, a "string" can hold a sequence of characters, and an "unsigned int" can only hold positive whole numbers. In others like python, a variable can hold anything at all because it doesn't have a certain type.
Our quants here say it is called a value set. They get paid tons of money to create them so I believe them!
You may think of a variable as containing an element that is a member of a set of numbers.
As such, domain is a good descriptor for the possible values of this set.
Range is also often used in a similar context. Here we talk of the range of a function, as the set of values the function can take on. Since a variable always contains the result of some expression or computation, range clearly makes sense too.
Either is appropriate in the proper context.
Related
I'm currently reading the book atomic kotlin where the definition says Kotlin, A data type provides a set of values from which an expression may take its values and I counter to that saying isn't it the variable of data type which provides the value ? I don't know can anybody please explain ?
A data type provides a set of values from which an expression may take its values
What the sentence is telling you is that a type is a set of values, and when you evaluate an expression of this type, the (single) value of that expression is one value of that set.
isn't it the variable of data type which provides the value ?
A variable of a given data type provides one value when it's read. This is one particular kind of expression of this type. More complex expressions also have a type, and provide one value of that type when evaluated.
The important bit here is that one expression evaluates to one value, while the type is the set of all possible values for expressions of such type.
For example, as mentioned by #Ruthvik, the Int type is the set of all possible integer values between Int.MIN_VALUE and Int.MAX_VALUE.
Since Keen is not strongly typed, I've noticed it is possible to send data of different types into the same property. For instance, some events may have a property whose value is a String (sent surrounded by quotes), and some whose value is an integer (sent without quotes). In the case of mathematical operations, what is the expected behavior?
Our comparator will only compute mathematical operations on numbers. If you have a property whose values are mixed, the operation will only apply to the numbers, strings will be ignored. You can see the values in your property by running a select_unique query on that property as the target_property, then (if you're using the Explorer) selecting JSON from the drop-down in the top-right. Any values you see there that are surrounded by quotes will be ignored by a mathematical query type (minimum, maximum, median, average, percentile, and sum).
If you are just starting out, and you know you want to be able to do mathematical operations on this property, we recommend making sure that you always send integers as numbers (without quotes). If you really want to keep your dataset clean, you can even start a new collection once you've made sure you are no longer sending any strings.
Yes, you're correct, Keen can accept data of different types as the value for your properties. An example of Keen's lenient data type is that a property such as VisitorID can contain both numbers (ie 14558) or strings (ie "14558").
This is article from the Keen site is useful for seeing where you can check data types: https://keen.io/docs/data-collection/data-modeling-guide-200/#check-for-data-type-mismatch
I have a table with a field name "BID" with its data type set as NUMERIC(20,0). Now i know that it will never be a decimal/float value but always be a int/long i.e a natural number.
Is there a way for the code generator to make the variable inside the generated model class a Long as opposed to java.math.BigDecimal which it makes currently. Can it be set in jooq.properties??
This "feature" is currently only available for the Oracle database, where NUMBER is the only numeric type available. Using Oracle with jOOQ, NUMBER(20, 0) would map to java.math.BigInteger instead of java.math.BigDecimal.
This behaviour will also be available for other RDBMS in the next release 1.6.3. See
https://sourceforge.net/apps/trac/jooq/ticket/639
Besides that, overriding of data type mappings in the code generator is currently not possible, but you could use BIGINT as suggested by gbn, if you don't really need 20 decimal digits. BIGINT can hold most 19-digit decimals...
Many people believe Hungarian notation is bad. How then do you name a variables that represent the same value casted to different types?
I've got a variable called value, that might be a string, or a decimal. What would you call the different formats? strValue, decValue? valueAsString?
I think it would largely depend on the context. For instance if the string value was named age, and the decimal was the parsed value then perhaps parsedAge or something along those lines. Really it comes down to what makes sense given what you are doing and the lifetime of that variable. If it only exists long enough to actually collect and parse the value, then I would give the better name to the parsed variable or worry less about the naming of the intermediary.
If you actually need to hold on to both values, then I might consider creating a struct or some similar data structure that represents the various forms for that data value to prevents the need to shift between string and decimal formats etc.
For some time i'm debating if i should leave columns which i don't know if data will be passed in and set the value to empty string ('') or just allow null.
i would like to hear what is the recommended practice here.
if it makes a difference, i'm using c# as the consuming application.
I'm afraid that...
it depends!
There is no single answer to this question.
As indicated in other responses, at the level of SQL, NULL and empty string have very different semantics, the former indicating that the value is unknown, the latter indicating that the value is this "invisible thing" (in displays and report), but none the less it a "known value". A example commonly given in this context is that of the middle name. A null value in the "middle_name" column would indicate that we do not know whether the underlying person has a middle name or not, and if so what this name is, an empty string would indicate that we "know" that this person does not have a middle name.
This said, two other kinds of factors may help you choose between these options, for a given column.
The very semantics of the underlying data, at the level of the application.
Some considerations in the way SQL works with null values
Data semantics
For example it is important to know if the empty-string is a valid value for the underlying data. If that is the case, we may loose information if we also use empty string for "unknown info". Another consideration is whether some alternate value may be used in the case when we do not have info for the column; Maybe 'n/a' or 'unspecified' or 'tbd' are better values.
SQL behavior and utilities
Considering SQL behavior, the choice of using or not using NULL, may be driven by space consideration, by the desire to create a filtered index, or also by the convenience of the COALESCE() function (which can be emulated with CASE statements, but in a more verbose fashion). Another consideration is whether any query may attempt to query multiple columns to append them (as in SELECT name + ', ' + middle_name AS LongName etc.).
Beyond the validity of the choice of NULL vs. empty string, in given situation, a general consideration it to try and be as consistent as possible, i.e. to try and stick to ONE particular way, and to only/purposely/explicitly depart from this way for good reasons and in few cases.
Don't use empty string if there is no value. If you need to know if a value is unknown, have a flag for it. But 9 times out of 10, if the information is not provided, it's unknown, and that's fine.
NULL means unknown value. An empty string means a known value - a string with length zero. These are totally different things.
empty when I want a valid default value that may or may not be changed, for example, a user's middle name.
NULL when it is an error if the ensuing code does not set the value explicitly.
However, By initializing strings with the Empty value instead of null, you can reduce the chances of a NullReferenceException occurring.
Theory aside, I tend to view:
Empty string as a known value
NULL as unknown
In this case, I'd probably use NULL.
One important thing is to be consistent: mixing NULLs and empty strings will end in tears.
On a practical implementation level, empty string takes 2 bytes in SQL Server where as NULLs are bitmapped. In some conditions and for wide/larger tables it makes a different in performance because it's more data to shift around.