log.debug(new UnsychronizedStringBuffer("Found object ", objname, " with value:", foundThing.value()));
(And yes, you should also be using log.isDebugEnabled() if your logging facility has that)
The advantage of this idiom over
log.debug((new UnsychronizedStringBuffer(80)).append("Found object ").append(objname).append(" with value:").append(foundThing.value()));
is that you don't have to get that "80" constant right in order to avoid potentially expensive re-allocating.
Of course, at this point it might well be worth it simply to have a class with a static function called "BetterStringConcatenation" or similar which is overloaded similarly (i.e. to take a huge number of different objects) and simply returns the string made by concatentating the right ones together.
The step after that is to hack a java compiler (e.g., jikes) so that it uses your BetterStringConcatenation internally whenever + is used for string concatenation... hrm...
Interesting - I've seen this view expressed before, but not in a forum where I could easily reply.
Tell me - how does your reasoning apply to the current situation in Baghdad? Is the US military doing profoundly the wrong thing by instituting a strict law & order policy, whereas it would be better to let the chaos sort itself out? Does the distribution of weapons affect this? Does a history of living under a very repressive regime? Is perhaps your argument actually rooted strongly in the American frontier culture, and not translateable to regions that have been civilized (more or less) for millenia? What does Baghdad show us?
I've never seen an async or non-blocking API that's as simple and straight forward to use as select()
VMS's QIO subsystem was pretty sweet in this regard, and the TGV network stack made it easy to use QIO with TCP connections.
Of course, if you were using C your life was painful in general on VMS, as you were constantly reminded over and over again the different ways in which VMS was not unix, but if you were working in a more VMS-friendly language (like DECPascal) QIO rocked.
The template meta-program is an unfair comparison for another reason: it's using a completely different algorithm from the other code. Hell, I could beat the icc-compiled C code using perl if I used that algorithm.
To be fair, the template method needs to be compared to this java code:
Map fmap = new HashMap(100);
long fib(int i) {
if(i<=2) return 1;
Integer key = new Integer(i);
Long res = fmap.get(key);
if (res == null)
{
fmap.put(key, res = new Long(fib(i-1)+fib(i-2));
}
return res.longValue(); }
And similar C code to be compiled with icc or gcc.
For extra speed on the java side, you might even try storing the result in one of those fancy new LongBuffer objects, or, since here we have a limit on what we're calculating, a simple long array.
But at this point it's silly - template metaprogramming wins here because it is (behind the scenes) using a better algorithm.
Which, I suppose would not be an overly bad lesson to take away from this: templates can do things faster because they transform into better algorithms behind the scenes. However, even though I believe that statement to be true generally, I still think that this example is cheating, as the memoizing that templates do for you is often not going to be what you want.
For reference, the perl that uses this is:
my %fmap=(); sub fib {
my $i = shift;
if ($i <= 2) {return 1;}
return ($fmap{$i} or
$fmap{$i} = fib($i-1) + fib($i-2)); }
print fib(45),"\n";
Toward a bittorrent discovery protocol
on
BitTorrent Guide
·
· Score: 1
So in order for this to work we need to have a way for the browser to automatically discover that a certain page (or at least the content it links to inline, like.avi files or.jpg files) is available via bittorrent.
There are a three different ways to do this that I see right away:
One way is to have a special <meta> tag in the page header which says "look at the.torrent file located at _href_ for a list of the files linked to by this page".
We could also design a special content type and just wrap files which should be bittorrent'ed in <object> tags, and place a regular object or img tag inside.
And finally, there's the method mentioned elsewhere here: let "bittorrent" become an acceptable content-transfer-encoding and have a mod_torrent module for Apache that will transmit a dynamically created.torrent file for files over a configured size.
While the second option is arguably using all of the w3c's carefully spec'ed out extension mechanisms in the proper manner, the last option has a lot to recommend it - it's largely automatic to the page creator once installed on the server; it's also something that could be configured to only activate when load exceeds a certain value.
On the other hand, the first option could be very useful on a page that had, instead of a single 30 Mb file, 300 100 kb files (because then the page could advertise one bittorrent archive of all the linked files). Doing that nicely with mod_torrent would be extremely tricky.
Unfortunately, the.torrent file format really is designed only for large files or file archives (think.tar files) - it doesn't carry information about the original URL easily in the archive, making the first option rather kludgey. (Though I suppose, given the rather extensible nature of the format, this could easily be added, or a base href could be given in the <meta> tag)
So - thoughts on this? Which way addresses best the problems that it's reasonable to throw bittorrent at? Also, which is easiest to get into the browsers?
Python's not some obscure scripting language. Lua might qualify as "some obscure scripting language". Maybe you could also qualify pike as "some obscure scripting language".
But in any case, the BitTorrent developers completely document their protocol at the network level; for example, nothing depends on how Python serializes or deserializes a certain structure - it's all specified in terms of bytes carried in standard IP packets.
Another post has given criterion 3 the name "the greedy choice property". I like that name, and in the spirit of that name propose the name "the strong greedy choice property" for criterion 4.
There's also another property of coinage systems that might be interesting to look at: that of unique optimal solutions. This is best illustrated by counterexample:
The system [1,4,10,25] satisfies the greedy choice property (but not the strong greedy choice property), but not the uniqueness property, since there are two optimal ways to make 12 cents: 10+1+1 and 4+4+4.
I think that the strong greedy choice property might imply unique optimal solutions.
I'm pretty sure that [1,5,10,25] satisfies the uniqueness property, but I haven't looked at it rigorously.
with denominations that do not divide evenly into each other it is non-trivial to find the optimal change for a given transaction.
What you really mean is "with coinage denomination systems which do not satisfy the greedy choice property, finding optimal change is non-trivial".
As you show, the current US coinage system satisfies the greedy choice property. However, the denominations do not divide into each other evenly. (25 % 10 != 0)
Having denominations divide into each other is sufficient for satisfying greedy choice, but not necessary. [1, 4, 10, 25] also satisfies greedy choice, and there none of the denominations except 1 divide any of the other denominations evenly. (Incidentally, [1,4,10,25] is also an improvement on the current system, in the sense of the paper)
Current system still not optimal
on
Making Change
·
· Score: 1
Our current system still isn't optimal, (in the narrow sense of fewest coins used) even under those constraints.
Using denominations of 1, 5, 10, and 25, making each change value from one cent to one dollar requires a total of 474 coins (470 if you say that making one dollar requires zero coins).
However, if you knock it back to 1, 4, 10, and 25, you can do it in 430 (426 without the dollar) coins.
Even 1,4,10,20 beats our current system.
Here's the perl code I used to play around with this:
print "For @denoms we need a total of $sum coins\n";
This code does almost no input validation or anything like that, though it does force the inclusion of a penny. I have no idea how it'll behave if handed non-integral values.
This code also requires that the coinage system be a "good" system, satisfying criterion 3 of my other post; otherwise, it might overcount the number of coins required.
Nice second point there
on
Making Change
·
· Score: 1
About the difficulties involved in making change with a small stock of coins.
That's definitely a refinement that needs to be made to this model, even if we make the (blatantly false, but false in a way that leads to interesting research) assumption that human brains do integer operations with the same speed tradeoffs as binary computers.
I'm not quite certain how you'd model this, and how you'd measure the "small coin stock robustness" of a coin denomination system, but it's definitely at least as interesting a problem as the original.
The musings I've had about coinage systems
on
Making Change
·
· Score: 1
I've occasionally looked at coinage systems and pondered about what makes for a "good" change system. Here's the conditions I've come up with:
1. Any combination of coins should represent a reasonable amount of currency. 2. A change system must be able to represent any reasonable non-negative amount of currency.
For all the definitions of reasonable that I'm likely to use, the first condition is equivalent to "all coins values are a positive integer number of cents" (i.e. no hay-pennies, and no coins that have negative value); the second is equivalent to requiring a penny.
3. It should be possible to figure out the best way to make change (meaning, fewest coins used) in a "good" system by following this naive greedy algorithm: first give out as many of the largest denomination as possible without exceeding the total you want to give out, then as many of the next largest, etc.
4. (a refinement) In a "really good" change system it should be possible to use an even more naive algorithm; this algorithm is best demonstrated in pseudocode:
for (i=0; i < NUMBER_OF_COIN_TYPES-1; i++) {
coins_to_return[i] = (change_amount % denomination[i+1]) / denomination[i]; } coins_to_return[i] = change_amount / denomination[i];
Note that our current system satisfies criterion 3, but not criterion 4. Our current system without the quarter (but with the half dollar) satisfies criterion 4. An example of a system that does not satisfy criterion 3 is [1,5,10,18]. (In that system, the naive greedy algorithm would make 20 as 18+1+1, whereas 10+10 uses fewer coins)
It's easy to show that satisfying criterion 4 implies satisfying criterion 3. It's also pretty easy to show that a sufficient condition for criterion 4 is
denomination[i+1] % denomination[i] == 0
for all i so that the indices make sense.
However, what I've never really sat down to work on (*) is whether this condition is really necessary for criterion 4, and what necessary and sufficient conditions are for criterion 3.
Efficiency in terms of numbers of coins used never even occurred to me, though I'm sure it would have if I lived in a country with a purely decimal coinage system (i.e. just penny, dime, and dollar coins)
(*) Or if I have, I've forgotten. I tend to do that when I don't write stuff down.
If Microsoft would let companies re-distribute their automatic patches within their own organization, or allowed OEMs to distribute these to their customers, you might see this.
The kind of innovation you're talking about requires lots of experiments, false starts, and playing with things to get it developed properly.
Unfortunately, the "only download and run this, do NOTHING else" nature of their standard EULA crushes the spirit of this innovation. I can't just go and start up a project to distribute Microsoft patches via bittorrent, for example. Even assuming I worked for a company big enough to negotiate different EULAs with Microsoft, I'd have to go to the suits and ask them to add this permission into the negotiations, and then I'd have to make up a business case for it, etc. All of which distracts from implementing the prototype.
Sure, any production-quality, successful large scale result of this kind would involve enough planning and development time that going to the suits wouldn't be terrible overhead. However, before that happens, you need a working toy. These toys aren't getting built because Microsoft restricts how and when updates happen.
It's a darn shame that you can't send someone slashdot messages, but I have to ask - what are you trying to do that's failing? I couldn't remember java 1.3 being broken in this fashion, so I wrote a little test program, and it seems to work just fine:
import java.net.*;
public class printURL { static void main(String argv[]) throws Exception { URL u = new URL(argv[0]); URLConnection urlc = u.openConnection(); urlc.setRequestProperty("X-Whatever", "WhichEver"); if (argv.length > 1) urlc.setRequestProperty("User-Agent", "Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2.1; MultiZilla v1.4.0.3J) Gecko/20030425"); java.io.InputStream is = urlc.getInputStream(); java.io.Reader rdr = new java.io.InputStreamReader(is); int ch; for (ch = rdr.read(); ch != -1; ch = rdr.read() ) { System.out.print((char)ch); } } }
When I run this against a cgi script that just prints out what you send it (printenv.pl from a recent apache distribution), it clearly shows that the user agent is Java1.3.1 without that "setRequestProperty" line, and is what I say (I just copied what my browser says) with it.
What are you doing?
I'd take this off slashdot, but you give no way of contacting you in your slashdot profile.
There's a cure for that, by the way: Effective C++ by Scott Meyers. It really is exactly the thing to fix up one's C++ knowledge to what's current (I learned C++ back in 1995, using books that were already over a year old then, and compiler versions that were at least three years old).
This reminds me that I should go ask the co-worker who's been borrowing it for six months now to return it...
Good idea. I am forced to use 1.3 for a project, and would love to be able to steal classes from later versions. We moved to 1.3 to get HTTP 1.1 support, but our production environment would have been greatly simplified if we had stayed with 1.2.
When we were faced with the same problem, we just went and used HTTPClient. Similarly, when we needed regexps in 1.3, we just went for the Jakarta ORO library. (And even in our java 1.4 environment, we're still using log4j)
Sure, it would be nice if Sun split the standard library from the runtime engine, but third-party java libraries are plentiful and can often cover the gaps. Also, if there's some new feature in a higher java revision that you can't live without, you might want to first check whether Sun also released a version of this feature that's compatible with the java version you're stuck with. (e.g. JSSE for java 1.2)
It's not that those bad habits are encouraged by VB, it's that they aren't forcefully discouraged strongly enough.
I've occasionally watched my father's students (he teaches part-time at a local community college) struggle with their first VB programs. As I see it, the problem with VB is that the pattern of "debugging by random code modification" so often works, or at least doesn't throw up errors when run. (Though some errors might be thrown up when the project is compiled; in VB "run mode", as with many classic BASIC variants, code paths that aren't traversed aren't even checked for syntax errors) This is partially due to VB being an extreme DWIM language. (e.g. automatic conversions between numbers and strings that even make perl programmers cringe)
But the tendency to just pound out spaghetti logic and then tweak it until it works is something that the students bring with them to the lab before they've ever used VB themselves.
Some of their behavior reminds me of TAing calculus students. They fundamentally don't want to learn what's going on, they just want to get the answer/get the project to work and be done with it. Even if you can get them to realize intellectually that a deeper understanding would allow them to finish their assignments faster, the strong gut reaction against figuring out what's going on remains.
The odd thing is that every so often I would find a student who was perfectly happy to learn the what was really going on, and get the deeper understanding that would have helped them, but only after fighting through the assignment the hard way.
I don't mean to imply by this that the vast majority of the calc. students I TAed (or those taking my father's VB class) are lazy; I think this may have something to do with the nature of how people learn new concepts. It may be orders of magnitude more difficult to learn high-level concepts without concrete experience to which one can relate those concepts. It almost makes me want to track down an education major and ask them about what the current theories say.
The problem with VB is that there is almost no incentive to go back and learn the "proper" way to do things after you've slogged through. The rapid increase in expressive power that one gains in most languages by taking the time to wrap one's brain around the language isn't really there in VB. VB, by design, makes certain that a muddled first-glance understanding is "good enough", so that's where many people stay.
I know this is hindsight, but consider this: if you are planning backups, and are planning them so that your systems will still operate if the building you're in falls over (which, after the 1993 bombing attempt, anyone in the WTC should have been doing), wouldn't you want to place the backups far enough away so that the building the main system is in can't possibly fall on the building the backup is in?
I know that's not what happened on 9/11, but shouldn't that scenario have been considered?
Besides, why waste WTC rental money housing backup systems? Surely there's cheaper land out on Long Island or across the river in Jersey.
Housing backup systems in the other tower was expensive flashiness that could never have been expected to provide bomb-proof systems.
This is already a feature of Conquest: (from the linked page, bold emphasis my own doing)
Conquest uses memory to store all metadata, small files (currently based on a size threshold), executables, and shared libraries, leaving only the content of large files on disk. All accesses to in-core data and metadata incur no data duplication or disk-related overhead, and executions are in-place. For the large-file-only disk storage, we use a larger access granularity to reduce the seek-time overhead. Because most accesses to large files are sequential, we can relax many historical disk design constraints, such as complex layout heuristics intended to reduce fragmentation or average seek times.
Actually, as of Python 2.2, with nested scopes implemented, g() can really access the variable outside its own scope.
The problem though is similar to what you alluded to with passing variables into functions and wanting the functions to modify them; when in the inner function you say "x = 50", you're rebinding the local-to-g version of x. The end result is that the outer x is then not repointed to the new object. (See the PEP for why, or look at the appropriate part of the "what's new" document)
In any case, this will work in Python 2.2, or in Python 2.1 that uses the proper "from __future__" construct:
I don't know where you've been, but cable companies haven't been able to charge per-TV in years, anywhere. In fact, the per-TV issue is right now one of the big advertising points the cable giants are using in the ad. campaign against satellite.
It's not that hard, really. And, if you think it is some great deep programming secret, you're going to be disappointed when you actually go look at a quine and see how it's done. A certain classic Turing Award acceptance speech starts off the speech with probably one of the easiest-to-understand quines there is.
Now go away and do it yourself, in some language. The end of this post is going to contain a quine-like construct, and I'd hate to give the secret away to someone who still wanted to discover it themselves.
Quines, or rather quine-like logic, do have actual current applications, though I can't think of one off the top of my head that isn't malicious.
Assuming this'll get past the lameness filter, here's a short piece of code that you should never, ever, ever execute on a lambda-derived moo. Ever. It's essentially a one-line fork bomb. The only way I know of killing it is by temporarily disabling $string_utils:print. It's technically not a quine, though its core is certianly quine-like.
;for i in ({1}) pre="for i in ({1}) pre="; a="; a = pre + $string_utils:print(pre) + \"; a= \" + $string_utils:print(a) + a; for d in ({1, 2}) fork foo (5) eval(a); endfork endfor endfor"; a = pre + $string_utils:print(pre) + "; a= " + $string_utils:print(a) + a; fork foo (5) me:notify("first: a is " + a); me:notify($string_utils:print(eval(a)));endfork; endfor
In fact just recently I wrote a one-off script here that did essentially what this PHP script does - it takes data out of a local sybase db and reformats it as a bunch of SQL statements. (We don't have direct access to the database into which this needs to be loaded, so there needs to be an intermediate form anyway)
I suppose this _might_ be worth a post on perlmonks, as an example of using the DBI, (and of working around the fact that DBD::Sybase doesn't really implement column_info) but not much more than that.
This code generates an SQL load file for each table that has a column named "DataSrcId" where that column has the value "35". It also substitutes the value 'guy' for any column named 'AudUsrId' and does not include any column named 'AudTmst' in the load output. As I said, it's a one-off hack.
foreach my $table (@tables) { $dbh->{PrintError} = 0; my $teststatement = $dbh->prepare("SELECT max(DataSrcId) FROM $table WHERE DataSrcId = 35"); $teststatement->execute; if ($teststatement->err) {next;}
$dbh->{PrintError} = 1; print "-- for $table \n"; dumpstatement($table, "SELECT * FROM $table WHERE DataSrcId = 35"); }
By the way - slashdot inserts an extra ";" in this code, even though it is NOT there in what I copy/paste in. Go figure.
No, primary and secondary schools are designed to shift responsibilities for children off of the parents' backs, so they have someone else to blame when their child doesn't turn out to be Superman and/or Wonderwoman.
I keep hearing (mostly on slashdot) some people complain that they are shut out of CS degrees because of an inability or unwillingness to get through the requisite math courses.
I must say that I have a very difficult time believing this, but under the weight of so many complaints I am willing to concede that my judgement may be off on this point.
However, the parent post's comment about "vb weenies who are gifted in mathmatics" has me intrigued. I've never seen one of these - what do they look like? I've seen vb weenies with a BA in Economics and even once with some sort of two-year accounting degree, but neither was what I'd call particularly skilled in mathematics. What mathematics they knew was rote memorization of the kind that can often get you through calculus (these days), but not far beyond.
So what does a vb weenie gifted in mathematics do? What is the characteristic of their programming style that one can point to and say "See, this bad practice? That's the sign of a mathematically gifted vb weenie." ?
I'm especially curious about people who fit this pattern with bachelor's degrees in mathematics, computer science, or one of the natural sciences.
Slashdot Mirror
In trade, one thing you might consider allowing is several constructors of the form:Then, you could replace common idioms like this:with:(And yes, you should also be using log.isDebugEnabled() if your logging facility has that)
The advantage of this idiom overis that you don't have to get that "80" constant right in order to avoid potentially expensive re-allocating.
Of course, at this point it might well be worth it simply to have a class with a static function called "BetterStringConcatenation" or similar which is overloaded similarly (i.e. to take a huge number of different objects) and simply returns the string made by concatentating the right ones together.
The step after that is to hack a java compiler (e.g., jikes) so that it uses your BetterStringConcatenation internally whenever + is used for string concatenation... hrm...
Interesting - I've seen this view expressed before, but not in a forum where I could easily reply.
Tell me - how does your reasoning apply to the current situation in Baghdad? Is the US military doing profoundly the wrong thing by instituting a strict law & order policy, whereas it would be better to let the chaos sort itself out? Does the distribution of weapons affect this? Does a history of living under a very repressive regime? Is perhaps your argument actually rooted strongly in the American frontier culture, and not translateable to regions that have been civilized (more or less) for millenia? What does Baghdad show us?
I've never seen an async or non-blocking API that's as simple and straight forward to use as select()
VMS's QIO subsystem was pretty sweet in this regard, and the TGV network stack made it easy to use QIO with TCP connections.
Of course, if you were using C your life was painful in general on VMS, as you were constantly reminded over and over again the different ways in which VMS was not unix, but if you were working in a more VMS-friendly language (like DECPascal) QIO rocked.
To be fair, the template method needs to be compared to this java code:And similar C code to be compiled with icc or gcc.
For extra speed on the java side, you might even try storing the result in one of those fancy new LongBuffer objects, or, since here we have a limit on what we're calculating, a simple long array.
But at this point it's silly - template metaprogramming wins here because it is (behind the scenes) using a better algorithm.
Which, I suppose would not be an overly bad lesson to take away from this: templates can do things faster because they transform into better algorithms behind the scenes. However, even though I believe that statement to be true generally, I still think that this example is cheating, as the memoizing that templates do for you is often not going to be what you want.
For reference, the perl that uses this is:
There are a three different ways to do this that I see right away:
While the second option is arguably using all of the w3c's carefully spec'ed out extension mechanisms in the proper manner, the last option has a lot to recommend it - it's largely automatic to the page creator once installed on the server; it's also something that could be configured to only activate when load exceeds a certain value.
On the other hand, the first option could be very useful on a page that had, instead of a single 30 Mb file, 300 100 kb files (because then the page could advertise one bittorrent archive of all the linked files). Doing that nicely with mod_torrent would be extremely tricky.
Unfortunately, the
So - thoughts on this? Which way addresses best the problems that it's reasonable to throw bittorrent at? Also, which is easiest to get into the browsers?
But come on.
Python is "some obscure scripting language"?
Python's not some obscure scripting language. Lua might qualify as "some obscure scripting language". Maybe you could also qualify pike as "some obscure scripting language".
But in any case, the BitTorrent developers completely document their protocol at the network level; for example, nothing depends on how Python serializes or deserializes a certain structure - it's all specified in terms of bytes carried in standard IP packets.
Another post has given criterion 3 the name "the greedy choice property". I like that name, and in the spirit of that name propose the name "the strong greedy choice property" for criterion 4.
There's also another property of coinage systems that might be interesting to look at: that of unique optimal solutions. This is best illustrated by counterexample:
The system [1,4,10,25] satisfies the greedy choice property (but not the strong greedy choice property), but not the uniqueness property, since there are two optimal ways to make 12 cents: 10+1+1 and 4+4+4.
I think that the strong greedy choice property might imply unique optimal solutions.
I'm pretty sure that [1,5,10,25] satisfies the uniqueness property, but I haven't looked at it rigorously.
with denominations that do not divide evenly into each other it is non-trivial to find the optimal change for a given transaction.
What you really mean is "with coinage denomination systems which do not satisfy the greedy choice property, finding optimal change is non-trivial".
As you show, the current US coinage system satisfies the greedy choice property. However, the denominations do not divide into each other evenly. (25 % 10 != 0)
Having denominations divide into each other is sufficient for satisfying greedy choice, but not necessary. [1, 4, 10, 25] also satisfies greedy choice, and there none of the denominations except 1 divide any of the other denominations evenly. (Incidentally, [1,4,10,25] is also an improvement on the current system, in the sense of the paper)
Using denominations of 1, 5, 10, and 25, making each change value from one cent to one dollar requires a total of 474 coins (470 if you say that making one dollar requires zero coins).
However, if you knock it back to 1, 4, 10, and 25, you can do it in 430 (426 without the dollar) coins.
Even 1,4,10,20 beats our current system.
Here's the perl code I used to play around with this:This code does almost no input validation or anything like that, though it does force the inclusion of a penny. I have no idea how it'll behave if handed non-integral values.
This code also requires that the coinage system be a "good" system, satisfying criterion 3 of my other post; otherwise, it might overcount the number of coins required.
About the difficulties involved in making change with a small stock of coins.
That's definitely a refinement that needs to be made to this model, even if we make the (blatantly false, but false in a way that leads to interesting research) assumption that human brains do integer operations with the same speed tradeoffs as binary computers.
I'm not quite certain how you'd model this, and how you'd measure the "small coin stock robustness" of a coin denomination system, but it's definitely at least as interesting a problem as the original.
1. Any combination of coins should represent a reasonable amount of currency.
2. A change system must be able to represent any reasonable non-negative amount of currency.
For all the definitions of reasonable that I'm likely to use, the first condition is equivalent to "all coins values are a positive integer number of cents" (i.e. no hay-pennies, and no coins that have negative value); the second is equivalent to requiring a penny.
3. It should be possible to figure out the best way to make change (meaning, fewest coins used) in a "good" system by following this naive greedy algorithm: first give out as many of the largest denomination as possible without exceeding the total you want to give out, then as many of the next largest, etc.
In C-like pseudocode, this algorithm would be:4. (a refinement) In a "really good" change system it should be possible to use an even more naive algorithm; this algorithm is best demonstrated in pseudocode:Note that our current system satisfies criterion 3, but not criterion 4. Our current system without the quarter (but with the half dollar) satisfies criterion 4. An example of a system that does not satisfy criterion 3 is [1,5,10,18]. (In that system, the naive greedy algorithm would make 20 as 18+1+1, whereas 10+10 uses fewer coins)
It's easy to show that satisfying criterion 4 implies satisfying criterion 3. It's also pretty easy to show that a sufficient condition for criterion 4 isfor all i so that the indices make sense.
However, what I've never really sat down to work on (*) is whether this condition is really necessary for criterion 4, and what necessary and sufficient conditions are for criterion 3.
Efficiency in terms of numbers of coins used never even occurred to me, though I'm sure it would have if I lived in a country with a purely decimal coinage system (i.e. just penny, dime, and dollar coins)
(*) Or if I have, I've forgotten. I tend to do that when I don't write stuff down.
If Microsoft would let companies re-distribute their automatic patches within their own organization, or allowed OEMs to distribute these to their customers, you might see this.
The kind of innovation you're talking about requires lots of experiments, false starts, and playing with things to get it developed properly.
Unfortunately, the "only download and run this, do NOTHING else" nature of their standard EULA crushes the spirit of this innovation. I can't just go and start up a project to distribute Microsoft patches via bittorrent, for example. Even assuming I worked for a company big enough to negotiate different EULAs with Microsoft, I'd have to go to the suits and ask them to add this permission into the negotiations, and then I'd have to make up a business case for it, etc. All of which distracts from implementing the prototype.
Sure, any production-quality, successful large scale result of this kind would involve enough planning and development time that going to the suits wouldn't be terrible overhead. However, before that happens, you need a working toy. These toys aren't getting built because Microsoft restricts how and when updates happen.
It's a darn shame that you can't send someone slashdot messages, but I have to ask - what are you trying to do that's failing? I couldn't remember java 1.3 being broken in this fashion, so I wrote a little test program, and it seems to work just fine:
import java.net.*;
public class printURL
{
static void main(String argv[])
throws Exception
{
URL u = new URL(argv[0]);
URLConnection urlc = u.openConnection();
urlc.setRequestProperty("X-Whatever", "WhichEver");
if (argv.length > 1)
urlc.setRequestProperty("User-Agent", "Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2.1; MultiZilla v1.4.0.3J) Gecko/20030425");
java.io.InputStream is = urlc.getInputStream();
java.io.Reader rdr = new java.io.InputStreamReader(is);
int ch;
for (ch = rdr.read(); ch != -1; ch = rdr.read() )
{
System.out.print((char)ch);
}
}
}
When I run this against a cgi script that just prints out what you send it (printenv.pl from a recent apache distribution), it clearly shows that the user agent is Java1.3.1 without that "setRequestProperty" line, and is what I say (I just copied what my browser says) with it.
What are you doing?
I'd take this off slashdot, but you give no way of contacting you in your slashdot profile.
There's a cure for that, by the way: Effective C++ by Scott Meyers. It really is exactly the thing to fix up one's C++ knowledge to what's current (I learned C++ back in 1995, using books that were already over a year old then, and compiler versions that were at least three years old).
This reminds me that I should go ask the co-worker who's been borrowing it for six months now to return it...
Good idea. I am forced to use 1.3 for a project, and would love to be able to steal classes from later versions. We moved to 1.3 to get HTTP 1.1 support, but our production environment would have been greatly simplified if we had stayed with 1.2.
When we were faced with the same problem, we just went and used HTTPClient. Similarly, when we needed regexps in 1.3, we just went for the Jakarta ORO library. (And even in our java 1.4 environment, we're still using log4j)
Sure, it would be nice if Sun split the standard library from the runtime engine, but third-party java libraries are plentiful and can often cover the gaps. Also, if there's some new feature in a higher java revision that you can't live without, you might want to first check whether Sun also released a version of this feature that's compatible with the java version you're stuck with. (e.g. JSSE for java 1.2)
It's not that those bad habits are encouraged by VB, it's that they aren't forcefully discouraged strongly enough.
I've occasionally watched my father's students (he teaches part-time at a local community college) struggle with their first VB programs. As I see it, the problem with VB is that the pattern of "debugging by random code modification" so often works, or at least doesn't throw up errors when run. (Though some errors might be thrown up when the project is compiled; in VB "run mode", as with many classic BASIC variants, code paths that aren't traversed aren't even checked for syntax errors) This is partially due to VB being an extreme DWIM language. (e.g. automatic conversions between numbers and strings that even make perl programmers cringe)
But the tendency to just pound out spaghetti logic and then tweak it until it works is something that the students bring with them to the lab before they've ever used VB themselves.
Some of their behavior reminds me of TAing calculus students. They fundamentally don't want to learn what's going on, they just want to get the answer/get the project to work and be done with it. Even if you can get them to realize intellectually that a deeper understanding would allow them to finish their assignments faster, the strong gut reaction against figuring out what's going on remains.
The odd thing is that every so often I would find a student who was perfectly happy to learn the what was really going on, and get the deeper understanding that would have helped them, but only after fighting through the assignment the hard way.
I don't mean to imply by this that the vast majority of the calc. students I TAed (or those taking my father's VB class) are lazy; I think this may have something to do with the nature of how people learn new concepts. It may be orders of magnitude more difficult to learn high-level concepts without concrete experience to which one can relate those concepts. It almost makes me want to track down an education major and ask them about what the current theories say.
The problem with VB is that there is almost no incentive to go back and learn the "proper" way to do things after you've slogged through. The rapid increase in expressive power that one gains in most languages by taking the time to wrap one's brain around the language isn't really there in VB. VB, by design, makes certain that a muddled first-glance understanding is "good enough", so that's where many people stay.
No human being would make such an absurd assumption.
That's what you think.
Clearly, you've never been on the other side of the desk during a job interview. Either that, or you've been insanely lucky in the applicants you see.
I know this is hindsight, but consider this: if you are planning backups, and are planning them so that your systems will still operate if the building you're in falls over (which, after the 1993 bombing attempt, anyone in the WTC should have been doing), wouldn't you want to place the backups far enough away so that the building the main system is in can't possibly fall on the building the backup is in?
I know that's not what happened on 9/11, but shouldn't that scenario have been considered?
Besides, why waste WTC rental money housing backup systems? Surely there's cheaper land out on Long Island or across the river in Jersey.
Housing backup systems in the other tower was expensive flashiness that could never have been expected to provide bomb-proof systems.
This is already a feature of Conquest: (from the linked page, bold emphasis my own doing)
Conquest uses memory to store all metadata, small files (currently based on a size threshold), executables, and shared libraries, leaving only the content of large files on disk. All accesses to in-core data and metadata incur no data duplication or disk-related overhead, and executions are in-place. For the large-file-only disk storage, we use a larger access granularity to reduce the seek-time overhead. Because most accesses to large files are sequential, we can relax many historical disk design constraints, such as complex layout heuristics intended to reduce fragmentation or average seek times.
Actually, as of Python 2.2, with nested scopes implemented, g() can really access the variable outside its own scope.
The problem though is similar to what you alluded to with passing variables into functions and wanting the functions to modify them; when in the inner function you say "x = 50", you're rebinding the local-to-g version of x. The end result is that the outer x is then not repointed to the new object. (See the PEP for why, or look at the appropriate part of the "what's new" document)
In any case, this will work in Python 2.2, or in Python 2.1 that uses the proper "from __future__" construct:
def f():
x = [50]
def g():
x[0] = 40
g()
print x[0]
f()
A possible way to think about this is that in python, assignment is not a setq but rather a defvar.
I don't know where you've been, but cable companies haven't been able to charge per-TV in years, anywhere. In fact, the per-TV issue is right now one of the big advertising points the cable giants are using in the ad. campaign against satellite.
It's not that hard, really. And, if you think it is some great deep programming secret, you're going to be disappointed when you actually go look at a quine and see how it's done. A certain classic Turing Award acceptance speech starts off the speech with probably one of the easiest-to-understand quines there is.
Now go away and do it yourself, in some language. The end of this post is going to contain a quine-like construct, and I'd hate to give the secret away to someone who still wanted to discover it themselves.
Quines, or rather quine-like logic, do have actual current applications, though I can't think of one off the top of my head that isn't malicious.
Assuming this'll get past the lameness filter, here's a short piece of code that you should never, ever, ever execute on a lambda-derived moo. Ever. It's essentially a one-line fork bomb. The only way I know of killing it is by temporarily disabling $string_utils:print. It's technically not a quine, though its core is certianly quine-like.
In fact just recently I wrote a one-off script here that did essentially what this PHP script does - it takes data out of a local sybase db and reformats it as a bunch of SQL statements. (We don't have direct access to the database into which this needs to be loaded, so there needs to be an intermediate form anyway)
/^AudTmst$/, @names);
= TEST_ATRB", $user, $password);
I suppose this _might_ be worth a post on perlmonks, as an example of using the DBI, (and of working around the fact that DBD::Sybase doesn't really implement column_info) but not much more than that.
This code generates an SQL load file for each table that has a column named "DataSrcId" where that column has the value "35". It also substitutes the value 'guy' for any column named 'AudUsrId' and does not include any column named 'AudTmst' in the load output. As I said, it's a one-off hack.
#!perl
use DBI;
use DBD::Sybase;
my($dbh);
sub dumpstatement {
my ($tablename, $statement) = @_;
my $sth;
$sth = $dbh->prepare($statement);
$sth->execute();
while ( my(@row) = $sth->fetchrow_array ) {
my @names = @{$sth->{NAME}};
@row = map { $names[$_] eq 'AudUsrId'?'guy':$row[$_] } (0..$#row);
@row = map { $names[$_] eq 'AudTmst'?qw():$row[$_] } (0..$#row);
@names = grep(!
print "INSERT $tablename (", join(',',@names), ")\n";
print "VALUES (", join(",",
map {$dbh->quote($row[$_],$sth->{TYPE}->[$_])}
(0..$#row)
), ")\n";
}
print "\n";
}
my($user, $password) = qw[sa confusion];
$dbh = DBI->connect("dbi:Sybase:server=njdscope;database
my($sth) = $dbh->table_info('%','%','%', '%');
my(@tables);
my($hashr);
while ($hashr = $sth->fetchrow_hashref("NAME_uc")) {
my($ctable) = $hashr->{TABLE_NAME};
push @tables, $ctable;
}
$sth = undef;
foreach my $table (@tables) {
$dbh->{PrintError} = 0;
my $teststatement = $dbh->prepare("SELECT max(DataSrcId) FROM $table WHERE DataSrcId = 35");
$teststatement->execute;
if ($teststatement->err) {next;}
$dbh->{PrintError} = 1;
print "-- for $table \n";
dumpstatement($table, "SELECT * FROM $table WHERE DataSrcId = 35");
}
By the way - slashdot inserts an extra ";" in this code, even though it is NOT there in what I copy/paste in. Go figure.
No, primary and secondary schools are designed to shift responsibilities for children off of the parents' backs, so they have someone else to blame when their child doesn't turn out to be Superman and/or Wonderwoman.
See, and I always thought that they were designed to produce a labor force to catapult your 19th-century backwater kingdom into an early 20th-century industrial power. That, and keep teenagers out of the labor forse.
I keep hearing (mostly on slashdot) some people complain that they are shut out of CS degrees because of an inability or unwillingness to get through the requisite math courses.
I must say that I have a very difficult time believing this, but under the weight of so many complaints I am willing to concede that my judgement may be off on this point.
However, the parent post's comment about "vb weenies who are gifted in mathmatics" has me intrigued. I've never seen one of these - what do they look like? I've seen vb weenies with a BA in Economics and even once with some sort of two-year accounting degree, but neither was what I'd call particularly skilled in mathematics. What mathematics they knew was rote memorization of the kind that can often get you through calculus (these days), but not far beyond.
So what does a vb weenie gifted in mathematics do? What is the characteristic of their programming style that one can point to and say "See, this bad practice? That's the sign of a mathematically gifted vb weenie." ?
I'm especially curious about people who fit this pattern with bachelor's degrees in mathematics, computer science, or one of the natural sciences.