Wikipedia:Reference desk/Archives/Computing/2012 December 1

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

December 1

Python syntax error

I've recently started learning Python, and I'm trying to write a simple program to calculate the day of the week. However, the following code (designed to determine if a user-entered year is a leap year, in which case 1 must be subtracted from the total) does not appear to be valid:

if month == January or February and year % 4 == 0 and year % 100 != 0:
total = day + month_code + int((year_breaker[-2:]/4)) + int(year_breaker[-2:]) + century_code - 1
elif month == January or February and year % 400 == 0:
total = day + month_code + int((year_breaker[-2:]/4)) + int(year_breaker[-2:]) + century_code - 1
else total = day + month_code + int((year_breaker[-2:]/4)) + int(year_breaker[-2:]) + century_code

When I run the program, I receive the following error:

 File "Weekday.py", line 53
   else total = day + month_code + int((year_breaker[-2:]/4)) + int(year_breaker[-2:]) + century_code
            ^
SyntaxError: invalid syntax

What is invalid about the "l" of "total"? Pokajanje|Talk 00:06, 1 December 2012 (UTC)

missing colon after else. -- Finlay McWalterჷTalk 00:15, 1 December 2012 (UTC)

Yes, but also Python requires proper indentations, as a syntax element. Perhaps they were lost when the OP did the cut and paste, but, just in case, here it is corrected:

if month == January or February and year % 4 == 0 and year % 100 != 0:
   total = day + month_code + int((year_breaker[-2:]/4)) + int(year_breaker[-2:]) + century_code - 1
elif month == January or February and year % 400 == 0:
   total = day + month_code + int((year_breaker[-2:]/4)) + int(year_breaker[-2:]) + century_code - 1
else:
   total = day + month_code + int((year_breaker[-2:]/4)) + int(year_breaker[-2:]) + century_code

StuRat (talk) 00:20, 1 December 2012 (UTC)

Note that error messages frequently point to the next thing after the error, rather than the error itself, as in this case. StuRat (talk) 00:23, 1 December 2012 (UTC)

Thanks for the quick responses and your patience. I am now receiving another, unrelated error. The formula requires that one of seven different numbers be added to the total, depending on the month (I have named this variable "month_code"). So early on in the program I have:

month = raw_input("Enter the month (the whole word). ")

And later I have an if statement beginning with:

if month == April or July:
    month_code = 0
elif month == January or October:
    month_code = 1

When the program runs, I can enter all the data, but then I receive:

NameError: name 'April' is not defined

Just as the previous error, I'm sure this is something obvious, but I don't know enough to see it. Pokajanje|Talk 00:34, 1 December 2012 (UTC)

• (edit conflict) Note that month == January or February will yield True as long as February is not False/None/0; use

month == January or month == February

or

month in (January, February)

Use parentheses to force the operator precedence you want, for example

if (month == January or month == February) and (year % 4 == 0) and (year % 100 != 0):

which also comes with the benefit of added readability. About the April symbol error, look up your code, make sure that April is being defined before execution reaches that point — Frankie (talk) 00:41, 1 December 2012 (UTC)

I tried all three of your suggestions. None worked. I intend that if the user enters "April", thereby making "month" equal to it, "month_code" will be zero. So there's really nothing to define. Pokajanje|Talk 00:55, 1 December 2012 (UTC)

Ok, are you doing something like month = raw_input("Please enter the month: ")? If so you need to use quotes because it is a string: if month == "April". It's case sensitive, so if the user enters "april" it will yield False — Frankie (talk) 01:09, 1 December 2012 (UTC)

Yes, and I have since fixed that and several other errors. The program now runs fully, but it gives the wrong days (calling November 30, 2012 a Monday). I looked through it very carefully, and checked the math and the formula myself, but I still can't find my mistake. The full source code (thus far) can be found here. The formula I am using can be found here. Pokajanje|Talk 04:59, 1 December 2012 (UTC)

