On 11/20/22 11:30, Janis Papanagnou wrote:
> [...]
>>

As noted in the last e-mail about finding a correction/improvement
factor for the moon phase, there is an old variant of the moon
function which subtracts 1900 from the input year. For some reason,
the formula was updated and this adjustment removed.

This week, I tested the moon phase function was tested with correction
factor from -3800 to +3800 applied to the input year. Meaning that,
if input is year 2000, then calculation was tested with 7600 different
correction factors, such as
year (2000-1), (2001+1) ... (2000-3800) and (2000+3800)
to see whether these adjustments in the internal calculation would
improve results of moon phase according to data scraped from USNO Navy
for each year from 1700 to 2102. It basically checks results from the
script with correction factor applied to see if each moon phase starts
at the same DATE as that from USNO Navy tables.

Below is an abridged table with results from the tests with
correction factors used and ratio of exact matches to the Navy moon
phase starting dates.

Input Year | Exact | Non- | Ratio
Adjustment | Matches | Matches | (Percent)
------------+----------+-----------+----------
-1900 | 1800 | 18132 | 9.03%
------------+----------+-----------+----------
+0 | 3495 | 16449 | 17.52% [original]
------------+----------+-----------+----------
+8 | 8037 | 11907 | 40.30%
------------+----------+-----------+----------
-68 | 8047 | 11897 | 40.35%
------------+----------+-----------+----------
-1892 | 9508 | 10426 | 47.70%

