Real data for a change in the assignment operators and Bounded_String discussions.

Real data for a change in the assignment operators and Bounded_String discussions.

[Robert I. Eachus]

"Mr. Wideman" <mrwideman@insightbb.com> posted the following message to
sci.crypt.random-numbers, which has nothing to do with solving secret 
messages but generating secure random number sequences:

========================================================================

(Maybe related to primes or the magic hexagon - also the result will
be in English using the 26 letter alphabet)

1713167174342128171514138189312
3328481316215188174182917819139
9198181712743151518167123321815
3419371816421839151471821218332
8415137933719383167187431713719
2991771571431333719341915183337
13719

=========================================================================

There are no zeros and lots of ones.  I thought that it might be a 
system like the one used by Col. Abel that had one and two digit 
sequences.  So I wrote a quick program (less than 4 hours, including 
dinner and a break to watch the fireworks from the back steps. ;-) to 
print out some statistics:

count_digits message.txt

   There were 191 digits.

   0=  0  1= 58  2= 14  3= 32  4= 13  5=  9  6=  5  7= 23  8= 21  9= 16

  00=  0 01=  0 02=  0 03=  0 04=  0 05=  0 06=  0 07=  0 08=  0 09=  0
  10=  0 11=  0 12=  5 13=  8 14=  3 15=  9 16=  5 17=  8 18= 12 19=  8
  20=  0 21=  6 22=  0 23=  2 24=  0 25=  0 26=  0 27=  1 28=  3 29=  2
  30=  0 31=  7 32=  3 33=  8 34=  3 35=  0 36=  0 37=  7 38=  2 39=  2
  40=  0 41=  5 42=  2 43=  4 44=  0 45=  0 46=  0 47=  1 48=  1 49=  0
  50=  0 51=  7 52=  0 53=  1 54=  0 55=  0 56=  0 57=  1 58=  0 59=  0
  60=  0 61=  0 62=  1 63=  0 64=  1 65=  0 66=  0 67=  3 68=  0 69=  0
  70=  0 71= 16 72=  0 73=  0 74=  4 75=  0 76=  0 77=  1 78=  1 79=  1
  80=  0 81= 10 82=  2 83=  4 84=  2 85=  0 86=  0 87=  1 88=  1 89=  1
  90=  0 91=  6 92=  1 93=  5 94=  0 95=  0 96=  0 97=  0 98=  1 99=  2

The fact that 1 never follows 1 even though it it the most frequent 
letter seems very suspicious, so I'll probably work back and forth to 
come up with 1 and 2 digit representations that make sense, then try to 
solve it as a simple substitution.  If my assumptions are right there 
should be at least a hundred characters, which should be plenty.

But I wanted to talk about the Ada program I wrote:

-----------------------------------------------------------------------------------------

