A Newbie Post

[440bx]

@MrPink,

Julian Bucknall's Tomes of Delphi: Algorithms and Data Structures is an excellent book in more ways than one.

In addition to what @Thaddy mentioned, you can get a copy "directly" from the author along with errata and the source code for the book at: https://secondboyet.com/FixedArticles/DADSBook.html

HTH.

[MarkMLl]

That is correct. Not only FORTRAN, but also TP and originally C had/have very simple LCG's that - on larger amounts of data can have a very noticable bias.

I know, but we're talking high-end fundamental physics here. Not tacky languages designed by people who didn't understand the application areas they would be used in.

MarkMLl

[Thaddy]

That's the same as the core developers interpreting a prng as implementation detail 
(Tragically they used to understand the issue while still students. Jonas? Care to answer on this?)

[MarkMLl]

That's the same as the core developers interpreting a prng as implementation detail 
(Tragically they used to understand the issue while still students. Jonas? Care to answer on this?)

Don't worry, I had a run-in with them when I complained that their "Mersenne Twister" emitted the wrong sequence because the internal representation was wrong (signed rather than unsigned?). That was when the docs were changed to say "similar to".

I remember a comms lecturer using the internal random number generator from TP1 or 2 for a lab simulation. Until one of his students pointed out that it first produced a stream of odd numbers, then switched to a stream of even numbers...

So as somebody said, "Random numbers are too important to be left to chance". And that's particularly significant when using something like Monte Carlo to provide an approximate solution to a problem that is intractable in practice.

MarkMLl

[Thaddy]

Mark,

The same is the case with C++, as I showed before on this forum. The standard is mt19937 and fpc - used to, not in trunk - conform to that. As does my implementation on the wiki.

Code: C  [Select][+][-]

1. #include <iostream>
2. #include <random> // for std::mt19937
3.  
4. int main() {
5.     std::mt19937 mt; // Instantiate a 32-bit Mersenne Twister
6.  
7.     // Print a bunch of random numbers
8.     for (int count { 1 }; count <= 40; ++count) {
9.         std::cout << mt() << '\t'; // generate a random number
10.  
11.         // If we've printed 5 numbers, start a new row
12.         if (count % 5 == 0)
13.             std::cout << '\n';
14.     }
15.  
16.     return 0;
17. }

That code is probably not mine, I believe I posted a similar example but can't find it.
Given the same seed, this generates random values compatible to Freepascal <= 3.2.2.

For others, casual readers: this is important to share data between the two languages.

You are right about the quote  It is important.

Your quote is attributed to Robert Coveyou

[Thaddy]

Btw Mark,
You are wrong in making the comparison between signed and unsigned.
That is because prng's operate on the bit level and should not care about sign.
So most prng algorithms use unsigned values and cast - or scale - back to signed when required.

[Thaddy]

@MrPink,

Julian Bucknall's Tomes of Delphi: Algorithms and Data Structures is an excellent book in more ways than one.

Thanks for mentioning the author. My mistake.

[MarkMLl]

You are wrong in making the comparison between signed and unsigned.

I am talking about the specific case of FPC's Random() circa 2016. I'm not going back looking for my bug report, but the fundamental problem was that even though it was described- at the time- as "Mersenne" you couldn't get 32-bit values out of it because the internal representation was wrong.

MarkMLl

[Thaddy]

  i never noticed that and I should have....
Now back to books...

[DavidL]

fwiw: there is nothing wrong with keep/still using the old terminal IDE or whatever editor floats your boat in case you do not wish to get distracted by all the graphical violence. I myself prefer it over using the Lazarus IDE (but that is because I get easily distracted by all bells and whistles).

Hahaha!  Yeah, as one who violently detests the gamification of software development, if I wanted to play video games I'd get a Nintendo.  But such is "progress".   

[MarkMLl]

Hahaha!  Yeah, as one who violently detests the gamification of software development, if I wanted to play video games I'd get a Nintendo.  But such is "progress".   

I sympathise with that, but the bottom line is that the work on- to pick just one example- ensuring that the debugger displays information in the format most useful to the high-level construct being examined is being done in Lazarus, not in the text-mode IDE.

Part of the reason for that is that the GUI facilities provided by Lazarus's LCL make design and implementation of such things far easier, but that has absolutely no bearing on the type of program being worked on by the end user.

And I assure you that no OS (using the broad term to include the desktop environment etc.) has ever really provided a decent TUI design environment: except possibly for MS's Visual Basic for DOS in the early 90s.

MarkMLl

[Thaddy]

Mark, are you very sure you did not attempt to write a pong clone? I don't believe that...

[MarkMLl]

Mark, are you very sure you did not attempt to write a pong clone? I don't believe that...

You'd use some 555s for that...

MarkMLl

[Thaddy]

I will add them to my phone book.

For others: https://www.businessinsider.nl/555-phone-number-tv-movies-telephone-exchange-names-ghostbusters-2018-3?international=true&r=US

[MarkMLl]

Looks like I have to explain the joke. These days, the average hacker will reach for an Arduino, but somebody of the old-school persuasion would say "I'd use a 555 for that". In fact back when I was an undergrad one of the lecturers grmbled about virtually all student dissertation projects being described as "741 op-amp blah blah phase-locked loop blah blah 555 timer...".

The 555 was a supernally flexible timer chip, implemented in an 8-pin package using a small number of transistors https://www.righto.com/2022/01/silicon-die-teardown-look-inside-early.html .

As an example of what it could be used for, see https://hackaday.com/2022/05/30/practical-wireless-tele-tennis-build-after-only-34-years/ .

Look at the photo at the bottom of that article. There's no microcontrollers in there, no firmware. Just a small number of monostable timers, responsible for both playing the game and generating the video.

Hence, "I'd use a 555 for that".

MarkMLl