Sunday, August 30, 2015

Digest for comp.lang.c++@googlegroups.com - 8 updates in 3 topics

Paavo Helde <myfirstname@osa.pri.ee>: Aug 30 04:36PM -0500

jt@toerring.de (Jens Thoms Toerring) wrote in
> It would be different if one would be able to write directly
> to the vectors memory area and change it's size afterwards,
> but that's not allowed.
 
What do you mean? What's wrong with using a properly resized std::vector or
std::string buffer for reading a file handle?
jt@toerring.de (Jens Thoms Toerring): Aug 30 10:28PM

> > but that's not allowed.
 
> What do you mean? What's wrong with using a properly resized std::vector or
> std::string buffer for reading a file handle?
 
Chances are I'm missing something, but the only way to get
at the underlying pointer to the vector's (or string's) data
is the data() method (and for strings there-s also c_str())
- and that just returns a const pointer, i.e. something I
can't pass to read(). Ok, one can use '&vec[0]' to obtain
that address also, but I hadn't considered to use that
address for writing to the arrays or strings memory as some-
thing kosher - but if it is why does data() return a const
pointer only? Could be that I'm too squeamish and it's above
the board to do it that way. If it is it would make some
things quite a bit simpler;-)
 
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
"Öö Tiib" <ootiib@hot.ee>: Aug 30 03:58PM -0700

On Sunday, 30 August 2015 17:34:49 UTC+3, JiiPee wrote:
> > instead of using containers.
 
> yes, and using possible delete as well (or if smar pointers, then
> reset). so total management
 
I do not know why we need 'delete'. I haven't had 'delete' for more
than decade in my own code. There are too large variety of well-tested
stock smart pointers available.
 
I 'reset' smart pointer for same reasons why I 'clear' a container.
It has to be empty by program logic and so I 'reset' or 'clear' it.
I may need 'new' for some rare reasons like for covariance.
jt@toerring.de (Jens Thoms Toerring): Aug 30 11:25PM

> returns a pointer to const value_type. Otherwise, it returns
> a pointer to value_type.
 
> (Disclaimer: I have not tried this, just read it from docs.)
 
Thanks! Took another look and found that the data() method for
vectors does indeed has a pointer to non-const version, while
strings don't (and you usually use character arrays as "byte"
arrays when using read() and friends). So I had overlooked that
with a vector more is allowed than with strings and assumed that
if strings don't do it also vectors won't (and then it seemed to
be a bit like taking too many liberties with the innards of a
vector). I'll have to see how I can use this newly acquired piece
of knowledge;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
ram@zedat.fu-berlin.de (Stefan Ram): Aug 30 10:52PM

>at the underlying pointer to the vector's (or string's) data
>is the data() method (and for strings there-s also c_str())
>- and that just returns a const pointer, i.e. something I
 
(You must mean a »pointer to const«, not a »const pointer«.)
 
There are two entries in ::std::vector.
 
value_type* data() noexcept; and
const value_type* data() const noexcept;
 
. If the ::std::vector object is const-qualified, the call
returns a pointer to const value_type. Otherwise, it returns
a pointer to value_type.
 
(Disclaimer: I have not tried this, just read it from docs.)
David Brown <david.brown@hesbynett.no>: Aug 31 12:28AM +0200

On 30/08/15 23:21, Prroffessorr Fir Kenobi wrote:
>>> view, this kode above on my old C2D executes 7.6 s and yeilds to
>>> 2.178154
>> Looks closer to 2 than e....
 
That's a typo. With 100000000 iterations the answer is about 2.718359.
With more iterations, it appears to get closer to e - but converges
extremely slowly.
 
I haven't done the maths to work out the answer correctly, but I can't
say it would shock me to see the answer being e.
 
 
 
> where is that code? (changing div to mul by inverse improves quite a
> lot 7.6 -> 5.6 or alike,, but really wonder if some better than clib
> rand cannot be found..
 
Use -ffast-math, which lets the compiler do optimisations like that
automatically. And making file-local functions (and variables, though
there are none here) "static" can sometimes be of significant help in
optimising, as well as being good programming practice.
 
 
> are all this various platform rands() implement the same algorithm?
 
There are vast numbers of pseudo-random number generating algorithms. I
have no idea which one your code will be using from the C library on
your system. But it won't take much googling to find some. The quality
(which can be measured in many different ways) varies - you might find
some algorithms that look good, and give a good long-term average
pattern, yet fail to give anything close to e on this test.
bartekltg <bartek@gmail.com>: Aug 31 12:44AM +0200

On 30.08.2015 23:13, Johann Klammer wrote:
 
>> this is anyway interesting form the optimistation points of view,
>> this kode above on my old C2D executes 7.6 s and yeilds to 2.178154
> Looks closer to 2 than e....
 
It is e. Fir just doesn't care and smash keyboard without looking;-)
 
Lets n(x) be an expected value of times one need to draw
a random number idd U[0..1] to gat sum smaller than x.
We are looking for n(1).
 
We draw a number p. If p>=x we are done. In other case
we need another n(x-p) draws.
 
n(x) = 1 + \int_0^x n(x-p) dp
 
I'm sure there is a methodical way to solve the equation,
but we can guess n(x) = exp(x). Ant it works.
1+\int_0^x exp(x-p) dp = 1 - exp(x-p)|_0^x = 1-(exp(0)-exp(x))=exp(x)
 
n(1) = e.
 
 
>> probabilistic properties and faster execution..
 
>> can someone provide such routine?
 
> take the code for rand and the functions it calls from the c library and inline them in this file.
 
I'm pretty sure a decent compiler do it for us.
 
 
A version with default_random_engine (propably x = x * 48271 %
2147483647) from <random> without any trick, is only a bit slower
 
int trial2() {
static random_device rd;
static default_random_engine gen(rd());
uniform_real_distribution<double> dist(0.0,1.0);
int count = 0;
double sum = 0;
while (sum <= 1.0) {
sum += dist(gen);
count++;
}
return count;
}
 
double monteCarlo2(int n) {
int i, total = 0;
for (i = 0; i < n; i++) {
total += trial2();
}
return total / (double) n;
}
 
 
c like rand 2.718359
5.64892s
c++11 <random> 2.718232
5.73054s
c like rand 2.718111
5.67173s
c++11 <random> 2.718149
5.73041s
c like rand 2.718318
5.67199s
c++11 <random> 2.718329
5.73014s
 
And mt19937, a real pseudorandom number generator, not a toy,
get results below 8seconds.
 
bartekltg
bartekltg <bartek@gmail.com>: Aug 31 12:50AM +0200

On 31.08.2015 00:28, David Brown wrote:
 
> That's a typo. With 100000000 iterations the answer is about 2.718359.
> With more iterations, it appears to get closer to e - but converges
> extremely slowly.
 
Monte Carlo always is extremely slow. It converges like 1/sqrt(n),
so we get next significant digit after 100 times more work.
 
bartekltg
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)