with Ada.Text_IO;
with Ada.Command_Line;
procedure Count_Digits is -- A program to count the digits and digit
                   -- pairs in a string.  Other charaters are ignored.
   function Get_Data return String is
     use Ada.Text_IO;
     use Ada.Command_Line;
     Input_File: File_Type;

     function Recur return String is
       Buffer: String(1..80);
       Last_Char: Integer;
     begin
       Get_Line(Input_File,Buffer,Last_Char);
       if End_Of_File(Input_File)
       then return Buffer(1..Last_Char);
       else return Buffer(1..Last_Char) & Recur;
       end if;
     end Recur;

   begin
     Open(Input_File,In_File,Argument(1));
     return Recur;
     Close(Input_File);
   end Get_Data;

   procedure Inc (Counter: in out Integer);
   pragma Inline(Inc);

   procedure Inc (Counter: in out Integer) is
   begin Counter := Counter + 1; end Inc;

   Data: String := Get_Data;
   Total: Integer;
   Previous: Character;
   Single: array(Character range '0'..'9') of Integer := (others => 0);
   Digraphs: array(Character range '0'..'9',
      Character range '0'..'9') of Integer := (others => (others => 0));
   Start: Integer := Data'First;

   procedure Print_Data is
     use Ada.Text_IO;
     use Ada.Command_Line;
     Output_File: File_Type;
     package Int_IO is new Integer_IO(Integer);
   begin
     if Argument_Count > 1 then
       Open(Output_File, Out_File, Argument(2));
       Set_Output(Output_File);
     end if;
     New_Line;
     Put_Line("  There were" & Integer'Image(Total) & " digits.");
     New_Line;
     for I in Character range '0'..'9' loop
       Put( "  " & I & '=');
       Int_IO.Put(Single(I),3);
     end loop;
     New_Line(2);

     for I in Character range '0'..'9' loop
       for J in Character range '0'..'9' loop
         Put( ' ' & I & J & '=');
         Int_IO.Put(Digraphs(I,J),3);
       end loop;
       New_Line;
     end loop;
     New_Line;

     if Is_Open(Output_File)
     then
       Set_Output(Standard_Output);
       Close(Output_File);
     end if;
   end Print_Data;

begin

   -- seed Digraph counting...
   while Data(Start) not in '0'..'9' loop
     Start := Start + 1;
   end loop;
   Total := 1; -- first character found
   Previous := Data(Start);
   Inc(Single(Data(Start)));

   -- main loop
   for I in Start+1.. Data'Last loop
     if Data(I) in '0'..'9'
     then
       Inc(Total);
       Inc(Single(Data(I)));
       Inc(Digraphs(Previous,Data(I)));
       Previous := Data(I);
     end if;
   end loop;

   Print_Data;

end Count_Digits;

----------------------------------------------------------------------------------------------

First, let me get deal with the Bounded_String argument.  This program 
is the sort of program whene some people think that Bounded_String is 
needed.  I probably would have used a line at a time loop if I expected 
to deal with hundreds of lines of input.  But as you can see, I read all 
the text data recursively, then splice it together into one String 
return VALUE.  Which goes here:

   Data: String := Get_Data;

The recursive function that does the splicing of lines is ten lines 
long.  Note that if a line is longer than 80 characters, Recur will read 
it in more than one bite.  But I don't have to worry about the layout of 
the input data.  (Just whether the counts will get too high and mess up 
my neat output formatting.)  You just CANNOT code like this in C or many 
other languages.  (I can imagine trying to write that code in C, with 
mallocs, frees, searches for nul (strlen) and copies all over the place. 
  Ouch!)  End of Bounded_String discussion.

Now onto the assignment operators.  At first I thought this code would 
be a poster child for the idem proposal.  But it was worth it to me to 
write:

   procedure Inc (Counter: in out Integer);
   pragma Inline(Inc);

   procedure Inc (Counter: in out Integer) is
   begin Counter := Counter + 1; end Inc;

I probably could have written the Inc operation as a one-liner and left 
off the declaration and the pragma Inline(Inc); but it was easier to 
write it than to figure out if it was worth the effort.  As you can see 
from the formatting, I definitely belong to the "if the code is 
unreadable it is wrong" school.  The same goes for the pragma Inline in 
this case--it was easier to put it in than justify leaving it out.

I also could have had pragma Inline for Get_Data and Print_Data, but my 
style is to leave out pragma Inline for procedures or functions that are 
called once and let the compiler figure it out.  Of course, a pragma 
Inline for Recur would be unlikely to accomplish much.  The same 
argument applies to closing the Input_File and Output_File.  It is not 
really needed, but it documents that I am finished using them.

Should Inc be predefined as a procudure?  (In addition to as an 
attribute function.)  No.  It is clearly easier to declare the version 
of Inc that I want, than to remember where it is defined, what the 
parameters are and so on.  And I certainly don't want to discuss that in 
ARG or WG9 meetings for something where the desired functionality fits 
in one line.

I don't expect this to end the discussion on these two issues, but I 
hope it helps.  The three calls in a row to Inc are much clearer than:

       Total := Total + 1;
       Single(Data(I)) := Single(Data(I)) + 1;
       Digraphs(Previous,Data(I))) := Digraphs(Previous,Data(I)) + 1;