Diagnosing these problems is called debugging and it's a very major component of programming at every level, so now you get to develop some skill at it. The amount of code you wrote without testing and debugging it was already maybe larger than ideal. You should write just a little bit of code (just a few lines when you're just getting started), test it, fix any problems, write a little more, etc. But this program is still pretty small and you should be able to find the problems and fix them.

Anyway what I'd suggest is working through the formula by hand with pencil and paper for a known date like November 30, 2012; write down all the intermediate results. Do you get the right answer? In this case, the program has errors. Add a series of print statements to the program to show the intermediate results during the calculation, and compare them to the steps in your hand calculation. Where you see a discrepancy, figure out what has happened, and that is probably a bug. Of course there may be multiple bugs, so keep testing and checking til you're confident that everything is fixed. Generally, don't try too hard to figure out in your head what the program is going to do at a given point, since it's easy to make errors. Add print statements to trace the program's activity so you can know for sure whether it's going wrong at a particular place.

One note: the integer division operator in Python is // (double slash) rather than / (single slash). Single slash works in Python 2 but will throw a warning is deprecated. In Python 3, it will give a floating point result and that can lead to wrong outputs. 66.127.54.40 (talk) 07:09, 1 December 2012 (UTC)

I'm aware of debugging & its importance. I just don't know enough to see the bug yet. Pokajanje|Talk 17:15, 1 December 2012 (UTC)

A few minor problems I see:

1) When you give the error message "Error: this program cannot find dates before 1500 or after 2699", you don't do anything to prevent it from executing the rest of the code normally. Ideally you would loop back and ask for the year again.

2) Asking for the first two digits of the year, then the last 2, is sloppy. You should just ask for the full year and parse it yourself.

3) The prompts should end in a colon, not a period. This is how the user can easily distinguish between normal prints (ending in periods) and prompts.

4) As pointed out above, you need to change the month name to either all uppercase or all lowercase, to make comparisons work despite their case. Python provides simple methods to do those conversions.

5) "Enter the day" is ambiguous. Try "Enter the day of the month" (versus the day of the week).

6) You have part of the last line repeated at the end, causing a syntax error.

As for why you are getting wrong answers, if you can provide a text description of the logic you are attempting to implement, it would be easier to for us to help you debug. StuRat (talk) 07:41, 1 December 2012 (UTC)

Just to help the OP along: You program still has the (incorrect) if month == "April" or "July". This is not interpreted as if (month == "April") or (month == "July") as you intend. "July" on its own is the the second expression evaluated for the or. Since the truth value of a non-empty string in Python is True, this part is always true, and (anything or True) is also always true. Use the expanded version (something like that works in nearly every language), or use month in ("April", "July") - something similar works in many modern high-level languages (like Python), but not in other languages. --Stephan Schulz (talk) 07:56, 1 December 2012 (UTC)

What I would suggest (kind of a more specific debugging suggestion) is printing the values of month_code and century_code after they are computed. Are the results what you expected? If not, you have narrowed down the problem. 66.127.54.40 (talk) 08:33, 1 December 2012 (UTC)

The problem was with century_code as described by Stephan Schulz. The program now works perfectly (I have removed the error messages for simplicity) and it can be seen here. Thank you all for your patience. Pokajanje|Talk 19:23, 1 December 2012 (UTC)

You haven't addressed my points #1 and #4, so it's not going to work in those cases. Also, you might want to change from "was" to "is" when you print the results, since the date might be in the past, present, or future. (You could also check against the current date and use "was", "is", or "will be", where appropriate, but that gets involved, as it depends on time zones, daylight savings time, etc.) StuRat (talk) 02:23, 2 December 2012 (UTC)

The simplest way to fix issue #1 is to add an "else:" after the error message, and indent the rest of the program after it. This won't prompt them to re-enter the year, though, the program will just end. StuRat (talk) 02:34, 2 December 2012 (UTC)

The simplest way to fix issue #4 is to add this line after they input the month:

month = month[0].upper() + month[1:].lower()

This will make the first letter of the month uppercase and the rest lowercase. StuRat (talk) 02:51, 2 December 2012 (UTC)

