Wikipedia:Reference desk/Archives/Mathematics/2016 February 23

From Wikipedia, the free encyclopedia
Mathematics desk
< February 22 << Jan | February | Mar >> February 24 >
Welcome to the Wikipedia Mathematics Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


February 23[edit]

tensor product 0 means coprime annihilators[edit]

Let M, N be two finitely generated modules over a commutative ring, such that is a proper ideal. I try to see why this implies that . How is it done? Is there some bilinear function defined on that we can show not to be the zero function?--46.117.106.166 (talk) 18:59, 23 February 2016 (UTC)[reply]

Quick and dirty approach: quotient down by a maximal ideal that contains . Then quotients down to a tensor product of nonzero vector spaces over the same field. Sławomir
Biały
20:02, 23 February 2016 (UTC)[reply]
I'm not sure I understood your suggestion. Is it the following argument? Supposing to the contrary that , we tensor it twice with R/I, where I is a maximal ideal containing both annihilators. then we get which is a tensor product of two vector spaces over R/I, hence WLOG , so M=IM, hence by Nakayama's lemma there is some such that for all m, we have . Hence , contradiction.--46.117.106.166 (talk) 20:52, 23 February 2016 (UTC)[reply]

Open the longest[edit]

What organization anywhere in the world has been continuously open the longest? The Facebook page for this mental hospital says it has been open continuously since June 15, 1841 — Preceding unsigned comment added by Diddlesticks355454646dddddddd (talkcontribs) 19:02, 23 February 2016 (UTC)[reply]

See List of oldest companies. General Ization Talk 19:22, 23 February 2016 (UTC)[reply]
That doesn't answer the question at all. I ask for ones that have been "continuously open" the longest. As you can see from the link I provided, the mental hospital claims to have been open 24 hours a day 7 days a week since 1841. Is that the longest or does something else beat it? I am NOT asking for oldest companies, I am asking for ones that have been continuously open the longest, ie 24/7 the longest without ever shutting down for Christmas or Thanksgiving or Sundays etc Diddlesticks355454646dddddddd (talk) 19:42, 23 February 2016 (UTC)[reply]
Define "open". Define "continuously". Define "organisation". You might think in terms of, say, the Royal Navy, which has been plodging around in boats for quite a while. Or the Catholic Church. Or Judaism. In the absence of definitions, it may be difficult to assist you. --Tagishsimon (talk) 20:33, 23 February 2016 (UTC)[reply]

Probability of duplicated filenames[edit]

I asked this question because I store all the pictures I have taken with my Olympus E-620 DSLR camera in a directory structure in the form AAA/BBBB where AAA is a running number from 100 onwards and BBBB is a number from 0 to 9800, in steps of 200. Olympus digital cameras name their photographs in the form mddnnnn where m is the month, from 1 to c (hexadecimal is used to avoid spending an extra digit), dd is the day of the month and nnnn is a running number from 1 to 9999. I store all the pictures in the order of the running numbers, making a new AAA directory every time the counter resets from 1. If a month or year changes in between, I don't care about it.

What is the probability of a single filename occurring in multiple directories, in terms of the number of AAA directories and the number of years I've been using the camera? JIP | Talk 20:24, 23 February 2016 (UTC)[reply]

How many pictures do you take in a year? 175.45.116.60 (talk) 22:51, 23 February 2016 (UTC)[reply]
It varies between fifty and one hundred thousand. JIP | Talk 04:51, 24 February 2016 (UTC)[reply]
I think that you are definitely likely to have a problem with different files having the same name. I had that problem with my first digital camera which gave file names DSC_xxxx, where xxxx is a four-digit number. I got duplications after it rolled over 9999. I wrote a program to rename the files by changing the "DSC" to encoding the year and month. With my current camera, I can set what it assigns for the first three characters of the file name. Right now it is set to "A16", the 16 is for the year, and "A" is the first set of 10,000. If I reach 10,000 in "A" while still in 2016, I'll change the setting to "B16", etc. Bubba73 You talkin' to me? 05:07, 24 February 2016 (UTC)[reply]
I already know I have files with the same name. That's not a problem as they go to different directories. I want to know, based on this information, what is the average probability of more than one file in different directories having the same name. JIP | Talk 06:08, 24 February 2016 (UTC)[reply]
I can't answer your question, but surely if there is one match between two directories (eg DSC12345) there are likely to be several more sequential matches (DSC12346, DSC12347, DSC12348 etc) unless the names are more random. -- SGBailey (talk) 14:24, 24 February 2016 (UTC)[reply]
On average, you take roughly 200 pictures per day. That means that in principle you could go maybe 50 years without duplicating a label, but in practice it will happen much sooner -- it's a birthday problem type question, but more complicated than the usual one in that you are packing intervals of length 200 into a larger list of length 10000. That's for a single day; this is happening simultaneously for every day of the year, although of course the outcomes for nearby days are related (if, in year 2, you didn't have overlap with the previous year for pictures on Jan 1, you also probably won't have overlap on Jan 2). I think that, realistically, it would be easier and more reliable to produce an empirical answer by simulating 10000 copies of yourself on a computer than it would be to try to do anything analytic. (Also this will allow you to tinker with the model of how you take photos to find something realistic, even if it's not analytically nice.) --JBL (talk) 14:52, 24 February 2016 (UTC)[reply]