[Pharo-project] can someone explain me this method?
comments? decent variable names? no magic numbers? NOW you can find NONE of that in dayMonthYearDo! ================================================================== dayMonthYearDo: aBlock "Evaluation the block with three arguments: day month, year." | l n i j dd mm yyyy | l := jdn + 68569. n := 4 * l // 146097. l := l - (146097 * n + 3 // 4). i := 4000 * (l + 1) // 1461001. l := l - (1461 * i // 4) + 31. j := 80 * l // 2447. dd := l - (2447 * j // 80). l := j // 11. mm := j + 2 - (12 * l). yyyy := 100 * (n - 49) + i + l. ^ aBlock value: dd value: mm value: yyyy. ================================================================== so can anyone explain me the magic numbers here??
http://www.hermetic.ch/cal_stud/jdn.htm <-- "9. Conversion Algorithms" describes the algorithm, if not the magic numbers. frank On 13 July 2012 16:53, Camillo Bruni <camillobruni@gmail.com> wrote:
comments? decent variable names? no magic numbers? NOW you can find NONE of that in dayMonthYearDo!
================================================================== dayMonthYearDo: aBlock "Evaluation the block with three arguments: day month, year."
| l n i j dd mm yyyy | l := jdn + 68569. n := 4 * l // 146097. l := l - (146097 * n + 3 // 4). i := 4000 * (l + 1) // 1461001. l := l - (1461 * i // 4) + 31. j := 80 * l // 2447. dd := l - (2447 * j // 80). l := j // 11. mm := j + 2 - (12 * l). yyyy := 100 * (n - 49) + i + l.
^ aBlock value: dd value: mm value: yyyy.
==================================================================
so can anyone explain me the magic numbers here??
Yeah, but sometimes a clever algorithm comes from a book, so to speak. Giving the variables long names, or the constants names, would not make that much difference, it would still be pretty hard to understand. ZTimestamp class>>withJdn: jdn dayMonthYearDo: block "Return the value of executing block with the Gregorian Calender day, month and year as arguments, as computed from my Julian Day Number, jdn. See http://en.wikipedia.org/wiki/Julian_date#Gregorian_calendar_from_Julian_day_..." | j g dg c dc b db a da y m d | j := jdn + 32044. g := j // 146097. dg := j \\ 146097. c := ((dg // 36524) + 1) * 3 // 4. dc := dg - (c * 36524). b := dc // 1461. db := dc \\ 1461. a := ((db // 365) + 1) * 3 // 4. da := db - (a * 365). y := (g * 400) + (c * 100) + (b * 4) + a. m := ((((da * 5) + 308)) // 153) - 2. d := da - ((m + 4) * 153 // 5) + 122. ^ block value: d + 1 value: ((m + 2) \\ 12) + 1 value: (y - 4800 + ((m * 2) // 12)) On 13 Jul 2012, at 17:53, Camillo Bruni wrote:
comments? decent variable names? no magic numbers? NOW you can find NONE of that in dayMonthYearDo!
================================================================== dayMonthYearDo: aBlock "Evaluation the block with three arguments: day month, year."
| l n i j dd mm yyyy | l := jdn + 68569. n := 4 * l // 146097. l := l - (146097 * n + 3 // 4). i := 4000 * (l + 1) // 1461001. l := l - (1461 * i // 4) + 31. j := 80 * l // 2447. dd := l - (2447 * j // 80). l := j // 11. mm := j + 2 - (12 * l). yyyy := 100 * (n - 49) + i + l.
^ aBlock value: dd value: mm value: yyyy.
==================================================================
so can anyone explain me the magic numbers here??
The first numbers are quite easy to guess without reading any reference : - 400 years span 146097 days in gregorian calendar. - 100 years span 36524 days, except every 400 years. - 4 years span 1461 days, except every 100 years. - 1 year span 365 days, except every four years For months and days, the tricks are less trivial... Nicolas 2012/7/13 Sven Van Caekenberghe <sven@beta9.be>:
Yeah, but sometimes a clever algorithm comes from a book, so to speak.
Giving the variables long names, or the constants names, would not make that much difference, it would still be pretty hard to understand.
ZTimestamp class>>withJdn: jdn dayMonthYearDo: block "Return the value of executing block with the Gregorian Calender day, month and year as arguments, as computed from my Julian Day Number, jdn. See http://en.wikipedia.org/wiki/Julian_date#Gregorian_calendar_from_Julian_day_..."
| j g dg c dc b db a da y m d | j := jdn + 32044. g := j // 146097. dg := j \\ 146097. c := ((dg // 36524) + 1) * 3 // 4. dc := dg - (c * 36524). b := dc // 1461. db := dc \\ 1461. a := ((db // 365) + 1) * 3 // 4. da := db - (a * 365). y := (g * 400) + (c * 100) + (b * 4) + a. m := ((((da * 5) + 308)) // 153) - 2. d := da - ((m + 4) * 153 // 5) + 122. ^ block value: d + 1 value: ((m + 2) \\ 12) + 1 value: (y - 4800 + ((m * 2) // 12))
On 13 Jul 2012, at 17:53, Camillo Bruni wrote:
comments? decent variable names? no magic numbers? NOW you can find NONE of that in dayMonthYearDo!
================================================================== dayMonthYearDo: aBlock "Evaluation the block with three arguments: day month, year."
| l n i j dd mm yyyy | l := jdn + 68569. n := 4 * l // 146097. l := l - (146097 * n + 3 // 4). i := 4000 * (l + 1) // 1461001. l := l - (1461 * i // 4) + 31. j := 80 * l // 2447. dd := l - (2447 * j // 80). l := j // 11. mm := j + 2 - (12 * l). yyyy := 100 * (n - 49) + i + l.
^ aBlock value: dd value: mm value: yyyy.
==================================================================
so can anyone explain me the magic numbers here??
Cool thanks everyone for the references :D We will pu that into the sources On 2012-07-13, at 19:47, Nicolas Cellier wrote:
The first numbers are quite easy to guess without reading any reference :
if you have a major in astronomy, sure :P
- 400 years span 146097 days in gregorian calendar. - 100 years span 36524 days, except every 400 years. - 4 years span 1461 days, except every 100 years. - 1 year span 365 days, except every four years
well indeed, not that hard :P, but when you're in midst of a mind-boggling refactoring you don't waste time to understand these details :P
For months and days, the tricks are less trivial...
Nicolas
2012/7/13 Sven Van Caekenberghe <sven@beta9.be>:
Yeah, but sometimes a clever algorithm comes from a book, so to speak.
Giving the variables long names, or the constants names, would not make that much difference, it would still be pretty hard to understand.
ZTimestamp class>>withJdn: jdn dayMonthYearDo: block "Return the value of executing block with the Gregorian Calender day, month and year as arguments, as computed from my Julian Day Number, jdn. See http://en.wikipedia.org/wiki/Julian_date#Gregorian_calendar_from_Julian_day_..."
| j g dg c dc b db a da y m d | j := jdn + 32044. g := j // 146097. dg := j \\ 146097. c := ((dg // 36524) + 1) * 3 // 4. dc := dg - (c * 36524). b := dc // 1461. db := dc \\ 1461. a := ((db // 365) + 1) * 3 // 4. da := db - (a * 365). y := (g * 400) + (c * 100) + (b * 4) + a. m := ((((da * 5) + 308)) // 153) - 2. d := da - ((m + 4) * 153 // 5) + 122. ^ block value: d + 1 value: ((m + 2) \\ 12) + 1 value: (y - 4800 + ((m * 2) // 12))
On 13 Jul 2012, at 17:53, Camillo Bruni wrote:
comments? decent variable names? no magic numbers? NOW you can find NONE of that in dayMonthYearDo!
================================================================== dayMonthYearDo: aBlock "Evaluation the block with three arguments: day month, year."
| l n i j dd mm yyyy | l := jdn + 68569. n := 4 * l // 146097. l := l - (146097 * n + 3 // 4). i := 4000 * (l + 1) // 1461001. l := l - (1461 * i // 4) + 31. j := 80 * l // 2447. dd := l - (2447 * j // 80). l := j // 11. mm := j + 2 - (12 * l). yyyy := 100 * (n - 49) + i + l.
^ aBlock value: dd value: mm value: yyyy.
==================================================================
so can anyone explain me the magic numbers here??
On Fri, Jul 13, 2012 at 10:51 AM, Camillo Bruni <camillobruni@gmail.com>wrote:
Cool thanks everyone for the references :D
We will pu that into the sources
On 2012-07-13, at 19:47, Nicolas Cellier wrote:
The first numbers are quite easy to guess without reading any reference :
if you have a major in astronomy, sure :P
- 400 years span 146097 days in gregorian calendar. - 100 years span 36524 days, except every 400 years. - 4 years span 1461 days, except every 100 years. - 1 year span 365 days, except every four years
well indeed, not that hard :P, but when you're in midst of a mind-boggling refactoring you don't waste time to understand these details :P
:) Here's an analogous method in VisualWorks. They don't bother to document seconds per day (86400). TimeZone>>timestampToSeconds: aTimestamp " Convert a Timestamp in to seconds starting from the Smalltalk epoch in UTC. Since we do not know leap-seconds in UTC, Answer the number of seconds since January 1, 1901. Same as 'self asDate asSeconds + self asTime asSeconds' " | yearIndex absDays seconds | yearIndex := aTimestamp year - 1901. absDays := yearIndex * 365 "elapsed years" + (yearIndex // 4) "ordinary leap years" + ((yearIndex + 300) // 400) "leap centuries, first one is 2000, i.e. yearIndex = 99" - (yearIndex // 100) "non-leap centuries" + aTimestamp day - 1 + (aTimestamp firstDayOf: aTimestamp month). seconds := aTimestamp hour * 60 + aTimestamp minute * 60 + aTimestamp second. "do it this way to minimize large arithmetic" ^absDays * 86400 + seconds But I like "Same as 'self asDate asSeconds + self asTime asSeconds'" since Date>asSeconds "Answer the seconds between the time that 1901 began and the same time in the receiver's day." ^self asTimestamp asSeconds and Timestamp>asSeconds "Answer the number of seconds since January 1, 1901." "Same as 'self asDate asSeconds + self asTime asSeconds'" ^TimeZone default timestampToSeconds: self So the documentation still leaves something to be desired :) It is perhaps unfortunate that manifest constants in class variables cost more than literals because of the indirection through the association. I did an inlining scheme in VisualWorks many years ago that depended on automatic recompilation when read-only bindings were changed (since the scope of these bindings is limited its quick to find affected methods). It depended on the method including the binding in its literals even though the compiler inlined the value of the binding, and it depended on access to source (since the points where the variable is inlined are not marked in the bytecode). I still think there's benefit here; even a JIT needs to know what bindings are read-only and a write-barrier to be able to inline the values of globals. But it has a lot of impact for not very much performance (given that in performance-critical parts of the system people have already inlined by hand, as in the above). So I suppose it will remain a fun experiment.
For months and days, the tricks are less trivial...
Nicolas
2012/7/13 Sven Van Caekenberghe <sven@beta9.be>:
Yeah, but sometimes a clever algorithm comes from a book, so to speak.
Giving the variables long names, or the constants names, would not make
that much difference, it would still be pretty hard to understand.
ZTimestamp class>>withJdn: jdn dayMonthYearDo: block "Return the value of executing block with the Gregorian Calender
day, month and year as arguments,
as computed from my Julian Day Number, jdn. See
http://en.wikipedia.org/wiki/Julian_date#Gregorian_calendar_from_Julian_day_... "
| j g dg c dc b db a da y m d | j := jdn + 32044. g := j // 146097. dg := j \\ 146097. c := ((dg // 36524) + 1) * 3 // 4. dc := dg - (c * 36524). b := dc // 1461. db := dc \\ 1461. a := ((db // 365) + 1) * 3 // 4. da := db - (a * 365). y := (g * 400) + (c * 100) + (b * 4) + a. m := ((((da * 5) + 308)) // 153) - 2. d := da - ((m + 4) * 153 // 5) + 122. ^ block value: d + 1 value: ((m + 2) \\ 12) + 1 value: (y - 4800 + ((m * 2) // 12))
On 13 Jul 2012, at 17:53, Camillo Bruni wrote:
comments? decent variable names? no magic numbers? NOW you can find NONE of that in dayMonthYearDo!
================================================================== dayMonthYearDo: aBlock "Evaluation the block with three arguments: day month, year."
| l n i j dd mm yyyy | l := jdn + 68569. n := 4 * l // 146097. l := l - (146097 * n + 3 // 4). i := 4000 * (l + 1) // 1461001. l := l - (1461 * i // 4) + 31. j := 80 * l // 2447. dd := l - (2447 * j // 80). l := j // 11. mm := j + 2 - (12 * l). yyyy := 100 * (n - 49) + i + l.
^ aBlock value: dd value: mm value: yyyy.
==================================================================
so can anyone explain me the magic numbers here??
-- best, Eliot
participants (5)
-
Camillo Bruni -
Eliot Miranda -
Frank Shearar -
Nicolas Cellier -
Sven Van Caekenberghe