Wikipedia:Reference desk/Archives/Computing/2012 October 27

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.

October 27

java yield method

My doubt is on yield method in multi threading.

Yield method is used to put a currently executing thread in pause and so other threads can run.

but it is not happening.i am expressing my doubts using below programme.please read and tell me how to understand yield method.

Source Code Example

---

class thread3

{

public static void main(String args[])

{

Thread count1=new Thread(new CountDownEven());

Thread count2=new Thread(new CountDownOdd());

count1.start();

count2.start();
Thread t=Thread.currentThread();
for(int i=11;i<=20;i=i+2)
{
System.out.println(t.getName()+"----"+i);
Thread.yield();
}
}
}
class CountDownEven implements Runnable
{
public void run()
{
Thread t=Thread.currentThread();
for(int i=0;i<10;i=i+2)
{
System.out.println(t.getName()+"----"+i);
Thread.yield();
}
}
}
class CountDownOdd implements Runnable
{
public void run()
{
Thread t=Thread.currentThread();
for(int i=1;i<10;i=i+2)

System.out.println(t.getName()+"----"+i);
Thread.yield();
}
}
}

out put:

main----11
Thread-1----1
Thread-0----0
Thread-1----3
main----13
Thread-1----5
Thread-0----2
Thread-1----7
main----15
Thread-1----9
Thread-0----4
main----17
Thread-0----6
main----19
Thread-0----8

---

my doubts: 1)see the first four lines of out put.before coming to main thread, thread1 is getting executed twice. see the out put between 5 to 8 lines. before coming to main thread, thread1 is getting executed twice see the out put between 9 to 11 lines. thread one is getting executed only once before coming to main thread. 2)why thread1 executed twice before,and once now? 3) how can i understand yield method? --Phanihup (talk) 09:26, 31 October 2012 (UTC)

First of all, I've taken the liberty of formatting your source-code so it is easier to read. Secondly, yield() is behaving exactly as expected: it is allowing the thread scheduler to decide which thread should run next. The thread scheduler can pick any thread that is available to run - including the same thread! If you want to use some method to guarantee that a different thread will run, you need to investigate the many ways to manage synchronization of threads in Java. For example, you could implement a barrier, as is performed in the official example of a guarded block. A good overview is provided in the official Java Tutorial on Concurrency . If you want to encourage the scheduler to select the other thread - without actually guaranteeing that behavior, you could use Thread.sleep() instead of yield(). By sleeping for a few seconds, it's probable that the other thread would be selected to run next; but unless you carefully and explicitly use some synchronization, you can't guarantee any order that threads will run. (For example, if the other thread is also sleeping, then neither thread will run, and the system will idle; and when both threads wake up, you're back to the same condition: the scheduler will select any one of the available threads. Part of the Java programming language contract is that the scheduler does not guarantee any specific algorithm for selecting the next thread to execute: that allows the JVM to tune for best performance, or allocate multiple threads to multiple execution units, and so forth. Nimur (talk) 04:22, 27 October 2012 (UTC)

For the experienced Java enthusiasts: I've just noticed that in Java SE 7, the official documentation has changed for yield(): Oracle's Thread.yield() javadoc explicitly states that Yield is just a "hint," and "the scheduler is free to ignore this hint." This has always been the contract, but the documentation was never so clear about it in previous generations! And, Oracle proceeds to state: ..."It is rarely appropriate to use this method. It may be useful for debugging or testing purposes...." Nimur (talk) 04:28, 27 October 2012 (UTC)

What is a binary file?

What's the point of calling a file binary? Are there files that are not binary? Is that a misnomer? Comploose (talk) 15:56, 27 October 2012 (UTC)

One explanation is that a binary file is not a text file. Jc3s5h (talk) 16:00, 27 October 2012 (UTC)

All files are composed of sequences of bytes, and are in that sense binary. However, it is common practice to refer to files that cannot conveniently be read or manipulated in a plain text editor, i.e. the text files that Jc3s5h linked to, as binary files (yes, we have an article). --NorwegianBlue ^talk 18:41, 27 October 2012 (UTC)

It's also common to store binary files in a 'bin' folder (in unix anyway). This is compiled, linked code ready to run on the operating system. Sandman30s (talk) 13:27, 28 October 2012 (UTC)

There are various ways of encoding text (ASCII, EBCDIC, ...) and various ways of encoding newline (LF, CR, CRLF, ...). Transfer protocols like FTP have a text mode to deal with the resulting interoperability problems. Also, some operating systems (notably VMS) treat line endings in a text file as a special out-of-band property like end of file, so text files really aren't binary. WinFS was another attempt at a filesystem that doesn't just store binary blobs. -- BenRG (talk) 19:17, 28 October 2012 (UTC)

Ethernet over phone cable

I currently have a slim Ethernet cable going from my ADSL router (next to my master phone socket) to a small unmanaged gigabit switch at the other side of my living room (next to an extension phone socket) into which I connect my TV, PS3, etc. I'd like to do away with this for aesthetic reasons, but without ripping my home to bits to lay new cable or buying new kit like HomePlug adaptors.

My house is just over two years old, and I had heard that it was quite common nowadays for actual Cat-5(/5e/6) cabling to be used for extension phone sockets, so I have taken a look at the cabling used: It is not Cat-5 (it only has 3 pairs like a normal phone cable, instead of 4 like Cat-5), however it is closer in thickness to network cabling than to other telephone extension cabling I've seen before.

I know that if it isn't Cat-5, it isn't within spec for Fast Ethernet, but what're the chances it'll work anyway given the fact it looks like decent thickish cable and is somewhere between 8-15m (I don't know what route it takes)? I'm after an idea of whether its worth the effort as I would need to re-terminate the cable (or at least the 2 pairs I'll be using) as it is currently connected to British telephone sockets

Thanks in advance, davidprior ^t/_c 19:13, 27 October 2012 (UTC)

What you would have there is Category 1 cable with no guarantee of function at Ethernet speeds, even 10 megabits per second half duplex. But it could well function on the short length you have and given that it is not getting cross talk with other cables. Graeme Bartlett (talk) 21:39, 27 October 2012 (UTC)

From the article you linked, it looks like British setups often place a DSL filter in the master socket. I'm guessing from your question that this is the setup you have. In the US, I've always had inline filters that are plugged in for each phone, and the DSL modem works on any jack. Is there any way you could do something similar? If you just switched back to a traditional socket for the master, I would expect the DSL modem to work at a downstream jack. You would have to install a filter at each phone, but I expect they will be cheap. I don't know enough about British phone and DSL systems to know if you could re-use the filter installed at your master jack. 209.131.76.183 (talk) 17:55, 29 October 2012 (UTC)

Although this may work in the short term, I think I'm likely to need connectivity in another room (directly through the wall from where the router is at present) soon. So would like to keep router where it is. Also, I've read elsewhere that placing DSL router anywhere except master socket decreases speed - though this may of course be urban legend.

As Graeme has suggersted there's a non-zero chance of ethernet working over this cable, I'm going to give it a go and see how I get on. Cheers, davidprior ^t/_c 13:20, 31 October 2012 (UTC)

Are there any Digital SIlver Currencies?

I gotta do a work on digital currencies and i choose ones based on silver, does any one knoif there are any digital silver currencies? — Preceding unsigned comment added by 189.222.145.250 (talk) 22:52, 27 October 2012 (UTC)

I recommend reading Electronic money and changing the topic to Bitcoins. They (talk) 01:16, 28 October 2012 (UTC)

You could create your own digital, silver-backed currency, say by buying and storing silver bullion coins on behalf of those who purchase your currency. Here are some recent silver coins: Silver_coins#Bullion_coins. StuRat (talk) 01:28, 28 October 2012 (UTC)

Though, if the plan is to trade in silver as a commodity, it's unlikely you can sustain the volumes necessary to be price-competitive with, say, CME silver on the New York Mercantile Exchange. Note the important distinction between creating a currency, and trading in a highly liquid commodity. Only one of these activities is usually considered legal in the United States. If you're writing a report on digital currency, you might do well to read about currency in general: this subject is actually a very complicated topic in economics. "What is a currency?" "Who may decide when a currency is valid, and how much is it worth?" These questions apply to all forms of money, whether we're discussing currency fiat by government decree, or anarchosocialist cyberpunk bitcoins trafficked by people who don't bother to think too deeply about the subject. Adding the extra technical complexity of implementing a currency in a digital format puts you into some fairly advanced economic theory. Nimur (talk) 19:22, 28 October 2012 (UTC)

According to our article Silver as an investment, "Digital gold currency providers and internet bullion exchanges, such as BullionVault or GoldMoney, offer silver as an alternative to gold." So you might want to investigate those two as well as the other examples given in the digital gold currency article. -Elmer Clark (talk) 23:34, 29 October 2012 (UTC)

Python unexpected details

a = [1,2,3]
b = a
b[0] = 8

It's kind of unexpected to me that a is now [8,2,3]. Does that sound logical? Are there many more of these pitfalls in Python? Does it have a name? Comploose (talk) 23:51, 27 October 2012 (UTC)

Shallow copy -- Finlay McWalterჷTalk 23:54, 27 October 2012 (UTC)

That's just wrong. That represents a profound misconception of how things work in Python. There's no copy going on here, shallow, deep or otherwise. There's only ever one list, regardless of how many variables refer to it. Python variables aren't variables in the same sense of C/C++ variables (i.e. defined boxes into which values get stored). Rather, they're more of a Reference (computer science) (i.e. labels which point to a given value). Michael Hudson's and Alex Martelli's explanation of the subject ("How to think like a Pythonista" [1]) should be near-required reading for anyone working with Python. -- 205.175.124.30 (talk) 19:09, 29 October 2012 (UTC)

A) The solution to the first problem is to use this assignment statement:

b = a[:]

And I agree that this is non-intuitive. After all, with the a = 5 assignment, this doesn't change the value of 5 when you change the value of a. So, they are using the equals sign inconsistently. If I had designed Python, I'd use a syntax like "a <=> b" to show it's not a straight assignment.

B) As for other pitfalls, I consider how the loops work to be particularly non-intuitive:

for I in range(5): 
   print I                # Prints 0,1,2,3,4

for I in range(12,10,-1): 
   print I                # Prints 12,11

C) Then there are immutable object types, which can't be changed with a simple assignment statement, but require use of a method instead. (The part I don't get is why they can modify it with a method, but can't get the interpreter to do the same thing with an assignment statement. Is this done intentionally as a reminder that it's inefficient to modify it ?)

Here's one painful way to manually change a tuple:

Tup = (1,2,3)
print Tup        # Prints (1, 2, 3)
Tup2 = ()         
Tup2 += (Tup[0],) 
Tup2 += (9,)       
Tup2 += (Tup[2],)  
Tup = Tup2          
print Tup        # Prints (1, 9, 3)

Tup[1] = 9       # Error: not allowed to change a tuple member.

D) And one I just found out about myself is that variables defined outside a function are global by default (so exist inside any functions as well).

E) If you're used to compiled languages versus an interpreted language, having to define a function higher in the source code than you call it might seem odd. StuRat (talk) 00:26, 28 October 2012 (UTC)

Actually, the cleaner (clearer) solution to A) is to use b=list(a). A list is an object. The assignment just creates a new reference to the same list, unless you actually tell it to create a new list (via the list() constructor). For B), the problem is not with loops at all. The loop always consistently iterates over all the elements in the iterable object you give it. You might not like the way range() produces this list, but that is quite a different aspect from the loop itself. And for C), you fall into a similar trap to A), namely not distinguishing between an object, and a variable that points to it. You are not changing the tuple. You create an new, fresh, different tuple that you then assign to the old variable. The original tuple is (unless collected by the garbage collector) still around, and still the same (1,2,3). One reason why there are immutable objects is that they can be used as keys in hashes/dicts. D) is the same in C and C++, so it's not surprising. And E) is somewhat wrong. You must have defined a function before you can use it, but that again is not that different from C or Pascal - in both languages, you need to at least declare functions you want to call - in Pascal with a "forward" declaration, in C with a prototype declaration. --Stephan Schulz (talk) 01:15, 28 October 2012 (UTC)

Not sure where you're going with C. After the "Tup = Tup2" assignment, Tup has indeed changed as I want it. I suppose you could be pedantic about it and say that now it's a different "Tup", but, for all practical purposes it's the same "Tup". StuRat (talk) 01:36, 28 October 2012 (UTC)