Also, I suggest you replace the last bit with this:

               print "%s %s, %s is a" % (month, day, year),
               if   total % 7 == 0:
                       print "Saturday."
               elif total % 7 == 1:
                       print "Sunday."
               elif total % 7 == 2:
                       print "Monday."
               elif total % 7 == 3:
                       print "Tuesday."
               elif total % 7 == 4:
                       print "Wednesday."
               elif total % 7 == 5:
                       print "Thursday."
               elif total % 7 == 6 :
                       print "Friday."

The advantage (along with being shorter), is that there's a single point of control. Thus, if you want to change the common part of the print, you need only change one line, instead of all 7. StuRat (talk) 03:24, 2 December 2012 (UTC)

An even simpler and more compact idiom would be

         weekdays = ("Saturday", "Sunday", "Monday", "Tuesday", "Wednesday", "Friday")
         print "%s %s, %s was a %s." % (month, day, year, weekdays[total % 7])

I.e. make it data-driven, not driven by control flow. --Stephan Schulz (talk) 08:16, 2 December 2012 (UTC)

...but don't forget to change "was" to "is", as I did, to avoid "January 1, 2200 was a Wednesday.". StuRat (talk) 08:38, 2 December 2012 (UTC)

Instead of month[0].upper() + month[1:].lower() you can write month.title(). StuRat, I know you just started learning Python and I don't think you should be instructing people in it quite yet.

The test century < 15 or century > 26 can be written not (15 <= century <= 26). This doesn't work in most other languages, though. (In C or C++ it will silently do the wrong thing).

For what it's worth there are standard library functions to do all of this stuff. You can replace everything after the raw_input statements with this:

        import time
        t = time.strptime("%d %s %d" % (century * 100 + year, month, day), "%Y %B %d")
        print time.strftime("%B %d, %Y is a %A.", t)

See the documentation. Of course, it's fine to do everything yourself for practice, but once you're done practicing you should discard your code and use the library functions, since they're already debugged. I think no one has pointed out yet that your code tests century % 400 == 0 (it should be century % 4 == 0), and there may be other lingering bugs. -- BenRG (talk) 18:11, 2 December 2012 (UTC)

Your method only shows them how to change a string to title form, while mine teaches how to change to uppercase and lowercase, and also how to slice and concatenate strings. Also, I doubt if you would have thought to show them any of it, had I not already brought up the issue. As for the 400 year check, I think that's right. The leap year rule is, every fourth year is a leap year, except for every hundredth year, except for every 400th year. So, 1600, 2000, and 2400 are still leap years, while 1700, 1800, 1900, 2100, 2200, and 2300 are not. StuRat (talk) 19:12, 2 December 2012 (UTC)

Also, Ben, I did at least test my code. Your code doesn't work. First you need to define "century", perhaps with "century = year_breaker[:2]". Also, you are using "year" to mean just the last two digits of the year, while the OP is using it for the entire year. Finally, I get a string/integer incompatibility error when I try to run it. StuRat (talk) 19:30, 2 December 2012 (UTC)

JQuery works on Codecadamy but not on my machine

I'm working on this exercise: http://www.codecademy.com/courses/jquery-checkers-part-2/0#!/exercises/1

If you click "Result", you see a brown outline of a box and the words, "Checkers Moves: 0". Well, I get that far when saving the four files: Checkers.html, provided.js, script.js,style.css to a folder on my desktop.

However when I add the code that creates the 64 squares, it works on Codecadamy, but on my computer it doesn't register the changes (64 squares do not appear within the brown box, it looks just like it did before). I am positive I saved my work. Any ideas why it isn't showing the changes? 169.231.8.73 (talk) 09:16, 1 December 2012 (UTC)

Are you linking to the JQuery library? The Codeacadamy frame includes a JQuery call that isn't listed in checkers.html (probably to simplify things, but it strikes me that it will confuse things). In the "<head>" section of checkers.html, add <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js" firebugignore="true"/> (which is the missing line of code). --Mr.98 (talk) 16:06, 1 December 2012 (UTC)

It works!!! Thank you!169.231.8.73 (talk) 01:51, 2 December 2012 (UTC)

