Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One in five genetics papers contains errors thanks to Excel (2016)

science.org

Post reply on HN
Print view View original

201–210 of 267 posts

Re: One in five genetics papers contains errors thanks to Excel (2016)

#201

Post by jyunwai »

v1ne wrote: post #134

We have a saying in German: A bad worker always blames their tools. Excel has many quirks, but I'm still very grateful that it exists, for quickly putting together some numbers and still being able to change the inputs to my formulas.

But at the same time, there is a saying in user experience design: don't blame the user.

At least at the time of the article, there was no way to disable the auto-conversion of certain strings (like "SEPT2") into dates. A setting to disable this would have stopped many errors amplified by researchers working late at night or rushing to meet a deadline.

It's true that there has to be some point where the users of the tool need to put in the effort to learn how to best use it. But effort poured in from the other end by the developers, too, can go a long way to prevent common errors and save users time.

Re: One in five genetics papers contains errors thanks to Excel (2016)

#202

Post by brookst »

dmvdoug wrote: post #181
zelphirkalt wrote: post #139

Know your tools. When I see such headlines, I feel sad about the state of this world and obstacles to progress, angry about the stupidity of designing all the tools for the most lazy of users, and at the same time I also laugh about the failures of proprietary software and its users, who could easily have invested a little bit of time to learn alternatives, but apparently chose not to. Yes the tooling they use might…

Yes, tools are not made for users but for the tool-builders. Everyone else must adapt!

I think you’re reframing “when all you have is a hammer, every problem is a nail” into “when all you have is a screw and a hammer, it’s outrageous the hammer wasn’t designed to drive screws”.

Re: One in five genetics papers contains errors thanks to Excel (2016)

#204

Post by tsimionescu »

eviks wrote: post #189
tsimionescu wrote: post #186

Earlier quoted context omitted.

In Wolfram alpha as well, ^ is a different notation than superscripts: https://www.wolframalpha.com/input?i=-3%5E2%2B2 And of course / is completely different from fractions too. Math notation is two-dimensional, and requires relatively few parentheses. Computer notation is uni-dimensional and requires parentheses all over the place. This is how math notation looks like, try to write this in C/Excel/Wolfram Alpha wit…

> try to write this ... without parens: Why? This extra condition doesn't help you, and why your link shows nothing, it behaves exactly as I'd expect, ^ is identical to superscript, you're just making an implicit mistake of thinking +2 is somehow covered by ^ and would be part of the superscript, but it wouldn't, that's a different source of ambiguity What would help is an example where parens aren't needed, but none…

The math notation doesn't need parens. The computer notation needs parens. This alone is simple obvious proof that they are different notations, at least in my understanding of what a notation is.

Re: One in five genetics papers contains errors thanks to Excel (2016)

#205

Post by vikingerik »

lbriner wrote: post #161

Don't get me started on the automatic conversion of strings that it thinks are in scientific notation into numbers - which you can't switch off! We have large data exports from systems that include things like unique location code. You accidentally happen to notice that a block of these look weird and it isn't just the display of them that has changed, the contents of the cell were changed by Excel automatically, wit…

Yes, it's that last reason. Backwards bug compatibility. There are zillions of recorded macros and VBA scripts and other workflows by non-technical users that inadvertently depend on these behaviors in subtle ways. It's like all Javascript's weird warts, you can't change these behaviors without breaking old stuff somehow. It's true that Microsoft could say that more directly, but of course they'd rather just avoid that argument.

Re: One in five genetics papers contains errors thanks to Excel (2016)

#206

Post by ttoinou »

BurningFrog wrote: post #203

This is 100% on the scientists who continue to use a tool that doesn't work for their use case!

Maybe they are locked into the tool because of legacy reasons, and they don’t have a developer around in their team responsible for upgrading their tool / software workflow. This must be a non-trivial problem for a lot of workers all around the world

Re: One in five genetics papers contains errors thanks to Excel (2016)

#207

Post by simonh »

Eddy_Viscosity2 wrote: post #184
simonh wrote: post #81

Earlier quoted context omitted.

Aside from setting all your cells to text, they have added checkboxes for this now. https://insider.microsoft365.com/en-us/blog/control-data-con...

I just tried this out. I'm using office 2021 and when I first opened excel, this setting was there just like in the link and it seemed to work when I entered a few strings in. 'Fantastic!' I thought. Then I closed it and thought of a few other date-like strings to try and this time the option had disappeared! Every date-looking string was instantly turned into date! I tried a few other times and this setting is gone.…

Have you opened an older file? Maybe it only works with files created with the feature. I’ve no idea why that would be the case, but it’s all I can think of.

Re: One in five genetics papers contains errors thanks to Excel (2016)

#208

Post by oglop »

lol. What a solution. Maybe learn how to use a proper DB. Research science is like 14 years behind the times. I was amazed at the SciPy24 conference how almost no data scientists use DBs. Wild. Pandas is your friend here and can at least help you with json stuff. Using excel though, yeesh. Yeah the problem isn’t excel, it’s bad training on data handling from schools.

Re: One in five genetics papers contains errors thanks to Excel (2016)

#209

Post by bikenaga »

thaumasiotes wrote: post #107
bikenaga wrote: post #70

Earlier quoted context omitted.

You're right that violating established mathematical convention can be a deal-killer for some kinds of adoption. A few years ago I was reading the docs for a new programming language, thinking it might be useful in teaching. The docs were well-written and in a beautifully produced book. I got to the chapter on trig functions and discovered that they'd decided to make angles increase clockwise . And there was a graph…

> I got to the chapter on trig functions and discovered that they'd decided to make angles increase clockwise . That is an established mathematical convention, called "bearing". https://en.wikipedia.org/wiki/Bearing_(navigation) > And there was a graph of the sine function, with the graph below the x-axis from 0 to 180 degrees. But that definitely isn't a convention anywhere; bearing 0 has sine 1. There isn't really…

As someone else noted, "bearing" isn't a mathematical convention. To be clear, when I say "mathematical convention" I mean what mathematicians do and teach. But I didn't know about "bearing" in navigation so thanks for mentioning that.

> There isn't really one mathematical convention on "angles".

There is for angles in the plane, which are the angles I was discussing. In every math course from trig where people first encounter angles in the plane they increase as you go counterclockwise. This is true in trig, precalc, calculus, ... You will not find a math textbook in which plane angles increase clockwise. I think that counts as a convention.

That convention determines the graph of the sine function, because sin theta is defined in trig courses as the y-coordinate of the point where the ray from the origin determining the angle intersects the unit circle. So (e.g.) if 45 degrees means 45 degrees clockwise, that ray is below the x-axis, and the y-coordinate of the intersection is negative -- and hence, sin 45 degrees would be negative.

If angles increase clockwise from the positive x-axis, then sin 45 degrees will be negative. And if sine 45 degrees is negative, then angles are increasing clockwise from the positive x-axis. And any mathematician would tell you that sine 45 degree is 1/sqrt(2), not -1/sqrt(2).

> ... in a math class it's normal to orient phi in whatever way makes sense to you.

You're correct that there are two prevailing conventions for the angle phi in spherical coordinates. Mathematicians measure phi downward from the positive z-axis, so it takes values from 0 to 180 degrees. (Actually, it's sort of like "bearing" that you mentioned.) Physicists measure phi upward from the x-y plane, so it can take values from -90 to 90 degrees. It does cause some confusion in teaching Calc 3, because students also taking a physics or astronomy course may be seeing two conventions for phi. However, in 3 dimensions (spherical coordinates) there's no natural "clockwise" or "counterclockwise".

But there is a convention for measuring phi in math classes -- it's the one I described above. Check any calculus book. Our colleagues in physics don't like it, but oh well. :-)

Re: One in five genetics papers contains errors thanks to Excel (2016)

#210

Post by eviks »

tsimionescu wrote: post #204
eviks wrote: post #189

Earlier quoted context omitted.

> try to write this ... without parens: Why? This extra condition doesn't help you, and why your link shows nothing, it behaves exactly as I'd expect, ^ is identical to superscript, you're just making an implicit mistake of thinking +2 is somehow covered by ^ and would be part of the superscript, but it wouldn't, that's a different source of ambiguity What would help is an example where parens aren't needed, but none…

The math notation doesn't need parens. The computer notation needs parens. This alone is simple obvious proof that they are different notations, at least in my understanding of what a notation is.

-3^2 in the math notation doesn't need parens only because of operator precedence.

The fact that the computer ^ requires parens in more cases like -3^(2+2) is irrelevant for this and doesn't allow you justifying different precedence rules (and your downgrading from "completely different" to "different" isn't a proof, just "tautology". Hey, they also look different, so they are different!)

Post reply on HN