Interestingly, subtracting 1892 from input year is the best adjustment
for this formula amongst the tested range. Improvement is observed
when testing correction factors grow up to |1892| and factors greater
than |1892| (positive and negative values) decrease improvement, so
it does seem like a correction factor of -1892 to the input year
ought to be optimal for this formula and use case, even though
the formula can `only' match the start of moon phases to USNO navy
tables at about 48% of times (better than the original formula which
delivers about 18% matches), but also, *it improves accuracy* of overall
results, i.e. decreases the distance from the start of calculated
moon phases relative to USNO Navy tables.

I hope this test explanation is comprehensible/understandable.

This moon phase function testing generated 3.34 GB of data which was
compared to Navy data, so I am reasonably confident about the results.

Cheers!
JSN

On Thursday, December 1, 2022 at 5:07:53 PM UTC-5, Janis Papanagnou wrote:
> On 01.12.2022 16:12, applemcg wrote:
> >
> > a little late to the party, saw some discussion of function syntax, definition.
> >
> > from this:
> >
> > #get day in the week
> > #usage: get_day_in_week unix_time
> > function get_day_in_week
> > {
> > echo ${DAY_OF_WEEK[( ( ($1+($1<0?1:0))/(24*60*60))%7 +($1<0?6:7))%7]}
> > }
> >
> > i'd write:
> >
> >
> > get_day_in_week ()
> > {
> > : get day in the week
> Identical to function name, unnecessary bloat, a potential source of
> inconsistency.
>
> > : example: get_day_in_week unix_time 2300000
>
> Seems to document a wrong syntax (seems to be inconsistent to code).
>
> > : uses: DAY_OF_WEEK
>
> Already quite obvious.
> >
> > echo ${DAY_OF_WEEK[( ( ($1+($1<0?1:0))/(24*60*60))%7 +($1<0?6:7))%7]}
> > }
> >
> I'd probably write (using ksh syntax here, but similar for bash)
>
> function get_day_in_week
> {
> typeset -i unix_time=${1:?}
>
> printf "%s\n" ${DAY_OF_WEEK[ $(( unix_time + ... )) ]
> }
>
> and omit the unnecessary comments, add a variable for legibility and
> safety (i.e. the test on $1), use arithmetic syntax for clarity, and
> standard (and generally safer) printf.
>
> > [...]
>
> Mileages vary.
>
> Janis
> >
> >
> > On Wednesday, November 30, 2022 at 1:01:27 AM UTC-5, castAway wrote:
> >> [...]

Janis,

thanks for your helpful corrections.

thanks also for pointing out the performance hit isn't to severe

but let me object to the use of "bloat"

i'm working on an idea, where the shell source text, the stuff you
put in source control, has the "unnecessary bloat", and you've
given be a terrific idea.

i've library, "shdoclib" which mangles shell function text. the
syntax you're looking at is a feature i call "tags"

a sample tag, "date" will appear like this in the code:

somefunction ()
{ : "the first null command is the function's abstract"
: here quoted to protect the " ' " character
: after the shdoc, which are the first untagged-lines of the function, come the tags,
: such as the next line
: date: 2016-06-06, the first time we stored this in a library
: ... etc ...
: date: 2022-12-04, the most recent modification
... # followed by the body of the function
...
}

w.r.t. the "example" example, that was indeed a syntactic mistake,

it might have more correctly said:

: example: get_day_in_week 1670194179

the purpose of the example tag is to show an instance of usage, if
only as a reminder. it may _not_ be directly using the function.
Here's an (dare I say) worked example, not every function is here
presented, but...

$ def {eval,show}_example show_dateformat
eval_example ()
{
: evaluate, i.e. execute the example TAG from a function;
: example: eval_example show_dateformat;
: related: show_dateformat;
: date: 2022-09-24;
: date: 2022-10-03;
: date: 2022-11-18;
set -- $(show_example $1);
debug $# $*;
[[ -n "$1" ]] && eval $@
} show_example ()
{
: extract the EXAMPLE tag value, i.e. the string to execute;
: date: 2022-09-24;
: date: 2022-11-18;
if_missingargs 1 $* && return;
report_notfunction $1 && return 1;
declare -f $1 | grep ': example: ' | sed "

s/[^']*: example: *//
s/; *$//
"
} show_dateformat ()
{
: example: foreach show_dateformat {a..z} {A..Z} | awk '$1 != $2';
: related: eval_example;
: date: 2020-05-03;
: date: 2022-09-23;
: date: 2022-11-18;
printf "%s\t%s\n" $1 "$(date +%$1)"
} shlib.$ eval_example eval_example
a Sun
b Dec
c Sun Dec 4 17:54:19 2022
d 04
e 4
g 22
h Dec
j 338
k 17
l 5
m 12
n
p PM
r 05:54:20 PM
s 1670194460
t
u 7
v 4-Dec-2022
w 0
x 12/04/2022
y 22
z -0500
A Sunday
B December
C 20
D 12/04/22
F 2022-12-04
G 2022
H 17
I 05
M 54
R 17:54
S 20
T 17:54:20
U 49
V 48
W 48
X 17:54:20
Y 2022
Z EST
shlib.$

Another tag is "related" means- a function not in the body of the code

other functions:

* if_missingargs, returns an error if the count of $* is less than the
preceeding N

* debug, with related "pause" function; these turned "on" and "off"

* report_notfunction, returns TRUE if it's argument is NOT a
function, reporting on stderr

Now, to solve your "unnecessary bloat" problem, I'm already keeping a
duplicate copy of every function library around, so, with a little
care, the one which i execute will be run thru a yet-to-be-written
"just_nocolon" function, a complement of this "shd_justcolon" function:

$ def shd_justcolon
shd_justcolon ()
{
: returns leading colon-comments from a SINGLE function;
: date: 2020-08-28;
report_notpipe && return 1;
awk '
NR > 2 {
if ( $1 !~ /^:/ ) exit
else print
}
'
} shlib.$

The copy on my PATH will be the NO-colon copy, the copy i work, test
and record the tag data base with will be HAS-colon copy. And, if you
don't mind, I shall credit you with the insight.

At my advanced age, my time is infinitely more precious than computer
time, so i thank you for skewering any "performance" argument. One
way I improve my work is to make abstracts of function libraries and
use them when it's time to recall what I may need now.

Here's a sample of querying my Database of Functions with Grep (dfg),
to produce a truncated TAG report, first TAG only:

$ dfg .| column context | row 'context ~ /: [a-zA-A0-9]*: /' | rd awk '!p[$2]++'

context
-------
: date: 2022-08-01;
: todo: construct the copyright dates from the date tag.;
: usage: "app_isa arg ... || return";
: lesson: how easy this all is;
: example: comm <( command_all|tpl|sort) <( functions ./commandlib | sort);
: related: eval_example;
....
shlib.$

I use a quite old copy of the Unix Relational Data Base /RBD (search for it) where

* column extracts the named columns, defaulting to all,
* row is the "select" operation, in this case the "context" column is a TAG, and
* rd is my hack to leave the RDB column headers, while executing the command arguemnts

Here's the tail of a "Word count" on the development database

...

10 53 381 utillib/wheres_home
6 19 127 utillib/whf
6 15 98 utillib/wpl
4 5 24 xrflib/bar
4 5 24 xrflib/foo
12 44 299 xrflib/gather_aux
16 65 473 xrflib/obsolescent
4 5 24 xrflib/zot
21565 73931 523977 total
dir.$
dir.$ wc */* | wc -l
1982
dir.$

N.B. you can imagine how valuable "related" and "use" become in a function database.

again, thanks for the insight.

~ Marty (aka, applemcg, a McGowan from Appleton (MN, not WI))

p.s. a quick scan of the resulting WC suggests a population history of the line count (WC -L)
for each function. never had thought of that ''till now. that's two for you.

On Thursday, December 1, 2022 at 5:07:53 PM UTC-5, Janis Papanagnou wrote:
> On 01.12.2022 16:12, applemcg wrote:
> >
> > a little late to the party, saw some discussion of function syntax, definition.
> >
> > from this:
> >
> > #get day in the week
> > #usage: get_day_in_week unix_time
> > function get_day_in_week
> > {
> > echo ${DAY_OF_WEEK[( ( ($1+($1<0?1:0))/(24*60*60))%7 +($1<0?6:7))%7]}
> > }
> >
> > i'd write:
> >
> >
> > get_day_in_week ()
> > {
> > : get day in the week
> Identical to function name, unnecessary bloat, a potential source of
> inconsistency.
>
> > : example: get_day_in_week unix_time 2300000
>
> Seems to document a wrong syntax (seems to be inconsistent to code).
>
> > : uses: DAY_OF_WEEK
>
> Already quite obvious.
> >
> > echo ${DAY_OF_WEEK[( ( ($1+($1<0?1:0))/(24*60*60))%7 +($1<0?6:7))%7]}
> > }
> >
> I'd probably write (using ksh syntax here, but similar for bash)
>
> function get_day_in_week
> {
> typeset -i unix_time=${1:?}
>
> printf "%s\n" ${DAY_OF_WEEK[ $(( unix_time + ... )) ]
> }
>
> and omit the unnecessary comments, add a variable for legibility and
> safety (i.e. the test on $1), use arithmetic syntax for clarity, and
> standard (and generally safer) printf.
>
> > [...]
>
> Mileages vary.
>
> Janis
> >
> >
> > On Wednesday, November 30, 2022 at 1:01:27 AM UTC-5, castAway wrote:
> >> [...]

On 05.12.2022 00:50, applemcg wrote:
>
> thanks also for pointing out the performance hit isn't to severe

Note that the side effects on ':' lines may be severe, as demonstrated.

Why don't you use comments for that purpose? I mean, other languages
seem to have done so, and if there's some need for "special comments"
you can build on the existing ones, like using '#>' (instead of '#')
so that you anticipate effects of ':' side-effects and special care.

>
> but let me object to the use of "bloat"
>
> i'm working on an idea, where the shell source text, the stuff you
> put in source control, has the "unnecessary bloat", and you've
> given be a terrific idea.
>
> i've library, "shdoclib" which mangles shell function text. the
> syntax you're looking at is a feature i call "tags"

This is nothing new you are explaining here. These things are supported
by (quasi-standard) tools like eg. javadoc that I used in my Java times,
and before that, three decades ago, I defined standard document headers
(for e.g. C++ and Kornshell) with tags that were used company-wide then.

If all you want is (user-defined, programmer-defined) tags just do it;
I understand and acknowledge that.
Although nowadays I'd most likely use some standard tool - unless my
requirements would be so trivial that some own solution would appear
more appealing (e.g. to avoid overhead/dependencies on external tools).

I was referring to the unnecessary comments that are widely depreciated
(AFAICT).

Typical examples are; repetitions of existing functional information
function get_day_in_week # get day in week
having information at the "wrong" place and requiring searches/lookups
function f # function f is returning the day in week
typeset a # used to store area of rectangle
(( a = $1 * $2 )) # width * height
documenting unnecessary information like language explanations
pi=3.14 # we assign value of 'pi' for more terse usage
and some more.

You've demonstrated my point already that inconsistencies may slip in
if you duplicate code (or things that belong to code) in comments.

> [...]

>
> Now, to solve your "unnecessary bloat" problem, I'm already keeping a
> duplicate copy of every function library around, so, with a little
> care, the one which i execute will be run thru a yet-to-be-written
> "just_nocolon" function, a complement of this "shd_justcolon" function:

You are keeping a copy? And need some care doing something? Finally
create a non-colon function? - Seems I miss the advantage of doing
all that. Anyway.

Note: there's nothing wrong if you have the need for that, for tags.
We are probably just speaking about different things. While you seem
to have advertised your tag-based commenting for your purposes I was
just providing a mundane alternative for writing shell code with IMO
less maintenance issues.

For standard documentation and it's extraction I use the existing
operational language features to express things. For everything
beyond that I add use (preferred standard) tools that support that.
Additional necessary comments to understand things not expressed
by the language, nor by the use of proper names and identifiers.

My experience with tags is that you need QA measures to keep them
true, consistent, sufficiently complete, and generally useful.

Janis

On 12/4/22 20:50, applemcg wrote:

the exec time may not be affected by running the : command however
painful debug prints this command expansion, with set -xv for eg

On 12/4/22 20:50, applemcg wrote:
> somefunction ()
> {
> : "the first null command is the function's abstract"
> : here quoted to protect the " ' " character
> : after the shdoc, which are the first untagged-lines of the function, come the tags,
> : such as the next line
> : date: 2016-06-06, the first time we stored this in a library
> : ... etc ...
> : date: 2022-12-04, the most recent modification
> ... # followed by the body of the function
> ...
> }

all the : forward code is unnecessary and will be printed on debugging

also, i don't care about comments of the source code if the
reference can be trusted blindly

On 05.12.2022 05:42, castAway wrote:
> On 12/4/22 20:50, applemcg wrote:
>> somefunction ()
>> {
>> : "the first null command is the function's abstract"
>> : here quoted to protect the " ' " character
>> : after the shdoc, which are the first untagged-lines of the
>> function, come the tags,
>> : such as the next line
>> : date: 2016-06-06, the first time we stored this in a library
>> : ... etc ...
>> : date: 2022-12-04, the most recent modification
>> ... # followed by the body of the function
>> ...
>> }
>
> all the : forward code is unnecessary and will be printed on debugging
>
> also, i don't care about comments of the source code if the
> reference can be trusted blindly

I may have a different opinion on blind trust, but now that I see this
comment piece above isolated I get the impression that at least the
'date:' stuff looks very much like configuration management / version
control stuff that is usually managed outside of source code files
(with the check-in process by the respective tools).

Janis

On Friday, November 11, 2022 at 11:04:19 AM UTC-6, Janis Papanagnou wrote:
> On 11.11.2022 17:36, Janis Papanagnou wrote:
> > On 11.11.2022 04:34, castAway wrote:
> >> On 11/10/22 21:46, Janis Papanagnou wrote:
> >>> What does the script that AT&T date or GNU date doesn't support in this
> >>> (time-intervals) respect?
> >>
> >> I am not sure that `awk' or `date' can be used to calculate time intervals
> >> other than in days, hours, minutes and seconds. So how can you calculate
> >> these time differences with awk? You could get to an _approximate_ result
> >> very easily but it gets more difficult as we need to compensate for a lot
> >> of things, for example not all months have 4 weeks.
> >
> > [...]
>
> On re-reading it occurred to me that you were probably not focusing
> on the sub-second issue but on support for dates before, say, 1900 or
> after 2100, or so. - Yes, Unix tools have different (often restricted)
> support for dates outside the Unix Epoch. - So, yes, depending on the
> used tool you'd have to transform the external form to an internal
> representation that fits this accuracy.
>
> Janis