November 20

How can I get this data, which is of basic nature, with respect to when these requests were sent to me ? Strange they've left this basic issue in a childish condition. I've raised this question there ('Help Community'), already, with no answers, as yet. BentzyCo (talk) 01:23, 20 November 2014 (UTC)[reply]

SO BASIC, BUT YET, SO COMPLICATED. Why designed so ? BentzyCo (talk) 06:43, 21 November 2014 (UTC)[reply]

The main point is that it is not in Facebook's interest to give you full access to that kind of data. It is in their interest to keep you on the site as long as possible, so that you see the most advertisements. As the saying goes, if the online service is free, you are not the customer, you are the product. You may have slightly more information available if you download your FB content, as described here [1]. SemanticMantis (talk) 20:28, 21 November 2014 (UTC)[reply]

I'm looking for the paper: A classification of CASE technology by A. Fuggetta. Here is a link to where the paper can be found:

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=247645&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel1%2F2%2F6338%2F00247645.pdf%3Farnumber%3D247645

I created a user ID on the IEEE site but without an institutional ID they make you pay for to download the paper. I need the paper to edit this article: Computer aided software engineering It's used as one of the primary references for many of the fundamental claims in the article. I think all the claims are true and probably backed up by the paper but want to be sure and also want to expand and edit the article to address the concerns in the tags. Also, on the Talk page of that article people have mentioned the idea of creating new articles that distinguish different subdomains of CASE (e.g. upper CASE vs. lower CASE) and I think this paper would be an excellent source if we do that. --MadScientistX11 (talk) 17:31, 20 November 2014 (UTC)[reply]

The place to ask for this is WP:REX. If you don't get any help there you can ask me on my talk page. SemanticMantis (talk) 20:08, 20 November 2014 (UTC)[reply]

In

   plt.plot(X, P, '-', color='grey')
   a = plt.plot(X, P, 'o', color=col[L])

from File:Poisson_pmf.svg. I see that both lines perform an action, but the second returns a value that gets used further. Where does the return value of the first go to? Does it just silently disappear without any side-effects? And would that be a problem, if you get really lots of these dismissed values? --Senteni (talk) 17:40, 20 November 2014 (UTC)[reply]

I don't know - but I know that this question goes on the computer reference desk. AndyTheGrump (talk) 17:46, 20 November 2014 (UTC)[reply]

The answer is pretty ... uh, "heavy...": the answer to these sorts of questions might not be very accessible to new programmers. How much do you know about compiler theory, and how much do you want to learn?

Both statements contain Python expressions and the latter statement is also an assignment statement. An assignment statement causes the interpreter to bind a value to a name. If the value is not bound, it is up to the Python interpreter environment to determine its scope and persistence behavior. In CPython (the most common implementation of Python), that value is stored in a reference-counted dictionary, and because it is unbound, it will be re-collected by the Python memory manager "very soon." In CPython, that garbage collection occurs when the value goes out of scope (which is, in a sense, a less memory-optimized sequence compared to the behavior of most compiled machine-code, in which an intermediate unbound value will cease to exist as soon as the CPU micro-architecture wants to re-use its hardware storage). Python's interpreter is, in a sense, a virtual machine; and the data-persistence of intermediate values is completely controlled by the software-implementation of the interpreter.

More to the point, "who cares" about how Python code interplays with the microarchitecture of compiled code? Well, you'll care if you ever try to embed the Python interpreter into your own code! Suppose you wanted to make a game, and you choose to implement the game in C code, but you want to permit the higher-level game logic to take the form of a Python script. Suddenly, the performance and data-persistence of the interpreted script can make a big difference! (As an actual example, Firaxis embedded Python into Civilization 4 and performance reviewers were not kind).

If you're into this stuff, the book you want is: Computer Organization and Design: The Hardware/Software Interface. Read that one over the course of a year; and then grab a copy of the CPython source and your favorite processor reference manual...

Nimur (talk) 18:20, 20 November 2014 (UTC)[reply]

