Google Trying to Solve a UUID | Hacker News Reader

Google Trying to Solve a UUID

google.com

307 pointsmococa151 comments

Open articleView on HN

Similarly, I once needed some new robust tyres for my folding bike, so I googled 'marathon plus 20 inch'.

Google helpfully informs me that

marathon + (20 inches) = 1.00001204 marathon

So that's what the "1.00001204" bumper sticker means!

I once googled for SEC scores on a Saturday during football season and it said 2.45048752096, which is sec(20).

Perhaps AI is developing a sense of humour...

Interesting! Anyone have any idea about what wolfram alpha's interpretation of the same query is? https://www.wolframalpha.com/input?i=marathon+plus+20+inch

WA tells you: it's converting 20in = 10^-5 marathon lengths.

Google refuses to search for hash-like strings that aren't well-known across the web.[0] That's why this search gives no actual results. (It certainly will in the future as this submission gets reposted, breaking the googlewhack)

[0] https://news.ycombinator.com/item?id=31638976

(I think Bing also blocks hashes but has an exemption for UUIDs; right now it gives me results for random UUIDs but not random MD5s)

Bing and Yandex are both capable of locating OP's Minecraft account in online databases:

https://web.archive.org/web/0/https://www.google.com/search?...

https://web.archive.org/web/0/https://www.bing.com/search?q=...

https://web.archive.org/web/0/https://yandex.com/search/?tex...

