Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #382975 > unrolled thread

Calculate date of Easter or Good Friday

Back to article view | Back to comp.lang.c

Contents

  Calculate date of Easter or Good Friday porkchop@invalid.foo (Mike Sanders) - 2024-02-24 21:15 +0000
    Re: Calculate date of Easter or Good Friday Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 22:54 +0000
      Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-24 23:57 +0100
        Re: Calculate date of Easter or Good Friday Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 23:02 +0000
          Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-25 02:00 +0100
            Re: Calculate date of Easter or Good Friday Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-25 02:27 +0000
            Re: Calculate date of Easter or Good Friday Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-25 16:58 +0000
              Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-25 18:50 +0100
              Re: Calculate date of Easter or Good Friday Dan Purgert <dan@djph.net> - 2024-02-26 12:43 +0000
          Re: Calculate date of Easter or Good Friday Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-24 18:00 -0800
          Re: Calculate date of Easter or Good Friday Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2024-02-26 11:24 -0700
            Re: Calculate date of Easter or Good Friday Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 23:20 +0000
              Re: Calculate date of Easter or Good Friday scott@slp53.sl.home (Scott Lurndal) - 2024-02-26 23:31 +0000
                Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-27 12:50 +0100
              Re: Calculate date of Easter or Good Friday James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-27 05:02 -0500
                Re: Calculate date of Easter or Good Friday Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 22:48 +0000
                  Re: Calculate date of Easter or Good Friday James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-27 19:06 -0500
                    Re: Calculate date of Easter or Good Friday Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-28 00:11 +0000
                      Re: Calculate date of Easter or Good Friday James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-27 19:24 -0500
                        Re: Calculate date of Easter or Good Friday Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-28 20:47 +0000
                          Re: Calculate date of Easter or Good Friday Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 14:06 -0800
                            Re: Calculate date of Easter or Good Friday Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-28 22:20 +0000
                          Re: Calculate date of Easter or Good Friday James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-29 13:21 -0500
                Re: Calculate date of Easter or Good Friday Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 22:50 +0000
                  Re: Calculate date of Easter or Good Friday James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-27 19:41 -0500
                    Re: Calculate date of Easter or Good Friday David Brown <david.brown@hesbynett.no> - 2024-02-28 13:13 +0100
      Re: Calculate date of Easter or Good Friday porkchop@invalid.foo (Mike Sanders) - 2024-02-25 01:33 +0000
        Re: Calculate date of Easter or Good Friday Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-25 06:20 +0000
      Re: Calculate date of Easter or Good Friday G <g@nowhere.invalid> - 2024-02-26 09:47 +0000
      Re: Calculate date of Easter or Good Friday Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2024-02-26 11:20 -0700
        Re: Calculate date of Easter or Good Friday David Brown <david.brown@hesbynett.no> - 2024-02-27 10:08 +0100
          Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-27 13:00 +0100
        Re: Calculate date of Easter or Good Friday Michael S <already5chosen@yahoo.com> - 2024-02-27 13:12 +0200
          Re: Calculate date of Easter or Good Friday Michael S <already5chosen@yahoo.com> - 2024-02-27 14:36 +0200
    Re: Calculate date of Easter or Good Friday Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-25 17:39 +0000
      Re: Calculate date of Easter or Good Friday porkchop@invalid.foo (Mike Sanders) - 2024-02-26 03:12 +0000
        Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-26 05:20 +0100
          Re: Calculate date of Easter or Good Friday porkchop@invalid.foo (Mike Sanders) - 2024-02-26 14:26 +0000
            Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-26 16:31 +0100
            [OT] personal things (was Re: Calculate date of Easter or Good Friday) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-26 16:43 +0100
          Re: Calculate date of Easter or Good Friday porkchop@invalid.foo (Mike Sanders) - 2024-02-26 14:32 +0000
            [OT] Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-26 17:10 +0100
              Re: [OT] Re: Calculate date of Easter or Good Friday David Brown <david.brown@hesbynett.no> - 2024-02-26 18:26 +0100
      Re: Calculate date of Easter or Good Friday David Brown <david.brown@hesbynett.no> - 2024-02-26 11:45 +0100
        Re: Calculate date of Easter or Good Friday Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-26 13:04 +0000
          Re: Calculate date of Easter or Good Friday David Brown <david.brown@hesbynett.no> - 2024-02-26 15:46 +0100
            Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-26 16:17 +0100
              Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-26 17:15 +0100
        Re: Calculate date of Easter or Good Friday porkchop@invalid.foo (Mike Sanders) - 2024-02-26 14:38 +0000
          Re: Calculate date of Easter or Good Friday scott@slp53.sl.home (Scott Lurndal) - 2024-02-26 16:29 +0000
            Re: Calculate date of Easter or Good Friday porkchop@invalid.foo (Mike Sanders) - 2024-02-26 19:54 +0000
              Re: Calculate date of Easter or Good Friday scott@slp53.sl.home (Scott Lurndal) - 2024-02-26 20:06 +0000
                Re: Calculate date of Easter or Good Friday porkchop@invalid.foo (Mike Sanders) - 2024-02-26 21:18 +0000
                Re: Calculate date of Easter or Good Friday Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 00:59 +0000
          Re: Calculate date of Easter or Good Friday David Brown <david.brown@hesbynett.no> - 2024-02-26 18:07 +0100
        Re: Calculate date of Easter or Good Friday Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-26 16:09 +0100
        Re: Calculate date of Easter or Good Friday Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-26 17:26 +0000
          Re: Calculate date of Easter or Good Friday David Brown <david.brown@hesbynett.no> - 2024-02-27 10:17 +0100
          Re: Calculate date of Easter or Good Friday Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-03 11:05 -0800
        Re: Calculate date of Easter or Good Friday vallor <vallor@cultnix.org> - 2024-02-27 01:28 +0000
          Re: Calculate date of Easter or Good Friday Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 02:25 +0000
          Re: Calculate date of Easter or Good Friday Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-03 10:03 -0800
      Re: Calculate date of Easter or Good Friday Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-28 01:54 +0000
        Re: Calculate date of Easter or Good Friday Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-03 10:23 -0800

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#383034

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> And both dates, western and eastern, are anyway arbitrary. But if you
> decide to neglect the existing facts, either by wrongly assuming that
> there's only one "correct" Easter date, or by (arrogantly?) presuming
> that one is more correct than the other, then you are discriminating
> Christian folks that follow the one [arbitrary] definition (or the
> other).

