I'll just note that, programming 3D FORTRAN in 1979, I built my own three-terminal setup (I built a three-way RS-422 switch) between the three terminals I had a total resolution of 3740x1024. I used one terminal for interacting with the mainframe, one to show the source, and one to display the 3D graphics output. All of these Tektronix terminals had their own memory so I could actually edit code in the edit buffer on that terminal, and all three maintained their view while I interacted with another.
Replying to myself - 304 million gallons over 20 years was incorrectly applied to 6+billion per day - that should have been 6.3 billion per day * 365.25 * 20 / 304 million = 1 part in 151,386 - I think this is about 1 cc of loss per barrel. I don't know where I got 576000 any more.
Stipulating that at present *every* method does not include all the externalities, the actual cost of any product, method or system reflects the environmental cost to the extent that the cost has been de-externalized. One way that happens is that, increasingly, cleanup costs are charged to and paid for by the producer/shipper and their insurance companies. And reporting is at least one, maybe two orders of magnitude better than it was 30 years ago. That _should_ be true for oil, for wind, for solar, etc. And it is increasingly true. At this point it's probably more true for oil than for any of the others (I suspect coal is still getting a break but I dunno.)
One example of externalities not presently charged to the electric vehicle industry is the lack of cleanup and mitigation in Canada and Russia around the big nickel mining areas, where according to legend 100s of square miles of territory are devoid of living vegetation. (/.ers: is this true? I keep hearing it...)
As it turns out, shipping the oil is not one of the bigger costs of oil. IIRC from two-three years ago, the cost of shipping is only about 18c per gallon (US cost). I think the actual bulk-carrier-tanker-ship part of that is only two or three cents - my memory may have failed me on that but Wikipedia agrees. That includes the cost of insurance and the overall amortized risk to the companies involved (if it were not, the companies would have been out of business long ago). Which means that it includes the costs to the companies including fines and mitigation costs, of all the oil spills and other pollution. It also includes the costs of the newer double-hull ships with additional spill prevention and mitigation equipment that is now required. One cost that isn't being included yet is the smokestack pollution from the tankers, and all other shipping.
To the extent that externalities of all the methods are included, that cost demonstrates that pollution is actually not a very large problem for oil _compared to total production_, so electric vehicles and their power sources (wind, whatever) will have to work hard to match the true cost/benefit of oil.
Discussion: people don't realize the sheer volume of oil that goes through the system every day - counting fuel and products, around 150 million barrels (6+ billion gallons, 24+ billion liters) per day. As of 2000, the total amount spilled in 20 years in the US from causes was about 300 million gallons (about 1/576000 over 20 years), and had decreased by 50% in that 20 years. The rate has continued to decrease since then. This is equivalent to about 2/100 of one cc out of a barrel - or an invisible speck that pops out of a bubble when you open a carbonated beverage and little bubbles pop.
note: some of this data was loosely adapted from this analysis. Also, a USA Today article followed that trend - from 2005 to 2009, there were an average of 22 spills per year of more than 50 barrels (down from some 8000 in 1980. This is not to excuse, but to provide perspective. Interestingly, the New England states had the highest number of spills per square mile 1980-2002.
Cool. I haven't written significant C in 10 years, so wasn't aware that gcc did that. Although IMHO it would be semantically better to use {} instead of () as the inside symbols, since {} identifies blocks elsewhere.
Yes. This was before security and the general level of bogosity was a big deal. The first Internet worm appeared in 1988, the same year the NeXT machine was introduced. Ahh, the good old days...
In point of fact, Tim Berners-Lee's "World Wide Web" program was inspired by and built on the NeXTstation, taking advantage of the combination of Unix underneath topped by object-based systems with transparent network access. Almost any application could incorporate objects from any other application, so the Webster's Dictionary had both audio and video clips in it, and spreadsheets could also have media of any type attached to a cell. (Lotus had a really cool object-based extension of spreadsheets - I forget its name. It took a while to get past the old assumptions, but once you did it was great. It died with the NeXT.)
I worked as product manage on a product called PaperSight, which was a network based document management system - any document of any type could have annotations that overlaid the document, and both voice and video notes attached to any point on the document. It was better then than anything I've seen since, and it's been 20 years. Even the Mac OSX today isn't really as capable and clean as NeXTstep was back then.
I've already said this twice in other replies, but here's another - NextMail had this capability in the late 1980s - early 1990s, including links to files on other hosts anywhere in the world (on the internet) using the Andrew file system.
There's definitely prior art for that - I mentioned in another reply that NextMail had this capability - a NextMail (or, really, any document) could have an audio, video, spreadsheet or any other type of object embedded in it. NextMail really looked like what the web was soon to become.
This was a thing in NextStep back in the late 1980s - early 1990s, I believe. It did not link to WWW, because that had not been created yet, but did link to items anywhere in the Andrew filesystem, which used the same link format - that format was adapted by Berners-Lee when he created WorldWideWeb. An Andrew file location looked like//some.dns.domain//some/path/to/file. It also opened up other applications, including FTP, image viewers, sound files, etc. and an email in NextMail looked a _lot_ like an early web page. Lee's work was really a pretty logical extension of NextStep applications.
A similar type of error results from C's syntax, which was unfortunately adopted in PHP - in allowing action inside a conditional "if ($foo = 1 + $bar)", the poor parser has no way to know if one really means 'compare' or 'assign'.
I don't understand. I'm not a parser, but to my eye that means "assign." If you wanted to compare, you would do "if ($foo == 1 + $bar)", no?
Ah, but in C, and thereby in several other languages that have adopted C syntax, the result of the assignment becomes the value of the conditional, so "if ($foo=1+$bar)" means, 'add one to $bar, assign it to $foo, then evaluate the conditional based on the value of $foo'. Maybe that's what I meant to write, but maybe I just mistyped. So thus arises an ambiguity - did we mean assign and then evaluate, or just compare? And thus bugs are born. It is quite easy to accidentally put '=' when we mean '=='. But the parser does not know whether we goofed.
This is why I would like to see the syntax changed to require any assignment inside a conditional to be enclosed in a block. This removes any ambiguity - "if ($foo=1+$bar)" would be a syntax error. For assignment we would write "if ({$foo=1+$bar})", and for comparison we would write "if ($foo==1+$bar)".
I just replied elsewhere about my recent experience with Perl - Perl makes PHP look like a paragon of consistency and well-designed code. But I do like Perl regular expressions - as implemented in PHP!:D
Python's use of a single, invisible marker for blocks - the indent - is a mistake that causes a lot of bugs. Blocks need different begin and end markers to allow the parser to know what goes where.
Re: PHP 6.0 without the stupid?
on
PHP 5.5.0 Released
·
· Score: 4, Informative
Ha. As a programmer in at least two handfuls of languages over 40 years from IBM 1130 ASM, FORTRAN, ALGOL 68, Pascal, Basic (ick), APL, etc., and long time programmer in PHP, I am presently in the process of hacking up someone else's Perl.
Nobody who writes in Perl can have anything to say about the structure, style or consistency of PHP. PHP may have grown like topsy and it could certainly use some revision of function argument order, but it at least uses a syntax that is remotely similar to other common imperative languages - java, c, etc. From my first look at Perl in 1995 I always thought Perl looked like sneezing, and now I'm working with it, my first impression was correct. (Although in fairness I use PCRE in PHP quite a lot!)
Exactly what the EXPR argument to when does is hard to describe precisely, but in general, it tries to guess what you want done. Sometimes it is interpreted as $_ ~~ EXPR, and sometimes it does not. It also behaves differently when lexically enclosed by a given block than it does when dynamically enclosed by a foreach loop. The rules are far too difficult to understand to be described here. See Experimental Details on given and when later on.
Since I'm on a role here, I will complain about one thing in Python, though I've only programmed a bit in Python. Python's much vaunted 'indent' based nesting is a mistake, because it only uses one invisible marker (which may be instantiated by several symbols - spaces and tabs, at least) to do this. All other common languages I can think of use different markers for begin and end, which acts as a kind of 'double entry bookkeeping' for the parser. Without a closing marker, Python's parser has no way to catch errors in leading spaces.
A similar type of error results from C's syntax, which was unfortunately adopted in PHP - in allowing action inside a conditional "if ($foo = 1 + $bar)", the poor parser has no way to know if one really means 'compare' or 'assign'. This is the cause of innumerable bugs in both languages. This could be fixed by requiring assignments inside a conditional to be surrounded by block markers: "if ({$foo = 1 + $bar})".
But I like all 'scripted' languages better for my purposes (entirely applications, no device drivers or kernel work) than C and other 2nd generation languages. I've had exactly one segfault working with PHP, in nearly 20 years.
WRT feeling, yes it touches on the question of just what we are, and how are we different (in kind, or only in scale) from the robot.
I'm inclined to agree on the 'system as reality' position, mostly, for a reason that touches on your first point. The best model of how the brain works is that it is (at least) one step removed from the sensory input, and does the majority of what we call 'thinking' (also feeling, etc. in the cognitive 'mind' sense) based on a model of the inputs, not the inputs themselves. For example, IIRC it takes close to 1/2 second for signals from the skin on your toes to reach your brain, but only a small fraction of that time for signals from the skin on your ears. Your brain integrates this all to be 'simultaneous' by running about 1/2 second behind reality and fixing things up as it goes, pasting over the incongruities. So you have the field of sensory inputs, and a model of those inputs, and the brain. So in fact we ourselves are always working from a model - how is that different from a machine that we design to do the same thing?
But there is no easy answer. as the Wikipedia article on Systems Philosophy notes, the nature of systems continues to be a controversy:
An important debate in Systems Philosophy reflects on the nature of natural systems, and asks whether reality is really composed of objectively real systems, or whether the concept of “natural systems” merely reflects a way in which humans might regard the world in terms relative to their own concerns.
.
Like many other areas of study, it turns out that the best answer depends on what you are doing, and what you want to know.
Your lack of hunger thing is something that one (who is 30 lbs. overweight) might casually wish for, without realizing the consequences. I lived for a short time in a house with a 12 year old boy who had fetal alcohol syndrome. One of his symptoms was inability to feel heat - he could not tell something's temperature until it burned him. So, partly because it made little difference and partly for safety reasons he prefered his food straight out ot the refrigerator.
I would argue that hunger, like suffering, is an emotional response that is inherent in a living, intelligent being. It's different from a programmed response to a low battery condition that sends the robot to a recharging facility.
OTOH there are those who think that motivation, which is the balancing of a large variety of inputs and responses to determine a best course of action, is both a key part of intelligence and an implementable function of a neural network. This goes back to the essentially philosophical question in systems science, as to whether a 'system' that we discuss is the actual thing, or merely a model of the thing that we discuss.
There was a book (on cognitive science?) back in the early 1990s, which asserted (IIRC) that self-aware intelligence did not arise in most humans until the Renaissance. I think it also argued that most of us, most of the time, are not self-aware and intelligent even today. I won't argue for or against, but that guy down the street, well!...
Yes. The paper I referenced covered this topic quite well, including citations from a number of other researchers. But AFAICT none of the folks on this thread actually went to go read even the executive summary. One person maligned me for not providing citations, and then maligned me for providing one. At least one decided that since it was linked to by the WSJ it must be evil propaganda.
Sigh. One does tire of what passes for discourse these days. I'm no great shakes and I blather on too long, but I at least _try_ to assemble a reasoned argument, and base it on my own research as well as outside references. But then, XKCD today...:)
Sigh. No, it didn't. From the report you cited, which was done a few months after the event, before the research that the PDF I cited was done, which corrects some of the early analysis as a result of better knowledge and research:
At 2:32 p.m., against this backdrop of unusually high volatility and thinning liquidity, a large fundamental5 trader (a mutual fund complex) initiated a sell program to sell a total of 75,000 E- Mini contracts (valued at approximately $4.1 billion) as a hedge to an existing equity position.
This order was similar to one performed a few months earlier, which was spread over six hours with no effect on the market. This time it was spread over only 20 minutes - big mistake. This is not HFT, in fact it was partly manual. It involved the 'largest net change in daily position of any trader in the E-mini in the last year.' Note that the original erroneous Sell algorithm was still pushing the stock orders throughout the period, including attempts during the five second halt. Much of the further decline was driven by algorithmic trading - only some of which is HFT. Every algorithm that sees the market falling off a cliff is going to try to get out before it's too late. The HFTs (as we later learned) were sopping up a lot of that sell side activity, until they too hit their stop levels.
Whether trading decisions are based on human judgment or a computer algorithm, and whether trades occur once a minute or thousands of times each second, fair and orderly markets require that the standard for robust, accessible, and timely market data be set quite high. Although we do not believe significant market data delays were the primary factor in causing the events of May 6, our analyses of that day reveal the extent to which the actions of market participants can be influenced by uncertainty about, or delays in, market data.
The Sell Algorithm used by the large Fundamental Seller responded to the increased volume by increasing the rate at which it was feeding the orders into the market, even though orders that it already sent to the market were arguably not yet fully absorbed by fundamental buyers or cross-market arbitrageurs. In fact, especially in times of significant volatility high trading volume is not a reliable indicator of market liquidity.
Once the HFTs and other buyers had sopped up all possible liquidity, with further sell pressure from the Seller, there was nowhere to go. At that point the HFTs, along with algorithmic non-HFT, EFTs, and everyone else, began to unload the positions that they had taken, which combined with the continuing Seller activity, took the market farther down.
But the key fact is this demonstration of how effectively the market was able to recover:
time to react and verify the integrity of their data and systems, buy-side and sell-side interest returned and an orderly price discovery process began to function. By approximately 3:00 p.m., most securities had reverted back to trading at prices reflecting true consensus values.
From the PDF I cited earlier:
Over the past decade, HFT has increased sharply, and liquidity has steadily improved. But correlation is not necessarily causation. Empirically, the challenge is to measure the incremental effect of HFT beyond other changes in equity markets. The best papers for this purpose isolate market structure changes that facilitate HFT. Virtually every time a market structure change results in more HFT, liquidity and market quality have improved because liquidity suppliers are better able to adjust their quotes in response to new information.
Based on the vast majority of the empirical work to date, HFT and automated, competing markets improve market liquidity, reduce trading costs, and make stock prices more efficient. Better liquidity lowers the cost of equity capi
If you read the PDF, you'll see that I'm very much in line with the regulators and economists, although taking a slightly different perspective (I look at the global markets as a complex adaptive system, which is a bit past the standard econometric models, which amount to a special case of the CAS model.) The regulators have looked at things like transaction taxes (as discussed in the infamous PDF), and found that the empirical evidence shows such taxes would have the opposite effect of the one desired - they decrease liquidity and increase volatility. And the exchanges and regulators established some mechanisms (mostly a few years ago) to deal with the potential issues, which so far seem to work pretty well.
I suggest you read this PDF, which was posted by someone else but has some very good information.
I suggest that you answer the arguments presented, rather than expect any readers of this discussion to read long external PDFs. Or were you counting on that they wouldn't and simply assume that it would back you, since you linked to it?
Why? I answered the arguments multiple times on this thread, and folks asked for citations. So there's a citation, that incorporates another 40 or so citations of actual, real, research by actual, real, university researchers who actually know something. the PDF is also, for those who actually want to learn something, a pretty substantive piece of educational material in its own right, which was originally linked by someone else who thought folks might actually want to learn something.
I can only beat a dead horse so many times before I get bored.
Read the PDF. The evidence is in the PDF. One example from the paper: the May 2010 crash was not caused by HFT. Its effect was _moderated_ by HFT, until the HFT traders couldn't take any more and got out of the market. That's when things went south. The SEC stopped trading for five minutes to give time for things to settle out, and when trading started back up the HFT were instrumental in bringing things back to normal within 20 minutes.
I won't argue that HFT has a potential for exacerbating things under certain circumstances - though the evidence is that it is much more likely to moderate things according to the research cited in the paper - and the exchanges and regulators have put in place mechanisms to deal with those events, such as the five minute halt cited, and per-stock 'circuit breakers' that can stop trading in any stock when movement goes outside of reasonable bounds. They've also instituted other mechanisms to prevent various abuses that have always been there, but were also exploited on the smaller time scales of HFT. It was much more likely to occur back when the algorithms were primitive, the regulations were not in place, and the number of different algorithms was small.
I suggest you read this PDF, which was posted by someone else but has some very good information. It's quite an education. (I had trouble opening, had to download it.)
1. See This PDF. 2. Economic policy is (generally, or rather a subset of) social policy. There are lots of papers out there showing that using taxation to accomplish a social (or economic) objective is rife with unintended consequences and perverse incentives. Just as a direct example, according to the PDF above, both theoretical and empirical research has shown that imposing a transaction tax on trades has the effect of reducing liquidity, increasing volatility, increasing the cost of trades for retail customers, and reduces stock prices substantially. These are generally the opposite of the desired effect.
Not to mention that this also drives the market to other jurisdictions - when Sweden imposed a 1% transaction tax they lost over 60% of their market to London, and even after eliminating the tax, 20 years later those customers (and jobs) have never returned.
It's true, I've blathered on beyond all sensibility. There's just so much misinformation and folks believing what the unedumacted media say about this stuff, forgetting the nearly nobody in the media has ever so much as taken an Economics course.
Case in point - analysis has shown that the flash crash in May 2010 was not caused by HFT (the PDF linked below talks about this in several places). It was in fact greatly moderated by HFT, until the HFT traders went past their own circuit breakers and withdrew from the market. Then, after a five minute 'rest' period instituted by the SEC, the HFT went back to work and everything was back to normal within 20 minutes. But ask anybody who reads the 'news', and they'll spout the media line that HFT caused the flash crash.
TFA provides pretty good evidence: 1) profits per trade are down by some 90% (IIRC what TFA said); 2) actual revenues are down by a factor of three according to the PDF below; 3) many institutions have left the business or gone bust because they couldn't compete as the market matured; 4) HFT has become an essential element of almost all market activity - according to SEC, 68% of large cap stock trades are made using HFT (this last item is in the link below); 5) 'Everybody' is now doing it - your neighborhood broker uses HFT to complete your trade of 10 shares of IBM.
IOW, HFT has transitioned from being the hot new way to make $zillions to the new combination of the ticker tape and the market makers. (but 'tis true, there are several kinds of HFT.)
And SEC is considering _requiring_ HFT traders to stay in the market during 'flash' events, because they are instrumental in reducing the impact of those events. (again, read the PDF, all the way through.)
These are all classic elements of a busted tech bubble. From Econ 102, the interesting thing about tech bubbles (which HFT certainly exemplifies) is that in the bubble the majority of the original players - sometimes 99%, sometimes less, drop out, are merged out of existence, or otherwise leave the market; and ten years later, _almost without exception_ the market is more than four times the size as it was at the peak of the bubble.
This was posted by someone else, and covers the topic pretty well. (I had to click the download link from the apparent PDF, then read it from the file manager - YMMV).
Slashdot Mirror
I'll just note that, programming 3D FORTRAN in 1979, I built my own three-terminal setup (I built a three-way RS-422 switch) between the three terminals I had a total resolution of 3740x1024. I used one terminal for interacting with the mainframe, one to show the source, and one to display the 3D graphics output. All of these Tektronix terminals had their own memory so I could actually edit code in the edit buffer on that terminal, and all three maintained their view while I interacted with another.
Replying to myself - 304 million gallons over 20 years was incorrectly applied to 6+billion per day - that should have been 6.3 billion per day * 365.25 * 20 / 304 million = 1 part in 151,386 - I think this is about 1 cc of loss per barrel. I don't know where I got 576000 any more.
Stipulating that at present *every* method does not include all the externalities, the actual cost of any product, method or system reflects the environmental cost to the extent that the cost has been de-externalized. One way that happens is that, increasingly, cleanup costs are charged to and paid for by the producer/shipper and their insurance companies. And reporting is at least one, maybe two orders of magnitude better than it was 30 years ago. That _should_ be true for oil, for wind, for solar, etc. And it is increasingly true. At this point it's probably more true for oil than for any of the others (I suspect coal is still getting a break but I dunno.)
One example of externalities not presently charged to the electric vehicle industry is the lack of cleanup and mitigation in Canada and Russia around the big nickel mining areas, where according to legend 100s of square miles of territory are devoid of living vegetation. (/.ers: is this true? I keep hearing it...)
As it turns out, shipping the oil is not one of the bigger costs of oil. IIRC from two-three years ago, the cost of shipping is only about 18c per gallon (US cost). I think the actual bulk-carrier-tanker-ship part of that is only two or three cents - my memory may have failed me on that but Wikipedia agrees. That includes the cost of insurance and the overall amortized risk to the companies involved (if it were not, the companies would have been out of business long ago). Which means that it includes the costs to the companies including fines and mitigation costs, of all the oil spills and other pollution. It also includes the costs of the newer double-hull ships with additional spill prevention and mitigation equipment that is now required. One cost that isn't being included yet is the smokestack pollution from the tankers, and all other shipping.
To the extent that externalities of all the methods are included, that cost demonstrates that pollution is actually not a very large problem for oil _compared to total production_, so electric vehicles and their power sources (wind, whatever) will have to work hard to match the true cost/benefit of oil.
Discussion: people don't realize the sheer volume of oil that goes through the system every day - counting fuel and products, around 150 million barrels (6+ billion gallons, 24+ billion liters) per day. As of 2000, the total amount spilled in 20 years in the US from causes was about 300 million gallons (about 1/576000 over 20 years), and had decreased by 50% in that 20 years. The rate has continued to decrease since then. This is equivalent to about 2/100 of one cc out of a barrel - or an invisible speck that pops out of a bubble when you open a carbonated beverage and little bubbles pop.
note: some of this data was loosely adapted from this analysis. Also, a USA Today article followed that trend - from 2005 to 2009, there were an average of 22 spills per year of more than 50 barrels (down from some 8000 in 1980. This is not to excuse, but to provide perspective. Interestingly, the New England states had the highest number of spills per square mile 1980-2002.
Cool. I haven't written significant C in 10 years, so wasn't aware that gcc did that. Although IMHO it would be semantically better to use {} instead of () as the inside symbols, since {} identifies blocks elsewhere.
Will it ever become part of standard C?
Yes. This was before security and the general level of bogosity was a big deal. The first Internet worm appeared in 1988, the same year the NeXT machine was introduced. Ahh, the good old days ...
In point of fact, Tim Berners-Lee's "World Wide Web" program was inspired by and built on the NeXTstation, taking advantage of the combination of Unix underneath topped by object-based systems with transparent network access. Almost any application could incorporate objects from any other application, so the Webster's Dictionary had both audio and video clips in it, and spreadsheets could also have media of any type attached to a cell. (Lotus had a really cool object-based extension of spreadsheets - I forget its name. It took a while to get past the old assumptions, but once you did it was great. It died with the NeXT.)
I worked as product manage on a product called PaperSight, which was a network based document management system - any document of any type could have annotations that overlaid the document, and both voice and video notes attached to any point on the document. It was better then than anything I've seen since, and it's been 20 years. Even the Mac OSX today isn't really as capable and clean as NeXTstep was back then.
NextMail - part of NextStep, 1989.
I've already said this twice in other replies, but here's another - NextMail had this capability in the late 1980s - early 1990s, including links to files on other hosts anywhere in the world (on the internet) using the Andrew file system.
There's definitely prior art for that - I mentioned in another reply that NextMail had this capability - a NextMail (or, really, any document) could have an audio, video, spreadsheet or any other type of object embedded in it. NextMail really looked like what the web was soon to become.
This was a thing in NextStep back in the late 1980s - early 1990s, I believe. It did not link to WWW, because that had not been created yet, but did link to items anywhere in the Andrew filesystem, which used the same link format - that format was adapted by Berners-Lee when he created WorldWideWeb. An Andrew file location looked like //some.dns.domain//some/path/to/file. It also opened up other applications, including FTP, image viewers, sound files, etc. and an email in NextMail looked a _lot_ like an early web page. Lee's work was really a pretty logical extension of NextStep applications.
A similar type of error results from C's syntax, which was unfortunately adopted in PHP - in allowing action inside a conditional "if ($foo = 1 + $bar)", the poor parser has no way to know if one really means 'compare' or 'assign'.
I don't understand. I'm not a parser, but to my eye that means "assign." If you wanted to compare, you would do "if ($foo == 1 + $bar)", no?
Ah, but in C, and thereby in several other languages that have adopted C syntax, the result of the assignment becomes the value of the conditional, so "if ($foo=1+$bar)" means, 'add one to $bar, assign it to $foo, then evaluate the conditional based on the value of $foo'. Maybe that's what I meant to write, but maybe I just mistyped. So thus arises an ambiguity - did we mean assign and then evaluate, or just compare? And thus bugs are born. It is quite easy to accidentally put '=' when we mean '=='. But the parser does not know whether we goofed.
This is why I would like to see the syntax changed to require any assignment inside a conditional to be enclosed in a block. This removes any ambiguity - "if ($foo=1+$bar)" would be a syntax error. For assignment we would write "if ({$foo=1+$bar})", and for comparison we would write "if ($foo==1+$bar)".
I just replied elsewhere about my recent experience with Perl - Perl makes PHP look like a paragon of consistency and well-designed code. But I do like Perl regular expressions - as implemented in PHP! :D
Python's use of a single, invisible marker for blocks - the indent - is a mistake that causes a lot of bugs. Blocks need different begin and end markers to allow the parser to know what goes where.
Ha. As a programmer in at least two handfuls of languages over 40 years from IBM 1130 ASM, FORTRAN, ALGOL 68, Pascal, Basic (ick), APL, etc., and long time programmer in PHP, I am presently in the process of hacking up someone else's Perl.
Nobody who writes in Perl can have anything to say about the structure, style or consistency of PHP. PHP may have grown like topsy and it could certainly use some revision of function argument order, but it at least uses a syntax that is remotely similar to other common imperative languages - java, c, etc. From my first look at Perl in 1995 I always thought Perl looked like sneezing, and now I'm working with it, my first impression was correct. (Although in fairness I use PCRE in PHP quite a lot!)
This is my most recent 'fave' quote from perlsyn - on 'when', which is part of Perl's attempt to rethink (or something) the switch/case pattern:
Exactly what the EXPR argument to when does is hard to describe precisely, but in general, it tries to guess what you want done. Sometimes it is interpreted as $_ ~~ EXPR, and sometimes it does not. It also behaves differently when lexically enclosed by a given block than it does when dynamically enclosed by a foreach loop. The rules are far too difficult to understand to be described here. See Experimental Details on given and when later on.
Pathologically Eclectic Rubbish Lister indeed!
Since I'm on a role here, I will complain about one thing in Python, though I've only programmed a bit in Python. Python's much vaunted 'indent' based nesting is a mistake, because it only uses one invisible marker (which may be instantiated by several symbols - spaces and tabs, at least) to do this. All other common languages I can think of use different markers for begin and end, which acts as a kind of 'double entry bookkeeping' for the parser. Without a closing marker, Python's parser has no way to catch errors in leading spaces.
A similar type of error results from C's syntax, which was unfortunately adopted in PHP - in allowing action inside a conditional "if ($foo = 1 + $bar)", the poor parser has no way to know if one really means 'compare' or 'assign'. This is the cause of innumerable bugs in both languages. This could be fixed by requiring assignments inside a conditional to be surrounded by block markers: "if ({$foo = 1 + $bar})".
But I like all 'scripted' languages better for my purposes (entirely applications, no device drivers or kernel work) than C and other 2nd generation languages. I've had exactly one segfault working with PHP, in nearly 20 years.
WRT feeling, yes it touches on the question of just what we are, and how are we different (in kind, or only in scale) from the robot.
I'm inclined to agree on the 'system as reality' position, mostly, for a reason that touches on your first point. The best model of how the brain works is that it is (at least) one step removed from the sensory input, and does the majority of what we call 'thinking' (also feeling, etc. in the cognitive 'mind' sense) based on a model of the inputs, not the inputs themselves. For example, IIRC it takes close to 1/2 second for signals from the skin on your toes to reach your brain, but only a small fraction of that time for signals from the skin on your ears. Your brain integrates this all to be 'simultaneous' by running about 1/2 second behind reality and fixing things up as it goes, pasting over the incongruities. So you have the field of sensory inputs, and a model of those inputs, and the brain. So in fact we ourselves are always working from a model - how is that different from a machine that we design to do the same thing?
But there is no easy answer. as the Wikipedia article on Systems Philosophy notes, the nature of systems continues to be a controversy:
An important debate in Systems Philosophy reflects on the nature of natural systems, and asks whether reality is really composed of objectively real systems, or whether the concept of “natural systems” merely reflects a way in which humans might regard the world in terms relative to their own concerns.
.
Like many other areas of study, it turns out that the best answer depends on what you are doing, and what you want to know.
Your lack of hunger thing is something that one (who is 30 lbs. overweight) might casually wish for, without realizing the consequences. I lived for a short time in a house with a 12 year old boy who had fetal alcohol syndrome. One of his symptoms was inability to feel heat - he could not tell something's temperature until it burned him. So, partly because it made little difference and partly for safety reasons he prefered his food straight out ot the refrigerator.
I would argue that hunger, like suffering, is an emotional response that is inherent in a living, intelligent being. It's different from a programmed response to a low battery condition that sends the robot to a recharging facility.
OTOH there are those who think that motivation, which is the balancing of a large variety of inputs and responses to determine a best course of action, is both a key part of intelligence and an implementable function of a neural network. This goes back to the essentially philosophical question in systems science, as to whether a 'system' that we discuss is the actual thing, or merely a model of the thing that we discuss.
There was a book (on cognitive science?) back in the early 1990s, which asserted (IIRC) that self-aware intelligence did not arise in most humans until the Renaissance. I think it also argued that most of us, most of the time, are not self-aware and intelligent even today. I won't argue for or against, but that guy down the street, well! ...
Oh, poor Siri! I dropped my iPhone in the toilet and now Siri is dead!
Yes. The paper I referenced covered this topic quite well, including citations from a number of other researchers. But AFAICT none of the folks on this thread actually went to go read even the executive summary. One person maligned me for not providing citations, and then maligned me for providing one. At least one decided that since it was linked to by the WSJ it must be evil propaganda.
Sigh. One does tire of what passes for discourse these days. I'm no great shakes and I blather on too long, but I at least _try_ to assemble a reasoned argument, and base it on my own research as well as outside references. But then, XKCD today ... :)
Sigh. No, it didn't. From the report you cited, which was done a few months after the event, before the research that the PDF I cited was done, which corrects some of the early analysis as a result of better knowledge and research:
At 2:32 p.m., against this backdrop of unusually high volatility and thinning liquidity, a large
fundamental5 trader (a mutual fund complex) initiated a sell program to sell a total of 75,000 E-
Mini contracts (valued at approximately $4.1 billion) as a hedge to an existing equity position.
This order was similar to one performed a few months earlier, which was spread over six hours with no effect on the market. This time it was spread over only 20 minutes - big mistake. This is not HFT, in fact it was partly manual. It involved the 'largest net change in daily position of any trader in the E-mini in the last year.'
Note that the original erroneous Sell algorithm was still pushing the stock orders throughout the period, including attempts during the five second halt.
Much of the further decline was driven by algorithmic trading - only some of which is HFT. Every algorithm that sees the market falling off a cliff is going to try to get out before it's too late. The HFTs (as we later learned) were sopping up a lot of that sell side activity, until they too hit their stop levels.
Whether trading decisions are based on human judgment or a computer algorithm, and
whether trades occur once a minute or thousands of times each second, fair and orderly
markets require that the standard for robust, accessible, and timely market data be set quite
high. Although we do not believe significant market data delays were the primary factor in
causing the events of May 6, our analyses of that day reveal the extent to which the actions of
market participants can be influenced by uncertainty about, or delays in, market data.
The Sell Algorithm used by the large Fundamental Seller responded to the increased volume
by increasing the rate at which it was feeding the orders into the market, even though orders
that it already sent to the market were arguably not yet fully absorbed by fundamental buyers
or cross-market arbitrageurs. In fact, especially in times of significant volatility high trading
volume is not a reliable indicator of market liquidity.
Once the HFTs and other buyers had sopped up all possible liquidity, with further sell pressure from the Seller, there was nowhere to go. At that point the HFTs, along with algorithmic non-HFT, EFTs, and everyone else, began to unload the positions that they had taken, which combined with the continuing Seller activity, took the market farther down.
But the key fact is this demonstration of how effectively the market was able to recover:
time to react and verify the integrity of their data and systems, buy-side and sell-side interest
returned and an orderly price discovery process began to function. By approximately 3:00
p.m., most securities had reverted back to trading at prices reflecting true consensus values.
From the PDF I cited earlier:
Over the past decade, HFT has increased sharply, and liquidity has steadily improved. But correlation is not necessarily causation. Empirically, the challenge is to measure the incremental effect of HFT beyond other changes in equity markets. The best papers for this purpose isolate market structure changes that facilitate HFT. Virtually every time a market structure change results in more HFT, liquidity and market quality have improved because liquidity suppliers are better able to adjust their quotes in response to new information.
Based on the vast majority of the empirical work to date, HFT and automated, competing markets improve market liquidity, reduce trading costs, and make stock prices more efficient. Better liquidity lowers the cost of equity capi
If you read the PDF, you'll see that I'm very much in line with the regulators and economists, although taking a slightly different perspective (I look at the global markets as a complex adaptive system, which is a bit past the standard econometric models, which amount to a special case of the CAS model.) The regulators have looked at things like transaction taxes (as discussed in the infamous PDF), and found that the empirical evidence shows such taxes would have the opposite effect of the one desired - they decrease liquidity and increase volatility. And the exchanges and regulators established some mechanisms (mostly a few years ago) to deal with the potential issues, which so far seem to work pretty well.
I suggest that you answer the arguments presented, rather than expect any readers of this discussion to read long external PDFs. Or were you counting on that they wouldn't and simply assume that it would back you, since you linked to it?
Why? I answered the arguments multiple times on this thread, and folks asked for citations. So there's a citation, that incorporates another 40 or so citations of actual, real, research by actual, real, university researchers who actually know something. the PDF is also, for those who actually want to learn something, a pretty substantive piece of educational material in its own right, which was originally linked by someone else who thought folks might actually want to learn something.
I can only beat a dead horse so many times before I get bored.
Bah.
Read the PDF. The evidence is in the PDF. One example from the paper: the May 2010 crash was not caused by HFT. Its effect was _moderated_ by HFT, until the HFT traders couldn't take any more and got out of the market. That's when things went south. The SEC stopped trading for five minutes to give time for things to settle out, and when trading started back up the HFT were instrumental in bringing things back to normal within 20 minutes.
I won't argue that HFT has a potential for exacerbating things under certain circumstances - though the evidence is that it is much more likely to moderate things according to the research cited in the paper - and the exchanges and regulators have put in place mechanisms to deal with those events, such as the five minute halt cited, and per-stock 'circuit breakers' that can stop trading in any stock when movement goes outside of reasonable bounds. They've also instituted other mechanisms to prevent various abuses that have always been there, but were also exploited on the smaller time scales of HFT. It was much more likely to occur back when the algorithms were primitive, the regulations were not in place, and the number of different algorithms was small.
I suggest you read this PDF, which was posted by someone else but has some very good information. It's quite an education. (I had trouble opening, had to download it.)
1. See This PDF.
2. Economic policy is (generally, or rather a subset of) social policy. There are lots of papers out there showing that using taxation to accomplish a social (or economic) objective is rife with unintended consequences and perverse incentives. Just as a direct example, according to the PDF above, both theoretical and empirical research has shown that imposing a transaction tax on trades has the effect of reducing liquidity, increasing volatility, increasing the cost of trades for retail customers, and reduces stock prices substantially. These are generally the opposite of the desired effect.
Not to mention that this also drives the market to other jurisdictions - when Sweden imposed a 1% transaction tax they lost over 60% of their market to London, and even after eliminating the tax, 20 years later those customers (and jobs) have never returned.
It's true, I've blathered on beyond all sensibility. There's just so much misinformation and folks believing what the unedumacted media say about this stuff, forgetting the nearly nobody in the media has ever so much as taken an Economics course.
Case in point - analysis has shown that the flash crash in May 2010 was not caused by HFT (the PDF linked below talks about this in several places). It was in fact greatly moderated by HFT, until the HFT traders went past their own circuit breakers and withdrew from the market. Then, after a five minute 'rest' period instituted by the SEC, the HFT went back to work and everything was back to normal within 20 minutes. But ask anybody who reads the 'news', and they'll spout the media line that HFT caused the flash crash.
TFA provides pretty good evidence:
1) profits per trade are down by some 90% (IIRC what TFA said);
2) actual revenues are down by a factor of three according to the PDF below;
3) many institutions have left the business or gone bust because they couldn't compete as the market matured;
4) HFT has become an essential element of almost all market activity - according to SEC, 68% of large cap stock trades are made using HFT (this last item is in the link below);
5) 'Everybody' is now doing it - your neighborhood broker uses HFT to complete your trade of 10 shares of IBM.
IOW, HFT has transitioned from being the hot new way to make $zillions to the new combination of the ticker tape and the market makers. (but 'tis true, there are several kinds of HFT.)
And SEC is considering _requiring_ HFT traders to stay in the market during 'flash' events, because they are instrumental in reducing the impact of those events. (again, read the PDF, all the way through.)
These are all classic elements of a busted tech bubble. From Econ 102, the interesting thing about tech bubbles (which HFT certainly exemplifies) is that in the bubble the majority of the original players - sometimes 99%, sometimes less, drop out, are merged out of existence, or otherwise leave the market; and ten years later, _almost without exception_ the market is more than four times the size as it was at the peak of the bubble.
This was posted by someone else, and covers the topic pretty well. (I had to click the download link from the apparent PDF, then read it from the file manager - YMMV).
haha. true. :D