Hank Rogers <hank@nospam.invalid> wrote:
> nospam wrote:
>> In article <u7732j$573v$2@dont-email.me>, Chris <ithinkiam@gmail.com>
>> wrote:
>>
>>>>>> Have you tried it in LibreOffice?
>>>>>
>>>>> LO is the same
>>>>
>>>> libre office is open source. modify it to do what you want.
>>>
>>> What's the point no-one uses it and it's a dead end.
>>
>> maybe so, but you can add or remove whatever functionality you want.
>>
>
> I can't even get it to run on my iPhone. Will things improve
> when we get replaceable batteries?

LOL, nice.

Yes, everything will be sunshine and lollipops when we get “replacable”
batteries. For the 5% of people who actually need to replace them.

The rest of us will still be struggling along with batteries that easily
last 5 years or more.

On 2023-06-25 06:07, Chris wrote:
> On 24/06/2023 14:45, Alan Browne wrote:
>> On 2023-06-23 23:52, Alan wrote:
>>> On 2023-06-23 11:19, Chris wrote:
>>
>>>> It's far simpler than that. There many gene IDs that look like dates to
>>>> excel e.g. oct-9, march15, dec-1. When opening a results CSV file of
>>>> 20,000
>>>> genes excel automatically (and quietly) converts those genes to
>>>> dates and
>>>> because the data are large the user doesn't notice when saving. Now any
>>>> future analysis will contain unknown gene names. This is a problem
>>>> as it's
>>>> a systematic bias and it's always the same genes that drop out of the
>>>> analysis reducing the chances of them being identified as
>>>> "interesting".
>>>
>>> Which would be a problem precisely ONCE for anyone who took the time
>>> to see why the error happened and learned how to avoid the problem
>>> entirely:
>>
>> Just created a .csv with the labels mentioned above, imported to excel
>> with no conversion.  I should have tested this earlier.
>>
>> Perhaps, Chris, you could post an actual gene file that "expresses"[1]
>> the error for testing?
>
> I've cropped a bit of a typical file, found here that has been annotated
> with the GeneIDs:
> https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE95077
>
> I've posted it on here:
> https://pastebin.com/UU4xhqwD
>
> Save as a .tsv and then double-click - at least here on my mac - that
> opens in Excel with no wizard, no nothing and no warning that data had
> been changed. Only only warning as is about "feature loss" if you stick
> to using csv formatted (sic) files.

I copied and saved via Text - formatted to plain text.

Auto opened in Apple Numbers, actually. So used "Open With"

Found MARCH2 on line 1855 did convert to a date.

(Excel for Mac, 2019).

> I challenge anyone to count how many errors have been introduced in
> under 1 minute. You're not allowed to use Search because the insiduous
> nature of this is that a priori a naive user wouldn't know that genes
> have been affected in this way. The usual use-case is to eye-ball the data.

Found 1. I quit!

> This is insiduous because the next step is often to "Save As" an .xlsx
> file so any changes made go unnoticed.
>
>> [1] See what I did there?
>
> I did ;)

Heehee.

--
“If you torture the data long enough, it will confess to anything."
-Ronald Coase

On 2023-06-25 11:02, Bob Campbell wrote:

> Yes, everything will be sunshine and lollipops when we get “replacable”
> batteries. For the 5% of people who actually need to replace them.

That many?

--
“If you torture the data long enough, it will confess to anything."
-Ronald Coase

On 2023-06-25 03:07, Chris wrote:
> On 24/06/2023 14:45, Alan Browne wrote:
>> On 2023-06-23 23:52, Alan wrote:
>>> On 2023-06-23 11:19, Chris wrote:
>>
>>>> It's far simpler than that. There many gene IDs that look like dates to
>>>> excel e.g. oct-9, march15, dec-1. When opening a results CSV file of
>>>> 20,000
>>>> genes excel automatically (and quietly) converts those genes to
>>>> dates and
>>>> because the data are large the user doesn't notice when saving. Now any
>>>> future analysis will contain unknown gene names. This is a problem
>>>> as it's
>>>> a systematic bias and it's always the same genes that drop out of the
>>>> analysis reducing the chances of them being identified as
>>>> "interesting".
>>>
>>> Which would be a problem precisely ONCE for anyone who took the time
>>> to see why the error happened and learned how to avoid the problem
>>> entirely:
>>
>> Just created a .csv with the labels mentioned above, imported to excel
>> with no conversion.  I should have tested this earlier.
>>
>> Perhaps, Chris, you could post an actual gene file that "expresses"[1]
>> the error for testing?
>
> I've cropped a bit of a typical file, found here that has been annotated
> with the GeneIDs:
> https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE95077
>
> I've posted it on here:
> https://pastebin.com/UU4xhqwD
>
> Save as a .tsv and then double-click - at least here on my mac - that
> opens in Excel with no wizard, no nothing and no warning that data had
> been changed. Only only warning as is about "feature loss" if you stick
> to using csv formatted (sic) files.
>
> I challenge anyone to count how many errors have been introduced in
> under 1 minute. You're not allowed to use Search because the insiduous
> nature of this is that a priori a naive user wouldn't know that genes
> have been affected in this way. The usual use-case is to eye-ball the data.
>
> This is insiduous because the next step is often to "Save As" an .xlsx
> file so any changes made go unnoticed.

