Would these teflon micropoints be robust under wear or heat? For example can I make a downhil Ski out of them? What about as a bearing lubricant or coating? would the forces or heat involve crush/melt these tiny points?
I dont know. I'm just asking.
Obviously if they were bigger objects then their bulk points of failure and ability to dissipate heat would not be adequate (for teflon) but perhaps on the molecular scale these things have non-bulk shear strengths and can rapidly shed heat given a huge surface to volume ratio??
three-words: high speed condoms. I'm looking forward to condoms made from this because There's two things I've never gotten used to and that's the smell of burning rubber and screaming women.
It makes little difference if they go after mozilla or not, because they already are going to affect these other browsers. The reason being that if plugins dont work in IE then basically you will see the death of plugins.
no people will not switch browsers. if a browser does not come with MS and is not located in the prefered position MOST users, that is the majority of the comsumers, will not use it. Thus IE will remain a standard and websites will comply or die. Sure a few may write special versions for multiple browsers but whose going to be writing the plugins? Unless theres a market to sell plugins the flash producers of the world are going to shrink in number.
Perhaps you think I overestimate consumer laziness. Well BMG just copyprotected all of their CDs. Anyone cany defeat the copy protection by, get this, holding down the shift key when inserting the disk. BMG acknowledges this wont stop some people but believes it will thwart the majority. They have reason to believe in consumer laziness.
You said, " The easiest way to remember it until its habit is to substitute the full phrase in your (not you're!) sentence, and see if it works:"
In that sentence, you mixed up the common homonyms (male labia) "it's" and "its".
The word "it's" is a contraction of "it is". the term "its" is a the possesive form of "it", which is wrong unless you meant to imply that one must train the word to know "its" place in the sentence; in that case you would be correct but un drugs or maybe snorting too much fairy dust and ranting about ficticious male genetalia (homo = man, nym from nympha = labia minor.)
Yep you're answer is better than my initial post. I agree with your math. (4.8Joules/gm-C)
my post erred because the reason the water boils is not the heat flux but the stored heat in the stove top coil. The transient delivery of this stored heat vastly exceeds the rate of power delivered to the stove and thus the water boils fast. but this would not be sustained.
lets do some order of magnitude, spheical cow type estimates using simple everyday experience in the kitchen.
A typical stove top burner is order of magnitude 1000 watts spread out over around 500 sq cm: so were talking order of magnitude less than 10 watts per sq cm.
if I take a teaspoon of water an put it on a sq cm of stove top and it boils in far less than a second. really almost instantly so its probably like less than a tenth of a second.
Thus if this thing is going to not explode, the flow rate required to avoid boiling at 1000 watts/sq cm is going to be on the order of hundreds to thousands of teaspoons per second.
If I take a tiny swizzel straw and try to suck through it I cannot suck 1000 teaspoos per second. Since my ability to suck is probably within an order of magnitude of the cavitation pressure for atmospheric pressure water a pump trying to flow this stuff through an equally small crossecttion may not be able to sustain such a flow rate. And any on-chip pump is probably going to have a simmilar crossection for its fluid intake port. (off -chip is another matter)
unless this thing is actually flowing the water based on the steam pressure itself, I'm skeptical that this can meet the claimed specs.
but I assume these people aren't fools. Perhaps the science reporter slipped a few digits.
Since everyone hear has totally missed the boat I'll chime in. The concept of a Scoll lock is indeed alive and well today. Try the following on your Unix computer: run some command that spews text to the screen in a terminal window (e.g. fs_usage or du/) now while its scrolling type control-S. it scroll locks. Now type control-Q to resume the text output.
this dates back to the teletype and is enshrined in the ascii alphabet as Xon and Xoff. Originally it was intended not as a scroll lock but as a way for a teletype or printer to not overflow its fixed hardware buffer. The communication baud rate could easily out pace the tele type printers print speed. when the hardware buffer was nearly full it would send an X-off (contol-s) to the sender to pause its communications. When the buffer was printed the teletype would send a X-on back to the sender to resume spewing.
There was no need for scoll locking functionality on a teletype printer since you could just hold up the paper and look at it back as many lines as you wanted.
but when dumb video terminals came along the terminals could print as fast as the data came in the X-on and X-off functions had little use as a communications protocol, but Now they were useful to humans as a scroll lock. they had at most 40 lines of text and once you scrolled off the top of the screen, you lost that line forever. There were no "windows" or "scroll bars". So you had your fingers poised over the contrl-s key to halt the text from flowing off the screen.
finally along came the PC and Microsoft messed with all the unix converions in their VMS/CPM ripoff called dos: so you could not be sure that control-S would actually work. In part this was because DOS was not really multitasking. programs could take over the OS and capture all the interupts and put hooks directly into the keyboard handler. Since there were no Menus and the "alt" key had not come into its standard defintion yet, the control keys were premium realestate for programs to hook functions into.
thus there was a need for another semaphore. So things like scroll lock and sysRequest, and print screen got added. So yes virgina you can blame MS for these keys as valuable male breasts or an appendix.
Yep,
until now the floodgates of dvd copying have been held back by the fact that movies are ubiquitously about 4.5GB insize and a single DVD-r cant hold that much. Sure you could copy it to your hard drive, but that gets full quickly (at least on a laptop). Or you could compress it, but then for people with home theaters this sucks in quality.
you could burn it onto two CDs but this cost money, is a hassle to actually do correctly, and is a hassle to play back correctly or in a timely fashion when you want to view it.
So until now actually making copies of DVD movies has had significant prohibitive obstacles which are now about to be erased. Of course this will not happen overnight since the price of these things and the media will still be a barrier. But Notice has been served. DVD copying is about to become a real issue.
Do you have any idea how much more hardware we could buy with the money that would be burned up by license fees?
oh about 500 to $1000 dollars is what a fortran lic costs. we have one and share it with 40 people. its a compiler lic not a run time lic, not a per seat lic. it is a processor lic and you can share it.
also if g77 did not exist, I think the number of compilers sold would be at least 100 fold larger, making the price presumably 10 or more times smaller. (the cost of support would not allow it to drop 100 fold) I base this on the empirical fact that indeed fortran compiler lic used to be fairly cheap and ubiquitous prior to g77.
also I think part of the disagreement here is just what is meant by scientific computing. THe fact that you mention a graphical interface at all shows you are thinking of personal scientific software or at best larger scale visualization.
Whereas true large scale number crunching happens on remote servers in batch jobs running in long queues. there is no concept of an interactive command line let alone a graphical interface. Thus much of your comments are off base because they are talking about an entirely different arena in scientific computing ins which C++ is indeed adequate and in some ways more useful due to its better interactivity.
Likewise, as for disk writes being not slow, I have to disagree. And its not uncommon in processing time seriees or genetic data to have writes exceeding four gigbytes, which is not something your are going to cache or even copy. this is compounded because diskwrites across network servers can be quite slow. So again you are imagining scientific computing to be something entirely different than I am.
Sorry to have to point this out but did you read the article you tell the parent poster to read?
if you did then you would know the article was about optimzed fortran77. Fortan 95 indeed has all the functionality they were trying to re-invent as meta-templates right in the language definition. parallelism is assumed for array assignments, for loops and even for conditional tests. Looping is implicitly done by the complier.
There's no way a meta-template could ever out perform that because the level of hinting is so much higher in the the fortran 95 syntax
Numerical recipies said it best. Scientist solve next years problems on last years computer. Computer "scientists" solve last years computer problem on next years computer. You appear to have no clue that all your statements about will slow the code and the memory management ot a crawl.
1) clean, neat code that is easy to read by non-programmers.
>*snort* I'll believe that when I see it.
double snort. Did you know its not possible to make a typo type syntax error in fortran 77 that will compile? hard to believe I know but its true. ( You cant misplace a plus sign or comma or leave off a [] and have it compile. when I try to debug faulty c-code and see something like i = --j I have to try to figure out if they could have meant to write i = -j or i = j-- or i = --j yuck.
2) Array bounds checking by the compiler - try that with C++. Array bounds checking saves me huge amounts of time in development.
I use the STL and not think about bounds ever again.
SLOOOOW. And unparallelizable. and it kills multi-processing dead. and loss of control over memory management. loss of memory mapped sub arrays, strides etc.... Sure you can do strides in c++ but now they are function calls not direct-to-memory. In fortran you can often pull contionals outside of loops using the WHERE syntax. Its much better to have a good syntax in the language than make up for it with a bunch of function calls and object instantiation. e.g. both languages can write A = B*C where A,B and C are matricies but C has to do it with objects and overloads. fortran does not. which do you think is going to be faster.
3) Compiler checking of function calls, via encapsulation of functions in modules.
Unless you're badly describing another feature, that was one of the first features of C++ and ANSI C.
So fortran steals a good thing from C and you complain? In fact fortran 95 implemented headers much better than the asanine way C does it. If fortran you can declare the headers for the called functions right in the code that will call the function so fewere prototype mismatches occur. and fortran also lets you specify the not just the type defs but also whether the subroutine will change the arguments or not (without having to pass by value or declate things final). Thus the compiler can know for example if a cache will need to be written back or how to share memeory between two processors. or if it can multi-thread past a subroutine call.
4) Easy use of BLAS and LAPACK routines for real computational work.
>Two words: C wrapper.
whoopee. I can say it in reverse: take the STL and put a fortran wrapper on it. now fortran has the STL.
5) The actual function definition used for the function prototype - I don't have to maintain a separate prototype for my functions to get the advantages of prototyping!
>Some argue that having a separate prototype prevents the implementor from arbitrarily changing the interface without warning their other team member.
well fortran90 can either derive its prototype or you can specify them your call. its nice to have it both ways and not pay any price.
>Fortran isn't perfect (yet). It still lacks the ability to make a function part of a data structure (ie, classes). not really true. You can program in an object oriented fashion if you wish. but its more like perl-objects where the data is explicitly passed rahter than C where its hidden from the user. in C++ you would say
myobject->hash_get(key) in fortran you would say: hash_get(myObjectStructure, key)
is there any important difference? It current i/o abilities still suck. It's ability to handle characters and character strings is terrible.
Well fortran90 does have nice string handling. and of course it lacks the C string terminator problems that account for so many buffer overflow issues. But I w
I fully agree that Fortran is NOT for every day programming of word processors, opertating systems, games, device drivers, and GUIs, and that there is a resistance to learning it in schools these days. However I believe the Modern Fortran Language is a better choice for most scientific and numerical programming by non-computer scientists;
Consider the following.... perhaps the biggest complaint in the cutting edge of computing is that no one knows how to effectively program for multi-processors for ad-hoc, scientific programming. Duals are already ubiquitous at the low end consumer market, and of course IBM, sun and sgi have long made units with dozens of cores. Its only going to increase. Likewise Intels now all have hyperthreading to increase the efficiency of their instruction pipeline.
An unsolved problem is how to write custom code for end use in multi-processors that does not depend on knowing the architecture or require special libraries or the very complicated bussiness of writing thread-safe code (locking variables etc...). Shared Memory management is a major bottleneck: How to distribute arrays to multi-processors and keep caches up-to-date after writes is a huge problem.
For parallel processing fortran 95 boasts many language level features that give ANY code implicit parallelism and implicit multi-threading and implicit distribution of memory WITHOUT the programmer cognizantly invoking multiple threads or having to use special libraries or overloaded commands. An example of this is the FORALL and WHERE statements that replace the usual "for" and "if" in C.
FORALL (I = 1:5)
WHERE (A(I,:)/= 0.0)
A(I,:) = log(A(i,:))
ENDWHERE
call some_slow_disk_write(A(I,:)) END FORALL
the FORALL runs the loop with the variable "i" over the range 1 to 5 but in any order not just 1,2,3,4,5 and also of course can be done in parallel if the compiler or OS, not the programmer, sees the opportunity on the run-time platform. The statement is a clue from the programmer to the compiler not to worry about loop-order dependencies. Moreover the compiler now knows it can fork off the slow-disk-write operation so it does not halt the loop on each interation.
The WHERE is like an "if" but tells the compiler to map the if operation over the array in parallel. What this means is that you can place conditional test inside of loops and the compiler knows how to factor the conditional out of the loop in a parallel and non-dependent manner.
Moreover, since the WHERE and FORALL tell the compiler that the there are no memory dependent interactions it must worry about. thus it can simply distibute just minimal and orthogonal pieces of the A array to different processors, without having to do maintain concurrency between the array segments used by different processcors, thus elminating shared memory bottlenecks.
Another parallelism feature is that the F95 header declaration not only declare the "type" of variable,as C does, but also if the routine will change that variable. This lets the compiler know that it can multi-thread and not have to worry about locking an array against changes. In the example, the disk-write subroutine would declare the argument (A) to be immutable. Again the multi-threading is hidden from the user, no need for laborious "synchronize" mutex statements. It also allows for the concept of conditionally-mutable data.
Other rather nice virutes of FORTRAN is that it uses references rather than pointers (like java), so less ways to spend your time debugging.
The sad reason the world does not know about these wonderful features, or repeats the myths about the fortran language missing features is due to GNU releasing a non DEC-compatible language. I think the world would be better off if g77 did not exist. By doing so they undercut the affordable fortran compiler market and forced everyone to write for the lowest common denominator to have their code
Mac addict shows that in photoshop a G5 with 2Gigs of memory is 20x faster than one with 512MB.
While more memory is better always, this probably is showing that g5 can really access is effectively.
So far it looks like the benchmarks show that the difference between a g4 and a g5 is just the clock speed difference. This seems a bit wacked so I suspect the test codes are not testing the right things.
The obvious ways this thing should be different are huge memory moves: the true independent DDR and fast bus means this thing can move a DVD's worth of data in ten seconds. The other way this should be better is that the processor should be able to have multiple floating moint commands being processed at once (in addition to altivec). neither of these are showing up in the app-based benchmarks.
these difference should be huge and impossible to miss. something is wrong. maybe some debug codes in the new OS or the compilers are crippling the G5.
The Bussiness software Alliance is applauding the choice. This means we need to keep a close eye on this.
I'm slightly concerned that its someone whos main source of income has been writing anti-virus software for Windows machines. I would doubt that he wakes up each day he hears about a new windows virus and says, that does it, i'm swithcing to linux for better security. He probably also would not really like to see for example, an open source virus program.
And to the extent that he can cast off his "I profit from poor windows security" past, then he would probably see the "paladium" or whatever its called now as the ideal solultion to the widows is a seive problem. And in the HS dept he'll have the clout to make it a national requirement.
the only good thing is it looks like he was a technical person who is well aware of many of the problems in computer security.
Gnu Fortran 95 compilation server?
on
Grid Processing
·
· Score: 1
For those who want to help here's the link to the gnu g95 page. The fact this is not out yet is community wide shame.
I wonder if there is some way someone could practically and legally set up a compilation server for F95 using a non gnu fortran. One could probably talk one of the proprietary compilers (Portland group or Absoft) into allowing this since it would actually promote sales of their products.
The reason this would improves sales is that This would alleviate the dillema programmers face. Write in crippled GNU syntax and have your program compilable by the masses or write in a sane, uncrippled syntax and produce great code that's easy to write, read and debug, and runs many times faster, but can only compile on an expesive compiler. the solution is to have a compilation server that serves a wide variety of target platforms.
The developers still buy the pro fortran since the server would be impractical for development. But it would allow end users to compile the source. thus it would increace the viability of fortran as a language and improve sales of the compilers
Re:Why parallel processors aren't common
on
Grid Processing
·
· Score: 1
Most progamming languages (C, java) dont parallelize efficeintly and others written for parrallism are too special purpose to warrant attention. On the other hand there is good old fortran which will surprise a lot of people because its written to allow implicit multi-processing and avoid shared memory distribution and concurrency bottlenecks. see this post on slashdot
Fortran 95 oddly enough is multi-processor aware.
on
Grid Processing
·
· Score: 4, Informative
Fortran is NOT for every day programming of word processors and such. However the Modern Fortran Language probably ought to be the choice for most scientific programming, its just that people think of it as an "old" as in decrepit Languange and dont learn it.
for parallel processing fortran boast many language level features that give ANY code implicit parallelism and implicit multi-threading and implicit distribution of memory WITHOUT the programmer cognizantly invoking multiple threads or having to use special libraries or overloaded commands. An example of this is the FORALL and WHERE statements that replace the usual "for" and "if" in C.
FORALL (I = 1:5)
WHERE (A(I,:)/= 0.0)
A(I,:) = log(A(i;0)
ENDWHERE
call some_slow_disk_write(A(I,:) END FORALL
the FORALL runs the loop with the variable "i" over the range 1 to 5 but in any order not just 1,2,3,4,5 and also of course can be done in parallel if the compiler or OS, not the programmer, sees the opportunity on the run-time platform. The statement is a clue from the programmer to the compiler not to worry about dependencies. Moreover the program can intelligently multi-thread so the slow-disk-write operation does not stop the loop on each interation.
The WHERE is like an "if" but tells the compiler to map the if operation over the array in parallel. What this means is that you can place conditional test inside of loops and the compiler knows how to factor the if out of the loop in a parallel and non-dependant manner.
Moreover, since the WHERE and FORALL tell the compiler that the there are no memory dependent interactions it must worry about. thus it can simply distibute just peices of the A array to different processors, without having to do maintain concurrency between the array used by different processcors, thus elminating shared memory bottlenecks.
Another parallelism feature is that the header declaration not only declare the "type" of variable,as C does, but also if the routine will change that variable. This lets the compiler know that it can multi-thread and not have to worry about locking an array against changes. In the example, the disk-write subroutine would declare the argument (A) to be immutable. Again the multi-threading is hidden from the user, no need for laborious "synchronize" mutex statements. It also allows for the concept of conditionally-mutable data.
Other rather nice virutes of FORTRAN is that it uses references rather than pointers (like java). And amazingly the syntax makes typos that compile almost impossible. that is, a missing +,=,comma, semi colon, the wrong number of array indicies, etc... will not compile (in contrast to ==, ++, =+ and [][] etc...).
One sad reason the world does not know about these wonderful features, or repeats the myths about the fortran language missing features is due to GNU. yes I know its a crime to crtisize GNU on slashdot but bear with me here because in this case they desereve some for releasing a non DEC-compatible language.
for the record, ancient fortran 77 as welll as modern fortran 95 DOES do dynamic allocation, support complex data structures (classes), have pointers (references) in every professional fortran compiler. Sadly GNU fortran 77, the free fortran, lacks these language features and there is no GNU fortran 95 yet. This is lack prevents a lot of people from writing code in this modern language. if Gnu g77 did not exist the professional compilers would be much more affordable. So I hope some reader who know about complier design is motivate to give the languishing GNU fortran 95 project the push it needs to finnish.
In the age of ubiquitous dual processing fortran could well become a valuable scientific language due to its ease of programming and resitance to syntax errors
Perhaps Google could do at least a poor mans version of this right now?
Suppose one had a GoogleNut tool. You query Google for a song. Google then distributes this Query to all of its distributed servers and on each one launches a Gnutella/Kaaza search, then replys with the a link that when activated uses your Gnuttell app/plugin to download the file from the location it found.
the Added value here is that 1) google's network would act as a fast bridge across the mostly small-world Gnutella networks. 2) they could cache simmilar requests 3) they could also develop lists of nodes to block if they detected RIAA style hanky-panky (e.g. different file sizes or fingerprints).
Since this mightbe more expensive than a regular search for Google, they could pay for it with say ultra-mercials while you download or make it a fee for service.
1) A good chunk of the solar spectrum is in the mid-IR and UV. I dont think this is recoverable even by a multi-layer solar cell
2) to beat the reflection loss the outer pane of glass, the focusing lens, and the solar collector will will have to have zero dielectric reflectance across the entire solar spectrum. For the outer pane, which wont be rotating, this also has to be true at all incidence angles. Otherwise each of these surfaces is going to have a reflection loss which ought to be a minimum of roughly 4% per surface = 20% loss.
3) the multi-layer solar cell is going to have multiple DC output voltages that need to upconverted from fractions of a volt, to, presumably, 120v AC. This is not lossless. Presumably each solar cell will have to do this converison itself, since lashing them in paralllel is likely to be fraught with the problem of them fighting each other, like bridging tow batteries with different voltages. (e.g. bird poop blocks one of the cells, and it voltage drops.).
4) any loss in the solar cell means its going to start heating up. so there may have to be some sort of airflow in the widows to cool it. If this is active cooling theres a loss.
there's also some technical issues. if you have a phased array of mirrors, and they malfunction its possible you could create a building sized lens reflecting the sun in some direction. Even when its working correctly it will reflect back towards the sun. I wonder if its possible this could create a hazzard to other building and planes or pedestrians?
Everyone seems to not be noticing that this action will probably play to microsofts interests. Of course MS would rather not pay 0.5 Billion dollars in penaties but now that they are they can tunr this to their advantage. here's how.
1) it makes.NET the killer app. MS would love to see plug-ins die, especiall y if they die for other browsers too. What's left to step in its place then? basically two things,.NET and a chaos of non-standard solutions.
2) MS would love to be able to go to the judge and say, look we had to integrate the broswer into the OS. there was no other way since it lost all its stand-alon functionality..NET is part of our OS and the browser had to be integrated there's no other solutions due the breadth of the EOLAS patent.
3) MS can appeal and maybe ret the 0.5 billion penalty reduced. and they can string along the usefulness of IE till 2005 when longhorn emerges. then pfft. MS will say EOLAS was totally right and has a solid case against us and all the other browsers. And here's our payment in full so you can fund your legal effort.
4) Maybe MS will invest another 0.5 billion and buy the IP from EOLAS. its will have been tested in court and they could shutdown all the other browsers that didn't use.NET and other fee based licesced extensions for MS.
DSL is only useful if you dont move around. When you travel or if like my parents you are retired and semi nomadic, you cant afford to get DSL connection at every place you might live.
Likewise I often find myslef in some crappy hotel where the connection is so noiesy I can barely squeeze a 14.4K connection out of it. I just want to check my web based e-mail not download the encyclopedia britannica
so anything that can make a dialup work painlessly on common web pages is a good thing.
Dont forget the Apple GCC compilier in X-code can do predictive compiling and just in time linking of module not needed to launch. making development builds insanley fast.
and if you are so lucky to work in a room with a lot of these there's the distributed compile via rendevouz.
IT WILL NOT WORK! Here's technical reason why
on
ESR to Shred SCO Claims?
·
· Score: -1, Flamebait
MD5 sums only can show if the source code is identical. or in this case since it uses three line sets, whether three lines are identical.
A single change in the white space would make the MD5keys not match. any code run through an obfuscator woul dnot match. a change in case would cause it not to match.
Perhaps one could however do the following: create a C language parser that reduced the C-code down to op codes. then comapre these.
Slashdot Mirror
I dont know. I'm just asking.
Obviously if they were bigger objects then their bulk points of failure and ability to dissipate heat would not be adequate (for teflon) but perhaps on the molecular scale these things have non-bulk shear strengths and can rapidly shed heat given a huge surface to volume ratio??
three-words: high speed condoms.
I'm looking forward to condoms made from this because There's two things I've never gotten used to and that's the smell of burning rubber and screaming women.
no people will not switch browsers. if a browser does not come with MS and is not located in the prefered position MOST users, that is the majority of the comsumers, will not use it. Thus IE will remain a standard and websites will comply or die. Sure a few may write special versions for multiple browsers but whose going to be writing the plugins? Unless theres a market to sell plugins the flash producers of the world are going to shrink in number.
Perhaps you think I overestimate consumer laziness. Well BMG just copyprotected all of their CDs. Anyone cany defeat the copy protection by, get this, holding down the shift key when inserting the disk. BMG acknowledges this wont stop some people but believes it will thwart the majority. They have reason to believe in consumer laziness.
Gramar Fairy,
You said, " The easiest way to remember it until its habit is to substitute the full phrase in your (not you're!) sentence, and see if it works:"
In that sentence, you mixed up the common homonyms (male labia) "it's" and "its".
The word "it's" is a contraction of "it is". the term "its" is a the possesive form of "it", which is wrong unless you meant to imply that one must train the word to know "its" place in the sentence; in that case you would be correct but un drugs or maybe snorting too much fairy dust and ranting about ficticious male genetalia (homo = man, nym from nympha = labia minor.)
my post erred because the reason the water boils is not the heat flux but the stored heat in the stove top coil. The transient delivery of this stored heat vastly exceeds the rate of power delivered to the stove and thus the water boils fast. but this would not be sustained.
I withdraw my original answer.
A typical stove top burner is order of magnitude 1000 watts spread out over around 500 sq cm: so were talking order of magnitude less than 10 watts per sq cm.
if I take a teaspoon of water an put it on a sq cm of stove top and it boils in far less than a second. really almost instantly so its probably like less than a tenth of a second.
Thus if this thing is going to not explode, the flow rate required to avoid boiling at 1000 watts /sq cm is going to be on the order of hundreds to thousands of teaspoons per second.
If I take a tiny swizzel straw and try to suck through it I cannot suck 1000 teaspoos per second. Since my ability to suck is probably within an order of magnitude of the cavitation pressure for atmospheric pressure water a pump trying to flow this stuff through an equally small crossecttion may not be able to sustain such a flow rate. And any on-chip pump is probably going to have a simmilar crossection for its fluid intake port. (off -chip is another matter)
unless this thing is actually flowing the water based on the steam pressure itself, I'm skeptical that this can meet the claimed specs.
but I assume these people aren't fools. Perhaps the science reporter slipped a few digits.
this dates back to the teletype and is enshrined in the ascii alphabet as Xon and Xoff. Originally it was intended not as a scroll lock but as a way for a teletype or printer to not overflow its fixed hardware buffer. The communication baud rate could easily out pace the tele type printers print speed. when the hardware buffer was nearly full it would send an X-off (contol-s) to the sender to pause its communications. When the buffer was printed the teletype would send a X-on back to the sender to resume spewing.
There was no need for scoll locking functionality on a teletype printer since you could just hold up the paper and look at it back as many lines as you wanted.
but when dumb video terminals came along the terminals could print as fast as the data came in the X-on and X-off functions had little use as a communications protocol, but Now they were useful to humans as a scroll lock. they had at most 40 lines of text and once you scrolled off the top of the screen, you lost that line forever. There were no "windows" or "scroll bars". So you had your fingers poised over the contrl-s key to halt the text from flowing off the screen.
finally along came the PC and Microsoft messed with all the unix converions in their VMS/CPM ripoff called dos: so you could not be sure that control-S would actually work. In part this was because DOS was not really multitasking. programs could take over the OS and capture all the interupts and put hooks directly into the keyboard handler. Since there were no Menus and the "alt" key had not come into its standard defintion yet, the control keys were premium realestate for programs to hook functions into.
thus there was a need for another semaphore. So things like scroll lock and sysRequest, and print screen got added. So yes virgina you can blame MS for these keys as valuable male breasts or an appendix.
THe capslock key is wired on onall nigerian keyboards by law.
you could burn it onto two CDs but this cost money, is a hassle to actually do correctly, and is a hassle to play back correctly or in a timely fashion when you want to view it.
So until now actually making copies of DVD movies has had significant prohibitive obstacles which are now about to be erased. Of course this will not happen overnight since the price of these things and the media will still be a barrier. But Notice has been served. DVD copying is about to become a real issue.
Do you have any idea how much more hardware we could buy with the money that would be burned up by license fees?
oh about 500 to $1000 dollars is what a fortran lic costs. we have one and share it with 40 people. its a compiler lic not a run time lic, not a per seat lic. it is a processor lic and you can share it.
also if g77 did not exist, I think the number of compilers sold would be at least 100 fold larger, making the price presumably 10 or more times smaller. (the cost of support would not allow it to drop 100 fold) I base this on the empirical fact that indeed fortran compiler lic used to be fairly cheap and ubiquitous prior to g77.
also I think part of the disagreement here is just what is meant by scientific computing. THe fact that you mention a graphical interface at all shows you are thinking of personal scientific software or at best larger scale visualization.
Whereas true large scale number crunching happens on remote servers in batch jobs running in long queues. there is no concept of an interactive command line let alone a graphical interface. Thus much of your comments are off base because they are talking about an entirely different arena in scientific computing ins which C++ is indeed adequate and in some ways more useful due to its better interactivity.
Likewise, as for disk writes being not slow, I have to disagree. And its not uncommon in processing time seriees or genetic data to have writes exceeding four gigbytes, which is not something your are going to cache or even copy. this is compounded because diskwrites across network servers can be quite slow. So again you are imagining scientific computing to be something entirely different than I am.
Sorry to have to point this out but did you read the article you tell the parent poster to read?
if you did then you would know the article was about optimzed fortran77. Fortan 95 indeed has all the functionality they were trying to re-invent as meta-templates right in the language definition. parallelism is assumed for array assignments, for loops and even for conditional tests. Looping is implicitly done by the complier.
There's no way a meta-template could ever out perform that because the level of hinting is so much higher in the the fortran 95 syntax
Numerical recipies said it best. Scientist solve next years problems on last years computer. Computer "scientists" solve last years computer problem on next years computer. You appear to have no clue that all your statements about will slow the code and the memory management ot a crawl.
1) clean, neat code that is easy to read by non-programmers.
>*snort* I'll believe that when I see it.
double snort. Did you know its not possible to make a typo type syntax error in fortran 77 that will compile? hard to believe I know but its true. ( You cant misplace a plus sign or comma or leave off a [] and have it compile.
when I try to debug faulty c-code and see something like
i = --j
I have to try to figure out if they could have meant to write
i = -j or i = j-- or i = --j
yuck.
2) Array bounds checking by the compiler - try that with C++. Array bounds checking saves me huge amounts of time in development.
I use the STL and not think about bounds ever again.
SLOOOOW. And unparallelizable. and it kills multi-processing dead. and loss of control over memory management. loss of memory mapped sub arrays, strides etc.... Sure you can do strides in c++ but now they are function calls not direct-to-memory. In fortran you can often pull contionals outside of loops using the WHERE syntax. Its much better to have a good syntax in the language than make up for it with a bunch of function calls and object instantiation. e.g. both languages can write
A = B*C where A,B and C are matricies but C has to do it with objects and overloads. fortran does not. which do you think is going to be faster.
3) Compiler checking of function calls, via encapsulation of functions in modules.
Unless you're badly describing another feature, that was one of the first features of C++ and ANSI C.
So fortran steals a good thing from C and you complain? In fact fortran 95 implemented headers much better than the asanine way C does it. If fortran you can declare the headers for the called functions right in the code that will call the function so fewere prototype mismatches occur. and fortran also lets you specify the not just the type defs but also whether the subroutine will change the arguments or not (without having to pass by value or declate things final). Thus the compiler can know for example if a cache will need to be written back or how to share memeory between two processors. or if it can multi-thread past a subroutine call.
4) Easy use of BLAS and LAPACK routines for real computational work.
>Two words: C wrapper.
whoopee. I can say it in reverse: take the STL and put a fortran wrapper on it. now fortran has the STL.
5) The actual function definition used for the function prototype - I don't have to maintain a separate prototype for my functions to get the advantages of prototyping!
>Some argue that having a separate prototype prevents the implementor from arbitrarily changing the interface without warning their other team member.
well fortran90 can either derive its prototype or you can specify them your call. its nice to have it both ways and not pay any price.
>Fortran isn't perfect (yet). It still lacks the ability to make a function part of a data
structure (ie, classes).
not really true. You can program in an object oriented fashion if you wish. but its more like perl-objects where the data is explicitly passed rahter than C where its hidden from the user.
in C++ you would say
myobject->hash_get(key)
in fortran you would say:
hash_get(myObjectStructure, key)
is there any important difference?
It current i/o abilities still suck. It's ability to handle characters and
character strings is terrible.
Well fortran90 does have nice string handling. and of course it lacks the C string terminator problems that account for so many buffer overflow issues. But I w
I fully agree that Fortran is NOT for every day programming of word processors, opertating systems, games, device drivers, and GUIs, and that there is a resistance to learning it in schools these days. However I believe the Modern Fortran Language is a better choice for most scientific and numerical programming by non-computer scientists;
/= 0.0)
,as C does, but also if the routine will change that variable. This lets the compiler know that it can multi-thread and not have to worry about locking an array against changes. In the example, the disk-write subroutine would declare the argument (A) to be immutable. Again the multi-threading is hidden from the user, no need for laborious "synchronize" mutex statements. It also allows for the concept of conditionally-mutable data.
Consider the following....
perhaps the biggest complaint in the cutting edge of computing is that no one knows how to effectively program for multi-processors for ad-hoc, scientific programming. Duals are already ubiquitous at the low end consumer market, and of course IBM, sun and sgi have long made units with dozens of cores. Its only going to increase. Likewise Intels now all have hyperthreading to increase the efficiency of their instruction pipeline.
An unsolved problem is how to write custom code for end use in multi-processors that does not depend on knowing the architecture or require special libraries or the very complicated bussiness of writing thread-safe code (locking variables etc...). Shared Memory management is a major bottleneck: How to distribute arrays to multi-processors and keep caches up-to-date after writes is a huge problem.
For parallel processing fortran 95 boasts many language level features that give ANY code implicit parallelism and implicit multi-threading and implicit distribution of memory WITHOUT the programmer cognizantly invoking multiple threads or having to use special libraries or overloaded commands.
An example of this is the FORALL and WHERE statements that replace the usual "for" and "if" in C.
FORALL (I = 1:5)
WHERE (A(I,:)
A(I,:) = log(A(i,:))
ENDWHERE
call some_slow_disk_write(A(I,:))
END FORALL
the FORALL runs the loop with the variable "i" over the range 1 to 5 but in any order not just 1,2,3,4,5 and also of course can be done in parallel if the compiler or OS, not the programmer, sees the opportunity on the run-time platform. The statement is a clue from the programmer to the compiler not to worry about loop-order dependencies. Moreover the compiler now knows it can fork off the slow-disk-write operation so it does not halt the loop on each interation.
The WHERE is like an "if" but tells the compiler to map the if operation over the array in parallel. What this means is that you can place conditional test inside of loops and the compiler knows how to factor the conditional out of the loop in a parallel and non-dependent manner.
Moreover, since the WHERE and FORALL tell the compiler that the there are no memory dependent interactions it must worry about. thus it can simply distibute just minimal and orthogonal pieces of the A array to different processors, without having to do maintain concurrency between the array segments used by different processcors, thus elminating shared memory bottlenecks.
Another parallelism feature is that the F95 header declaration not only declare the "type" of variable
Other rather nice virutes of FORTRAN is that it uses references rather than pointers (like java), so less ways to spend your time debugging.
The sad reason the world does not know about these wonderful features, or repeats the myths about the fortran language missing features is due to GNU releasing a non DEC-compatible language. I think the world would be better off if g77 did not exist. By doing so they undercut the affordable fortran compiler market and forced everyone to write for the lowest common denominator to have their code
Mac addict shows that in photoshop a G5 with 2Gigs of memory is 20x faster than one with 512MB. While more memory is better always, this probably is showing that g5 can really access is effectively.
The obvious ways this thing should be different are huge memory moves: the true independent DDR and fast bus means this thing can move a DVD's worth of data in ten seconds. The other way this should be better is that the processor should be able to have multiple floating moint commands being processed at once (in addition to altivec). neither of these are showing up in the app-based benchmarks.
these difference should be huge and impossible to miss. something is wrong. maybe some debug codes in the new OS or the compilers are crippling the G5.
I'm slightly concerned that its someone whos main source of income has been writing anti-virus software for Windows machines. I would doubt that he wakes up each day he hears about a new windows virus and says, that does it, i'm swithcing to linux for better security. He probably also would not really like to see for example, an open source virus program.
And to the extent that he can cast off his "I profit from poor windows security" past, then he would probably see the "paladium" or whatever its called now as the ideal solultion to the widows is a seive problem. And in the HS dept he'll have the clout to make it a national requirement.
the only good thing is it looks like he was a technical person who is well aware of many of the problems in computer security.
I wonder if there is some way someone could practically and legally set up a compilation server for F95 using a non gnu fortran. One could probably talk one of the proprietary compilers (Portland group or Absoft) into allowing this since it would actually promote sales of their products.
The reason this would improves sales is that This would alleviate the dillema programmers face. Write in crippled GNU syntax and have your program compilable by the masses or write in a sane, uncrippled syntax and produce great code that's easy to write, read and debug, and runs many times faster, but can only compile on an expesive compiler. the solution is to have a compilation server that serves a wide variety of target platforms.
The developers still buy the pro fortran since the server would be impractical for development. But it would allow end users to compile the source. thus it would increace the viability of fortran as a language and improve sales of the compilers
Most progamming languages (C, java) dont parallelize efficeintly and others written for parrallism are too special purpose to warrant attention. On the other hand there is good old fortran which will surprise a lot of people because its written to allow implicit multi-processing and avoid shared memory distribution and concurrency bottlenecks. see this post on slashdot
for parallel processing fortran boast many language level features that give ANY code implicit parallelism and implicit multi-threading and implicit distribution of memory WITHOUT the programmer cognizantly invoking multiple threads or having to use special libraries or overloaded commands.
An example of this is the FORALL and WHERE statements that replace the usual "for" and "if" in C.
FORALL (I = 1:5)
WHERE (A(I,:)
A(I,:) = log(A(i;0)
ENDWHERE
call some_slow_disk_write(A(I,:)
END FORALL
the FORALL runs the loop with the variable "i" over the range 1 to 5 but in any order not just 1,2,3,4,5 and also of course can be done in parallel if the compiler or OS, not the programmer, sees the opportunity on the run-time platform. The statement is a clue from the programmer to the compiler not to worry about dependencies. Moreover the program can intelligently multi-thread so the slow-disk-write operation does not stop the loop on each interation.
The WHERE is like an "if" but tells the compiler to map the if operation over the array in parallel. What this means is that you can place conditional test inside of loops and the compiler knows how to factor the if out of the loop in a parallel and non-dependant manner.
Moreover, since the WHERE and FORALL tell the compiler that the there are no memory dependent interactions it must worry about. thus it can simply distibute just peices of the A array to different processors, without having to do maintain concurrency between the array used by different processcors, thus elminating shared memory bottlenecks.
Another parallelism feature is that the header declaration not only declare the "type" of variable
Other rather nice virutes of FORTRAN is that it uses references rather than pointers (like java). And amazingly the syntax makes typos that compile almost impossible. that is, a missing +,=,comma, semi colon, the wrong number of array indicies, etc... will not compile (in contrast to ==, ++, =+ and [][] etc
One sad reason the world does not know about these wonderful features, or repeats the myths about the fortran language missing features is due to GNU. yes I know its a crime to crtisize GNU on slashdot but bear with me here because in this case they desereve some for releasing a non DEC-compatible language.
for the record, ancient fortran 77 as welll as modern fortran 95 DOES do dynamic allocation, support complex data structures (classes), have pointers (references) in every professional fortran compiler. Sadly GNU fortran 77, the free fortran, lacks these language features and there is no GNU fortran 95 yet. This is lack prevents a lot of people from writing code in this modern language. if Gnu g77 did not exist the professional compilers would be much more affordable. So I hope some reader who know about complier design is motivate to give the languishing GNU fortran 95 project the push it needs to finnish.
In the age of ubiquitous dual processing fortran could well become a valuable scientific language due to its ease of programming and resitance to syntax errors
Suppose one had a GoogleNut tool. You query Google for a song. Google then distributes this Query to all of its distributed servers and on each one launches a Gnutella/Kaaza search, then replys with the a link that when activated uses your Gnuttell app/plugin to download the file from the location it found.
the Added value here is that 1) google's network would act as a fast bridge across the mostly small-world Gnutella networks. 2) they could cache simmilar requests 3) they could also develop lists of nodes to block if they detected RIAA style hanky-panky (e.g. different file sizes or fingerprints).
Since this mightbe more expensive than a regular search for Google, they could pay for it with say ultra-mercials while you download or make it a fee for service.
1) A good chunk of the solar spectrum is in the mid-IR and UV. I dont think this is recoverable even by a multi-layer solar cell
2) to beat the reflection loss the outer pane of glass, the focusing lens, and the solar collector will will have to have zero dielectric reflectance across the entire solar spectrum. For the outer pane, which wont be rotating, this also has to be true at all incidence angles. Otherwise each of these surfaces is going to have a reflection loss which ought to be a minimum of roughly 4% per surface = 20% loss.
3) the multi-layer solar cell is going to have multiple DC output voltages that need to upconverted from fractions of a volt, to, presumably, 120v AC. This is not lossless. Presumably each solar cell will have to do this converison itself, since lashing them in paralllel is likely to be fraught with the problem of them fighting each other, like bridging tow batteries with different voltages. (e.g. bird poop blocks one of the cells, and it voltage drops.).
4) any loss in the solar cell means its going to start heating up. so there may have to be some sort of airflow in the widows to cool it. If this is active cooling theres a loss.
there's also some technical issues. if you have a phased array of mirrors, and they malfunction its possible you could create a building sized lens reflecting the sun in some direction. Even when its working correctly it will reflect back towards the sun. I wonder if its possible this could create a hazzard to other building and planes or pedestrians?
Everyone seems to not be noticing that this action will probably play to microsofts interests. Of course MS would rather not pay 0.5 Billion dollars in penaties but now that they are they can tunr this to their advantage. here's how.
.NET the killer app. MS would love to see plug-ins die, especiall y if they die for other browsers too. What's left to step in its place then? basically two things, .NET and a chaos of non-standard solutions.
.NET is part of our OS and the browser had to be integrated there's no other solutions due the breadth of the EOLAS patent.
.NET and other fee based licesced extensions for MS.
1) it makes
2) MS would love to be able to go to the judge and say, look we had to integrate the broswer into the OS. there was no other way since it lost all its stand-alon functionality.
3) MS can appeal and maybe ret the 0.5 billion penalty reduced. and they can string along the usefulness of IE till 2005 when longhorn emerges. then pfft. MS will say EOLAS was totally right and has a solid case against us and all the other browsers. And here's our payment in full so you can fund your legal effort.
4) Maybe MS will invest another 0.5 billion and buy the IP from EOLAS. its will have been tested in court and they could shutdown all the other browsers that didn't use
we're hosed.
Likewise I often find myslef in some crappy hotel where the connection is so noiesy I can barely squeeze a 14.4K connection out of it. I just want to check my web based e-mail not download the encyclopedia britannica
so anything that can make a dialup work painlessly on common web pages is a good thing.
and if you are so lucky to work in a room with a lot of these there's the distributed compile via rendevouz.
A single change in the white space would make the MD5keys not match. any code run through an obfuscator woul dnot match. a change in case would cause it not to match.
Perhaps one could however do the following: create a C language parser that reduced the C-code down to op codes. then comapre these.