But part of what makes it much clearer is having the definition of Inc 
right there.  And certainly any argument that

       Total +:= 1;  -- or perhaps
       Total := idem + 1; -- or whatever

is "better" than:

       Inc(Total);

is crazy.  If you count characters, the line with the fancy new operator 
is one character longer. Not that this is an APL contest to do something 
with the fewest characters.  The real win is that the procedure call has 
fewer parts to understand: a procedure call with one parameter, and 
requires no language extensions.

-- 

                                                   Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Inc (was: Real data for a change in the assignment operators and Bounded_String discussions. )

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>Should Inc be predefined as a procudure?  (In addition to as an
>attribute function.)  No.  It is clearly easier to declare the version
>of Inc that I want, than to remember where it is defined, what the
>parameters are and so on.  And I certainly don't want to discuss that in
>ARG or WG9 meetings for something where the desired functionality fits
>in one line.

That's all fine, it would be sufficient to establish Standard Minimal
Requirements for Ada (2005) textbooks, and require them to explain usefulness
of Inc procedure -:)

>I don't expect this to end the discussion on these two issues, but I
>hope it helps.  The three calls in a row to Inc are much clearer than:
>
>       Total := Total + 1;
>       Single(Data(I)) := Single(Data(I)) + 1;
>       Digraphs(Previous,Data(I))) := Digraphs(Previous,Data(I)) + 1;

I think Pascal language was aware of that even before Ada emerged.

>But part of what makes it much clearer is having the definition of Inc
>right there.  And certainly any argument that
>
>       Total +:= 1;  -- or perhaps
>       Total := idem + 1; -- or whatever
>
>is "better" than:
>
>       Inc(Total);
>
>is crazy.

Certainly, Inc is much better here. But "idem" feature is not aimed for this case,
it is for more complex formulae where cant'be anything so simple and universal
like Inc.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Real data for a change in the assignment operators and Bounded_String discussions.

[Hyman Rosen]

Robert I. Eachus wrote:
>     Open(Input_File,In_File,Argument(1));
>     return Recur;
>     Close(Input_File);

What's this? Does Ada come with a delay slot?

 > You just CANNOT code like this in C or many other languages.

True.

> (I can imagine trying to write that code in C, with  mallocs, frees,
 > searches for nul (strlen) and copies all over the place. Ouch!)

Well, let's see (error checking left out):
     char *first_line_of_file(char *file_name)
     {
         int nread = 0, capacity = 0, c;
         char *buf = 0;
         FILE *f = fopen(file_name, "r");
	while ((c = fgetc(f)) != EOF && c != '\n')
         {
             if (nread >= capacity)
                  buf = realloc(buf, capacity += 80);
             buf[nread++] = c;
         }
         fclose(f);
         if (nread >= capacity)
             buf = realloc(buf, capacity + 1);
         buf[nread] = 0;
         return realloc(buf, nread + 1);
     }

I suggest your imagination was unequal to the task. And in C++,
the whole thing is a single call to std::getline.

> I don't expect this to end the discussion on these two issues, but I 
> hope it helps.  The three calls in a row to Inc are much clearer than:

But you have cheated, by having all three lines increment an Integer.
Ada not being C, there are a proliferation of user-defined types that
all need incrementing, so soon the code is crawling with simple little
Inc and Dec procedures. The idea behind having special assignment
operators (or idem) is precisely to avod having to write these little
procedures for every such type.

Re: Real data for a change in the assignment operators and Bounded_String discussions.

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: 
:> (I can imagine trying to write that code in C, with  mallocs, frees,
: > searches for nul (strlen) and copies all over the place. Ouch!)
: 
: Well, let's see (error checking left out):

