Am 06.03.2022 um 22:17 schrieb Bart:
> On 06/03/2022 19:30, Manu Raju wrote:
>> On 06/03/2022 12:19, Bart wrote:
>>>
>>>
>>> I don't need to read any further. Just look at the difference between
>>> those two examples. I can easily follow the algorithm expressed as C,
>>> but I can'make out anything in the C++. Is there even an algorithm in
>>> that lot? All I can see is the last line that matches C's.
>>
>> A simple C program without any bells & whistles!!!!
>>
>> <====================================================================>
>> #include <math.h>
>> #include <stdio.h>
>> #include <time.h>
>> #include <stdlib.h>
>>
>> float calculateSD(float data[]);
>> int main()
>> {
>>     int i;
>>     srand(time(NULL));    float data[10];
>>     for (i = 0; i < 10; ++i)
>>     {
>>         data[i] = rand() % 99;
>>     }
>>     printf("The 10 numbers are: \n");
>>     for (int i = 0; i < 10; i++)
>>     {
>>         printf("%4.0f", data[i]);
>>     }
>>     printf("\nStandard Deviation = %.6f", calculateSD(data));
>>     return 0;
>> }
>>
>> float calculateSD(float data[])
>> {
>>     float sum = 0.0, mean, SD = 0.0;
>>     int i;
>>     for (i = 0; i < 10; ++i)
>>     {
>>         sum += data[i];
>>     }
>>     mean = sum / 10;
>>     for (i = 0; i < 10; ++i)
>>     {
>>         SD += pow(data[i] - mean, 2);
>>     }
>>     return sqrt(SD / 10);
>> }
>>
>> <====================================================================>
>
> This is a little /too/ simple. The size of the data should be a
> parameter to calculateSD(), otherwise it will only ever work for arrays
> of length 10.
>
> >     return sqrt(SD / 10);
>
> This should probably divide by 9 (or N-1 when done properly).

Lost your basics ?
When he iterates through 10 elements he should divide by 10.

On Sunday, 6 March 2022 at 21:20:24 UTC, Bonita Montero wrote:
> Am 06.03.2022 um 22:17 schrieb Bart:
> > On 06/03/2022 19:30, Manu Raju wrote:
> >> On 06/03/2022 12:19, Bart wrote:
> >>>
> >>>
> >>> I don't need to read any further. Just look at the difference between
> >>> those two examples. I can easily follow the algorithm expressed as C,
> >>> but I can'make out anything in the C++. Is there even an algorithm in
> >>> that lot? All I can see is the last line that matches C's.
> >>
> >> A simple C program without any bells & whistles!!!!
> >>
> >> <====================================================================>
> >> #include <math.h>
> >> #include <stdio.h>
> >> #include <time.h>
> >> #include <stdlib.h>
> >>
> >> float calculateSD(float data[]);
> >> int main()
> >> {
> >> int i;
> >> srand(time(NULL)); float data[10];
> >> for (i = 0; i < 10; ++i)
> >> {
> >> data[i] = rand() % 99;
> >> }
> >> printf("The 10 numbers are: \n");
> >> for (int i = 0; i < 10; i++)
> >> {
> >> printf("%4.0f", data[i]);
> >> }
> >> printf("\nStandard Deviation = %.6f", calculateSD(data));
> >> return 0;
> >> }
> >>
> >> float calculateSD(float data[])
> >> {
> >> float sum = 0.0, mean, SD = 0.0;
> >> int i;
> >> for (i = 0; i < 10; ++i)
> >> {
> >> sum += data[i];
> >> }
> >> mean = sum / 10;
> >> for (i = 0; i < 10; ++i)
> >> {
> >> SD += pow(data[i] - mean, 2);
> >> }
> >> return sqrt(SD / 10);
> >> }
> >>
> >> <====================================================================>
> >
> > This is a little /too/ simple. The size of the data should be a
> > parameter to calculateSD(), otherwise it will only ever work for arrays
> > of length 10.
> >
> > > return sqrt(SD / 10);
> >
> > This should probably divide by 9 (or N-1 when done properly).
> Lost your basics ?
> When he iterates through 10 elements he should divide by 10.
>
9 for sample deviation. If the data are a sample, you divide by N-1. If they
are a population, you divide by N.

On Sunday, 6 March 2022 at 20:23:18 UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Sunday, 6 March 2022 at 19:42:41 UTC, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >> > On Sunday, 6 March 2022 at 15:59:14 UTC, Ben Bacarisse wrote:
> >> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> >>
> >> >> > On Sunday, 6 March 2022 at 15:05:04 UTC, Ben Bacarisse wrote:
> >> >> >> Bart <b...@freeuk.com> writes:
> >> >> >>
> >> >> >> > That this is supposed to be generic is no excuse. Generic code should
> >> >> >> > not need to look much different from non-generic code. With dynamic
> >> >> >> > typing, it would be exactly the same source code**.
> >> >> >> >
> >> >> >> > According to the examples posted by David Brown, a generic version of
> >> >> >> > your the C function, written in C++, ought to look like this:
> >> >> >> >
> >> >> >> > double stddev(auto *x, int N) {...}
> >> >> >> double stddev(const auto *x, int N)
> >> >> >> {
> >> >> >> double sum = 0, sum_sq = 0;
> >> >> >> for (int i = 0; i < N; i++) {
> >> >> >> sum += x[i];
> >> >> >> sum_sq += x[i]*x[i];
> >> >> >> }
> >> >> >> return sqrt((sum_sq - sum*sum/N)/(N-1));
> >> >> >> }
> >> >> >> But then you then probably loose the automatic parallelisation that the
> >> >> >> standard library might give you.
> >> >> >> > x is a pointer to int, long long int, float or double. But I couldn't
> >> >> >> > get this to compile. If code needs to look like your C++, then it is a
> >> >> >> > failure IMO.
> >> >> >> The trouble is that the C++ code shown was intended to do more than the
> >> >> >> C, and not just in terms of handling generic types. Also, you can't
> >> >> >> judge C++ by a single example from one person. For example, I don't
> >> >> >> think
> >> >> >>
> >> >> >> double stddev(const auto &first, const auto &last)
> >> >> >> {
> >> >> >> double sum = std::accumulate(first, last);
> >> >> >> double sum_sq = std::accumulate(
> >> >> >> first, last, [](double sqs, double x){ return sqs + x*x; });
> >> >> >> double N = std::distance(first, last);
> >> >> >> return sqrt((sum_sq - sum*sum/N)/(N-1));
> >> >> >> }
> >> >> >>
> >> >> >> is particularly unclear.
> >> >> >>
> >> >> > Yes, but that's not generic. If first and last iterator over employees, the "+'
> >> >> > operator has to be defined to add two employees together. That's unlikely
> >> >> > to make any sort of sense.
> >> >> I think that's a good thing. Standard deviation is an arithmetic
> >> >> property.
> >> >> > In fact we'll want that standard deviation of the salaries. So we can pass
> >> >> > in a trivial little lambda [](Employee &employee){return
> >> >> > employee.salary;}
> >> >> I think you should use the ranges::view types to pass iterators to that
> >> >> data. Otherwise, every arithmetic operation has to acquire a little
> >> >> function to do the conversion, and the most common cases need a trivial
> >> >> function that does no more than the language does by default.
> >> >> > If we've not another variable associated with the employees, like hours
> >> >> > worked, we can get the standard deviation of that just by changing the
> >> >> > lambda.
> >> >> I think views can handle this just fine without complicating every
> >> >> arithmetic operation. But this is a classic example of why you should
> >> >> be posting where experts can reply -- I may be wrong.
> >> >> > reduce is better than accumulate because accumulate requires left-to
> >> >> > right evaluation of the operands. That's not necessary for a standard
> >> >> > deviation, unless annoyingly, we need every bit of precision (floating
> >> >> > point arithmetic isn't exactly associative, though it's near enough
> >> >> > for almost all purposes).
> >> >> Sure. You can just plug in reduce if you don't mid the risk of losing
> >> >> control over the order:
> >> >> double stddev(const auto &first, const auto &last)
> >> >> {
> >> >> double sum = std::reduce(first, last);
> >> >> double sum_sq = std::reduce(
> >> >> first, last, [](double sqs, double x){ return sqs + x*x; });
> >> >> double N = std::distance(first, last);
> >> >> return sqrt((sum_sq - sum*sum/N)/(N-1));
> >> >> }
> >> >>
> >> > This won't work. You want the sum of squares. But if you evaluate left
> >> > to right, the first element is not squared. That's easily fixed by
> >> > passing in an init.
> >> Thanks. I removed the 0 init from the accumulate version without
> >> thinking. But...
> >> > However if you use "reduce" instead of "accumulate" then the problem is
> >> > much more serious. Rndom pairs might not have the first operand
> >> > squared.
> >> Ah yes. The binary operator must be associative and commutative.
> >>
> >> > You must use reduce_transform.
> >>
> >> (transform_reduce)
> >>
> >> So I read the documentation (as I clearly should have done before!) and,
> >> unless I've messed up again, an even neater solution presents itself:
> >> double stddev(const auto &first, const auto &last)
> >> {
> >> double sum = std::reduce(first, last);
> >> double sum_sq = std::transform_reduce(first, last, first);
> >> double N = std::distance(first, last);
> >> return sqrt((sum_sq - sum*sum/N)/(N-1));
> >> }
> > That's a huge readability improvement.
> >>
> >> because std::transform_reduce(first, last, first) is essentially a
> >> parallel inner product of the sequence with itself. It's possible,
> >> given the prevalence of inner products, that this might be special-cased
> >> and particularly fast on some hardware.
> >>
> > I'm in two minds about this. Whilst it's good to know that inner products
> > are particularly fast, ina sense special-casing is a cheat. The idea is that
> > the transorm reduce paradigm can be widely used to construct a wide
> > varienty of functions. I chose stddev because it lends itself to this
> > approach.
> I would not write the code that way /because/ it might be special-cased.
> I would write it that way because it's, to me, clearer than using the
> long form with two functions.
>
> Maybe your objection is that the fact that
>
> std::transform_reduce(first, last, first)
>
> means
>
> std::transform_reduce(first, last, first, std::plus<>(), std::multiplies<>())
>
> is rather less than obvious? Maybe. But once you know what the three
> iterator version of reduce is doing, the defaults for the functions
> become obvious.
>
I'm looking for a technique that generalises to all sorts of applications,
including non-numerical ones. A fast special-cased dot product isn't what
I'm really after, though I understand that transform_reduce will probably
be used mainly for calculating dot products.

On 06/03/2022 20:07, Bonita Montero wrote:
> Am 06.03.2022 um 20:30 schrieb Manu Raju:
>> On 06/03/2022 12:19, Bart wrote:
>>>
>>>
>>> I don't need to read any further. Just look at the difference between
>>> those two examples. I can easily follow the algorithm expressed as C,
>>> but I can'make out anything in the C++. Is there even an algorithm in
>>> that lot? All I can see is the last line that matches C's.
>>
>> A simple C program without any bells & whistles!!!!
>>
>> <====================================================================>
>> #include <math.h>
>> #include <stdio.h>
>> #include <time.h>
>> #include <stdlib.h>
>>
>> float calculateSD(float data[]);
>> int main()
>> {
>>     int i;
>>     srand(time(NULL));    float data[10];
>>     for (i = 0; i < 10; ++i)
>>     {
>>         data[i] = rand() % 99;
>>     }
>>     printf("The 10 numbers are: \n");
>>     for (int i = 0; i < 10; i++)
>>     {
>>         printf("%4.0f", data[i]);
>>     }
>>     printf("\nStandard Deviation = %.6f", calculateSD(data));
>>     return 0;
>> }
>>
>> float calculateSD(float data[])
>> {
>>     float sum = 0.0, mean, SD = 0.0;
>>     int i;
>>     for (i = 0; i < 10; ++i)
>>     {
>>         sum += data[i];
>>     }
>>     mean = sum / 10;
>>     for (i = 0; i < 10; ++i)
>>     {
>>         SD += pow(data[i] - mean, 2);
>>     }
>>     return sqrt(SD / 10);
>> }
>
> Works only with float-arrays.
>
> This works with any input-iterable data that is
> convertible to double:
>
>
> template<typename Iterator>
>     requires std::is_convertible_v<typename
> std::iterator_traits<Iterator>::value_type, double> &&
> std::input_iterator<Iterator>
> double stddev( Iterator begin, Iterator end )
> {
>     using namespace std;
>     using T = typename iterator_traits<Iterator>::value_type;
>     ptrdiff_t n;
>     double mean = 0.0;
>     if constexpr( random_access_iterator<Iterator> )
>         n = std::distance( begin, end ),
>         for_each( begin, end, [&]( T &value ) { mean += (double)value;
> } );
>     else
>         n = 0,
>         for_each( begin, end, [&]( T &value ) { ++n; mean +=
> (double)value; } );
>     mean /= n;
>     double sqSum = 0.0;
>     for_each( begin, end, [&]( T &value ) { double diff = (double)value
> - mean; sqSum += diff * diff; } );
>     return sqrt( sqSum / n );
> }
>
> Magnitudes more flexible.
>

