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 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.
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.
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.
“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.
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?
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.
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.
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.
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.
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).
+ 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.
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???
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.
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.
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
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.
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.
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.
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.
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.
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!
What browser? Firefox Mobile needs a user-agent-switching extension to bypass Google's anti-competitive user-agent-sniffing suppression of fancy results widgets.
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.
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.
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).
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).
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.
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)
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?
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.
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
158 comments
[ 4.5 ms ] story [ 215 ms ] threadhttps://addons.mozilla.org/en-US/android/addon/google-search...
That seems... very anticompetitive.
Google tries to interpret a UUID search query as a math equation and solve it.
$ 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?
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.
(10 + 23)^5 = 39,135,393 which is enough for company devices
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.
Avoid generating codes like FARKU, WANKR, USUCK etcetera.
“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...
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.
you think zip codes are a more common use case than numbers?
Second, how would you handle international addresses? For many businesses, a program that can't do that would be useless.
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.
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.
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.
The looser your typings the more it matters, and spreadsheets barely even have types.
Edit: found https://retrocomputing.stackexchange.com/questions/20460/wha..., suggests it was ALGOL-68.
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.
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.
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.
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.
> 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.
If they were text, I'd expect it to end up as `12345678`, personally. + being reasonably commonly overloaded to mean string concatenation.
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.
WTF? Are you saying Toyota don't normally put seatbelts in their cars? Like... what???
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.
Zip codes are not a weird edge case either.
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.
If I type 000012 why would you think I wanted 12?
What’s painful is when a file has phone numbers and excel helpfully converts them all to scientific notation.
That a Excel could introduce bugs due to doing floats behind the scenes.... Completely unacceptable.
I appreciate that comeback. Well played.
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
Because one of it’s main uses is for doing calculations with money?
I just don’t use excel anymore.
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.
But that's not pocket size... what kind of pockets do you...
> in the 90s
Ohhhh, JNCOs!
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?
[1] https://www.wolframalpha.com/
Exercise: Why?
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).
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!
a number probably infinitely small... Google might be the only user in this case
Google helpfully informs me that
marathon + (20 inches) = 1.00001204 marathon
[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)
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?
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)
You have a great ability to break things down in a way that makes sense.
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
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