PS: example of an uncommon hash that Yandex finds but not the other two: the MD5 of 'Hacker News' (f3e4...), which actually occurs on the web on one site (http://archive.ph/oLgUe http://archive.today/lkyNN http://archive.ph/v3TY5)

What's the reasoning behind the design decision 'refusing to search for hashes', what grounds would they have to block such searches?

I also would like to know. My guess is maybe password dumps?

This was my first guess

This is as much a stab in the dark as any, but as someone that builds/rebuilds ROM sets pretty often (leading me to do a lot of hash-specific searches) I've noticed that there's a lot of crypto-trading related hashes in the indices they maintain.

I'm assuming what happens is that the hashes for various blockchain transactions have a lot of common sub-strings within that collide with non-crypto stuff, hence why they get offered.

Maybe the folks that manage the search engine were finding that these crawls were adding a lot of useless info and just blanket blocked their inclusion?

Might just be to reduce the size of the index.

Not sure if they still do, but they used to map keywords to integer identifiers, instead of using the actual string value (string indices get very big). Page and Brin themselves explain it here[1]. I do the same in my search engine.

Problem is there are a lot of junk identifiers, so there's a point to reducing the scope by eliminating probable noise-keywords that are unlikely to ever be relevant to any search. UUIDs and hashes would probably fall into that scope, since they have a very large namespace that can very easily gunk up the lexicon with words that are never ever going to be relevant. You'd probably want to keep the word identifier 32 bits if you can get away with it, but maybe 64 bits for a global search engine like Google.

[1] http://infolab.stanford.edu/~backrub/google.html (section 4.2.4)

I really enjoy reading your comments on HN. I found your search engine on Gemini then see you post about search engines every now and then.

You have a great ability to break things down in a way that makes sense.

Hey, thanks man.

I don't feel like I do a very good job at explaining things for the most part, but maybe that's not a very reliable indicator of whether what I write makes sense. :P

The top Comment of [0] of the OP has a likely scenario: malware offers periodically searching for hashes of their malware to see if it's detected on the web, without having to submit it to virus scanning websites (as most online virus scan engines will automatically submit the executable for automated malware analysis).

Ha, the search in the submission now points to the version of itself that I saved in archive.ph, which didn't get the equation solver feature. But archive.org did; maybe change it for posterity to https://web.archive.org/web/20220806203457if_/https://www.go...

meta: apparently HN penalizes comments that have been edited to be too different from what was originally posted -- I tried adding this to my parent comment, which sent it far down the thread, which was then reversed upon editing it back

That's pretty funny. I work for a company that puts 5 alphanumeric characters on physical devices to track and identify them. We are always putting those 5 characters into various google sheets. And every so often one had an E in the middle of all numbers and google would convert by default to something like "1.10E+34" so we had to make SCIENTIFIC_NUMBER_REGEX = Regex("\\d+e\\d+") and stop making codes with E's in the middle.

Why not just set the column to text?

I assume avoiding any issues popping up from having to remember to do that is worth the reduction in state space.

(10 + 23)^5 = 39,135,393 which is enough for company devices

I assume there’s a row or column that this applies to in their sheet. So I’m suggesting instead of having some regex applies to check the values. Just setting the entire row or column to text would resolve the issue.

When he says "various google sheets" it sounds like new ones are occasionally created so you would have to do that each time a new one is created. It's extra friction which you can easily avoid.

But he’s putting a regex into the sheet? Unless he has some tool to look at the spreadsheets in gdrive and applies the regex to them? Guess we lack info from the OP.

The regex goes into their UUID generation routine, to stop it from ever generating another UUID with an E in the middle.

Why 23?

Guessing no I, L, or O to avoid confusion with numbers.

At that point I feel like you should just use base32 instead of 33.

For just removing digits-E-digits, that's 10000 patterns for each E position, of which there are 3. Since 36^5 is over 60 million, you're only removing a twentieth of a percent of values. Closer to a tenth of a percent if you remove those values from 33^5 or 32^5.

It's more useful to look at the total amount of values rather than how much the space gets reduced. If you have 10s of millions of values you can have several devices for even the largest employers that exist today.

It was I, O, and E.

When generating human readable alpha codes, never include vowels.

Avoid generating codes like FARKU, WANKR, USUCK etcetera.

This reminds me of this one from a couple of years ago: https://www.theverge.com/2020/8/6/21355674/human-genes-renam...

“Scientists rename human genes to stop Microsoft Excel from misreading them as dates”

> …over the past year or so, some 27 human genes have been renamed, all because Microsoft Excel kept misreading their symbols as dates.

> The problem isn’t as unexpected as it first sounds. Excel is a behemoth in the spreadsheet world and is regularly used by scientists to track their work and even conduct clinical trials. But its default settings were designed with more mundane applications in mind, so when a user inputs a gene’s alphanumeric symbol into a spreadsheet, like MARCH1 — short for “Membrane Associated Ring-CH-Type Finger 1” — Excel converts that into a date: 1-Mar.

Original paper leading to the changes: https://genomebiology.biomedcentral.com/articles/10.1186/s13...

And I still can’t believe that after multiple decades it removes the leading “0” for things like zip codes. It does this even though the default data type for cells is “general” and not explicitly numeric. To my thinking that should cause excel to defer to the source data characters.

When I worked at a lower level I had to deal with this constantly when folks doing mail merges had bad zip formats coming through, and as the “data guy” it all got referred to me to fix.

Still, I think excel is great when used within certain confines. I use it for ad hoc purposes all of the time for simpler bits of work that are one-offs where it would take a fair bit longer to explore the data a bit and make some minimally presentable visuals & tables and some inline notes on analysis and interpretation.

> the default data type for cells is “general” and not explicitly numeric. To my thinking that should cause excel to defer to the source data characters

you think zip codes are a more common use case than numbers?

I think if you explicitly type in a leading zero with five digits it seems reasonable that it should infer it’s a zip code.

Maybe, given the appropriate locale in the system settings.

Oh no, Jesus, please no. Nothing better then Excell file what behaves completely differently when moved to another computer, purely because of something like locale in system settings.

First, you should not conflate the locale of the user or program with the locale of the (span in the) file.

Second, how would you handle international addresses? For many businesses, a program that can't do that would be useless.

programmers who don't work with time be like

It needs Clippy-ing: "recognise column as zip codes? always, now, not now, never, turn off format recognition".

If the column is going to be called something stupid like A, B or C clippy is going to have a hard time....

I would expect it to leave my data alone unless told so. It’s one of the little things that drive me crazy with Excel the few times I use it, and every time I need to search how to make it behave because I don’t use it nearly enough to remember.

I would expect it to store 01234 as a number unless explicitly told to store it as a string. This is exactly how it should work. I’m all for hating on excel but being upset because the software can’t read your mind and your eccentric edge case isn’t automatically picked up is a bit entitled

I think I want to do the opposite of reading my mind to be honest. The default cell type is generic, so just assume everything is a string and don’t do any parsing. Maybe show a tooltip to quickly change the cell type if you detect something that might be a number or a date.

Probably it’s just different usage - when I use excel is mostly to store a table of raw data where I want to store the actual data, not what excel thing the data is. I’m using it as the equivalent of a database, but simple to update and share with other people (even not technical folks) or to open a csv and quickly hide/filter some data.

> The default cell type is generic, so just assume everything is a string and don’t do any parsing.

So, if you have `1234` in A1 and `5678` in B1, `=A1+B1` should by default produce `VALUE ERROR` rather than `6912`?

That's... not why spreadsheets were invented.

> when I use excel is mostly to store a table of raw data where I want to store the actual data, not what excel thing the data is. I’m using it as the equivalent of a database,

Then use a database program, not a spreadsheet!

However, if there are no database programs that fit your needs, and you end up using a spreadsheet instead, don't complain that the spreadsheet acts like a spreadsheet instead of a database. It's not the tool's fault that you're the one using the wrong tool for the job.

> So, if you have `1234` in A1 and `5678` in B1, `=A1+B1` should by default produce `VALUE ERROR` rather than `6912`?

If you didn't change anything else, just made A1 and B1 text cells, then adding them would still return 6912.

> That's... not why spreadsheets were invented.

It's decades later. Why they were invented is not the priority.

> Then use a database program, not a spreadsheet!

Databases only have a fraction of the capabilities of a spreadsheet. That's not a reasonable response.

Umm, if you are treating them as text cells, then adding them would product 12345678 since you are concatenating strings. I just don't think there is any good solution for this, since it's effectively impossible to automatically distinguish numbers that the user wants to treat as strings (like a zip code) and numbers that should be treated as floats or ints.

+ is not concatenation in any spreadsheet program I've seen, and it probably shouldn't be concatenation in anything. That's the solution, having a separate concatenation operator.

the '+' operator provides concatenation of strings in both python and C; in Excel, you use '=CONCAT()'... just syntactic differences, is all.

Yeah, I spend more time doing data manipulation in python than in excel, so I thought that excel would do that as well.

It's not just a syntactic difference. It's a huge UX difference that one operator always does an addition on both numbers and numeric strings, and another operator always concatenates both numbers and numeric strings.

The looser your typings the more it matters, and spreadsheets barely even have types.

In C? How?

sorry, meant cpp! C (apparently) uses a function that more closely resembles Excel

C has strcat but that only does the easy part - allocating and freeing the memory is still the caller's b job.

Tend to agree that choice of + for string concatenation was a mistake - anyone know the history/first widely used example? Did the original BASIC have it? (I think QuickBasic did, but that's unlikely to be the origin).

Edit: found https://retrocomputing.stackexchange.com/questions/20460/wha..., suggests it was ALGOL-68.

+ is not a cancatenation operator in excel. It is numeric addition. It is added the numeric values of which the letter characters are merely a representation then that answer would be the same as if excel treated them as numeric data types.

Alternatively, if you don’t want excel to perform addition on underlying numeric values but instead only on defined data types then the formula could result in NaN which would signal to the user that the explicit data type was not compatible with addition.

I know, complaining like this probably doesn’t make sense. It’s a minor issue to begin with and I’m probably an edge case as far as excel users go. It doesn’t make sense for MS to tailor its product for my type of user.

Databases only have a fraction of the capabilities of a spreadsheet. That's not a reasonable response.

There’s nothing you can do in a spreadsheet that an RDBMS can’t do.

Programmers often object to spreadsheets because they’re too “brittle”. I don’t think it’s an unreasonable objection.

Most spreadsheet users don’t exhibit the rigor necessary to impose a schema on their spreadsheet-based data, nor to use features like named ranges to abstract away the physical location of data in the spreadsheet from its semantic meaning. Data validation is an afterthought, too. Spreadsheets invite silent errors when rows or columns are inserted or removed, data is copied/pasted, etc. It takes more effort, in my experience, to keep the formulae in a spreadsheet working in the face of modifications versus a database.

A database explicitly separates the data from logic (at least, typically— getting into queries that act conditionally based kn queried data blurs that line a bit) and provides a strong schema and enforced validation at the time data is added or modified. You’re not going to get wrong answers from a database query because somebody added a row at the bottom of a range that isn’t covered by a SUM(), for example.

...I logged back into my lurker account just because of how annoying this was- I use Google Sheets all the time to do data visualization and analysis work because it just works, and because I can share my results with other people, and let them explore the data in a format that they understand.

There's a reason lots of MBA types get issued high-performance, high RAM machines- because asking them to learn SQL or whatever AND asking them to learn how data structures and query syntax work instead of just doing things a little more slowly and throwing more performance at Excel makes a lot of sense.

Not saying it's perfect, but please don't hate on Excel et al because they aren't the perfect world way of doing things.

And even if you do teach them proper database queries, that doesn't give you a nice editable view of multiple interlinked queries and parameters, with output organized into charts and graphs. The best option down that road isn't switching to a database program, it's using a spreadsheet program that can do SQL.

Spreadsheets are great for ad hoc work. I think they’re intuitive and agile. I use them for that purpose too. All the time.

Using them for business processes is a recipe for sadness. People don’t have the discipline to use them for that, and the tools have too many shortcomings.

In terms of “exploring data” I’ve been in way too many meetings where different users have worked on forks of the same original spreadsheet and come up with contradictory answers.

Re: slowing people down - I’ve had the fortune to show a few “MBA types” how to do JOINs in lieu of the eldritch horrors they’d created attempting to re-implement JOIN with VLOOKUP. The productivity gains were significant. Excel is using a screwdriver to drive nails in some very glaring cases.

> Using them for business processes is a recipe for sadness. People don’t have the discipline to use them for that, and the tools have too many shortcomings.

> In terms of “exploring data” I’ve been in way too many meetings where different users have worked on forks of the same original spreadsheet and come up with contradictory answers.

You shouldn't use a notepad of SQL statements for processes either!

Once certain things are figured out and planned around for repeated use, they need to be transformed into a proper maintainable form, probably involving careful code with error detection. But that's not a spreadsheet vs. SQL issue. If SQL causes fewer problems it's probably because someone that knows SQL is more likely to have programming knowledge/discipline, not something about SQL itself.

> Re: slowing people down - I’ve had the fortune to show a few “MBA types” how to do JOINs in lieu of the eldritch horrors they’d created attempting to re-implement JOIN with VLOOKUP. The productivity gains were significant. Excel is using a screwdriver to drive nails in some very glaring cases.

It's great to use a JOIN when it's appropriate. But a lot of the time there's still no real need for a database, and you want all the other tools a spreadsheet has. Or there is a good case for a database, but the best answer is having some queries that feed the spreadsheet.

> So, if you have `1234` in A1 and `5678` in B1, `=A1+B1` should by default produce `VALUE ERROR` rather than `6912`?

If they were text, I'd expect it to end up as `12345678`, personally. + being reasonably commonly overloaded to mean string concatenation.

Wat.

Excel uses & for string concatenation. Excel considers + to be an arithmetic operation. Excel is a spreadsheet.

you are so not the target user my dude

Maybe, but it seems weird for it to be completely unreasonable for operator overloading to be a thing, but also expect the user to have a working knowledge of basic data types.

Everyone uses Excel as a database, and Excel should absolutely tackle this. It’s like “Everyone is using Toyota to carry children to schools in underdeveloped countries” so let’s put seatbelts, you know, even if it’s not the intended usage.

The French government believed that Covid cases had stopped increasing, because their federated Excel spreadsheet was silently truncating data at 1 million rows. Accidents like this happen all the time.

Access should be based on Excel, only adding sheet types: single-record forms, SQL reports, pivot tables.

In fact, pivot tables are the proof that Excel is a database tool.

> It’s like “Everyone is using Toyota to carry children to schools in underdeveloped countries” so let’s put seatbelts, you know, even if it’s not the intended usage.

WTF? Are you saying Toyota don't normally put seatbelts in their cars? Like... what???

In the bed of pickups, maybe?

I think the usage to store other type of type is getting popular very late after excel has being invented.

It was created to count money. So it would make sense to defaults field to number unless it obviously isn't.

People are just using a tool that isn't designed for your current purpose.

I think probably the best change it can do is don't alter the data at input. Instead, alter it at display and compute. Then it won't actually corrupt your data anymore.

Then for a wrong field type, you just need to change the type, and the correct data will be displayed as expected.

Your expectation is that it should destructively change what you enter? Why not even just store what I put in and cast when necessary?

Zip codes are not a weird edge case either.

They're weird in that they are text codes rendered exclusively in digits in the US. Most Americans are generally ignorant of this and blissfully input them as numbers and those in the east with leading zero codes have to deal with the blowback.

Storing a zip code in a column of an excel file is by no means an eccentric edge case. If I type 01234 into a cell, it’s not unreasonable to expect excel to save it (and reproduce it in e.g. a mail merge) that way.

I would expect it to store 01234 as a number unless explicitly told to store it as a string.

These days I'd disagree. Once upon a time explicitly column delimited data with leading 0 padding may have been common, but I suspect in most software written in the last 20+ years leading 0s if included are more likely relevant parts of the data rather than Hollerith card default punches.

excel users don't think like this

Excel users use leading zeroes to indicate they are using a punchcard based format? Seems… unlikely

not what i'm saying. the vast majority of people who work with spreadsheets have no interest in redefining it to align with other paradigms. spreadsheets work damn well as they are

and spreadsheets would not break if 02559 were stored as 02559, so what's the problem?

it would break tens of millions of people's expectations. decades of muscle memory for many people. pretty big effect for no objective benefit

When writing a number you never start with a zero. If something never happens you should favor the scenario that happens quite often.

If I type 000012 why would you think I wanted 12?

12 is equal to 000012

If you're in the context of math, yes. Otherwise no. How often are you both doing math and _also_ bizarrely typing leading zeros? Who does that?

I would expect it to not destroy data.

I don't care how it stores it but if I've input 01234 either manually or via a CSV import etc. I do expect it to remember that there was a 0 at the beginning. Excel's lossy data type conversion has caused more problems than I care to remember over the years. One of them caused a significant sum of money to be deposited in the wrong bank account once.

If I explicitly typed a leading 0, I want it to stay unless I'm typing it into a numeric cell. In that case I'm doing something strange and wasting my time but what I want is obviously 1234.

Why would anyone type a leading zero on a number? The only time I _ever_ do that are parts of dates, which this wouldn't hit, and octal numbers extremely rarely in code.

I think cases where I want to preserve the leading 0s vastly outnumber cases where I don't.

The leading +1 on international numbers is a pain too.

Zip codes are easy to fix.

What’s painful is when a file has phone numbers and excel helpfully converts them all to scientific notation.

I always prefix zipcodes with a single quote. It tells Excell “this is text” and the leading single quote does not render.

It's little things like parsing unmatched leading single quotation marks as meaningful non-errors that contributes the "hate" component of my love-hate relationship with Excel.

Excel is also super dangerous. All numbers are stored as double, which means that if you open a csv file that contains large int64 ids, they will likely be rounded. And then there are dates, and people who still think it is a good idea to store dates in a US or European format in a csv file rather than something unambiguous and universal (yyyy-mm-dd).

That doesn’t sound like a dengerous excel problem, it sounds like a sloppy ETL problem. Don’t import data blindly - check the date formats for example.

That's nice in theory, but in practice people do it. https://www.theverge.com/2020/8/6/21355674/human-genes-renam...

That’s garbage. If I input a number in to a spreadsheet I expect that number to stay exactly as-is.

That a Excel could introduce bugs due to doing floats behind the scenes.... Completely unacceptable.

must be new here .. :)

Hahahaha

I appreciate that comeback. Well played.

Most programming languages don’t behave that way, either.

Why would we have to hold Excel to higher standards?

Now, that Excel stores binary floats, but tries to pretend to use decimal ones, that’s something I think we can blame it for.

From section 2 of https://people.eecs.berkeley.edu/~wkahan/Mindless.pdf:

Some parentheses in Microsoft’s Excel 2000 spreadsheet possess uncanny powers: Values Excel 2000 Displays for Several Expressions

  Expression              1.23456789012345000E+00   <– Entered to help count digits
  V = 4/3  displays…      1.33333333333333000E+00   Does Excel carry 15 sig. dec.?
  W=V- 1                  3.33333333333333000E-01   Whence comes the 15th 3 ?
  X = W*3                 1.00000000000000000E+00   Where went all 15 of the 9s ?
  Y=X- 1                  0.00000000000000000E+00   They all went away !
  Z = Y*2^52              0.00000000000000000E+00   Really all gone.
  (4/3 - 1)*3 - 1         0.00000000000000000E+00   Yes, gone.
  ((4/3 - 1)*3 - 1)       -2.22044604925031000E-16  (But not ENTIRELY gone !)
  ((4/3 - 1)*3 - 1)*2^52  -1.00000000000000000E+00  Excel’s arithmetic is weird.

> Why would we have to hold Excel to higher standards?

Because one of it’s main uses is for doing calculations with money?

I've seen a lot of compliance tests for credit card processing. These frequently will be Excel sheets with series of test descriptions. For example "Run a $12.45 sale on card number XXXXX with a tax amount of $1.73 and a shipping address of 1234 Main Street, 70242." Inevitably the card numbers are rounded. If you paste in a timestamp for the transaction result, that gets cast weirdly. I end up reworking the default formats for the sheet so that things will not be clobbered.

Raspberry pi serial numbers have a lot of zeros and when migrating device management solutions w/ a CSV set up in Excel we lost a lot of time from serials getting mangled like this.

I just don’t use excel anymore.

This reminds me of a story of a geocoder (postal address search) which was found to frequently fail in NYC. When they debugged, they found addresses in east Manhattan (e.g. 100 E 61 St) were being converted to scientific notation.

There many CUSIPs (strings) that Excel with convert to numbers (scientific notation).

I you want to avoid that "auto correct" behavior, prepend the cell contents with '. Eg '1e4.

In the place I work, builds used to fail if the commit short-sha is interpreted as a number in exponential notation (e.g. 67124e2). It happened surprisingly often!

https://imgur.com/a/FLiHwE1

I don't get this on mobile, thanks for posting the screenshot.

Interestingly, I do get this on mobile.

Google seems to disable a lot of features (e.g. package tracking) when I'm using Firefox mobile, but not Chrome.

There is an add-on for firefox mobile that changes the user agent to chrome when yoh visit a google page.

https://addons.mozilla.org/en-US/android/addon/google-search...

Huh, i opened in firefox mobile and just got "no results", but with chrome I do get the result.

That seems... very anticompetitive.

I'm on Firefox mobile and was confused what everyone was talking about until I saw this subthread. Very anticompetitive indeed.

works in Safari on ios

Not for me.

www.zdnet.com/article/former-mozilla-exec-google-has-sabotaged-firefox-for-years/

There's also experiments and staged rollouts, and if there's no hurry they can take a while.

I'm amazed that google does that (I didn't know) and even shows the steps! But it still is lacking.

