The Qt::Key enum has no number pad specific numeric definitions. So how would one go about distinguishing between a number pressed on the number pad vs a number on the number row? I know the events at the OS level are different.
Enter and Return on the other hand are separate keys.
Use keyPressEvent->modifiers().testFlag(Qt::KeypadModifier).
Related
Quick background - I want store every possible 5 character base 64 product. So, AAAAA, Afjsfs, 00ZZ0, etc.
I want to be able to grab 1000 of them randomly, then delete them from the DB so they're not used again.
Its trivial to generate and shuffle these. If I store them in an RDBMS, I could use an auto-inc Int ID, the first 1000, then delete the records. Assuming I put them in randomized, that totally works.
I'd like to see if its feasible to accomplish with DynamoDB, or if this problem is best left to RDBMS.
I could use an Int ID as the key, the 5 char string as the value, and do something similar.
Unless I'm misunderstanding, I can't just get walk keys and grab 1000 records can I? I need to provide a key. That sounds fine, except now I have to maintain DB state at the app layer or introduce another table just to keep track of the IDs I've iterated and deleted.
you can do the following:
(1) Each item will have a fixed partition key (that is same partition key value for all item. The exact value does not matter, as long as it is the same for all items, so let's assume it is simply the string "foo").
(2) The sort key will be a something random, for instance a randomly generated 32 bit integer.
(3) the 5-characters base 64 string will be stored in a third attribute (which is neither the partition nor the sort key)
when you want to grab 1000 random items you need to issue a DynamoDB query on partition key = "foo". Items returned from a query are sorted by the sort key. Since you chose a random sort key (see (2) above) you will get 1000 random items.
sort key considerations
the set of all 5 characters base 64 is a space of size 2^30. Thus your sort key needs to be large enough to store 2^30 items. So, pragmatically picking a random 32-bit int will be enough. However, if you need ensure that the selection of 1000 items is really really random you may want to pick something whose randomness is better than your runtime's random function. For instance, you can compute sha-384 on the base 64 value that you store and use it as the sort key value. The max length of a sort key is 1024 bytes so 384 bits is well within the limits.
In particular, do not use UUID as your sort key. UUIDs are typically not that random.
Not sure if this is the right subreddit to ask this question, but I will give it a shot. There is the ICAO standard for Machine Readable Zones as described here https://en.wikipedia.org/wiki/Machine-readable_passport. I don't see the point for check digits there.
If I have F instead of 5 for example in the MRZ code somewhere in the second line for example, all the checkdigits will be the same. What is the point in the first place for those check digits in the ICAO standard? Especially I don't see the point of the last check digits calculation since you could also calculate it by using the check digits from the second line and not all the letters/numbers.
Could someone explain why we need those checkdigits?
To be fair. This is not a subreddit. Anyway, there are multiple reasons that there are check digits inside the MRZ. The first reason is that automatic readers can check if the code is read well enough. The second reason is that it prevents a lot of fraud and identification theft. Some people that alter their travel documents do not know that there are check digits in place. So some people will get caught because they fail to edit the numbers.
Some countries now include PDF417 barcodes and/or QR-codes to reach better reads by machines. But keep in mind that not all governments/countries have access to high-tech devices, so the machine readable zone is still mandatory for a check with the naked eye.
Source: I work for a travel document verification company.
MRZ check digits are calculated on subsections of the entire MRZ. Each calculation serves as a check for each section. A final check digit is calculated on the sum of each sections and this digit serves as a double check of the individual check.
The below have same check digit of 8:
123456780
128456785
Whereas the subsection check digit matched after the tampering but the final check digit will detect this. Therefore, the final check digit adds additional robustness.
Although, I am wondering whether this visual check digit is mandatory because an eMRTD NFC chip BAC protocol also does a much stronger cryptographic check of the MRZ value.
UPDATES: My original claim that the composite check digit adds robustness to tampering is incorrect. Given the below TD1 MRZ:
IDSLV0012345678<<<<<<<<<<<<<<<
9306026F2708252SLV<<<<<<<<<<<4
JOHN<SMEAGOL<<WENDY<LIESSETTEF
An OCR scanner can either gave 0012345678 or OO12345678 for the document number portion and all check digits passes including the composite check digit. But there is no way to tell which document number is correct. It seems that an MRZ check digit has edge cases that cannot be helped.
What is the storage space for a number type in DynamoDB Number vs string type?
Say I have a number (1234789). If I store it as number type, then it will take just 4 bytes, and as string it will take 7 bytes?
Does DynamoDB stores all numbers as bigdecimal?
DynamoDb is a managed cloud service, so I think the way that they store data internally is not clear.
However, they transfer Numbers as Strings for language compatibility support and one of the things that affect RCU/WCU is transfer data size.
So, as far as your concern is about calculating provisioned throughput and costs, Number size should be considered as a String size.
As Per DynamoDB Documentation : Datatypes :
String
Strings are Unicode with UTF-8 binary encoding. The length of a string
must be greater than zero, and is constrained by the maximum DynamoDB
item size limit of 400 KB.
If you define a primary key attribute as a string type attribute, the
following additional constraints apply:
For a simple primary key, the maximum length of the first attribute value (the partition key) is 2048 bytes.
For a composite primary key, the maximum length of the second attribute value (the sort key) is 1024 bytes.
Number
Numbers can be positive, negative, or zero. Numbers can have up to 38
digits precision—exceeding this will result in an exception.
Positive range: 1E-130 to 9.9999999999999999999999999999999999999E+125
Negative range: -9.9999999999999999999999999999999999999E+125 to -1E-130
In DynamoDB, numbers are represented as variable length. Leading and
trailing zeroes are trimmed.
All numbers are sent across the network to DynamoDB as strings, to
maximize compatibility across languages and libraries. However,
DynamoDB treats them as number type attributes for mathematical
operations.
Note : If number precision is important, you should pass numbers to DynamoDB using strings that you convert from number type.
I Hope, this may help you get your answer.
My application requires a key value store. Following are some of the details regarding key values:
1) Number of keys (data type: string) can either be 256, 1024 or 4096.
2) Data type of values against each key is a list of integers.
3) The list of integers (value) against each key can vary in size
4) The largest size of the value can be around 10,000,000 integers
5) Some keys might contain very small list of integers
The application needs fast access to the list of integers against a specified key . However, this step is not frequent in the working of the application.
I need suggestions for best Key value stores for my case. I need fast retrieval of values against key and value size can be around 512 MB or more.
I checked Redis but it requires the store to be stored in memory. However, in the given scenario I think I should look for disk based key value stores.
LevelDB can fit your use case very well, as you have limited number of keys (given you have enough disk space for your requirements), and might not need a distributed solution.
One thing you need to specify is if (and how) you wish to modify the lists once in the db, as levelDB and many other general key-val stores do not have such atomic transactions.
If you are looking for a distributed db, cassandra is good, as it will also let you insert/remove individual list elements.
I want to generate unique random number sequence in QT, Using QDateTime::currentDateTime().toTime_t() as seed value, will qrand() generate unique random numbers?
No. qrand can only generate as many unique numbers as fit into an integer, so -- whatever the implementation -- you cannot count on uniqueness.
Also, knowing that a different seed creates a different random integer would yield a level of predictability that effectively makes qrand not random anymore.
Edit: I swear I'm not trying to make fun of you by posting a cartoon; I think this is a quite good explanation of the problem:
(source: dilbert.com)
Depending on how you store your session ids, you can generated a (mostly) guaranteed unique identifier by using a UUID. See the documentation for QUuid. Also be aware of this (bold added):
You can also use createUuid(). UUIDs generated by createUuid() are of the random type. Their QUuid::Version bits are set to QUuid::Random, and their QUuid::Variant bits are set to QUuid::DCE. The rest of the UUID is composed of random numbers. Theoretically, this means there is a small chance that a UUID generated by createUuid() will not be unique. But it is a very small chance.
I can vouch for the fact that those generated UUIDs won't necessarily be unique, so if you do need them to be unique, look into libuuid or something similar.
According to the Qt Documentation, QRand is just a thread-safe version of the standard rand(), I wouldn't assume the method used is any more secure/superior to that of rand() based on that description.
I think you need to use different terminology than 'unique' random numbers (no Psuedo-Random Number Generator will produce a unique stream, as input X will always produce output Y). What's the actual situation?