The problem comes when we try to fit in behaviors into our model, rather than have models to explain behavior.
Sun does what it wants to do - Just because scientists observed something periodic, does not require the Sun to behave appropriately.
For e.g., fitting employees performance to a Bell Curve (normalization curve) - Here we take data and fudge it to fit into the model for the sake of convenience of management.
It might be of scientific interest to see why this happened, though. Just let the Sun be!
Sriram
I tried Help Desk Pilot for some time - There used to be a free version for limited users. The support is also pretty good.
I am not sure if the free version is still around. It's worth checking out
http://www.helpdeskpilot.com/
In the current configuration available with XOHM, Clearwire (DL/UL - 35/12), it is possible to achieve 46 Mbps using MIMO and 64 QAM 5/6 with 10 MHz bandwidth in 2.5/2.6 GHz operation.
But, this is the throughput at the Base Station. Good Wimax terminals can handle up to 35 Mbps (some claim 40 Mbps) in the downlink.
64 QAM 5/6 is already pushing the limits of wireless. It is possible to decode this modulation and coding only at very high signal to (noise+interference) rations. So, as someone pointed out earlier, it may not be possible for everyone in the coverage to get 64 QAM data. (Unless the Base station supports multi antenna/BeamForming techniques)
It is possible to increase the throughput by increasing the bandwidth. To increase further than 46-50 Mbps, we'll need new coding techniques or use more MIMO (currently only two antennas are used - Wimax supports 3 and 4 antenna schemes too)
I am not too conversant with LTE to comment about it.
I think Zune is one kind of player, where MS focus on blocking different kind of contents instead of playing all kinds of contents.
The wrong focus (IMHO) leads to bad design and hence reduced usability.
I am worried that Zune still sells even only in small numbers. (Why?)
I feel the reason this article was slashdotted was only because of the interesting title, and not because of the contents. I found the article quite boring and uninformative.
I agree that it is extremly difficlut to be truly random. There are some good ways of initializing the seed in such a way that the pseudo random number generator behaves differently.
A good way, done in telecom terminals is to measure the noise at the receiver and then use it to seed the random number generator. Since, the noise is truly random, that is a good way to seed the random number generator. If the costs, are not too high, then it might even be a good idea to read noise (or any truly random parameter) whenever required. That would be close to really random, provided, we can map the random parameter into a quantitative parameter without big errors and approximations.
I dont think Python belongs to the category of C* languages. Check out IronPython (http://www.ironpython.com/). I believe python is a good language to start programming compared to Java or C#. since your University may not have that in the syllabus, it may be a good idea to choose C#, unless you are paranoid of locking into Microsoft technologies.
Slashdot Mirror
The problem comes when we try to fit in behaviors into our model, rather than have models to explain behavior. Sun does what it wants to do - Just because scientists observed something periodic, does not require the Sun to behave appropriately. For e.g., fitting employees performance to a Bell Curve (normalization curve) - Here we take data and fudge it to fit into the model for the sake of convenience of management. It might be of scientific interest to see why this happened, though. Just let the Sun be! Sriram
I tried Help Desk Pilot for some time - There used to be a free version for limited users. The support is also pretty good. I am not sure if the free version is still around. It's worth checking out http://www.helpdeskpilot.com/
I was expecting something better :-)
In the current configuration available with XOHM, Clearwire (DL/UL - 35/12), it is possible to achieve 46 Mbps using MIMO and 64 QAM 5/6 with 10 MHz bandwidth in 2.5/2.6 GHz operation.
But, this is the throughput at the Base Station. Good Wimax terminals can handle up to 35 Mbps (some claim 40 Mbps) in the downlink.
64 QAM 5/6 is already pushing the limits of wireless. It is possible to decode this modulation and coding only at very high signal to (noise+interference) rations. So, as someone pointed out earlier, it may not be possible for everyone in the coverage to get 64 QAM data. (Unless the Base station supports multi antenna/BeamForming techniques)
It is possible to increase the throughput by increasing the bandwidth. To increase further than 46-50 Mbps, we'll need new coding techniques or use more MIMO (currently only two antennas are used - Wimax supports 3 and 4 antenna schemes too)
I am not too conversant with LTE to comment about it.
I think Zune is one kind of player, where MS focus on blocking different kind of contents instead of playing all kinds of contents. The wrong focus (IMHO) leads to bad design and hence reduced usability. I am worried that Zune still sells even only in small numbers. (Why?)
I feel the reason this article was slashdotted was only because of the interesting title, and not because of the contents. I found the article quite boring and uninformative.
I agree that it is extremly difficlut to be truly random. There are some good ways of initializing the seed in such a way that the pseudo random number generator behaves differently. A good way, done in telecom terminals is to measure the noise at the receiver and then use it to seed the random number generator. Since, the noise is truly random, that is a good way to seed the random number generator. If the costs, are not too high, then it might even be a good idea to read noise (or any truly random parameter) whenever required. That would be close to really random, provided, we can map the random parameter into a quantitative parameter without big errors and approximations.
I dont think Python belongs to the category of C* languages. Check out IronPython (http://www.ironpython.com/). I believe python is a good language to start programming compared to Java or C#. since your University may not have that in the syllabus, it may be a good idea to choose C#, unless you are paranoid of locking into Microsoft technologies.