Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
As a non-english speaker, I have trouble differentiating this.
When I try to translate this into my language, I get something weird like "go up" for ascending. So lets say I want to sort the names of all my pets alphabetically. I want that A comes first, then B, then C... and so on. So since the alphabet is not a number for me, my brain refuses to grok what's "going up". A = 0? B = 1? C = 2? If yes, then ascending would be what I'm most of the time looking for. Table would start showing A, then B, then C... Or is that the other way around? Must I look from the bottom of the table, up?
And with numbers: If it's an ascending order, the smallest comes first? (would seem logical...)
Can someone post a short but good example for what is an ascending sort order, and what is an descending sort order? And does that apply to whatever platform, programming language, API, etc.?
Perhaps this trick might help:
A scending
A B C D
D escending
D C B A
Perhaps Increasing(Ascending) vs Decreasing(Descending) is a better way for you to think of it?
Most of the time:
ascending : the order you would normally expect
descending : the reverse of what you would normally expect
Just think what order you would expect something to be sorted in if you just asked an intern to sort them without saying how. (numbers: smaller before larger, words: apathetically/lexicographically, etc.)
Think of everything as a number... Characters are represented by numbers as well, so:
A = 5
B = 6
Descending is biggest number first.
Ascending is smallest number first.
I always get confused with ASC/DESC for dates and times, however once you learn how datetime works, it's easy. A date is simply a number, it represents the number of seconds that have passed since a certain date, so the bigger the number is, the closer to now it is!
I get something weird like "go up" for ascending".
It's not weird... that's exactly what ascending means: that goes up (comes from the Latin word ascendere).
So, for numbers is: 1,2,3,4,5 ... for letters is just alphabetical order: A, B, C, D...
Ascending order of alphabets are like A, B, C, D . . . Z
Descending order of alphabets are like Z, Y, X, W . . . A
Bothe are defined by the collation sequence on your system. See the defintion of collation sequence here for example http://www-01.ibm.com/software/globalization/terminology/cd.jsp#c02
Related
I need a function that would compare two strings and outputs an edit distance like Levenshtein, but only if the characters are homoglyphs in cursives. I have a list of those homoglyphs so I could feed a custom list to this function.
Example
homoglyphs = [["o","a"],["rn","m","nn"],...] // In cursive they look-alike
compare("Mory", "Mary", homoglyphs) // Levenshtein gives 1
compare("Mory", "Tory", homoglyphs) // Levenshtein gives 1, but I want false, 99 or -1
compare("Morio", "Mario", homoglyphs) // I expect a distance of 1
compare("Morio", "Maria", homoglyphs) // I expect a distance of 2
Tory should give a false result since there's no way someone misread an M as a T. An A could be misread as an O so it can count as 1.
The scoring could be different, I just need to know that Mory is probably Mary not Tory and Morio is a little more likely to be Mario than Maria.
Do something like this exists?
The key to your problem can be thought of like an IQ word association question.
Sound Glyph
--------- = ----------
Homophone Homoglyphs
Now if you know that there is a way to find similar sounding words (homophone) then the same can be applied but instead of sounds change to glyphs (homoglyph).
The way to find similar sounding words is via Soundex (Sound Index).
So just do what Soundex does but instead of having a mapping from similar homophones use similar homoglyphs.
Once you convert each word (glyphs) input into a Glyphdex (Glyph Index) then you can compute the Levenshtein distance for the two Glyphdex.
Make sense?
If you are into cellular biology then codon translation into amino acids (ref) might make more sense. Many amino acids are coded by more than one 3 letter codon.
Note: Since the word glyhdex has been used prior to me writing this I can not say I coined that word, however the usage I currently find via Google (search) for the word are not in the same context as described here. So in the context of converting a sequence of glyphs into an index of similar sequence of glyphs I will take credit.
This question may sound mathematical, but it's more of a programming question related to discretization, so I decided to ask it here.
The problem is to find a 2nd order finite difference approximation of the partial derivative uxy, where u is a function of x and y.
Page 5 of this pdf I found does a centered difference approximation it in two steps. It first does the 2nd order centered finite-difference approximation of one of the partials, and then inserts the approximation of the second partial into it (using the same formula):
Inserting lines 2 and 3 into 1 gives (according to the pdf) the following:
The last O[(Δx)2,(Δy)2] is what I have a problem with. Notice that when the O(Δy)2 terms of lines 2 and 3 go into the numerator of 1, they are being divided by the Δx in the denominator. So how come the residual terms in line 3 are of O(Δy)2 instead of O(Δy2/Δx)? Would this be a '2nd order' approximation any more? (If, say, grid-spacing along both axes are the same (Δx=Δy=h), the term is of order h2/h =h, not h2.)
My suggestion would be to use a higher order approximation (3rd or more) in lines 2 and 3 in order to survive the division by Δx and still have the final expression in 2nd order. But I may be missing something here.
If I remember correctly, if you write more terms in the Taylor expansions, it quickly becomes obvious that the higher order terms cancel out. That is, that the "O(dy)^2 - O(dy)^2" that you'd get after substitution of (2) and (3) in the numerator of (1) actually does become zero.
You have two 1st order slopes that combined gives a 1st order plane. You are not gaining anything in terms of order by combining the two slopes to get (∂u/∂x)*(∂u/∂y).
This is still a 1st order approximation and if needed you will need to use more points into the finite difference to get higher order terms.
I think the notation of (∂²u/∂x∂y) is confusing the matter. Use the product of two 1st order operators to be more clear on what is going on.
I usually try not ask for homework help but once again I am stuck. I've been going over and over my textbook but I am not able to figure this out. Emailed the instructor and all the help i get is "Check this page" and "check that page", so instead of just not doing it, I would like some advice so I am actually able to learn.
The "G" gate thing, is whats bugging me in the book there is no gate that looks like that so i have no idea what to do. Here's a picture of the question, basically I have to find the X values (outputs). The answer would be nice. But I highly would appreciate a little explaination of "why".
Really appreciate the help!
Ok, so you you're not quite sure what this G gate means from looking at the diagram. In a question like this (where there's something that doesn't make sense to you), it's helpful to start with what you do know.
From looking at the diagram I don't know what the G gate means. In fact I don't know anything about circuits (but I do know something about logic :) ). I start with the truth table that the author has generously given me the formulas for each gate. I notice that there are 3 operators (*,+,') which I know.
If you know what those operators mean, then you can derive the meaning of the G gate.
D looks like an AND
E looks like NAND, the nipple-ish thing is an inverter
F looks like NOT, a buffer with an inverter on the output
G looks like a NOR, an OR with inverted output
The unlabeled one looks like an OR.
That's a really bad drawing though.
Giving you the answer would only cheat you out of your education and this stuff is important. There are 16 logical connectives for binary functions and they're all . . . logical. They make sense.
AND means when both inputs are true the output will be true. "If A and B = 1 output is 1"
OR means if any of the inputs are true the output will be true. "if A or B = 1 output is 1"
NOT means if the input is true the output is false.
XOR means if either input is true, but not both, the output will be true. "If A or B = 1 output is 1 unless both A and B = 1"
AND, OR, and XOR can all have inverters on their outputs which reverses their meanings. When they're supposed to output true they'll output false and when they're supposed to output false they'll output true.
The headings in the table are using * to mean AND, + to mean OR, and ' to mean "invert the symbol on the left".
D is A AND B, so if A and B are true, then put a 1 in the column, the rest of the column is false.
E is B NAND C, so if B and C are true, then put a 0 in the column, the rest of the column is true.
F is NOT C, so put the opposite of C in the column.
G is NOT((A AND B) OR (NOT C)), or if you look at the schematic and think about the formulas a bit you'll see that it's NOT(D OR F). You should be able to figure this out on your own now.
X is G OR E, There's a more complicated formula for it that traces through the circuit like the formula for G, but if you need it to prove your work you'll have to talk to your teacher. You'll probably get more help asking questions that show you put in effort.
I wrote an article about Logical functions in JavaScript that includes schematics. If you memorize the function tables at the top of the article it'll help you a lot when dealing with digital logic. Bonus points for associating the function number with the function name, you'll have memorized the output column of the functions truth table. They've taught you to count in binary right? Anyway, here's the article: http://matthewkastor.blogspot.com/2013/10/logical-functions-in-javascript.html It's not so important for your immediate question but will definitely do you good to read it. Oh, inputs can be inverted as well so don't let that throw you off.
I'm trying to create a "scrabble-solver" to run stress-tests on a scrabble-like game I'm developing. I have a database containing ~200.000 words and I'm now looking for a way to match the scrabble tiles given with the words in the database.
Example:
Given tiles: A, P, E, F, O, L, M
Result: APE, POLE, PALE, MOLE, PAL...
Is this possible by using a simple SELECT-statement with REGEXP? If possible I would also like to add letters on specific positions and be able to determine max/min length.
I hope this question made sense :)
I've been googling my eyes out but I can't seem to find what I'm looking for. Anyone got an idea?
Thanks! :)
It doesn't sound like a regex problem. I think you'll be better off simply creating all possible combinations of letters from the existing tiles and then running your SELECT statement with the IN clause. For example, with tiles:
A, P, E
your SELECT clause will be
SELECT word FROM words WHERE word IN ('APE', 'AEP', 'PAE' ,'PEA', 'EPA', 'EAP');
You'll get the list of valid words from your table.
A regex would not help you much in this case. You need to construct the possible words by yourself.
The problem is that you have a limited number of each possible letter and a regex cannot encode that information. If you had infinite supply of each letter, then you could use a regex like [APEFOI]*.
You will have to enumerate all the possible words yourself. The implementation would depend on the language your using, but your best bet might be a next_permutation function or better a function that enumerates all permutations. A simple (and slightly inefficient) implementation (in Python-like pseudocode) would be:
words = []
for permutation in permutations(letters): # enumerate all character orders
for i in range(1, len(permutation)): # enumerate all lengths of words
words.append(letters[:i]) # append to candidate set
At that point words will contain all the candidate words you would then use in a SELECT ... IN statement.
That isn't the most efficient approach, but should be practical enough to get you started.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Alright, so maybe I shouldn't have shrunk this question sooo much... I have seen the post on the most efficient way to find the first 10000 primes. I'm looking for all possible ways. The goal is to have a one stop shop for primality tests. Any and all tests people know for finding prime numbers are welcome.
And so:
What are all the different ways of finding primes?
Some prime tests only work with certain numbers, for instance, the Lucas–Lehmer test only works for Mersenne numbers.
Most prime tests used for big numbers can only tell you that a certain number is "probably prime" (or, if the number fails the test, it is definitely not prime). Usually you can continue the algorithm until you have a very high probability of a number being prime.
Have a look at this page and especially its "See Also" section.
The Miller-Rabin test is, I think, one of the best tests. In its standard form it gives you probable primes - though it has been shown that if you apply the test to a number beneath 3.4*10^14, and it passes the test for each parameter 2, 3, 5, 7, 11, 13 and 17, it is definitely prime.
The AKS test was the first deterministic, proven, general, polynomial-time test. However, to the best of my knowledge, its best implementation turns out to be slower than other tests unless the input is ridiculously large.
For a given integer, the fastest primality check I know is:
Take a list of 2 to the square root of the integer.
Loop through the list, taking the remainder of the integer / current number
If the remainder is zero for any number in the list, then the integer is not prime.
If the remainder was non-zero for all numbers in the list, then the integer is prime.
It uses significantly less memory than The Sieve of Eratosthenes and is generally faster for individual numbers.
The Sieve of Eratosthenes is a decent algorithm:
Take the list of positive integers 2 to any given Ceiling.
Take the next item in the list (2 in the first iteration) and remove all multiples of it (beyond the first) from the list.
Repeat step two until you reach the given Ceiling.
Your list is now composed purely of primes.
There is a functional limit to this algorithm in that it exchanges speed for memory. When generating very large lists of primes the memory capacity needed skyrockets.
#akdom's question to me:
Looping would work fine on my previous suggestion, and you don't need to do any calculations to determine if a number is even; in your loop, simply skip every even number, as shown below:
//Assuming theInteger is the number to be tested for primality.
// Check if theInteger is divisible by 2. If not, run this loop.
// This loop skips all even numbers.
for( int i = 3; i < sqrt(theInteger); i + 2)
{
if( theInteger % i == 0)
{
//getting here denotes that theInteger is not prime
// somehow indicate that some number, i, divides it and break
break;
}
}
A Rutgers grad student recently found a recurrence relation that generates primes. The difference of its successive numbers will generate either primes or 1's.
a(1) = 7
a(n) = a(n-1) + gcd(n,a(n-1)).
It makes a lot of crap that needs to be filtered out. Benoit Cloitre also has this recurrence that does a similar task:
b(1) = 1
b(n) = b(n-1) + lcm(n,b(n-1))
then the ratio of successive numbers, minus one [b(n)/b(n-1)-1] is prime. A full account of all this can be read at Recursivity.
For the sieve, you can do better by using a wheel instead of adding one each time, check out the Improved Incremental Prime Number Sieves. Here is an example of a wheel. Let's look at the numbers, 2 and 5 to ignore. Their wheel is, [2,4,2,2].
In your algorithm using the list from 2 to the root of the integer, you can improve performance by only testing odd numbers after 2. That is, your list only needs to contain 2 and all odd numbers from 3 to the square root of the integer. This cuts the number of times you loop in half without introducing any more complexity.
#theprise
If I were wanting to use an incrementing loop instead of an instantiated list (problems with memory for massive numbers...), what would be a good way to do that without building the list?
It doesn't seem like it would be cheaper to do a divisibility check for the given integer (X % 3) than just the check for the normal number (N % X).
If you're wanting to find a way of generating prime numbers, this have been covered in a previous question.