- Why study the Bible? What can we learn? - 1 Update
- The first non-duplicated letter in a string - 1 Update
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 01 02:57PM -0800 What is a Christian teaching like? It's all summed up from the realization: Christ's righteousness given to us, our sin given to Him https://twitter.com/DrStevenJLawson/status/826879446254809090 There cannot be better news than that. It is the gospel (the "good news"): The word "gospel" is Strong's 2098, euaggelion: http://biblehub.com/greek/2098.htm Short Definition: the good news, the gospel ----- To take the teaching a step further, so that it can be seen what it's like to honor God with your life, ask yourself the question: What exactly is it like to have a men's Bible Study? What goes on in those teachings? Is it just reading the Bible? Is there discussion? Is there a leader teaching? What is it? Here Dr. Lawson teaches Bible Stud on Romans 1:8-13. He puts the message of scripture into practical application in these, our modern lives: http://www.onepassionministries.org/the-mens-bible-study/2017/1/19/january-5-romans-18-15 Watch the video. This link's video is a little over an hour. And there are several more which follow. A life of knowing Jesus Christ as Savior and Lord awaits you. It begins with the first step. Thank you, Rick C. Hodgin |
| Tim Rentsch <txr@alumni.caltech.edu>: Feb 01 11:00AM -0800 > algorithm for. I assume that in many programs many strings are > sized well below 100'000 and use less than 1'000 of all the code > points of Unicode. Still more than enough for quadratic behavior to be slower than linear behavior, even if the linear behavior has a constant factor of 100. > I expected the brute force algorithm to be quite fast because it's > inner loop has high cache locality and perfect predictability of > its access pattern for the prefetcher. That doesn't matter nearly as much as how many times that loop is executed. In cases where the double loop algorithm is faster, it is faster because the inner loop isn't executed very many times. > Sometimes, RAND_MAX is as small as 32767, so this might not fill > the whole range of a tchar, which might have 32 bits, but then, > realistic data might not fill it either. Based on my tests, a smaller value of RAND_MAX will tend to be worse for the double loop algorithm, because duplicate values usually make it slow down. >> millionfold improvement? > When the string is small, the probability that some character is > unique is high and the outer loop can exit early. If the string is small (say, less than 25 characters), it won't matter if an O( n**2 ) algorithm is used. But even relatively short strings (a few hundred characters) can get bogged down, depending mostly on the characters. The relevant question is _where_ does the first unique character occur? If it's the first character in the string, the double loop algorithm is very fast. Somewhere up around the 20'th or 30'th character, the double loop algorithm starts to lose to the algorithms that go through the string a (small) fixed number of times. > usually small. Fancy algorithms have big constants. Until > you know that n is frequently going to be big, don't get fancy. > - Rob Pike This quote isn't really apt, because that isn't what's going on here. The double loop algorithm is faster _on some inputs_, but O( n**2 ) for other inputs, and even for shortish strings this matters. If it were known that all the inputs were 25 characters or less, the double loop algorithm would be fine. Above that, it depends on the strings in question. Here we may need a fancier (but still not all that fancy) algorithm not because of how large n is but because of what the input values might be. Insertion sort can be very fast on some inputs, but it still is a poor choice for more than a hundred elements or so. The same kind of reasoning applies to the find-first-unique question. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment