In CoreImage a CIFilter has both a set of Max/Min values and a set of SliderMax/Min values.
The documentation for the Max/Min says "The maximum/minimum value for a filter parameter" and the SliderMax/Min says "The maximum/minimum value, specified as a floating-point value, to use for a slider that controls input values for a filter parameter."
I'm wondering why these might be different values, as they are, for example, for the inputAngle parameter of CIHueAdjust, where max/min are 0/0 but sliderMax/Min is 3.14/-3.14?
And also what is the use of having the max/min values at 0/0 like they are for most of the filters?
I would wager that a value of 0 means there is no max/min, that any value representable by the datatype is valid for the filter.
As for why there's a separate slider value, it's because what you present to the user is often different than what's accepted. For example, the CIHueAdjust may accept any value for the actual adjustment, but a slider presented to the user has no reason to go outside the range of -3.14..3.14 (because anything outside this range is equivalent to a value inside the range).
Related
Is there any way to convert numeric data to binary equivalent for giving input to neural networks
Checked in weka- "Converts all numeric attributes into binary attributes (apart from the class attribute, if set): if the value of the numeric attribute is exactly zero, the value of the new attribute will be zero. If the value of the numeric attribute is missing, the value of the new attribute will be missing. Otherwise, the value of the new attribute will be one. The new attributes will be nominal."
Checked in RapidMiner- "they are using 2 parameters for convertion min and max values.If the value of an attribute is between the specified minimal and maximal value, it becomes 'false', otherwise 'true'
"
Can anyone tell me a better way to convert numeric data to binary.
sample data
10,50,35,15
15,20,70,25
25,10,55,10
55,10,35,15
35,15,10,50
20,25,15,20
7,55,25,30
8,35,25,30
9,70,55,10
Or whether neural networks is capable of taking numeric data as input?
Let's say I have a value that is passed to a process. What activity should i use to compare this value with another?
I know it may seem a foolish question, but i am new to this.
Assuming you are talking about BusinessWorks, comparing text values of XML attributes or elements is done with XPath using the '=' sign. You don't need to use any specific activity to do so. This can actually be done on any branch (with the "Success with condition" switch) or on the input tab of any activity.
For instance, if you want to compare the text values of 2 elements, you can use an XPath formula like this:
$Start/root/myString1 = $Start/root/myString2
This formula returns true if myString1 and myString2 have the same text value, false otherwise.
Then you can, for example, use this formula as a test condition for an "If" or a "Choice" statement on an input tab of any activity.
I'm using SMOTE to oversample my dataset (affected by class imbalance). Some of my attributes have integer values, others have only two decimals but SMOTE creates new instances with many decimals. So to solve this problems I thought to use NumericCleaner Filter and set the number of decimals I desire. This seems to work but I've got problems with missing values. Each missing values is replaced with a 0.0 value, I need to evaluate my model using missing values in dataset. So how can I use NumericCleaner (or other filters that permit to round values) and keep my missing values?
Very interesting question. Okay, here is the solution:
use SMOTE to oversample the minority group (this produces decimal points but the missing values remain missing values)
then select weka filter->unsupervised->attribute->NumericTransform
then click on this filter and set the attribute instances (where you are having decimal points features) and in the methodName instead of "abs", put "ceil".
I hope that solves the problem.
I'm trying to determine the relationship between default values and the has_foo() methods that are declared in various programmatic interfaces. In particular, I'm trying to determine under what circumstances (if any) you can "tell the difference" between a field explicitly set to the default value, and an unset value.
If I explicitly set a field (e.g. "Bar.foo") to its default value (e.g., zero), then is Bar::has_foo() guaranteed return true for that data structure? (This appears to be true for the C++ generated code, from a quick inspection, but that doesn't mean it's guaranteed.) If this is true, then it's possible to distinguish between an explicitly set default value and an unset prior to serialization.
If I explicitly set a field to its default value (e.g., zero), and then serialize that object and send it over the wire, will the value be sent or not? If it is not, then clearly any code that receives this object can't distinguish between an explicitly set default value and an unset value. I.e., it won't be possible to distinguish these two cases after serialization -- Bar::has_foo() will return false in both cases.
If it's not possible to tell the difference, what is the recommended technique for encoding a protobuf field if I want to encode a "nullable" optional value? A couple options come to mind, but neither seem great: (a) add an extra boolean field that records whether the field is set or not, or (b) use a "repeated" field even though I semantically want an optional field -- this way I can tell the difference between no value (length-zero list) or a set value (length-one list).
The following applies for 'proto2' syntax, not 'proto3' :
The notion of a field being set or not is a core feature of Protobuf. If you set a field to a value (any value), then the corresponding has_xxx method must return true, otherwise you have a bug in the API.
If you do not set a field and then serialize the message, no value is sent for that field. The receiving side will parse the message, discover which values where included, and set the corresponding "has_xxx" values.
Exactly how this is implemented in the wire-format is documented here: http://code.google.com/apis/protocolbuffers/docs/encoding.html. The short version is that message are encoded as a sequence of key-value pairs, and only fields which are explicitly set are included in the encoded message.
Default values only come into play when you attempt to read an unset field.
Can anyone explain the following behaviour to me?
When a field type in an AX Table is set to an Enum, you can select any of the Enum values as a value for the field.
But if you make the field Mandatory, you can no longer select the first Enum value in the list through the user interface.
Obviously this can be worked around by not making the field Mandatory. I am looking for an explanation of this bizarre behaviour.
AX does not have a null value concept. Instead the following values are considered "not entered" by defintion:
string: blank
int and int64: 0 (zero)
enum: 0 (typically the first value)
date: 01\01\1900 (displays as blank)
For new base enums make a blank zero enum value (by convention name it None). This will make the use of mandatory fields possible for this enum type.
Also have a look on this: Mark mandatory fields on form, if not filled with valid value
You're saying "if you make the field Mandatory, you can no longer select the first Enum value in the list through the user interface" - this is exactly what the Mandatory property does for enums: prevents you from using a zero value. E.g. if you make NoYesId mandatory you'll be able to enter only Yes because No would no longer be allowed - why would you need it on the form then?
Please also note that from a user perspective it isn't necessarily clear what enum value is zero, so if it didn't work the way it works, understanding what value is not allowed when the enum is mandatory could be tricky.