I think Bart is a complete idiot - what
he doesn't understand is overly complex.

On 07/03/2022 19:35, Bonita Montero wrote:
>> 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 ?

Why don't you post a version I can run. Or at least tell what what I
have to pass to get the SD of this array:

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

(I assume you have tested your routine.)

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>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.

I would argue that nobody would be handling employee salary in
C or C++. They're be more like to use the built in functionality of
their database SQL interpreter, even to get the standard deviation
of employee salary. At worse, they export from the database into a CSV
using a SQL query and run the output through some spreadsheet software, R,
Matlab or a python script.

Instead of wasting time proposing more and more obscure features for
C++, how about a standard data base access API instead? Something actually
useful?

On 07/03/2022 19:55, Malcolm McLean wrote:
> 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.

Is there actually a problem? Is this example posted by Ben just designed
to demonstrate various advanced features of C++?

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";

How did anyone ever manage this before views? Puzzling!

I suggested elsewhere using list-comps to help with this, when input
data to stddev wasn't a simple array.

This demo is something I don't have working right now, but is a feature
I used to have which fell into disuse. Then the above example would look
like this (assume employees[] has the same structure):

println stddev((e.salary for e in employees))
println stddev((e.age for e in employees))

So considerably simpler. However, the evaluation here is not lazy. That
means that you might run out of memory if you have half a billion people
on your payroll.

> 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.

My views are ultra-simple: a linear slice in the first dimension, with a
step of +1. Python's slices are a little more elaborate in that the step
can be +/- N.

My view (no pun) is that one should strive to keep such features as
simple and streamlined as possible; the opposite approach to C++ which
is to pile in as much as is possible.

Bart <bc@freeuk.com> writes:

> On 07/03/2022 19:55, Malcolm McLean wrote:
>> 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.
>
> Is there actually a problem? Is this example posted by Ben just
> designed to demonstrate various advanced features of C++?

No, it was designed to answer a point Malcolm made. He wanted to pass
an access function to stddev so it could handle "non-numerical data". I
wanted to support the idea that stddev is inherently numerical and
can be kept that way without limiting it's use too much.

> 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";
>
> How did anyone ever manage this before views? Puzzling!

Surely you could program this in half a dozen languages, couldn't you?
The ones that don't support this sort of high-level data access will be
clumsy or limited in some way. Just thinking of those half a dozen
different designed should reveal the pros and cons of the facilities
provided.

> I suggested elsewhere using list-comps to help with this, when input
> data to stddev wasn't a simple array.

Yes, that's how I might do it in some of the designs I am now imagining.

--
Ben.

> Why don't you post a version I can run. ...

Because you are stupid.

On Monday, 7 March 2022 at 20:51:55 UTC, Scott Lurndal wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >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.
> I would argue that nobody would be handling employee salary in
> C or C++. They're be more like to use the built in functionality of
> their database SQL interpreter, even to get the standard deviation
> of employee salary. At worse, they export from the database into a CSV
> using a SQL query and run the output through some spreadsheet software, R,
> Matlab or a python script.
>
Oh sure. In reality it's very unlikely that you want want to calculate the standard
deviation, hardcoded to employees' salaries, in C. You'd have a database or a
spreadsheet. stddev might still be implemented in C, but it would work on label-
free data presented by the calling program.
>
A payroll program is the standard example of "an application program". It's not
that we'll really be working with employees. It's that "struct Employee" is a good
example of a simple structure which shows up some problems in representing
real records in programming.
>
> Instead of wasting time proposing more and more obscure features for
> C++, how about a standard data base access API instead? Something actually
> useful?
>
I agree that a standard database access API might well be useful. But that
clearly belongs in another thread.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
generally useful.
>> I would argue that nobody would be handling employee salary in
>> C or C++. They're be more like to use the built in functionality of
>> their database SQL interpreter, even to get the standard deviation
>> of employee salary. At worse, they export from the database into a CSV
>> using a SQL query and run the output through some spreadsheet software, R,
>> Matlab or a python script.
>>
>Oh sure. In reality it's very unlikely that you want want to calculate the standard
>deviation, hardcoded to employees' salaries, in C. You'd have a database or a
>spreadsheet. stddev might still be implemented in C, but it would work on label-
>free data presented by the calling program.
>>
>A payroll program is the standard example of "an application program". It's not
>that we'll really be working with employees. It's that "struct Employee" is a good
>example of a simple structure which shows up some problems in representing
>real records in programming.

The concept of a "payroll" program (the vast majority of which were
written in COBOL) is a couple decades out of favor - most companies
outsource their payroll now or purchase a third-party application
from Oracle or SAP. It's very difficult to get right given all the
tax code and regulatory hoops that need jumping through.

On 07/03/2022 20:51, Scott Lurndal wrote:

>
> I would argue that nobody would be handling employee salary in
> C or C++. They're be more like to use the built in functionality of
> their database SQL interpreter, even to get the standard deviation
> of employee salary.

In MySQL you only need this to get StdDev:
<https://www.mysqltutorial.org/mysql-standard-deviation/>

SELECT customerNumber,
COUNT(*) orderCount
FROM orders
WHERE status = 'Shipped'
GROUP BY customerNumber;

SELECT FORMAT(STD(orderCount),2)
FROM (SELECT customerNumber, count(*) orderCount
FROM orders
GROUP BY customerNumber) t;

For MS-SQL you need this:
<https://docs.microsoft.com/en-us/sql/t-sql/functions/stdev-transact-sql?view=sql-server-ver15>

For Oracle they have something similar.

I agree C/C++ is never used for such things unless it is for some
academic/research purposes.

On 3/7/2022 9:49 PM, Bart wrote:
> On 07/03/2022 19:35, Bonita Montero wrote:
>>> 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 ?
>
> Why don't you post a version I can run. Or at least tell what what I
> have to pass to get the SD of this array:
>
>  double A[]={41,53,97,67,62, 82,93, 54,34,11};
>
> (I assume you have tested your routine.)

Bart, you fell into BM's trap!
Before replying to her, consider how much she loves trolling..

> Bart, you fell into BM's trap!

Bart falls into all developers traps which are more skilled
like him - and that are a lot.

On 10/03/2022 17:10, Bonita Montero wrote:
>> Bart, you fell into BM's trap!
>
> Bart falls into all developers traps which are more skilled
> like him - and that are a lot.
>

Bart mainly works with languages he has designed and implemented
himself, and which are 100% self-hosted. There are not a lot of a
developers who can claim that.

When it comes to C, he mainly works with a compiler for that language he
has implemented himself. Not many developers can claim that either.

With regard to your routine, it gave a different result because it
evaluated a population SD not a sample SD like most of the other
contributions.

You could have mentioned that, and explained how the routine could be
called by providing a working example, instead of just dishing out insults.