What's value of 1<<1? how to calculate it? [duplicate] - iphone

This question already has answers here:
What are bitwise shift (bit-shift) operators and how do they work?
(10 answers)
Closed 9 years ago.
Can any one tell me how to calculate value of 1<<0 and others ?
I am new to iOS and it's difficult for me to understand it.
kSCNetworkReachabilityFlagsTransientConnection = 1<<0,
kSCNetworkReachabilityFlagsReachable = 1<<1,
kSCNetworkReachabilityFlagsConnectionRequired = 1<<2,
kSCNetworkReachabilityFlagsConnectionOnTraffic = 1<<3,
kSCNetworkReachabilityFlagsInterventionRequired = 1<<4,
kSCNetworkReachabilityFlagsConnectionOnDemand = 1<<5, //

It's just a bit-shift operation.
1 << 0 = 1
1 << 1 = 2
1 << 2 = 4
1 << 3 = 8
etc...
or in binary view
00000001 << 1 = 00000010
00000001 << 2 = 00000100
00000001 << 3 = 00001000

This is left shift operator.
All the bits are shifted one place toward left. Resulting is *2 of the value by shifting value.
like
1<<3 will be 1*2*2*2=8, shifted 3 bits so three times *2

"<<" indicates left shift (in binary numbers). So 1 << n is the same as 2 to the power of n. However it is most appropriate to look at it in binary,
1<<0 = 1b
1<<1 = 10
1<<2 = 100

Related

How to read 19bits out of 3 bytes in Swift?

I have a Data object with 20 bytes that I'm getting from a BLE device.
This is an example when I po the data in the CBCharacteristic:
▿ 20 bytes
- count : 20
▿ pointer : 0x0000000282889ab0
- pointerValue : 10779925168
▿ bytes : 20 elements
- 0 : 16
- 1 : 0
- 2 : 0
- 3 : 21
- 4 : 0
- 5 : 0
- 6 : 20
- 7 : 3
- 8 : 87
- 9 : 154
- 10 : 3
- 11 : 88
- 12 : 204
- 13 : 20
- 14 : 255
- 15 : 197
- 16 : 7
- 17 : 159
- 18 : 56
- 19 : 122
Now I have instructions that tell me that on Byte 1,2,3 there is the signal that I'm looking for as 19 bits (0-524288)
So how can I get that signal value?
I would appreciate reading material on how to get this on my own if necessary. I don't have a proper CS background and I'm lost on how/where to even look for this.
Thank you
EDIT (in response to #Sweeper):
These are instructions for Byte 0
General state / configuration. Contains following bits:
7 (highest) – Error state, reads 0 normally and 1 if any error in hardware side
6 – button pressed (’1’ – button is pressed, ’0’ – button is not pressed)
5 – USB connected (’1’ – USB is connected, ’0’ – USB is not connected)
4 – Charging/charged (’1’ – Charging, ’0’ – not charging)
3 – Gain of channel A. 2 gains (0 is slower, 1 is higher)
2 – Gain of channel B. 2 gains (0 is slower, 1 is higher)
1 – Gain of channel C. 2 gains (0 is slower, 1 is higher)
0 – Gain of channel D. 2 gains (0 is slower, 1 is higher)
And by doing this I can get the expected data for the first byte:
guard let data = characteristic.value else { return }
guard data.count == 20 else { return }
let val = [UInt8](data)
let general:UInt8 = val[0]
let error = general >> 7 & 1
let buttonPressed = general >> 6 & 1
let usbConnected = general >> 5 & 1
let charging = general >> 4 & 1
let gainChannelA = general >> 3 & 1
let gainChannelB = general >> 2 & 1
let gainChannelC = general >> 1 & 1
let gainChannelD = general >> 0 & 1
Does this help in knowing the endianness of the protocol?
Since the data comes from multiple bytes, the answer depends on the endianness implied by the protocol. These 19 bits use two full bytes and three bits in a third byte.
If these three bytes are stored in unsigned 8-bit variables a, b, and c, the value would be either
Int(a) << 11 + Int(b) << 3 + Int(c) & 0x07
or
Int(c) << 11 + Int(b) << 3 + Int(a) & 0x07
values for a b and c would come either from bytes 1, 2, and 3 or bytes 3, 2, 1, depending on the order specified in the protocol.
Note: Expression x & 0x07 means "three lower bits", because 0x07 hex is 00000111 in binary.

How can I convert binary bits into index in MATLAB

I have a question regarding how to use the binary bits as an index in MATLAB, For example, if I'm using 4 antennas to transmit data, in each instant, one antenna or two are active to transmit the data. how can I use the indexing of antennas to transmit that symbol, here an example as below:
%Suppose I'm using for antennas to transmit that data.
Nt = 4; % Number of antennas
Symbole = 1+j; % The symbol to transmit in binary after modulation
Ant_index = 11; % The antenna index which will be used to transmit data. (here number 3 will be used)
x_trans =zeros(Nt,1); % Initialization of antennas
x_trans(Ant_index) = Symbole; %Use the antenna to transmit the data
My question is in the last step, x_trans(Ant_index) = Symbole;I want to use the binary bits as index, which means, instead of the bits Ant_index = 11 which means 3 in decimal, I want to use the two bits as antennas for transmitting the same symbol. for example if I have bits 0101 , It means I will use the antenna number 1 and number 3 to transmit the symbol in the same above example Ant_index = 0011. it means that first and second antennas will be used to transmit the Symbol.
EDIT:
Second part of question, what's about if the generated bits for antenna indexing are generated randomly. and we want to avoid having the Ant_index = 000; in other words, we need the Ant_index to be as decimal value, and then make mapping for 000 which is in decimal 0, the antenna 1 should be activated, 001 = 1 ---> antenna 2 should be activated. 010 = 2 ---> antenna 3 active, 011 = 3 ---> antenna 4 active. 100 = 4 ---> antennas 1 and 2 are active, 101 = 5 ---> antennas 1 and 3 are active, and so on.
Depending on the desired format of your input, you can use one of the 2 decimal to binary conversion function:
de2bi => return
an array of 0 and 1, representing the binary number.
dec2bin =>
return a string representation of the binary number.
Conversion:
I recommend using de2bi since an array will be easier to convert into indices. For example:
activate antenna 1 and 2 (3 decimal == 11 in binary):
>> de2bi(3) % index antenna 1 and 2 (`3` decimal == `11` in binary):
ans =
1 1
>> de2bi(10) % index antenna 2 and 4 (`10` decimal == `1010` in binary):
ans =
0 1 0 1
Note that by default de2bi return the binary representation in small endian bit ordering (the first element in the array represents the lowest bit). This is a bit the opposite of our visual convention, there is a parameter to reverse that, but for your purpose it is already exactly what we want. It saves us from reading the array from right to left or reversing it.
Indexing:
You said you have 4 antenna, but for this example I'll enlarge that a bit. Let's say you need to control 7 antenna. It would mean I always have to have an array of indices conataining 7 elements. No problem, de2bi allows you to specifiy the number of output digits. So again, to activate antenna 2 and 4 (out of seven):
>> Nt=7;
>> Ant_index = de2bi(10,Nt)
Ant_index =
0 1 0 1 0 0 0
with that you can directly use your index to transmit data:
x_trans(Ant_index) = Symbole;
Input format:
This is all and well if you know your elementary binary table up to your number of antenna. In case you want to be able to specify active antennas with a binary representation instead of a direct decimal number, you can use the reverse conversion function, more specifically bin2dec
So a last example to show you how they all work together:
>> stringAntIndex = '1010'
stringAntIndex =
1010
decimalAntIndex = bin2dec(stringAntIndex)
decimalAntIndex =
10
>> Ant_index = de2bi(decimalAntIndex,7)
Ant_index =
0 1 0 1 0 0 0
Which of course you could simplify to:
>> stringAntIndex = '1010' ;
>> Ant_index = de2bi(bin2dec(stringAntIndex),Nt)
Ant_index =
0 1 0 1 0 0 0
Edit: Ok I place the answer to your updated question here to finish it but note that your edited question is completely different than your original question. What you are asking now has nothing to do with converting bits into indices, it is just a straight mapping which you have to define before hand (since it doesn't follow any computation logic).
Basically, store your active antenna indices in a cell array, and pick the the cell corresponding to your randomly generated index (you'll have to add 1 because MATLAB starts array indices at 1, not at 0 like many other languages.
So:
% Map the antenna to be active depending on decimal input
Antenna2Activate = {
[1] ; % antenna 1 active
[2] ; % antenna 2 active
[3] ; % ...
[4] ; % ...
[1 2] ; % antenna 1 & 2 active
[1 3] ; % antenna 1 & 3 active
[1 4] ; % ...
[2 3] % antenna 2 & 3 active
};
% Then to activate the proper antenna given a decimal input [decimalInput]:
Ant_index = Antenna2Activate{ decimalInput+1 } ;
x_trans(Ant_index) = Symbole;
To make sure it works the way you want, you can run the following code:
decinput = 0:7 ;
for k=1:numel(Antenna2Activate)
Ant_index = Antenna2Activate{ decinput(k)+1 } ;
fprintf('Decimal input= %d \t Binary= %3s \t Ant_index: ',decinput(k),dec2bin(decinput(k),3))
disp(Ant_index)
end
Which yields:
Decimal input= 0 Binary= 000 Ant_index: 1
Decimal input= 1 Binary= 001 Ant_index: 2
Decimal input= 2 Binary= 010 Ant_index: 3
Decimal input= 3 Binary= 011 Ant_index: 4
Decimal input= 4 Binary= 100 Ant_index: 1 2
Decimal input= 5 Binary= 101 Ant_index: 1 3
Decimal input= 6 Binary= 110 Ant_index: 1 4
Decimal input= 7 Binary= 111 Ant_index: 2 3
You do ant_index = [0,0,1,1] for transmitting the symbol on antenna 1 and 2. Then do x_trans(ant_index == 1) = symbol. Hope that helps.

Hashtable open addressing handling probing cycles

I have been investigating various collision resolution techniques for hashtables implemented via open addressing. However, all the collision resolution methods I have investigated so far (linear probing, quadratic probing, double hashing) have the pitfall that there exists a probing sequence that produces a cycle whose length is less than the size of the table. This becomes problematic when you're trying to insert an element with the open addressing scheme because there are free buckets to insert an entry but they might not be reachable if they're not part of the cycle.
For example, if we're using linear probing on a table of size 12 with the linear function: H(k, i) = (h(k) + 4*i) mod 12 then a cycle would occur if a particular key hashes to 8 and all the slots 0, 4, and 8 are already filled:
H(k, 0) = 8 + 0 mod 12 = 8
H(k, 1) = 8 + 4 mod 12 = 0
H(k, 2) = 8 + 8 mod 12 = 4
H(k, 3) = 8 + 12 mod 12 = 8
H(k, 4) = 8 + 16 mod 12 = 0
H(k, 5) = 8 + 20 mod 12 = 4
H(k, 6) = 8 + 24 mod 12 = 8
...
Similar cycles can also be found with quadratic and double hashing if the probing sequence is bad, so my question then is how are cycles handled? Or do we always pick hash functions/special table sizes which do not permit cycles which are too short?

Overflow/underflow in unsigned numbers

So, if you have a carry out of 1 on addition with unsigned numbers, you have overflowed, and if you have a carry out of 0 with subtraction, you have underflowed. Does this work in every case, though?
If you do 5-0:
0101
-0000
=
0101
+(1111 + 1)
=
0101
+0000
= 0101... there is a carry out of zero here, instead of 1. How does one account for this case? Is there a different way to do it?
(using MIPS architecture, or anything else)
---Edit
Thanks Amadan. I understand that part, though. My problem is just that zero seems to be a special case. It does not seem to follow what normal numbers do: in my example above, there is no carry out of 1.
I'm doing circuit design working with an ALU at the moment and trying to implement the overflow detection, when this one case came up that doesn't follow what the others do.
We are assuming that with subtraction, the second operand is preinverted (twos complement) before going into the ALU (then added to the first operand). So, whenever the "invert_b" for subtraction is set to 1, b is inverted and we assume that the case we are checking for is subtraction, which should have a carry out of 1.
I believe the msbit carry out bit on its own covers unsigned and for signed you look to see if the carry in to the msbit and the carry out differ.
5-0 does not overflow because the result fits in the number of bits available. The same way that 15-1 does not overflow a 4 bit system for signed numbers
5 - 0 = 0101 + 1111 + 1
1
0101
+1111
=====
11111
0101
+1111
=====
0101
so 5 - 0 certainly carries out a 1, since this is a subtract that is not an overflow
15 - 1 = 1111 + ~1 with the carry in set
1
1111
1110
====
11111
1111
1110
====
1110
a subtract with a 1 out is not an unsigned overflow as you stated
Likewise -1 - 1 = 1111 + ~1 with the carry in bit set
11111
1111
1110
====
1110
the carry in to the last bit is a 1 the carry out is a 1 they match, no signed overflow.
8 + 8 = 1000 + 1000 with the carry in clear
0
1000
+1000
=====
10000
1000
+1000
=====
0000
unsigned overflow.
hmmm 4 + 4
0
0100
+0100
=====
01000
0100
+0100
=====
1000
unsigned add the carry out is 0 this is not an unsigned overflow. but this is a signed overflow because the carry in to the msbit and carry out differ. +4 + +4 = +8, in a 4 bit signed system you cannot represent +8, so the signed overflow is accurate.
No matter how many bits the weird numbers are all zeros and a one and the rest zeros, 0 and 8 or -8 for a 4 bit system.
Make a chart either with 2, 3, or 4 bit numbers all combinations and manually look through all of them to see that they make sense. whatever you find will scale no matter how many bits wide, a 100 bit adder works like a 10 bit adder...
add C V unsigned signed
00 + 00 = 000 0 0 0 + 0 = 0 0 + 0 = 0
00 + 01 = 001 0 0 0 + 1 = 1 0 + 1 = 1
00 + 10 = 010 0 0 0 + 2 = 2 0 + -2 = -2
00 + 11 = 011 0 0 0 + 3 = 3 0 + -1 = -1
01 + 00 = 001 0 0 1 + 0 = 1 1 + 0 = 1
01 + 01 = 010 0 1 1 + 1 = 2 1 + 1 = 2 signed cannot represent a +2
01 + 10 = 011 0 0 1 + 2 = 3 1 + -2 = -1
01 + 11 = 100 1 0 1 + 3 = 4 1 + -1 = 0 unsigned cannot represent +4
10 + 00 = 010 0 0 2 + 0 = 2 -2 + 0 = -2
10 + 01 = 011 0 0 2 + 1 = 3 -2 + 1 = -1
10 + 10 = 100 1 1 2 + 2 = 4 -2 + -2 = -4 neither +4 nor -4 will fit in 2 bits
10 + 11 = 101 1 1 2 + 3 = 5 -2 + -1 = -3 neither +4 nor -3 will fit in 2 bits
11 + 00 = 011 0 0 3 + 0 = 3 -1 + 0 = -1
11 + 01 = 100 1 0 3 + 1 = 4 -1 + 1 = -2 +4 does not fit in 2 bits
11 + 10 = 101 1 1 3 + 2 = 5 -1 + -2 = -3 neither +5 nor -3 fit in 2 bits
11 + 11 = 110 1 0 3 + 3 = 6 -1 + -1 = -2 6 does not fit in 2 bits
sub
00 - 00 = 100 0 0
00 - 01 = 011 1 0 0 - 1 = -1 -1 does not fit in an unsigned result
00 - 10 = 010 1 1 0 - 2 = -2 0 - -2 = +2
00 - 11 = 001 1 0 0 - 3 = -3
01 - 00 = 101 0 0
01 - 01 = 100 0 0
01 - 10 = 011 1 1 1 - 2 = -1 1 - -2 = 3
01 - 11 = 010 1 1 1 - 3 = -2 1 - -1 = 2
10 - 00 = 110 0 0
10 - 01 = 101 0 1 -2 - 1 = -3
10 - 10 = 100 0 0
10 - 11 = 011 1 0 2 - 3 = -1
11 - 00 = 111 0 0
11 - 01 = 110 0 0
11 - 10 = 101 0 0
11 - 11 = 100 0 0
The code that generated the above
printf("add\n");
for(ra=0;ra<4;ra++)
{
for(rb=0;rb<4;rb++)
{
rd=(ra&1)+(rb&1);
rc=ra+rb;
rd=(rd>>1)&1;
re=(rc>>2)&1;
if(re) c=1; else c=0;
if(rd!=re) v=1; else v=0;
if(ra&2) printf("1"); else printf("0");
if(ra&1) printf("1"); else printf("0");
printf(" + ");
if(rb&2) printf("1"); else printf("0");
if(rb&1) printf("1"); else printf("0");
printf(" = ");
if(rc&4) printf("1"); else printf("0");
if(rc&2) printf("1"); else printf("0");
if(rc&1) printf("1"); else printf("0");
printf(" %u %u\n",c,v);
}
}
printf("sub\n");
for(ra=0;ra<4;ra++)
{
for(rb=0;rb<4;rb++)
{
rd=(ra&1)+((~rb)&1)+1;
rc=ra+((~rb)&3)+1;
rd=(rd>>1)&1;
re=(rc>>2)&1;
if(re) c=0; else c=1;
if(rd!=re) v=1; else v=0;
if(ra&2) printf("1"); else printf("0");
if(ra&1) printf("1"); else printf("0");
printf(" - ");
if(rb&2) printf("1"); else printf("0");
if(rb&1) printf("1"); else printf("0");
printf(" = ");
if(rc&4) printf("1"); else printf("0");
if(rc&2) printf("1"); else printf("0");
if(rc&1) printf("1"); else printf("0");
printf(" %u %u\n",c,v);
}
}
Now your question was talking about unsigned numbers yes? so you may not care about the V bit nor the right half, the signed half.
Here is some HDL/RTL for a small 16 bit processor I implemented:
case 4b0000:
{
//0000 add rd,rs
op_a = bundle(1b0,reg[bundle(2b0,inst[4;8])].value);
op_b = bundle(1b0,reg[bundle(2b0,inst[4;4])].value);
op_res = op_a + op_b;
reg[1].value[CBIT] <= op_res[16];
reg[1].value[NBIT] <= op_res[15];
if(op_res[16;0] == 16h0000)
{
reg[1].value[ZBIT] <= 1b1;
}
else
{
reg[1].value[ZBIT] <= 1b0;
}
if((op_a[15] == op_b[15]) && (op_res[15] != op_b[15] ) )
{
reg[1].value[VBIT] <= 1b1;
}
else
{
reg[1].value[VBIT] <= 1b0;
}
reg[bundle(2b0,inst[4;8])].value <= op_res[16;0];
}
case 4b0001:
{
//0001 sub rd,rs
op_a = bundle(1b0,reg[bundle(2b0,inst[4;8])].value);
op_b = bundle(1b0,reg[bundle(2b0,inst[4;4])].value);
op_res = op_a - op_b;
reg[1].value[CBIT] <= (~op_res[16]);
reg[1].value[NBIT] <= op_res[15];
if(op_res[16;0] == 16h0000)
{
reg[1].value[ZBIT] <= 1b1;
}
else
{
reg[1].value[ZBIT] <= 1b0;
}
if((op_a[15] != op_b[15]) && (op_res[15] == op_b[15] ) )
{
reg[1].value[VBIT] <= 1b1;
}
else
{
reg[1].value[VBIT] <= 1b0;
}
reg[bundle(2b0,inst[4;8])].value <= op_res[16;0];
}
I have/had seen the msbit thing for signed overflow in other logic and couldnt find a case where it didnt match the carry in vs carry out method when trying every possible combination in a head to head analysis.
If I went overboard with the answer I dont mind clipping it off at the beginning where it shows that 5 - 0 has a 1 as a carry out of 1, which for a subtract is not an overflow. The long answer because it can be hard to wrap your head around signed vs unsigned and how the adder works in logic in general. The adder does not know or care about signed or unsigned, it does care about add vs subtract, with subtract you invert the second operand, invert the carry in to the lsbit and the carry out of the msbit (think about add, add with carry, sub and sub with carry). The signed vs unsigned takes care if itself (the beauty of twos complement). Reducing the above to an unsigned only discussion makes it more than half as simple as the signed overflow is not (as) obvious (as unsigned overflow) to the casual observer.
I sure hope I cut and pasted the debugged HDL , will get a lot of responses/corrections if I didnt...I spent a few days convincing myself of all of the above and comparing to the results of other processors I had access to, etc. Hopefully this saves you a few days.
Not an expert, but the whole statement on subtraction seems wrong.
You can implement subtraction in two basic ways: directly as subtraction, or as addition of two's complement.
If you go with two's complement addition, then it is as you say: carry of 1 is underflow.
5 - 6
= 0101 - 0110
= 0101 + (1001 + 1)
= 0101 + 1010
= (0)1111, carry 0 = underflow
If you subtract directly, then 1 carry is underflow:
0101 - 0110:
0 to 1 is 1
1 to (1)0 is 1, carry 1
1 + 1 to (1)1 is 1, carry 1
0 + 1 to (1)0 is 1, carry 1 = underflow
There may be other equivalent ways of designing overflow detection units for adders, but the most common is Cin XOR Cout. For example, see the end of lecture 4 http://cs.nyu.edu/~gottlieb/courses/2007-08-fall/arch/class-notes.html
It simply checks if the numbers being added (if something is inverted for 2's complement or not doesn't matter, we look at these values afterwards) carry in to the last digit's calculation but not into the digit beyond the supported bit-size, or the opposite.
This makes sense because if they carry in and not out the result must be negative (since the MSB must be 1) but the operands must be positive (since if they were negative there would be carry out). This is the definition of overflow, since two positives cannot sum to a negative.
This is a signed model however, I'm not sure if that's what you're looking for since you mentioned unsigned. If that's the case, then you're right, the simple addition model has overflow when carry out is 1 (this is equivalent to the above if you consider the addition to have an extra 0 for each operands' MSB, then the carry out will always be 0 and there's overflow iff the carry in is 1. The carry in in this case is the carry out in our model).
Subtraction results in underflow if the value is negative. We can again derive an equivalence if we consider the positive operand to have an appended MSB of 0 and the negative operand one of 1 (sign extension). Then we are negative when the MSB of the result is 1. This happens iff the carry out in our original model (the carry in in the new model) is 0, since only then will the MSB of the result in the new model remain 1.
You example is no exception: 0101 + 1111 + 1 = 0101 with a carry out of 1, and therefore no underflow, since the result is positive.

Converting numbers between Number Bases

I'm working on a program that converts between number bases. For example Octal is 8, decimal is 10. Letters A to Z could be considered as base 26.
I want to convert a number like "A" into 0, Z into 25, "AA" into 27 and "BA" into 53.
Before I start coding I'm doing it on paper so I understand the process. To start out I'm trying to convert 533 to base 26.
What algorithm is best for doing this?
You need to assign a "digit" to each letter, like:
A = 0 N = 13
B = 1 O = 14
C = 2 P = 15
D = 3 Q = 16
E = 4 R = 17
F = 5 S = 18
G = 6 T = 19
H = 7 U = 20
I = 8 V = 21
J = 9 W = 22
K = 10 X = 23
L = 11 Y = 24
M = 12 Z = 25
Then, your {20,13} becomes UN.
Converting back is UN -> {20,13} -> (20 * 26 + 13) -> 52.
By way of further example, let's try the number 10163, just plucked out of the air at random.
Divide that by 26 until you get a number less than 26 (i.e., twice), and you get 15 with a fractional part of 0.03402366.
Multiply that by 26 and you get 0 with a fractional part of 0.88461516.
Multiply that by 26 and you get 23 (actually 22.99999416 on my calculator but, since the initial division was only two steps, we stop here - the very slight inaccuracy is due to the fact that the floating point numbers are being rounded).
So the "digits" are {15,0,23} which is the "number" PAX. Wow, what a coincidence?
To convert PAX back into decimal, its
P * 262 + A * 261 + X * 260
or
(15 * 676) + (0 * 26) + 23
= 10140 + 0 + 23
= 10163
Let's take a step back for a second, and look at decimal.
What does a number like "147" mean? Or rather, what do the characters '1', '4' and '7', when arranged like that, indicate?
There are ten digits in decimal, and after that, we add another digit to the left of the first, and so on as our number increases. So after "9" = 9*1, we get "10" = 1*10 + 0*1. So "147" is 1*10^2 + 4*10 + 7*1 = 147. Similarly, we can go backwards - 147/10^2 = 1, which maps to the character '1'. (147 % 10^2) / 10 = 4, which maps to the character '4'. And 147 % 10 = 7, which maps to the character '7'.
This works works for any base N - if we get the number 0, that maps to the first character in our set. The number 1 maps to the second character, and so on until the number N-1 maps to the last character in our set of digits.
You convert 20 and 13 to the symbols that represent 20 and 13 in your base 26 notation. It sounds like you are using the letters of the alphabet so, that would be UN (where A is 0 and Z is 25).
What language are you writing this in? If you're doing this in Perl you can use the CPAN module Math::Fleximal that I wrote many years ago while I was bored. If you're using a language with infinite precision integers, then life becomes much easier. All you have to do is take characters, convert them into an array of integers, then do the calculation to turn that into a number.