Indeed ;-)

The program has a leak.  Adding

int main()
{
  /* make sure this file exists, otherwise you might get
     a segmentation fault */

  char* TEST_FILE = "test.file";
  char* _1st_line = 0;

  while (1)
    _1st_line = first_line_of_file(TEST_FILE);
  fputs(_1st_line, stdout);
}

and a few "(char*)realloc(...)" to first_line_of_file().

georg@strudel:/tmp$   gcc -o whole whole.c
georg@strudel:/tmp$   ls -l test.file
-rw-r--r--    1 georg    staff           0 Jul  7 10:24 test.file
georg@strudel:/tmp$   ./whole

Re: Real data for a change in the assignment operators and Bounded_String discussions.

[Georg Bauhaus]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote:
And the final message is:

: georg@strudel:/tmp$   ./whole
Killed
georg@strudel:/tmp$ 

after a few minutes and total exhaustion of physical memory
and swap space. Another interesting C program :-)

Re: Real data for a change in the assignment operators and Bounded_String discussions.

[Hyman Rosen]

Georg Bauhaus wrote:
> : Well, let's see (error checking left out):
> Indeed ;-)

The Ada program didn't check for sucessful file opens,
and didn't check for Storage_Error, so I did the same
in my C code.

> The program has a leak.

Your program has a leak. The C version necessarily
differs from the Ada version in that it must allocate
memory on the heap, so the returned pointer must be
freed by the caller.

>   while (1)
>     _1st_line = first_line_of_file(TEST_FILE);
>   fputs(_1st_line, stdout);

Instead,
     while (1)
     {
         _1st_line = first_line_of_file(TEST_FILE);
         fputs(_1st_line, stdout);
         free(_1st_line);
     }

> and a few "(char*)realloc(...)" to first_line_of_file().

Unnecessary in C code, provided you include the correct
header file. Realloc returns a void*, which in C converts
to any other pointer without a cast.

Re: Real data for a change in the assignment operators and Bounded_String discussions.

[Hyman Rosen]

Georg Bauhaus wrote:
> after a few minutes and total exhaustion of physical memory
> and swap space. Another interesting C program :-)

Well, it was your code that did that, not mine.
And this is plain C we're talking about. In C++,
the whole thing is just

     #include <fstream>
     #include <iostream>
     #include <ostream>
     #include <string>
     int main()
     {
         while (1)
         {
             std::ifstream f("test.file");
             std::string s;
             if (std::getline(f, s))
                 std::cout << s << '\n';
         }
     }

Re: Real data for a change in the assignment operators and Bounded_String discussions.

[Robert I. Eachus]

Georg Bauhaus wrote:
> And the final message is:
> 
> : georg@strudel:/tmp$   ./whole
> Killed
> georg@strudel:/tmp$ 
> 
> after a few minutes and total exhaustion of physical memory
> and swap space. Another interesting C program :-)

Don't lose any sleep over this.  The only "debugging" I did on the Ada 
version was to add a couple of New_Line calls, and remove a couple of 
blanks from the Put calls to make the output look prettier.  And that is 
sort of the point. If I hadn't been "publishing" the code, I wouldn't 
have even done that, just used the results and gone on.  In Ada, I could 
do some pretty fancy string manipulation in "throwaway" code just to 
make the overall program simpler.

I am sure I could debug my way through to a working version of a similar 
C program.  But I certainly wouldn't try to do it with the same style of 
pasting string sections together from long and unhappy experience.  In C 
(and C++) I'd much rather write the program to work on one line of input 
at a time, with only one (malloced) buffer.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Real data for a change in the assignment operators and Bounded_String discussions.

[Robert I. Eachus]

Hyman Rosen wrote:

> Instead,
>     while (1)
>     {
>         _1st_line = first_line_of_file(TEST_FILE);
>         fputs(_1st_line, stdout);
>         free(_1st_line);
>     }
...

