Re: jot: producing too much output?

2023-01-09 Thread Martin Neitzel
> | The name jot derives in part from iota, a function in APL.
>
> Maybe somebody(tm) should look that up.

That's certainly the case.  The other two tools of Kunze's
tool bundle derive from APL, too:  rs(1) and lam(1) ("reshape"
and "laminate").

Martin  (APL back then as now)


Re: jot: producing too much output?

2023-01-07 Thread Robert Elz
Date:Fri, 6 Jan 2023 22:07:48 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:  

  | The original code (see rev 1.1) seems to be more clear on how
  | the parameters should be evaluated.

Yes, but that's even more counter-intuitive than our existing version.
In that, when just begin and end are specified, it first defaults reps
to 100, then calculates the step size so that 100 values fit between
the begin and end specified.   That's why in Mouse's case (what was
reported for the ancient code) some characters were repeated (when
doing -c) as the step size would be 0.95 (maybe 0.96, those details tend
to be beyond my immediate capacity to calculate) rather than 1, so when
converted to integers, every now and then the same value is produced as
last time  (I bet there are really 4, 5, or 6 duplicate chars (one of
those...), not just first and last).

We can easily go back to that if anyone thinks it is a good idea (this
seems to have changed as an unexplained side effect of rev 1.21 in 2008,
or at least I can't see any explicit mention of the alteration), we could
leave things as they are now, or we could kind of have the half way in
between approach, where begin and end are both used (as in 1.1) but where
we assume a step of 1 (or -1 if decreasing) rather than forcing 100 values
in that case.


mo...@rodents-montreal.org said:
  | Arguably the right thing to do here is to do the analog of what that
  | version does and list all 16 possible combinations of START, REPS,
  | ENDER, and STEP, with explicit code for each.

The technique used to write the code is about the least important detail,
what matters more is just what the "explicit code" should do in the cases
which aren't obvious.

And yes, the code as it exists now does correspond to the current man page,
but man pages tend to be written (and changed) after the code, and simply
reflect what happens, rather than what's supposed to happen.

One can also read our man page to imply the 1.1 semantics.

kre



Re: jot: producing too much output?

2023-01-06 Thread Mouse
>> [...jot...]
> The original code (see rev 1.1) seems to be more clear on how the
> parameters should be evaluated.

Yes.  Arguably the right thing to do here is to do the analog of what
that version does and list all 16 possible combinations of START, REPS,
ENDER, and STEP, with explicit code for each.

But then, the jot NetBSD already has conforms precisely to its spec.
Perhaps this could be viewed as a bug in the spec.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Re: jot: producing too much output?

2023-01-06 Thread Michael van Elst
mo...@rodents-montreal.org (Mouse) writes:

>>> I'd tend to assume it is the code.

>Well, then, there never can be any such thing as a bug in jot.


The original code (see rev 1.1) seems to be more clear on how
the parameters should be evaluated.




Re: jot: producing too much output?

2023-01-06 Thread Mouse
>>> I'd do it myself except I don't know where to find an authoritative
>>> spec for jot.

>> I'd tend to assume it is the code.

Well, then, there never can be any such thing as a bug in jot.

I find that...dubious.

> Remark from the peanut gallery, after (again) reading this in jot(1):

> | The name jot derives in part from iota, a function in APL.

> Maybe somebody(tm) should look that up.  Or ask John A. Kunze.

I know enough APL to make some sense of that, and it's not very
informative here.

Caveat: my APL knowledge is relatively old.  But I suspect the jot
name's derivation is comparably old.  So, as I understand APL

There's an operator - pronounced "iota", because the usual glyph for it
is the lowercase Greek letter ι - which takes a scalar, let's call it
N, and returns a 1D array from 0 through N-1.  There is an APL
character which I'm not sure of the location of in non-APL-specific
fonts; it looks roughly like a degree sign moved down so its centre is
approximately where a centered-dot's centre would be.  It is pronounced
"jot".  I don't see how to get to jot(1)'s functionality from APL's
jot, but it is in some respects like APL's iota.

However, that doesn't help much here because APL's ι operator doesn't
have the issues under discussion here.  It takes exactly one argument;
in jot(1) terms, start is 0, step is 1, and the argument is reps, with
end being implicit in the other three.  If you want anything else, you
have to construct it from the vector ι returns.  For example, if you
want the vector 2.4 2.5 2.6 2.7 2.8 2.9, you would probably do
something like...well, I'm not sure I'm going to get the MIME right,
but I think 2.4+.1×ι6 is what you'd want.

APL ι does have dyadic semantics as well, but they're even less
relevant.  (Most briefly, XιY returns an array of the same shape as Y,
indicating where in X the elements of Y are first found.  If X is not
1D, I'm not sure what happens; I suspect it actually operates on ,X
instead of X as given, though it seems to me the most philosophically
APLish thing would be to add another dimension ρρX to the result and
return entire subscript vectors.)

I don't see any help in APL for figuring out what jot(1) should do.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Re: jot: producing too much output?

2023-01-06 Thread Robert Elz
Date:Fri, 6 Jan 2023 20:56:17 +0100
From:i...@netbsd.org
Message-ID:  

  | | The name jot derives in part from iota, a function in APL.
  | Maybe somebody(tm) should look that up.

It has been a long time since I did any APL programming, but
in that, the iota function simply generates a vector of integers
(it has a single operand) - it is more or less "seq N".  That
won't help us at all.

  | Or ask John A. Kunze.

That would be a better idea.   I might try that one, but not tonight.

kre



Re: jot: producing too much output?

2023-01-06 Thread is
On Thu, Jan 05, 2023 at 11:46:42PM +0700, Robert Elz wrote:
> Date:Thu, 5 Jan 2023 11:16:22 -0500 (EST)
> From:Mouse 

>   | I'd do it myself except I don't know where to find an
>   | authoritative spec for jot.
> 
> I'd tend to assume it is the code.

Remark from the peanut gallery, after (again) reading this 
in jot(1):

| The name jot derives in part from iota, a function in APL.

Maybe somebody(tm) should look that up. Or ask John A. Kunze.

-is



Re: jot: producing too much output?

2023-01-05 Thread Robert Elz
Date:Thu, 5 Jan 2023 11:16:22 -0500 (EST)
From:Mouse 
Message-ID:  <202301051616.laa11...@stone.rodents-montreal.org>

Answering your 2 recent messages backwards:

  | But I don't understand why the code isn't instead something more
  | like
  |
  | if (! (have & REPS)) reps = 100;
  | if (! (have & BEGIN)) begin = 1;
  | if (! (have & ENDER)) ender = 100;
  | if (! (have & STEP)) step = 1;
  | ...compute t and possibly reduce reps...

That wouldn't work for a usage like jot 2 - 20 5  (which should output
15 and 20) as you set begin to 1 (it wasn't given) whereas it should be
calculated.

  | I am reminded of the aphorism that there are two ways to build a

Perhaps jot is trying to do too much, that's out of my pay grade to
decide, if you only need numbers, seq(1) has a simpler interface.

  | I'd do it myself except I don't know where to find an
  | authoritative spec for jot.

I'd tend to assume it is the code.

mo...@rodents-montreal.org said in the preceding message:
  | So I would expect "- 32 126" to behave like "100 32 126 1". And text which
  | you didn't quote says "If four [args] are specified and the given and
  | computed values of reps conflict, the lower value is used".

But as you said 4 values weren't specified, so that doesn't apply.
In practice, (ie: in the code) the end value is only ever used to
calculate missing other values, the actual output comes entirely
from begin, step, and reps.

  | Forcing users to compute the number of values they want when specifying
  | both begin and end strikes me as counterintuitive at best.

That's never been required, you could specify s (the step) instead, and
since in the cases you're interested in, that's just 1 that's kind of easy
to do.   With begin and and s (step) reps can be calculated (and is).

  | When jot didn't give I wanted, I wrote shell loop (
  |i=BEGIN; while [ $i -lt END ]; do BODY; i=$(($i + 1)); done
  | or something like it).

and in that you specified BEGIN END and step (as the constant 1).   If you
had done the same with jot, it would have done what you wanted, first time.

kre

ps: it would probably be -le rather than -lt to duplicate the meanings of
begin and end in jot.



Re: jot: producing too much output?

2023-01-05 Thread Mouse
> Actually, replace that last patch with this one.   The previous one
> wouldn't work if begin and end were the same value (intending to get
> just one output value) - though why anyone would write the args that
> way instead of just saying 1 reps begin at ... I cannot imagine.

Perhaps because the values weren't hand-specified but came from
somewhere automated in a script?  It's a bit like saying "why would
anyone run `cat /dev/null'".

Mouse


Re: jot: producing too much output?

2023-01-05 Thread Robert Elz
Actually, replace that last patch with this one.   The previous one
wouldn't work if begin and end were the same value (intending to get
just one output value) - though why anyone would write the args that
way instead of just saying 1 reps begin at ... I cannot imagine.

This patch doesn't have that defect however.

kre

Index: jot.c
===
RCS file: /cvsroot/src/usr.bin/jot/jot.c,v
retrieving revision 1.28
diff -u -r1.28 jot.c
--- jot.c   14 Jun 2020 01:26:46 -  1.28
+++ jot.c   5 Jan 2023 16:20:17 -
@@ -249,6 +249,9 @@
 
switch (have) {
 
+   case ENDER | BEGIN:
+   step = ender >= begin ? 1.0 : -1.0;
+   /* FALLTHROUGH */
case ENDER | STEP:
case ENDER | STEP | BEGIN:
/* Calculate reps */




Re: jot: producing too much output?

2023-01-05 Thread Mouse
> As an extra bonus, the appended patch causes jot to generate what
> you're expecting.

True.  But I don't understand why the code isn't instead something more
like

if (! (have & REPS)) reps = 100;
if (! (have & BEGIN)) begin = 1;
if (! (have & ENDER)) ender = 100;
if (! (have & STEP)) step = 1;
...compute t and possibly reduce reps...

I am reminded of the aphorism that there are two ways to build a
system: you can make it so complex that there are no obvious defects,
or you can make it so simple there are obviously no defects.  The code
there now strikes me as closer to the former.

At the very least I think someone who knows jot's actual spec should
check that all 16 possible values of have produce their correct
behaviours.  I'd do it myself except I don't know where to find an
authoritative spec for jot.  What seems obvious to me is apparently not
a reliable guide in this case.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Re: jot: producing too much output?

2023-01-05 Thread Mouse
>> jot -s "" - 32 126

>> Based on reading the manpage, I would expect that to produce a
>> single line 323334353637...124125126.  It does on my 1.4T.  On my
>> 5.2, ftp.n.o's 9.0_STABLE, and a work 9.1 machine, the line actually
>> ends ...125126127128129130131.

> The man page actually says:

>  If fewer than three [of the reps begin end & step args] are specified,
>  defaults are assigned left to right, except for s, which assumes its
>  default unless both begin and end are given.

Right.  So I would expect "- 32 126" to behave like "100 32 126 1".
And text which you didn't quote says "If four [args] are specified and
the given and computed values of reps conflict, the lower value is
used".  That is not directly applicable because only two values were
specified, but it does seem reasonable to me to expect the reps value
computed from the given begin and end and the defaulted step - meaning
95 in this case - to be used.  Forcing users to compute the number of
values they want when specifying both begin and end strikes me as
counterintuitive at best.

In any case, it's of mostly academic interest to me personally; I
normally use count(1), a program of my own that defaults in ways that
make more sense to me.  I just had occasion to want to generate
sequential data on a machine that didn't have my suite of utilities set
up, leading me to go looking.  When jot didn't give I wanted, I wrote
shell loop (i=BEGIN; while [ $i -lt END ]; do BODY; i=$(($i + 1)); done
or something like it).

But it did look to me as though jot wasn't behaving the way I thought
the manpage said it should, hence my mail.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Re: jot: producing too much output?

2023-01-05 Thread Robert Elz
As an extra bonus, the appended patch causes jot to generate what
you're expecting.   I'm not going to apply it however, without someone
who knows what jot is really intended to do in this situation indicates
that it is a reasonable thing to have happen (in which case it would also
need a man page update).

kre

Index: jot.c
===
RCS file: /cvsroot/src/usr.bin/jot/jot.c,v
retrieving revision 1.28
diff -u -r1.28 jot.c
--- jot.c   14 Jun 2020 01:26:46 -  1.28
+++ jot.c   5 Jan 2023 16:04:33 -
@@ -270,6 +270,9 @@
begin = ender - reps * step + step;
break;
 
+   case BEGIN | ENDER:
+   reps = fabs(ender - begin);
+   /* FALLTHROUGH */
case REPS | BEGIN | ENDER:
/* Calculate step */
if (reps == 0)




Re: jot: producing too much output?

2023-01-05 Thread Robert Elz
Date:Thu, 5 Jan 2023 09:52:06 -0500 (EST)
From:Mouse 
Message-ID:  <202301051452.jaa23...@stone.rodents-montreal.org>

  | jot -s "" - 32 126
  |
  | Based on reading the manpage, I would expect that to produce a single
  | line 323334353637...124125126.  It does on my 1.4T.  On my 5.2,
  | ftp.n.o's 9.0_STABLE, and a work 9.1 machine, the line actually ends
  | ...125126127128129130131.

The man page actually says:

 If fewer than three [of the reps begin end & step args] are specified,
 defaults are assigned left to right, except for s, which assumes its
 default unless both begin and end are given.

What actually happens, is that if only 2 args are given, unless one of them
is reps (and the other is begin or end) the only arg actually used is begin,
a default is assigned (left to right...) for reps, so the default (100) reps
is used (just like a simple "jot") - in your case that's 100 values,
from 32 .. 131.

Whether something different should be done when begin and end are given
(but neither reps nor step, so one would need to guess, at least one of
those) I don't know.

kre