And what's this? c'mon now, there's nothing arrogant or presumptuous here.
I'm not discriminating against anyone (I'm Catholic if it makes a difference).
Now then - don't start an argument where there is none...

-- 
:wq
Mike Sanders

[toc] | [prev] | [next] | [standalone]

#383046 — [OT] Re: Calculate date of Easter or Good Friday

On 26.02.2024 15:32, Mike Sanders wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> 
>> And both dates, western and eastern, are anyway arbitrary. But if you
>> decide to neglect the existing facts, either by wrongly assuming that
>> there's only one "correct" Easter date, or by (arrogantly?) presuming
>> that one is more correct than the other, then you are discriminating
>> Christian folks that follow the one [arbitrary] definition (or the
>> other).
> 
> And what's this? c'mon now, there's nothing arrogant or presumptuous here.
> I'm not discriminating against anyone (I'm Catholic if it makes a difference).
> Now then - don't start an argument where there is none...

While it may be personal arrogance (I can't tell; that's why I had put
it in parenthesis and with a question mark) I had more the often
observed "Western Arrogance" in mind. The country I'm living in is no
exception here! Sadly we can observe (more often than desirable) that
other cultures than the ones we are used to or living in are ignored,
their culture despised or neglected.

Speaking (in general contexts), say, only about male people will
discriminate the female ones. Considering only the sexually straight
people (is that word correct?) will discriminate the "LGBT..." folks.
Disregarding non-Christian religions will discriminate the majority
of religious people in the world. And if Christians exclude the
Orthodox Christians it's also a discrimination.

In case of the calendar issues even an unnecessary discrimination.

Whether you are a Catholic or not might explain a preference, or may
make some ignorance concerning other cultures understandable; I can't
tell, and it's not the relevant point when we're speaking about any
objective discrimination.

Janis

[toc] | [prev] | [next] | [standalone]

#383053 — Re: [OT] Re: Calculate date of Easter or Good Friday

On 26/02/2024 17:10, Janis Papanagnou wrote:
> On 26.02.2024 15:32, Mike Sanders wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>> And both dates, western and eastern, are anyway arbitrary. But if you
>>> decide to neglect the existing facts, either by wrongly assuming that
>>> there's only one "correct" Easter date, or by (arrogantly?) presuming
>>> that one is more correct than the other, then you are discriminating
>>> Christian folks that follow the one [arbitrary] definition (or the
>>> other).
>>
>> And what's this? c'mon now, there's nothing arrogant or presumptuous here.
>> I'm not discriminating against anyone (I'm Catholic if it makes a difference).
>> Now then - don't start an argument where there is none...
> 
> While it may be personal arrogance (I can't tell; that's why I had put
> it in parenthesis and with a question mark) I had more the often
> observed "Western Arrogance" in mind. The country I'm living in is no
> exception here! Sadly we can observe (more often than desirable) that
> other cultures than the ones we are used to or living in are ignored,
> their culture despised or neglected.
> 
> Speaking (in general contexts), say, only about male people will
> discriminate the female ones. Considering only the sexually straight
> people (is that word correct?) will discriminate the "LGBT..." folks.
> Disregarding non-Christian religions will discriminate the majority
> of religious people in the world. And if Christians exclude the
> Orthodox Christians it's also a discrimination.
> 
> In case of the calendar issues even an unnecessary discrimination.
> 
> Whether you are a Catholic or not might explain a preference, or may
> make some ignorance concerning other cultures understandable; I can't
> tell, and it's not the relevant point when we're speaking about any
> objective discrimination.
> 
> Janis
> 

"Arrogance" is one possibility.  But people may fail to include a given 
group for many different reasons, including (but not limited to) :

1. Ignorance.  Maybe the OP knows little or nothing about the Eastern 
Orthodox churches and when they have Easter.  My guess is that many who 
know that much, do not know about Oriental Orthodox churches, and these 
are different from Eastern Orthodox, and that some of these use the 
Easter date from Western Christian (Protestant and Catholic) tradition, 
and some use Eastern Orthodox Easter.  Then there are other Christian 
groups such as Jehovah's Witnesses that do not celebrate Easter at all, 
and there are not doubt many others that I have never heard of that do 
do things somewhat differently.

2. Simplification.  You can't cover /everything/.

3. Local bias.  If you are involved in a particular Church, then that 
determines the Easter of relevance to you.  Many countries will also 
have a strong bias towards one interpretation of Easter - perhaps for 
public holidays, school terms, or other purposes.

4. Lack of thought or consideration - people don't always think things 
through or consider all implications of things they write.  That does 
not make them arrogant or bigoted - it just makes them a normal, 
fallible human.

5. Lack of relevance.  If the code was just some sample C code for 
learning the language, details of what it is actually calculating don't 
matter in the context.

