How to use the current `\jobname` as a seed for random numbers? - TeX

निरंजन replying to samcarter

Hahaha

samcarter

I feel like watching a code golf tournament <3

frougon replying to Skillmon

I have nothing against it, was merely fixing a few imperfections (IMHO) in samcarter's answer. Feel free to write a second answer. :)

Skillmon replying to frougon

Why not `\sys_gset_rand_seed:n { 0 \str_map_tokens:Nn \c_sys_jobname_str { + \int_from_alph:n } }`?

frougon replying to निरंजन

You're welcome. :)

निरंजन replying to frougon

Okay. Got it. Thanks for clarifying.

frougon replying to निरंजन

The “contract” when using scratch variables implies that non-kernel code is explicitly allowed to modify them: they are **scratch** variables. You are free to save and restore scratch variables for “someone else” but this is merely wasting CPU cycles, as no one who follows the rules will expect non-kernel code to preserve these variables.  
  
(Please don't label code as safe or unsafe depending on whether it preserves scratch variables: modifying them is perfectly allowed, thus safe.)

निरंजन replying to frougon

Exactly, but they are declared for everyone, not just for me or not just for you. In that case, why not to keep them safe for others? It only eases other people's job, in my opinion. I agree that expecting them to be safe is not good because all the third party code cannot be trusted to be safe. But I don't see why encouraging programmers for keeping it safe is bad.

frougon replying to निरंजन

Of course you can use private variables instead of scratch variables. The point of scratch variables is that they already exist, so you don't need to declare them, and using them won't reserve a TeX register that no one else can use in the whole TeX run (which is/was quite important for engines that only have 256 registers of a given type; I don't recall if these are still supported).

निरंजन replying to frougon

The following text is added to the description of each and every scratch variable in source3.pdf.

> These are never used by the kernel code, and so are safe for use with any LaTeX3-defined function. However, they may be overwritten by other non-kernel code and so should only be used for short-term storage.

I didn't read it as a permission to use scratch variables freely. I understood the basic warning that if I use scratch variables, then I should use them locally, so that they are unaffected by the outer non-kernel code, but somehow I also thought that keeping them safe for others is a good practice. Otherwise why to even have scratch variables in the first place? Everyone can have their own declared variables anyway. The point of having them for me was that it's a common and easy name that doesn't require a particular module and so many people would want to use them. If your purpose is only to use it for a short time, then better not to disturb other people's code. Otherwise I can always declare `\l__mymodule_tmpa_tl` and be absolutely sure that nobody would dare consider it safe for their use. Note that scratch variables have a single underscore and not two.

frougon replying to samcarter

You're welcome. :)

frougon replying to निरंजन

From `texdoc interface3` (§1.1.2, *Scratch variables*):  
  
> These are never used by the core code. The nature of TeX grouping means that as with any other scratch variable, these should only be set and used with no intervening third-party code.

samcarter replying to frougon

Thanks! That looks much more readable!

frougon replying to निरंजन

No, sorry. Outer code that calls my function should not expect that my function preserves `\l_tmpa_int`: it's a scratch variable. Kernel functions don't modify them; that is the only guarantee I am aware of.

निरंजन

Wait, I think I got what you mean. If it's a function that uses scratch variables, then its definition should contain groups, but if it's a one time code run before `\begin{document}`, then it doesn't necessarily need that. Correct?

frougon replying to निरंजन

If you have code that sets e.g. `\l_tmpa_int`, then calls non-kernel outer code, then expects `\l_tmpa_int` to be unchanged, this code is buggy and should be fixed. If the “non-kernel outer code” is in fact from your package and only uses kernel code (no other “outer”), then it's for you to decide whether it is guaranteed to preserve `\l_tmpa_int`.

निरंजन replying to frougon

Okay. While working on a collaborative package, I found grouping quite helpful, because there were cases where it leaked and other functions got disturbed.

frougon replying to निरंजन

I quickly replaced `\tl_map_inline:Vn` with `\str_map_inline:Nn`, so no variant is needed.  
  
Regarding `expl3` scratch variables, you don't have to preserve them for hypothetical outer code you don't even know. You only need to make sure they are not disturbed by outer code when your code calls outer code and then reuses scratch variables that your code previously used (in which case you should rather use a local, non-scratch variable).

निरंजन replying to frougon

Oh, true! I forgot about `\tl_map_inline`. What I meant with outer grouping is that if it is a part of a larger code, then other functions might be using scratch variables. That's why I suggested adding a group.

frougon replying to निरंजन

Here is how I would implement @samcarter's idea. No intermediate `seq` needed. No outer grouping either, as `\begin{document}` does not expect scratch variables possibly used by `\documentclass` to be preserved.  
  
```  
\documentclass{article}

\ExplSyntaxOn

\int_zero:N \l_tmpa_int
\str_map_inline:Nn \c_sys_jobname_str
  { \int_add:Nn \l_tmpa_int { \int_from_alph:n {#1} } }
\sys_gset_rand_seed:n { \l_tmpa_int }

\ExplSyntaxOff

\begin{document}

\fpeval{rand()}

\end{document}
```  
  
Of course Skillmon's approach is better.

निरंजन replying to Skillmon

Ahh, sorry, got it.

Skillmon replying to निरंजन

No, this is the md5 hash of the given string (in this case the value of `\jobname`), not the file contents.

निरंजन

@samcarter, here is a version without `\text_map_inline:nn`. I don't know how to eliminate `\seq_map_inline:Nn`, though. As long as we are sticking to your idea, I can't think of doing it without sequences. Probably @frougon should try.

```
\ExplSyntaxOn
\group_begin:
\int_zero:N \l_tmpa_int
\seq_clear:N \l_tmpa_seq

\cs_generate_variant:Nn \seq_set_split:NnV { NnV }
\seq_set_split:NnV \l_tmpa_seq { } \c_sys_jobname_str

\seq_map_inline:Nn \l_tmpa_seq {
  \int_add:Nn \l_tmpa_int {
    \int_from_alph:n { #1 }
  }
}

\sys_gset_rand_seed:n { \l_tmpa_int }
\group_end:

\fp_show:n { rand() }

\ExplSyntaxOff

\stop
```

निरंजन

@Skillmon, re: [your answer](#a7772), wouldn't this only generate a different number when the concerned file has undergone some changes? That might be passable or even desired in some cases. Looking at what @samcarter has mentioned in the question, it seems to be fine for this case, but it would be good to mention this as a known limitation, IMO.

निरंजन replying to frougon

I didn't even see what was inside the braces!! :joy: I just saw scope, module, naming scheme and that's it. Being a teacher is difficult..

samcarter

@Skillmon, re: [your answer](#a7772), Nice idea! Thanks for your answer!

frougon replying to samcarter

I don't have anything interesting enough to post an answer, was just pointing out that (unless I am missing something) the `seq` appears to be an otherwise useless intermediary variable in your answer. :)

samcarter replying to frougon

probably not, but this is what I got working :) Feel free to post an alternative answer!

samcarter replying to frougon

In my use case only latin letters in upper- and lowercase

samcarter replying to frougon

Thanks!

frougon

@samcarter Is the `seq` variable really needed?

frougon

Also, I believe `\text_map_inline:nn` is quite heavy machinery (dealing with grapheme clusters...) for `\c_sys_jobname_str`... **unless** the latter can contain non-ASCII chars in modern engines? I don't know, haven't practiced much lately!

frougon replying to samcarter

You could use `\int_zero:N \l_tmpa_int` instead of `\int_set:Nn \l_tmpa_int {0}`.

निरंजन replying to samcarter

Hmm, happens. Thanks for correcting it... :D

samcarter replying to निरंजन

Thanks! I always confuse the order!

निरंजन

@samcarter, re: [your answer](#a7771), `\int_new:N \int_mysum` is wrong. `_int` should be at the end. You should add a scope marker, i.e., l or g. In this case, it would be `l` as you are using `\int_add:Nn` and not `\int_gadd:Nn`. After the scope marker, you also need a unique module name. Also, better to put your operations inside a group if they use scratch variables.

samcarter replying to Udi Fogiel

indeed :)

Udi Fogiel

I think your answer is good enough then :)

samcarter replying to Udi Fogiel

Let's say that two compilations with different job names should have a > 90% probability to use a different seed.

Udi Fogiel

Or consider this. You have 26^19 possible strings, but only 2^28 possible seeds, and 26^19/ 2^28 >>> 16^19 / 2^28 = 2^76 / 2^28 = 2^48...

Udi Fogiel

even if you disregard letter ordering, you still have 45 choose 19 options, which is bigger than 2^28, so you cannot have a collision-free encoding into 28 bits this way. So now the question is what do you mean by "give a different seed in most cases".

2 Answers