Even writing dedicated versions of the C for each of float, double, i32
and i64 is magnitudes more readable than this.

And also much easier to call. How do you even call your routine? I
couldn't figure it out.

Multiple versions in C can be done with macros. It's ungainly, but
/still/ simpler to follow than the C++:

#define FUNC(name, T) \
double name##T(T *x, int N)\
{\
int i;\
double mean = 0;\
double sumvar2 = 0;\
\
for (i =0; i < N; i++)\
mean += x[i];\
mean /= N;\
\
for (i =0; i < N; i++)\
sumvar2 += (x[i] - mean)*(x[i]-mean);\
\
return sqrt(sumvar2/(N-1));\
}

FUNC(stddev,float)
FUNC(stddev,double)
FUNC(stddev,int)
#define STDDEV(T,a,b) stddev##T(a,b)

Call using, for example:

sd = STDDEV(float, data, N);

Den 2022-03-06 skrev Ben Bacarisse <ben.usenet@bsb.me.uk>:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 06/03/2022 18:03, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 06/03/2022 16:36, Ben Bacarisse wrote:
>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>>
>>>>>>>> That this is supposed to be generic is no excuse. Generic code should
>>>>>>>> not need to look much different from non-generic code. With dynamic
>>>>>>>> typing, it would be exactly the same source code**.
>>>>>>>>
>>>>>>>> According to the examples posted by David Brown, a generic version of
>>>>>>>> your the C function, written in C++, ought to look like this:
>>>>>>>>
>>>>>>>> double stddev(auto *x, int N) {...}
>>>>>>>
>>>>>>> double stddev(const auto *x, int N)
>>>>>>> {
>>>>>>> double sum = 0, sum_sq = 0;
>>>>>>> for (int i = 0; i < N; i++) {
>>>>>>> sum += x[i];
>>>>>>> sum_sq += x[i]*x[i];
>>>>>>> }
>>>>>>> return sqrt((sum_sq - sum*sum/N)/(N-1));
>>>>>>> }
>>>>>>>
>>>>>>> But then you then probably loose the automatic parallelisation that the
>>>>>>> standard library might give you.
>>>>>>
>>>>>> Unless you're using one of the ubiquitous automatically vectorizing
>>>>>> compilers.
>>>>>
>>>>> Do they work well with type-generic code, given that they won't always
>>>>> know how + and * are defined?
>>>>
>>>> They know how + and * are defined when compiling the code - it's
>>>> compile-time polymorphism. Compilers can do exactly as much with such
>>>> templated (or implicitly templated with "auto") code as they can with
>>>> explicit types.
>>>
>>> But do they? If you include link-time with compile-time, sure the
>>> compiler knows what * is, but it's usually too late to change what the
>>> loop compiled to. Does the code generator write two forms and the
>>> linker picks one or the other when certain conditions are met?
>>>
>>> Or maybe I've missed your point altogether.
>>
>> When you use "auto" in a function declaration, it is just like a
>> template (indeed it /is/ a template, written with a shorter syntax).
>> Code is not generated for it at all until the compiler knows the type
>> being used, and the details of it. Of course, if the type is a class
>> with operators + and *, which are declared at the point of template
>> instantiation but defined externally, then the compiler won't be able to
>> do anything special with them.
>
> Your "of course" is exactly my point -- apparently what I was saying is
> obvious! Your "[t]hey know how + and * are defined when compiling the
> code" is either not always true, or, in the case of whole-program
> optimisation, not current enough to be much use.
>

I did some simple testing with clang. Using the C-style generic
function with auto, the entire loop is optimised away and the value is
computed at compile time when using a constant array of ints.
Inserting a simple custint class encapsulating the integers in a class
with custom operator* and operator+, the loop is not optimised away
and the operator functions are called during runtime.

Wouldn't this behaviour be the same calling into standard library
functions? They might be written to run in parallel, but they too
won't know about the implementation of the operators and shouldn't be
able to optimise any better than the loop.

To me, the question becomes one of choosing between a for-loop
implementation or calling one or more functions that could be
implemented using parallel algorithms. This is not a question of
optimisation, but one of picking an implementation.

You could do the same thing in C, without the C++ specific use of
auto, by calling implementations of accumulate, reduce, etc that may
or may not be written as parallel code.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Sunday, 6 March 2022 at 20:23:18 UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Sunday, 6 March 2022 at 19:42:41 UTC, Ben Bacarisse wrote:

>> >> So I read the documentation (as I clearly should have done before!) and,
>> >> unless I've messed up again, an even neater solution presents itself:
>> >> double stddev(const auto &first, const auto &last)
>> >> {
>> >> double sum = std::reduce(first, last);
>> >> double sum_sq = std::transform_reduce(first, last, first);

Correction: missing "init" argument.

>> >> double N = std::distance(first, last);
>> >> return sqrt((sum_sq - sum*sum/N)/(N-1));
>> >> }
>> > That's a huge readability improvement.
>> >>
>> >> because std::transform_reduce(first, last, first) is essentially a
>> >> parallel inner product of the sequence with itself. It's possible,
>> >> given the prevalence of inner products, that this might be special-cased
>> >> and particularly fast on some hardware.
>> >>
>> > I'm in two minds about this. Whilst it's good to know that inner products
>> > are particularly fast, ina sense special-casing is a cheat. The idea is that
>> > the transorm reduce paradigm can be widely used to construct a wide
>> > varienty of functions. I chose stddev because it lends itself to this
>> > approach.
>> I would not write the code that way /because/ it might be special-cased.
>> I would write it that way because it's, to me, clearer than using the
>> long form with two functions.
>>
>> Maybe your objection is that the fact that
>>
>> std::transform_reduce(first, last, first)
std::transform_reduce(first, last, first, 0.0)
>>
>> means
>>
>> std::transform_reduce(first, last, first, std::plus<>(), std::multiplies<>())
std::transform_reduce(first, last, first, 0.0,
std::plus<>(), std::multiplies<>())
>>
>> is rather less than obvious? Maybe. But once you know what the three
>> iterator version of reduce is doing, the defaults for the functions
>> become obvious.
>>
> I'm looking for a technique that generalises to all sorts of applications,
> including non-numerical ones. A fast special-cased dot product isn't what
> I'm really after, though I understand that transform_reduce will probably
> be used mainly for calculating dot products.