I originally posted a working Ada program, with output.  Would you care 
to do the same for your C and/or C++ versions?  This particular fragment 
will read a line from TEST_FILE and print it forever, at least as far as 
I can see.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Real data for a change in the assignment operators and Bounded_String discussions.

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> after a few minutes and total exhaustion of physical memory
:> and swap space. Another interesting C program :-)
: 
: Well, it was your code that did that, not mine.

Uhm, it uses but your function, which allocates an extra
character for empty input, if I'm not mistaken?

: And this is plain C we're talking about.

Yes.

Re: Real data for a change in the assignment operators and Bounded_String discussions.

[Hyman Rosen]

Robert I. Eachus wrote:
> I originally posted a working Ada program, with output.  Would you care 
> to do the same for your C and/or C++ versions?

Sorry about that. I read your code too hastily and misinterpreted
what it was doing. Here we go -

#include <fstream>
#include <iostream>
#include <iterator>
#include <vector>
#include <iomanip>
#include <ctype.h>

template <typename In, typename Out, typename Pred>
Out copy_if(In b, In e, Out o, Pred p)
{
     for (; b != e; ++b)
         if (p(*b))
             *o++ = *b;
     return o;
}

void process(std::istream &in, std::ostream &out)
{
     typedef std::vector<char> buf_type;
     buf_type buf;
     copy_if(std::istream_iterator<char>(in),
             std::istream_iterator<char>(),
             std::back_inserter(buf),
             isdigit);
     buf_type::iterator b = buf.begin(), e = buf.end();
     unsigned long c1d[10] = { 0 }, c2d[10][10] = { 0 };
     out << "There were " << buf.size() << " digits.\n\n";
     while (b != e)
     {
         char d = *b++ - '0';
         ++c1d[d];
         if (b != e)
             ++c2d[d][*b - '0'];
     }
     for (int i = 0; i < 10; ++i)
         out << i << "=" << std::setw(3) << c1d[i] << " ";
     out << "\n\n";
     for (int j = 0; j < 10; ++j)
     {
         for (int i = 0; i < 10; ++i)
             out << j << i << "=" << std::setw(3) << c2d[j][i] << " ";
         out << "\n";
     }
}

int main(int c, char **v)
{
     std::ifstream is;
     if (c > 1) is.open(v[1]);
     std::ofstream os;
     if (c > 2) os.open(v[2]);
     process(is.is_open() ? is : std::cin,
             os.is_open() ? os : std::cout);
}

Re: Real data for a change in the assignment operators and Bounded_String discussions.

[Hyman Rosen]

Georg Bauhaus wrote:
> Uhm, it uses but your function, which allocates an extra
> character for empty input, if I'm not mistaken?

It alwyas allocates one extra character for a null terminator,
so that the result is a standard C string. Anyway, I've now
posted the entire original program rewritten in C++, so we
should probably move on to arguing about that one :-) (It
turned out that I had misread the original Ada code, thinking
that it wanted to read just one line instead of sucking up the
entire file.)

Re: Inc (was: Real data for a change in the assignment operators and Bounded_String discussions. )

[Gautier Write-only]

> >I don't expect this to end the discussion on these two issues, but I
> >hope it helps.  The three calls in a row to Inc are much clearer than:
> >
> >       Total := Total + 1;
> >       Single(Data(I)) := Single(Data(I)) + 1;
> >       Digraphs(Previous,Data(I))) := Digraphs(Previous,Data(I)) + 1;

Alexander Kopilovitch:

> I think Pascal language was aware of that even before Ada emerged.

You certainly think to Borland Pascal. Yes, it was a good idea from them.
(Standard) Pascal has only "Succ" and "Pred".

Applied to different contexts, both the "Inc" and the "idem" ideas would be
useful for making programs readable and catch errors. In the example
above, "Inc" is obviously the best.