Ben's explanation below applies. Yes, Tup has changed, but not the actual tuple. Tup is just a reference. The tuple is immutable. Consider (with ; for newlines to save space) a=(1, 2); b=a; a2=a[:1]; a2+=(3,); a=a2. The right hand side of the first statement creates a tuple with value (1,2). The assignment makes a a reference to that tuple. The second assignment (b=a) make b a second reference to the same tuple. If you think low-level, imagine the tuple to sit at some address in memory, and a and b both storing this same address.

The next assignment, a2=a[:1] then creates a new tuple, namely (1,). And a2+=(3,) creates two new tuples, (3,) on the right hand side, and (1, 3) in the "+" part of "+=". It then makes a2 a reference to that last new tuple. At this time, a and b both reference the original tuple, and a2 references the new tuple. There are no remaining references to the two intermediary tuples, so the garbage collector will eventually pick them up and destroy them. The last statement, a=a2 does not change or create any new tuples, it just makes a a reference to the existing tuple (1, 3). You can verify that the original tuple did not change by printing b, which still references (1, 2).

Being pedantic is essentially what computer science (and programming) is all about. Even if you are not, the computer is, and will byte your ankle (or more valuable parts) if you don't live up to its standards. ;-). --Stephan Schulz (talk) 07:34, 28 October 2012 (UTC)

Can you think of any case where it makes a difference whether the original Tup has the same address as the new Tup ? If not, then this is "a distinction without a difference". After all, that's why we use high-level computer languages versus, say, assembler, so we don't have to worry about the low-level memory management. StuRat (talk) 16:34, 28 October 2012 (UTC)

Sure, the very example I provided. In my example, you have both tuples remaining, one pointed to by a and a2, and one pointed to by b. If you had modified the original one, you would have only one of the tuples. From a different angle, knowing this stuff is important if you are at all concerned about efficiency. Passing references is a lot more efficient than copying large data structures, both in time and memory. But you need to be aware of the exact semantics, otherwise your code will be buggy. IIRC (but that may be an urban legend), Eurisko once discovered that append and nconc performed the same function, but nconc was faster. So it went ahead and "optimised" its own code, not understanding that while both do the same from a functional perspective (concatenating two lists), they have very different side effects. In particular, nconc simply reused both lists, extending the first with the second, while append made a copy of the first, and thus left both lists unchanged. --Stephan Schulz (talk) 16:51, 28 October 2012 (UTC)

When you write a = b, you are making a refer to the same object that b refers to. In other words, you are assigning a reference, not copying an object. This is always true in Python (and Java and Javascript and Scheme and many other languages). It's called aliasing. It can be very confusing and bug-prone with mutable objects like lists, but it's not much of a problem with immutable objects. Examples of immutable objects are integers, strings, and tuples. If you write a = (1, 2, 3); b = a, there's nothing you can do to a that will affect b. b will always point to the immutable value (1, 2, 3) until you make it point to something else. The same is true if you write a = 123; b = a or a = "123"; b = a. It's pretty common for languages to behave this way. C++ is notably different: in C++, variables don't refer to objects, they are objects, and when you write b = a; you are copying the object a on top of b. If a and b are std::vectors, for example, then subsequently assigning b[0] = 8; won't change a[0]. -- BenRG (talk) 06:41, 28 October 2012 (UTC)

This is off topic, but there's a near universal convention of putting spaces after commas in Python code. [1, 2, 3], not [1,2,3]. -- BenRG (talk) 07:01, 28 October 2012 (UTC)

a = (3)

a is a int here.

a = (3,3)

a is a tuple

If you want a tuple with one element:

a = (3,)

OsmanRF34 (talk) 01:23, 28 October 2012 (UTC)

Use the copy module.

from copy import copy, deepcopy

l = list(range(10))
print("copy(l) is l", copy(l) is l, sep=": ")
print("copy(l) == l", copy(l) == l, sep=": ")

l = [1, [2, [3, [4]]]]
assert repr(l[1]) == '[2, [3, [4]]]'
print("copy(l)[1] is l[1]", copy(l)[1] is l[1], sep=": ")
print("deepcopy(l)[1] is l[1]", deepcopy(l)[1] is l[1], sep=": ")

→Σσς. (Sigma) 19:24, 28 October 2012 (UTC)