Ignoring the return value of a function that returns one is an OK thing to do in every programming language I know (which is a LOT!). I don't know (in detail) how this works in Python - but in good old fashioned C, the "return" statement inside of a function placed the result into Register R0 (on most machine architectures) - and if you assigned that result to a variable in the calling code, it would copy R0 into that variable...if you didn't do the assignment, then R0 would eventually get overwritten. In most languages, the cost of ignoring a returned value is exactly zero. Now, admittedly, because Python is a garbage-collected language, if you create some kind of data structure - then the ONLY remaining reference to it is passed into a return statement - which is then ignored - then there will be no references left to that structure and it'll eventually be garbage-collected. There are administrative overheads to doing that - but the costs aren't really in ignoring the 'return' so much as creating something unnecessarily and then having it destroyed again. For example, if you saved the returned value in a variable, then destroyed the variable - the cost would be the same as ignoring it.

SteveBaker (talk) 19:27, 21 November 2014 (UTC)[reply]

The important point in this example is not whether the visible code does something with the return value or not. Rather, we know that the return value (or at least something very closely related to it) does not just go away because matplotlib is retaining a reference to it. (It must be, since it writes (a representation of) it to disk later!) This sort of magic background reference causes confusion precisely because it disrupts our understanding of what data is going where when we read the code. (For an extreme version of this idea, see Law of Demeter.) --Tardis (talk) 04:11, 23 November 2014 (UTC)[reply]

The standard CPython interpreter compiles to intermediate bytecode and uses a stack machine to do the processing. You can actually use the dis module to look at the bytecode [2]:

   def fun1(p):
       return 4

   def fun2():
       fun1(5)

   import dis
   dis.dis(fun1)
     2           0 LOAD_CONST               1 (4)
                 3 RETURN_VALUE        
   dis.dis(fun2)
     2           0 LOAD_GLOBAL              0 (fun1)
                 3 LOAD_CONST               1 (5)
                 6 CALL_FUNCTION            1
                 9 POP_TOP             
                10 LOAD_CONST               0 (None)
                13 RETURN_VALUE        

The LOAD_* opcodes place a value on the stack. RETURN_VALUE says to return the value on the top of the stack to the caller (which will see it as the top of the stack). Note that if we're not using the return value, the CALL_FUNCTION opcode is immediately followed by a POP_TOP opcode, which removes a value from the top of the stack and discards it. This is generally what happens with ignored return values, even for other languages/interpreters/compilers. The function itself normally is written such that it places the return value in an appropriate place (on the stack, in a register) so a single function can be used both with and without looking at the return value. If a function ignores a return value, it's normally up to the calling function to remove/delete/overwrite/ignore/discard the returned value. - By the way, the bytecode/stack machine implementation is for the regular CPython interpreter itself. Other Python implementations have different ways of handling it. The Python language itself just says that the reference/binding is discarded. (Keep in mind how Python thinks about objects and variables [3]: there can be multiple bindings to the same object, and the object will exist until all the references to it disappear.) -- 160.129.138.186 (talk) 20:37, 24 November 2014 (UTC)[reply]

I'm trying to understand the syntax and approach used with Vcard, when handling obsolete and emergency contact data. In the real world, obsolete contact data can be important - but it can also be very important to ensure it is clearly not to be used.

Example: Contact "Jane" has used the following 5 phone numbers -

• 123-1000, main home phone number (voice service)
• 456-1000, cellphone (voice, text services, preferred contact)
• 876-1000, a previous phone number, before she moved out of her old home. This is never to be called, even by accident, as it's obsolete, but deleting it would mean that all call history to and from that number would no longer be identified with Jane. Her 'ex' also still lives at that number so it's important to recognize it, if it ever rings and even if it's never used.
• 765-1000, another previous phone number, now reallocated by the telco to unconnected subscribers, but likewise if it's deleted then old and important records related to that contact number won't be linked to Jane.
• 333-1000, her medical emergency contact service for some condition Jane may have. Never to be called except in emergency as they charge $150 per call on each occasion used.

I'm trying to understand what provision VCard includes, or how VCard entries are structured, to reflect that very often, numbers need to be "on file" for a contact even though "obsolete" or "emergency", and how a number of this kind is represented in a typical handset's Vcard if it's needed but never normally to be actually dialed. In particular how one tags a number if it must be recognized but also mustn't be allowed to be dialed even accidentally. FT2 ^{(Talk | email)} 23:24, 20 November 2014 (UTC)[reply]