For "Inc", why not let the programmer define the procedure, the standard
ensuring an "Intrinsic" pragma like for the Shift_Right function ?
A set of "Inc", "Dec" (all scalar or floating types),
"Add", "Sub", "Mul", "Div" (all numeric) would be nice.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Inc (was: Real data for a change in the assignment operators and

[Larry Kilgallen]

In article <3F09E6B8.FB19B956@somewhere.nil>, Gautier Write-only <gautier@somewhere.nil> writes:
>> >I don't expect this to end the discussion on these two issues, but I
>> >hope it helps.  The three calls in a row to Inc are much clearer than:
>> >
>> >       Total := Total + 1;
>> >       Single(Data(I)) := Single(Data(I)) + 1;
>> >       Digraphs(Previous,Data(I))) := Digraphs(Previous,Data(I)) + 1;
> 
> Alexander Kopilovitch:
> 
>> I think Pascal language was aware of that even before Ada emerged.
> 
> You certainly think to Borland Pascal. Yes, it was a good idea from them.
> (Standard) Pascal has only "Succ" and "Pred".

I was under the impression the reference was to the Pascal WITH keyword,
which is quite familiar to me although I have never used Borland Pascal.

Re: Inc (was: Real data for a change in the assignment operators and Bounded_String discussions. )

[Vinzent Hoefler]

Gautier Write-only wrote:

[Inc]
>You certainly think to Borland Pascal. Yes, it was a good idea from them.
>(Standard) Pascal has only "Succ" and "Pred".

Yes, but note the slight semantic difference there: Inc and Dec don't
come with range checks.


Vinzent.

Re: Inc (was: Real data for a change in the assignment operators and

[Gautier Write-only]

> > You certainly think to Borland Pascal. Yes, it was a good idea from them.
> > (Standard) Pascal has only "Succ" and "Pred".

Larry Kilgallen:

> I was under the impression the reference was to the Pascal WITH keyword,
> which is quite familiar to me although I have never used Borland Pascal.

Maybe (Alexander ?). But Pascal's WITH works only for simplifying
a record selection, it can nothing with an array selection like
Digraphs[Previous,Data[I]].
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Inc (was: Real data for a change in the assignment operators and Bounded_String discussions. )

[Gautier Write-only]

> [Inc]
> >You certainly think to Borland Pascal. Yes, it was a good idea from them.
> >(Standard) Pascal has only "Succ" and "Pred".

Vinzent Hoefler:
> Yes, but note the slight semantic difference there: Inc and Dec don't
> come with range checks.

Interesting. Of course the Ada implementation would follow the
"natural" rule: range check (according to the type), unless suppressed.
Maybe a precision for readers without too much exposure to Pascal:
"Succ" and "Pred" are functions (x:= Succ(x)) like the eponym Ada attributes.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Inc (was: Real data for a change in the assignment operators and

[Alexander Kopilovitch]

Larry Kilgallen wrote:

>In article <3F09E6B8.FB19B956@somewhere.nil>, Gautier Write-only
<gautier@somewhere.nil> writes:
>>> >I don't expect this to end the discussion on these two issues,
but I
>>> >hope it helps.  The three calls in a row to Inc are much clearer
than:
>>> >
>>> >       Total := Total + 1;
>>> >       Single(Data(I)) := Single(Data(I)) + 1;
>>> >       Digraphs(Previous,Data(I))) := Digraphs(Previous,Data(I))
+ 1;
>>
>> Alexander Kopilovitch:
>>
>>> I think Pascal language was aware of that even before Ada emerged.
>>
>> You certainly think to Borland Pascal. Yes, it was a good idea from
them.
>> (Standard) Pascal has only "Succ" and "Pred".
>
>I was under the impression the reference was to the Pascal WITH
keyword,

No, I meant Inc (otherwise why I created new Subject line with this
name? -:)

(And yes, I thought about Borland Pascal... original Pascal brought
too much
sense to the famous phrase: "real programmers don't use Pascal" -:)



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia