In case anyone is interested and wants to be fully informed what the patent [iponz.govt.nz] actually says [iponz.govt.nz] (so rare a quality in a slashdot reader I find these days), then here is the abstract:
I'd like to know what the patent actually says.
At the same time, I'm not particularly interested in what the abstract says.
we do live in a world where if you pick up a catalog to order things, there's a price for 1-25, a price for 25-50 and a price for 100+, the more you buy the cheeper you get what you want.
More to the point, we don't live in a world where one usually sees the price depend on how few of the competitor's product you bought instead of how many you bought from them.
For what it's worth, there have been rare occasions when buying more of an item might lead to higher per unit prices.
One example involved Sony when they first started out. According to an article in one of the business journals about 20 years ago (I think it was Forbes), when Sony showed their transistor radios to one big chain, the chain asked for many more radios than Sony expected. The price Sony quoted was higher per radio than the price they quoted for a much smaller quantity of radios. The buyer from the chain was very surprised and asked why. Sony said that with an order that big, they would have to build a bigger factory to produce them and they would have to earn enough to help pay for additional production capability.
I know one company president who thinks that computers are basically just typewriters that let you save what you typed so you can make changes.
That company has nearly shut down an entire division because it takes too many people to do the work. If they would automate what they are doing, they could cut the personnel required to do the work by at least 75%.
They do everything nearly the most inefficient way possible.
It's amazing how many good ideas are "reinvented" years after they were shown to be viable.
For those who aren't familiar with the PDP-11, the I and D space allowed us to double the amount of memory allocated to a program. A program and all of its data had to fit in a very limited address space. By using I and D space, a program could double that.
Using I and D space, if a program wrote something to memory at location 4000 and then branched to location 4000, it would be two different locations in memory. That is, memory location 4000 in D space and memory location 4000 in I space were on two different pages of memory.
However, DEC didn't really use I and D space much. At least, the RSTS/E (Resource Sharing Time Sharing / Extended) operating system didn't, to the best of my knowledge, use I and D space. I asked one of the RSTS/E developers about this at a DECUS once, but didn't get much of an answer.
Using I and D space would have had some consequences. The PDP-11 instruction set included a MARK N instruction that couldn't be used in I and D space. The N of the MARK N instruction was a count of the number of arguments in a subroutine call.
When calling a subroutine using the MARK N instruction, you would push the MARK N instruction, with the appropriate N, onto the stack. When returning, you could branch to that location on the stack and execute the MARK N instruction which would perform your stack cleanup for you. So you were actually writing an instruction to memory and then later, branching to it.
I don't think that the MARK N instruction was used all that much. In one of the popular PDP-11 assembly language books, the section on the MARK N instruction was just flat wrong. It was obvious that the author had never actually used it.
At a Spring DECUS in New Orleons (1984 or 1985), in a discussion session on assembly language programming, tips, and tricks, someone asked about the MARK N instruction. The speaker/moderator asked how many people had ever actually used the MARK N instruction, but I was the only one I could see to raise a hand.
I wonder if a city could declare $1 to be fair market value per share of IBM stock and then use eminent domain to sieze the IBM stock held by people in the city, pay the $1 fair market value, and sell it to someone else for $5 per share.
(I hope no mayors, city managers,... read that. They might just try it.)
These days, the government takes land from one citizen or business so it can transfer to another citizen or business.
Their rationale is that it is okay to do that if the new owner will pay more in taxes.
Of course, the new owner, in addition to being able to receive stolen property, is often given a tax break. So it's not about increasing tax revenue -- it's about doing favors for the rich and powerful.
To some of us who came from all caps days (you couldn't even print lowercase on the printers), the lure of being able to use mixed case is just too tantalizing to ignore.
It is faster to process the data sequentially than to skip around.
That is especially true if the data elements are small such as chars. You would end up having to fetch the same data from memory multiple times in the processing of one loop compared to only once in the other loop.
Slashdot Mirror
I must have missed something.
One link showed an error. The other was a doc file that contained the abstract.
I'd like to know what the patent actually says.
At the same time, I'm not particularly interested in what the abstract says.
Has that even happened since the Louisiana Purchase?
I think they've filed pretty much the same patent in the United States and in Europe.
Some companies like the competition.
That's especially true when the competition is incompetent, and their very presence helps keep more competent companies from opening local operations.
More to the point, we don't live in a world where one usually sees the price depend on how few of the competitor's product you bought instead of how many you bought from them.
For what it's worth, there have been rare occasions when buying more of an item might lead to higher per unit prices.
One example involved Sony when they first started out. According to an article in one of the business journals about 20 years ago (I think it was Forbes), when Sony showed their transistor radios to one big chain, the chain asked for many more radios than Sony expected. The price Sony quoted was higher per radio than the price they quoted for a much smaller quantity of radios. The buyer from the chain was very surprised and asked why. Sony said that with an order that big, they would have to build a bigger factory to produce them and they would have to earn enough to help pay for additional production capability.
Those who just looked in but weren't applying didn't get accepted either.
If they are going to break into the school's computer (it doesn't matter that someone else showed them how), they shouldn't be accepted.
That depends. Which SCO-thing?
SCO vs IBM -- It's about contract issues, not copyrights. That was evident long ago.
SCO vs IBM counterclaims -- IBM wants a declatory judgement that they are not violating SCO's copyrights.
SCO vs Novell -- It's about who owns the code. Or, more precisely, is Novell making knowingly false claims when they say they own the code.
SCO vs Daimler Chrysler -- It's about timely responding to SCO's demand and whether SCO's demand was too broad given the contract involved.
SCO vs AutoZone -- SCO claims AutoZone is violating their copyrights.
Red Hat vs SCO -- Seeks a declatory judgement that they are not violating SCO's copyrights.
It could be worse.
I know one company president who thinks that computers are basically just typewriters that let you save what you typed so you can make changes.
That company has nearly shut down an entire division because it takes too many people to do the work. If they would automate what they are doing, they could cut the personnel required to do the work by at least 75%.
They do everything nearly the most inefficient way possible.
It's amazing how many good ideas are "reinvented" years after they were shown to be viable.
For those who aren't familiar with the PDP-11, the I and D space allowed us to double the amount of memory allocated to a program. A program and all of its data had to fit in a very limited address space. By using I and D space, a program could double that.
Using I and D space, if a program wrote something to memory at location 4000 and then branched to location 4000, it would be two different locations in memory. That is, memory location 4000 in D space and memory location 4000 in I space were on two different pages of memory.
However, DEC didn't really use I and D space much. At least, the RSTS/E (Resource Sharing Time Sharing / Extended) operating system didn't, to the best of my knowledge, use I and D space. I asked one of the RSTS/E developers about this at a DECUS once, but didn't get much of an answer.
Using I and D space would have had some consequences. The PDP-11 instruction set included a MARK N instruction that couldn't be used in I and D space. The N of the MARK N instruction was a count of the number of arguments in a subroutine call.
When calling a subroutine using the MARK N instruction, you would push the MARK N instruction, with the appropriate N, onto the stack. When returning, you could branch to that location on the stack and execute the MARK N instruction which would perform your stack cleanup for you. So you were actually writing an instruction to memory and then later, branching to it.
I don't think that the MARK N instruction was used all that much. In one of the popular PDP-11 assembly language books, the section on the MARK N instruction was just flat wrong. It was obvious that the author had never actually used it.
At a Spring DECUS in New Orleons (1984 or 1985), in a discussion session on assembly language programming, tips, and tricks, someone asked about the MARK N instruction. The speaker/moderator asked how many people had ever actually used the MARK N instruction, but I was the only one I could see to raise a hand.
Do you realy believe that any politician has the good of humanity in mind?
Or for that matter that any politician can truly determine what is good for humanity?
I wonder if a city could declare $1 to be fair market value per share of IBM stock and then use eminent domain to sieze the IBM stock held by people in the city, pay the $1 fair market value, and sell it to someone else for $5 per share.
... read that. They might just try it.)
(I hope no mayors, city managers,
What we really need is for patents to protect the copying the invention itself, not all independent developments of the same idea.
Anyone who independently develops an idea without looking to see how the patent holder did it should be able to use and profit by his work.
These days, the government takes land from one citizen or business so it can transfer to another citizen or business.
Their rationale is that it is okay to do that if the new owner will pay more in taxes.
Of course, the new owner, in addition to being able to receive stolen property, is often given a tax break. So it's not about increasing tax revenue -- it's about doing favors for the rich and powerful.
They definition of "fair market value" is not necessarily fair at all.
Patents aren't really evil, just misguided, but the power of eminent domain is truly evil.
I wish I'd have had a copy of that at the time.
The result of the war was that I used 8 characters and everyone else used 3 characters.
In that case, the dumb ass should be moved to something else.
To some of us who came from all caps days (you couldn't even print lowercase on the printers), the lure of being able to use mixed case is just too tantalizing to ignore.
I worked at one company years ago where we had a religious war about how many spaces to use for a tab.
You could just skip the source code and patch the executables directly.
Because of the way the data is stored.
It is faster to process the data sequentially than to skip around.
That is especially true if the data elements are small such as chars. You would end up having to fetch the same data from memory multiple times in the processing of one loop compared to only once in the other loop.
One of my favorite approaches is to write the comments before the code.
Then, if the comments need to be modified to reflect the code, change them.
I've known some very good first rate programmers who religiously put the constants on the left. I've never known a second rate programmer who did.
Why not just define a macro or inline function with a descriptive name?