It might have been better for the OP to use "The Catholic Church Easter" 
rather than just "Easter", but I don't think it is fair to suggest a 
particular arrogance (much less to imply bigotry of some kind as you do 
here) on the part of the OP.

(I think it is a good thing to take a stand against bigotry when you see 
it, but it is not helpful to go searching for it where it is not present.)

[toc] | [prev] | [next] | [standalone]

#383030

On 25/02/2024 18:39, Lew Pitcher wrote:
> On Sat, 24 Feb 2024 21:15:56 +0000, Mike Sanders wrote:
> 
>> Calculate the date of Easter Sunday or Good Friday:
>>
>> https://busybox.neocities.org/notes/is-easter-or-goodfriday.txt
> 
> I don't have the expertise to discuss whether or not your code
> properly implements the calculations necessary to determine the
> date of Good Friday and/or Easter. However, I /do/ have some
> expertise on writing understandable code.
> 
> My suggestions, with respect to your program, would be to
> a) name your objects with relevant, understandable names
>     You code uses quite a lot of meaningless one-letter
>     objects, and it is difficult to keep track of the
>     purpose of the calculations using them.

I agree here.

I'd also avoid single-letter capital letter variables, and avoid 
single-letter variables that are easily misread (so don't use "L" or 
"O", big or small).  Single-letter variables are fine if their scope is 
small and their meaning is clear - such as "i" for a loop variable, and 
"x" and "y" for coordinates.

Good names here, together with some comments, would go a long way to 
making it possible to understand your algorithm here.  Links to web 
pages for reference are useful (and it's always polite to give your 
references), but remember that web pages don't last for ever - try to 
make your code stand alone as code, or at least have enough comments to 
cover the information.

> b) Don't place your calculations /in/ the object initializations.
>     Doing so obfuscates the intent of the logic, and makes
>     problem determination and resolution difficult.

I'd disagree with that one.  Initialise your variables when you have 
something to put in them, and that is often a calculated value.

> 
> Otherwise, it /appears/ to do the job. Good first attempt.

Some other suggestions:

Don't use "int" when you mean "bool".  That applies to parameters, 
return types, and variables.

Don't have one function that appears to do two different things.  It's 
much better to have "isEaster()" and "isGoodFriday()" functions. 
Clearly these are heavily related, so have a static helper function that 
does the common calculations.

Consider making and using several general functions, rather than having 
a single impenetrable function.  You might have a "numberOfDaysInYear()" 
function, and functions for converting (day, month) pairs back and forth 
to the number of days since the first of January.  You can have lunar 
calculations also based on the number of days from a given starting 
point (perhaps using Unix epoch time rather than struct tm).  Then you 
can have a "findEaster()" function that returns the date of Easter for a 
given year as the number of days from the first of January.

[toc] | [prev] | [next] | [standalone]

#383032

David Brown <david.brown@hesbynett.no> writes:

> On 25/02/2024 18:39, Lew Pitcher wrote:
>> On Sat, 24 Feb 2024 21:15:56 +0000, Mike Sanders wrote:
>> 
>>> Calculate the date of Easter Sunday or Good Friday:
>>>
>>> https://busybox.neocities.org/notes/is-easter-or-goodfriday.txt
>> I don't have the expertise to discuss whether or not your code
>> properly implements the calculations necessary to determine the
>> date of Good Friday and/or Easter. However, I /do/ have some
>> expertise on writing understandable code.
>> My suggestions, with respect to your program, would be to
>> a) name your objects with relevant, understandable names
>>     You code uses quite a lot of meaningless one-letter
>>     objects, and it is difficult to keep track of the
>>     purpose of the calculations using them.
>
> I agree here.

I challenge the "use better names" to try it.  The trouble with this
sort of code is, I suspect, that the quantities don't correspond to
anything that can be clearly named.  I may be wrong as I don't know this
form, but it true of the much better known Zeller's Congruence.

I think the correct way to present an algorithm like this if to include
a block comment than documents and explains the formula (using whatver
names are conventional), followed by code that uses the same names to do
the calculation.

> I'd also avoid single-letter capital letter variables, and avoid
> single-letter variables that are easily misread (so don't use "L" or "O",
> big or small).  Single-letter variables are fine if their scope is small
> and their meaning is clear - such as "i" for a loop variable, and "x" and
> "y" for coordinates.

In this case, I would use the conventional names (if there are any) even
if this violates the usual programming conventions.  All supposing that
the formula has been explained in a comment using exactly those names.

> Good names here, together with some comments, would go a long way to making
> it possible to understand your algorithm here.

Have you tried?  It may well detract from the explanations in the
references.  (I am hoping that the referenced URLs explain the formula.)

> Links to web pages for
> reference are useful (and it's always polite to give your references), but
> remember that web pages don't last for ever - try to make your code stand
> alone as code, or at least have enough comments to cover the information.
>
>> b) Don't place your calculations /in/ the object initializations.
>>     Doing so obfuscates the intent of the logic, and makes
>>     problem determination and resolution difficult.
>
> I'd disagree with that one.  Initialise your variables when you have
> something to put in them, and that is often a calculated value.

Yes, and I'd make them all const to show that they just name quantities
to simplify later calculations.  That would force the adjustments to the
day, month and year (to get good Friday) to be in another function.  The
logical one would be a separate test function for that date (as you have
suggested):

> Don't have one function that appears to do two different things.

Yes.  I was taught a phrase about function arguments: "pass data not
control".

> It's much
> better to have "isEaster()" and "isGoodFriday()" functions. Clearly these
> are heavily related, so have a static helper function that does the common
> calculations.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#383036

On 26/02/2024 14:04, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 25/02/2024 18:39, Lew Pitcher wrote:
>>> On Sat, 24 Feb 2024 21:15:56 +0000, Mike Sanders wrote:
>>>
>>>> Calculate the date of Easter Sunday or Good Friday:
>>>>
>>>> https://busybox.neocities.org/notes/is-easter-or-goodfriday.txt
>>> I don't have the expertise to discuss whether or not your code
>>> properly implements the calculations necessary to determine the
>>> date of Good Friday and/or Easter. However, I /do/ have some
>>> expertise on writing understandable code.
>>> My suggestions, with respect to your program, would be to
>>> a) name your objects with relevant, understandable names
>>>      You code uses quite a lot of meaningless one-letter
>>>      objects, and it is difficult to keep track of the
>>>      purpose of the calculations using them.
>>
>> I agree here.
> 
> I challenge the "use better names" to try it.  The trouble with this
> sort of code is, I suspect, that the quantities don't correspond to
> anything that can be clearly named.  I may be wrong as I don't know this
> form, but it true of the much better known Zeller's Congruence.

Yes, I realise that's likely to be a problem here.  For variables that 
exist solely to break up a long complicated calculation into manageable 
parts, good names are hard or impossible.

However, I would guess - without having looked at the details of the 
algorithm - that this could be split into parts that are a bit clearer, 
and at least some of the variables could then have names showing what's 
going on.  You might have the offset into the lunar month, or the number 
of days in February, or a boolean for before/after the spring equinox.

If the expressions can only be split in somewhat arbitrary positions, 
and therefore the variables have arbitrary and meaningless names, so be 
it.  But if it is possible and practical to do better, then I'd 
recommend that.

> 
> I think the correct way to present an algorithm like this if to include
> a block comment than documents and explains the formula (using whatver
> names are conventional), followed by code that uses the same names to do
> the calculation.

That is something I also suggested (without the detail of the names).

> 
>> I'd also avoid single-letter capital letter variables, and avoid
>> single-letter variables that are easily misread (so don't use "L" or "O",
>> big or small).  Single-letter variables are fine if their scope is small
>> and their meaning is clear - such as "i" for a loop variable, and "x" and
>> "y" for coordinates.
> 
> In this case, I would use the conventional names (if there are any) even
> if this violates the usual programming conventions.  All supposing that
> the formula has been explained in a comment using exactly those names.
> 

Agreed.  Clear and understandable code is more important than 
conventions.  (But names like "l" or "O" are rarely clear, even if they 
are used in the context of the documentation of an algorithm.)

>> Good names here, together with some comments, would go a long way to making
>> it possible to understand your algorithm here.
> 
> Have you tried?  It may well detract from the explanations in the
> references.  (I am hoping that the referenced URLs explain the formula.)
> 
>> Links to web pages for
>> reference are useful (and it's always polite to give your references), but
>> remember that web pages don't last for ever - try to make your code stand
>> alone as code, or at least have enough comments to cover the information.
>>
>>> b) Don't place your calculations /in/ the object initializations.
>>>      Doing so obfuscates the intent of the logic, and makes
>>>      problem determination and resolution difficult.
>>
>> I'd disagree with that one.  Initialise your variables when you have
>> something to put in them, and that is often a calculated value.
> 
> Yes, and I'd make them all const to show that they just name quantities
> to simplify later calculations.  That would force the adjustments to the
> day, month and year (to get good Friday) to be in another function.  

Agreed - I think it is often clearer to have const variables that are 
set once and never changed, so that you can always see exactly what 
value they have, and when it is set.

> The
> logical one would be a separate test function for that date (as you have
> suggested):
> 
>> Don't have one function that appears to do two different things.
> 
> Yes.  I was taught a phrase about function arguments: "pass data not
> control".
> 

That's a good way to put it.

>> It's much
>> better to have "isEaster()" and "isGoodFriday()" functions. Clearly these
>> are heavily related, so have a static helper function that does the common
>> calculations.
> 

[toc] | [prev] | [next] | [standalone]

#383041

On 26.02.2024 15:46, David Brown wrote:
> 
> Yes, I realise that's likely to be a problem here.  For variables that
> exist solely to break up a long complicated calculation into manageable
> parts, good names are hard or impossible.
> 
> However, I would guess - without having looked at the details of the
> algorithm - that this could be split into parts that are a bit clearer,

Unfortunately not, I fear.

> and at least some of the variables could then have names showing what's
> going on.  You might have the offset into the lunar month, or the number
> of days in February, or a boolean for before/after the spring equinox.