The "solution" here is just a simplification, not something I would call a "solution" (like for an actual equation). But as it isn't an equation, that could be fine. Another weird thing is that it won't simply eliminate the first term with 0x=0. Why?

Same. At least in my years that I actually needed this, they didn't have it. So I use Wolfram Alpha [1]. (Well, you probably still should use that instead if you have extended use, since it's far more advanced).

[1] https://www.wolframalpha.com/

This UUID comes from my Minecraft account; I was curious to know if I could find something on the web. Not work on every UUID!

Moo!

I'm just getting a search returning no results rather than an attempt to solve anything?

What browser? Firefox Mobile needs a user-agent-switching extension to bypass Google's anti-competitive user-agent-sniffing suppression of fancy results widgets.

FYI your comments are getting automatically flagged. Might want to email hn@ycombinator.com (I think) to figure out why.

Too bad you can't send them a private message on HN itself... instead of using a third party service like email

It's a free service. Why put in the time and money to create and support. a messaging system when email works fine?

Its a public messaging system... Not sure why they get offended when I ask publicly... Either don't answer or do... Why waste time and ask me to use email instead... I'm not going to use email to communicate about a communication forum.

Ok then... don't?

They are under no obligation to answer you on any method, let alone through an official one that is relatively easy to access. Once again, it's a free service.

