If I leave out the "INCREMENT BY" in a sequence, does it automatically just increment by one? I am realizing I checked in code to start a sequence and left out the "INCREMENT BY" statement. However, once I view the sequence in my schema, It shows the sequence is set to incrementing by 1. Just trying to figure out if I need to check out that code and make changes or is it fine.
As documentation says:
INCREMENT BY
Specify the interval between sequence numbers. This
integer value can be any positive or negative integer, but it cannot
be 0. This value can have 28 or fewer digits for an ascending sequence
and 27 or fewer digits for a descending sequence. The absolute of this
value must be less than the difference of MAXVALUE and MINVALUE. If
this value is negative, then the sequence descends. If the value is
positive, then the sequence ascends. If you omit this clause, then
the interval defaults to 1.
Related
Let's say I need to generate 100 numerical values. The value that is generated each time must be greater than or equal to the previous generated value. The issue is is that each individual value MUST be generated on the spot when needed, so we do not store any of the data. I have a solution using recursion, but the issue is is that if I want to generate the 100th value, it will have to recursively go through and generate and check all of the previous values, which you can imagine is terrible. The issue is further complicated by the fact that, if I'm generating the 100th value, I don't know for sure that the 99th value is accurate. Perhaps the 99th value is smaller than the 98th value, so the 99th value must do that check - so when generating the 100th value, we must not only check the 99th value, but potentially the 98th value, etc... Is there any way of solving this more eloquently without generating and storing all of the data before hand? Thank you!
The value that is generated each time must be greater than or equal to the previous generated value.
Just generate a random displacement from the previous value; like:
next_value = previous_value + get_random_value_from_zero_to_whatever();
previous_value = next_value;
The problem you need to worry about (regardless of how you do it) is exhaustion - what happens when the previous value was the highest possible value (e.g. INT_MAX if you're using int). Do you continually use the same highest possible value with no randomness at all (to avoid a smaller value), or...?
You actually only have to store one value, not all of them. The proof is by induction:
If you generate a value and it's the very first time, that value is trivially greater or equal to all previous
If you know the previously generated value v, which by induction is greater or equal to all previous values, then you merely have to generate a value larger than v for it to be greater or equal to all previous
You could also just generate 100 values and then sort them.
I had a telephone recently for a SE role and was asked how I'd determine if two words were anagrams or not, I gave a reply that involved something along the lines of getting the character, iterating over the word, if it exists exit loop and so on. I think it was a N^2 solution as one loop per word with an inner loop for the comparing.
After the call I did some digging and wrote a new solution; one that I plan on handing over tomorrow at the next stage interview, it uses a hash map with a unique prime number representing each character of the alphabet.
I'm then looping through the list of words, calculating the value of the word and checking to see if it compares with the word I'm checking. If the values match we have a winner (the whole mathematical theorem business).
It means one loop instead of two which is much better but I've started to doubt myself and am wondering if the additional operations of the hashmap and multiplication are more expensive than the original suggestion.
I'm 99% certain the hash map is going to be faster but...
Can anyone confirm or deny my suspicions? Thank you.
Edit: I forgot to mention that I check the size of the words first before even considering doing anything.
An anagram contains all the letters of the original word, in a different order. You are on the right track to use a HashMap to process a word in linear time, but your prime number idea is an unnecessary complication.
Your data structure is a HashMap that maintains the counts of various letters. You can add letters from the first word in O(n) time. The key is the character, and the value is the frequency. If the letter isn't in the HashMap yet, put it with a value of 1. If it is, replace it with value + 1.
When iterating over the letters of the second word, subtract one from your count instead, removing a letter when it reaches 0. If you attempt to remove a letter that doesn't exist, then you can immediately state that it's not an anagram. If you reach the end and the HashMap isn't empty, it's not an anagram. Else, it's an anagram.
Alternatively, you can replace the HashMap with an array. The index of the array corresponds to the character, and the value is the same as before. It's not an anagram if a value drops to -1, and it's not an anagram at the end if any of the values aren't 0.
You can always compare the lengths of the original strings, and if they aren't the same, then they can't possibly be anagrams. Including this check at the beginning means that you don't have to check if all the values are 0 at the end. If the strings are the same length, then either something will produce a -1 or there will be all 0s at the end.
The problem with multiplying is that the numbers can get big. For example, if letter 'c' was 11, then a word with 10 c's would overflow a 32bit integer.
You could reduce the result modulo some other number, but then you risk having false positives.
If you use big integers, then it will go slowly for long words.
Alternative solutions are to sort the two words and then compare for equality, or to use a histogram of letter counts as suggested by chrylis in the comments.
The idea is to have an array initialized to zero containing the number of times each letter appears.
Go through the letters in the first word, incrementing the count for each letter. Then go through the letters in the second word, decrementing the count.
If the counts reach zero at the end of this process, then the words are anagrams.
Or of all pairs formed by taking xor of all the numbers in a list.
eg : 10,15,17
ans = (10^15)|(15^17)|(10^17) = 31 . i have made an o(n*k) algo but need something better than that(n is number of entries and k is no. of bits in each number) .
It may be easiest to think in negatives here.
XOR is basically "not equal to"--i.e., it produces a result of 1 if and only if the two input bits are not equal to each other.
Since you're ORing all those results together, it means you get a 1 bit in the result anywhere there are at least two inputs that have different values at that bit position.
Inverting that, it means that we get a zero in the result only where every input has the same value at that bit position.
To compute that we can accumulate two intermediate values. For one, we AND together all the inputs. This will give us the positions at which every input had a one. For the other, we invert every input, and AND together all those results. This will tell us every position at which all the inputs had the value 0.
OR those together, and we have a value with a 1 where every input was equal, and a zero otherwise.
Invert that, and we get the desired result: 0 where all inputs were equal, and 1 where any was different.
This lets us compute the result with linear complexity (assuming each input value fits into a single word).
Lets say we have an integer array of N elements which consists of integers between 0 and 10000. We need to detect the numbers including a digit more than once e.g 1245 is valid while 1214 is not. How can we do this optimally? Thanks!
You need two loops. One loop you scan each element of the array.
In the inner loop, you determine if for the given element it's valid or not based on the criteria you indicated. To determine if a number has the same digit more than once, you need a routine that effectively extracts each digit one by one. I think the most optimal way to do that is to do "mod 10" on the number, then loop dividing the original by 10. keep doing that until you don't have number left (zero). Now that you have a routine for looking at each digit of an integer, the way to determine if there are duplicate digits the most optimally is to create an array of 10 booleans. Start with a cleared array. For every digit, use it as an index into the bool array and set it to true. If you see "true" again in that spot before you set it, that means that element in the bool array was visited before, thus it's a duplicate digit. So you break out of the loop altogether and say you found an invalid value.
I was going through this paper about counting number of distinct common subsequences between two strings which has described a DP approach to do the same. Now, when there are more than two strings whose number of distinct common subsequences must be found, it might take an approach different from this one. What I want is that whether this task is achievable in time complexity less than exponential and how can it be done?
If you have an alphabet of size k, and m strings of size at most n then (assuming that all individual math operations are O(1)) this problem is solvable with dynamic programming in time at most O(k nm+1) and memory O(k nm). Those are not tight bounds, and in practice performance and memory should be significantly better than that. But in practice with long strings you will wind up needing big integer arithmetic, which will make math operations not O(1). Still it is polynomial.
Here is the trick in an unfortunately confusing sentence. We want to build up a series of tables listing, for each possible length of subsequence and each set of ways to pick one copy of a character from each string, the number of distinct subsequences there are whose minimal expression in each string ends at the chosen spot. If we do that, then the sum of all of those values is our final answer.
Here is an outline of how to do it (which you can do without understanding the above description).
For each string, build a transition table mapping (position in string, character) to the position of the next occurrence of that character. The tables should start with position 0 being before the first character. You can use -1 for running off of the end of the string.
Create a data structure that maps a list of integers the same size as the number of strings you have to another integer. This will be the count of subsequences of a fixed length whose shortest representation in each string ends at that set of positions.
Insert as the sole value (0, 0, ..., 0) -> 1 to represent the fact that there is 1 subsequence of length 0 and its shortest representation in each string ends at the start.
Set the total count of common subsequences to 0.
While that map is not empty:
Add the sum of values in that map to the total count of common subsequences.
Create a second map of the same type, with no data.
For each key/value pair in the first map:
For each possible character in your alphabet:
Construct a new vector of integers to be a new key by taking each string, looking at the position, then taking the next position of that character. Of course if you run off of the end of the string, break out of the loop.
If that key is not in your second map, insert it with value 0.
Increase the value for that key in the second map by your current value in the current map. (Basically add the number of subsequences that just had this minimal character transition.)
Copy the second data structure to the first.
The total count of distinct subsequences in common across all of the strings should now be correct.