I just downloaded the file; it saved as "GSE95077 Test.txt"

I opened Excel, chose "Open..." from the file menu and selected it.

The Text Import Wizard opened, automatically selected "Tab" for the
delimiter, and after hitting "Next" it asked me what format I wanted to
use for importing each column. I changed them all from "General" to
"Text" (except the "ENTREZID", which were obviously numbers) and it
opened perfectly.

The whole process added perhaps one minute to opening the file.

Alan Browne <bitbucket@blackhole.com> wrote:
> On 2023-06-25 11:02, Bob Campbell wrote:
>
>> Yes, everything will be sunshine and lollipops when we get “replacable”
>> batteries. For the 5% of people who actually need to replace them.
>
> That many?

I was feeling generous.

On 2023-06-25 12:54, Alan wrote:
> On 2023-06-25 03:07, Chris wrote:
>> On 24/06/2023 14:45, Alan Browne wrote:
>>> On 2023-06-23 23:52, Alan wrote:
>>>> On 2023-06-23 11:19, Chris wrote:
>>>
>>>>> It's far simpler than that. There many gene IDs that look like
>>>>> dates to
>>>>> excel e.g. oct-9, march15, dec-1. When opening a results CSV file
>>>>> of 20,000
>>>>> genes excel automatically (and quietly) converts those genes to
>>>>> dates and
>>>>> because the data are large the user doesn't notice when saving. Now
>>>>> any
>>>>> future analysis will contain unknown gene names. This is a problem
>>>>> as it's
>>>>> a systematic bias and it's always the same genes that drop out of the
>>>>> analysis reducing the chances of them being identified as
>>>>> "interesting".
>>>>
>>>> Which would be a problem precisely ONCE for anyone who took the time
>>>> to see why the error happened and learned how to avoid the problem
>>>> entirely:
>>>
>>> Just created a .csv with the labels mentioned above, imported to
>>> excel with no conversion.  I should have tested this earlier.
>>>
>>> Perhaps, Chris, you could post an actual gene file that
>>> "expresses"[1] the error for testing?
>>
>> I've cropped a bit of a typical file, found here that has been
>> annotated with the GeneIDs:
>> https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE95077
>>
>> I've posted it on here:
>> https://pastebin.com/UU4xhqwD
>>
>> Save as a .tsv and then double-click - at least here on my mac - that
>> opens in Excel with no wizard, no nothing and no warning that data had
>> been changed. Only only warning as is about "feature loss" if you
>> stick to using csv formatted (sic) files.
>>
>> I challenge anyone to count how many errors have been introduced in
>> under 1 minute. You're not allowed to use Search because the insiduous
>> nature of this is that a priori a naive user wouldn't know that genes
>> have been affected in this way. The usual use-case is to eye-ball the
>> data.
>>
>> This is insiduous because the next step is often to "Save As" an .xlsx
>> file so any changes made go unnoticed.
>
> I just downloaded the file; it saved as "GSE95077 Test.txt"
>
> I opened Excel, chose "Open..." from the file menu and selected it.
>
> The Text Import Wizard opened, automatically selected "Tab" for the
> delimiter, and after hitting "Next" it asked me what format I wanted to
> use for importing each column. I changed them all from "General" to
> "Text" (except the "ENTREZID", which were obviously numbers) and it
> opened perfectly.
>
> The whole process added perhaps one minute to opening the file.

So in the end, Excel is inconsistent.

I often open files via Finder. Either the extension indicates the app
or use the drop down (right click) "Open with".

In this case I don't get the option to import as you describe ("Text
Wizard.".

If I open from the Excel "Open" menu then I do.

So, in effect it is a bug because of the inconsistency.

--
“If you torture the data long enough, it will confess to anything."
-Ronald Coase

