You can use the moon as a reflector for radio waves, it's just not very effective. In the early days of long range wireless communications using the moon as reflector was quite a popular theory. Problem is the delay really, and the power needed to broadcast so a relatively small receiver can pick it up. Turns out that a distance to a negative power lower or equal to -2 is quite a hassle when you're trying to reflect something of the moon. But to get back to the original point, yes you can in fact reflect things of the moon. Another fun thing people used to try was lifting huge metal balls into the sky with balloons and using those as reflectors. Luckily we have satellites these days, but I hope you get the point. Bonus points to the person who bounces a signal of Mars.
Even with a fairly low transmission power (1 W) you can reach hundreds of meters. So yeah, it'll extend far beyond the school unless your intended range of use is 1 cm.
Fortran is compiled directly to machine code in most cases. The Fortran VMs and interpreters aren't used all that often as far as I'm aware. At least I haven't seen any of them used in production environments. Lets take a good example: Intel Composer actively seems to avoid microcode based instructions and goes for fast hardware implemented ones and uses all features of the hardware. Pretty interesting to see at times how much a good compiler can make a difference. Trying to achieve the same with compiled python will be very difficult simply due to the language's structure. Even more so if you consider how compile paths can include things like java bytecode. Lethal for performance on x86 based systems.
And I'm not moving goalposts at all, it's not because your definition of interpreted is so skewed that mine is. Not interpreted means it runs on bare metal without any form of code interacting with it (so no microcode either).
First of all, if you keep pulling different implementations out of your hat you can try to prove anything. And C and Fortran interpreters, lets just not go there before this turns into a complete comedy. You butcher both languages simply by doing that. On the other hand, Python wasn't designed to be compiled like that and is inefficient at it. So yes, our definition still holds. Compiling such a language will never lead to an optimal implementation in size, memory usage or performance. If you take the path you suggest it becomes even worse. The JVM is stack based, modern x86 processors are pretty much the exact opposite. Translation only goes so far. There goes your efficiency... And it's not because it's linkable that it's fast or worth using, we all remember PHP Phalanger don't we? That one also produced linkable code...
Sorry, but you're wrong: it is. Or did you forget where the PYC files come from? You might want to read the official Python documentation on this one http://docs.python.org/3/glossary.html . Go to "interpreted" in case you're too lazy to find it yourself. And by the definition we use over at the electronics department Python is an interpreted language no matter what you wish to claim.
Most of those are still interpreted. It's not because it's a bytecode that it's not interpreted. In fact even your CPU interprets complex instructions and executes them using a set of simple instructions in a lot of cases (yay for RISC/CISC hybrids). A pre-compiled generalised library will never reach the performance of real Fortran code. People often forget that a lot of Fortran's performance comes from the way it deals with memory, pre-compiled libraries can't do that. Not to mention what a few decades of optimizer development has done for Fortran.
I doubt SciPy would have been as easily to expand for running on a cluster. These sort of things come of as natural to Fortran. Additionally if I write my code in Fortran the compiler can optimize it a lot further than Python will allow me to. Hence the speed advantage is still in Fortran's hands which is important if you don't have access to the latest hardware and time on large clusters.
Sure you can, any language that has a full feature set can do any task that the system is capable off. But efficiency is also important, and Fortran simply has so much advantages over Python. Complex data structures aren't needed for most simulations while they make optimisation so much harder. Additionally interpretation is a serious bottleneck.
You're comparing two very different tasks. A game and a large simulation are very different things. Lets compare two extremes: EVE online and the FDTD algorithm (EM field solver). EVE Online has a lot of conditionals. It's very unpredictable in memory usage. But the FDTD algorithm has very different properties. It needs a lot of data, but there are no conditional expressions. Additionally what's needed from the memory is known long before it's ever needed. It just goes over the data every pass without analysing it. It simply does calculations. Do you see how this can be done efficiently on a pipelined CPU? You can ensure the data shows up on the right spot at the right time. The Fortran compiler tries to analyse the implemented algorithm and optimize these sort of things, that's where it strength lies. The same sort of compiler would be very difficult to write for Python.
Nah, Fortran was designed with number crunching for scientific and engineering applications in mind. It won't choke, it won't stop. Fortran compilers are far smarter than Python when dealing with memory. The language was designed to allow the compiler to make assumptions to speed up computation and make for efficient memory management. But I'll agree that you shouldn't write the entire application in Fortran. For visualisation other languages are better suited (MATLAB/Octave comes to mind). You can have a python script to assign the tasks to the cluster. But for the actual calculations I'd still use Fortran. It's still the tool of the trade for very good reasons.
I disagree partially with what you said based on personal experience. As an EE student I had to learn to use Fortran for my thesis. I needed to run a large EM simulation and not a single affordable commercial program was able to run on a small cluster of computers that was available. So I resorted to using Fortran and MATLAB for visualisation. So I managed to learn basic Fortran over the weekend and then use it to write a working program for a cluster, all within 1 week time. I just don't think I could have done that with Python. Especially considering the time constraints I had in terms of runtime.
You're dead wrong, nothing quite beats Fortran in speed when it comes to number crunching. If you need to go through hundreds of gigabytes of data and performance is important there's only one realistic choice: Fortran. Python isn't fit to run on a large cluster to simulate things, too much overhead. And lets not forget what sort of efficiency you can get if you use a good compiler (Intel Composer). You won't find Fortran on the way out over here, it's here to stay!
Yay for those of us in the EU... Due to strict regulations the chances of finding a well paid internship are near 0 without some borderline legal construction. Like having the student work his last day as student job and paying him his full salary in that single day. It just doesn't pay off to get an internship over here for most students.
What's even more interesting is that IEEE doesn't list it as a WiFi related patent: http://standards.ieee.org/about/sasb/patcom/pat802_11.html
And considering IEEE doesn't tend to mess around about these sort of things. Actually you might want to contact them on this one. If it works once it could work on bigger players as well, so there is a chance they'd actually take a look at the patent and see if it's worth anything. While I doubt it'll help, it probably wouldn't hurt to try.
As IAmR007 explains so nicely in #42777533. There are problems when attempting to integrate magnetic particles with current production techniques is quite a challenge. But an interesting one. Semiconductors generally use materials like aluminium, copper, titanium, and so on. None of these materials actually exhibit feromagnetism, as such you need to keep a current flowing to sustain a magnetic field.
Yes, but a magnetic field needs a current. FPGAs are electrostatic in nature, once you're past the big startup current it levels off. To keep a magnetic field going (small as it might be) you need to have a current flowing...
Mhhh, you sure? I've seen a few that were pretty high up in bandwidth, they use the same method to make some of their high end scopes. Then again, you are trying to make a Fourier analyser so you will need a pretty sharp filter at 4 GHz. Good luck with it!
I'm wondering, have you tried interleaving 1 GSa/s units? They're more likely to cough those up considering how long they've been around. Though the clock distribution might become problematic.
Slashdot Mirror
You can use the moon as a reflector for radio waves, it's just not very effective. In the early days of long range wireless communications using the moon as reflector was quite a popular theory. Problem is the delay really, and the power needed to broadcast so a relatively small receiver can pick it up. Turns out that a distance to a negative power lower or equal to -2 is quite a hassle when you're trying to reflect something of the moon. But to get back to the original point, yes you can in fact reflect things of the moon. Another fun thing people used to try was lifting huge metal balls into the sky with balloons and using those as reflectors. Luckily we have satellites these days, but I hope you get the point. Bonus points to the person who bounces a signal of Mars.
Bluetooth will cause the exact same problem... A real solution here might be using infrared though.
Even with a fairly low transmission power (1 W) you can reach hundreds of meters. So yeah, it'll extend far beyond the school unless your intended range of use is 1 cm.
Fortran is compiled directly to machine code in most cases. The Fortran VMs and interpreters aren't used all that often as far as I'm aware. At least I haven't seen any of them used in production environments. Lets take a good example: Intel Composer actively seems to avoid microcode based instructions and goes for fast hardware implemented ones and uses all features of the hardware. Pretty interesting to see at times how much a good compiler can make a difference. Trying to achieve the same with compiled python will be very difficult simply due to the language's structure. Even more so if you consider how compile paths can include things like java bytecode. Lethal for performance on x86 based systems.
And I'm not moving goalposts at all, it's not because your definition of interpreted is so skewed that mine is. Not interpreted means it runs on bare metal without any form of code interacting with it (so no microcode either).
First of all, if you keep pulling different implementations out of your hat you can try to prove anything. And C and Fortran interpreters, lets just not go there before this turns into a complete comedy. You butcher both languages simply by doing that. On the other hand, Python wasn't designed to be compiled like that and is inefficient at it. So yes, our definition still holds. Compiling such a language will never lead to an optimal implementation in size, memory usage or performance. If you take the path you suggest it becomes even worse. The JVM is stack based, modern x86 processors are pretty much the exact opposite. Translation only goes so far. There goes your efficiency... And it's not because it's linkable that it's fast or worth using, we all remember PHP Phalanger don't we? That one also produced linkable code...
Sorry, but you're wrong: it is. Or did you forget where the PYC files come from? You might want to read the official Python documentation on this one http://docs.python.org/3/glossary.html . Go to "interpreted" in case you're too lazy to find it yourself. And by the definition we use over at the electronics department Python is an interpreted language no matter what you wish to claim.
Most of those are still interpreted. It's not because it's a bytecode that it's not interpreted. In fact even your CPU interprets complex instructions and executes them using a set of simple instructions in a lot of cases (yay for RISC/CISC hybrids). A pre-compiled generalised library will never reach the performance of real Fortran code. People often forget that a lot of Fortran's performance comes from the way it deals with memory, pre-compiled libraries can't do that. Not to mention what a few decades of optimizer development has done for Fortran.
I doubt SciPy would have been as easily to expand for running on a cluster. These sort of things come of as natural to Fortran. Additionally if I write my code in Fortran the compiler can optimize it a lot further than Python will allow me to. Hence the speed advantage is still in Fortran's hands which is important if you don't have access to the latest hardware and time on large clusters.
Sure you can, any language that has a full feature set can do any task that the system is capable off. But efficiency is also important, and Fortran simply has so much advantages over Python. Complex data structures aren't needed for most simulations while they make optimisation so much harder. Additionally interpretation is a serious bottleneck.
You're comparing two very different tasks. A game and a large simulation are very different things. Lets compare two extremes: EVE online and the FDTD algorithm (EM field solver). EVE Online has a lot of conditionals. It's very unpredictable in memory usage. But the FDTD algorithm has very different properties. It needs a lot of data, but there are no conditional expressions. Additionally what's needed from the memory is known long before it's ever needed. It just goes over the data every pass without analysing it. It simply does calculations. Do you see how this can be done efficiently on a pipelined CPU? You can ensure the data shows up on the right spot at the right time. The Fortran compiler tries to analyse the implemented algorithm and optimize these sort of things, that's where it strength lies. The same sort of compiler would be very difficult to write for Python.
Nah, Fortran was designed with number crunching for scientific and engineering applications in mind. It won't choke, it won't stop. Fortran compilers are far smarter than Python when dealing with memory. The language was designed to allow the compiler to make assumptions to speed up computation and make for efficient memory management. But I'll agree that you shouldn't write the entire application in Fortran. For visualisation other languages are better suited (MATLAB/Octave comes to mind). You can have a python script to assign the tasks to the cluster. But for the actual calculations I'd still use Fortran. It's still the tool of the trade for very good reasons.
I disagree partially with what you said based on personal experience. As an EE student I had to learn to use Fortran for my thesis. I needed to run a large EM simulation and not a single affordable commercial program was able to run on a small cluster of computers that was available. So I resorted to using Fortran and MATLAB for visualisation. So I managed to learn basic Fortran over the weekend and then use it to write a working program for a cluster, all within 1 week time. I just don't think I could have done that with Python. Especially considering the time constraints I had in terms of runtime.
Yes, but Python is still an interpreted language and very slow compared to Fortran.
You're dead wrong, nothing quite beats Fortran in speed when it comes to number crunching. If you need to go through hundreds of gigabytes of data and performance is important there's only one realistic choice: Fortran. Python isn't fit to run on a large cluster to simulate things, too much overhead. And lets not forget what sort of efficiency you can get if you use a good compiler (Intel Composer). You won't find Fortran on the way out over here, it's here to stay!
Yay for those of us in the EU... Due to strict regulations the chances of finding a well paid internship are near 0 without some borderline legal construction. Like having the student work his last day as student job and paying him his full salary in that single day. It just doesn't pay off to get an internship over here for most students.
Yeah, this exactly makes no sense if it's related to WiFi. And there's more than enough prior art on this one anyway just by looking at the title...
And there I was thinking it was FDDI...
What's even more interesting is that IEEE doesn't list it as a WiFi related patent: http://standards.ieee.org/about/sasb/patcom/pat802_11.html
And considering IEEE doesn't tend to mess around about these sort of things. Actually you might want to contact them on this one. If it works once it could work on bigger players as well, so there is a chance they'd actually take a look at the patent and see if it's worth anything. While I doubt it'll help, it probably wouldn't hurt to try.
As IAmR007 explains so nicely in #42777533. There are problems when attempting to integrate magnetic particles with current production techniques is quite a challenge. But an interesting one. Semiconductors generally use materials like aluminium, copper, titanium, and so on. None of these materials actually exhibit feromagnetism, as such you need to keep a current flowing to sustain a magnetic field.
Yes, but now try integrating a feromagnetic material. You can't just vapour deposit anything you wish.
Yes, but a magnetic field needs a current. FPGAs are electrostatic in nature, once you're past the big startup current it levels off. To keep a magnetic field going (small as it might be) you need to have a current flowing...
Mhhh, you sure? I've seen a few that were pretty high up in bandwidth, they use the same method to make some of their high end scopes. Then again, you are trying to make a Fourier analyser so you will need a pretty sharp filter at 4 GHz. Good luck with it!
Well, simulation is key really. Additionally it's amazing how you can get some pretty accurate measurements with crude instruments in the HF range.
Most countries have an exception in their laws for experimental low power devices...
I'm wondering, have you tried interleaving 1 GSa/s units? They're more likely to cough those up considering how long they've been around. Though the clock distribution might become problematic.