> Get the full value from curated content you share on social media
Automatically add your presence and promote your content with every external link you share
The problem are the RTL2832U receivers.
The sample rate is too low, 500ns resolution with 2MSample/s is not enough.
For this reason I cannot recommend using the dvb-t sticks as ads-b receiver (the symbol rate is too high, compare nynquist theorem).
Multilateration has already be done for ADS-B on large scale, but with different receivers.
There are receivers available[1] with nanosecond accuracy (and gps time synchronization).
GPS synchronization isn't needed, by choosing other flight paths to provide basic time synchronization between receivers.
Given that UmTRX is dual channel, has a GPS locked clock and is much higher performance is general, I'm thinking it might make for an excellent platform for experimenting with passive RADAR!
"A programmer may try to get you to install Python 3 and learn that. Say, "When all of the Python code on your computer is Python 3, then I'll try to learn it." That should keep them busy for about 10 years. I repeat, do not use Python 3. Python 3 is not used very much, and if you learn Python 2 you can easily learn Python 3 when you need it. If you learn Python 3 then you'll still have to learn Python 2 to get anything done. Just learn Python 2 and ignore people saying Python 3 is the future."
I don't think it is useful for a beginner to start with python3.
Python 3 is useful for a beginner to start with because they don't have to learn the deprecated cruft that Python 2 preserves for compatibility. If they just learn the Python 3 way of doing things, it generally works in both 2 and 3.
In his explanation of classes he has several paragraphs about old-style vs. new-style classes, ending it with:
"Just completely ignore the idea of old style versus
new style classes and assume that Python always requires
(object) when you make a class. Save your brain power for
something important."
Python 3 only has new-style classes, so the entire explanation could have been left out, allowing the beginner to, as he recommends, focus on more interesting things.
Another example is his advice, in exercise 11, to avoid the input() function because of its security problems. Python 3 doesn't have that function, so the beginner doesn't have to remember to avoid it.
And of course, there's Unicode, which this book seems to completely ignore. A beginner starting with Python 3 has to learn the "Unicode sandwich" approach[1], which applies very well to Python 2 code as well. But someone starting with Python 2 can easily be confused about the concept (because the language is confused) and will have a hard time getting things to work correctly. For example, the book recommends that people "from another country" set their source encoding to UTF-8 – good luck printing things on Windows.
No one's saying that Python 3 doesn't improve on Python 2 in significant and tangible ways. The key phrase is "If you learn Python 3 then you'll still have to learn Python 2 to get anything done" which is absolutely true in my experience.[1] This is because as soon as you hit a single dependency that doesn't support Python 3, you have to switch to Python 2. And there are still a good number of important modules that are Python 2 only. (And no, reimplementing the functionality of dependency oneself is not an option for a beginning programmer.) And even if all the modules you need right now are available for Python 3, you might find later that the new feature you want to implement in an existing program requires a Python2-only module. No matter how great Python 3 is, and how much we all wish we could switch to it, we can't just will all our dependencies to add support for it.
[1] Obviously your experience may vary depending on which modules are considered essential for your work.
I'm from "another country" and I always asumed all the characters that couldn't be printed on screen by Python were cmd.exe's (and powershell) fault for not handling Unicode correctly, not a Python "error" per se.
Also, all my Python sources are set to UTF-8 and I never had any problem in Windows. Notepad.exe gives you the encoding option when you save a file, and every sensible text editor/IDE gives you encoding and line feed options.
So what would be the problem with Zed's tip? Have you ever tried to run a Python script with special characters? The interpreter dies instantly with an encoding error. It's easier to set the encoding to UTF-8 and get the program running than parse the whole thing checking whether you used a special character in the comments -- which shouldn't affect program execution, but hey!. Also, this way you can write meaningful comments in your native language without worrying if it'll kill the interpreter right away.
The problem is that the Windows commandline, legacy Windows programs and modern Unix systems all use different encodings, so any particular string of bytes (representing non-ASCII text) will only be correct on one of them.
For example, let's say our Other Country is a Western European country. The encoding for non-Unicode Win32 programs will be Windows-1251 (more or less ISO 8859-1) and the encoding for MS-DOS programs and the commandline will be codepage 850.
In this scenario, this Python 2 program (saved as UTF-8):
#-*- coding: utf-8 -*-
print "ångström"
will print the wrong thing – "├Ñngstr├Âm" if you run it from the commandline, and "Ã¥ngström" in a more Windowsy context (e.g. if you're writing it to a file and reading it in Notepad).
To make it correct, you can apply the Unicode sandwich approach:
1) Know the input encoding and decode from that to Unicode.
2) Process the text as Unicode.
3) Know the output encoding and encode into that encoding on output.
In other words, making it a Unicode string will transform the text from whatever encoding you chose to write the file in to whatever encoding your terminal happens to use, so this program will always (if the system is correctly configured) print the right thing:
#-*- coding: utf-8 -*-
print u"ångström"
In Python 3, UTF-8 source encoding and Unicode strings are the default, so the correct program becomes simply:
The problem isn't extended characters in your Python script, it's how your Python script handles extended character data. Scripts written in Python 2 that ignore the existence of Unicode won't always do the right thing when they encounter non-ASCII strings in the wild.
Nearly all packages are ported to python3.
There are still some bigger projects missing, but these are exceptions and not the norm.
Python3 simplifies many aspects of the language, for example handling of bytes and handling different encodings.
In my day to day use I don't want to miss these features.
Many interesting features where added in 3, like yield from, more powerful generator syntax and the libraries multiprocessing and pathlib.
Well, this quote is a little pessimistic because now almost everything is either Python 3 compatible or has been replaced with something that is and it's only been 7 years. :P
Even NumPy and SciPy work on Python 3 now, and it's not like there are massive differences between Py2 and Py3 anyway, so generally speaking it shouldn't be hard for a noob to revert to Py2 if it becomes inexplicably necessary.
That nearly all good intros to Python for non-programmers insist on teaching only Python 2.x, because Python 2.x is what's used in lots of advanced programs and production code, is an attitude that I've found very unhelpful as a beginner.
True beginners don't need to use numpy and run a bunch of production-ready libraries. They first need to learn what libraries ARE and the basics of using them. Besides, numpy &c. can already run on Python3, how much further will they be along in 1-3 years? Most simple Python3 programs work fine in Python 2.7.9 with little wrangling, and it's not hard to keep two installs of Python.
"Learn Python" right now means "learn both", only many introductory tutorials will refuse to teach both. Instead they'll compound your frustration by making you learn the intricacies of Python 2's print statement instead of print().
A beginner will want to read and write files pretty early on. In Python 2 it's very easy to e.g. ignore that you need to pass the 'b' option for reading binary files and write scripts that seem to work, and then silently corrupt data when run on windows. Which is not a good experience.
Wouldn't this argument preclude using anything new, ever? Don't use C++14 until all of your code is converted to use it. Don't touch ES6 until you throw out your legacy JavaScript. Some of these programs haven't been updated to use Linux-specific features, so let's all stick to UNIX System V.
If anyone is best in the position to take up the bleeding edge with no thought to backwards compatibility, it's the people just starting out. They're the ones who, by definition, don't have legacy code to maintain.
I have my main work database / Django project in Python 2.
I have a few smaller projects I have started since then - I used Python 3.
There are very few noticeable differences. Why would you not start with a more up to date version. Unless there are specific packages you need or expect to need that are not supported I would say Python 3 makes more sense.
I have to serve the student's needs before any in the community, and there's a very practical reason for going with Python2:
The vast majority of code out there is in Py2, so if someone learns Py2 first, they can start coding and doing stuff right now. If they stumble onto a need for Py3 later, then they would have the skill to learn Py3 from the tutorial and other books.
If they learn Py3 first, then immediately they have to learn Py2 because there's simply too much code out there that uses it. This will frustrate beginners as the next thing they need to do after my book is start using Python to make things.
When the situation changes, and not just because the Python leaders say it does, then I'll update the book. Honestly though, I think Go, Rust, Nim, and Clojure have a better chance at widespread adoption than Python3 at this point.
Incidentally, the mistake that the Python3 project made was to not use a virtual machine that could run both 2 and 3 byte code. If I can run tons of languages on my CPU, the JVM, and the .NET CLR, then Python3 could have run both 2 and 3. I predict that to get people on the new version of Python they will have to make Python4 and have it run 2,3 and 4 seamlessly so that it won't matter how much code is out there in any version of the language.
Is anything? I've recently decided to start learning Python and started with the assumption that Python 3 would self-evidently be the sensible thing to do.
I tried that for about a week before discovering that about 90% of the libraries that I wanted to play with, and 90% of the tutorials and StackOverflow answers that I found were 2.7-specific.
It's technically a French company, but they have an incredible 50,000+ employees in India.
There was one development candidate I was interviewing who was speaking to himself in hushed tones, during the interview '...google...sql join...', 'YES, YES, JUST A MINUTE SIR', '...next page...no, no..ah..' etc. Quite ridiculous.
I have to interview about 20 shortlisted people to find 1 decent developer. Problem is it's difficult to use CVs/resumes to shortlist, since many are complete fabrications.
Normally I would say "what's wrong with knowing what to Google for and getting the right answer in a short enough time span to seem like a reasonable response to your dev question" since that's how many devs (who actually get stuff done) work. However, it's hilarious because the internet speeds are so slow in India that they probably would be better off actually spending the time in front of a reference book than waiting for their browser to crawl through Google.
I've no issue with using Google (or whatever your favourite search engine happens to be) in day-to-day work. But in an interview setting, and especially for extremely basic questions, it's completely inappropriate.
Regarding Internet speed, India has seen phenomenal infrastructure changes in the past decade. Internet speed in this particular office in Mumbai is very fast.
Fast connections are available in major cities, for consumers as well as businesses. There are a number of ISPs in Mumbai offering ADSL and FTTH connections (I've only just got FTTC where I am in the UK!).
Seriously: Does anyone expect the FBI to say "Yeah, we're busted. That was our laptop, we've been working with company XXX on collecting UDIDs, and we would have gotten away with it if it hadn't been for those meddling kids."
And your post summarizes what annoys me about people who still throw around "apple fanboy"; you're in an endless witch hunt to find some kind of subtext in what people say just to call them out for their choice of computer. There was nothing in what mdonahoe said to suggest "fanboy".
I don't want to start a flamewar here but "Neither are macs" sounds somewhat arrogant to me, serious and honest question am I the only one to think that?
Edit to comment about the depth limit: I can't comment any deeper. (Karma related?)
There is a time limit to the depth - this is to help prevent pointless bickering.
"neither are macs" isn't, I think, arrogant nor judgemental. A person can buy a Mac if they like that kind of thing, but if they prefer other stuff they can buy other machines. Each person decides what's important to them.
About the device: I don't like the way that micro-SD card adapters stick out the side of the case. I'm not sure I dislike that enough to pay $35, but if people have that kind of spare cash I'm not going to piss and moan at them about it.
Notice how careful I am to avoid mentioning any actual thing that may influence a purchasing decision? That's how frustrating and pointless these conversations can be. :-(
If there are a lot of replies in a short time, the reply link goes away for a bit to moderate the discussion. You can always reply from the comment's permalink.
As much as I might enjoy starting a fight, I'm sure we'd both just get downvoted until we can't read what we said anymore.
I wasn't trying to be snooty or anything with my remarks. I just meant that there is a market for a wide range of seemingly ridiculous stuff in this world.
In a land where people pay big bucks to have double eyelid surgery, inject toxins into their lips, and buy intentionally "distressed" furniture, a slightly better-fitting SD Card adapter doesn't seem so absurd.
2) It was shown that Samsung was willfully trying to make its products similar to Apple's.
There are some further murky corners to the verdict, one aspect which seems will be contested is the size of the damages. The Jury foreman stated that they valued the damages to be "more than a slap on the wrist".
Whereas the instructions given clearly state that the jury is not to levy punitive damages, but to recoup losses incurred by the infringed.
Edit: Going to double check just to be sure.
Update:
Iirc the groklaw point was that
1) Yes there is prior art
but Samsung lost because
2) It was shown that Samsung was willfully trying to make its products similar to Apple's.
There are some further murky corners to the verdict, one aspect which seems will be contested is the size of the damages. The Jury foreman stated that they valued the damages to be "more than a slap on the wrist".
Whereas the instructions given clearly state that the jury is not to levy punitive damages, but to recoup losses incurred by the infringed.
Edit: Going to double check just to be sure.
Update: From the verdict:
Patent invalidity, Samsung had to prove apple invalid - No, across the board for all patents brought up.
Apple contested that 3 feature related patents and 4 design patents were infringed
a) '381 - rubber band - valid / Samsung infringed
b) ’915 - pinch to zoom or scroll - valid / Samsung infringed
c) ’163 - multi-tap to zoom - valid / Samsung infringed
Samsung also was found to be willfully infringing.
Apple has only proven that the unregistered iPhone 3G trade dress is protectable. Negative on the iPhone / iPad combo and the iPad / iPad 2 trade dress
This is a pretty broad sweep of the verdict, a lot of the verdict breaks down onto whether Samsung Telecom America (STA), Samsung Electronics (SEC) and Samsung Engineering America (SEA). This is further broken down over each product which is found to be infringing.
Thank you for that comment. I find it weird that the patent was not only not invalidated, but Samsung was found infringing, even with the Surface prior art clearly existing.
IANAL, sadly; interpreting this thing would take a lot of time and effort for a lay man.
I can understand them getting hit on willful infringement, but the way the verdict was read out, they got hit for infringement first, and then willful infringement.
> Get the full value from curated content you share on social media Automatically add your presence and promote your content with every external link you share