I'm confused. How can it being (possibly) fast be a problem for you?

In case you are referring back to the "I want to to work with salaries"
point, this is how I'd do that: (Forgive the simplistic struct, I don't
want too much extaneous noise.)

#include <numeric>
#include <cmath>

double stddev(const auto &first, const auto &last)
{
double sum = std::reduce(first, last);
double sum_sq = std::transform_reduce(first, last, first, 0.0);
double N = (double)std::distance(first, last);
return std::sqrt((sum_sq - sum*sum/N)/(N-1));
}

struct Employee {
int age;
double salary;
};

#include <iostream>
#include <ranges>

int main()
{
Employee employees[] = {
{42, 56000}, {22, 46000}, {58, 33000}, {30, 60000}
};

auto salary = [](const Employee &e){ return e.salary; };
auto salaries = employees | std::views::transform(salary);
std::cout << stddev(salaries.begin(), salaries.end()) << "\n";

auto age = [](const Employee &e){ return e.age; };
auto ages = employees | std::views::transform(age);
std::cout << stddev(ages.begin(), ages.end()) << "\n";
}

stddev should always be purely numeric. That's what it is.

--
Ben.

On 06/03/2022 20:07, Bonita Montero wrote:
>
> Works only with float-arrays.

Well that's how C language is unlike C++ or C#. In C# you can overload a
Method and/or use Object that can handle anything.

>
> This works with any input-iterable data that is
> convertible to double:

True but C is a very old language and some people like it. I don't. I an
a C# "lover"!!!!!!

>
>
>
>
> Magnitudes more flexible.
>
See this slightly revised prog but still most things hard-wired unlike
C# where we can use <List> or C++ <vector>. These are resizeable
"arrays" with more functions/Methods already supplied in the language.

<================================================================>

#include <stdio.h>
#include <math.h>

float stdev(float x[], int N);

int main()
{ � // test the function with an example array
� float arr[] = {19, 82, 48, 9, 17, 80, 3, 21, 67, 94};
� int N = sizeof arr / sizeof arr[0];
� float result = stdev(arr, N);
� printf("result: %lf\n", result);

� return 0;
}

// compute the standard deviation of elements in a array x with length N
// formula found here: https://en.wikipedia.org/wiki/Standard_deviation
float stdev(float x[], int N)
{ � // first compute the mean
� float mean = 0, total = 0;
� for (int i = 0; i < N; i++)
� {
� total += x[i];
� }
� mean = total / N;

� // compute the summation portion of the formula
� float sum = 0;
� for (int i = 0; i < N; i++)
� {
� sum += pow(x[i] - mean, 2);
� }

� // return the result of the final computation required
� return sqrt(sum / N);
} /*
result: 32.517689
*/

<================================================================>

On 06/03/2022 23:58, Manu Raju wrote:
> On 06/03/2022 20:07, Bonita Montero wrote:
>>
>> Works only with float-arrays.
>
> Well that's how C language is unlike C++ or C#. In C# you can overload a
> Method and/or use Object that can handle anything.
>
>
>>
>> This works with any input-iterable data that is
>> convertible to double:
>
> True but C is a very old language and some people like it. I don't. I an
> a C# "lover"!!!!!!
>
>
>>
>>
>>
>>
>> Magnitudes more flexible.
>>
> See this slightly revised prog but still most things hard-wired unlike
> C# where we can use <List> or C++ <vector>. These are resizeable
> "arrays" with more functions/Methods already supplied in the language.

C doesn't only have fixed-size arrays. It also offers:

* Arrays whose length is not known until runtime, but once allocated do
not change length

* Arrays whose length is determined at runtime, but which may also grow,
or shrink

It's just that the management of those kinds is manual. (Except perhaps
for VLAs, which allow smallish arrays of the first kind.)

In article <t02t8a$kj4$2@dont-email.me>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 06.03.2022 um 13:42 schrieb Kenny McCormack:
>> In article <b2017949-b97f-4d1e-87c5-5b6ed79ecd10n@googlegroups.com>,
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> Following the recent discussion of "reduce", I decided to try my hand at generic
>>> programming in C++.
>>
>> Off topic.
>>
>> Try comp.lang.c++
>
>Comparison of C against other languages is on-topic here.
>

No. You are wrong. This is a fact; it is not open to discussion.

Just ask Leader Keith. He'll tell you.

--
I'll give him credit for one thing: He is (& will be) the most quotable President
ever. Books have been written about (GW) Bushisms, but Dubya's got nothing on Trump.

Tremendously wet - from the standpoint of water.

