Jump to content

Wikipedia:Reference desk/Archives/Computing/2017 December 21

From Wikipedia, the free encyclopedia
Computing desk
< December 20 << Nov | December | Jan >> December 22 >
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 21

[edit]

How to populate an online poll with options from an Excel spreadsheet

[edit]

I have an excel document with only the first column and 400 rows down full of options for 1 multiple choice question. How do I go about creating an online poll that allows me to fill it with those options from the spreadsheet? for example the polls question is; Which of these options is your favorite food? (The Excel spreadsheet is full of items you could choose from; apple, cherry, pear, ribs, hamburger, chicken etc.) — Preceding unsigned comment added by 2601:247:301:295F:E142:1063:C8BC:A85C (talk) 01:07, 21 December 2017 (UTC)[reply]

Why you need an operator like ++ or --

[edit]

Why not just user something that everybody understands like simply +1 or -1? — Preceding unsigned comment added by 31.177.98.70 (talk) 10:38, 21 December 2017 (UTC)[reply]

See Increment and decrement operators. n+1 is an expression which often occurs in contexts where you don't want to change the value of n but just compute n+1 for other purposes. PrimeHunter (talk) 11:06, 21 December 2017 (UTC)[reply]
Well, I'm sure you've noticed that "X++" is shorter than "X = X + 1".
Incrementing and decrementing are used so often, especially in low level code, that it seemed to C's creators that a bit of Syntactic_sugar would make everybody's life easier. It saves typing, and is easy to read.
But it's not just that. C was written by and for people familiar with assembly language. Most versions of assembly have separate commands for increment and decrement, and they're used quite a lot. So it would have seemed perfectly natural to them for increment and decrement to get special treatment. (This also goes some way towards explaining why the bitwise operations all have one or two character symbols in C. Those are also very common in assembly code.)
ApLundell (talk) 16:17, 21 December 2017 (UTC)[reply]
Credit where due: the ++ and -- operators originated with the language B, created by Kenneth Thompson, not with C, which was created by Dennis Ritchie based on B. Of course the two were co-workers at Bell Labs and would certainly have influenced each other. --69.159.60.147 (talk) 05:13, 22 December 2017 (UTC)[reply]
I think the OP is asking about using x+1 instead of x++. The problem with that is you often want to use x+1 without changing x. Bubba73 You talkin' to me? 18:06, 21 December 2017 (UTC)[reply]
That's right, usually for comparison with something else. Akld guy (talk) 21:00, 21 December 2017 (UTC)[reply]
One advantage is when working with post- and pre- increment, as (++i < 10) is different to (i++ < 10). The first increments i by one and then asks if it is greater than 10, while the other asks if i is less than 10 and then increments i by one. It isn't a construct you need often, but there are occasions when that distinction is useful. - Bilby (talk) 05:42, 22 December 2017 (UTC)[reply]
  1. Parentheses: ++x for any expression x is equivalent to (x+=1) or (if x has no side effects) (x=x+1). The same purpose underlies p->v, which is equivalent to (*(p)).v which gets very ugly in cases like a->b->c->d. (Note, though, that ++p->v is ++(*(p)).v), not (*(++p)).v).
  2. The post operations: x++ is mostly equivalent to (x+=1,x-1), which is even more cumbersome and would raise the question of whether the 1s were equal by coincidence.
  3. Pointers: in many array processing algorithms, we are concerned with the next or previous element, which is conceptually simpler than "the element whose index is 1 larger (or smaller)". --Tardis (talk) 14:26, 22 December 2017 (UTC)[reply]
To my mind, (3) is the most important reason for these operators. As ApLundell points out, C was designed as an more functional alternative to assembly language, and its primary use was to quickly develop operating systems. For that, you need some way to code Pointer_arithmetic. I'd go so far as to say that without this ability, 90% of the functionality C provided over other languages of the day would have been lost. OldTimeNESter (talk) 14:42, 25 December 2017 (UTC)[reply]

Overwriting a list in Python with a slice taken from that list

[edit]

With a long list of numbers in Python, I'd like to search it for a number from a shorter list, and if I find the number, discard everything after that position in the longer list before searching for the next number from the shorter list. Can I do that by slicing the long list and overwriting it with the slice? Because deletion is less efficient, AFAIK. Thanks! 129.67.116.82 (talk) 13:31, 21 December 2017 (UTC)[reply]

It looks like you are concerned about the way something like L=L[0:8] is implemented. From the point of view of a person who teaches operating systems and has students write parsers for common scripting languages (like Python), the implementation that you can't see (because it is buried in Python's executable) is what you need to worry about. Optimally, it will realize that it doesn't need to change the memory pointer for L. It only needs to change the size allocation. You can't expect that. What you should expect is that it will create a completely new memory pointer and allocate size for the new list. It will copy the values to the new list and let the old memory pointer go to garbage. A way to avoid this is to use a temporary list. Set S=L[0:8] and the original list doesn't go to garbage. It still copies everything over to the new list. If you then set S=L[0:4], you can expect it to overwrite the memory location with new data. So, you save the garbage collection in the background by doing this - as long as S continually requests less size. It should because your problem makes it shorter each time. But, that might not happen. It might garbage S every time. You save nothing. So, another idea is to use the index function on the slice itself, such as L[0:8].index(x). This is saying "find x in L, but don't go past index 8." It ends up implementation. Will python just use offset 0 to 8 on the memory location L or will it make a copy of L[0:8]? It is hard to say. In the end, my opinion is that this sort of optimization isn't useful because you don't know how it is implemented. It is like people who spend hours changing i++ to ++i or replacing double-quotes in PHP with single-quotes. The benefit of the optimizations is so negligible that it doesn't really matter. 209.149.113.5 (talk) 20:03, 21 December 2017 (UTC)[reply]