On 2023-06-25 13:02, Alan Browne wrote:
> On 2023-06-25 12:54, Alan wrote:
>> On 2023-06-25 03:07, Chris wrote:
>>> On 24/06/2023 14:45, Alan Browne wrote:
>>>> On 2023-06-23 23:52, Alan wrote:
>>>>> On 2023-06-23 11:19, Chris wrote:
>>>>
>>>>>> It's far simpler than that. There many gene IDs that look like
>>>>>> dates to
>>>>>> excel e.g. oct-9, march15, dec-1. When opening a results CSV file
>>>>>> of 20,000
>>>>>> genes excel automatically (and quietly) converts those genes to
>>>>>> dates and
>>>>>> because the data are large the user doesn't notice when saving.
>>>>>> Now any
>>>>>> future analysis will contain unknown gene names. This is a problem
>>>>>> as it's
>>>>>> a systematic bias and it's always the same genes that drop out of the
>>>>>> analysis reducing the chances of them being identified as
>>>>>> "interesting".
>>>>>
>>>>> Which would be a problem precisely ONCE for anyone who took the
>>>>> time to see why the error happened and learned how to avoid the
>>>>> problem entirely:
>>>>
>>>> Just created a .csv with the labels mentioned above, imported to
>>>> excel with no conversion.  I should have tested this earlier.
>>>>
>>>> Perhaps, Chris, you could post an actual gene file that
>>>> "expresses"[1] the error for testing?
>>>
>>> I've cropped a bit of a typical file, found here that has been
>>> annotated with the GeneIDs:
>>> https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE95077
>>>
>>> I've posted it on here:
>>> https://pastebin.com/UU4xhqwD
>>>
>>> Save as a .tsv and then double-click - at least here on my mac - that
>>> opens in Excel with no wizard, no nothing and no warning that data
>>> had been changed. Only only warning as is about "feature loss" if you
>>> stick to using csv formatted (sic) files.
>>>
>>> I challenge anyone to count how many errors have been introduced in
>>> under 1 minute. You're not allowed to use Search because the
>>> insiduous nature of this is that a priori a naive user wouldn't know
>>> that genes have been affected in this way. The usual use-case is to
>>> eye-ball the data.
>>>
>>> This is insiduous because the next step is often to "Save As" an
>>> .xlsx file so any changes made go unnoticed.
>>
>> I just downloaded the file; it saved as "GSE95077 Test.txt"
>>
>> I opened Excel, chose "Open..." from the file menu and selected it.
>>
>> The Text Import Wizard opened, automatically selected "Tab" for the
>> delimiter, and after hitting "Next" it asked me what format I wanted
>> to use for importing each column. I changed them all from "General" to
>> "Text" (except the "ENTREZID", which were obviously numbers) and it
>> opened perfectly.
>>
>> The whole process added perhaps one minute to opening the file.
>
>
> So in the end, Excel is inconsistent.

No. It is completely consistent.

>
> I often open files via Finder.  Either the extension indicates the app
> or use the drop down (right click) "Open with".

And why should that behaviour not be different?

>
> In this case I don't get the option to import as you describe ("Text
> Wizard.".
>
> If I open from the Excel "Open" menu then I do.
>
> So, in effect it is a bug because of the inconsistency.

Nope. Because there is no reason the two behaviours SHOULD be the same.

It isn't a bug because you think they should have done it differently.

