dalke

Here is a problem I've been noodling with. If you are a decent programmer, how does your LLM help you solve this problem?

Given a cheminformatics fingerprint definition based on SMARTS substructure patterns, come up with a screening filter, likely using a decision tree, which uses intermediate feature tests to prune search space faster than simply testing each pattern one-by-one.

For example, the Klekota-Roth patterns defined in their supplemental data (and also available from CDK at https://github.com/cdk/cdk/blob/main/descriptor/fingerprint/...) contain patterns like:

    "CC(=NNC=O)C",
    "CC(=NNC=O)C(=O)O",
    "CC(=NNC=O)C=C",
    "CC(=NNC=O)C=Cc1ccccc1",

Clearly if 'CC(=NNC=O)C' does not exist in the molecule to fingerprint then there is no reason to test for the subsequent three patterns.

Similarly, there are patterns like:

    "FC(F)(C=O)C1(F)OC(F)(F)C(F)(F)C1(F)F",
    "FC(F)(F)C(F)(F)C(F)(F)OC(F)(C=O)C(F)(F)F",
    "FC(F)(F)C(F)(F)C(F)(F)S",

which could be improved by an element count test - count the number of fluorines, and only do the test if there are enough atoms in the molecule to fingerprint.

So one stage might be to construct a list of element counts;

   ele_counts = [0]*200
   seen = set()
   for atom in mol.GetAtoms():
      ele_counts[eleno:=atom.GetAtomicNum()] += 1
      seen.add(eleno)

then have a lookup table for each element, based on the patterns which have at least that count of the given element type;

   ele_patterns = [
     # max known count, list of set of matching patterns
     (0, [set()]), # element 0
     (0, [set()]), # hydrogen
     ..
     (20, [{all patterns which contain no carbon},
           {all patterns which require at most 1 carbon}, ...
           {all patterns which require at most 19 carbons}],
     (10, [{all patterns which contain no fluorine}, ..
           {all patterns which contain at most 9 fluorines}], 
      ...]

so one reduction can be

   def get_possible_patterns(seen, ele_counts):
     for eleno in seen:
        max_count, match_list = ele_patterns[eleno]
        count = min(ele_counts[eleno], max_count)
        yield match_list[count]
   patterns = set.intersect(*get_possible_patterns(seen, ele_counts))

and only test that subset of patterns.

However, this is not sophisticated enough to identify which other tests, like the "CC(=NNC=O)C" example I gave before, or "S(=O)(=O)", which might be good tests at a higher level than the element.

And clearly if there isn't a sulphur, aren't two oxygens, and aren't two double bonds then there's no need to test "S(=O)(=O)", suggesting a tree structure would be useful.

> These "wallets" are not used for financial transactions, they're for credentials.

Which is why I gave other examples of the human factors issues, not just financial transactions: configurable cookie warnings, configurable app permissions, and user agreements.

> what it means to use a very fine grained proof

Except you know that bars, etc. are going to ask for more details, including full name, address etc. And they'll say it's needed to prevent known hooligans and troublemakers.

Will people stop going to the bars until the bars only request the minimum required information? No - or at least not more than people currently click off all the "I agree to this surveillance" buttons on a web page.

So people just accept, and enter. Then the bar asks for more, and more, and more, and people have been trained to just agree to everything, because they have very little power to say no.

I've already heard accounts of people who bring their passport instead of state id for the simple reason that it does not contain a scannable address. If it's expected that everyone always has the ability to provide any required information, simply saying no is hard.

> Fine grained digital approaches can help those situations.

"Can" is pulling a lot of weight. I can click off all the cookie trackers. The vast majority do not. Is that from an informed decision, or is that simply the easiest decision?

I can disable geolocation tracking on my browser, but then - oops! - the county web site showing me the upcoming vaccination times doesn't work because the site assumes everyone has geolocation turned on, and they never tested for someone who voluntarily disabled that option.

Build a system that expects coherent data, and you build a system where people get trained to provide anything which asked for, with poor support for those who opt-out.

My question remains: to what extent is selective disclosure useful given the demonstrable human factors failures in existing selective disclosure systems?

User agreements are another example of failure. They give full disclosure, on a take-or-leave-it basis. Few people say no to GitHub when it means being blocked from participating in most software development projects.

Plus, very few actually read that full disclosure. I can guarantee you that most people do not come out of high school with sufficient training to read those agreements, much less immigrants like me who never received training in the Swedish legalese I am required to agree to use digital healthcare.

All these experiences tell me that a central personal information store as described will have exactly the same failures, and that selective disclosure will in practice be equally meaningless.

"Learn a credit card" is misdirection. We know from the number of people who declared bankruptcy due to credit card debt that they didn't all learn how to use it correctly, or had no alternative than taking on ruinous debt.

So you think that selective disclosure isn't all that useful without all of the above?

Who will do the education? The banks? The schools? If the latter, what subjects will be removed from the curriculum?

Who will verify the AI is trained correctly? Who is liable of it is not? How will it be updated as new frauds are discovered?

Will the solution require everyone to buy new phones? How much more will be destroy the world?

> great ideas in this, like selective disclosure

How will a centralized wallet used for everything solve the human factors problems?

We know there's a deep human factors issue here. Web sites and apps ask for permission seemingly all the time for as much as they can, and most people just agree, because they've learned that usually works.

Until it doesn't.

Here's a Fortune article of how BankID, a widely-used electronic ID in Sweden, is used in fraud, at https://fortune.com/europe/2024/06/21/why-going-cashless-has... :

"For Bagley, the fact that BankID is so commonplace is part of the problem. “It ends up not really being a security measure, but just another step in using a website,” she said. “You don’t really think twice about what the BankID app might say you are logging into.”"

You can blame Bagley for not double-checking the transfer before verifying, but she's not the only one. "Online fraud and digital crime in Sweden have surged, with criminals taking 1.2 billion kronor in 2023 through scams like the one Bagley fell for, doubling from 2021."

Last time I was in Switzerland, back in 2015 or so, the B&B I stayed in was cash only. The stay cost something like 500 CHF, or nearly 600 USD.

More and more places here in Sweden do not accept cash, and I don't like it.

I have the usual personal reasons:

- I don't like individualized tracking,

- there's no backup solution if my stuff gets stolen (10 years ago my bank card stopped working during a trip to Germany. I borrowed cash from friends for the rest of the trip and paid them back)

- I'm dependent on a single bank (I've wondered if I should open an account at a second bank)

- It depends on an international network to always work, which doesn't seem to be true even here.

- More abstractly, since the SWIFT system depends on the US, US laws get to decide who cannot have a bank account, as when the US recently classified a couple of Swedes as terrorists.

I also have a problem because my eldest is old enough to go places on his own, but many years before he'll get a bank card or smart phone. Some of the places which no longer accept cash are public toilets (card only), the local minigolf course, and the swimming pool.

When I was that age, my Mom would give enough money to go somewhere and be able to pay for a ticket and maybe a snack or soda.

In a cashless culture, I don't see how my kids will have that level of independence from us until they are old enough to have a bank card.

My eldest still loses his library card about half the time, so that's not going to be soon, and their first phones - which will not be smartphones - won't be for years.

Bank provided causes problems with people who don't have bank accounts. Here in Sweden most people use bank-provided electronic ID called "BankID".

Quoting "Foreign citizens in Sweden blocked from BankID after several banks roll out new rules" https://www.thelocal.se/20220117/foreign-citizens-in-sweden-...

> “We have been working systematically for six months to get residence permit cards, then a personal number, then a Skatteverket national ID card, and finally bank accounts. To our shock, we were just told by ICA Banken that the Skatteverket National ID – the only one available to non-citizens – is not a valid source of identification for BankID.”

BankID causes problems because it isn't designed for the interests of the whole population. For example, it requires proprietary software which only runs on Microsoft Windows, macOS, iOS, or Android, with hardware verification and Google services.

This makes it unacceptable to free software advocates, and to privacy advocates, and to national data sovereignty advocates .. the total population of which is so small as to not affect the banks' commercial interests.

One thing I learned recently is how the US can, with its control over the SWIFT banking network, tell banks in other countries to shut down the account for a local citizen who the US has designated a terrorist. At least that's what I gather from the news I read after two leaders of the biggest neo-nazi group here in Sweden were designated as terrorists by the US.

If the goal is to keep power out of government hands, don't look to highly-regulated banks which are subject to the whims of multiple governments.

Ideally, a Sweden would be taking the considerable parental leave policy - over one year distributed among both parents, and preschool starts at 1 year old, so working parents don't often need to have the kid present while working.

The recommendations are at https://www.folkhalsomyndigheten.se/livsvillkor-levnadsvanor... .

It does say that video calls with relatives and looking at photos is okay, otherwise, avoid where possible.

When it isn't possible, like if an older child is using digital media, sit with them to discuss and explain what's going on, at a level they can understand.

https://www.folkhalsomyndigheten.se/livsvillkor-levnadsvanor... suggests that if you need to your your phone or other screens, for example, to check the bus schedule, buy tickets, or communicate with the school, then tell the kid what you are doing so they know it's for practical matters, not for entertainment or pastime.

Back in the 90s I implemented a ribbon diagram representation for VMD, a visualization program.

The first problem is secondary structure assignment, that is, which are the alpha helices, beta sheets, and other (coil/turns). The standard approach was from Kabsch and Sander, but their implementation, DSSP, wasn't really meant for library/automated use.

Instead of re-implementing it (like Roger Sayle did for RasMol, for example), I used Stride, from Frishman and Argos, which we distributed with VMD.

The alpha helix path was pretty simple - use a Catmull-Rom spline using the C-alphas as control points. There's a free variable which corresponds, as I recall, to tension. I tweaked it until it looked right. (By this time I had stared at a lot of ribbon diagrams.)

Getting the plane of the ribbon was hard. I never figured it out. I looked at the Raster3D implementation to get the algorithm. I then asked the main developer, Ethan Merritt, for permission to use the method. He said yes, and added that they in turn got it from the O molecular modeling program.

The beta sheets were mostly a matter of fitting a curve to the alternating C-alphas, being careful to keep twists less than 180 degrees.

Then there's a bit more to make things joined up.

It was decent, but not great. For one, our internal display lists didn't handle norms in a way that would result in smooth curves. All we had were cylindrical segments.

It was latter rewritten, which is why the current version is(was?) called "New Ribbons".

For what it's worth, I did meet Jane Richardson once, when she visited our lab.

Yes, and someone followed up with that suggestion.

But the problem is that someone needs to do it. Jan Labanowski is xkcd's "random person in Nebraska", a computational chemist volunteering unpaid time, on a 30 year old code base. That isn't so easy to step into, computational quantum chemists who are interesting in doing that migration are as rare as hen's teeth, and why would a non-QC systems developer help?

Yes, there are other mailing list hosting options, but the style and character of CCL is atypical enough that it warrants commentary in Wikipedia, at https://en.wikipedia.org/wiki/Computational_Chemistry_List . It is unlikely to be transplanted elsewhere.

It is that sort of independent web which gets smothered by Google's near single-handed ability to determine what people are allowed to view with Chrome, in this case in the name of "security".

Because the person who is charge is not a software developer, systems administrator, or anything like your background, so is unable to explain things in your terms.

Chrome's ability to control how people interact with the world is also contributing to the death of the old, independent web. From an email yesterday from the administrator of the Computational Chemistry List (which started in 1991), at https://server.ccl.net/cgi-bin/ccl/message-new?2024+08+08+00... :

> I have to redo the CCL Web Site, since currently all pages that are not "secure" (https) will not be displayed in Chrome and some other browsers. So http is gone and practically replaced by https. The http pages are treated as insecure, and you cannot view them as http://www.ccl.net like before. The whole site needs to be redone (I mean gigabytes of stuff). This will be a painful process and the problems will persist for a while. [...] I hope I will finish this conversion before I die... If not, then, Bye, Bye, CCL.

Last fall I almost missed my ferry because my train up to Hamburg was so delayed that it missed my connection to Kiel, and my backup connection pulled out just as my arriving train was stopping.

I knew things were getting bad in Germany so I had planned for enough time for a secondary backup. It left on time, but kept getting slower and slower. Then they announced that due to rail works, there was a bus from Neumünster to Kiel.

At Neumünster, I instead got a taxi, which (thanks to all the taxes going to the Autobahn instead of rails, I presume), got me to the ferry with a peak speed of 150kph, and 10 minutes before loading ended - some four hours after I had planned to be there.

It is the most widely used FOSS package in its domain, with Open Babel and CDK as the main alternatives. RDKit has far more active development.

The "machine learning" part is mostly historical. When RDKit started there were few packages, like scikit-learn, for machine learning, so RDKit included its own implementations.

I knew one of those too. I consulted for a company across the street from the Palo Alto general aviation airport. The doc/pubs manager lived some place north of Sonoma. She would fly in, walk across the street, and go to work.

At another job, the project manager lived in WA but worked in Palo Alto. He flew (commercial) in early Monday, with a small apartment to live in during the week, then take off mid-afternoon Friday to be back in WA with his family for the weekend.

When I was a kid in Miami, I read about people commuting to work by jet ski. This was before they replaced the Rickenbacker Causeway drawbridge with the William Powell Bridge, and the commute from Key Biscayne into Miami could be delayed and backed up, as boats had the right-of-way.

Yes, you have the right understanding.

I plan to be at the RDKit User Group meeting in Germany this fall. You might think of participating, even remotely.

My comment about SMILES strings size was meant to highlight how the 20 bytes you use is quite a lot of data.

Yes, the binary RDMol is larger than the SMILES - it can also store more data, including coordinates and extended stereochemistry, which cannot be expressed as a SMILES.

If you are just worried about structure equivalence, and you consider the canonical SMILES to be the best way to check for that (which your snippet does), and you don't mind the additional space and creation time, then put the canonical SMILES into the database along side the binary, and index on the string.

If you don't want any extra space or creation time overhead, then you end up with the design you've seen, where it tries hard to work with values easily computed from the molecule.

It seems like you're looking for an intermediate, with fixed space.

If you just want fast identity tests, and are willing to take a small fixed space, and aren't so concerned about database creation time, then you can generate the SMILES and hash them to a fixed width. Even 64 bits should be good enough to filter all but a handful of mismatches.

You can also use one of the molecule hashes, which are faster to compute, but will have a higher false-positive rate. (But still less than what your current scheme uses.)

It looks now like you want something which can also be used as a substructure screen.

That's in general what substructure screens are designed for. There's a long and dusty history of developing substructure screens, which is mostly forgotten these days now that compute power and memory are so cheap.

Consider that the MACCS keys were developed in the 1970s as a substructure screen, with 166 bits, or just slightly higher than the 160 bits you use in your prefix.

Coming up with a good 128-bit or even 64-bit screen is a topic I've wanted to investigate for a long time. The furthest I got was http://www.dalkescientific.com/writings/diary/archive/2012/0... from about 12 years ago.

I mention a 54 bit fingerprint. It's available at https://www.mail-archive.com/rdkit-discuss@lists.sourceforge... . I'm told it's pretty decent, but I haven't put it to practice myself.

If you do more in this area, I've managed to gather some queries (identity, substructure, and similarity), in my Structure Query Collection, at https://hg.sr.ht/~dalke/sqc .

If I follow it correctly, you've reduced the search time by pre-computing some of the comparison information and storing it into the database. This increases the database creation time but decreases the search time.

You've decided to store some of the numeric values in the database, stored as 5 32-bit integers, or 20 bytes of data.

20 bytes is a lot of data. A SMILES string averages about 60 bytes. If you are willing to take the additional record creation overhead you could generate the canonical achiral SMILES, hash it (eg, as the first 20 bytes of the SHA256, or even a non-cryptographic hash like SipHash), and use that as your prefix. That should give you a near perfect test (120 bits implies roughly 2^60 structures needed before there's a 50% chance of a duplicate hash.)

Alternatively, consider something like https://www.rdkit.org/docs/source/rdkit.Chem.RegistrationHas... or https://www.rdkit.org/docs/source/rdkit.Chem.rdMolHash.html (examples at http://rdkit.org/docs/Cookbook.html#molecule-hash-strings ) to generate the hashable string. These should be faster to generate than a canonical SMILES, giving you an ability to tune database creation performance with search performance.

???? Sweden is a great country to be a parent. Source: I'm an immigrant to Sweden with two Swedish-born kids.

My mother was one of 8. That doesn't make rural Michigan in the 1950s a great place to be a parent. That means, as an aunt put it, that my grandparents didn't know about birth control.

My Mom's a widower living on her husband's pension. My sister and her spouse both work, with good incomes.

Of course my sister paid my Mom to babysit the grandkids.

I think it's because the author's native language is Swedish and had a harder time seeing mistakes which use Swedish instead of English.

"There were no adress and the" is another example - the Swedish is "adress" while the English is "address".

I'm old enough that my father worked for one of those "golden age" companies. https://en.wikipedia.org/wiki/Wometco_Enterprises

It was a conglomerate, starting with theaters then adding TV and other entertainment, plus soft drink bottling and more.

The individual companies were well funded, they had plenty of staff, and there cross-company staff discounts. My dad worked for the TV station WTVJ and we got discounts to go to the movie theaters owned by Wometco.

There was a yearly Christmas party for staff and family, and the Wometco would be flown in by helicopter, dressed as Santa.

After his death it got bought by KKR in a LBO, split up, and sold for parts. Staff was greatly reduced and overworked. The Christmas party was no more.

As someone in the EU, I can say that's not realistic.

The apps for my bank, the local bus transit system, electronic payments, and even my kid's school, are only available for iOS and Android, and the first three use Google exclusionary software to lock out non-Google OSes. You must have a Mac or Windows computer, or iOS or Google Android, to run the proprietary software used as single-sign-on for most government web apps.

Very few are willing to live without those apps.

FWIW, the traditional, 1980s approach uses fingerprints, which are binary vectors. Here's the same search using RDKit's "Morgan" fingerprints, with radius 2, and count enumeration simulation enabled, using my "chemfp" project.

  % curl -O 'https://gist.githubusercontent.com/fzliu/8052bd4d609bc6260ab7e8c838d2f518/raw/f1c9efb816d6b8514c0a643323f7afa29372b1c4/fda_approved_structures.csv'
  % chemfp csv2fps --type "RDKit-Morgan radius=2 countSimulation=1" fda_approved_structures.csv -o fda_approved_structures.fps
  % simsearch --query "CC(C)CC1=CC=C(C=C1)C(C)C(O)=O" -k 10 fda_approved_structures.fps --out csv
  query_id,target_id,score
  Query1,Dexibuprofen,1.0000000
  Query1,Ibuprofen,1.0000000
  Query1,Loxoprofen,0.5185185
  Query1,Tyrosine,0.4782609
  Query1,Suprofen,0.4716981
  Query1,Iofetamine I-123,0.4583333
  Query1,N-acetyltyrosine,0.4339623
  Query1,Naproxen,0.4259259
  Query1,Hydroxyamphetamine,0.4222222
  Query1,Carprofen,0.3898305

This is where it would take a pharmaceutical chemist to compare the two lists.

For example, Suprofen is a nonsteroidal anti-inflammatory drug which made my list but did not make the other list. There are oodles of ways to compare molecules, and decades of discussion about when to use what.

Also, RDKit could not parse two of the SMILES strings:

1) Cyanocobalamin has a 4-valent nitrogen

  Explicit valence for atom # 84 N, 4, is greater than permitted

2) Temoporfin uses an invalid bond notation in "C\-1N2".

These are the sorts of issues which require a deeper analysis to detect than molecule_vectorizer provides.

EDIT:

It looks like molecule_vectorizer uses RDKit to parse the SMILES string and generate RDKit fingerprints by default (or Morgan fingerprints as an option). These are binary, and count simulation wasn't used.

Those SMILES parse errors should have been caught as part of the process. Without digging deeper, I can't figure out what happened.

(My initial guess was that used text-based tokenization, like the n-mer approach in "Lingos, Finite State Machines, and Fast Similarity Searching", by Grant et al.)

Knowing now that it uses the RDKit path fingerprints, I can re-run chemfp on the same data set:

  % chemfp csv2fps --type RDKit-Fingerprint fda_approved_structures.csv -o fda_approved_structures.fps
  % simsearch --query "CC(C)CC1=CC=C(C=C1)C(C)C(O)=O" -k 10 fda_approved_structures.fps --out csv
  query_id,target_id,score
  Query1,Ibuprofen,1.0000000
  Query1,Dexibuprofen,1.0000000
  Query1,Loxoprofen,0.6725664
  Query1,Phenylacetic acid,0.5175439
  Query1,Naproxen,0.5056180
  Query1,Fenoprofen,0.4825737
  Query1,Ketoprofen,0.4333333
  Query1,Dexketoprofen,0.4333333
  Query1,Mandelic acid,0.4127517
  Query1,Oxeladin,0.4080000

which is a perfect match to the list given on the linked-to writeup.

That's far from enough.

I set up a company, had a no-cost+open source version for download, and a money+open source version ("commercial") for purchase, both with an MIT license. The commercial version was faster, with more features, and included support, and it was in the marketing literature from the start.

The goal was to give users a way to justify the expenditure to their budget people.

It didn't help. I was even at an open source conference where one of the industry presenters complained about how hard it was to pay open source developers.

Thing is, the presenter earlier gave a talk about their extensive use of my software - first time I knew they used it.

I pointed out that I could get them an invoice within 10 minutes, for an improved version of the tool they were using, plus support.

They did not take me up on the offer.

I now generally interpret "it's so hard to pay for open source" as cover for "we've heard it's hard so it's our excuse for why we don't even try."

I've tried other approaches too, like a consortium model for new feature development and support/maintenance. It wasn't enough to be economically viable. Yet companies include that software in products they sell. A few years ago I asked one of them for money for support, and was told it wasn't in the budget. What they do now is ask the current maintainers for free support.

My advice: if you plan to write OSS for a living, work for a company where that project demonstrably saves them money and/or lowers their risk on external vendors. Do not try to be an independent open source software vendor.

Quakes came out in, what, 1996? And was written by some of the foremost practitioners of computer graphics?

We were a couple of physics grad students working on a side project in late 1993. My background was a semester course based on Foley & van Dam. Hardware gave us a 5-10 year lead over what we could have done with consumer tech.

There wasn't really a "rest of CG". Only the highest-end SGI machines at the time had hardware texture mapping - most did it in software (see https://en.wikipedia.org/wiki/Extreme_Graphics).

We aren't talking 2D organo-chem hexagons, but 3D spheres and cylinders. Back around 1995 I posted some benchmarks to Usenet about the different approaches I tried (including NURBS), but I can no longer find a copy of it.

The straight-forward way is to render the spheres as a bunch of triangles, so, what, 50 polygons per sphere? Times 100,000 spheres = 5 million polygons. That was large for the time, but doable. Plus, during movement we used a lower level of detail.

What was Quake's polygon count?

Oh, and we're displaying animated molecules, including interacting with a live physics simulation, so no pre-computed BSP either.

Rastering spheres quickly on a PC was also possible then, which was RasMol's forte, but it was flat compared to having a couple hardware-based point lights plus ambient lighting.

Interestingly, AutoCAD (RIP Walker) tried to get into molecular modeling, but it didn't work out. https://www.fourmilab.ch/autofile/e5/chapter2_82.html

We've talked before about our respective molecular graphics background.

I started with Unix on a Personal IRIS as an undergrad working in a physics lab which used it for imaging capture and analysis. I was the nominal sys admin, with one semester of Minix under my belt and just enough to be dangerous. (I once removed /bin/cc because I thought it was possible to undelete, like on DOS. I had to ask around the meteorology department for a restore tape.)

The summer before grad school I got a job at the local supercomputing center to work on a parallelization of CHARMm, using PVM. I developed it on that PI, and on a NeXT. That's also when I learned about people at my future grad school working on VR for molecular visualization, in a 1992 CACM article. So when I started looking for an advisor, that's the lab I chose, and I became the junior co-author and eventual lead developer of VMD.

With a Crimson as my desktop machine, a lab full of SGIs and NeXTs, and the CAVE VR setup elsewhere in the building. Heady times.

I visited SGI in 1995 or so, on holiday, thinking that would be a great place to work. They even had an Inventor plugin for molecular visualization, so I thought it would be a good lead. I emailed and got an invited to visit, where the host kindly told me that they were not going to do more in molecular visualization because they wanted to provide the hardware everyone uses, and not compete in that software space.

In the early 1990s SGIs dominated molecular modeling (replacing Evans & Sutherland), so naturally the related tools, like molecular dynamics codes, also ran on them. But we started migrating to distributed computing, where it didn't make sense to have 16 expensive SGIs, leaving them more as the head .. which as you pointed out, was soon able to run just fine on a Linux machine.

Sweden doesn't require that you have id to vote. You could alternatively bring in someone who will vouch for you and can present their id and personal id number.

https://www.norden.org/sv/info-norden/rostratt-i-sverige

> För att kunna rösta ska du kunna styrka din identitet. Du styrker din identitet genom att visa upp en giltig id-handling eller genom att en annan person kan bekräfta din identitet. Då måste den som bekräftar din identitet kunna uppvisa id-handling och ange sitt personnummer.