You seem to have chosen a source where "Spencer's" algorithm is
described. In a corresponding Wikipedia article (here in German:
e.g. https://de.wikipedia.org/wiki/Spencers_Osterformel)
you find the same non-descriptive names.

> 
> If the expressions can only be split in somewhat arbitrary positions,
> and therefore the variables have arbitrary and meaningless names, so be
> it.  But if it is possible and practical to do better, then I'd
> recommend that.

If you put in a reference to the document source - while not
explaining anything - that might suffice. Otherwise you'd have
to spend more effort describing the variables in detail.

Janis

[toc] | [prev] | [next] | [standalone]

#383047

've just noticed I was formulating it as if it was your code. Of course
it was addressed at the author of the code. My apologies!


On 26.02.2024 16:17, Janis Papanagnou wrote:
> On 26.02.2024 15:46, David Brown wrote:
>>
>> Yes, I realise that's likely to be a problem here.  For variables that
>> exist solely to break up a long complicated calculation into manageable
>> parts, good names are hard or impossible.
>>
>> However, I would guess - without having looked at the details of the
>> algorithm - that this could be split into parts that are a bit clearer,
> 
> Unfortunately not, I fear.
> 
>> and at least some of the variables could then have names showing what's
>> going on.  You might have the offset into the lunar month, or the number
>> of days in February, or a boolean for before/after the spring equinox.
> 
> You seem to have chosen a source where "Spencer's" algorithm is
> described. In a corresponding Wikipedia article (here in German:
> e.g. https://de.wikipedia.org/wiki/Spencers_Osterformel)
> you find the same non-descriptive names.
> 
>>
>> If the expressions can only be split in somewhat arbitrary positions,
>> and therefore the variables have arbitrary and meaningless names, so be
>> it.  But if it is possible and practical to do better, then I'd
>> recommend that.
> 
> If you put in a reference to the document source - while not
> explaining anything - that might suffice. Otherwise you'd have
> to spend more effort describing the variables in detail.
> 
> Janis
> 

[toc] | [prev] | [next] | [standalone]

#383035

David Brown <david.brown@hesbynett.no> wrote:

> Don't use "int" when you mean "bool".  That applies to parameters, 
> return types, and variables.

But I dont mean bool, I mean int, because the function (well my
private code at any rate) now includes other Holi/Holy days:

int foo(const struct tm *now, int hDay);

switch (hDay)...

But you all still raise some good points.

-- 
:wq
Mike Sanders

[toc] | [prev] | [next] | [standalone]

#383049

porkchop@invalid.foo (Mike Sanders) writes:
>David Brown <david.brown@hesbynett.no> wrote:
>
>> Don't use "int" when you mean "bool".  That applies to parameters, 
>> return types, and variables.
>
>But I dont mean bool, I mean int, because the function (well my
>private code at any rate) now includes other Holi/Holy days:
>
>int foo(const struct tm *now, int hDay);

I would expect that an enumeration would be superior
to an 'int' for this purpose.

[toc] | [prev] | [next] | [standalone]

#383057

Scott Lurndal <scott@slp53.sl.home> wrote:

>>int foo(const struct tm *now, int hDay);
> 
> I would expect that an enumeration would be superior
> to an 'int' for this purpose.

Just now getting around to thinking of that to be honest
Scott (seems you're step ahead of me), but enums are
great in my thinking, consider:

enum weekdays { Sun, Mon, Tue, Wed, Thu, Fri, Sat };

if (Wed > Sun) { ... }

Nice & easy to read yeah?


-- 
:wq
Mike Sanders

[toc] | [prev] | [next] | [standalone]

#383058

porkchop@invalid.foo (Mike Sanders) writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>
>>>int foo(const struct tm *now, int hDay);
>> 
>> I would expect that an enumeration would be superior
>> to an 'int' for this purpose.
>
>Just now getting around to thinking of that to be honest
>Scott (seems you're step ahead of me), but enums are
>great in my thinking, consider:
>
>enum weekdays { Sun, Mon, Tue, Wed, Thu, Fri, Sat };
>
>if (Wed > Sun) { ... }
>
>Nice & easy to read yeah?

When you're working with dates, wednesday both preceeds
and follows sunday;  so your if statement is logically
ambiguous.

Often, struct tm is useful for representing date/times
(unless you need year values 12024 or more years before present).

  seconds [0-59]
  minutes [0-59]
  hours   [0-23]
  day     [1-31]
  month   [0-11]
  year    [INT_MIN - INT_MAX]
  wday    [0-6]   /* day of week */
  yday    [0-365] /* day of year */
  isdst   [-1,0,1] /* DST flag */


In any case, your 'hday' would have enumerated a
list of holidays, right?    Where ordering wouldn't
be a prime criteria, rather the usefulness of an
enumeration would be in readability and maintainabilty
of the code.

[toc] | [prev] | [next] | [standalone]

#383062

Scott Lurndal <scott@slp53.sl.home> wrote:

> In any case, your 'hday' would have enumerated a
> list of holidays, right?    Where ordering wouldn't
> be a prime criteria, rather the usefulness of an
> enumeration would be in readability and maintainabilty
> of the code.

Likely something close to (beware word-wrap) the following:

#define MAXNODES 6000

int foo(const struct tm *now, this, that, FILE *file) {

int totalDays = 366;
int count = 0;

    BLOCK *nodes = (BLOCK *)malloc(MAXNODES * sizeof(BLOCK));
    if (!nodes) return eMsg(errALLOC, 0);

    temp_date = *now;

    if (ops.hly) {
      for (int j = temp_date.tm_mday; j <= totalDays && count < MAXNODES; j++) {
        BLOCK tmp = putHoliday(tmp_date, ENUM_WILL_BE_PLACED_HERE);
        if (tmp) {
          nodes[count] = tmp;
          temp_date = addDays(tmp_date, 1); // so we can see ahead of the curve...
          count++;
        }
      }
    }


    if (count) {
      for (int q = 0; q < count; q++)
         fprintf(file, "%s whatever", node[q].member);
    }

    free(nodes); // etc...
    return 0;

}

BLOCK putHoliday(const struct tm *now, ENUM_WILL_BE_PLACED_HERE) {

    // you get the idea i'm guessing

}

struct tm addDays(struct tm date, int days) {
    date.tm_mday += days; // add days to the current date
    mktime(&date); // normalize date
    return date;
}


-- 
:wq
Mike Sanders

[toc] | [prev] | [next] | [standalone]

#383080

On Mon, 26 Feb 2024 20:06:44 GMT, Scott Lurndal wrote:

> porkchop@invalid.foo (Mike Sanders) writes:
>
>>if (Wed > Sun) { ... }
>>
>>Nice & easy to read yeah?
> 
> When you're working with dates, wednesday both preceeds and follows
> sunday;  so your if statement is logically ambiguous.

There is a term for that: it’s “modulo arithmetic”.

[toc] | [prev] | [next] | [standalone]

#383051

On 26/02/2024 15:38, Mike Sanders wrote:
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> Don't use "int" when you mean "bool".  That applies to parameters,
>> return types, and variables.
> 
> But I dont mean bool, I mean int, because the function (well my
> private code at any rate) now includes other Holi/Holy days:
> 
> int foo(const struct tm *now, int hDay);
> 
> switch (hDay)...
> 
> But you all still raise some good points.
> 

I can only comment on the code you've given.  And "isLeapYear()", and 
"isEasterOrGoodFriday()" should both return "bool".  The parameter 
"checkGoodFriday" should be bool too.  (Actually, it should be scraped 
and the function split, as discussed on another branch.)

And if you are returning "holiday type" from a function, it should not 
be "int" either - make it return an enumerated type.

[toc] | [prev] | [next] | [standalone]

#383039

On 26.02.2024 11:45, David Brown wrote:
> On 25/02/2024 18:39, Lew Pitcher wrote:
>> On Sat, 24 Feb 2024 21:15:56 +0000, Mike Sanders wrote:
>>
>>> Calculate the date of Easter Sunday or Good Friday:
>>> https://busybox.neocities.org/notes/is-easter-or-goodfriday.txt
>>
>> [...]
>>
>> My suggestions, with respect to your program, would be to
>> a) name your objects with relevant, understandable names
>>     You code uses quite a lot of meaningless one-letter
>>     objects, and it is difficult to keep track of the
>>     purpose of the calculations using them.
> 
> [...]
> 
> Good names here, together with some comments, would go a long way to
> making it possible to understand your algorithm here.  Links to web
> pages for reference are useful (and it's always polite to give your
> references), but remember that web pages don't last for ever - try to
> make your code stand alone as code, or at least have enough comments to
> cover the information.

Yes. Often it is the case that some magic formula is just copied
from some place without knowledge. (I suspect here too.) At least
a reference of the source of the formula should be provided with
the code! (At first glance it seems to be the so called Spencer's
formula [1922], published by someone else already in 1876.[*])

Over the years there had been many formulas, variants, refinements
introducing correction factors, etc. In the Wikipedias you should
find enough information[**].

> 
> Consider making and using several general functions, rather than having
> a single impenetrable function.  You might have a "numberOfDaysInYear()"
> function, and functions for converting (day, month) pairs back and forth
> to the number of days since the first of January.  You can have lunar
> calculations also based on the number of days from a given starting
> point (perhaps using Unix epoch time rather than struct tm).  Then you
> can have a "findEaster()" function that returns the date of Easter for a
> given year as the number of days from the first of January.

I'd expect that formulating the algorithm/formula using FP numbers
could probably make it also a bit simpler. (But I haven't tried.)
If you consider the actual task you observe that you somehow have
to map the lunar period (~30 d) to the sun period (~365 d), where
these cycles are not exact (not integral) and they are numerically
not synchronous, plus the weekday mapping (actually a third cycle,
in the calculation, here of integral type). This whole set of scalar
integers seem to emulate these inherent issues as correction factors
and few of them will represent real world entities.

Janis

[*] https://de.wikipedia.org/wiki/Spencers_Osterformel

[**] I picked the links from the German Wikipedia - apologies for
that - but I think that articles like these should be available in
other languages as well if you search for the respective keywords.
Easter date (also listing the two prevalent Easter definitions):
https://de.wikipedia.org/wiki/Osterdatum
Easter computation (mentioning also the necessary corrections):
https://de.wikipedia.org/wiki/Computus_(Osterrechnung)
Gauss' formulas and historic:
https://de.wikipedia.org/wiki/Gau%C3%9Fsche_Osterformel
And a general article about Easter (for the cultural basics):
https://de.wikipedia.org/wiki/Ostern

[toc] | [prev] | [next] | [standalone]

#383052

On Mon, 26 Feb 2024 11:45:36 +0100, David Brown wrote:

> On 25/02/2024 18:39, Lew Pitcher wrote:
>> On Sat, 24 Feb 2024 21:15:56 +0000, Mike Sanders wrote:
>> 
>>> Calculate the date of Easter Sunday or Good Friday:
>>>
>>> https://busybox.neocities.org/notes/is-easter-or-goodfriday.txt
>> 
>> I don't have the expertise to discuss whether or not your code
>> properly implements the calculations necessary to determine the
>> date of Good Friday and/or Easter. However, I /do/ have some
>> expertise on writing understandable code.
>> 
>> My suggestions, with respect to your program, would be to
[snip]
>> b) Don't place your calculations /in/ the object initializations.
>>     Doing so obfuscates the intent of the logic, and makes
>>     problem determination and resolution difficult.
> 
> I'd disagree with that one.  Initialise your variables when you have 
> something to put in them, and that is often a calculated value.

I base my suggestion on the OP's source:
 int isEasterOrGoodFriday(const struct tm *now, int checkGoodFriday) {

    int Y = now->tm_year + 1900; // correcting the year
    int a = Y % 19;
    int b = Y / 100;
    int c = Y % 100;
    int d = b / 4;
    int e = b % 4;
    int f = (b + 8) / 25;
    int g = (b - f + 1) / 3;
    int h = (19 * a + b - d - g + 15) % 30;
    int i = c / 4;
    int k = c % 4;
    int L = (32 + 2 * e + 2 * i - h - k) % 7;
    int m = (a + 11 * h + 22 * L) / 451;
    int month = (h + L - 7 * m + 114) / 31;
    int day = ((h + L - 7 * m + 114) % 31) + 1;

    if (checkGoodFriday) {
[rest of code elided]

The program code /depends/ on the specific order of
the declarations: <<Y>> /must/ be declared before <<a>>,
<<a>> /must/ be declared before <<h>>, etc.

If some good-meaning (or unknowledgable) maintainer decides to
reorder or consolidate the above declarations, the program
either fails or gives erroneous results.

The OP embedded the /logic/ of the program within the declarations.
That, to me. is /not/ good programming. 

Hope this helps clarify my earlier remarks.
-- 
Lew Pitcher
"In Skills We Trust"

[toc] | [prev] | [next] | [standalone]

#383091

On 26/02/2024 18:26, Lew Pitcher wrote:
> On Mon, 26 Feb 2024 11:45:36 +0100, David Brown wrote:
> 
>> On 25/02/2024 18:39, Lew Pitcher wrote:
>>> On Sat, 24 Feb 2024 21:15:56 +0000, Mike Sanders wrote:
>>>
>>>> Calculate the date of Easter Sunday or Good Friday:
>>>>
>>>> https://busybox.neocities.org/notes/is-easter-or-goodfriday.txt
>>>
>>> I don't have the expertise to discuss whether or not your code
>>> properly implements the calculations necessary to determine the
>>> date of Good Friday and/or Easter. However, I /do/ have some
>>> expertise on writing understandable code.
>>>
>>> My suggestions, with respect to your program, would be to
> [snip]
>>> b) Don't place your calculations /in/ the object initializations.
>>>      Doing so obfuscates the intent of the logic, and makes
>>>      problem determination and resolution difficult.
>>
>> I'd disagree with that one.  Initialise your variables when you have
>> something to put in them, and that is often a calculated value.
> 
> I base my suggestion on the OP's source:
>   int isEasterOrGoodFriday(const struct tm *now, int checkGoodFriday) {
> 
>      int Y = now->tm_year + 1900; // correcting the year
>      int a = Y % 19;
>      int b = Y / 100;
>      int c = Y % 100;
>      int d = b / 4;
>      int e = b % 4;
>      int f = (b + 8) / 25;
>      int g = (b - f + 1) / 3;
>      int h = (19 * a + b - d - g + 15) % 30;
>      int i = c / 4;
>      int k = c % 4;
>      int L = (32 + 2 * e + 2 * i - h - k) % 7;
>      int m = (a + 11 * h + 22 * L) / 451;
>      int month = (h + L - 7 * m + 114) / 31;
>      int day = ((h + L - 7 * m + 114) % 31) + 1;
> 
>      if (checkGoodFriday) {
> [rest of code elided]
> 
> The program code /depends/ on the specific order of
> the declarations: <<Y>> /must/ be declared before <<a>>,
> <<a>> /must/ be declared before <<h>>, etc.

Yes, because "a" is initialised with an expression using "Y".

> 
> If some good-meaning (or unknowledgable) maintainer decides to
> reorder or consolidate the above declarations, the program
> either fails or gives erroneous results.

Why would anyone do that?  These are initialised variables that depend 
on each other.  Re-ordering makes no more sense than re-ordering 
printf("world\n") before printf("Hello ").

> 
> The OP embedded the /logic/ of the program within the declarations.

You mean, the variables are declared only when there was something to 
put in them?

> That, to me. is /not/ good programming.

It has been good programming for many decades in C - it doesn't even 
need C99.

> 
> Hope this helps clarify my earlier remarks.

If you are trying to say that you think the "correct" way to write C 
code is to declare all your variables without initialisation at the 
start of the function and have a strict separation from the expressions 
and statements of the function, then I know what you are saying.  I 
totally disagree with it, but that is a discussion that comes up 
regularly, and I believe we've been through it recently.  It would be 
on-topic in c.l.c., which is nice, but I'm not sure we'll cover anything 
new.

If that's /not/ what you are saying, them I'm afraid I don't yet 
understand your point.

[toc] | [prev] | [next] | [standalone]

#383272

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

[minor editing]

>> On 25/02/2024 18:39, Lew Pitcher wrote:
>>
>>> On Sat, 24 Feb 2024 21:15:56 +0000, Mike Sanders wrote:
>>>
>>>> Calculate the date of Easter Sunday or Good Friday:
>>>>
>>>> https://busybox.neocities.org/notes/is-easter-or-goodfriday.txt
>>>
>>> My suggestions, with respect to your program, would be to
>>> [...]
>>> b) Don't place your calculations /in/ the object initializations.
>>>     Doing so obfuscates the intent of the logic, and makes
>>>     problem determination and resolution difficult.

Minor comment:  normally I am used to the term "logic" to mean
how control structures are used, not simply the order of
otherwise sequential program elements.  However I think I
understand what you mean so let's ignore that question.

> I base my suggestion on the OP's source:
>  int isEasterOrGoodFriday(const struct tm *now, int checkGoodFriday) {
>
>     int Y = now->tm_year + 1900; // correcting the year
>     int a = Y % 19;
>     int b = Y / 100;
>     int c = Y % 100;
>     int d = b / 4;
>     int e = b % 4;
>     int f = (b + 8) / 25;
>     int g = (b - f + 1) / 3;
>     int h = (19 * a + b - d - g + 15) % 30;
>     int i = c / 4;
>     int k = c % 4;
>     int L = (32 + 2 * e + 2 * i - h - k) % 7;
>     int m = (a + 11 * h + 22 * L) / 451;
>     int month = (h + L - 7 * m + 114) / 31;
>     int day = ((h + L - 7 * m + 114) % 31) + 1;
>
>     if (checkGoodFriday) {
> [rest of code elided]
>
> The program code /depends/ on the specific order of
> the declarations: <<Y>> /must/ be declared before <<a>>,
> <<a>> /must/ be declared before <<h>>, etc.
>
> If some good-meaning (or unknowledgable) maintainer decides to
> reorder or consolidate the above declarations, the program
> either fails or gives erroneous results.

If variables are declared separately, without any initializers,
and all assignments are done after all the declarations, then the
assignment statements can be arbitrarily reordered and still get
a compilable program.  If varibles are all declared with an
initializing expression, as above, then any improper reordering
gives a compilation error, due to a variable being undeclared.
It seems to be that separating the declarations and the initial
assignments is more error prone than keeping them together.

> The OP embedded the /logic/ of the program within the declarations.
> That, to me, is /not/ good programming.

I don't understand why you think that.  Can you explain further?

> Hope this helps clarify my earlier remarks.

It does help clarify the what.  I still don't yet understand the
why.

[toc] | [prev] | [next] | [standalone]

#383081

On Mon, 26 Feb 2024 11:45:36 +0100, David Brown <david.brown@hesbynett.no>
wrote in <urhq4h$2g5oc$1@dont-email.me>:

> On 25/02/2024 18:39, Lew Pitcher wrote:
>> On Sat, 24 Feb 2024 21:15:56 +0000, Mike Sanders wrote:
>> 
>>> Calculate the date of Easter Sunday or Good Friday:
>>>
>>> https://busybox.neocities.org/notes/is-easter-or-goodfriday.txt
>> 
>> I don't have the expertise to discuss whether or not your code properly
>> implements the calculations necessary to determine the date of Good
>> Friday and/or Easter. However, I /do/ have some expertise on writing
>> understandable code.
>> 
>> My suggestions, with respect to your program, would be to a) name your
>> objects with relevant, understandable names
>>     You code uses quite a lot of meaningless one-letter objects, and it
>>     is difficult to keep track of the purpose of the calculations using
>>     them.
> 
> I agree here.
> 
> I'd also avoid single-letter capital letter variables, and avoid
> single-letter variables that are easily misread (so don't use "L" or
> "O", big or small).  Single-letter variables are fine if their scope is
> small and their meaning is clear - such as "i" for a loop variable, and
> "x" and "y" for coordinates.
> 
> Good names here, together with some comments, would go a long way to
> making it possible to understand your algorithm here.  Links to web
> pages for reference are useful (and it's always polite to give your
> references), but remember that web pages don't last for ever - try to
> make your code stand alone as code, or at least have enough comments to
> cover the information.
> 
>> b) Don't place your calculations /in/ the object initializations.
>>     Doing so obfuscates the intent of the logic, and makes problem
>>     determination and resolution difficult.
> 
> I'd disagree with that one.  Initialise your variables when you have
> something to put in them, and that is often a calculated value.
> 
> 
>> Otherwise, it /appears/ to do the job. Good first attempt.
> 
> Some other suggestions:
> 
> Don't use "int" when you mean "bool".  That applies to parameters,
> return types, and variables.
> 
> Don't have one function that appears to do two different things.  It's
> much better to have "isEaster()" and "isGoodFriday()" functions. Clearly
> these are heavily related, so have a static helper function that does
> the common calculations.
> 
> Consider making and using several general functions, rather than having
> a single impenetrable function.  You might have a "numberOfDaysInYear()"
> function, and functions for converting (day, month) pairs back and forth
> to the number of days since the first of January.  You can have lunar
> calculations also based on the number of days from a given starting
> point (perhaps using Unix epoch time rather than struct tm).  Then you
> can have a "findEaster()" function that returns the date of Easter for a
> given year as the number of days from the first of January.

ncal(1) has the -e and -o options for both Easters.  I went looking for
the source of the Easter-computation code, found one copy here:

https://github.com/lattera/freebsd/blob/master/lib/libcalendar/easter.c

On Ubuntu with source repositories enabled, one can get the BSD
ncal (with its bundled libcalendar) with

$ apt-get source ncal

I really wish the function easterg() was commented better.

/* Compute Easter Sunday in Gregorian Calendar */
date *
easterg(int y, date *dt)
{
        int c, i, j, k, l, n;

        n = y % 19;
        c = y / 100;
        k = (c - 17) / 25;
        i = (c - c/4 -(c-k)/3 + 19 * n + 15) % 30;
        i = i -(i/28) * (1 - (i/28) * (29/(i + 1)) * ((21 - n)/11));
        j = (y + y/4 + i + 2 - c + c/4) % 7;
        l = i - j;
        dt->m = 3 + (l + 40) / 44;
        dt->d = l + 28 - 31*(dt->m / 4);
        dt->y = y;
        return (dt);
}

The code is 27 years old.  I will not pretend to understand it. (Yet?)

Feed the easterg() function to ChatGPT, and it will pretend
to explain it.  (Is it correct?  Beats me.  But it did
introduce me to the concept of the "Computus"[*].)

[*] Described in here: https://en.wikipedia.org/wiki/Date_of_Easter

-- 
-v
"What did you give up for Lent?" "Religion."

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web