On 2023-06-25 16:29, Alan wrote:
> On 2023-06-25 13:02, Alan Browne wrote:
>> On 2023-06-25 12:54, Alan wrote:
>>> On 2023-06-25 03:07, Chris wrote:
>>>> On 24/06/2023 14:45, Alan Browne wrote:
>>>>> On 2023-06-23 23:52, Alan wrote:
>>>>>> On 2023-06-23 11:19, Chris wrote:
>>>>>
>>>>>>> It's far simpler than that. There many gene IDs that look like
>>>>>>> dates to
>>>>>>> excel e.g. oct-9, march15, dec-1. When opening a results CSV file
>>>>>>> of 20,000
>>>>>>> genes excel automatically (and quietly) converts those genes to
>>>>>>> dates and
>>>>>>> because the data are large the user doesn't notice when saving.
>>>>>>> Now any
>>>>>>> future analysis will contain unknown gene names. This is a
>>>>>>> problem as it's
>>>>>>> a systematic bias and it's always the same genes that drop out of
>>>>>>> the
>>>>>>> analysis reducing the chances of them being identified as
>>>>>>> "interesting".
>>>>>>
>>>>>> Which would be a problem precisely ONCE for anyone who took the
>>>>>> time to see why the error happened and learned how to avoid the
>>>>>> problem entirely:
>>>>>
>>>>> Just created a .csv with the labels mentioned above, imported to
>>>>> excel with no conversion.  I should have tested this earlier.
>>>>>
>>>>> Perhaps, Chris, you could post an actual gene file that
>>>>> "expresses"[1] the error for testing?
>>>>
>>>> I've cropped a bit of a typical file, found here that has been
>>>> annotated with the GeneIDs:
>>>> https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE95077
>>>>
>>>> I've posted it on here:
>>>> https://pastebin.com/UU4xhqwD
>>>>
>>>> Save as a .tsv and then double-click - at least here on my mac -
>>>> that opens in Excel with no wizard, no nothing and no warning that
>>>> data had been changed. Only only warning as is about "feature loss"
>>>> if you stick to using csv formatted (sic) files.
>>>>
>>>> I challenge anyone to count how many errors have been introduced in
>>>> under 1 minute. You're not allowed to use Search because the
>>>> insiduous nature of this is that a priori a naive user wouldn't know
>>>> that genes have been affected in this way. The usual use-case is to
>>>> eye-ball the data.
>>>>
>>>> This is insiduous because the next step is often to "Save As" an
>>>> .xlsx file so any changes made go unnoticed.
>>>
>>> I just downloaded the file; it saved as "GSE95077 Test.txt"
>>>
>>> I opened Excel, chose "Open..." from the file menu and selected it.
>>>
>>> The Text Import Wizard opened, automatically selected "Tab" for the
>>> delimiter, and after hitting "Next" it asked me what format I wanted
>>> to use for importing each column. I changed them all from "General"
>>> to "Text" (except the "ENTREZID", which were obviously numbers) and
>>> it opened perfectly.
>>>
>>> The whole process added perhaps one minute to opening the file.
>>
>>
>> So in the end, Excel is inconsistent.
>
> No. It is completely consistent.
>
>>
>> I often open files via Finder.  Either the extension indicates the app
>> or use the drop down (right click) "Open with".
>
> And why should that behaviour not be different?

Consistency. Users should not have to remember that if you open one
particular way it behaves x and open the same file another way it behaves y.

>
>>
>> In this case I don't get the option to import as you describe ("Text
>> Wizard.".
>>
>> If I open from the Excel "Open" menu then I do.
>>
>> So, in effect it is a bug because of the inconsistency.
>
> Nope. Because there is no reason the two behaviours SHOULD be the same.

Above.

>
> It isn't a bug because you think they should have done it differently.

At best it's inconsistent. At worst it's a bug.

--
“If you torture the data long enough, it will confess to anything."
-Ronald Coase

