Wednesday, April 6, 2016

Digest for comp.lang.c++@googlegroups.com - 24 updates in 6 topics

Vlad from Moscow <vlad.moscow@mail.ru>: Apr 06 03:57PM -0700

On Saturday, November 7, 2015 at 11:26:46 PM UTC+3, Vlad from Moscow wrote:
 
> As I was already said several times at the same Stackoverflow the problem is that I am from Russia and this is clear from my nickname Vlad from Moscow.
 
> I asked a question at Meta that to discuss the situation but again I was ignored and my question was just removed.
 
> So I am again banned after my correct answer was deliberately down-voted and after I asked a question how to behave in such situations.:)
 
The fascist policy of the Stanckoverflow continues.:)
 
Now I am banned after my correct answer to this question
 
http://stackoverflow.com/questions/36435991/3-recursion-problems-beginner-c/36436517#36436517
 
It is evident that at first my correct answer was down-voted without any comments that would explain what is wrong in the presented code.:)
 
After I made a note that you should not take into account the down-votings because the answer is correct and the down-votings only confuse other readers of the question and the answer I was banned.:)
 
SO searches for any reason to ban me.:)
legalize+jeeves@mail.xmission.com (Richard): Apr 06 10:59PM

[Please do not mail me a copy of your followup]
 
Vlad from Moscow <vlad.moscow@mail.ru> spake the secret code
 
>The fascist policy of the Stanckoverflow continues.:)
 
Whaaaaaaaaaaaa.
 
I don't mind someone using the term "fascist" when something is
actually fascist. However, to use it as a generic pejorative for
"anything I don't like" makes you look like an idiot and a crybaby.
 
If you have a rant against stack overflow, go find an appropriate
newsgroup for it.
 
This is not the right newsgroup for your stack overflow complaints.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Mr Flibble <flibble@i42.co.uk>: Apr 07 12:02AM +0100

On 06/04/2016 23:57, Vlad from Moscow wrote:
 
> It is evident that at first my correct answer was down-voted without any comments that would explain what is wrong in the presented code.:)
 
> After I made a note that you should not take into account the down-votings because the answer is correct and the down-votings only confuse other readers of the question and the answer I was banned.:)
 
> SO searches for any reason to ban me.:)
 
Your answer was probably down voted because you are doing someone's
homework for them. Doing people's homework for them is not good because
that person doesn't learn anything and it is also basically cheating.
 
/Flibble
Vlad from Moscow <vlad.moscow@mail.ru>: Apr 06 04:15PM -0700

On Thursday, April 7, 2016 at 1:59:58 AM UTC+3, Richard wrote:
> The Computer Graphics Museum <http://computergraphicsmuseum.org>
> The Terminals Wiki <http://terminals.classiccmp.org>
> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
 
I am banned only because I am from Russia. Some participants of the SO already wrote that they see the only reason that I am banned is that I am from Russia.
 
When I ask moderators they just ignore me. But if someone complains I am banned at once. For example my correct answers are down-voted in revenge as the answer I referenced here. But if I down-voted somebody answer I am also banned at once even if I described in a comment to the answer why I down-voted the answer.:)
Vlad from Moscow <vlad.moscow@mail.ru>: Apr 06 04:28PM -0700

On Thursday, April 7, 2016 at 2:02:32 AM UTC+3, Mr Flibble wrote:
> homework for them. Doing people's homework for them is not good because
> that person doesn't learn anything and it is also basically cheating.
 
> /Flibble
 
 
If you personally do not like some question for example because you think it is some homework then you can vote to close the question or even down vote it.
 
But you may not dictate me what must I do. For me the assignment is interesting and I do what isinteresting to me without asking a permisiion.
 
You may down-vote my answer if it is incoorect if it gives an invalid solution and so on.
 
But you may not down-vote correct answers in revenge if you personally do not like that I aswered the question.
 
The result is that I who gave a correct answer was down-voted after my correct answer was down voted in revenge.:)
Jerry Stuckle <jstucklex@attglobal.net>: Apr 05 07:31PM -0400

On 4/5/2016 6:54 PM, Chris Vine wrote:
>> will be recovered by the system when your program terminates.
 
> Out of interest, can you name a modern system in practical use that does
> not recover memory when a program terminates?
 
Immaterial. It is still good practice for your program to release any
resources it has acquired while running. There is, for instance, no
guarantee the OS will release the resources - or that the program will
terminate.
 
>> practice.
 
> No. Using resource handles such as std::unique_ptr is considered good
> practice.
 
That's another good practice. But issuing a delete for every new is
also a good practice. unique_ptr is not always applicable, for instance.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
JiiPee <no@notvalid.com>: Apr 06 07:27AM +0100

On 05/04/2016 20:29, Öö Tiib wrote:
> perhaps study how 'boost::adjacency_list' is written and why it is
> bad and weak class. Skill of inventing square wheels is not
> desirable in our industry. ;)
 
you meant "re-inventing a round wheel"?
"Osmium" <r124c4u102@comcast.net>: Apr 06 08:18AM -0500

"Jerry Stuckle" wrote:
 
> resources it has acquired while running. There is, for instance, no
> guarantee the OS will release the resources - or that the program will
> terminate.
 
The whole notion of an OS is a master program that lets programs run, one
after another; perhaps even concurrently. If you are writing programs to
run under a boot loader, you should release your resources, If you are
writing for an OS, it is a duty of the OS to release the resources you had.
Otherwise the system won't work for more than a few hours at most.
scott@slp53.sl.home (Scott Lurndal): Apr 06 04:24PM

>run under a boot loader, you should release your resources, If you are
>writing for an OS, it is a duty of the OS to release the resources you had.
>Otherwise the system won't work for more than a few hours at most.
 
That depends entirely on the operating system, doesn't it. Some small
embedded operating systems may not, in fact, release the resources.
"Öö Tiib" <ootiib@hot.ee>: Apr 06 09:49AM -0700

On Wednesday, 6 April 2016 09:27:28 UTC+3, JiiPee wrote:
> > bad and weak class. Skill of inventing square wheels is not
> > desirable in our industry. ;)
 
> you meant "re-inventing a round wheel"?
 
No way. Good for nothing square wheels to pass a weird phone interview
from place where OP believes that square wheels roll.
Paul <pepstein5@gmail.com>: Apr 06 11:44AM -0700

On Wednesday, April 6, 2016 at 5:49:41 PM UTC+1, Öö Tiib wrote:
 
> > you meant "re-inventing a round wheel"?
 
> No way. Good for nothing square wheels to pass a weird phone interview
> from place where OP believes that square wheels roll.
 
I'm talking about the standard procedures for hiring software developers by software companies -- nothing "weird" about it. Also, I don't think I said that "square wheels roll."
 
Paul
"Osmium" <r124c4u102@comcast.net>: Apr 06 02:38PM -0500

"Paul" <pepstein5@gmail.com> wrote in message
news:61e15101-40a0-4bd2-aed0-4595eefedfcc@googlegroups.com...
On Wednesday, April 6, 2016 at 5:49:41 PM UTC+1, Öö Tiib wrote:
 
> > you meant "re-inventing a round wheel"?
 
> No way. Good for nothing square wheels to pass a weird phone interview
> from place where OP believes that square wheels roll.
 
I'm talking about the standard procedures for hiring software developers by
software companies -- nothing "weird" about it. Also, I don't think I said
that "square wheels roll."
 
Go back and read his posts *very* carefully. AIUI there is something in
boost he doesn't like and he wants you to study that way and then be sure to
not do it that way. I believe that boost is the source of the square wheels.
Ramine <ramine@1.1>: Apr 06 12:50PM -0700

Hello.........
 
 
To show you what is capable of my USL programs, here is
a demonstration:
 
Here is the graph of the predicted scalability of USL law of the
raytracer performance data that my windows usl_graph.exe program has
drawn by typing at the command prompt: usl_graph data.csv -g 10 349
 
Please look at it here:
 
http://pages.videotron.com/aminer/chart.html
 
 
Please try my windows USL programs , they are powerful tools..
 
I have included windows 32 bit and 64 bit executables of my USL programs
inside the zip files..
 
You can download my USL programs from:
 
https://sites.google.com/site/aminer68/universal-scalability-law-for-delphi-and-freepascal
 
 
Thank you,
Amine Moulay Ramdane.
bleachbot <bleachbot@httrack.com>: Apr 06 04:53PM +0200

bleachbot <bleachbot@httrack.com>: Apr 06 06:49PM +0200

Mr Flibble <flibble@i42.co.uk>: Apr 06 12:55AM +0100

On 06/04/2016 00:09, Chris Vine wrote:
 
> Can you provide a reference for me of this? C++14 is the same as C++98
> on the complexity of splice. size() has gone from linear time to
> constant time, but that is a different matter.
 
One of the splice() overloads needs to be linear time if size() is to be
constant time.
 
/Flibble
"Öö Tiib" <ootiib@hot.ee>: Apr 05 05:12PM -0700

On Wednesday, 6 April 2016 02:09:57 UTC+3, Chris Vine wrote:
 
> Can you provide a reference for me of this? C++14 is the same as C++98
> on the complexity of splice. size() has gone from linear time to
> constant time, but that is a different matter.
 
Before C++11 there was no requirement that 'size' is constant time.
When standard was made then committee assumed that typically 'size' is
not needed massively. Committee assumed that typically it is of interest
if container "is empty", Unfortunately a method with awful (IMHO)
"emptying" name 'empty' was added instead of 'is_empty'.
 
Many implementations made 'size' of some containers linear time, since it
can speed up inserts, erases and splices from trees and lists. It is just
as rarely needed to 'splice' a lot (as is to 'size' a lot) but 'std::list'
had its exceptionally strong side in those implementations.
 
However noob user (and typical user is noob) code did not use 'c.empty()';
most code used 'c.size() == 0' and C++ noob code was inefficient. So C++11
went noob friendly and now requires that size must be constant.
 
Therefore splice has now to be linear complexity since the new size has to
be found out during splice. Well ... we can use 'boost::intrusive::list'
(with its inconveniences) if we ever need well-performing lists again.
Juha Nieminen <nospam@thanks.invalid>: Apr 06 06:19AM

> time (which was a good decision IMO).
 
> It remains obvious that you are still blissfully unaware of the std::list
> use-cases.
 
The decision to make that splice() function linear-time was idiotic because
it pretty much destroys one of the use cases where linked lists are
actually efficient. There are algorithms that depend on splicing parts of
lists onto other lists in constant-time. Now std::list became useless
for that purpose.
 
I think it's *you* who doesn't know the use cases for linked lists.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
SG <s.gesemann@gmail.com>: Apr 06 02:42AM -0700

> As you also appear to have stubbornly refused to utilise the advantages of std::list during your career probably due to following some blinkered groupthink I suspect you would simply reject any valid std::list use-case I provide so I won't even bother.
 
How convenient for you.
 
Why would I refuse to utilise the advantages of std::list? Such a
situation just never came up. If anything, I'm unimaginative -- not
stubborn. I would have liked to read about actual problems you solved
using std::list. But I guess I won't be hearing about them since you
avoided answering my questions.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 06 11:47AM +0100

On Tue, 5 Apr 2016 17:12:05 -0700 (PDT)
Öö Tiib <ootiib@hot.ee> wrote:
[snip]
> has to be found out during splice. Well ... we can use
> 'boost::intrusive::list' (with its inconveniences) if we ever need
> well-performing lists again.
 
OK, thanks for explaining that. I can see that the complexity of range
splicing between different lists has changed from constant time to
linear time over the range (but not over the whole list). For single
element splicing (the three argument version of std::list::splice()),
constant time should still be possible because you know you can just
increment the size variable of the sink by one and decrement the source
by one. For whole list splicing (the two argument version of
std::list::splice()), you can just add the two previous sizes to get
the new size of the sink, and set the size of the source to 0. C++98,
C++14 and the latest version of the draft standard produced by WG21
(N4582) indeed still say that these must be constant time. Likewise
range splicing (the four argument version of splice) should still be
constant time if the sink and source are the same because the size does
not change, and the standard still requires this (§23.3.10.5 of N4582).
 
Previously range splicing where the source list is different from the
sink list could presumably have been constant time since you would only
need to fix up the affected node pointers. What puzzles me on thinking
about this is that C++98 says the same as the current standard, namely
that range splicing between different lists has linear time
(§23.2.2.4/14). Presumably most implementations in fact ignored this
and made the operation constant time, and it is ability of
implementations to 'improve on' the standard which has now gone.
 
Chris
Juha Nieminen <nospam@thanks.invalid>: Apr 06 11:49AM

> However noob user (and typical user is noob) code did not use 'c.empty()';
> most code used 'c.size() == 0' and C++ noob code was inefficient. So C++11
> went noob friendly and now requires that size must be constant.
 
One possible solution would have been to keep splice constant-time, and
have size() be linear-time only the first time it's called, and constant-time
with subsequent calls, until the next time the list is spliced. (Element
addition and removal wouldn't need to invalidate the size because those
are done one at a time. Only splicing can add an unknown number of elements.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 06 10:17AM -0500

> lists onto other lists in constant-time. Now std::list became useless
> for that purpose.
 
> I think it's *you* who doesn't know the use cases for linked lists.
 
It remains painfully obvious that it is YOU who doesn't know when to use
std::list as you are only aware of one (non-ideal) use-case (range variant
of splice).
 
/Flibble
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 06 10:17AM -0500

> with subsequent calls, until the next time the list is spliced. (Element
> addition and removal wouldn't need to invalidate the size because those
> are done one at a time. Only splicing can add an unknown number of elements.)
 
I suggested several years ago in this very newsgroup that std::list::size()
could be amortised constant time (basically make the size member variable
mutable optional) as a solution to this problem however the range variant
of splice() isn't the only std::list use-case so perhaps such a change was
seen as too irksome with a too-low priority.
 
/Flibble
Ramine <ramine@1.1>: Apr 06 10:54AM -0700

Hello......
 
 
USL for Delphi and FreePascal was updated to version 2.5
 
Now you can draw a beautiful graph of the USL law
 
Here is how:
 
I have included also usl_graph.exe and its source code,
us_graph.exe will draw a graph of the predicted scalability
of the USL law, please type at the commmand prompt:
 
usl_graph data.csv -g 5 449
 
You have to give two parameters to the -g option, this will
draw a graph with a step=d(x)=5 between two successive
data points , and it will draw a graph up to the peak number
that is x=449
 
You can save after that your graph to the clipboard and
open the paint program on windows and save it after that.
 
You will find the Delphi XE source code of the usl_graph.exe
on the source directory of the zipfile for the Delphi XE versions.
 
You can download my USL programs from:
 
https://sites.google.com/site/aminer68/universal-scalability-law-for-delphi-and-freepascal
 
 
Author: Amine Moulay Ramdane.
 
Email: aminer@videotron.ca
 
 
Description:
 
This program analyzes system performance data with the Universal
Scalability Law, and it compiles with Delphi XE versions and
FreePascal.
 
You have to supply the performance data as a csv file format,
please take a look at the supplied csv file called "data.csv",
the first line of the names of the colomuns of the csv file must
be commented by "#" character, the names of the columns are
mandatory.
 
Just compile the usl.pas program and run it by executing it
on the command prompt like this: usl data.csv
 
The Universal Scalability Law (USL) was developed by Dr. Neil J.
Gunther. It can be used to analyze system performance data in order to
learn more about the scalability limitations of the system.
 
Details are presented in the book *Guerrilla Capacity Planning*.
 
Authors of Universal Scalability Law website:
 
http://www.perfdynamics.com/
 
Please take a look at the source code in the zip file:
 
When you compile the usl.pas , please type this at
the command prompt:
 
usl data.csv
 
Here is the output of my program:
 
Peak number is: 449.188
Predicted scalability peak is: 18.434
Coefficient of determination R-squared is: 0.995
 
The peak number is the peak number of cores (look inside the csv file)
that will give the Predicted scalability peak that is: 18.434X
 
I have included also usl_graph.exe and its source code,
us_graph.exe will draw a graph of the predicted scalability
of the USL law, please type at the commmand prompt:
 
usl_graph data.csv -g 5 449
 
You have to give two parameters to the -g option, this will draw a graph
with a step=d(x)=5 between two successive data points , and it will draw
a graph up to the peak number that is x=449
 
You can save after that your graph to the clipboard and open the
paint program on windows and save it after that.
 
I have used a polynomial regression and i have done other approximations
to find the predicted scalability peak when the derivative must equal an
approximation of 0 and this when the USL coefficient beta equal 0. This
is all about mathematics.
 
You have two options:
 
You can type at the command prompt: usl data.csv -p 20
 
the -p option will give you the scalability for the data point 20
 
and you can type at the command prompt: usl data.csv -d 0.2 10
 
the -d option will give you the derivative of the USL equation at
delta(y)/delta(x)=0.2 (it must be between 0 and 1) with a step
delta(x)=10 that will output a good approximation of a number and a
derivative to better optimize the criterion of the cost for a
better QoS.
 
I will a little bit explain my USL program...
 
If you have took a look at this link:
 
https://cran.r-project.org/web/packages/usl/vignettes/usl.pdf
 
You will notice that the performance data for the raytracer in the
link above is the same as the performance data inside the data.csv
file inside my zip file of my USL software..
 
And as you have noticed in the link above the peak scalability
number is at: 449 processors.
 
So if you run my program against this same performance data
like this at the command prompt:
 
usl data.csv
 
So the output is of my program is:
 
--
Peak number is: 449.188
Predicted scalability peak is: 18.434
Coefficient of determination R-squared is: 0.995
--
 
So as you have noticed that the peak number that
is the peak number of processors is: 449.188
this is the same result as the link above.
 
So my program is working correctly.
 
But this is not the end of the story..
 
You have to optimize the criterion of the cost for a better QoS,
and for this i have supplied you with a second option called -d that
you have to run for that, so you have to type at the command
prompt:
 
usl data.csv -d 0.3 0.1
 
 
the 0.3 is the slope of the secant with a step 0.1, so since the step
is 0.1 so this will approximate a derivative of the USL equation that
equal 0.3, so here is the output of my program when you run
it with -d 0.3 0.1:
 
--
Peak number is: 449.188
Predicted scalability peak is: 18.434
Coefficient of determination R-squared is: 0.995
The derivative of the USL equation at delta(y)/delta(x)=0.300 with a
step delta(x)=0.100, gives a good approximation of a number and a
derivative delta(y)/delta (x) of: 16.600 and 0.300
--
 
So as you have noticed that a good approximation for the
derivative of the USL equation will arrive at the 16.600 cores
and this gives also a derivative of the secant that approximate the
derivative of the USL equation.
 
So to optimize more the criterion of the cost for a better QoS,
you have to choose a good delta(y)/delta(x) to optimize the criterion
of the cost of your system and you have to balance better between
the performance and the cost.
 
I have tested more my USL for Delphi and FreePascal and it is working
perfectly. But to make it work best with multicores, you have to choose
the first column of the number of cores of the csv to: 1,2,4,8,
16 without going up to 32 and it will work ok, don't choose 1,2,3,4,5
because this will not be a good approximation and this will cause problems.
 
How can you be sure that my USL program for Delphi and FreePascal works
correctly ?
 
Please take a look at this link:
 
https://cran.r-project.org/web/packages/usl/vignettes/usl.pdf
 
Notice the raytracer performance data, when they have analysed it, it
gives a peak scalability at: 449
 
So try to run my program inside the zip against the the same raytracer
performance data that you will find inside the data.csv file inside the
zip, and this will give the same peak scalability at: 449.
 
So as you have noticed, my program is working for this performance data
of the raytracer, so i think that you can be confident with my program.
 
I have included a 32 bit windows executable called usl.exe inside the
zip, please read the readme file to know how to use it, it is a very
powerful tool.
 
- Platform: Win32 ,Win64,Linux,OSX
 
 
Thank you,
Amine Moulay Ramdane.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)