Am 06.03.2022 um 22:40 schrieb Bart:
> On 06/03/2022 20:07, Bonita Montero wrote:
>> Am 06.03.2022 um 20:30 schrieb Manu Raju:
>>> On 06/03/2022 12:19, Bart wrote:
>>>>
>>>>
>>>> I don't need to read any further. Just look at the difference
>>>> between those two examples. I can easily follow the algorithm
>>>> expressed as C, but I can'make out anything in the C++. Is there
>>>> even an algorithm in that lot? All I can see is the last line that
>>>> matches C's.
>>>
>>> A simple C program without any bells & whistles!!!!
>>>
>>> <====================================================================>
>>> #include <math.h>
>>> #include <stdio.h>
>>> #include <time.h>
>>> #include <stdlib.h>
>>>
>>> float calculateSD(float data[]);
>>> int main()
>>> {
>>>     int i;
>>>     srand(time(NULL));    float data[10];
>>>     for (i = 0; i < 10; ++i)
>>>     {
>>>         data[i] = rand() % 99;
>>>     }
>>>     printf("The 10 numbers are: \n");
>>>     for (int i = 0; i < 10; i++)
>>>     {
>>>         printf("%4.0f", data[i]);
>>>     }
>>>     printf("\nStandard Deviation = %.6f", calculateSD(data));
>>>     return 0;
>>> }
>>>
>>> float calculateSD(float data[])
>>> {
>>>     float sum = 0.0, mean, SD = 0.0;
>>>     int i;
>>>     for (i = 0; i < 10; ++i)
>>>     {
>>>         sum += data[i];
>>>     }
>>>     mean = sum / 10;
>>>     for (i = 0; i < 10; ++i)
>>>     {
>>>         SD += pow(data[i] - mean, 2);
>>>     }
>>>     return sqrt(SD / 10);
>>> }
>>
>> Works only with float-arrays.
>>
>> This works with any input-iterable data that is
>> convertible to double:
>>
>>
>> template<typename Iterator>
>>      requires std::is_convertible_v<typename
>> std::iterator_traits<Iterator>::value_type, double> &&
>> std::input_iterator<Iterator>
>> double stddev( Iterator begin, Iterator end )
>> {
>>      using namespace std;
>>      using T = typename iterator_traits<Iterator>::value_type;
>>      ptrdiff_t n;
>>      double mean = 0.0;
>>      if constexpr( random_access_iterator<Iterator> )
>>          n = std::distance( begin, end ),
>>          for_each( begin, end, [&]( T &value ) { mean +=
>> (double)value; } );
>>      else
>>          n = 0,
>>          for_each( begin, end, [&]( T &value ) { ++n; mean +=
>> (double)value; } );
>>      mean /= n;
>>      double sqSum = 0.0;
>>      for_each( begin, end, [&]( T &value ) { double diff =
>> (double)value - mean; sqSum += diff * diff; } );
>>      return sqrt( sqSum / n );
>> }
>>
>> Magnitudes more flexible.
>>
>
> Even writing dedicated versions of the C for each of float, double, i32
> and i64 is magnitudes more readable than this.
>
> And also much easier to call. How do you even call your routine? I
> couldn't figure it out.
>
> Multiple versions in C can be done with macros. It's ungainly, but
> /still/ simpler to follow than the C++:
>
>   #define FUNC(name, T) \
>   double name##T(T *x, int N)\
>   {\
>       int i;\
>       double mean = 0;\
>       double sumvar2 = 0;\
>   \
>       for (i =0; i < N; i++)\
>         mean += x[i];\
>       mean /= N;\
>   \
>       for (i =0; i < N; i++)\
>          sumvar2 += (x[i] - mean)*(x[i]-mean);\
>   \
>       return sqrt(sumvar2/(N-1));\
>   }

Ugly ! Macros are a no-go.
You don't understand how flexible concepted templates are.
You can't emulate this with macros.

> float stdev(float x[], int N)

That's much less flexible.

>   #define FUNC(name, T) \
>   double name##T(T *x, int N)\
>   {\
>       int i;\
>       double mean = 0;\
>       double sumvar2 = 0;\
>   \
>       for (i =0; i < N; i++)\
>         mean += x[i];\
>       mean /= N;\
>   \
>       for (i =0; i < N; i++)\
>          sumvar2 += (x[i] - mean)*(x[i]-mean);\
>   \
>       return sqrt(sumvar2/(N-1));\
>   }
>
>   FUNC(stddev,float)
>   FUNC(stddev,double)
>   FUNC(stddev,int)
>   #define STDDEV(T,a,b) stddev##T(a,b)
>
> Call using, for example:
>
>   sd = STDDEV(float, data, N);

And my function works with any data that is convertible to
double - yours not. And my function even works with linked
lists - yours also not.

On 07/03/2022 08:34, Bonita Montero wrote:
>>    #define FUNC(name, T) \
>>    double name##T(T *x, int N)\
>>    {\
>>        int i;\
>>        double mean = 0;\
>>        double sumvar2 = 0;\
>>    \
>>        for (i =0; i < N; i++)\
>>          mean += x[i];\
>>        mean /= N;\
>>    \
>>        for (i =0; i < N; i++)\
>>           sumvar2 += (x[i] - mean)*(x[i]-mean);\
>>    \
>>        return sqrt(sumvar2/(N-1));\
>>    }
>>
>>    FUNC(stddev,float)
>>    FUNC(stddev,double)
>>    FUNC(stddev,int)
>>    #define STDDEV(T,a,b) stddev##T(a,b)
>>
>> Call using, for example:
>>
>>    sd = STDDEV(float, data, N);
>
> And my function works with any data that is convertible to
> double - yours not. And my function even works with linked
> lists - yours also not.

But DOES it work? Since I've no idea exactly what it does, no idea
exactly how to call it to test it, and no idea what the allowed inputs are.

I have very near 100% confidence that my C routine will do what it says,
and I know the input is an array of numeric values represented by T*.
But what the hell is yours up to?

Here's a challenge for you: write a generic C++ stddev routine that
looks as much like the C as possible, where the algorithm used is
identical. Don't be tempted to cram as many C++ toys into it as possible.

So, just like the C, but that works for float*, double* and any int*.

If there is really a need for a version that takes an interator object
(since there is no need for random-access objects, it can be serial)
then make a separate version for that.

> But DOES it work? Since I've no idea exactly what it does, no idea
> exactly how to call it to test it, and no idea what the allowed inputs
> are.

Your knowledge is the problem, not that it doesn't work.

> I have very near 100% confidence that my C routine will do what it says,
> and I know the input is an array of numeric values represented by T*.
> But what the hell is yours up to?

The code is even trivial in C++ if you know the language.

> Here's a challenge for you: write a generic C++ stddev routine that
> looks as much like the C as possible, where the algorithm used is
> identical. Don't be tempted to cram as many C++ toys into it as
> possible.

That would lose the flexibility of arbitrary data types being
convertible to double and non random access iterators. That are
the strong advantages over C.

> So, just like the C, but that works for float*, double* and any int*.

My code works with any data-type convertible to double (f.e.
though conversoin-operators) and with any iterable input -
with the same performance on random-accessible data.

> If there is really a need for a version that takes an interator
> object (since there is no need for random-access objects, it
> can be serial) then make a separate version for that.

Generic iterators aren't practicable in C like in C++.

Bart <bc@freeuk.com> writes:

> On 07/03/2022 08:34, Bonita Montero wrote:
>>>    #define FUNC(name, T) \
>>>    double name##T(T *x, int N)\
>>>    {\
>>>        int i;\
>>>        double mean = 0;\
>>>        double sumvar2 = 0;\
>>>    \
>>>        for (i =0; i < N; i++)\
>>>          mean += x[i];\
>>>        mean /= N;\
>>>    \
>>>        for (i =0; i < N; i++)\
>>>           sumvar2 += (x[i] - mean)*(x[i]-mean);\
>>>    \
>>>        return sqrt(sumvar2/(N-1));\
>>>    }
>>>
>>>    FUNC(stddev,float)
>>>    FUNC(stddev,double)
>>>    FUNC(stddev,int)
>>>    #define STDDEV(T,a,b) stddev##T(a,b)
>>>
>>> Call using, for example:
>>>
>>>    sd = STDDEV(float, data, N);

> I have very near 100% confidence that my C routine will do what it
> says, and I know the input is an array of numeric values represented
> by T*. But what the hell is yours up to?
>
> Here's a challenge for you: write a generic C++ stddev routine that
> looks as much like the C as possible, where the algorithm used is
> identical.

That one of those strange Usenet challenges where you insist that the
person with the advantage in the exchange plays with their hands tied
behind their back! But I'll play:

double stddev(const auto *x, int N)
{
double sum = 0;
for (int i = 0; i < N; i++)
sum += x[i];

double mean = sum/N, sum_var_sq = 0;
for (int i = 0; i < N; i++)
sum_var_sq += (x[i] - mean) * (x[i] - mean);

return std::sqrt(sum_var_sq / (N-1));
}

Shorter, clearer and easier to understand than the C, but it does
inherit some of the C code's limitations.

> Don't be tempted to cram as many C++ toys into it as
> possible.

Ah, the politician's urge to spin comes out again! Many of C++ advanced
features make writing flexible, reliable code easier. There are
legitimate criticism that be levelled at the complexity of modern C++,
but they are not toys.

In C++ one would use an iterator at the very least (and probably two,
rather than an explicit size) so that the code would work on all sorts
of iterable things. That's not cramming in a toy.

> So, just like the C, but that works for float*, double* and any int*.

And one could document this with a type constraint. Again, not a toy.

And one might use pre-written algorithms to take advantage of future
library implementation improvements:

double stddev(const auto &first, const auto &last)
{
double sum = std::reduce(first, last);
double sum_sq = std::transform_reduce(first, last, first, 0.0);
double N = std::distance(first, last);
return std::sqrt((sum_sq - sum*sum/N)/(N-1));
}

Again, not toys.

> If there is really a need for a version that takes an interator object
> (since there is no need for random-access objects, it can be serial)
> then make a separate version for that.

Of course there is a need for that. In C++, what there is not a need
for is a separate version that uses a pointer.

--
Ben.

On 07/03/2022 12:51, Bonita Montero wrote:
>> But DOES it work? Since I've no idea exactly what it does, no idea
>> exactly how to call it to test it, and no idea what the allowed inputs
>> are.
>
> Your knowledge is the problem, not that it doesn't work.

And that knowledge that is needed is immense.

Trying to make sense of your C++ is harder than trying to read assembly.

I specialise in language solutions that consist of clean, readable code
that anyone can understand even without that knowledge. You just need to
be able to read pseudo-code.

Your speciality seems to be the opposite: you don't care how unreadable
your code looks. In fact the worse the better. It could have ten times
as much clutter as necessary, but nobody would be able to tell.

>> I have very near 100% confidence that my C routine will do what it
>> says, and I know the input is an array of numeric values represented
>> by T*. But what the hell is yours up to?
>
> The code is even trivial in C++ if you know the language.

What, this is trivial:

template<typename Iterator>
requires std::is_convertible_v<typename
std::iterator_traits<Iterator>::value_type, double> &&
std::input_iterator<Iterator>

This is just plain gobbledygook, whether you know the language or not.

I wasn't able to test it, because you failed to provide an example of
how it can be called with a regular array.

>
>> Here's a challenge for you: write a generic C++ stddev routine that
>> looks as much like the C as possible, where the algorithm used is
>> identical. Don't be tempted to cram as many C++ toys into it as
>> possible.
>
> That would lose the flexibility of arbitrary data types being
> convertible to double

The C macro solution I posted works with doubles, floats or ints. Ints
are converted to double only as needed.

> and non random access iterators. That are
> the strong advantages over C.

Yeah, I use arrays of numeric data implemented as linked lists a lot!

>> So, just like the C, but that works for float*, double* and any int*.
>
> My code works with any data-type convertible to double (f.e.
> though conversoin-operators) and with any iterable input -
> with the same performance on random-accessible data.
>
>> If there is really a need for a version that takes an interator
>> object  (since there is no need for random-access objects, it
>> can be serial) then make a separate version for that.
>
> Generic iterators aren't practicable in C like in C++.

No, they're not. But as far as I'm concerned, your C++ is useless. Maybe
there are better C++ solutions, and I asked you to post one that does
the same job as my C-macro version (ie. works with arrays of
double-float-int), but you failed to do so.

Maybe you are just incapable of writing simple, clean code in C++ even
when it would be possible.

Meanwhile, if I desperately needed a generic solution regardless of
language, I would use this dynamic script, based on Malcolm's OP:

fun stddev(A) =
mean:=sumvar2:=0

for x in A do mean +:= x od
mean /:= A.len
for x in A do sumvar2 +:= sqr(x-mean) od

sqrt(sumvar2/(A.len-1))
end

It's called as:

sd := stddev(data)

This works with arrays of u8-u32, i8-i64, f32-f64.

It also works with lists of MIXED elements.

But it doesn't work with linked lists (which are little used in dynamic
code). For that, I'd need to call it like this:

sd := stddev(convert(L))

where convert() turns the linked or other special list L, into the
indexable object that is needed.

(It also doesn't work with arbitrary-precision decimals, but that's due
to limited support for functions like sqrt().)

Am 07.03.2022 um 15:53 schrieb Bart:
> On 07/03/2022 12:51, Bonita Montero wrote:
>>> But DOES it work? Since I've no idea exactly what it does, no idea
>>> exactly how to call it to test it, and no idea what the allowed inputs
>>> are.
>>
>> Your knowledge is the problem, not that it doesn't work.
>
> And that knowledge that is needed is immense.