On 2023-06-25 17:08, Alan Browne wrote:
> On 2023-06-25 16:29, Alan wrote:
>> On 2023-06-25 13:02, Alan Browne wrote:
>>> On 2023-06-25 12:54, Alan wrote:
>>>> On 2023-06-25 03:07, Chris wrote:
>>>>> On 24/06/2023 14:45, Alan Browne wrote:
>>>>>> On 2023-06-23 23:52, Alan wrote:
>>>>>>> On 2023-06-23 11:19, Chris wrote:
>>>>>>
>>>>>>>> It's far simpler than that. There many gene IDs that look like
>>>>>>>> dates to
>>>>>>>> excel e.g. oct-9, march15, dec-1. When opening a results CSV
>>>>>>>> file of 20,000
>>>>>>>> genes excel automatically (and quietly) converts those genes to
>>>>>>>> dates and
>>>>>>>> because the data are large the user doesn't notice when saving.
>>>>>>>> Now any
>>>>>>>> future analysis will contain unknown gene names. This is a
>>>>>>>> problem as it's
>>>>>>>> a systematic bias and it's always the same genes that drop out
>>>>>>>> of the
>>>>>>>> analysis reducing the chances of them being identified as
>>>>>>>> "interesting".
>>>>>>>
>>>>>>> Which would be a problem precisely ONCE for anyone who took the
>>>>>>> time to see why the error happened and learned how to avoid the
>>>>>>> problem entirely:
>>>>>>
>>>>>> Just created a .csv with the labels mentioned above, imported to
>>>>>> excel with no conversion.  I should have tested this earlier.
>>>>>>
>>>>>> Perhaps, Chris, you could post an actual gene file that
>>>>>> "expresses"[1] the error for testing?
>>>>>
>>>>> I've cropped a bit of a typical file, found here that has been
>>>>> annotated with the GeneIDs:
>>>>> https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE95077
>>>>>
>>>>> I've posted it on here:
>>>>> https://pastebin.com/UU4xhqwD
>>>>>
>>>>> Save as a .tsv and then double-click - at least here on my mac -
>>>>> that opens in Excel with no wizard, no nothing and no warning that
>>>>> data had been changed. Only only warning as is about "feature loss"
>>>>> if you stick to using csv formatted (sic) files.
>>>>>
>>>>> I challenge anyone to count how many errors have been introduced in
>>>>> under 1 minute. You're not allowed to use Search because the
>>>>> insiduous nature of this is that a priori a naive user wouldn't
>>>>> know that genes have been affected in this way. The usual use-case
>>>>> is to eye-ball the data.
>>>>>
>>>>> This is insiduous because the next step is often to "Save As" an
>>>>> .xlsx file so any changes made go unnoticed.
>>>>
>>>> I just downloaded the file; it saved as "GSE95077 Test.txt"
>>>>
>>>> I opened Excel, chose "Open..." from the file menu and selected it.
>>>>
>>>> The Text Import Wizard opened, automatically selected "Tab" for the
>>>> delimiter, and after hitting "Next" it asked me what format I wanted
>>>> to use for importing each column. I changed them all from "General"
>>>> to "Text" (except the "ENTREZID", which were obviously numbers) and
>>>> it opened perfectly.
>>>>
>>>> The whole process added perhaps one minute to opening the file.
>>>
>>>
>>> So in the end, Excel is inconsistent.
>>
>> No. It is completely consistent.
>>
>>>
>>> I often open files via Finder.  Either the extension indicates the
>>> app or use the drop down (right click) "Open with".
>>
>> And why should that behaviour not be different?
>
> Consistency.  Users should not have to remember that if you open one
> particular way it behaves x and open the same file another way it
> behaves y.

But that completely removes the ability to every vary from standard,
doesn't it?

Sorry, but it doesn't wash.

The normal way is useful for probably 95%+ of all people who use Excel
and for edge cases there is another way to do things that they don't
even need to know about.

>
>>
>>>
>>> In this case I don't get the option to import as you describe ("Text
>>> Wizard.".
>>>
>>> If I open from the Excel "Open" menu then I do.
>>>
>>> So, in effect it is a bug because of the inconsistency.
>>
>> Nope. Because there is no reason the two behaviours SHOULD be the same.
>
> Above.
>
>>
>> It isn't a bug because you think they should have done it differently.
>
> At best it's inconsistent.  At worst it's a bug.

It's definitely not a bug, because it is intended behaviour.

And inconsistency is wrong because you are achieving the operation with
very different approaches.

On 2023-06-25 20:36, Alan wrote:
> On 2023-06-25 17:08, Alan Browne wrote:

>> At best it's inconsistent.  At worst it's a bug.
>
> It's definitely not a bug, because it is intended behaviour.

"So, we're agreed in this design review that if the user opens a text
file one way, we go straight to it, no warnings, no attempt to get the
user to make choices.
But, if the user opens it /this/ way, then the user will get some
formatting guidance."

"Well, that's just bad UI design. Inconsistent. Frankly it's a bug -
both ways should follow the exact same opening sequence. Less code,
easier to test, less prone to fail.:

"Shut the fuck up."
-MS product design manager.

>
> And inconsistency is wrong because you are achieving the operation with
> very different approaches.

Not at all. Consistency is a useful thing. And MS is not the
Consistent co.

--
“If you torture the data long enough, it will confess to anything."
-Ronald Coase

On 2023-06-25 18:04, Alan Browne wrote:
> On 2023-06-25 20:36, Alan wrote:
>> On 2023-06-25 17:08, Alan Browne wrote:
>
>>> At best it's inconsistent.  At worst it's a bug.
>>
>> It's definitely not a bug, because it is intended behaviour.
>
> "So, we're agreed in this design review that if the user opens a text
> file one way, we go straight to it, no warnings, no attempt to get the
> user to make choices.
>  But, if the user opens it /this/ way, then the user will get some
> formatting guidance."
>
> "Well, that's just bad UI design.  Inconsistent.  Frankly it's a bug -
> both ways should follow the exact same opening sequence.  Less code,
> easier to test, less prone to fail.:
>
> "Shut the fuck up."
>  -MS product design manager.

Not actual quotes, so cute... ...but just so much bullshit.