Help finding information for Teknique Freeview Box T181b

I was thinking of getting a Teknique Freeview Box T181 from my nearest store, but there is very little information for it both in store & on their website. All I would like to know is does this product have a Timers Menu option (so I can set it to come on to record a programme if I'm out), similar to the DigiHome AV16890. I have already tried their website but its getting upgraded or something. Any help ? 80.254.146.140 (talk) 12:06, 1 December 2012 (UTC)

Well, are there any other freeview boxes that have the same/ similar Timers Menu feature as the DigiHome AV16890 ? 80.254.146.140 (talk) 13:28, 4 December 2012 (UTC)

64 bit / 32 bit

Can anyone explain in simple words what the difference is between having 32 bit OS or 64 bit OS? 117.227.39.231 (talk) 14:56, 1 December 2012 (UTC)

A 64 bit OS can make use of more RAM, whereas (normally) a 32 bit OS is limited to a maximum 4GB of RAM. 64 bit programs and drivers will not work on 32 bit OS. These are the two main differences 92.233.64.26 (talk) 15:54, 1 December 2012 (UTC)

Older x86 processors (386, 486, etc.) ran 32-bit code. Later (starting with the Athlon 64 and crossing over to Intel) a 64-bit mode was added, which expanded the instruction set and the address space, but also supported backwards compatibility with 32-bit processors. 64-bit mode is generally faster because of the added instructions and registers and because the instructions operate on bigger chunks of data. Its drawbacks are incompatibility with 32-bit processors, and increased memory consumption (because pointers and sometimes integers use 8 bytes instead of 4, and your program might use a lot of them). You have to use completely different compiler settings, runtime libraries, etc., so there are generally separate OS installs. I haven't benchmarked carefully or anything like that, but I'd say use a 32-bit OS if your computer has 2GB of memory or less. If you have 2-4GB, it's a toss-up and the best choice might depend on your workload. Above 4GB, you probably want a 64 bit system. 66.127.54.40 (talk) 16:33, 1 December 2012 (UTC)

In Windows, if you have 4GB of RAM, in 32-bit you get access to only 3.2GB or something like that whereas in 64-bit I think you get access to the whole 4GB. Of course, the 64-bit may use up more memory than 32-bit, but with 4GB I prefer 64-bit Windows. (I have two computers with that configuration.) Bubba73 ^{You talkin' to me?} 06:22, 6 December 2012 (UTC)

This is covered at 64-bit computing, and 64-bit computing#32-bit_vs_64-bit. If you just want help deciding which version to use on some hardware you've got: if the processor is a 64-bit processor, you may as well use a 64-bit OS. ¦ Reisio (talk) 17:30, 1 December 2012 (UTC)

Originally, when computer designers said a CPU was "64-bit", they were referring to the smallest addressable memory, and the default word-size for arithmetic operations. This is a very specific technical usage, and it had a lot of implications to performance. Because computers are very complicated, one single parameter like "word size" is not a complete way to define the performance of the entire system. This is complicated by the fact that inside a single processor, different parts need to be 8, 16, 32, 128- bits, 36 bits... and so on - in fact many different bit lengths are typically used internally. In general, "64-bit" has ceased referring to a specific parameter, and has come to mean a more recent generation of higher-performance-class processors. Often, it means that the x86-64 Intel architecture is in use, referring to a specific standard architecture; but not all 64-bit computers are made by Intel or use the Intel architecture. Consider this parameter in the same way that you read "4-cylinder" and "6-cylinder" engine. In isolation the number tells you nothing about the performance or quality of a car or its engine. In practice, it is widely known that 6-cylinder engines are designed and marketed as more powerful engines for more expensive, higher-performance vehicles. The same applies to computing: a 64-bit processor is usually built into and marketed for a higher-class, higher-performance machine. In the last few years, it has actually become difficult to find processors for consumer personal computers that are marketed as 32-bit systems, because 64-bit technology has matured and captured this market. Nimur (talk) 19:53, 1 December 2012 (UTC)

VB 6

Can anyone give me a link where I can download Visual Basic 6.0? 117.227.39.231 (talk) 15:13, 1 December 2012 (UTC)

I'll Assume Good Faith that you're not asking for pirated software, which we can't provide links to, of course. Alas, VB6 is not legally for sale anymore, unless perhaps you find old installation disks on eBay (the legality of which is at least murky, licenses and first sale and all). You can, however, get VB.NET for free, in the form of Visual Studio Express. There are tools that sometimes — but not always — can automatically convert VB6 code to VB.NET, but they are really very different languages. If that isn't satisfactory (which I don't disagree with; I think VB.NET is a fairly painful language in comparison, a strange mix-up of VB and other languages), your only recourse is to illegal methods, and we can't help you with those. --Mr.98 (talk) 15:56, 1 December 2012 (UTC)

http://msdn.microsoft.com/en-us/subscriptions/downloads/#searchTerm=visual%20basic%206 ¦ Reisio (talk) 17:27, 1 December 2012 (UTC)

Hmm, that's interesting. It seems with certain types of MSDN subscriptions you can get VB6 Enterprise Edition? It's too bad that they all seem to be fantastically expensive (hundreds if not thousands of dollars). --Mr.98 (talk) 19:28, 1 December 2012 (UTC)

Well, it'd be too bad if VB6 were worth having (at any time in history). :p ¦ Reisio (talk) 19:51, 1 December 2012 (UTC)

Well, it's not a bad little language for quickly mocking up something with an interface. Surely even you can admit that. VB.NET is a poor substitute in this respect — it has pretensions of being a real language but it's not, and yet it makes quickly mocking things up more difficult than it ought to. Worst of both worlds. It's still stupid that you have to have an expensive membership to get access to a discontinued language. --Mr.98 (talk) 20:13, 1 December 2012 (UTC)

Yeah, but it's so old, it's hard to care that they don't care. :p ¦ Reisio (talk) 20:31, 1 December 2012 (UTC)

Yack, what's the deal with not providing illegal advice. Legal advice is the kind we are to avoid...

No really, in the EU, it's OK to pick up genuine CDs via ebay (and virtually any way as long as it's genuine and not used at more than one place at a time). Yes, anything beyond that would be a "surprising" requirement, and if you cannot see that requirement before buying the product, it is void. - ¡Ouch! (^{hurt me} / _{more pain}) 18:37, 1 December 2012 (UTC)

It's not so much the Reference Desk has specific "illegal advice" policies, it's that we don't want to run afoul of Wikipedia's own copyright policies. Anyway, it is not exactly hard to figure out how one might do a thing on the Internet. But we shouldn't play a role in that. Actually, the OP's IP geolocates to India anyway, so it's probably neither here nor there to cite EU vs. US first sale policy (I find the EU's approach much more sensible than the US's, but who cares what I think?). --Mr.98 (talk) 19:28, 1 December 2012 (UTC)

Also, if you are looking for a VB6-like language, you might check out Realbasic. It's not really VB — and so can't used VB linked libraries or OCXs or COM controls or whatever — but the actual language itself is functionally almost identical to VB in terms of syntax (and difficulty), and the interface provides many of the same features. It also can be cross-compiled. There are free trials on their website. --Mr.98 (talk) 20:17, 1 December 2012 (UTC)

Ouch again. I know that WP:LEGAL and similar rules are not RD-specific; I should have added a little emoticon to the 1st line of my reply. I just wanted to point out that not all countries have regulations sillilar to the US's (which are a bit on the pro-industry side), and that there is good point in WP:AGF on this topic. I was afraid that the topic could be dismissed as criminal by one who didn't know. That would have been a good-faith closure but still a very poor one.

Reisio said it best - I'm not exactly fond of VB myself. So-called object-oriented languages without destructors are not any better than qBasic IMO. And all those silly file extensions (VBX, OCX, etc) are no good either. They are glorified DLLs.

Just my bits. - ¡Ouch! (^{hurt me} / _{more pain}) 08:42, 3 December 2012 (UTC)