Ok, cool, so you've looked at the offerings,
and you've looked at the source, and at the
timings, and you have some interest, apparently,
in the fastest possible XML parsing.
So, what would you say? I know for
some applications you'd want XML to be as
fast as possible -- but would you call it
downright slow, the way so many others commenting
on this article have?
I forgot to mention that I also experimented
with a binary version of the XML format, and
although of course it was faster, it was
nothing like 10 times as fast.
It seems to me that a lot of people blame
XML for being "too slow" without adequately
investigating the subject. Some database
project uses XML, and it was slow, so it
must be XML's fault. That sort of thing.
I'm not an XML fanatic -- it's just a data
exchange format -- but I like the fact that
it's human readable. Most of the alternatives
people suggest are not.
"I don't know why people don't rebel against this and make faster XML parsers the widely-used ones; for whatever reason, apparently everyone continues using slow parsers."
Maybe it's becuase there are people out there who've written parsers that are "100 fold faster" and don't make them available.
Well said. But I didn't have a choice, management
was going through a freakish anti-open-source phase
right then, and I was just a contractor with no
bargaining power.
Also, from my point of view, XML parsers aren't
rocket science, so until today's discussion I
didn't think it was that big of a deal. (I'm still
not sure that it is.)
P.S. I do try sometimes. I donated the first
version of the C library (the core of it...string
funcs, printf, etc) to Stallman back in the 80s.
He threw the entire thing away and had someone else
write a new one, and told me only after the fact that
he did so -- all because he thought that my
decimal-ascii to integer conversion (in printf/scanf)
was too slow. I could've fixed it. Annoying.
Linus has ignored some of my kernel submissions too;
he's famous for that. But there are more hurdles to
contributing free source than people generally
acknowledge.
that is a pretty bold claim. it's either a lame troll, or you're god.
I'm not trolling, I'm not exaggerating, and although
I'm pretty good at making things run extremely fast,
last time I looked I was only a mortal. It's true
I fixed someone's bug recently and he did say
I was
a god, but I'm pretty sure that was just hyperbole.:-)
I mentioned "several years ago", "SAX/DOM", and
IBM -- we were using the SAX/DOM package originally
written by IBM (this was at go.com, if that helps), and it appeared to be practically
an industry standard at that time, at least from
what multiple people told me.
Yet it was buggy
and slow -- which annoyed me at the time, and here
people are claiming that whatever XML parsers they are
using (most of the comments didn't mention), they're slow today too...that's what I
was responding to.
Nowhere did I claim that I have one that is 100
fold faster than whatever is fastest today; I haven't
followed the different XML parsers as they've been
introduced. I don't even know what was the fastest
available when I did this 5 years ago; after some
unsuccessful searching I gave up and wrote a new one,
because it's trivial (I'm a compiler guy, among
other things).
The point I'm making is simple: either XML parsers
are very fast...which I know is possible, because I
created one...and people's complaints are unwarranted,
or else they are using XML parsers that are much
slower than they should be, and they should switch.
So if the XMLbench URL you provided leads people
to much faster parsers, great. If they don't need
to switch, then they don't need to complain, either.
Again, the point is that XML is not inherently slow.
That point stands.
This is also just common sense. Look at the syntax.
It's practically trivial. Related technologies like
Xpath, XSLT, etc etc may have their own issues, but
that's not the same as saying "XML is slow". Again,
it's not.
As I recall I timed it at 3 megabytes of XML parsed
per second on a Sparc desktop workstation of whatever
model was popular 5 years ago...I forget. It could
have been made even faster; I'm not claiming that what
I did was as fast as possible. It was enough for
it to improve on the IBM DOM/SAX parser.
P.S. Speeding things up 100-fold (when they're
dreadfully slow to start with) is not uncommon
for programmers who specialize in such things --
usually by changing the underlying algorithm
e.g. from quadratic to linear, sometimes by avoiding
virtual memory thrashing, sometimes just by vastly
simplifying crufty spaghetti code. Other times it helps to understand
cpu architecture, assembly language, compilers,
operating systems...many purely application-level
programmers don't, and hence don't see where the
code they're writing has inefficiencies.
On the other hand, sometimes it's impossible to
speed things up...if they were written by
a guru to start with, then there's nothing left to
improve.
P.P.S. The post I'm responding to suggested looking at
XMLbench at
xmlbench
. A glance at the first page makes it look
like a reasonable starting place.
XML is very fast
on
Effective XML
·
· Score: 4, Interesting
XML is heavy weight......see a huge drop in performance. This is due to the fact that parsing XML blows and eats up copious amounts of CPU and memory.
That's because everyone uses slow XML parsers.
Some years ago at one of the then-top 5 web
portals I was unhappy with the standard
SAX/DOM parser in use; it was ridiculously slow
(and buggy).
So I wrote a new one. Parsing XML became
one hundred fold faster! I timed it quite carefully.
Other people in this thread are saying "of course
XML is slower than binary formats, it's 3 times
bigger." But a factor of 3 in performance is
nothing, considering some of the advantages.
A slowdown of 100, on the other hand, is absurd.
I don't know why people don't rebel against this
and make faster XML parsers the widely-used ones;
for whatever reason, apparently everyone continues
using slow parsers.
At any rate, no, XML is not slow. It's just a simple,
easy to parse format, for which IBM and others have
written very, very slow parsers.
And everyone just assumes that it has to be slow.
Sheesh, why should an XML parser be slower than
a C++ compiler??? Come on.
the number of possible games of GO is huge, but not infinite
Pretty sure you're wrong there. Two players cooperating could play a game of go that never ends. All you need is to vary that, and you're set for infinite choices.
The "ko" (eternity) rule prevents infinite games.
But it almost doesn't matter. There are only a finite
number of possible board positions. Naively,
each spot can be empty or hold a white or black
stone, so there are no more than 3 to the power
(19*19) unique board positions (fewer, since
not all are reachable given the various rules of Go).
No matter what the precise rules of a game are,
sooner or later the game must either end, or
loop back to a previous board position.
It's true that one could figure out ways to
force an infinite sequence of increasingly
complex ways of looping through all of those
board positions, but this would be a sterile
exercise rather than a "game".
I suppose you're technically correct, though,
ignoring the Ko rule, and ignoring the fact
that we're talking about games, not just
board positions.
Anyway, that's why Go has the ko rule, and
chess has similar rules...this stuff always
comes up in practice, because some players will
do anything to avoid losing, including
aiming for infinite games. So eventually
rules get introduced to rule out infinite
games.
what would you have me do? Post the entire source of NT and VMS and then some sort of algorithm (vetted by you?) that proves that the code is different?
What you could do is e.g. post a URL that
discusses the VMS vs NT differences, rather than
continuing to make flat assertions based on your
(anonymous) authority...That's what m_pll did (thanks m_pll!),
and isn't this interesting, the
Win NT magazine article
highlights
the zillion ways that NT is based on
VMS. Some highlights:
- "[the VMS] kernel and Executive subsystems are clear predecessors to NT's"
- "In developing NT, these designers rewrote VMS in C, cleaning up, tuning, tweaking, and adding some new functionality and capabilities as they went...
Nevertheless, the migration of VMS internals to NT was so thorough that within a few weeks of NT's release, Digital engineers noticed the striking similarities."
- "Those similarities could fill a book. In fact, you can read sections of VAX/VMS Internals and Data Structures (Digital Press) as an accurate description of NT internals simply by translating VMS terms to NT terms."
- "NT's processes are virtually the same as VMS's processes."
- "Microsoft added lightweight user-mode threads support to NT 4.0 in 1996, which it copied from the VMS implementation of threads."
- "NT's I/O Manager is closely based on VMS's I/O Manager. Both OS's I/O Manager support a layered-driver model throughout the device driver stacks for different device types and implements asynchronous packet-based I/O commands, and its device drivers dynamically load and unload."
- "As you can see by comparing Figure 2 and Figure 3, page 117, the Executive subsystems exhibit the most significant resemblance between VMS and NT. But many minor similarities exist in which it is clear that Microsoft derived NT's capabilities from VMS."
- "...Therefore, VMS's security implementation is the predecessor to NT's. Microsoft even included systems tools similar to VMS's in NT, including the Performance Monitor, which is based on MONITOR, the extensible VMS performance monitor. VMS included a utility called BACKUP long before Microsoft developed NT's backup utility."
- "...Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars."
So, before I was just asking, not making an assertion.
But NOW I will make the assertion: NT is clearly
derived from VMS, based on the above facts.
And for this I get slammed by a bunch of anonymous
cowards and anonymous supposed NT developers? Give me a break.
All I did before was ask for facts rather than assertions.
What I got were some angry but empty words. Rather telling.
This is some of the most absurd reasoning I have ever seen on Slashdot. I am simply astonished at its fallacy
It wasn't "reasoning". It was saying, "you're
presenting what seems to be a minority opinion,
please give further info rather than just a flat
assertion." In other words, it was a request
for information.
Please try to read a little more carefully;
it's going pretty far astray to have strong
disagreements with people who aren't making
claims in the first place.
Linux can be secure, but it just isn't as easy as the Open Source world tries to create. The Myth becomes so predominate that people install Linux and just assume that their computers are more secure, and hence never take into account updates, patches, or basic security measures....
Tell the truth, all systems are susceptible, no matter who makes it. All it takes is time and a smart mind to virtually get into anything.
There's a lot of truth to this. But it misses
the point that, if you try, it's much easier
to make Unix/Linux systems relatively secure, whereas
it's an uphill battle with Windoze. Until
recently, Microsoft gave the appearance that
they didn't even care very much how secure
their software was, regardless of whether the
customer cared or not.
You are correct in that this is almost
a side issue, given that it is not easy on
any system, and most people don't try hard
enough on any system.
But that doesn't mean that all systems
are therefore equal.
When I made my comment, the grandparent article
was "+3 informative", which I thought was
extremely inappropriate.
Now it is "+5 funny". I have no problem with
it being "funny". I do have a problem with
it being considered "informative", and
I tried to explain why.
Those moderators who struck me down by 2 points:
I sure hope it was because you thought I
was arguing with it being funny...because
if you thought I was being unreasonable
saying it was not informative, then you're crazy.
It was not informative, it was wrong.
Funny, on the other hand, is a horse
of a different color.
This is basically a comment for any meta-moderators
who are looking at context.
My response was not flamebait, it
was correcting erroneous statements.
99% of the time slashdot moderation seems to
work very well, but once in a while it
gets very weird.
(Although maybe I'm philosophically wrong
in thinking that something should be
factually correct before being moderated
as "informative"???)
I was a software engineer and lead in Systems at Microsoft for 13 years. I worked on several OS projects including windows NT. So I quote myself as an authority: NT is not VMS.
I'm sorry, I don't see how that statement
says that you can guarantee that NT wasn't derived
from NT. It seems to me you are saying you know
a lot about NT. I don't see anything there
that says that you know VMS, nor about
the origin of NT.
I myself "worked on several OS projects"
but that doesn't mean I know their origins.
"An authority" is not just someone who knows
a lot; it's someone who knows a lot on
the subject under discussion...not
just one close to it...wouldn't you agree?
Anyway, even if you were David Cutler himself,
please don't just ask us to take things on
authority; give us some details to illustrate
the point at hand. "You can see that NT
is importantly different from VMS because..."
(The ancient greeks discovered a number
of important logical fallacies; one of them was
called "argumentum ad hominem", in Latin:
arguing that something is necessarily true
because a respected person said that it is so.)
While one of the Architects of NT was also an architech of VMS, the two OS's are completely different. NT was written from scratch.
To say that NT is VMS is like saying "IT" is the same as "Dreamcatcher" because they had the same author.
I don't know the truth of this one way or the
other. I know the broad history of NT, of VMS,
of the people involved, and I know a little of
the APIs of various versions of the two systems...
and have done some NT and some VMS programming...
but nonetheless, I don't know enough to know for
sure one way or the other.
What I do know is that an awful lot of people
who know more than I, contradict you. You seem
to have the minority opinion.
So, to educate all of us, please give some pointers
to information to support your opinion, rather
than merely the opinion itself.
UNIX: A rough implementation of Multics, written expressly so that Ken Thompson and Dennis Ritchie could port a game called Space Travel to old, cheap hardware.
Who's got new ideas now?
Please mod parent back down to normal. He has a
highly misleading
view of history that has been modded up to +3.
Misleading item #1: "Linux is a clone of Minux,
itself a clone of Unix". Completely incorrect,
although seemingly-plausible to newbies due
to the historical association of these things.
I evaluated Minix back when it was hot stuff, and
I rejected it precisely because it was not
a clone of Unix. It was a toy version of
Unix. If it had been a good clone, I would have
used it, no problem.
A few years later, I evaluated Linux. It was
not a toy version of either Minix nor
Unix, it was a true clone of Unix. So I started
using it.
Now, ok, Linux was a true clone of Unix back then,
this much is true (although not quite what the poster
said), and hence yes, Linux back then was not a new
idea.
But so what? The point is that it was a FREELY
AVAILABLE, OPEN SOURCE clone of Unix --
which is exactly what millions of us were waiting
for. Minix wasn't real Unix...BSD was, but wasn't
freely available back then...Linux was a god send.
Misleading item #2: "UNIX: A rough implementation of Multics, written expressly so that Ken Thompson and Dennis Ritchie could port a game called Space Travel to old, cheap hardware."
No, Unix is not any kind of version of Multics, that
is just plain wrong. Sure, it borrowed a few ideas;
the Unix authors were involved in authoring Multics,
so surely that is no surprise. But "a version of"?
No. Wrong. Completely wrong.
As for "Written so that...Space Travel..." could run
on some platform? Sure, that's part of the
history...so what? The question is, what did they
come up with as a result?
The parent post is a cynical, distorted view
of history that is grinding an axe to achieve
an agenda. Please mod it back down to a normal +1
opinion. It is NOT
insightful nor informative.
Actually, the computer could win if the axiom of choice happens to be true. Even if that isn't true, a computer could still beat every human on earth.
--
Be incomprehensible. If they can't understand you, they can't disagree with you
Are you trying out an application of your.sig here?
Because (1) the axiom of choice only applies to infinite
sets, whereas the number of possible games of GO is huge,
but not infinite,
and (2) The axiom of choice is not an open question that
may "happen" to be true or not; it has been
proven to be independent
of the other typically used axioms. You can
declare it to be either true or false, and
either way, develop an interesting branch
of math that depends on your choice --
as many mathematicians have done.
In other words,
your.sig philosophy of "if you can't dazzle
'em with brilliance, baffle 'em with BS"
isn't cutting it this time around.:-)
Something as intense as calculations for chess really much push the brain to its "limits."
Sure, but:
The X3D technology fools the brain into seeing 3D.
I wonder how much this 50% lack of visual stimuli changes the way the chessmaster's brain works here.
No effect whatsoever, because there is no
"50% lack of visual stimuli".
Anything that flickers fast enough
is perceived by the retina itself as
a solid unchanging image.
The "critical flicker fusion rate" that
determines "what is fast enough" varies
from about 40 frames per second to about 80
frames per second, depending on image brightness,
ambient illumination, the particular individual
viewing it, etc.
TV in the US, for instance, flickers at about
60 hertz, but in non-flourescent ambient illumination,
most people don't notice. In Europe the rate is
50 hertz, and people frequently do notice.
And some people get headaches from computer monitors
that flicker even at 72 hertz, especially
under flourescent lights.
I used to regularly get annoyed at PC monitors
in conference rooms flickering at 60 hertz,
when others didn't notice -- so I'd bring
up display preferences and set it at the
highest refresh rate. Until it occured to
me that I was sabotaging people who needed
to interface it to the overhead projector
at 60 hertz. Oops!:-) But I digress.
Movies are displayed at 48 hertz (although only
24 unique frames per second; they are
"double-shuttered" to double the frame rate). Cartoons sometimes
have as few as 6 unique frames per second (although
they are displayed at movie or tv flicker rates)
because that's about the threshold for perceiving
continuous motion. Lots of issues, lots of
thresholds.
But even if the 3D viewing shows perceptible flicker,
there isn't any issue of "50% lack of visual stimuli".
Both eyes are constantly receiving information.
I could imagine that any number of things about
this 3D gadget could distract a chess player --
but so does cigar smoke (a trick used to advantage
in chess matches early in the 20th century).
Years ago I used to use similar 3D goggles to
play first person shooters like Quake, and it
was great. It helped my game. Quake isn't chess,
but 3D goggles aren't rocket science.
You can assume that, if he agreed to use this
3D setup, he was confident it wouldn't throw off
his game. He does care, after all.
Don't feel bad...sure, it's embarassing,
but it turns out there are only a few ways
to checkmate someone in the first 10 moves
of the game, and it only takes about
half an hour of instruction to learn
how to avoid all of them.
In other words, you could almost instantly
become unbeatable! Well, within those
first 10 moves, anyway.:-)
The next level of difficulty after that is
to learn the basics of opening development --
how to get all of your pieces out and mobile
while maintaining a good defensive position,
and having some notion what to do if the other
guy gets aggressive and starts trading pieces with
you.
With instruction from a friendly player who
already knows that much, you can develop those
basic ideas in perhaps only a few dozen games.
And you can't be that bad of a player, or
else you couldn't have won that game against the
Chessmaster 2100. Take heart.
But you are very unlikely to learn from other
bad players, nor from poor sports, like that duffer
who overturned the chess pieces because he won
too easily.
This was a real posting to a job list a few
months ago:
> From: Jenny Richards [mailto:..........@yahoo.com] > Sent: Friday, May 09, 2003 11:11 AM > To:.........@yahoogroups.com > Subject: [.......] Entry level programmer in Duluth, MN > > Location : Duluth, MN > Term : 1 year > Rate : $5.10 / hour > > Requirements: > > - 21+ years of J2EE Development. > - Fluent Sanskrit. > - PhD in Computer Science and 17th Century French Poetry. > - Must have had 4 or more products that sold 1,000,000 copies. > - Must be a member of the Mayflower Society. > > Locals to Duluth given preference. > All requirements are mandatory, so don't waste my time by sending my > your pathetic resume unless you're a perfect fit.
It was real posting to a real job list, which
I thought was very funny, but the poster
got banned from the list for their sense of
humor.
Yes. Because routers route, period. And when they route, they're supposed to route correctly. Opt-out is bullshit, because it's saying "our product ships broken, until you unbreak it."
That's very true, but this is even worse -- there
is no error indication, no http 404, no low level
checksum error, no TCP timeout -- it LOOKS
like everything worked. Only a human watching a browser
will see the failure.
I use wget and other http tools rather heavily.
I could imagine not seeing the ad-damage for weeks,
but meanwhile having things screwed up behind the
scenes (e.g. wget-to-mirror-archive, something
I do a lot).
I don't know why no one has mentioned this yet,
because it really is the worst aspect of it
(other than Belkin's attitude, that is).
I don't think that apologizing and patching their
product is sufficient -- not that a company with
that much chutzpah is likely to back down anyway.
Let the SOBs just die -- permanent boycott!
Your idea about a "60 Hz notch filter" is as
absurd as I have ever read on/.
Oh come now, there's any amount of incredibly
absurd stuff here.:-)
The filter thing isn't utterly absurd, I
was just mixing up several different related
subjects. Like I said, the proposal didn't
become a reality...but here's
one post I just found in searching to demonstrate
that I didn't just make it up:
msg01163
Otherwise, forget I said anything -- that's
what I get for posting hurriedly on the basis
of very old memories.
"Any kind of statistical extrapolation, as opposed to intensive direct counting, relies on knowing the underlying distribution of the data. If you don't know the general curve(s) the data lies on, then you can't extrapolate, period."
What about CLT?
The Central Limit Theorem? What about it?
It just says that an infinite series of convolutions
of many kinds of distributions tends in the limit
towards a Gaussian.
Let's say you know that a distribution is
normal, but not whether it is bimodal or not.
A single small sampling cannot possibly tell you
which it is. You have to make the assumption first
(or preferably, actually know one way or the other),
and then fit to the curve. Real world data is
always noisy, remember.
Just as a BTW the central limit theorem doesn't
apply to everything. An infinite series of convolutions of
dirac deltas converges to just another delta, not
to a normal distribution. There are also any number
of assumptions about an L^2 space -- granted this
is extremely common in real life, but other
spaces with wildly different norms are possible,
albeit generally ignored by statisticians.
In other words, typical practice only works most
of the time, but it is completely unwarranted to
assume that that means that it will always
work. There's no mathematical, scientific, nor
philosophical basis for such an assumption.
And coming back to the subject at hand,
and getting very explicit, the distribution being
sampled is not necessarily Gaussian. Maybe
for some reason it is best fit by a nice
cubic, or even a plain old straight line,
due to an underlying causal factor. If
you don't know that little fact, and just
assume a Gaussian in going from the sampling
to a statement about the entire population,
then you've just plain screwed up.
Thus my original statement: you need to
know something about the underlying distribution.
You can't generate information from nothing;
this isn't just a matter of statistics, it's
even more fundamentally a matter of information
theory.
Garbage in, garbage out.
Bluetooth will fail because [...]
Low speed, short range: 39KHz IR or 433MHz AM
High speed, short range: IRDA
High speed, long range: 802.11a/b/g
Can somebody tell me exactly where bluetooth's niche is?
From 50,000 feet many technologies look the same, so
your bullet points don't really matter.
VHS beat Beta for secondary reasons, even though
Beta was the better technology.
When the Amiga and the Atari ST came out to challenge
the Mac, they looked alike from 50,000 feet
(but short term, the ST won over the hearts of
musicians and the Amiga won over the niche of
video).
Back in the 60s, when IBM brought out EBCDIC
to challenge ASCII, they looked the same from
50,000 feet, and there were religious wars.
These days there are religious wars over
Java versus C++, even though they look the
same from 50,000 feet (e.g. to a not
very technical CEO).
But partisans always realize that God (or the Devil)
"is in the details".
Now, you didn't mention "non-line-of-sight" explicitly,
but that's one clear advantage of Bluetooth over
IRDA, just as a BTW. The advantage of Bluetooth
over 802.11blah is in positioning and intended
use. People keep saying 802 could do
everything Bluetooth is intended for, but
there's no standard or marketing intention of
having it do the same stuff that I've
ever heard of.
P.S. what's this 433 Mhz AM that competes with
Bluetooth? Never heard of it.
It's only possible when you have a representative sample. If you have a systemic bias in your sample then there is nothing you can do to correct this, and your extrapolation is going to be invalid. An example could be trying to estimate household income by a telephone income. Those on a low income are less likely to have a telephone, and therefore you estimate the average income too high. In this case, those who know their computers are being monitored may choose to not do things which people who are not being monitored may choose to do.
You are correct that such things are an issue, but
you are incorrect in saying "there is nothing you
can do to correct this".
In the example of phoning people and asking their
incomes, for instance, you can correct for the
bias easily if you use a different technique that
addresses that particular issue head-on: do
an expensive but small survey of a random selection
of the entire population, and from that, find
out what percentage have no phone and low income,
no phone and high income, phone and low income,
phone and high income. This difficult and expensive
information can then be used to extrapolate the
information discovered in a larger (and cheaper
per capita) study.
Here's another way to put it. Any kind of
statistical extrapolation, as opposed to intensive
direct counting, relies on knowing the underlying
distribution of the data. If you don't know the general
curve(s) the data lies on, then you can't extrapolate,
period.
Fortunately (for statistics folks), there are many
ways to determine the nature of the underlying
distributions. Then, knowing those, you can then
reliably extrapolate a finite sample into
a determination of the behavior of the entire
population (modulo issues of precision, accuracy,
random and systematic experimental error, etc,
all of which are routinely dealt with by
hardcore scientists such as particle physicists,
and alas, too often dealt with poorly by
social scientists).
Nonetheless, the better soft scientists (and
better reputable pollsters) can and do approach
these things the right way -- that is, doing it
the way that our huge body of math and science
informs us is the best practice.
All of that is, of course, a different question
than whether this study used best practice.
Some here have said they are reputable, and so they
must have, but the results are extraordinarily
counter-intuitive, so I, for one, refuse to believe
that they used best practice until I see some
better proof of the fact.
Slashdot Mirror
So, what would you say? I know for some applications you'd want XML to be as fast as possible -- but would you call it downright slow, the way so many others commenting on this article have?
I forgot to mention that I also experimented with a binary version of the XML format, and although of course it was faster, it was nothing like 10 times as fast.
It seems to me that a lot of people blame XML for being "too slow" without adequately investigating the subject. Some database project uses XML, and it was slow, so it must be XML's fault. That sort of thing.
I'm not an XML fanatic -- it's just a data exchange format -- but I like the fact that it's human readable. Most of the alternatives people suggest are not.
Well said. But I didn't have a choice, management was going through a freakish anti-open-source phase right then, and I was just a contractor with no bargaining power.
Also, from my point of view, XML parsers aren't rocket science, so until today's discussion I didn't think it was that big of a deal. (I'm still not sure that it is.)
P.S. I do try sometimes. I donated the first version of the C library (the core of it...string funcs, printf, etc) to Stallman back in the 80s. He threw the entire thing away and had someone else write a new one, and told me only after the fact that he did so -- all because he thought that my decimal-ascii to integer conversion (in printf/scanf) was too slow. I could've fixed it. Annoying.
Linus has ignored some of my kernel submissions too; he's famous for that. But there are more hurdles to contributing free source than people generally acknowledge.
I'm not trolling, I'm not exaggerating, and although I'm pretty good at making things run extremely fast, last time I looked I was only a mortal. It's true I fixed someone's bug recently and he did say I was a god, but I'm pretty sure that was just hyperbole. :-)
I mentioned "several years ago", "SAX/DOM", and IBM -- we were using the SAX/DOM package originally written by IBM (this was at go.com, if that helps), and it appeared to be practically an industry standard at that time, at least from what multiple people told me.
Yet it was buggy and slow -- which annoyed me at the time, and here people are claiming that whatever XML parsers they are using (most of the comments didn't mention), they're slow today too...that's what I was responding to.
Nowhere did I claim that I have one that is 100 fold faster than whatever is fastest today; I haven't followed the different XML parsers as they've been introduced. I don't even know what was the fastest available when I did this 5 years ago; after some unsuccessful searching I gave up and wrote a new one, because it's trivial (I'm a compiler guy, among other things).
The point I'm making is simple: either XML parsers are very fast...which I know is possible, because I created one...and people's complaints are unwarranted, or else they are using XML parsers that are much slower than they should be, and they should switch.
So if the XMLbench URL you provided leads people to much faster parsers, great. If they don't need to switch, then they don't need to complain, either.
Again, the point is that XML is not inherently slow. That point stands.
This is also just common sense. Look at the syntax. It's practically trivial. Related technologies like Xpath, XSLT, etc etc may have their own issues, but that's not the same as saying "XML is slow". Again, it's not.
As I recall I timed it at 3 megabytes of XML parsed per second on a Sparc desktop workstation of whatever model was popular 5 years ago...I forget. It could have been made even faster; I'm not claiming that what I did was as fast as possible. It was enough for it to improve on the IBM DOM/SAX parser.
P.S. Speeding things up 100-fold (when they're dreadfully slow to start with) is not uncommon for programmers who specialize in such things -- usually by changing the underlying algorithm e.g. from quadratic to linear, sometimes by avoiding virtual memory thrashing, sometimes just by vastly simplifying crufty spaghetti code. Other times it helps to understand cpu architecture, assembly language, compilers, operating systems...many purely application-level programmers don't, and hence don't see where the code they're writing has inefficiencies.
On the other hand, sometimes it's impossible to speed things up...if they were written by a guru to start with, then there's nothing left to improve.
P.P.S. The post I'm responding to suggested looking at XMLbench at xmlbench . A glance at the first page makes it look like a reasonable starting place.
That's because everyone uses slow XML parsers. Some years ago at one of the then-top 5 web portals I was unhappy with the standard SAX/DOM parser in use; it was ridiculously slow (and buggy).
So I wrote a new one. Parsing XML became one hundred fold faster! I timed it quite carefully.
Other people in this thread are saying "of course XML is slower than binary formats, it's 3 times bigger." But a factor of 3 in performance is nothing, considering some of the advantages.
A slowdown of 100, on the other hand, is absurd.
I don't know why people don't rebel against this and make faster XML parsers the widely-used ones; for whatever reason, apparently everyone continues using slow parsers.
At any rate, no, XML is not slow. It's just a simple, easy to parse format, for which IBM and others have written very, very slow parsers.
And everyone just assumes that it has to be slow. Sheesh, why should an XML parser be slower than a C++ compiler??? Come on.
Yes; thanks for giving interesting food for thought. Before you raised this, I thought I had a stronger point.
The "ko" (eternity) rule prevents infinite games. But it almost doesn't matter. There are only a finite number of possible board positions. Naively, each spot can be empty or hold a white or black stone, so there are no more than 3 to the power (19*19) unique board positions (fewer, since not all are reachable given the various rules of Go).
No matter what the precise rules of a game are, sooner or later the game must either end, or loop back to a previous board position.
It's true that one could figure out ways to force an infinite sequence of increasingly complex ways of looping through all of those board positions, but this would be a sterile exercise rather than a "game".
I suppose you're technically correct, though, ignoring the Ko rule, and ignoring the fact that we're talking about games, not just board positions.
Anyway, that's why Go has the ko rule, and chess has similar rules...this stuff always comes up in practice, because some players will do anything to avoid losing, including aiming for infinite games. So eventually rules get introduced to rule out infinite games.
What you could do is e.g. post a URL that discusses the VMS vs NT differences, rather than continuing to make flat assertions based on your (anonymous) authority...That's what m_pll did (thanks m_pll!), and isn't this interesting, the Win NT magazine article highlights the zillion ways that NT is based on VMS. Some highlights:
- "[the VMS] kernel and Executive subsystems are clear predecessors to NT's"
- "In developing NT, these designers rewrote VMS in C, cleaning up, tuning, tweaking, and adding some new functionality and capabilities as they went...
Nevertheless, the migration of VMS internals to NT was so thorough that within a few weeks of NT's release, Digital engineers noticed the striking similarities."
- "Those similarities could fill a book. In fact, you can read sections of VAX/VMS Internals and Data Structures (Digital Press) as an accurate description of NT internals simply by translating VMS terms to NT terms."
- "NT's processes are virtually the same as VMS's processes."
- "Microsoft added lightweight user-mode threads support to NT 4.0 in 1996, which it copied from the VMS implementation of threads."
- "NT's I/O Manager is closely based on VMS's I/O Manager. Both OS's I/O Manager support a layered-driver model throughout the device driver stacks for different device types and implements asynchronous packet-based I/O commands, and its device drivers dynamically load and unload."
- "As you can see by comparing Figure 2 and Figure 3, page 117, the Executive subsystems exhibit the most significant resemblance between VMS and NT. But many minor similarities exist in which it is clear that Microsoft derived NT's capabilities from VMS."
- "...Therefore, VMS's security implementation is the predecessor to NT's. Microsoft even included systems tools similar to VMS's in NT, including the Performance Monitor, which is based on MONITOR, the extensible VMS performance monitor. VMS included a utility called BACKUP long before Microsoft developed NT's backup utility."
- "...Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars."
So, before I was just asking, not making an assertion. But NOW I will make the assertion: NT is clearly derived from VMS, based on the above facts.
And for this I get slammed by a bunch of anonymous cowards and anonymous supposed NT developers? Give me a break.
All I did before was ask for facts rather than assertions. What I got were some angry but empty words. Rather telling.
It wasn't "reasoning". It was saying, "you're presenting what seems to be a minority opinion, please give further info rather than just a flat assertion." In other words, it was a request for information.
Please try to read a little more carefully; it's going pretty far astray to have strong disagreements with people who aren't making claims in the first place.
There's a lot of truth to this. But it misses the point that, if you try, it's much easier to make Unix/Linux systems relatively secure, whereas it's an uphill battle with Windoze. Until recently, Microsoft gave the appearance that they didn't even care very much how secure their software was, regardless of whether the customer cared or not.
You are correct in that this is almost a side issue, given that it is not easy on any system, and most people don't try hard enough on any system.
But that doesn't mean that all systems are therefore equal.
Now it is "+5 funny". I have no problem with it being "funny". I do have a problem with it being considered "informative", and I tried to explain why.
Those moderators who struck me down by 2 points: I sure hope it was because you thought I was arguing with it being funny...because if you thought I was being unreasonable saying it was not informative, then you're crazy. It was not informative, it was wrong.
Funny, on the other hand, is a horse of a different color.
This is basically a comment for any meta-moderators who are looking at context. My response was not flamebait, it was correcting erroneous statements.
99% of the time slashdot moderation seems to work very well, but once in a while it gets very weird.
(Although maybe I'm philosophically wrong in thinking that something should be factually correct before being moderated as "informative"???)
I'm sorry, I don't see how that statement says that you can guarantee that NT wasn't derived from NT. It seems to me you are saying you know a lot about NT. I don't see anything there that says that you know VMS, nor about the origin of NT.
I myself "worked on several OS projects" but that doesn't mean I know their origins.
"An authority" is not just someone who knows a lot; it's someone who knows a lot on the subject under discussion...not just one close to it...wouldn't you agree?
Anyway, even if you were David Cutler himself, please don't just ask us to take things on authority; give us some details to illustrate the point at hand. "You can see that NT is importantly different from VMS because..."
(The ancient greeks discovered a number of important logical fallacies; one of them was called "argumentum ad hominem", in Latin: arguing that something is necessarily true because a respected person said that it is so.)
I don't know the truth of this one way or the other. I know the broad history of NT, of VMS, of the people involved, and I know a little of the APIs of various versions of the two systems... and have done some NT and some VMS programming... but nonetheless, I don't know enough to know for sure one way or the other.
What I do know is that an awful lot of people who know more than I, contradict you. You seem to have the minority opinion.
So, to educate all of us, please give some pointers to information to support your opinion, rather than merely the opinion itself.
Please mod parent back down to normal. He has a highly misleading view of history that has been modded up to +3.
Misleading item #1: "Linux is a clone of Minux, itself a clone of Unix". Completely incorrect, although seemingly-plausible to newbies due to the historical association of these things.
I evaluated Minix back when it was hot stuff, and I rejected it precisely because it was not a clone of Unix. It was a toy version of Unix. If it had been a good clone, I would have used it, no problem.
A few years later, I evaluated Linux. It was not a toy version of either Minix nor Unix, it was a true clone of Unix. So I started using it.
Now, ok, Linux was a true clone of Unix back then, this much is true (although not quite what the poster said), and hence yes, Linux back then was not a new idea.
But so what? The point is that it was a FREELY AVAILABLE, OPEN SOURCE clone of Unix -- which is exactly what millions of us were waiting for. Minix wasn't real Unix...BSD was, but wasn't freely available back then...Linux was a god send.
Misleading item #2: "UNIX: A rough implementation of Multics, written expressly so that Ken Thompson and Dennis Ritchie could port a game called Space Travel to old, cheap hardware."
No, Unix is not any kind of version of Multics, that is just plain wrong. Sure, it borrowed a few ideas; the Unix authors were involved in authoring Multics, so surely that is no surprise. But "a version of"? No. Wrong. Completely wrong.
As for "Written so that...Space Travel..." could run on some platform? Sure, that's part of the history...so what? The question is, what did they come up with as a result?
The parent post is a cynical, distorted view of history that is grinding an axe to achieve an agenda. Please mod it back down to a normal +1 opinion. It is NOT insightful nor informative.
Are you trying out an application of your .sig here?
Because (1) the axiom of choice only applies to infinite sets, whereas the number of possible games of GO is huge, but not infinite, and (2) The axiom of choice is not an open question that may "happen" to be true or not; it has been proven to be independent of the other typically used axioms. You can declare it to be either true or false, and either way, develop an interesting branch of math that depends on your choice -- as many mathematicians have done.
In other words, your .sig philosophy of "if you can't dazzle
'em with brilliance, baffle 'em with BS"
isn't cutting it this time around. :-)
Sure, but:
The X3D technology fools the brain into seeing 3D. I wonder how much this 50% lack of visual stimuli changes the way the chessmaster's brain works here.
No effect whatsoever, because there is no "50% lack of visual stimuli". Anything that flickers fast enough is perceived by the retina itself as a solid unchanging image.
The "critical flicker fusion rate" that determines "what is fast enough" varies from about 40 frames per second to about 80 frames per second, depending on image brightness, ambient illumination, the particular individual viewing it, etc.
TV in the US, for instance, flickers at about 60 hertz, but in non-flourescent ambient illumination, most people don't notice. In Europe the rate is 50 hertz, and people frequently do notice. And some people get headaches from computer monitors that flicker even at 72 hertz, especially under flourescent lights.
I used to regularly get annoyed at PC monitors in conference rooms flickering at 60 hertz, when others didn't notice -- so I'd bring up display preferences and set it at the highest refresh rate. Until it occured to me that I was sabotaging people who needed to interface it to the overhead projector at 60 hertz. Oops! :-) But I digress.
Movies are displayed at 48 hertz (although only 24 unique frames per second; they are "double-shuttered" to double the frame rate). Cartoons sometimes have as few as 6 unique frames per second (although they are displayed at movie or tv flicker rates) because that's about the threshold for perceiving continuous motion. Lots of issues, lots of thresholds.
But even if the 3D viewing shows perceptible flicker, there isn't any issue of "50% lack of visual stimuli". Both eyes are constantly receiving information.
I could imagine that any number of things about this 3D gadget could distract a chess player -- but so does cigar smoke (a trick used to advantage in chess matches early in the 20th century).
Years ago I used to use similar 3D goggles to play first person shooters like Quake, and it was great. It helped my game. Quake isn't chess, but 3D goggles aren't rocket science.
You can assume that, if he agreed to use this 3D setup, he was confident it wouldn't throw off his game. He does care, after all.
Don't feel bad...sure, it's embarassing, but it turns out there are only a few ways to checkmate someone in the first 10 moves of the game, and it only takes about half an hour of instruction to learn how to avoid all of them.
In other words, you could almost instantly become unbeatable! Well, within those first 10 moves, anyway. :-)
The next level of difficulty after that is to learn the basics of opening development -- how to get all of your pieces out and mobile while maintaining a good defensive position, and having some notion what to do if the other guy gets aggressive and starts trading pieces with you.
With instruction from a friendly player who already knows that much, you can develop those basic ideas in perhaps only a few dozen games. And you can't be that bad of a player, or else you couldn't have won that game against the Chessmaster 2100. Take heart.
But you are very unlikely to learn from other bad players, nor from poor sports, like that duffer who overturned the chess pieces because he won too easily.
It was real posting to a real job list, which I thought was very funny, but the poster got banned from the list for their sense of humor.
That's very true, but this is even worse -- there is no error indication, no http 404, no low level checksum error, no TCP timeout -- it LOOKS like everything worked. Only a human watching a browser will see the failure.
I use wget and other http tools rather heavily. I could imagine not seeing the ad-damage for weeks, but meanwhile having things screwed up behind the scenes (e.g. wget-to-mirror-archive, something I do a lot).
I don't know why no one has mentioned this yet, because it really is the worst aspect of it (other than Belkin's attitude, that is).
I don't think that apologizing and patching their product is sufficient -- not that a company with that much chutzpah is likely to back down anyway. Let the SOBs just die -- permanent boycott!
See my previous interactions with dollargonzo regarding definition of "declarative", sample place where you made your comment.
Oh come now, there's any amount of incredibly absurd stuff here. :-)
The filter thing isn't utterly absurd, I
was just mixing up several different related
subjects. Like I said, the proposal didn't
become a reality...but here's
one post I just found in searching to demonstrate
that I didn't just make it up:
msg01163
Otherwise, forget I said anything -- that's what I get for posting hurriedly on the basis of very old memories.
The Central Limit Theorem? What about it? It just says that an infinite series of convolutions of many kinds of distributions tends in the limit towards a Gaussian.
Let's say you know that a distribution is normal, but not whether it is bimodal or not. A single small sampling cannot possibly tell you which it is. You have to make the assumption first (or preferably, actually know one way or the other), and then fit to the curve. Real world data is always noisy, remember.
Just as a BTW the central limit theorem doesn't apply to everything. An infinite series of convolutions of dirac deltas converges to just another delta, not to a normal distribution. There are also any number of assumptions about an L^2 space -- granted this is extremely common in real life, but other spaces with wildly different norms are possible, albeit generally ignored by statisticians.
In other words, typical practice only works most of the time, but it is completely unwarranted to assume that that means that it will always work. There's no mathematical, scientific, nor philosophical basis for such an assumption.
And coming back to the subject at hand, and getting very explicit, the distribution being sampled is not necessarily Gaussian. Maybe for some reason it is best fit by a nice cubic, or even a plain old straight line, due to an underlying causal factor. If you don't know that little fact, and just assume a Gaussian in going from the sampling to a statement about the entire population, then you've just plain screwed up.
Thus my original statement: you need to know something about the underlying distribution. You can't generate information from nothing; this isn't just a matter of statistics, it's even more fundamentally a matter of information theory. Garbage in, garbage out.
From 50,000 feet many technologies look the same, so your bullet points don't really matter.
VHS beat Beta for secondary reasons, even though Beta was the better technology.
When the Amiga and the Atari ST came out to challenge the Mac, they looked alike from 50,000 feet (but short term, the ST won over the hearts of musicians and the Amiga won over the niche of video).
Back in the 60s, when IBM brought out EBCDIC to challenge ASCII, they looked the same from 50,000 feet, and there were religious wars.
These days there are religious wars over Java versus C++, even though they look the same from 50,000 feet (e.g. to a not very technical CEO).
But partisans always realize that God (or the Devil) "is in the details".
Now, you didn't mention "non-line-of-sight" explicitly, but that's one clear advantage of Bluetooth over IRDA, just as a BTW. The advantage of Bluetooth over 802.11blah is in positioning and intended use. People keep saying 802 could do everything Bluetooth is intended for, but there's no standard or marketing intention of having it do the same stuff that I've ever heard of.
P.S. what's this 433 Mhz AM that competes with Bluetooth? Never heard of it.
1M Bluetooth/week
Same thing labelled as a factoid (not the same as a lie, mind you)
I've got enough karma, no need to mark this up.
In the example of phoning people and asking their incomes, for instance, you can correct for the bias easily if you use a different technique that addresses that particular issue head-on: do an expensive but small survey of a random selection of the entire population, and from that, find out what percentage have no phone and low income, no phone and high income, phone and low income, phone and high income. This difficult and expensive information can then be used to extrapolate the information discovered in a larger (and cheaper per capita) study.
Here's another way to put it. Any kind of statistical extrapolation, as opposed to intensive direct counting, relies on knowing the underlying distribution of the data. If you don't know the general curve(s) the data lies on, then you can't extrapolate, period.
Fortunately (for statistics folks), there are many ways to determine the nature of the underlying distributions. Then, knowing those, you can then reliably extrapolate a finite sample into a determination of the behavior of the entire population (modulo issues of precision, accuracy, random and systematic experimental error, etc, all of which are routinely dealt with by hardcore scientists such as particle physicists, and alas, too often dealt with poorly by social scientists).
Nonetheless, the better soft scientists (and better reputable pollsters) can and do approach these things the right way -- that is, doing it the way that our huge body of math and science informs us is the best practice.
All of that is, of course, a different question than whether this study used best practice. Some here have said they are reputable, and so they must have, but the results are extraordinarily counter-intuitive, so I, for one, refuse to believe that they used best practice until I see some better proof of the fact.