How to calculate check digits for a Hexadecimal IMEI (Number+Character) using luhn's algorithm? - luhn

I want to understand the logic so that I can implement this algorithm in java.
I want to calculate check digit for a valid hexadecimal IMEI number.
For example - 6C4BFFC0000004
Please help me with the algorithm.
I tried to find solution in google but I could not find correct answer using those algorithm.
Calculation what I did is like -
But the check digit for the above IMEI is 4. I am getting 7. I dont know where I am going wrong.

Actually, you do not need to convert to Decimal first. If you have an "IMEI" in hex it is really an MEID. IMEIs are a decimal-only subset of MEIDs. There is actually a patent out on how to calculate the Luhn for hex-based MEIDs. See claims 0113 through 0119 of the following:
https://patentimages.storage.googleapis.com/74/63/03/3fb507952c7ccf/US20080194223A1.pdf

I have had the same need and I found the solution by using the logic explained on the following website :
Luhn test of credit card numbers
I write a function based on the C example in order to determine the last digit. Behavior will be the same in Java.

Related

Variable Length MIDI Duration Algorithm

I'm trying to compile MIDI files, and I reached an issue with the duration values for track events. I know these values (according to this http://www.ccarh.org/courses/253/handout/vlv/) are variable length quantities where each byte is made up of a continuation bit (0 for no following duration byte and 1 for a following duration byte) and the rest of the number in a 7 bit representation.
For example, 128 would be represented as such:
1_0000001 0_0000000
The problem is that I'm having trouble wrapping my head around this concept, and am struggling to come up with an algorithm that can convert a decimal number to this format. I would appreciate it if someone could help me with this. Thanks in advance.
There is no need to re-invent the wheel. The official MIDI specification has example code for dealing with variable length values. You can freely download the specs from the official MIDI.org website.

Calculate pseudo random number based on an increasing value

I need to calculate a pseudo random number in a given range (e.g. 0-150) based on another, strictly increasing number. Is there a mathematical way to solve this?
I am given one number x, which increases by 1 every day. Based on this number, I need to - somehow - calculate a number in a given range, which seems to be random.
I have a feeling that there is an easy mathematical solution for this, but sadly I am not able to find it. So any help would be appreciated. Thanks!
One sound way to do that is to hash the number x (either its binary representation or in text form) and then to use the hash to produce the 'random' number in the desired range (say by taking the first 32 bits of the hash and extracting by any known method the desired value). A cryptographic hash can be used like Sha256, but this is not necessary, MurmurHash is possibly a good one for your application.
Normally when you generate a random number, a seed value is used so that the same sequence of psuedorandom numbers isn't repeated. When a seed isn't explicitly given, many systems will use the time as a seed value.
Perhaps you could use x as a seed.
Here's an article explaining seeding: https://www.statisticshowto.com/random-seed-definition/

Why is the "sign bit" included in the calculation of negative numbers?

I'm new to Swift and is trying to learn the concept of "shifting behavior for signed integers". I saw this example from "the swift programming language 2.1".
My question is: Why is the sign bit included in the calculation as well?
I experienced with several number combinations and they all works, but I don't seem to get reasons behind including sign bit in the calculation.
To add -1 to -4, simply by performing a standard binary addition of
all eight bits (including the sign bit), and discarding anything that
doesn't fit in the eight bits once you are done:
This is not unique to Swift. Nevertheless, historically, computers didn't subtract, they just added. To calculate A-B, do a two's-complement of B and add it to A. The two's-complement (negate all the bits and add 1) means that the highest order bit will be 0 for positive numbers (and zero), or 1 for negative numbers.
This is called 2's compliment math and allows both addition and subtraction to be done with simple operations. This is the way many hardware platforms implement arithmetic. You should look more into 2's compliment arithmetic of you want a deeper understanding.

MATLAB date number too short - how to get MATLAB to stop shortening my Serial Date Number

I need to extract the dates from a set of data s.
I use the command s(x).comm.date where x can be changed for each person however it is returning the serial date number as 7.3244e+005 which just gives me the day but I need it to show much more detail something like this 732162.65994213.
I don't know if the data I have is already saving it as the shorthand format but it's a set of data from MIT and the help documentation shows it as the long hand format so I sincerely doubt this.
Yours,
MATLAB Newbie
Try typing the following help format or format long (for starters).
By default, Matlab displays 5 significant digits (calculations are done in appropriate floating-point precision, no matter how those variables are displayed). Refer to the documentation for different ways of displaying.

Problem with very small numbers?

I tried to assign a very small number to a double value, like so:
double verySmall = 0.000000001;
9 fractional digits. For some reason, when I multiplicate this value by 10, I get something like 0.000000007. I slighly remember there were problems writing big numbers like this in plain text into source code. Do I have to wrap it in some function or a directive in order to feed it correctly to the compiler? Or is it fine to type in such small numbers in text?
The problem is with floating point arithmetic not with writing literals in source code. It is not designed to be exact. The best way around is to not use the built in double - use integers only (if possible) with power of 10 coefficients, sum everything up and display the final useful figure after rounding.
Standard floating point numbers are not stored in a perfect format, they're stored in a format that's fairly compact and fairly easy to perform math on. They are imprecise at surprisingly small precision levels. But fast. More here.
If you're dealing with very small numbers, you'll want to see if Objective-C or Cocoa provides something analagous to the java.math.BigDecimal class in Java. This is precisely for dealing with numbers where precision is more important than speed. If there isn't one, you may need to port it (the source to BigDecimal is available and fairly straightforward).
EDIT: iKenndac points out the NSDecimalNumber class, which is the analogue for java.math.BigDecimal. No port required.
As usual, you need to read stuff like this in order to learn more about how floating-point numbers work on computers. You cannot expect to be able to store any random fraction with perfect results, just as you can't expect to store any random integer. There are bits at the bottom, and their numbers are limited.