There are some details, but none of that details is complcitated.

> What, this is trivial:
>
> template<typename Iterator>
>     requires std::is_convertible_v<typename
> std::iterator_traits<Iterator>::value_type, double> &&
> std::input_iterator<Iterator>
>
> This is just plain gobbledygook, whether you know the language or not.

If you know the language halfway that's easy to read.

> The C macro solution I posted works with doubles, floats or ints. Ints
> are converted to double only as needed.

But my solution can have arbitrary iterators "pointing" to anything
convertible to double.

> Yeah, I use arrays of numeric data implemented as linked lists a lot!

Variance isn't used only with strong numeric calculations.

> No, they're not. But as far as I'm concerned, your C++ is useless.

.... for a C-fanatic.

> Maybe there are better C++ solutions, ...

Show me ...

> Meanwhile, if I desperately needed a generic solution regardless of
> language, I would use this dynamic script, based on Malcolm's OP:
>
>     fun stddev(A) =
>         mean:=sumvar2:=0
>
>         for x in A do mean +:= x od
>         mean /:= A.len
>         for x in A do sumvar2 +:= sqr(x-mean) od
>
>         sqrt(sumvar2/(A.len-1))
>     end
>
> It's called as:
>
>     sd := stddev(data)
>
> This works with arrays of u8-u32, i8-i64, f32-f64.

This is for sure not as flexible as my C++-solution.

On 07/03/2022 14:34, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:

>> Here's a challenge for you: write a generic C++ stddev routine that
>> looks as much like the C as possible, where the algorithm used is
>> identical.
>
> That one of those strange Usenet challenges where you insist that the
> person with the advantage in the exchange plays with their hands tied
> behind their back!

No, I'm insisting they write clean, readable code.

C++ always seems to be touted as providing the language-building tools
that will let to write much clearer and simpler code than C. That's
rarely the case with the C++ I've seen, especially from BM.

> double stddev(const auto *x, int N)
> {
> double sum = 0;
> for (int i = 0; i < N; i++)
> sum += x[i];
>
> double mean = sum/N, sum_var_sq = 0;
> for (int i = 0; i < N; i++)
> sum_var_sq += (x[i] - mean) * (x[i] - mean);
>
> return std::sqrt(sum_var_sq / (N-1));
> }
>
> Shorter, clearer and easier to understand than the C, but it does
> inherit some of the C code's limitations.

