How to store too large binary value in objective-c? [closed] - objective-c

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I have got a too large binary value.
value1 : 2 ^ 300,000.
value2 : 2 ^ 300,000.
I'd like to do 'and calculation' of value1 and value2.
First of all, how to store a value1 and value2? (int, float, double... ???)
int value1 = 2 ^ 300000;
Is this correct?
Does this way completly store a value?
context for using)
I have two arrays which has 300,000 elements.
eg) array1 # [# "apple", # "banana", # "iphone", # "TV", # "clock" .... <= it has 300, 000.
array2 # [# "fruit", # "fruit", # "electric", # "electric", # "electric" ....] <= also has 300,000.
display prefered thing to binary : 1,1,0,0,1 ...
display prefered kind to binary : 1,1,0,0,0 ...
result of calculating 'and' of array1 & array2 : 1,1,0,0,0 ...
I like "apple" and "banana" of fruit.
Reason of using binary calculating are expected to be faster than other way.

The first thing is that you are not using Objective-C classes, but Plain Old Datatype, a.k.a. POD.
That large value far exceeds the limit of integers, even 64-bit unsigned ints. I am not a math wiz, so I'm not sure if that will fit in a double but that doesn't matter because with floating-point, you loses precision. (Link to WolframAlpha for the exact value that definitely won't fit.)
What you want is probably NSDecimalNumber which provide up to 38 digit precision, that's what's built into the library, if you need further precision, you can write your own class, or check out libraries like GMP.
There's a good question and answer about NSDecimalNumber here.
UPDATE: As Craig mentioned in the comment, you may want to roll your own class to speed up the calculation. Libraries like GMP are general purpose, and will do the calculation in a way that's so safe that it sometimes are wasting your time as the calculation you want to do can be simplified.

First of all the ^ operator is not a power operator, but a bitwise XOR.
So 2 ^ 300000 actually produces 300002.
Secondly you can use NSDecimalNumber, a subclass of NSNumber, which according to the documentation
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 from –128 through 127

If you have 300 000 objects, have you considered to use a database, e.g. Core Data? Instead of a very large bit mask, maybe it would be easier to do the same by a single database (Core Data) request.
To answer your specific question, a C-array of integers would be probably the best solution:
const NUM_OBJECTS = 300000;
//8 * sizeof(int) bits per an int
int* mask = malloc((size_t) ceilf(NUM_OBJECTS / (sizeof(int) * 8.0f));

Related

Is there anything special about the number 308? [duplicate]

This question already has answers here:
Biggest integer that can be stored in a double
(10 answers)
Closed 1 year ago.
So one day I was experimenting (like any other good coder does), and I came up across this:
>>> 1e308
1e+308
>>> 1e309
inf
What is going on? First of all, 308’s factors are 2, 2, 7, and 11.
Farther investigation yields:
>>> 1.7976931348623158075e308 # No, I didn’t copy it incorrectly
1.797693134862315e+308
>>> 1.79769313486231581+308
inf
So what is going on? There doesn’t seem any relationship between an absurdly big number and an equally weird number with over 10 decimal places.
Also, all of this was using the repl python console, so others might be different.
A double-precision floating point number in IEEE-754 has an 11-bit exponent and a 53-bit mantissa. The 11-bit exponent means we get from 2**(-1023) to 2**+1023. 2**1023 happens to be 10**308.
You get about 3.23 bits per decimal digit. A 53-bit mantissa gives you about 17 digits of precision.
The largest number that fits in a double is, as you noticed, 1.7976931348623158075E+308.
I recommend https://en.wikipedia.org/wiki/IEEE_754 .

Why write 1,000,000,000 as 1000*1000*1000 in C?

In code created by Apple, there is this line:
CMTimeMakeWithSeconds( newDurationSeconds, 1000*1000*1000 )
Is there any reason to express 1,000,000,000 as 1000*1000*1000?
Why not 1000^3 for that matter?
One reason to declare constants in a multiplicative way is to improve readability, while the run-time performance is not affected.
Also, to indicate that the writer was thinking in a multiplicative manner about the number.
Consider this:
double memoryBytes = 1024 * 1024 * 1024;
It's clearly better than:
double memoryBytes = 1073741824;
as the latter doesn't look, at first glance, the third power of 1024.
As Amin Negm-Awad mentioned, the ^ operator is the binary XOR. Many languages lack the built-in, compile-time exponentiation operator, hence the multiplication.
There are reasons not to use 1000 * 1000 * 1000.
With 16-bit int, 1000 * 1000 overflows. So using 1000 * 1000 * 1000 reduces portability.
With 32-bit int, the following first line of code overflows.
long long Duration = 1000 * 1000 * 1000 * 1000; // overflow
long long Duration = 1000000000000; // no overflow, hard to read
Suggest that the lead value matches the type of the destination for readability, portability and correctness.
double Duration = 1000.0 * 1000 * 1000;
long long Duration = 1000LL * 1000 * 1000 * 1000;
Also code could simple use e notation for values that are exactly representable as a double. Of course this leads to knowing if double can exactly represent the whole number value - something of concern with values greater than 1e9. (See DBL_EPSILON and DBL_DIG).
long Duration = 1000000000;
// vs.
long Duration = 1e9;
Why not 1000^3?
The result of 1000^3 is 1003. ^ is the bit-XOR operator.
Even it does not deal with the Q itself, I add a clarification. x^y does not always evaluate to x+y as it does in the questioner's example. You have to xor every bit. In the case of the example:
1111101000₂ (1000₁₀)
0000000011₂ (3₁₀)
1111101011₂ (1003₁₀)
But
1111101001₂ (1001₁₀)
0000000011₂ (3₁₀)
1111101010₂ (1002₁₀)
For readability.
Placing commas and spaces between the zeros (1 000 000 000 or 1,000,000,000) would produce a syntax error, and having 1000000000 in the code makes it hard to see exactly how many zeros are there.
1000*1000*1000 makes it apparent that it's 10^9, because our eyes can process the chunks more easily. Also, there's no runtime cost, because the compiler will replace it with the constant 1000000000.
For readability. For comparison, Java supports _ in numbers to improve readability (first proposed by Stephen Colebourne as a reply to Derek Foster's PROPOSAL: Binary Literals for Project Coin/JSR 334) . One would write 1_000_000_000 here.
In roughly chronological order, from oldest support to newest:
XPL: "(1)1111 1111" (apparently not for decimal values, only for bitstrings representing binary, quartal, octal or hexadecimal values)
PL/M: 1$000$000
Ada: 1_000_000_000
Perl: likewise
Ruby: likewise
Fantom (previously Fan): likewise
Java 7: likewise
Swift: (same?)
Python 3.6
C++14: 1'000'000'000
It's a relatively new feature for languages to realize they ought to support (and then there's Perl). As in chux#'s excellent answer, 1000*1000... is a partial solution but opens the programmer up to bugs from overflowing the multiplication even if the final result is a large type.
Might be simpler to read and get some associations with the 1,000,000,000 form.
From technical aspect I guess there is no difference between the direct number or multiplication. The compiler will generate it as constant billion number anyway.
If you speak about objective-c, then 1000^3 won't work because there is no such syntax for pow (it is xor). Instead, pow() function can be used. But in that case, it will not be optimal, it will be a runtime function call not a compiler generated constant.
To illustrate the reasons consider the following test program:
$ cat comma-expr.c && gcc -o comma-expr comma-expr.c && ./comma-expr
#include <stdio.h>
#define BILLION1 (1,000,000,000)
#define BILLION2 (1000^3)
int main()
{
printf("%d, %d\n", BILLION1, BILLION2);
}
0, 1003
$
Another way to achieve a similar effect in C for decimal numbers is to use literal floating point notation -- so long as a double can represent the number you want without any loss of precision.
IEEE 754 64-bit double can represent any non-negative integer <= 2^53 without problem. Typically, long double (80 or 128 bits) can go even further than that. The conversions will be done at compile time, so there is no runtime overhead and you will likely get warnings if there is an unexpected loss of precision and you have a good compiler.
long lots_of_secs = 1e9;

handling overflow in Objective C

I'm building a hex calculator in objective-c. My problem is dealing with long long values that would overflow when multiplied.
When I add values before I add i check that the value would not overflow by doing something like this.
long long leftToAdd = LLONG_MAX - self.runningTotal;
if (self.selectedNumber <= leftToAdd) {
self.runningTotal += self.selectedNumber;
} else {
self.selectedNumber -= leftToAdd;
self.runningTotal = self.selectedNumber-1;
self.overflowHasOccured = YES;
}
if the value would overflow it takes the overflow value (without actually overflowing) and adds an overflow notification. I was hoping to find a way to do this same type of thing but for multiplication, can anyone help with this?
here's what i have so far.
// if - value would not overflow //
if (self.runningTotal > 0 && self.selectedNumber > 0
&& LLONG_MAX/self.runningTotal >= self.selectedNumber) {
self.runningTotal *= self.selectedNumber;
// else - handle overflow //
} else {
}
and as a side question would i need to do a similar check for division?
You could check for overflow in multiplication following the same pattern you use for addition - for the later you use subtraction to determine the bound, for the former you would use division:
long long canMultiplyBy = LLONG_MAX / self.runningTotal;
In all cases if you are supporting signed numbers you have to consider underflow as well. Division requires a divide by zero check.
In the C library there are functions for checked arithmetic, lookup check_int64_mul to find the lot (they are all described on the same manual page). These will be efficient and operate directly with primitive value types are you are now doing.
The Clang compiler also provides some checked arithmetic builtin functions, these differ from the C library functions in returning a bool indications and being defined for int, long and long long types rather than int32 and int64. See Checked Arithmetic Builtins.
There are also NSDecimal - a value type, and NSDecimalNumber - an object type built over the former. These provide both extended precision, up to 38 decimal digits, and control over overflow, underflow, divide-by-zero, etc. See NSDecimalNumberBehaviors and NSDecimalNumberHandler.
HTH

Objective-C floating point addition error [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Trouble with floats in Objective-C
I have broken this problem down to about as simple as i can get it. Feel free to try the same thing and tell me if you get the same error and what solution you might have. I have already tried it on several computers.
float total = 200000.0f + 154196.8f;
NSLog(#"total: %f", total);
The output is:
total: 354196.812500
If anyone has any sort of logical explanation, feel free to share it.
I'd suggest you brush up on your floats
http://www.altdevblogaday.com/2012/05/20/thats-not-normalthe-performance-of-odd-floats/
If you need higher precision use a double.
Additionally http://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2/
See What Every Programmer Should Know About Floating-Point Arithmetic for all the deep understanding. The short answer is that all floating point representations have limitations on their precision, and that things that can be expressed in a small number of digits in decimal may not be expressible in a small number of digits in binary (and specifically not in floating point formats).
Note that while double can improve things, it is no panacea. It is quite common to have small rounding errors, even with double. You may easily get 1.99999999 when you expect 2.
Hint:
long double total = 200000.0 + 154196.8;
NSLog(#"total: %Lf", total);
On my machine prints the correct value.
A 32 bit floating point has a 23 bit mantissa, the closest value is 0.5+0.25+0.125.
You should use more bits to get the correct representation.

How do I process enormous numbers? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Most efficient implementation of a large number class
Suppose I needed to calculate 2^150000. Obviously that number is going to exceed the size of an int, float, or double. How can I make a data type that allows normal math functions but exceeds the basic number types?
If this is a "depends which language you use" kind of deal. I will say C#.
See
Most efficient implementation of a large number class
for some leads.
If C# is not cast in stone, and you want something that just works out of the box, then there are several options. The one I know best is Python, but I think that languages like Scheme and Ruby support large numbers, too.
Python: 2**150000. Prints the result after about 1 second.
If you want free mathematics software, look at Maxima or Sage.
You might also consider using Frink, which is a language with the native capability of dealing with measurement units.
It computes 2^150000 without difficulty, deals with fractions (e.g. 1/3+2/5 --> 11/15), computes 3 meters + 2 inch --> 3.0508 m and is a full programming language.
Frink - Copyright 2000-2008 Alan Eliasen, eliasen#mindspring.com
http://futureboy.us/frinkdocs/
Several languages have built in support for arbitrary large numbers. You could use Mathematica, for example. I tried your example in Mathematica, and the result has 45,155 digits. I tried the same example with bc on a Unix machine. bc supports extended precision, but not that extended; it bombed on the example.
Lisp is your friend. Default biginteger numbers.
I find it very frustrating to use a language without arbitrarily large numbers: it seems nonsensical to be able to use ordinary operators like addition on most numbers, but to have to switch to method calls on a BigInt instance simply because of its size.
A whole bunch of languages have more complete numeric towers, and seamlessly coerce when needed; e.g., Allegro Common Lisp evaluates and prints all 45,155 digits of (expt 2 150000) in 1ms.
cl-user(2): (time (expt 2 150000))
; cpu time (non-gc) 0 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 0 msec user, 0 msec system
; real time 1 msec
; space allocation:
; 2 cons cells, 18,784 other bytes, 0 static bytes
There is a product in C called calc which is an arbitrary precision calculator. I used it once when working as a researcher and found it fairly straightforward to use...
http://sourceforge.net/projects/calc/
It can be programmed for difficult or long calculations and can accept arguments from the command line. In interactive mode, it accepts one command at a time, and displays the answer.
Ordinarily the commands are simply expressions such as:
3 * (4 + 1)
and calc will print:
15
Calc does the arithmetic operators +, -, /, * as well as ^ (exponentiation), % (modulus) and // (integer divide).
For example:
3 * 19 ^ 43 - 1
will produce:
29075426613099201338473141505176993450849249622191102976
Calc values can be VERY large. For example:
2 ^ 23209 - 1
will print:
402874115778988778181873329071 ... loads of digits ... 3779264511
Hope this helps...
I don't know C# but I do know the Ruby programming language has the BigDemical class that seems to allow numbers of unlimited size.
Python has a bignum library. If you need to implement a bignum library in another language you can at least use the Python one as reference for validating your work. Note that bignums have a few implementation gotchas that aren't immediately obvious if you don't know what you're looking for.