Art of file 3D (by irid)
I must admit that the scenes reaction at my post about the graphical interpretation of files has surprised me. First I was asked by qubodup to release the source on an open source license, which lead to the release of a *nix port by KlAaze, and now irid has created a 3D version in python!
- topic on reddit (it contains a link to the source code)
- youtube video
Cool :)
To tell you the truth I've experimented with 3D (long before the 2D version was created), but unfortunately I've chose wrong (ultra boring) files for tests, which made me cancel the project in the end. I'm really glad that irid didn't make the same mistake - some files look really great in 3D!
An interesting misinterpretation related to rand()
Recently I've seen some code created by one of my friends, which I'll quote (the code, not the friend; it won't be a direct code, but nothing important is changed):
int my_rand_limit = 60000;
srand(time(0));
#ifdef RAND_MAX
# undef RAND_MAX
#endif
#define RAND_MAX my_rand_limit
int rand_value = rand();Curious about what was this piece of code supposed to do (since I expected it didn't do what was expected) I have asked my friend for explanation - he replied with a direct quote from the manual:
The rand() function returns a pseudo-random integer in the range [0, RAND_MAX].So the above code was supposed to work like this: "I want rand() should return a value from 0 to 60000, so I'll change RAND_MAX to 60000". I must admit that that logic was undeniable.
However, even if logically it was correct, it didn't work as it should. The reason? RAND_MAX is kinda "read-only", or, to be more precise, it is a constant declared by the developer of rand() which describes the maximal capabilities of rand() function (as in - the maximum value rand() can return). The value of this constant depends on the implementation, but the implementation does not use it. It's just an information - so, changing RAND_MAX in fact changes nothing.
Of course, the correct usage of rand() in this case is rand_value = rand() % (my_rand_limit + 1).
But what's interesting, is that you can make the above code work anyway! You just have to make the implementation, or the invocation, RAND_MAX related. You can do the later one by a short preprocessor directive:
#define rand() (rand() % RAND_MAX)
By the way...
On 22nd Nov'24 we're running a webinar called "CVEs of SSH" – it's free, but requires sign up: https://hexarcana.ch/workshops/cves-of-ssh (Dan from HexArcana is the speaker).
My friend has told me that he had tested the code earlier, and it has returned only values from the expected boundaries - so I began searching for the above #define in headers of different compilers, but I found nothing. As we figured out later, the test results were positive due to the my_rand_limit being very close to RAND_MAX, so the values seemed OK, and were accepted without further testing.
And that would be all for now :)
Comments:
Well, that would not be entirely correct. If you want to avoid skewing the random distribution, you should throw away any values greater than the highest multiple of (my_rand_limit+1) that fits in RAND_MAX. A simple if-condition would do.
Example:
Lets say RAND_MAX is 4, and you want numbers between 1 and 0 ; you'd do modulo 2.
0 % 2 = 0
1 % 2 = 1
2 % 2 = 0
3 % 2 = 1
4 % 2 = 0
The chance of getting a 0 is 3/5, while the chance of getting a 1 is 2/5. The effect of this will be less obvious when the RAND_MAX is many orders of magnitude larger than my_rand_max, but it would possibly skew your results.
Yep, you are correct.
A similar remark was posted on the PL side of this blog - the readers have proposed to rescale the value that rand() returns to the expected limit using the following formula:
r = ( (double)rand() / ((double)(RAND_MAX)+1.0) )
rand_value= (r * my_rand_limit).
However your proposal is much better, since in the above case some numbers are still more common than others.
Add a comment: