Computing desk
< January 12	<< Dec \| January \| Feb >>	January 14 >

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.

January 13

Tesla privacy

I was just reading this, which gives me the impression that every charge for every Tesla is tracked from the company's central server, at least where the identity of the car is concerned. It strikes me that this completes an apparent design, since according to some things I read the vehicle apparently collects detailed logs of everything the driver does for about the past 50 hours. [1][2][3]. There is some inconsistency in those: the article about the New York Times gives a strong impression that it was tracking the car's position, while the programmers say that there is no evidence of it storing actual position data... while also saying the file contains encrypted material only Tesla can read. Anyway, I was wondering if you can recommend more data to put this together reliably this goes there, saying the company even gets profiles of how the driver acts on specific roads, but it seems a little hard to follow certain details). My overall impression from the preceding is that by controlling the only power generally available and making electronic connections whenever it is powered, the company knows precisely where and how the "owner" of the car is driving soon enough, but I'd prefer some clearer sourcing before I go on about it in the article. Wnt (talk) 17:34, 13 January 2017 (UTC)[reply]

For your first link, if Tesla gives out free charging to its customers, I see no way to ensure that only Tesla-issued cars are plugged in it without going online. You obviously need some sort of identification to avoid a smart guy to come up with an adapter and suck free electrons. An offline challenge-response authentification is all sorts of trouble (can give details if needed), and a huuuge security liability especially if you are going to bill people with it.

For the rest, well... Computer driving being a game of machine learning, Tesla has a legitimate interest in keeping as much driving data as possible. It will actually improve the auto-driving software. It is certainly more legitimate than, say, Google maximizing the profit they get from auctioning your computing power, bandwidth, and human attention to whoever pays the most to execute their arbitrary code in your browser - err, I mean, delivering ads that interest you. If I was in charge, I would make the thing opt-out but with ten steps before reaching the "disable" button, so that I lose data on the 0.1% of civil right activists that use it but also the criticism that comes with it. Tigraan^{Click here to contact me} 18:39, 13 January 2017 (UTC)[reply]

Actually I was looking for capabilities rather than explanations, since the latter seem pretty simple to come up with post hoc and don't really mean a lot. Wnt (talk) 22:01, 13 January 2017 (UTC)[reply]

Nitpick: on the net, you aren't really taking Tesla's electrons when you charge your car at Tesla's station... you're taking their energy, because for every electron that flows into your battery as elecrtric current, a replacement electron flows back out. In other words, even as you "charge" a battery, you are completing an electric circuit. The battery doesn't end a charge cycle with more electrons than it starts with. Rather, it finishes with the same number of net electrons, chemically emplaced into a higher energy state. The clever user who seeks to steal electrons will find himself carrying an electrostatic charge; the effects of the coulomb force would be macroscopic for any thief who tried to take even a few milligrams of electrons. They'd probably be unable to depart the charging station, even using a powerful high-torque electric motor like the one found on a Tesla. WP:OR - Shall I provide a link to these calculations on Wolfram Alpha? Nimur (talk) 22:37, 13 January 2017 (UTC)[reply]

Nimur, I read the Coulomb force article, but I'm unclear — it looks like the force would either be immensely repulsive (i.e. the thief would get injured so badly he'd be unable to leave) or immensely attractive, but I didn't understand the article well enough to know which of these would be true. Or perhaps something else would happen (e.g. a massive static electricity shock, rendering the thief badly injured); which, if any, of these is what you meant? Nyttend (talk) 01:19, 14 January 2017 (UTC)[reply]

Ultimately, you don't "steal electrons" when you charge a battery - so, by default "none of the above" - but for whichever non-physical hypothetical scenario you could imagine, a different problem would arise! If you tried to store the electrons somewhere, they'd repel each other (with a lot of force); if you tried to take them somewhere, that would require separation of charge... and so on. Each of these physical phenomena would cause trouble for any macroscopic movement of charge. Nimur (talk) 18:37, 15 January 2017 (UTC)[reply]

Nitpicks are always welcome on the RefDesk, but colloquially using the term 'electrons' to stand for electricity and/or electronic data has a long history on the internet. Matt Deres (talk) 14:11, 15 January 2017 (UTC)[reply]

Indeed; the colloquial plain-English usage of the word "charge", as it pertains to the normal procedure for an electric battery, is a troublesome word; because "electric charge" has a very specific meaning in physics. In reality, we often colloquially use and abuse the terminology for electric current, voltage, electrical energy, electrical power, electrical charge... and then, we additionally complicate things with dynamic processes including electromagnetic waves... Point taken, though! In colloquial speech, all of these terms are used much more freely! Nimur (talk) 18:37, 15 January 2017 (UTC)[reply]