>
>>
>> And inconsistency is wrong because you are achieving the operation
>> with very different approaches.
>
> Not at all.  Consistency is a useful thing.  And MS is not the
> Consistent co.

"A foolish consistency is the hobgoblin of little minds".

-Ralph Waldo Emerson.

The simple fact of the matter is the functionality that isn't useful to
everyone SHOULD be place in a way that makes it less immediate.

But moreover, the fact for this subthread is that the so-called "issue"
that geneticists were having has an utterly simply way to avoid.

Alan Browne <bitbucket@blackhole.com> wrote:
> On 2023-06-25 06:07, Chris wrote:
>> On 24/06/2023 14:45, Alan Browne wrote:
>>> On 2023-06-23 23:52, Alan wrote:
>>>> On 2023-06-23 11:19, Chris wrote:
>>>
>>>>> It's far simpler than that. There many gene IDs that look like dates to
>>>>> excel e.g. oct-9, march15, dec-1. When opening a results CSV file of
>>>>> 20,000
>>>>> genes excel automatically (and quietly) converts those genes to
>>>>> dates and
>>>>> because the data are large the user doesn't notice when saving. Now any
>>>>> future analysis will contain unknown gene names. This is a problem
>>>>> as it's
>>>>> a systematic bias and it's always the same genes that drop out of the
>>>>> analysis reducing the chances of them being identified as
>>>>> "interesting".
>>>>
>>>> Which would be a problem precisely ONCE for anyone who took the time
>>>> to see why the error happened and learned how to avoid the problem
>>>> entirely:
>>>
>>> Just created a .csv with the labels mentioned above, imported to excel
>>> with no conversion.  I should have tested this earlier.
>>>
>>> Perhaps, Chris, you could post an actual gene file that "expresses"[1]
>>> the error for testing?
>>
>> I've cropped a bit of a typical file, found here that has been annotated
>> with the GeneIDs:
>> https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE95077
>>
>> I've posted it on here:
>> https://pastebin.com/UU4xhqwD
>>
>> Save as a .tsv and then double-click - at least here on my mac - that
>> opens in Excel with no wizard, no nothing and no warning that data had
>> been changed. Only only warning as is about "feature loss" if you stick
>> to using csv formatted (sic) files.
>
> I copied and saved via Text - formatted to plain text.
>
> Auto opened in Apple Numbers, actually. So used "Open With"

Yeah, I changed the default app.

> Found MARCH2 on line 1855 did convert to a date.

Did you get any warnings or hints that the data might be altered?

> (Excel for Mac, 2019).
>
>> I challenge anyone to count how many errors have been introduced in
>> under 1 minute. You're not allowed to use Search because the insiduous
>> nature of this is that a priori a naive user wouldn't know that genes
>> have been affected in this way. The usual use-case is to eye-ball the data.
>
> Found 1. I quit!

It's a start. How long did it take to find that one?

>> This is insiduous because the next step is often to "Save As" an .xlsx
>> file so any changes made go unnoticed.
>>
>>> [1] See what I did there?
>>
>> I did ;)
>
> Heehee.
>

On 2023-06-26 00:41, Alan wrote:
> On 2023-06-25 18:04, Alan Browne wrote:
>> On 2023-06-25 20:36, Alan wrote:
>>> On 2023-06-25 17:08, Alan Browne wrote:
>>
>>>> At best it's inconsistent.  At worst it's a bug.
>>>
>>> It's definitely not a bug, because it is intended behaviour.
>>
>> "So, we're agreed in this design review that if the user opens a text
>> file one way, we go straight to it, no warnings, no attempt to get the
>> user to make choices.
>>   But, if the user opens it /this/ way, then the user will get some
>> formatting guidance."
>>
>> "Well, that's just bad UI design.  Inconsistent.  Frankly it's a bug -
>> both ways should follow the exact same opening sequence.  Less code,
>> easier to test, less prone to fail.:
>>
>> "Shut the fuck up."
>>   -MS product design manager.
>
> Not actual quotes, so cute... ...but just so much bullshit.

There's little other explanation for such a blatantly bad design.
although the closing could have been more like any of these:

"That will take time. Forget it."
-MS product design manager.

"It's already in the release process. We'll address it next time.
-MS product design manager - many years and releases ago.

"There's a guy in account, the one with Asperger's, who likes it this
way - and he's a nephew of ......... . So it stays."
-MS product design manager.

