Computing desk
< March 14	<< Feb \| March \| Apr >>	March 16 >

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.

March 15

[jQuery] select -> change()

I have a complex HTML form that is consists of a number of text input fields. Many of them must be evaluated after the user has completed input. Such as (1/2) --> (0.5) (I have written a simple math evaluation function), or (0) lb (18) oz --> (1) lb (2) oz. Sometimes you need to change two or more input fields's values based on input of one.

I used jQuery evens to handle this situation. I tried $('input').change(alert('Hi!!!');) . It doesn't work. When I click reload, my browser says hi. Then it does nothing when I actually change the values. What should I do? -- Toytoy (talk) 10:13, 15 March 2011 (UTC)[reply]

iPod not appearing in iTunes

I'm running whatever the newest version of OSX on mac is and using an ipod nano from the generation before the current one. Everything was working fine, up until about a week ago. Now when I connect it to a USB port it still charges, still appears in "finder" and I can still access my other files saved on it. but it does not appear in itunes so I cannot update my music on it. I have tried unplugging, restarting the computer and trying again etc. I have all the newest software updates. what can I try next? Postrock1 (talk) 12:10, 15 March 2011 (UTC)[reply]

Do you have the newest iTunes? Try clicking Software Update in the apple menu. You might also read here: http://support.apple.com/kb/TS1410 --Thekmc (talk) 21:01, 15 March 2011 (UTC)[reply]

Sorry. I didn't notice you said you had all the updates. However, you might also want to see this article: http://support.apple.com/kb/TS1461. Look in the Mac OS X 10.5.x section, and whenever it says put in your mac os x 10.5 install disk, instead put in your 10.6 install disk, since that is the newest version of os x. Then just follow those instructions and see if it helps. Otherwise, I don't know what you can do. You may have to contact Apple. --Thekmc (Leave me a message) 19:08, 19 March 2011 (UTC)[reply]

Fortran and Real precision

I got gfortran off the internet and compiled the following .f90 file:

  PROGRAM ShowPI
     IMPLICIT NONE
     REAL(KIND=16) :: PI
     PI = 3.14159265358979323846264338
     WRITE(*,*)  'PI: ', PI
  END PROGRAM ShowPI

and the output of the program looks like this:

PI:    3.1415927410125732421875000000000000

Why did it start to differ at the seventh decimal place? Thanks.20.137.18.50 (talk) 18:17, 15 March 2011 (UTC)[reply]

I haven't executed the program, but at first glance it seems that the constant 3.14159… is being stored as a single-precision variable. Try switching the assignment statement to

     PI = 3.14159265358979323846264338_8

and see if that fixes it. Titoxd^{(?!? - cool stuff)} 19:26, 15 March 2011 (UTC)[reply]

Thanks, appending _16 to the end of the number actually worked in making all the digits I specified right. I didn't know about appending the underscore and the number of bytes precision, as I'm just starting to play around with Fortran. 20.137.18.50 (talk) 19:44, 15 March 2011 (UTC)[reply]

Programming language implementations (usually) store numbers in one of two formats that can be easily manipulated in hardware: integers and floating-point numbers. There's a fixed number of bits dedicated to representing numbers, but there are an infinite number of numbers, so with integers you get overflow when the numbers get too large. Floating point number storage is a bit more subtle (see IEEE 754-2008); they have a limited number of digits to express the exponent, and they have a limited number of digits to express the mantissa. The _16 thing tells the compiler to use more digits. In particular, now you have enough digits in the mantissa to cover as much of pi as you are printing.

The reason you don't see zeros in the spots after precision has "run out" is that the mantissa is in binary, not base 10. If you take a decimal number, convert it to binary, round off digits at the end, and then convert that back to decimal, you'll discover that the end of the binary digit expansion was, (in a very informal sense) in the middle of one of the decimal digits, so it doesn't cut it off cleanly. Paul (Stansifer) 00:50, 16 March 2011 (UTC)[reply]