Because of the nitpick, I re-read my sentence "suck(ing) free electrons", and now I'm picturing somethink like this but with an adult on a Tesla charging station.

You can look at the analysis of logs which were publicly released in this dispute [4] [5] [6]. It doesn't include any position information but that may have just been because it wasn't relevant to the dispute. Also this was a while ago. Note that although this car was being test-driven, I've never seen any suggestion the logging wouldn't have happened normally although I believe unsurprisingly the journalist was required to allow Tesla to retrieve the logs. Note that I don't actually see anything in those logs that probably isn't required in most fancy cars and probably non fancy ones, with an Electronic control unit obtainable via OBD2 other than the charging stuff. Nil Einne (talk) 04:33, 14 January 2017 (UTC)[reply]

@Nil Einne: I appreciate that all cars were, rather stealthily as I recall, set up with electronic "black boxes" that later started turning up in court proceedings for reckless driving and such. However, those boxes in many cases --- I think --- have remained inaccessible to routine daily monitoring by higher authorities. The question here is whether Tesla does, as that one source suggests, have access to the entire log each time the vehicle is charged, or under some other circumstance, and what that log contains. Wnt (talk) 16:22, 14 January 2017 (UTC)[reply]

Ambiguity and programming languages

Could a programming language be ambiguous under any aspect? Can we be 100% that a language is not ambiguous, not matter what you express in this language? — Preceding unsigned comment added by 31.4.136.155 (talk) 23:03, 13 January 2017 (UTC)[reply]

In many programming languages it is possible to set up a race condition, the outcome of which is not predictable. Jc3s5h (talk) 23:08, 13 January 2017 (UTC)[reply]

Also, many languages explicitly allow for constructs that have undefined behaviour (in C, e.g. comparing two arbitrary pointers, or the order of execution between sequence points, or, IIRC, dereferencing the NULL pointer). Such ambiguities are often trouble for portability, because different implementations may implement them differently. --Stephan Schulz (talk) 23:22, 13 January 2017 (UTC)[reply]

Undefined behavior is a huge issue, and I think it counts as "ambiguous".

I like to think of three kinds of programs: the good, the bad, and the ugly. Good programs are correct, and work. Bad programs have an error which the compiler catches. But ugly programs contain undefined behavior, which the compiler might catch or not, and which if the compiler doesn't catch might do what you want or not, or might do different things depending on the phase of the moon.

In a programming language, you can think of undefined behavior as a "gulf" between the good constructs and the bad constructs. You can imagine that the wider that gulf of undefinedness is, the more risky (or at least tricky) programming in that language is going to be.

I like C a lot -- it's still my favorite programming language -- but I have to admit, its gulf of undefinedness is uncomfortably wide.

(I believe I've heard that a design goal of Java was to eliminate undefined behavior entirely, i.e. to shrink the gulf of undefinedness down to nothing.) —Steve Summit (talk) 13:34, 14 January 2017 (UTC)[reply]

To expand on your note about C and Java... C purposely does not define many things that are best left to the compiler. For example, one CPU might have some built-in system for doing the mod function with a built-in quantum math unit. If so, let the compiler define how to do mod, which may or may not handle negative mod in a way that is expected. Java runs on a JVM. So, there are rare benefits to the hardware. You have to compile the JVM to the hardware and then alter anything that behaves in a way that isn't defined. It reduces undefined behavior at a cost of speed and efficiency. Therefore, it is not a situation where one way is best. It depends on your needs. 209.149.113.5 (talk) 20:51, 17 January 2017 (UTC)[reply]

Don't get me wrong -- I did say C was still my favorite language! (I didn't say, but if you ask, I have no love for Java.)

But the number of instances of undefined behavior in C (not to mention the way they're exploited by modern compilers) can be a real problem.

You mentioned performing mod on negative numbers, but that's not the best example, since that was only ever implementation-defined (not undefined) and in any case it's been well-defined for many years; compilers don't get to choose any more. —Steve Summit (talk) 11:56, 18 January 2017 (UTC)[reply]

You are looking for Deterministic_context-free_language. To answer the original questions, yes, a programming language can be ambiguous under some aspect, no, we can never be 100% sure it is not. 89.120.104.138 (talk) 14:24, 16 January 2017 (UTC)[reply]

There are languages which users perceive as ambiguous because meaning is defined by context and the context is not always obvious. One language I have used lets you abbreviate all functions and variable names. Suppose I run the function "b(h,w)". It will run the most recently used function beginning with "b" with the most recently used variables beginning with "h" and "w". The "most recently used" context means that it isn't actually ambiguous. It is clearly defined. But, I can break it by inserting a line that runs a function beginning with "b", which causes the "ambiguous" function call to be in a new context. 209.149.113.5 (talk) 13:27, 17 January 2017 (UTC)[reply]