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

231–240 of 267 posts

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

#231

Post by gavinhoward »

shagie wrote: post #58
mobilio wrote: post #55

Earlier quoted context omitted.

But it's 9! Check it: https://www.mathplanet.com/education/pre-algebra/explore-and... . "You also have to pay attention to the signs when you multiply and divide. There are two simple rules to remember: When you multiply a negative number by a positive number then the product is always negative. When you multiply two negative numbers or two positive numbers then the product is always positive." So basically you have…

https://www.wolframalpha.com/input?i=-3%5E2 https://en.wikipedia.org/wiki/Order_of_operations Parentheses, Exponentiation, Multiplication, Division, Addition, Subtraction -3^2 would then be correctly parsed as -(3^2) which is -9. Parsing it as (-3)^2 would require the addition of parentheses. This gets to the special case of the unary minus sign... which the Wikipedia article specifically calls out. Special cases Una…

Gavin Howard here.

There really isn't a design choice to be made. POSIX requires unary negation to have higher precedence.

The only precedence change (I can remember) from GNU bc is that I changed the not operator to have the same precedence as negation. This was so all unary operators had the same precedence, which leads to more predictable parsing and behavior.

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

#232

Post by RajT88 »

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…

> 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!

Every week it bites me once or twice. Drives me bananas.

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

#234

Post by tssva »

mark-r wrote: post #228
tssva wrote: post #224

Earlier quoted context omitted.

The specific import process isn't some sort of esoteric process. It is the data import wizard. Also as I said if you are regularly importing data from a file with the same format writing some VBA to do so is pretty quick and simple task. Also your data isn't gone. It is still in the CSV file you imported it from. Re-import it.

I would wager more people open a CSV by double-clicking on it rather than using the import data wizard. And even if you use the wizard it takes extra work to specify the type of each column, which most people won't bother with. Writing some VBA is a simple process if you're a programmer. I wonder how many genetic researchers fit that description? P.S. when I said "too late to fix it", I meant by some process within E…

Expecting you to learn the basics about the tools you're using is not expecting too much. And if you are too lazy to spend a few seconds specifying data types then you get what you deserve.

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

#235

Post by XlA5vEKsMISoIln »

tssva wrote: post #224
mark-r wrote: post #215

Earlier quoted context omitted.

If you open a CSV file without going through a specific import process, you don't even get the option to specify a data type. And once it's open it's too late to fix it, the original data is already gone.

The specific import process isn't some sort of esoteric process. It is the data import wizard. Also as I said if you are regularly importing data from a file with the same format writing some VBA to do so is pretty quick and simple task. Also your data isn't gone. It is still in the CSV file you imported it from. Re-import it.

Excel chews up CSVs that it opens. I know this because an accountant checked each file our code produced using Excel before trying to import it into another program. We proofread our code before we realizing the problem was somewhere else. Shoulder-surfed the process, found the giant bug with a green X on it.

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

#236

Post by fifilura »

I always felt that there is a hierarchy for working with numbers that goes something like this

Ease of use:

1. Excel

2. SQL

3. Functional programming (e.g. Scala, Python to some measure e.g. Pandas)

4. Imperative programming (C/C++/Java)

But then there another hierarchy that (roughly) goes in the other direction, which is about quality, repeatability, tooling.

If you are at 1 or 2, you responsibility will not be about writing tests and verifying your code using traditional engineering methods.

However! You are responsible for cross checking your results based on the input. This may be a manual process. But actually looking at the numbers from several different angles can give higher quality than writing contrived testcases (in 3 or 4).

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

#237

Post by XlA5vEKsMISoIln »

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.

A bad dancer finds even his ballsack annoying.

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

#238

Post by shagie »

gavinhoward wrote: post #231
shagie wrote: post #58

Earlier quoted context omitted.

https://www.wolframalpha.com/input?i=-3%5E2 https://en.wikipedia.org/wiki/Order_of_operations Parentheses, Exponentiation, Multiplication, Division, Addition, Subtraction -3^2 would then be correctly parsed as -(3^2) which is -9. Parsing it as (-3)^2 would require the addition of parentheses. This gets to the special case of the unary minus sign... which the Wikipedia article specifically calls out. Special cases Una…

Gavin Howard here. There really isn't a design choice to be made. POSIX requires unary negation to have higher precedence. The only precedence change (I can remember) from GNU bc is that I changed the not operator to have the same precedence as negation. This was so all unary operators had the same precedence, which leads to more predictable parsing and behavior.

The question that I'm curious about is "why does POSIX require unary negation to have a higher precedence?"

Was it a "this is the way that bc worked in the 70s because it was easier to write a parser for it?" or was there some more underlying reason for the "this problem gets really icky if unary negation has lower precedence than the binary operators and makes for other expressions that become less reasonable?"

It's like the Logical XOR issue ( https://youtu.be/4PaWFYm0kEw?t=2236&si=Wi0gwV-XctLGN98I ) ... and I'm of the opinion that there's a real reason why this design choice was made.

(Aside: Some other historical "why things work that way" touching on dc's place in history: Ken Thompson interviewed by Brian Kernighan at VCF East 2019 https://youtu.be/EY6q5dv_B-o?si=YKr4j_FAEp-OihiX&t=1784 - it goes on to pipes and dc makes an appearance there again)

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

#239

Post by tjalfi »

Dalewyn wrote: post #132
aezart wrote: post #120

Earlier quoted context omitted.

The Godot game engine has its 2d graphics origin at the top-left of the screen, with the positive Y axis pointed down. Having clockwise trig functions is a natural consequence of that. I think it's a fairly common setup for all 2D graphics software.

I don't think I've ever seen a graphical system of any kind that didn't have 0,0 at the top-left corner of the monitor or viewport either, with positive x going right and positive y going down. I actually didn't even think about it until now. Now it's going to bug me. God damnit. :V

OS/2's Presentation Manager had 0,0 at the bottom-left corner of the monitor.

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

#240

Post by gavinhoward »

shagie wrote: post #238
gavinhoward wrote: post #231

Earlier quoted context omitted.

Gavin Howard here. There really isn't a design choice to be made. POSIX requires unary negation to have higher precedence. The only precedence change (I can remember) from GNU bc is that I changed the not operator to have the same precedence as negation. This was so all unary operators had the same precedence, which leads to more predictable parsing and behavior.

The question that I'm curious about is "why does POSIX require unary negation to have a higher precedence?" Was it a "this is the way that bc worked in the 70s because it was easier to write a parser for it?" or was there some more underlying reason for the "this problem gets really icky if unary negation has lower precedence than the binary operators and makes for other expressions that become less reasonable?" It's…

Unfortunately, I can't really say much about historical design.
Post reply on HN