Wikipedia:Reference desk/Archives/Computing/2013 July 12

= July 12 =

Bugged by design Microsoft vs HIPAA
Now that M$ baked in insecurity has been leaked...

http://www.guardian.co.uk/world/2013/jul/11/microsoft-nsa-collaboration-user-data

Isn't it a violation of the Health Insurance Portability and Accountability Act to use any M$ spyware in any doctor's office, hospital or insurance company? Hcobb (talk) 00:49, 12 July 2013 (UTC)


 * The reference desk isn't able to decide what is legal and what is illegal - that would be providing legal advice.
 * My position is twofold: first, the media is sensationalizing a "breaking story" about something that is actually very commonplace, and has been commonplace for decades, in many forms, technological and otherwise. Various media providers may have a vested interest in all this mudslinging; newspaper articles like the Guardian article you linked are not doing a great job of providing a neutral point of view.
 * Secondly, just because something is morally objectionable (to some people) - like massive government surveillance and corporate collusion - it is not necessarily illegal. Law is so complicated that attorneys spend years studying it.  Even then, lawyers rarely agree with each others' interpretations.  It is very probable that the various parties involved took great care to ensure that they were totally complying with relevant laws.  For example, this press release Statement to the NSA/CSS workforce, states clearly: "Through four years of oversight, the committee has not identified a single case in which a government official engaged in willful effort to circumvent or violate the law." Nimur (talk) 01:32, 12 July 2013 (UTC)


 * The article doesn't seem to be describing MS illegally forcing records on the NSA, it sounds like the NSA legally obtaining records from MS with their cooperation (Apple, Google, etc. were mentioned too). I'm pretty positive if everybody suddenly quit using Google, MS, etc. because of NSA and CIA surveillance, that they would use their authority to monitor whatever service everyone switched to. The issue isn't MS, the issue is the NSA, CIA, and FBI (if you have an issue), you can always consult a lawyer and see about challenging them...but I doubt that would go anywhere.Phoenixia1177 (talk) 04:08, 12 July 2013 (UTC)


 * HIPPA has all sorts of carve outs for legally authorized disclosures, and even if it didn't, it'd be hard to argue that you couldn't, for instance, obtain certain information in a criminal defense. Armchair lawyering like this tends to go from conclusion to reason, and rarely holds up to an even cursory reading of the law. On that point, I've got zero inclination to do the latter. Shadowjams (talk) 06:36, 13 July 2013 (UTC)


 * Were you responding to me or the op?Phoenixia1177 (talk) 07:27, 13 July 2013 (UTC)

CPU clock discrepancy
When I ran CPU-Z with my Core i7 2600K at factory settings, which include FSB at 100.0 MHz, CPU-Z reported the front-bus speed as actually 99.77 MHz, and a CPU clock speed consistent with that slightly slower FSB. I've since changed my FSB setting in BIOS to 100.3 MHz, and CPU-Z reports 100.10 MHz. Does this mean the CPU clock is running slower than the real-time clock? If so, which one is likely to measure a second more accurately? (I bought the CPU and motherboard at the same time.) Neon  Merlin  13:10, 12 July 2013 (UTC)
 * Late reply but...
 * Because an early (as in "running too fast") real-time clock would be wrong by 8.64 seconds per day if it were only 0.01% faster than a perfect cock, it is safe to assume that your bus is actually a bit on the slow side.
 * However, I'd ask you if your PC is actually doing a solid hour of I/O per day? If it is, the slow bus would result in a 7.9 second penalty compared to the "perfect motherboard" - not really worth correcting for speed reasons.
 * IIRC, the bus tolerances are 1.5% - i.e. there could be seven times the deviation your bus clock exhibits before you'd run a risk of into any signal corruption.
 * But if you want to get it right for rightness's sake, "100.3" (that is, 100.07 MHz) is certainly a closer fit than 99.77 MHz. Just don't expect any significant speed or reliability increase from it. - ¡Ouch! (hurt me / more pain) 07:14, 16 July 2013 (UTC)


 * *clock. Damn, Google's gonna give us a lot of traffic for this one...- ¡Ouch! (hurt me / more pain) 07:25, 16 July 2013 (UTC)

Error debug
Hey there! I was working with nested switch case in C++ language. The code i developed gives 0 error and 0 warning. But it does not execute any of the switch. It just exit. Can any one please tell me where the mistake is. I have got stuck. Any help will be highly appreciated. Thanks

Mike robert (talk) 15:29, 12 July 2013 (UTC)


 * You're doing what amounts to:


 * so in that last line you're comparing the int option with the char '1' (which, because it's ascii, is 49, not 1). You probably just want case 1: not case '1'
 * -- Finlay McWalterჷTalk 16:58, 12 July 2013 (UTC)


 * Thankyou so much. I didnt notice that. Now it's working. :)Mike robert (talk) 17:08, 12 July 2013 (UTC)

Is there a frexp function for JavaScript
The frexp function found in the standard c library exists as a function in JavaScript? I've looked everywhere but I've found nothing. Where can I find it? 181.50.178.92 (talk) 23:42, 12 July 2013 (UTC)


 * Unless you are using an exotic JavaScript interpreter, there is no frexp function built in. You can compose the same mathematical functionality using Math.log (and related functions), part of the standard Math object; or by writing your own function - it might be a good exercise in practical applications of recursion!
 * If you want to live dangerously, you can attempt to implement a constant-time algorithm (instead of an O(log(n)) time algorithm by directly inspecting the binary representation of the floating point numeral - chances are very good that it's stored as a IEEE 754 numeral (on any sane JavaScript implementation). But if you walk down this dangerous road, you will soon realize that JavaScript doesn't make this style of programming very easy - for one thing, type punning is not defined, because JavaScript is type safe and dynamically typed.  Nimur (talk) 01:25, 13 July 2013 (UTC)


 * This should get the internal representation of a float (which on my nodejs build is a single precision IEEE 754 float) as an int:


 * That's essentially what in C would be:


 * -- Finlay McWalterჷTalk 02:29, 13 July 2013 (UTC)


 * A C implementation of frexp which uses the internal representation (it uses doubles) is here. That entails extracting the exp and fraction part of the IEEE number (the C code does it in macros), which (I haven't tested it) should be:


 * then I guess you normalise per that code.
 * -- Finlay McWalterჷTalk 02:35, 13 July 2013 (UTC)


 * Since we're doing things the hard way, and I've already implemented this code, I may as well share it... in Python, the math object in the standard library implements frexp, but I wrote a function myself just to be sure I could.


 * The real meat of this algorithm is only a few lines of code, and did not require recursion. You could trivially convert this to JavaScript.  In principle, it should be safer - and slower - than Finlay's version; but that depends on your exact needs and use-case.  You might also want to check the behavior on weird floating-point inputs like NaN and negative zero.
 * Also, I'm impressed that Finlay found a way to type-pun in JavaScript. His code works!  But that sort of hackery should probably be avoided if you're deploying your script via the web - you never know how it might break on weird clients!  Supposing somebody's running your JavaScript in Netscape on a really old SPARC or an IBM 390, or a VAX?  In all seriousness, it's really unlikely JavaScript will ever run on a machine whose floating-point format is not IEEE 754, but it's still not a good idea to make assumptions about endianness or binary formats.   Nimur (talk) 06:03, 13 July 2013 (UTC)