![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | ← | Archive 3 | Archive 4 | Archive 5 |
Per WP:MOSDATES, choice of CE/BCE or BC/AD should be driven by content. In this case it's an astronomy topic with a minor in computing, use of CE/BCE dominates in the relevant professional communities. Even Jesuit astronmers are now following this convention, in papers I've read. Guy ( Help!) 13:38, 30 August 2019 (UTC)
I don't have a strong general attachment to either AD/BC or CE/BCE, but since the Easter (Paschal) cycle played an important role in Scaliger's development of his Julian Period, there's a reasonable argument in favor of AD/BC notation in this article. -- SteveMcCluskey ( talk) 00:48, 1 September 2019 (UTC)
If a formula to compute the day of the week from the JDN is to be added, as suggested by Eric Kvaalen at the end of the above section, there should be a statement as to the range of validity of the formula.
According to our " Week" article, in the " Hellenistic and Roman era" section, the cycle of week days can be verified as far back as 6 February AD 60; this information is cite to
I do not posses either of these works. I wouldn't add information to an article unless I had read the source for the information myself. Jc3s5h ( talk) 13:49, 18 June 2020 (UTC)
The MOD(a,n) function, in any computer language, returns a remainder r that satisfies
for some integer q. In some languages, r may be negative in certain cases. So mod(JDN,7) may be negative for negative JDN, but it won't be less than −7. So if we then add 8, it will be positive. If we then do MOD again, we will always get an integer between 0 and 6, no matter what computer language we use. Adding 1 gives the number of the day of the week.
I don't understand what you mean by the "range of validity" of a formula for day of week. The day of the week goes from Sunday to Saturday every seven days, forever into the future and in all time past! There's no such thing as "verifying" that this was true in AD 60! Or do you mean that we have some record for that year saying that a certain day of the Julian calendar was a certain day of the week? Do you think that maybe people got confused at some point in time and lost track of which day of the week it was? It is well accepted that we can extrapolate back further than AD 60 in talking about days of the week. For example, there is a lot of discussion in the literature about the date of the crucifixion of Christ, and everybody accepts that we can say which day of the week any particular Julian date was.
Eric Kvaalen ( talk) 06:43, 21 June 2020 (UTC)
The source for the following formula and conditions is
Richards in chapter 23, "Mathematical Notes" states that when mod(A, B) is used, "we always assume that A and B are integers (A ≥ 0 & B ≥ 0)." (p. 292) Richards, in Chapter 22, "Calendrical Conversions", p. 291, mentions "Algorithms which use decimal numbers are best avoided when working with computers or calculators since they may not record with sufficient accuracy; for example, when the result of a calculation should be exactly 1, some computers might record it as 1.999...; if we ignore the decimal, we are wrongly left with 1 rather than 2. As a bonus, integer arithmetic is performed faster than decimal arithmetic in many computer systems." In chapter 24, "To Calculate the Day of the Week" on page 309, Richards gives this formula for the calculation of the day of the week from the Julian day number (where Sunday is assigned the number 1):
It is not mentioned on this page, but of course the result of the formula applies the at moment of noon and several hours following noon. What happens to the name of the weekday later in the Julian day depends on context. Jc3s5h ( talk) 13:28, 21 June 2020 (UTC)
The formulas given in the sections “Converting Gregorian calendar date to Julian Day Number” and “Converting Julian calendar date to Julian Day Number” appear to be wrong. For example, in the section “Converting Gregorian calendar date to Julian Day Number,” the value of JDN for Y = 1999, M = 3, and D = 23 is approximately 2,451,263.202. The correct Julian day number is 2,451,261. The formulas return non-integer values. The correct formulas must return integer values. — Jencie Nasino ( talk) 05:46, 25 September 2019 (UTC)
{{extract|1999-03-23|show=juliandate}}
→ 2451261{{extract|juliandate|2451261}}
→ 23 March 1999CALENDAR Date Time Day Julian Date Day-of-Year (UT1) (UT1) (UT1) d h m s d d 2019 Oct 10 12:00:00.0 Thu 2458767.000000 283.500000
@ Jencie Nasino, Johnuniq, Jc3s5h, and ShimmerFairy: We had a big argument about the algorithm for going from Julian Day Number to dates almost three years ago ( Talk:Julian day/Archive 4, sections 2, 3, and 4). I said that the way the algorithm is presented is very confusing (using a table of parameters) and that the algorithm works just fine for negative JDN so long as "div" is defined the right way. We couldn't come to an agreement so the article stayed the way it was, unfortunately.
According to Division (mathematics), the definition of "integer division" with a negative result is language-dependent! So it's not good enough just to say "divisions are integer divisions"!
By the way, here is an explanation of how the algorithm works:
We could add the fact that mod(JDN+1,7)+1 gives the day of the week (Sunday being 1).
Eric Kvaalen ( talk) 17:06, 17 June 2020 (UTC)
@ Jc3s5h: You didn't ping me.
I am not proposing putting the above explanation of the algorithm into the article. That was just for the benefit of the people who read this talk page.
Do you agree that mod(mod(JDN,7)+8,7)+1 gives the day of the week?
And what do you say about the fact that the definition of "integer division" is language-dependent?
Eric Kvaalen ( talk) 12:18, 18 June 2020 (UTC)
=MOD(B12+1,7)+1
gives the day of the week, if cell B12 contains the JDN and the JDN is positive, 0, or a small negative number. I haven't tested for large magnitude negative numbers.@ Jc3s5h: I will address the question of weekday below your new section header. As for the question of integer division, I didn't say that you said it's implementation dependent, I said that Division (mathematics) says that. So when we put, in the article, "(M − 14)/12" or "(M − 9)/7", the result is not well defined. Those two expressions are simply meant to distinguish January and February from the other months. They are supposed to give −1 for January and February and 0 for the other months, but in some computer languages they may give −2 and −1. It would be better, in my opinion, to simply define some variable, say C for "correction", as −1 if M is 1 or 2 and 0 otherwise, and then use this variable in the places where those expressions are used. And if, as I tried to convince you three years ago, we were to define integer division as floor(a/n), then the formulas could be used for dates which give negative JDN. But I know you won't accept that. Eric Kvaalen ( talk) 06:43, 21 June 2020 (UTC)
@ Jc3s5h: I don't understand. Do you mean you don't know whether what I propose is the same as what we have (when that is interpreted the way you want)? We don't need to find a book for every little obvious thing, such as using FLOOR(A / N) instead of A / N (with integer division defined the way you want). If vandalism occurs, you just revert! Eric Kvaalen ( talk) 13:37, 21 June 2020 (UTC)
The issue is that the algorithms currently in the article are only asserted in the source to work for Julian day numbers greater than or equal to 0; my own experiments have found that they do indeed fail for negative JDNs that are many years earlier than 4718 BC. Eric Kvaalen would like to introduce original modifications to make them work earlier in the past.
As far as copyright is concerned, from what I've seen, there is seldom any hesitation to copy a few equations or formulas from one work to another, under the doctrine of fair use. The fact that there are relatively few ways to express the algorithm without introducing errors or creating great inconvenience for readers is a factor. Also, the algorithm in Doggett was taken from Fliegel and Van Flandern (1968)"A Machine Algorithm for Processing Calendar Dates" Communications of the Association of Computing Machines 11, 657. (I don't know how closely it was coppied; I don't have that article.)
It's also likely that Doggett's chapter is not covered by copyright, since he was a staff astronomer at the US Naval Observatory at that time. Works made in the course of their duties by employees of the federal goverment are not eligible for copyright. The copyright page of the book states "reproduction or translation of any part of this work beyond that permitted by Section 107 or 108 of the 1976 United States Copyright Act without the permission of the copyright owner is unlawful." [Emphasis added]. It's quite unusual for copyright pages to mention section 108, which is the section that allows copying of publications of federal employees. Jc3s5h ( talk) 22:59, 21 June 2020 (UTC)
The table claims that day one of "Rata Die" is 1 January 1 AD, proleptic Gregorian calendar. I believe this is incorrect. Rather than Gregorian, I believe it's proleptic Julian. Alexgenaud ( talk) 16:55, 2 February 2021 (UTC)
We have chosen midnight at the onset of Monday, January 1, 1 (Gregorian) as our fixed date 1, which we abbreviate as R.D.
Algorithm under Converting Gregorian calendar date to Julian Day Number gives me JDN 0 to be Nov 24, 4713 BC. But text says it should be Nov 24, 4714 BC. Day and month ok, but year wrong.
Also, algorithm under Julian or Gregorian calendar from Julian day number gives me Gregorian date Nov 24, 4712 BC as JDN 0.
But for more recent dates it's ok.
It's just me?
- Nerun ( talk) 22:42, 13 February 2021 (UTC)
Is integer division well defined in mathematics, and in computer programming languages?
Many of the algorithms in the article use the integer division operation (but no use is made of the remainder, which might be thought of in math as one of the results of a division, the other result being the quotient). But Eric Kvaalen states in the thread #Wrong formulas ' All I'm saying is that we can rewrite the formulas to use FLOOR instead of so-called "integer division" which is not well defined and not commonly understood.' Jc3s5h ( talk) 15:10, 22 June 2020 (UTC)
My understanding of division, based on my training in elementary school, formal university classes in FORTRAN, use of FORTRAN as an electronics engineer at IBM, and working on the CPU hardware of IBM System/390, corresponds with the following material from a FORTRAN programming manual near the time that Fleigel and Van Flanderen wrote their letter to the editor to Communications of the Association for Computing Machines (which I will add to the article as further reading shortly). The source is IBM System/360 and System/370 FORTRAN IV Language, IBM publication number GC28-6515-10, May 1974, page 29.
I | J | I/J |
---|---|---|
9 | 2 | 4 |
−5 | 2 | −2 |
1 | -4 | 0 |
I think the results in the table agree with how mathematicians define the quotient in cases where the remainder is given separately; does anyone believe otherwise? Does anyone know a programming language that gives different results? Jc3s5h ( talk) 15:10, 22 June 2020 (UTC)
I found a case where an operator that might be used as integer division, but really is not, is "floor division". In the current Python language reference it is indicated that the floor division operator, "https://", first performs a floating point division with the two operands and then performs a floor function.
The current Python math.floor function, math.floor(x), returns "the largest integer less than or equal to x." This gives different results for the quotient than FORTRAN division of integers. Jc3s5h ( talk) 16:52, 22 June 2020 (UTC)
/
operator may be used on integer or real operands, and always yields a real result. This language also provides the DIV
and MOD
operators, both of which may only be used on integer operands and yield integer results. So 22 DIV 7
returns 3; and 22 MOD 7
returns 1. Regarding negative operands: this isn't a FLOOR case, it rounds towards zero. To quote
BS 6192, section 6.7.2.2: -- Redrose64 🌹 ( talk) 21:38, 22 June 2020 (UTC)A term of the form i div j shall be an error if j is zero, otherwise the value of i div j shall be such that
abs(i) - abs(j) < abs((i div j) * j) ≤ abs(i)
where the value shall be zero if abs(i) < abs(j), otherwise the sign of the value shall be positive if i and j have the same sign and negative if i and j have different signs.
A term of the form i mod j shall be an error if j is zero or negative, otherwise the value of i mod j shall be that value of (i-(k*j)) for integral k such that
0 ≤ i mod j < j.
I think that what David Epstein has said supports my contention that integer division is not well defined (Python defines it differently from C). But more to the point is that people don't know how it is defined! (Do any of you know which way to round, in FORTRAN say, if both the dividend and the divisor are negative??) That's why I don't like the way we present the formulas in our article. As one can see by looking over past comments on this talk page and its archives, it's a cause of confusion.
In our formulas, we have the expressions "(M − 14)/12" and "(M − 9)/7", where the rounding has to be done toward zero, because it's simply meant to distinguish January and February from the other months. They are supposed to give −1 for January and February and 0 for the other months, but in Python they would give −2 for January, −1 for February and several subsequent months, and with "(M − 9)/7", 0 for September through December!
In the other places where integer division is used in our formulas, the formulae work so long as the dividend is positive, but if the dividend is negative and you use the kind of integer division used in C or FORTRAN then our formulae don't work!
Eric Kvaalen ( talk) 10:20, 23 June 2020 (UTC)
I'd like to make David Eppstein's post more concrete by applying it to the examples from the IBM FORTRAN manual above:
I | J | I/J | q = floor(I/J) | remainder = I-qJ |
---|---|---|---|---|
9 | 2 | 4 | 4 | 1 |
−5 | 2 | −2 | −3 | 1 |
1 | -4 | 0 | −1 | −3 |
This leads to some surprising notation issues. If we write the results of the first row as a mixed number it would be 4+1⁄2. The implied positive sign before the 4 also applies to the fraction 1⁄2.
If we look at the second row, we would write it as −2+1⁄2. So, unlike what we are used to when J and K are both positive, the quotient (−3) when expressed as quotient and remainder is not equal to the integer part of the mixed-number representation. Also, the remainder (+1) is not equal to the denominator (−1) of the mixed-number representation. Jc3s5h ( talk) 13:57, 23 June 2020 (UTC)
in computer programming languages) than the first (
in mathematics). I'll only focus on the first part of the question. Basically, the question itself isn't very well-defined. But division on the integers is well-defined in some way that intuitively makes sense.In mathematics, asking if something is define-able isn't a very meaningful question (outside of topics in logic, set theory, etc. that we're clearly not talking about). Division is not well-defined as a group operation for the integers or even as a binary operation on the integers, but then again nor is division well-defined in that way for the real numbers (due to division by zero).However, division on the integers is well-defined in other ways. For instance, take the binary operation of division on the nonzero rationals that sends to . Then the intersection of the Cartesian square of the nonzero integers and the pre-image of the nonzero integers gives a well-defined function . This function sends pairs of nonzero integers (but only the ones such that is an integer) to the nonzero integer . You could also define integer division as a function as just sending the integers to the rational number . You could also define it using Euclidean division (basically David Eppstein's answer above, and it actually works for negative divisors as well). There are plenty of ways to have a well-defined integer division.This probably only answers the literal question
Is integer division well defined in mathematicsbut not the underlying content dispute. If this is about whether to use the floor function or not in the presentation of algorithms, then it's clarifying to use the floor function instead of straight division (even if your chosen programming language interprets
a/b
for integers to mean the floor function). —
MarkH21
talk
10:29, 21 July 2020 (UTC)If Wikipedians are allowed to use citation 68 in the article to supply the formula, why aren't they allowed to use that same citation where it explicitly says integer division rounds "toward zero"? Why does that require a citation 'f'? And why does rounding towards zero need explained in this article at all? Further, the paragraph preceding the math says all formulas below round toward zero, but then each formula's introduction *also says* integer division... and omits "towards zero". I corrected one before coming over to the talk page to mention these issues. I've never made a Wikipedia edit before. 65.31.58.24 ( talk) 19:57, 17 August 2021 (UTC) I should've been clearer when I asked why is "towards zero" explained in this article. I was implying that "integer division towards zero" should link to another article ( /info/en/?search=Division_(mathematics)#Of_integers), rather than being described in this one. 65.31.58.24 ( talk) 20:27, 17 August 2021 (UTC)
It's clear that whatever computer was used by Fliegel and Van Flandern, they used integer variables and Fortran. The computer did not round. It had registers with bits to store integers, including the dividend, divisor, quotient, and remainder. When the integer portion of the CPU was used, there simply wasn't any place to store a fraction. So there was no rounding, just computation of a quotient and remainder. The footnote in the article indicates that rounding toward zero is functionally equivalent to the way Fortran calculates a quotient and remainder, but the computer doesn't actually do any rounding.
The IBM 360, 370, 390, and z-series are famous for being backward compatible. The z/Architecture Principles of Operation 10th ed. (IBM; 2012) indicates beginning on page 7-207 that division with either signed or unsigned numbers is possible, using different assembly language instructions. Regarding how the remainder is calculated, IBM states
The sign of the quotient is determined by the rules of algebra, and the remainder has the same sign as the dividend, except that a zero quotient or a zero remainder is always positive.
I think it's reasonable to believe that whatever computers were used by Doggett, Fliegel, and Van Flandern were functionally equivalent to the IBM/360 family and the IBM Fortran compilers.
I think it would be best to keep in mind that in the hardware and software intended by Doggett, Fliegel, and Van Flandern, there is no rounding. The article only mentions rounding for the benefit of readers stuck with hand calculators, or software like Excel, that do not provide easy access to integer arithmetic. Jc3s5h ( talk) 16:12, 21 October 2021 (UTC)
It’s Julian Day 2460000. It seems slightly notable. Only happens every 27 years. Any way to get this featured?
—- Nike ( talk) 08:57, 24 February 2023 (UTC) (JD 2459999.87282)
The page includes a little demo that shows the UTC time the user loaded the page along with a "refresh" link. It produces an erroneous result that's off by an hour and 20 minutes from the actual UTC time the page was loaded.
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | ← | Archive 3 | Archive 4 | Archive 5 |
Per WP:MOSDATES, choice of CE/BCE or BC/AD should be driven by content. In this case it's an astronomy topic with a minor in computing, use of CE/BCE dominates in the relevant professional communities. Even Jesuit astronmers are now following this convention, in papers I've read. Guy ( Help!) 13:38, 30 August 2019 (UTC)
I don't have a strong general attachment to either AD/BC or CE/BCE, but since the Easter (Paschal) cycle played an important role in Scaliger's development of his Julian Period, there's a reasonable argument in favor of AD/BC notation in this article. -- SteveMcCluskey ( talk) 00:48, 1 September 2019 (UTC)
If a formula to compute the day of the week from the JDN is to be added, as suggested by Eric Kvaalen at the end of the above section, there should be a statement as to the range of validity of the formula.
According to our " Week" article, in the " Hellenistic and Roman era" section, the cycle of week days can be verified as far back as 6 February AD 60; this information is cite to
I do not posses either of these works. I wouldn't add information to an article unless I had read the source for the information myself. Jc3s5h ( talk) 13:49, 18 June 2020 (UTC)
The MOD(a,n) function, in any computer language, returns a remainder r that satisfies
for some integer q. In some languages, r may be negative in certain cases. So mod(JDN,7) may be negative for negative JDN, but it won't be less than −7. So if we then add 8, it will be positive. If we then do MOD again, we will always get an integer between 0 and 6, no matter what computer language we use. Adding 1 gives the number of the day of the week.
I don't understand what you mean by the "range of validity" of a formula for day of week. The day of the week goes from Sunday to Saturday every seven days, forever into the future and in all time past! There's no such thing as "verifying" that this was true in AD 60! Or do you mean that we have some record for that year saying that a certain day of the Julian calendar was a certain day of the week? Do you think that maybe people got confused at some point in time and lost track of which day of the week it was? It is well accepted that we can extrapolate back further than AD 60 in talking about days of the week. For example, there is a lot of discussion in the literature about the date of the crucifixion of Christ, and everybody accepts that we can say which day of the week any particular Julian date was.
Eric Kvaalen ( talk) 06:43, 21 June 2020 (UTC)
The source for the following formula and conditions is
Richards in chapter 23, "Mathematical Notes" states that when mod(A, B) is used, "we always assume that A and B are integers (A ≥ 0 & B ≥ 0)." (p. 292) Richards, in Chapter 22, "Calendrical Conversions", p. 291, mentions "Algorithms which use decimal numbers are best avoided when working with computers or calculators since they may not record with sufficient accuracy; for example, when the result of a calculation should be exactly 1, some computers might record it as 1.999...; if we ignore the decimal, we are wrongly left with 1 rather than 2. As a bonus, integer arithmetic is performed faster than decimal arithmetic in many computer systems." In chapter 24, "To Calculate the Day of the Week" on page 309, Richards gives this formula for the calculation of the day of the week from the Julian day number (where Sunday is assigned the number 1):
It is not mentioned on this page, but of course the result of the formula applies the at moment of noon and several hours following noon. What happens to the name of the weekday later in the Julian day depends on context. Jc3s5h ( talk) 13:28, 21 June 2020 (UTC)
The formulas given in the sections “Converting Gregorian calendar date to Julian Day Number” and “Converting Julian calendar date to Julian Day Number” appear to be wrong. For example, in the section “Converting Gregorian calendar date to Julian Day Number,” the value of JDN for Y = 1999, M = 3, and D = 23 is approximately 2,451,263.202. The correct Julian day number is 2,451,261. The formulas return non-integer values. The correct formulas must return integer values. — Jencie Nasino ( talk) 05:46, 25 September 2019 (UTC)
{{extract|1999-03-23|show=juliandate}}
→ 2451261{{extract|juliandate|2451261}}
→ 23 March 1999CALENDAR Date Time Day Julian Date Day-of-Year (UT1) (UT1) (UT1) d h m s d d 2019 Oct 10 12:00:00.0 Thu 2458767.000000 283.500000
@ Jencie Nasino, Johnuniq, Jc3s5h, and ShimmerFairy: We had a big argument about the algorithm for going from Julian Day Number to dates almost three years ago ( Talk:Julian day/Archive 4, sections 2, 3, and 4). I said that the way the algorithm is presented is very confusing (using a table of parameters) and that the algorithm works just fine for negative JDN so long as "div" is defined the right way. We couldn't come to an agreement so the article stayed the way it was, unfortunately.
According to Division (mathematics), the definition of "integer division" with a negative result is language-dependent! So it's not good enough just to say "divisions are integer divisions"!
By the way, here is an explanation of how the algorithm works:
We could add the fact that mod(JDN+1,7)+1 gives the day of the week (Sunday being 1).
Eric Kvaalen ( talk) 17:06, 17 June 2020 (UTC)
@ Jc3s5h: You didn't ping me.
I am not proposing putting the above explanation of the algorithm into the article. That was just for the benefit of the people who read this talk page.
Do you agree that mod(mod(JDN,7)+8,7)+1 gives the day of the week?
And what do you say about the fact that the definition of "integer division" is language-dependent?
Eric Kvaalen ( talk) 12:18, 18 June 2020 (UTC)
=MOD(B12+1,7)+1
gives the day of the week, if cell B12 contains the JDN and the JDN is positive, 0, or a small negative number. I haven't tested for large magnitude negative numbers.@ Jc3s5h: I will address the question of weekday below your new section header. As for the question of integer division, I didn't say that you said it's implementation dependent, I said that Division (mathematics) says that. So when we put, in the article, "(M − 14)/12" or "(M − 9)/7", the result is not well defined. Those two expressions are simply meant to distinguish January and February from the other months. They are supposed to give −1 for January and February and 0 for the other months, but in some computer languages they may give −2 and −1. It would be better, in my opinion, to simply define some variable, say C for "correction", as −1 if M is 1 or 2 and 0 otherwise, and then use this variable in the places where those expressions are used. And if, as I tried to convince you three years ago, we were to define integer division as floor(a/n), then the formulas could be used for dates which give negative JDN. But I know you won't accept that. Eric Kvaalen ( talk) 06:43, 21 June 2020 (UTC)
@ Jc3s5h: I don't understand. Do you mean you don't know whether what I propose is the same as what we have (when that is interpreted the way you want)? We don't need to find a book for every little obvious thing, such as using FLOOR(A / N) instead of A / N (with integer division defined the way you want). If vandalism occurs, you just revert! Eric Kvaalen ( talk) 13:37, 21 June 2020 (UTC)
The issue is that the algorithms currently in the article are only asserted in the source to work for Julian day numbers greater than or equal to 0; my own experiments have found that they do indeed fail for negative JDNs that are many years earlier than 4718 BC. Eric Kvaalen would like to introduce original modifications to make them work earlier in the past.
As far as copyright is concerned, from what I've seen, there is seldom any hesitation to copy a few equations or formulas from one work to another, under the doctrine of fair use. The fact that there are relatively few ways to express the algorithm without introducing errors or creating great inconvenience for readers is a factor. Also, the algorithm in Doggett was taken from Fliegel and Van Flandern (1968)"A Machine Algorithm for Processing Calendar Dates" Communications of the Association of Computing Machines 11, 657. (I don't know how closely it was coppied; I don't have that article.)
It's also likely that Doggett's chapter is not covered by copyright, since he was a staff astronomer at the US Naval Observatory at that time. Works made in the course of their duties by employees of the federal goverment are not eligible for copyright. The copyright page of the book states "reproduction or translation of any part of this work beyond that permitted by Section 107 or 108 of the 1976 United States Copyright Act without the permission of the copyright owner is unlawful." [Emphasis added]. It's quite unusual for copyright pages to mention section 108, which is the section that allows copying of publications of federal employees. Jc3s5h ( talk) 22:59, 21 June 2020 (UTC)
The table claims that day one of "Rata Die" is 1 January 1 AD, proleptic Gregorian calendar. I believe this is incorrect. Rather than Gregorian, I believe it's proleptic Julian. Alexgenaud ( talk) 16:55, 2 February 2021 (UTC)
We have chosen midnight at the onset of Monday, January 1, 1 (Gregorian) as our fixed date 1, which we abbreviate as R.D.
Algorithm under Converting Gregorian calendar date to Julian Day Number gives me JDN 0 to be Nov 24, 4713 BC. But text says it should be Nov 24, 4714 BC. Day and month ok, but year wrong.
Also, algorithm under Julian or Gregorian calendar from Julian day number gives me Gregorian date Nov 24, 4712 BC as JDN 0.
But for more recent dates it's ok.
It's just me?
- Nerun ( talk) 22:42, 13 February 2021 (UTC)
Is integer division well defined in mathematics, and in computer programming languages?
Many of the algorithms in the article use the integer division operation (but no use is made of the remainder, which might be thought of in math as one of the results of a division, the other result being the quotient). But Eric Kvaalen states in the thread #Wrong formulas ' All I'm saying is that we can rewrite the formulas to use FLOOR instead of so-called "integer division" which is not well defined and not commonly understood.' Jc3s5h ( talk) 15:10, 22 June 2020 (UTC)
My understanding of division, based on my training in elementary school, formal university classes in FORTRAN, use of FORTRAN as an electronics engineer at IBM, and working on the CPU hardware of IBM System/390, corresponds with the following material from a FORTRAN programming manual near the time that Fleigel and Van Flanderen wrote their letter to the editor to Communications of the Association for Computing Machines (which I will add to the article as further reading shortly). The source is IBM System/360 and System/370 FORTRAN IV Language, IBM publication number GC28-6515-10, May 1974, page 29.
I | J | I/J |
---|---|---|
9 | 2 | 4 |
−5 | 2 | −2 |
1 | -4 | 0 |
I think the results in the table agree with how mathematicians define the quotient in cases where the remainder is given separately; does anyone believe otherwise? Does anyone know a programming language that gives different results? Jc3s5h ( talk) 15:10, 22 June 2020 (UTC)
I found a case where an operator that might be used as integer division, but really is not, is "floor division". In the current Python language reference it is indicated that the floor division operator, "https://", first performs a floating point division with the two operands and then performs a floor function.
The current Python math.floor function, math.floor(x), returns "the largest integer less than or equal to x." This gives different results for the quotient than FORTRAN division of integers. Jc3s5h ( talk) 16:52, 22 June 2020 (UTC)
/
operator may be used on integer or real operands, and always yields a real result. This language also provides the DIV
and MOD
operators, both of which may only be used on integer operands and yield integer results. So 22 DIV 7
returns 3; and 22 MOD 7
returns 1. Regarding negative operands: this isn't a FLOOR case, it rounds towards zero. To quote
BS 6192, section 6.7.2.2: -- Redrose64 🌹 ( talk) 21:38, 22 June 2020 (UTC)A term of the form i div j shall be an error if j is zero, otherwise the value of i div j shall be such that
abs(i) - abs(j) < abs((i div j) * j) ≤ abs(i)
where the value shall be zero if abs(i) < abs(j), otherwise the sign of the value shall be positive if i and j have the same sign and negative if i and j have different signs.
A term of the form i mod j shall be an error if j is zero or negative, otherwise the value of i mod j shall be that value of (i-(k*j)) for integral k such that
0 ≤ i mod j < j.
I think that what David Epstein has said supports my contention that integer division is not well defined (Python defines it differently from C). But more to the point is that people don't know how it is defined! (Do any of you know which way to round, in FORTRAN say, if both the dividend and the divisor are negative??) That's why I don't like the way we present the formulas in our article. As one can see by looking over past comments on this talk page and its archives, it's a cause of confusion.
In our formulas, we have the expressions "(M − 14)/12" and "(M − 9)/7", where the rounding has to be done toward zero, because it's simply meant to distinguish January and February from the other months. They are supposed to give −1 for January and February and 0 for the other months, but in Python they would give −2 for January, −1 for February and several subsequent months, and with "(M − 9)/7", 0 for September through December!
In the other places where integer division is used in our formulas, the formulae work so long as the dividend is positive, but if the dividend is negative and you use the kind of integer division used in C or FORTRAN then our formulae don't work!
Eric Kvaalen ( talk) 10:20, 23 June 2020 (UTC)
I'd like to make David Eppstein's post more concrete by applying it to the examples from the IBM FORTRAN manual above:
I | J | I/J | q = floor(I/J) | remainder = I-qJ |
---|---|---|---|---|
9 | 2 | 4 | 4 | 1 |
−5 | 2 | −2 | −3 | 1 |
1 | -4 | 0 | −1 | −3 |
This leads to some surprising notation issues. If we write the results of the first row as a mixed number it would be 4+1⁄2. The implied positive sign before the 4 also applies to the fraction 1⁄2.
If we look at the second row, we would write it as −2+1⁄2. So, unlike what we are used to when J and K are both positive, the quotient (−3) when expressed as quotient and remainder is not equal to the integer part of the mixed-number representation. Also, the remainder (+1) is not equal to the denominator (−1) of the mixed-number representation. Jc3s5h ( talk) 13:57, 23 June 2020 (UTC)
in computer programming languages) than the first (
in mathematics). I'll only focus on the first part of the question. Basically, the question itself isn't very well-defined. But division on the integers is well-defined in some way that intuitively makes sense.In mathematics, asking if something is define-able isn't a very meaningful question (outside of topics in logic, set theory, etc. that we're clearly not talking about). Division is not well-defined as a group operation for the integers or even as a binary operation on the integers, but then again nor is division well-defined in that way for the real numbers (due to division by zero).However, division on the integers is well-defined in other ways. For instance, take the binary operation of division on the nonzero rationals that sends to . Then the intersection of the Cartesian square of the nonzero integers and the pre-image of the nonzero integers gives a well-defined function . This function sends pairs of nonzero integers (but only the ones such that is an integer) to the nonzero integer . You could also define integer division as a function as just sending the integers to the rational number . You could also define it using Euclidean division (basically David Eppstein's answer above, and it actually works for negative divisors as well). There are plenty of ways to have a well-defined integer division.This probably only answers the literal question
Is integer division well defined in mathematicsbut not the underlying content dispute. If this is about whether to use the floor function or not in the presentation of algorithms, then it's clarifying to use the floor function instead of straight division (even if your chosen programming language interprets
a/b
for integers to mean the floor function). —
MarkH21
talk
10:29, 21 July 2020 (UTC)If Wikipedians are allowed to use citation 68 in the article to supply the formula, why aren't they allowed to use that same citation where it explicitly says integer division rounds "toward zero"? Why does that require a citation 'f'? And why does rounding towards zero need explained in this article at all? Further, the paragraph preceding the math says all formulas below round toward zero, but then each formula's introduction *also says* integer division... and omits "towards zero". I corrected one before coming over to the talk page to mention these issues. I've never made a Wikipedia edit before. 65.31.58.24 ( talk) 19:57, 17 August 2021 (UTC) I should've been clearer when I asked why is "towards zero" explained in this article. I was implying that "integer division towards zero" should link to another article ( /info/en/?search=Division_(mathematics)#Of_integers), rather than being described in this one. 65.31.58.24 ( talk) 20:27, 17 August 2021 (UTC)
It's clear that whatever computer was used by Fliegel and Van Flandern, they used integer variables and Fortran. The computer did not round. It had registers with bits to store integers, including the dividend, divisor, quotient, and remainder. When the integer portion of the CPU was used, there simply wasn't any place to store a fraction. So there was no rounding, just computation of a quotient and remainder. The footnote in the article indicates that rounding toward zero is functionally equivalent to the way Fortran calculates a quotient and remainder, but the computer doesn't actually do any rounding.
The IBM 360, 370, 390, and z-series are famous for being backward compatible. The z/Architecture Principles of Operation 10th ed. (IBM; 2012) indicates beginning on page 7-207 that division with either signed or unsigned numbers is possible, using different assembly language instructions. Regarding how the remainder is calculated, IBM states
The sign of the quotient is determined by the rules of algebra, and the remainder has the same sign as the dividend, except that a zero quotient or a zero remainder is always positive.
I think it's reasonable to believe that whatever computers were used by Doggett, Fliegel, and Van Flandern were functionally equivalent to the IBM/360 family and the IBM Fortran compilers.
I think it would be best to keep in mind that in the hardware and software intended by Doggett, Fliegel, and Van Flandern, there is no rounding. The article only mentions rounding for the benefit of readers stuck with hand calculators, or software like Excel, that do not provide easy access to integer arithmetic. Jc3s5h ( talk) 16:12, 21 October 2021 (UTC)
It’s Julian Day 2460000. It seems slightly notable. Only happens every 27 years. Any way to get this featured?
—- Nike ( talk) 08:57, 24 February 2023 (UTC) (JD 2459999.87282)
The page includes a little demo that shows the UTC time the user loaded the page along with a "refresh" link. It produces an erroneous result that's off by an hour and 20 minutes from the actual UTC time the page was loaded.