>
>>
>>>
>>> And inconsistency is wrong because you are achieving the operation
>>> with very different approaches.
>>
>> Not at all.  Consistency is a useful thing.  And MS is not the
>> Consistent co.
>
> "A foolish consistency is the hobgoblin of little minds".
>
> -Ralph Waldo Emerson.
>
> The simple fact of the matter is the functionality that isn't useful to
> everyone SHOULD be place in a way that makes it less immediate.

"Everyone" doesn't open the files the same way as "everyone" every time.

> But moreover, the fact for this subthread is that the so-called "issue"
> that geneticists were having has an utterly simply way to avoid.

Yeah, a workaround that should have been eliminated years ago in order
to make the UI uniform and consistent.

--
“If you torture the data long enough, it will confess to anything."
-Ronald Coase

On 2023-06-26 14:09, Alan Browne wrote:
> On 2023-06-26 00:41, Alan wrote:
>> On 2023-06-25 18:04, Alan Browne wrote:
>>> On 2023-06-25 20:36, Alan wrote:
>>>> On 2023-06-25 17:08, Alan Browne wrote:
>>>
>>>>> At best it's inconsistent.  At worst it's a bug.
>>>>
>>>> It's definitely not a bug, because it is intended behaviour.
>>>
>>> "So, we're agreed in this design review that if the user opens a text
>>> file one way, we go straight to it, no warnings, no attempt to get
>>> the user to make choices.
>>>   But, if the user opens it /this/ way, then the user will get some
>>> formatting guidance."
>>>
>>> "Well, that's just bad UI design.  Inconsistent.  Frankly it's a bug
>>> - both ways should follow the exact same opening sequence.  Less
>>> code, easier to test, less prone to fail.:
>>>
>>> "Shut the fuck up."
>>>   -MS product design manager.
>>
>> Not actual quotes, so cute... ...but just so much bullshit.
>
>
> There's little other explanation for such a blatantly bad design.
> although the closing could have been more like any of these:
>
> "That will take time.  Forget it."
>  -MS product design manager.
>
> "It's already in the release process.  We'll address it next time.
>  -MS product design manager - many years and releases ago.
>
> "There's a guy in account, the one with Asperger's, who likes it this
> way - and he's a nephew of  ......... . So it stays."
>  -MS product design manager.
>
>
>
>>
>>>
>>>>
>>>> And inconsistency is wrong because you are achieving the operation
>>>> with very different approaches.
>>>
>>> Not at all.  Consistency is a useful thing.  And MS is not the
>>> Consistent co.
>>
>> "A foolish consistency is the hobgoblin of little minds".
>>
>> -Ralph Waldo Emerson.
>>
>> The simple fact of the matter is the functionality that isn't useful
>> to everyone SHOULD be place in a way that makes it less immediate.
>
> "Everyone" doesn't open the files the same way as "everyone" every time.
>
>> But moreover, the fact for this subthread is that the so-called
>> "issue" that geneticists were having has an utterly simply way to avoid.
>
> Yeah, a workaround that should have been eliminated years ago in order
> to make the UI uniform and consistent.

So your answer would be to force everyone to use the Text Import Wizard
every time they open a CSV?

On 2023-06-26 19:12, Alan wrote:
> On 2023-06-26 14:09, Alan Browne wrote:
>> On 2023-06-26 00:41, Alan wrote:

>>> But moreover, the fact for this subthread is that the so-called
>>> "issue" that geneticists were having has an utterly simply way to avoid.
>>
>> Yeah, a workaround that should have been eliminated years ago in order
>> to make the UI uniform and consistent.
>
> So your answer would be to force everyone to use the Text Import Wizard
> every time they open a CSV?

Easy enough to skip ("Finish"). Another way to put it is that generally
importing text files is an exceptional use of a spreadsheet program - so
yes, should always remind the user that he should pay attention before
pulling the data in.

--
“If you torture the data long enough, it will confess to anything."
-Ronald Coase

Alan Browne <bitbucket@blackhole.com> wrote:
> On 2023-06-26 00:41, Alan wrote:
>> On 2023-06-25 18:04, Alan Browne wrote:
>>> On 2023-06-25 20:36, Alan wrote:
>>>> On 2023-06-25 17:08, Alan Browne wrote:
>>>
>>>>> At best it's inconsistent.  At worst it's a bug.
>>>>
>>>> It's definitely not a bug, because it is intended behaviour.
>>>
>>> "So, we're agreed in this design review that if the user opens a text
>>> file one way, we go straight to it, no warnings, no attempt to get the
>>> user to make choices.
>>>   But, if the user opens it /this/ way, then the user will get some
>>> formatting guidance."
>>>
>>> "Well, that's just bad UI design.  Inconsistent.  Frankly it's a bug -
>>> both ways should follow the exact same opening sequence.  Less code,
>>> easier to test, less prone to fail.:
>>>
>>> "Shut the fuck up."
>>>   -MS product design manager.
>>
>> Not actual quotes, so cute... ...but just so much bullshit.
>
>
> There's little other explanation for such a blatantly bad design.
> although the closing could have been more like any of these:
>
> "That will take time. Forget it."
> -MS product design manager.
>
> "It's already in the release process. We'll address it next time.
> -MS product design manager - many years and releases ago.
>
> "There's a guy in account, the one with Asperger's, who likes it this
> way - and he's a nephew of ......... . So it stays."
> -MS product design manager.
>
>
>
>>
>>>
>>>>
>>>> And inconsistency is wrong because you are achieving the operation
>>>> with very different approaches.
>>>
>>> Not at all.  Consistency is a useful thing.  And MS is not the
>>> Consistent co.
>>
>> "A foolish consistency is the hobgoblin of little minds".
>>
>> -Ralph Waldo Emerson.
>>
>> The simple fact of the matter is the functionality that isn't useful to
>> everyone SHOULD be place in a way that makes it less immediate.
>
> "Everyone" doesn't open the files the same way as "everyone" every time.
>
>> But moreover, the fact for this subthread is that the so-called "issue"
>> that geneticists were having has an utterly simply way to avoid.
>
> Yeah, a workaround that should have been eliminated years ago in order
> to make the UI uniform and consistent.

Or a setting that could be changed. "Autodetect Dates" on/off. Default is
on for not changing current behaviour.

It's worth noting this date change even happens when you paste in data
IIRC. There's no workaround in that case.

On 2023-06-26 13:32, Chris wrote:
> Alan Browne <bitbucket@blackhole.com> wrote:
>> On 2023-06-25 06:07, Chris wrote:
>>> On 24/06/2023 14:45, Alan Browne wrote:
>>>> On 2023-06-23 23:52, Alan wrote:
>>>>> On 2023-06-23 11:19, Chris wrote:
>>>>
>>>>>> It's far simpler than that. There many gene IDs that look like dates to
>>>>>> excel e.g. oct-9, march15, dec-1. When opening a results CSV file of
>>>>>> 20,000
>>>>>> genes excel automatically (and quietly) converts those genes to
>>>>>> dates and
>>>>>> because the data are large the user doesn't notice when saving. Now any
>>>>>> future analysis will contain unknown gene names. This is a problem
>>>>>> as it's
>>>>>> a systematic bias and it's always the same genes that drop out of the
>>>>>> analysis reducing the chances of them being identified as
>>>>>> "interesting".
>>>>>
>>>>> Which would be a problem precisely ONCE for anyone who took the time
>>>>> to see why the error happened and learned how to avoid the problem
>>>>> entirely:
>>>>
>>>> Just created a .csv with the labels mentioned above, imported to excel
>>>> with no conversion.  I should have tested this earlier.
>>>>
>>>> Perhaps, Chris, you could post an actual gene file that "expresses"[1]
>>>> the error for testing?
>>>
>>> I've cropped a bit of a typical file, found here that has been annotated
>>> with the GeneIDs:
>>> https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSE95077
>>>
>>> I've posted it on here:
>>> https://pastebin.com/UU4xhqwD
>>>
>>> Save as a .tsv and then double-click - at least here on my mac - that
>>> opens in Excel with no wizard, no nothing and no warning that data had
>>> been changed. Only only warning as is about "feature loss" if you stick
>>> to using csv formatted (sic) files.
>>
>> I copied and saved via Text - formatted to plain text.
>>
>> Auto opened in Apple Numbers, actually. So used "Open With"
>
> Yeah, I changed the default app.
>
>> Found MARCH2 on line 1855 did convert to a date.
>
> Did you get any warnings or hints that the data might be altered?
>
>> (Excel for Mac, 2019).
>>
>>> I challenge anyone to count how many errors have been introduced in
>>> under 1 minute. You're not allowed to use Search because the insiduous
>>> nature of this is that a priori a naive user wouldn't know that genes
>>> have been affected in this way. The usual use-case is to eye-ball the data.
>>
>> Found 1. I quit!
>
> It's a start. How long did it take to find that one?

Half a minute. Just scrolled - the re-formatted date shifted to the
right side of the cell, so it stood out.

(wrote this yesterday - forgot to send).

--
“If you torture the data long enough, it will confess to anything."
-Ronald Coase