Currently I am pulling data from a webservice and populating the data into a custom object.
I am storing decimals such as 4.56 etc.
I am slightly confused by NSDecimal and NSDecimalNumber. I have read that NSDecimalNumber should be used when dealing with money, which I am. So the question is whether or not my properties should be NSDecimal or NSDecimalNumber. I have read cases where your model would be NSDecimal and that you would use NSDecimalNumber for any arithmetic with the numbers.
I basically want to create behavior like such in ObjectiveC
private decimal thirtyYear;
public decimal getThirtyYear(){
return thirtyYear/100.0;
}
public void setThrityYear(decimal rate){
thirtyYear = rate;
}
So, should my thirtyYear property be NSDecimal or NSDecimalNumber. Also, when doing the dividing within the getThirtyYear() method should I use NSDecimalNumber for the arithmetic.
Question #1: Should my thirtyYear property be NSDecimal or NSDecimalNumber?
As you stated if you're dealing with any financial calculations always use NSDecimalNumber and NSDecimalNumber provides predictable rounding behavior and precision when performing base 10 calculations.
If you want more detailed information this is from the Apple Documentation directly:
NSDecimalNumber is an immutable subclass of NSNumber that provides an
object-oriented wrapper for doing base-10 arithmetic. An instance can
represent any number that can be expressed as mantissa x 10 exponent
where mantissa is a decimal integer up to 38 digits long, and exponent
is an integer between -128 and 127.
Now in regards to NSDecimal, this is a C struct and not as easy to work with in Objective C. As stated above that's where the NSDecimalNumber object comes in which is made to work with object oriented languages. In short NSDecimalNumber is the way to go. It is easier to work with.
Question #2: When dividing within the getThirtyYear() method should I use NSDecimalNumber for the arithmetic?
If precision calculations are crucial in your app then yes use NSDecimalNumber since they're guaranteed to be accurate.
Since you will be using NSDecimalNumber I suggest checking out the NSDecimalNumber Class Reference because the class has a number (no pun intended) of useful methods. Hope this helps.
Related
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 6 years ago.
For some reason, certain Doubles in my Swift app are giving me trouble when converting to NSNumber, while some are not. My app needs to convert doubles with 2 decimal places (prices) to NSNumbers so they can be stored and retrieved using Core Data. For example, a few particular prices such as 79.99 would evaluate to 99.98999999999999 unless specifically formatted using NSNumber's doubleValue method.
Here selectedWarranty.price = 79.99 as shown in debugger
// item.price: NSNumber?
// selectedWarranty.price: Double?
item.price = NSNumber(double: selectedWarranty.price!)
I programmed some print statements to show how the conversion works out
Original double: 79.99
Converted to NSNumber: 79.98999999999999
.doubleValue Representation: 79.99
Can somebody explain if there is a reason why the initializer cannot surely keep 2 decimal places for every number? I would really like to store the prices in Core Data like they should be. Formatting every time it is displayed doesn't sound very convenient.
UPDATE:
Converted Core Data object to type NSDecimalNumber through data model, 79.99 and 99.99 no longer a problem, but now more manageable issue with different numbers...
Original double: 39.99
Converted to NSDecimalNumber: 39.99000000000001024
Firstly, you're confusing some terms. 79.98999999999999 is higher precision than 79.99 (it has a longer decimal expansion), but lower accuracy (it deviates from the true value).
Secondly, NSNumber does not store neither 79.99 nor 79.98999999999999. It stores the magnitude of the value according to the IEEE 754 standard. What you're seeing is likely the consequence of the printing logic that's applied to convert that magnitude into a human readable number. In any case, you should not be relying on Float or Double to store values with a fixed precision. By their very nature, they sacrifice precision in order to gain a longer range of representable values.
You would be much better off representing prices as an Int of cents, or as an NSDecimalNumber.
Please refer to Why not use Double or Float to represent currency?
That's how double works everywhere. If you need only 2 decimal places consider using integer/long instead adding point after second digit, when need to display the value.
Yes, I know I should use NSDecimalNumber to deal with currency, money, price... I've read this. The problem is, I adapted an existed project, which use NSString and NSNumber (float, double, CGFloat...) as currency. They deal with floating point by using NSNumberFormatter, as I can see it's not a big problem (yet?). Those currency is stored to coredata.
Now, if I want to convert all of those currency into NSDecimalNumber, I'll have to do a massive refactor in the code and migration in coredata. Here come the question:
If (I assume) double, CGFloat, NSNumber can hold the value as large as NSDecimalNumber, why should I use NSDecimalNumber since I can use
other with NSNumberFormatter? Is it because of performance?
In case of the necessary of the converting, can I do an auto migration with the help of MappingModel only, of course), or do I have
to adapt a custom migration policy?
Because the coredata use both NSString and NSNumber as currency, so please help me find a solution to migrate from both data type. I'm not used to work with NSDecimalNumber in coredata. Thanks in advance.
EDIT
Okay, I got it that NSDecimalNumber is necessary. Please help me answer the second question: Can I do auto migration, using mappingModel + the thing like FUNCTION($source.price, "decimalValue") (this is incorrect since decimalValue return NSDecimal, not NSDecimalNumber). Do I really have to write a custom migration policy?
Do I really have to write a custom migration policy?
Yes. Create a subclass of NSEntityMigrationPolicy for each entity that needs conversion and implement the menthod createDestinationInstancesForSourceInstance:entityMapping:manager:error:. Enter the name of this class in the Custom Policy of the entity in the mapping model.
- (BOOL)createDestinationInstancesForSourceInstance:(NSManagedObject *)sInstance
entityMapping:(NSEntityMapping *)mapping manager:(NSMigrationManager *)manager
error:(NSError **)error
{
BOOL aBool = [super createDestinationInstancesForSourceInstance:sInstance entityMapping:mapping manager:manager error:error];
if (aBool)
{
NSArray *aSourceArray = [[NSArray alloc] initWithObjects:&sInstance count:1];
NSArray *aDestArray = [manager destinationInstancesForEntityMappingNamed:[mapping name] sourceInstances:aSourceArray];
if (aDestArray && [aDestArray count] > 0)
{
NSManagedObject *dInstance = [aDestArray objectAtIndex:0];
// conversion
}
}
return aBool;
}
The issue is that double, CGFloat, and those value types stored in NSNumber cannot precisely handle decimal values. Thus, if you set 4.50, you may end up with some close approximation. This is generally not desirable for monetary values, as you want exact representations. You can perhaps get away with rounding using NSNumberFormatter, but if you start doing math with these values or need more accuracy than hundredths, you could end up with incorrect amounts.
I suspect you would have to do a heavy-weight migration to change the type of an attribute on a CoreData entity. Even if you didn't have to, you might want to, so that you could ensure the values that you convert to Decimal are rounded to the precision you choose (since they may or may not be what you want in the database right now).
It sounds like you have some technical debt in your project. Wether you choose to pay that debt down now or wait until it grows is up to you in the end.
You probably want to use NSDecimalNumber, not NSDecimal. NSDecimal is a struct, while NSDecimalNumber is an Objective-C class that inherits from NSNumber. Thus you can usually pass an NSDecimalNumber wherever an NSNumber is accepted. NSNumberFormatter formats NSDecimalNumber instances automatically, and if you set your formatter's generatesDecimalNumbers to YES, it will parse strings into NSDecimalNumber instances.
The range of NSDecimal and NSDecimalNumber is larger than double or CGFloat. The decimal types store more significant digits and have a larger exponent range.
I don't know the answer to the auto migration question, but I do know that Core Data supports NSDecimalNumber. You can set an attribute's type to decimal (NSDecimalAttributeType) in your model.
When I convert NSNumber to NSDecimalNumber this conversion is frequently not true.
I have a number like 92.43 when I convert this value to decimal or double
[number decimalValue] or [number doubleValue] value changes as 92.4299999999..
I did so many things like [NSDecimalNumber decimalNumberWithDecimal:[number decimalValue] its always returns "92.429999" to this number.
How do I use NSNumber originalValue decimal or double it is not matter I want to use "92.43" this number as "92.43". And Why this value changing?
Why is this happening?
A simplified explanation would be that it is related to how computers perform the calculations and how floating point numbers are being represented. Most floating point numbers simply does not have an accurate enough representation since they require infinite number of digits to be represented, hence the rounding (also known as roundoff or rounding error).
What can you do?
If you really need to perform accurate calculations (calculating prices for example), you should not work with NSNumber at all, but use NSDecimalNumber all the way and use it for all calculation. The safest way would be to create it from a string, for example:
NSDecimalNumber *decimalNumber = [NSDecimalNumber decimalNumberWithString:#"92.34567891"];
If accuracy doesn't matter, you can alway format the result to a fixed number of decimal places. In this case, you might also want to look into NSDecimalNumberHandler to define the rounding behaviour.
If you just need to print this number then try:
NSLog(#"%.2f", decimalNumber);
This will round 92.4299999999.. on two decimals and result will be:
92.43
Yes, I've read the other posts on stackoverflow about comparing NSNumber and none of them seem to quite address this particular situation.
This solution was particularly bad ... NSNumber compare: returning different results
Because the suggested solution doesn't work at all.
Using abs(value1 - value2) < tolerance is flawed from the start because fractional values are stripped off, making the tolerance irrelevant.
And from Apple documentation... NSNumber explicitly doesn't guarantee that the returned type will match the method used to create it. In other words, if you're given an NSNumber, you have no way of determining whether it contains a float, double, int, bool, or whatever.
Also, as best I can tell, NSNumber isEqualToNumber is an untrustworthy method to compare two NSNumbers.
So given these definitions...
NSNumber *float1 = [NSNumber numberWithFloat:1.00001];
NSNumber *double1 = [NSNumber numberWithDouble:1.00001];
If you run the debugger and then do 2 comparisons of these identical numbers using ==, one fails, and the other does not.
p [double1 floatValue] == [float1 floatValue] **// returns true**
p [double1 doubleValue] == [float1 doubleValue] **// returns false**
If you compare them using isEqualToNumber
p [float1 isEqualToNumber:double1] **// returns false**
So if isEqualToNumber is going to return false, given that the creation of an NSNumber is a black box that may give you some other type on the way out, I'm not sure what good that method is.
So if you're going to make a test for dirty, because an existing value has been changed to a new value... what's the simplest way to do that that will handle all NSNumber comparisons.. not just float and double, but all NSNumbers?
It seems that converting to a string value, then compariing would be most useful, or perhaps a whole lot of extra code using NSNumberFormatter.
What are your thoughts?
It is not possible to reliably compare two IEEE floats or doubles. This has nothing to do with NSNumber. This is the nature of floating point. This is discussed in the context of simple C types at Strange problem comparing floats in objective-C. The only correct way to compare floating point numbers is by testing against a tolerance. I don't know what you mean by "fractional values are stripped off." Some digits are always lost in a floating point representation.
The particular test value you've provided demonstrates the problems quite nicely. 1.00001 cannot be expressed precisely in a finite number of binary digits. Wolfram Alpha is a nice way to explore this, but as a double, 1.00001 rounds to 1.0000100000000001. As a float, it rounds to 1.00001001. These numbers, obviously, are not equal. If you roundtrip them in different ways, it should not surprise you that isEqualToNumber: fails. This should make clear why your two floatValue calls do turn out to be equal. Rounded to the precision of float, they're "close enough."
If you want to compare floating point numbers, you must compare against an epsilon. Given recent advances in compiler optimization, even two identical pieces of floating point C code can generate slightly different values in their least-significant digits if you use -Ofast (we get big performance benefits by allowing that).
If you need some specific number of significant fractional digits, then it is usually better to work in fixed point notation. Just scale everything by the number of digits you need and work in integers. If you need floating point, but just want base-10 to work well (rather than base-2), then use NSDecimalNumber or NSDecimal. That will move your problems to things that round badly in base-10. But if you're working in floating point, you must deal with rounding errors.
For a much more extensive discussion, see "What Every Programmer Should Know About Floating-Point Arithmetic."
I want to perform some simple arithmetic on NSNumbers and preserve the type. Is this possible?
For example:
- (NSNumber *)add:(NSNumber *)firstNumber to:(NSNumber *)secondNumber;
Is my method definition, and firstNumber and secondNumber are integers then I would like to return an integer that is the integer addition of them both. Equally if both are doubles then to return the result as a double.
It looks like I can get the type (except for boolean) using [NSNumber objCType] as found in this question: get type of NSNumber but I can't seem to extract those types and do the calculation without lots of code to extract the values do the calculation and return the result for every possible type.
Is there a short and concise way of doing this?
If you want to perform arithmetic the best bet would be using an NSDecimalNumber.
NSDecimalNumber have methods to perform arithmetic operations like :
– decimalNumberByAdding:
– decimalNumberBySubtracting:
– decimalNumberByMultiplyingBy:
– decimalNumberByDividingBy:
– decimalNumberByRaisingToPower:
– decimalNumberByMultiplyingByPowerOf10:
– decimalNumberByAdding:withBehavior:
– decimalNumberBySubtracting:withBehavior:
– decimalNumberByMultiplyingBy:withBehavior:
– decimalNumberByDividingBy:withBehavior:
– decimalNumberByRaisingToPower:withBehavior:
– decimalNumberByMultiplyingByPowerOf10:withBehavior:
And since NSDecimalNumber extends NSNumber it also have all methods of an NSNumber, so i think that you could use it in your case without any problem.
For nearly all applications it will be fine to convert to double and back using -doubleValue and –initWithDouble:. This will let you use the standard C symbols (+, -, ...) and functions (exp(), sin()). The only way you would run into trouble is if you were using close to the full precision for 64-bit integer values.
If you want to stick with Objective-C class operations you can use NSDecimalNumber instead.
See also: How to add two NSNumber objects?
How about calculating the expression value as a double (with all the inputs as double values), and then checking if the result is an integer? Then you just use NSNumber numberWithInt: or NSNumber numberWithDouble: to return the result.
When you check if the result value is an integer, be sure to account for the rounding error (e.g. when 1 is expressed as 0.99999999, etc).
EDIT: Just noticed in the docs for NSNumber this phrase:
Note that number objects do not necessarily preserve the type they are
created with.
I think this means you can't reliably do what you're trying to do.