It is my understanding that your brain takes both the phase difference and the volume difference between the ears in to account when determining the source of the sound. Up/down/front/back are detected by changes in wave form due to the irregular way the ear is shaped.
Yes, I agree with you, and I too use Qt and boost to ease porting. It's still not as easy as Java though:P
What's wrong with VC++ stdio?
_snprintf() and _vsnprintf() do not conform to the C99 standard: they do not guarantee NUL termination of the buffer while they should and return the wrong value if the buffer was too small. The former was a mistake of epic proportions if you ask me. Microsoft tried to fix that with the non-standard _snprintf_s() and _vsnprintf_s() but these still return the wrong value in case of a buffer overrun. I guess they prefix everything with _ because they are unable to implement conforming procedures.
Why is it so hard to understand that Java, a language DESIGNED for portabilty, is more suitable for cross platform development than C++? You can throw any number of well designed cross platform C++ libraries at C++, it is still NOT part of the language, not part of the standard development platform and therefore it is harder to do cross platform C++ development than in Java. I can not comprehend why you think otherwise. Yes, the disparity in cross platform developement ease between the two may slowly fade in time, especially in the light of the new C++ release which makes a lot of features that you need from an API standard (threads for instance), but to say they are on par is simply an outrageous claim and definitely not a "simple fact".
Allow me to demonstrate some practical problems with C/C++ cross development between Windows & Unix) - Non standard build system (make / vc++), different systems used for different libraries. - Different linking process (.so vs.dll/.lib) - Wildly differing implementations of the standard C library (stdio in VC++ is severely broken). - No network API, so we will have to deal with either manual compatibily shims (more work) or 3rd party library (more work) - No GUI API, same as above
The uniformity in Java is what makes cross platform development such an easy task: - Everything is.JAR, build tools the same for all platforms (granted, you still need a Make equivalent, say ant, but the result of the build process is portable) - Linking is just throwing a bunch of JARs together - There is only one implementation of the standard library that everyone uses. - Network API is standard - GUI API is standard.
Now please enlighten me how exactly C++ crossplatform development is just as easy as in Java.
I'd like to add that the added cost in C/C++ is because of the need to port 3rd party libraries, not your own software because that was obviously designed with portability in mind!
Unless your "application" consists only of business logic that is simply not true. You must interface with the real world. You can do that in Java by default. In C++ you must find non standard libaries who can do that for you. That is definitely more work and so it is not as easy in Java.
You're simplifying things. Most importantly Java has actually all the tools necessary to communicate with the operating system while C/C++ have almost none of them (for instance networking, graphics are missing). Plain C/C++ is not usable as a cross development platform _unless_ you restrict yourself to only use portable (3rd party) libraries. On the other hand, 99% of the Java libraries out there are already completely portable, so every Java program in Java can be made portable with a minimum of changes even if it wasn't designed for that initially, or in simple cases will just work out of the box.
So I wouldn't say it is as easy in C/C++ as in Java. This has obviously more to do with the standard libraries than the language itself.
Ok, what a second, I never said I was from the USA (I'm Dutch) and secondly lets not over generalize the perceived deficiencies mentioned by others of the German schooling system.
The basic theory that you specify accuracy or errors in measurements was never questioned by me. However I'm simply saying, that lacking such information, the number of significant figures DOES matter. That is what it all boils down to. That is the reason why you simply can't say 1.0 =~ 1.0000, but you can say 1.0 =~ 1.0000 +/- 0.05.
Finally, the voltmeter I have here (of German make btw, although admittedly a cheap model) doesn't say what its accuracy is.
This has nothing to do with internet. I learned this stuff when I was about 13 in school. I don't get your whole argument on the terminology. The concept has been repeatedly explained. I will try to explain this stuff once more in even easier words (I hope).
As I said before, no one in the real engineering world is using a number like "1.000000000" to indicate anything like error, accuracy etc.
Yes they do. Suppose you have a Volt meter and it displays 1.0000 V. Would you say it it could actually be anything between 1.5000 V and 0.5000 V ? Of course not. The 1.0000 V really implies that the error is less than 0.00005 as (i.e. the actual voltage is between 1.0005 V and 0.99995 V. Unless the device explicitly states its error is larger than that we may assume all digits are accurate.
Dude, you're completely wrong. I live in Europe and I use that notation all the time.
1.000000000 is definitely more accurate than 1.0. This notation implies an error of up to +/- 0.000000005 in the measurement or result. 1.0 implies an error of up to +/- 0.5. If you do math with different numer of significant digits you round the outcome to the numer of sig figs of the least accurate input., Thus 2.3456 * 3.14156 - 1.02 = 6.35 (i.e. 3 significant digits). Any more digits in the result are _useless_. Technically to be even more accurate you state the actual result and the error, but the number digits is usually sufficient to get the general idea.
One can only hope that this dirty "hybrid GPU" hack goes away rather sooner than later. I simply can't comprehend why it's inventor came up with the idea to _add more_ hardware to decrease power consumption, instead of just fixing the original problem.
Both yes and no. Sure, the OS will use processing time to run another thread while one is blocked, but it has to preserve its complete call stack - e.g. on Windows, that's the default reservation of 1Mb for every thread, plus whatever it may have incurred on top of that. With async model, the continuation closure only needs to preserve what it needs to run after control is returned to it, which can be significantly less.
I mostly agree, but I see this more as an implementation detail. The root cause here is that threads are apparently resource intensive. In a perfect world, the data that a thread would have to store during a context switch is exactly the same amount that you would store yourself during a voluntary context switch. In reality, the "win" from the asynchronous model is that you as an application developer have more knowledge about that state that needs to preserved than the OS probably will ever have and thus can write more efficient applications.
I agree that for single threaded client side programs, it is a real boon not to have to use threads, and still be responsive while performing I/O.
Really the only difference between a synchronous and an asynchronous model is that you shift the burden (and the resources) of multitasking from the the operating system to the application. Under the hood, everything is always asynchronous. It's just that in a synchronous multi-threaded program the OS deschedules a thread whenever you do a blocking call, instead of doing it yourself. So you can consider threads to be syntactic sugar for any I/O bound program.
I disagree with the view that "headaches" of concurrency go away with a continuation model, because in a server environment, you often have to deal with shared resources, and I don't really see how this model helps (note that asynchronous model does not mean no threads...). The two concepts are orthogonal IMHO.
In case of your example, a UI, instead of letting the OS take care of the state of the background threads, you now have to keep state yourself, needlessly complicating application design. For complicated tasks you will get enormous state machines.
Yes, thats sequential.
Obviously with forward seeks or seeks of any kind, performance will diminish. Still I suppose if you could put everything that is needed for booting on the first 100MB of the disk, you could read it in about a second... I'm speculating here, but perhaps someone might write a boot cache that does a trace of an actual boot and caches all those data blocks in order somewhere on the disk. That should speed things up significantly.
Simple enough, each OS has its own boot loader installed on its root partition. The boot loader only needs to know how to interpret the filesystem for that particular OS and load its kernel.
A simple boot manager is installed in the MBR that just knows how to "chainload" (i.e. boot a boot loader, regardless of filesystem).
I'd say that 100MB/sec for ordered reads or writes on a single consumer HDD with filesystem is actually realistic. For example, I can copy large files between my workstation (Windows 7) and my server (FreeBSD, Samba) at 100MB/sec. Admittedly, the filesystem on the server (UFS2) is only 30% full. The disks in both systems are modern 7200rpm devices: WD Caviar Blue 640GB and a random Samsung 1TB HDD. Both systems use AHCI capable (onboard) controllers. If you can't get more than 25MB/sec sustained from your hardware, it must be really old or something else is wrong.
I know you're trying to be funny but to enable Jersey for example you only have to add a couple of lines to web.xml. The actual REST interfaces are defined using annotations.
Slashdot Mirror
Lol, why would he care about copyright? Afraid some other hacker might steal his logo?
To be fair I'd rather implement a brainfuck interpreter in VBA than the other way around :-)
Thank you for that link, Wt seems really useful.
It is my understanding that your brain takes both the phase difference and the volume difference between the ears in to account when determining the source of the sound. Up/down/front/back are detected by changes in wave form due to the irregular way the ear is shaped.
Yes, I agree with you, and I too use Qt and boost to ease porting. It's still not as easy as Java though :P
What's wrong with VC++ stdio?
_snprintf() and _vsnprintf() do not conform to the C99 standard: they do not guarantee NUL termination of the buffer while they should and return the wrong value if the buffer was too small. The former was a mistake of epic proportions if you ask me.
Microsoft tried to fix that with the non-standard _snprintf_s() and _vsnprintf_s() but these still return the wrong value in case of a buffer overrun.
I guess they prefix everything with _ because they are unable to implement conforming procedures.
Why is it so hard to understand that Java, a language DESIGNED for portabilty, is more suitable for cross platform development than C++? You can throw any number of well designed cross platform C++ libraries at C++, it is still NOT part of the language, not part of the standard development platform and therefore it is harder to do cross platform C++ development than in Java. I can not comprehend why you think otherwise. Yes, the disparity in cross platform developement ease between the two may slowly fade in time, especially in the light of the new C++ release which makes a lot of features that you need from an API standard (threads for instance), but to say they are on par is simply an outrageous claim and definitely not a "simple fact".
Allow me to demonstrate some practical problems with C/C++ cross development between Windows & Unix) .dll/.lib)
- Non standard build system (make / vc++), different systems used for different libraries.
- Different linking process (.so vs
- Wildly differing implementations of the standard C library (stdio in VC++ is severely broken).
- No network API, so we will have to deal with either manual compatibily shims (more work) or 3rd party library (more work)
- No GUI API, same as above
The uniformity in Java is what makes cross platform development such an easy task: .JAR, build tools the same for all platforms (granted, you still need a Make equivalent, say ant, but the result of the build process is portable)
- Everything is
- Linking is just throwing a bunch of JARs together
- There is only one implementation of the standard library that everyone uses.
- Network API is standard
- GUI API is standard.
Now please enlighten me how exactly C++ crossplatform development is just as easy as in Java.
*as easy _as_ in Java. :-).
I'd like to add that the added cost in C/C++ is because of the need to port 3rd party libraries, not your own software because that was obviously designed with portability in mind!
Unless your "application" consists only of business logic that is simply not true. You must interface with the real world. You can do that in Java by default. In C++ you must find non standard libaries who can do that for you. That is definitely more work and so it is not as easy in Java.
You're simplifying things. Most importantly Java has actually all the tools necessary to communicate with the operating system while C/C++ have almost none of them (for instance networking, graphics are missing). Plain C/C++ is not usable as a cross development platform _unless_ you restrict yourself to only use portable (3rd party) libraries. On the other hand, 99% of the Java libraries out there are already completely portable, so every Java program in Java can be made portable with a minimum of changes even if it wasn't designed for that initially, or in simple cases will just work out of the box.
So I wouldn't say it is as easy in C/C++ as in Java. This has obviously more to do with the standard libraries than the language itself.
Too bad you still have to explicitly specify the length of the string. Twice.
Ok, what a second, I never said I was from the USA (I'm Dutch) and secondly lets not over generalize the perceived deficiencies mentioned by others of the German schooling system.
The basic theory that you specify accuracy or errors in measurements was never questioned by me. However I'm simply saying, that lacking such information, the number of significant figures DOES matter. That is what it all boils down to. That is the reason why you simply can't say 1.0 =~ 1.0000, but you can say 1.0 =~ 1.0000 +/- 0.05.
Finally, the voltmeter I have here (of German make btw, although admittedly a cheap model) doesn't say what its accuracy is.
I hope we can finally put this to rest now :-)
Well stereo is now widely used and it definitely adds to the quality of music. If 3D's going the way of stereo I foresee a bright future for it.
As I said before, no one in the real engineering world is using a number like "1.000000000" to indicate anything like error, accuracy etc.
Yes they do. Suppose you have a Volt meter and it displays 1.0000 V. Would you say it it could actually be anything between 1.5000 V and 0.5000 V ? Of course not. The 1.0000 V really implies that the error is less than 0.00005 as (i.e. the actual voltage is between 1.0005 V and 0.99995 V. Unless the device explicitly states its error is larger than that we may assume all digits are accurate.
Dude, you're completely wrong. I live in Europe and I use that notation all the time.
1.000000000 is definitely more accurate than 1.0. This notation implies an error of up to +/- 0.000000005 in the measurement or result. 1.0 implies an error of up to +/- 0.5. If you do math with different numer of significant digits you round the outcome to the numer of sig figs of the least accurate input., Thus 2.3456 * 3.14156 - 1.02 = 6.35 (i.e. 3 significant digits). Any more digits in the result are _useless_. Technically to be even more accurate you state the actual result and the error, but the number digits is usually sufficient to get the general idea.
This is physics 101.
There is similar work being done on FreeBSD:
http://www.cl.cam.ac.uk/research/security/capsicum/
One can only hope that this dirty "hybrid GPU" hack goes away rather sooner than later. I simply can't comprehend why it's inventor came up with the idea to _add more_ hardware to decrease power consumption, instead of just fixing the original problem.
Both yes and no. Sure, the OS will use processing time to run another thread while one is blocked, but it has to preserve its complete call stack - e.g. on Windows, that's the default reservation of 1Mb for every thread, plus whatever it may have incurred on top of that. With async model, the continuation closure only needs to preserve what it needs to run after control is returned to it, which can be significantly less.
I mostly agree, but I see this more as an implementation detail. The root cause here is that threads are apparently resource intensive. In a perfect world, the data that a thread would have to store during a context switch is exactly the same amount that you would store yourself during a voluntary context switch. In reality, the "win" from the asynchronous model is that you as an application developer have more knowledge about that state that needs to preserved than the OS probably will ever have and thus can write more efficient applications.
I agree that for single threaded client side programs, it is a real boon not to have to use threads, and still be responsive while performing I/O.
Really the only difference between a synchronous and an asynchronous model is that you shift the burden (and the resources) of multitasking from the the operating system to the application. Under the hood, everything is always asynchronous. It's just that in a synchronous multi-threaded program the OS deschedules a thread whenever you do a blocking call, instead of doing it yourself. So you can consider threads to be syntactic sugar for any I/O bound program.
I disagree with the view that "headaches" of concurrency go away with a continuation model, because in a server environment, you often have to deal with shared resources, and I don't really see how this model helps (note that asynchronous model does not mean no threads...). The two concepts are orthogonal IMHO.
In case of your example, a UI, instead of letting the OS take care of the state of the background threads, you now have to keep state yourself, needlessly complicating application design. For complicated tasks you will get enormous state machines.
Yes, thats sequential. Obviously with forward seeks or seeks of any kind, performance will diminish. Still I suppose if you could put everything that is needed for booting on the first 100MB of the disk, you could read it in about a second... I'm speculating here, but perhaps someone might write a boot cache that does a trace of an actual boot and caches all those data blocks in order somewhere on the disk. That should speed things up significantly.
Except that FreeBSD/Solaris/Windows all have there own loader and only linux uses the one from GRUB
Simple enough, each OS has its own boot loader installed on its root partition. The boot loader only needs to know how to interpret the filesystem for that particular OS and load its kernel. A simple boot manager is installed in the MBR that just knows how to "chainload" (i.e. boot a boot loader, regardless of filesystem).
I'm afraid it really is so. Here are some screenshots to prove it.
Downloading a big file
http://lux.student.utwente.nl/~pyotr/dump/hddspeed.png
Uploading a big file
http://lux.student.utwente.nl/~pyotr/dump/hddspeed-up.png
Destination disk is
ada0: ATA-8 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
I can assure you FreeBSD does not do write behind caching (well it does, but only 1MB or so). Windows probably does.
I'd say that 100MB/sec for ordered reads or writes on a single consumer HDD with filesystem is actually realistic. For example, I can copy large files between my workstation (Windows 7) and my server (FreeBSD, Samba) at 100MB/sec. Admittedly, the filesystem on the server (UFS2) is only 30% full. The disks in both systems are modern 7200rpm devices: WD Caviar Blue 640GB and a random Samsung 1TB HDD. Both systems use AHCI capable (onboard) controllers. If you can't get more than 25MB/sec sustained from your hardware, it must be really old or something else is wrong.
I know you're trying to be funny but to enable Jersey for example you only have to add a couple of lines to web.xml. The actual REST interfaces are defined using annotations.