OK, that's much better than what I've seen previously. (I assume you are
comparing it to C++, as it's on a par C.)

As to the limitations, what are they?

> In C++ one would use an iterator at the very least (and probably two,
> rather than an explicit size) so that the code would work on all sorts
> of iterable things. That's not cramming in a toy.

(I don't use 'iterable' on my own stuff; mainly 'indexable')

>> So, just like the C, but that works for float*, double* and any int*.
>
> And one could document this with a type constraint. Again, not a toy.

You're taking my use to 'toy' too literally!

> And one might use pre-written algorithms to take advantage of future
> library implementation improvements:
>
> double stddev(const auto &first, const auto &last)
> {
> double sum = std::reduce(first, last);
> double sum_sq = std::transform_reduce(first, last, first, 0.0);
> double N = std::distance(first, last);
> return std::sqrt((sum_sq - sum*sum/N)/(N-1));
> }

I tried this using:

double A[]={41,53,97,67,62, 82,93, 54,34,11};
double x;

x=stddev(&A[0], &A[9]);
printf("%f\n", x);

But it didn't give the right result (should be 26.903). It worked with
&A[10] as the 'last' element.

It turns out I could call BM's version the same way, although that has
this interface:

double stddev( Iterator begin, Iterator end)
However, this gives me a result of 20.847, whether I use &A[9] or
&A[10]. So either that code is wrong (wouldn't be surprising), or I've
no idea how it should be called.

> And one might use pre-written algorithms to take advantage of future
> library implementation improvements:
>
> double stddev(const auto &first, const auto &last)
> {
> double sum = std::reduce(first, last);
> double sum_sq = std::transform_reduce(first, last, first, 0.0);
> double N = std::distance(first, last);
> return std::sqrt((sum_sq - sum*sum/N)/(N-1));
> }

This works also but without concepts you mightz get ugly
error-messages.

Bart <bc@freeuk.com> writes:

> On 07/03/2022 14:34, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> Here's a challenge for you: write a generic C++ stddev routine that
>>> looks as much like the C as possible, where the algorithm used is
>>> identical.
>> That one of those strange Usenet challenges where you insist that the
>> person with the advantage in the exchange plays with their hands tied
>> behind their back!
>
> No, I'm insisting they write clean, readable code.

Come on! Insisting that some bit of C++ be as much like the C version
is an absurd restriction.

> C++ always seems to be touted as providing the language-building tools
> that will let to write much clearer and simpler code than C. That's
> rarely the case with the C++ I've seen, especially from BM.

There's a research project in there -- is C++ generally badly written
compared to C? I can't even guess as I am out of the game. I don't see
code "in the wild" anymore, but in my day there was a lot of bad C code
out there as well.

>> double stddev(const auto *x, int N)
>> {
>> double sum = 0;
>> for (int i = 0; i < N; i++)
>> sum += x[i];
>>
>> double mean = sum/N, sum_var_sq = 0;
>> for (int i = 0; i < N; i++)
>> sum_var_sq += (x[i] - mean) * (x[i] - mean);
>>
>> return std::sqrt(sum_var_sq / (N-1));
>> }
>>
>> Shorter, clearer and easier to understand than the C, but it does
>> inherit some of the C code's limitations.
>
> OK, that's much better than what I've seen previously. (I assume you
> are comparing it to C++, as it's on a par C.)

No, it's better than the C code. No token pasting. It's not littered
with \s. No need to instantiate it for the different types and no need
to have a special call macro or to use its special type-decorated name.
How could you not think it's clearer?

> As to the limitations, what are they?

It only works with arrays due to the use of pointers. In C++ you'd use
an iterator so that it would work with conventional arrays, vectors,
arrays, views and many more. With a simple view you could get the
standard deviation of the values in a map using the same function.

>> In C++ one would use an iterator at the very least (and probably two,
>> rather than an explicit size) so that the code would work on all sorts
>> of iterable things. That's not cramming in a toy.
>
> (I don't use 'iterable' on my own stuff; mainly 'indexable')

Modern C++ has a lot of support for neat programming using iterators.
It would be a serious mistake not to use iterators. Did you see my
example of using views to get the standard deviation of employees'
salaries and ages? How would you do that in C?

>>> So, just like the C, but that works for float*, double* and any int*.
>> And one could document this with a type constraint. Again, not a toy.
>
> You're taking my use to 'toy' too literally!

No, I know it's a metaphor -- a deliberately belittling one -- and I too
was using the term metaphorically: the features I describe are not toys
in the metaphorical sense. I never thought you meant they were
literally only for play, so that was not how I was using the term
either.

--
Ben.

On Monday, 7 March 2022 at 10:53:14 UTC, Bart wrote:
>
> If there is really a need for a version that takes an interator object
> (since there is no need for random-access objects, it can be serial)
> then make a separate version for that.
>
If you want to parallelise efficiently, random access to the data can be
important. So if we have 100 processors, and 100 million items, we can
say

processor 1 - items 1 to 1 million
processor 2 - items 1million + 1 to 2 million
...
processor 100 - items 99 million to 100 million

If we only have serial access, we've got to trawl through 100 million
entries.

On 07/03/2022 16:43, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 07/03/2022 14:34, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> Here's a challenge for you: write a generic C++ stddev routine that
>>>> looks as much like the C as possible, where the algorithm used is
>>>> identical.
>>> That one of those strange Usenet challenges where you insist that the
>>> person with the advantage in the exchange plays with their hands tied
>>> behind their back!
>>
>> No, I'm insisting they write clean, readable code.
>
> Come on! Insisting that some bit of C++ be as much like the C version
> is an absurd restriction.

If not like the C, then at least be as readable as pseudo-code. That is,
being to follow the algorithm. Having it 90% boilerplate code makes it
harder to discern the actual code.

As it turned out, BM's solution didn't work. I've no idea why and the
C++ is far too complex for me to try and figure it out.

>> OK, that's much better than what I've seen previously. (I assume you
>> are comparing it to C++, as it's on a par C.)
>
> No, it's better than the C code. No token pasting. It's not littered
> with \s. No need to instantiate it for the different types and no need
> to have a special call macro or to use its special type-decorated name.
> How could you not think it's clearer?

Oh, you're talking about my attempt using macros. I /said/ it's
ungainly, but I also said it's still clearer than BM's effort!

(I can't do much about the C, but if I had to add proper
('early-binding'?) generics to a language, my start point might be a
dynamic version like this:

fun stddev(A) = ... # A has a variant type

This I believe can be adapted to /optionally/ serve as a template, while
keeping the body of this function unchanged. )

>> (I don't use 'iterable' on my own stuff; mainly 'indexable')
>
> Modern C++ has a lot of support for neat programming using iterators.
> It would be a serious mistake not to use iterators. Did you see my
> example of using views to get the standard deviation of employees'
> salaries and ages? How would you do that in C?

Over-complex slices and views is something else I'm not keen on either!

However I might concede the use a list-comp for example to extract the
relevant data into an indexable object, which can then be passed into
the stddev routine.

So, this limits the number of language features that need to cope with
arbitrary complexity. I think it is also an approach that is easier to
grasp by some programmer.

Bart <bc@freeuk.com> writes:

> On 07/03/2022 16:43, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 07/03/2022 14:34, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>> Here's a challenge for you: write a generic C++ stddev routine that
>>>>> looks as much like the C as possible, where the algorithm used is
>>>>> identical.
>>>> That one of those strange Usenet challenges where you insist that the
>>>> person with the advantage in the exchange plays with their hands tied
>>>> behind their back!
>>>
>>> No, I'm insisting they write clean, readable code.
>> Come on! Insisting that some bit of C++ be as much like the C version
>> is an absurd restriction.
>
> If not like the C, then at least be as readable as pseudo-code. That
> is, being to follow the algorithm. Having it 90% boilerplate code
> makes it harder to discern the actual code.

I think you've lost track of what's being talked about. Either that or
I have no idea what you meant by your "challenge".

> As it turned out, BM's solution didn't work. I've no idea why and the
> C++ is far too complex for me to try and figure it out.
>
>>> OK, that's much better than what I've seen previously. (I assume you
>>> are comparing it to C++, as it's on a par C.)
>> No, it's better than the C code. No token pasting. It's not littered
>> with \s. No need to instantiate it for the different types and no need
>> to have a special call macro or to use its special type-decorated name.
>> How could you not think it's clearer?
>
> Oh, you're talking about my attempt using macros.

What C did you mean when you said "as much like the C as possible" and
what algorithm when you insisted it use an "identical" one?

--
Ben.

> As it turned out, BM's solution didn't work. I've no idea why
> and the C++ is far too complex for me to try and figure it out. ...

You don't understand the code and you say that it doesn't work ?

> Oh, you're talking about my attempt using macros. I /said/ it's
> ungainly, but I also said it's still clearer than BM's effort!

LOL.

> Over-complex slices and views is something else I'm not keen on either!

Iterators make things _less_ complex.
Views make plain memory iterable - with bounds-checking while you debug.

On Monday, 7 March 2022 at 18:39:38 UTC, Bart wrote:
> On 07/03/2022 16:43, Ben Bacarisse wrote:
>
> > Modern C++ has a lot of support for neat programming using iterators.
> > It would be a serious mistake not to use iterators. Did you see my
> > example of using views to get the standard deviation of employees'
> > salaries and ages? How would you do that in C?
> Over-complex slices and views is something else I'm not keen on either!
>
Views should be something built into the language. They shouldn't be implemented,
however cleverly, using existing language features.
They are a solution to the employee salary problem. You don't often get a datum
which is just "a real". It's usually associated with something else. C does sort
of allow a "stride / offset of" interface, but it's too clumsy to be generally useful.
C++ allows you to pass an access function, which will usually be a trivial
little lambda, which was my first solution. In C, you can pass a function
pointer to the access function, but it has to take a const void *, and it has to be
defined at file scope, which makes it awkward.
C++ also allows a view. Whilst of course you could implement this in C,
it would be so difficult that you'd effectively be writing a C emulator for a
different labguage. Views separate the trivial data access stage from the rest
of the logic.