It's impressive that the search result has didactic steps towards a solution though....

Though my TI-89 pocket calculator could do that in the 90s

But could it search for porn?

I certainly tried

The boob function....

I’m imagining “the boob function” just ignores any input and returns 80085?

Didn't need to. The arbitrary precision was already boner-inducing.

> my TI-89 pocket calculator could do that

But that's not pocket size... what kind of pockets do you...

> in the 90s

Ohhhh, JNCOs!

Not very impressive, as it doesn’t immediately (or ever) eliminate the term with a leading `0` factor.

This is just nonsense. Garbage in, garbage out, nothing gained.

Google tries to interpret a UUID search query as a math equation and solve it.

We get it.

Tested with a few UUIDs:

$ uuidgen

2b2ec13b-a1a4-49da-938a-50b24a1e416a

Google - https://www.google.com/search?q=2b2ec13b-a1a4-49da-938a-50b2...

$ uuidgen --sha1 --namespace @dns --name "www.google.com"

488416f4-fcaf-5027-8c63-0105cfa213ea

Google - https://www.google.com/search?q=488416f4-fcaf-5027-8c63-0105...

Nothing. Maybe it is a bug?

Not a bug, there are actual search results for the last query. So probably a feature that since results exist, it's not a computation.

Those aren't valid expressions. It's when there aren't any numerals after a letter, then the letters can be interpreted as variables and the numerals coefficients (for each term separated by a subtract).

That's not it. Digits after letter didn't stop Google from interpreting the original UUID.

Oh you're right. it just considers them all multiplications, sometimes powers.

Only other difference I can see then is >1 contiguous letters in the UUIDS that didn't trigger it, maybe variables have to be single letter.

That's interesting, because on the other end, lately I had some cases where Google did not even recognize very elementary operations and would not give me the result. That never happened before.

I don't get this in firefox on ubuntu.

What does it mean to solve a UUID?

For some users it is mistaking a UUID for a math problem and trying to "solve" it.

On Android Firefox it just says there are no results. So if you ever need a UUID, just use that one; Google says it's good!

> For some users

a number probably infinitely small... Google might be the only user in this case

funny!

[0xe+3y] gets a graph of [14+3*y].

Exercise: Why?

Their calculator understands hexadecimal, and 0xE is 14.

One of several notations for hexadecimal used by programming languages. It did not understand 0eh or $0e to mean the same thing when I tried though.

It did however understand 0o16 (octal) ... and 0b1110 (binary), which is a bit surprising because it is a relatively new addition to C++ (C14) and C (C23).

0b is a gnu89 extension. It's been around a while.

Reply on news.ycombinator.com