Microsoft fixt Excel-functie die naam van genen in data veranderde

Microsoft heeft de werking van de Excel-functie voor automatische conversie aangepast, zodat het niet automatisch namen van genen omzet naar data. De namen van de genen waren al aangepast, omdat Excel ze bleef zien als data.

De fix is afgelopen week beschikbaar gemaakt, meldt een Microsoft-engineer die aan Excel werkt. De fix zorgt ervoor dat er opties zijn voor de verschillende soorten conversie van data in Excel, waardoor gebruikers die ergens tegenaan lopen specifieke vormen van conversie kunnen uitzetten.

De fix komt jaren nadat wetenschappers hebben aangegeven dat het bij het invoeren van genen fout gaat in Excel. Ongeveer 3,5 jaar geleden wijzigden de wetenschappers van Human Gene Nomenclature Committee de namen van sommige genen om verwarring met data in Excel te voorkomen. Daarbij ging het onder meer om Membrane Associated Ring-CH-Type Finger 1, dat tot voor kort MARCH1 heette. Excel zette dat automatisch om in '1 maart' en wetenschappers die dat programma gebruiken, moeten dat dus elke keer ongedaan maken. Er was geen manier om te voorkomen dat Excel dat doet. MARCH1 heet nu MARCHF1 en SEPT1 heet sindsdien SEPTIN1

Microsoft Excel: controle over dataconversie

Reacties (120)

[Melones]

Het zou fijn zijn als iedereen die zichzelf serieus neemt als wetenschapper nou eens zou afstappen van excel als database (of überhaupt). Van ieder fatsoenlijk wetenschappelijk onderzoek is de herhaalbaarheid en controleerbaarheid een groot goed, want falsificatie betekent óók dat de mensheid verder komt qua kennis. In excel zijn honderden manieren om de data te vernachelen en het is schier onmogelijk om alle tussentijdse mutaties accuraat te controleren. Je ziet alleen het eindresultaat van alle bewerkingen.
Om het onderzoek en bijbehorende papers daadwerkelijk zowel bewijstechnisch als statistiek technisch goed te kunnen beoordelen is het scheiden van (ruwe) data en logica erg belangrijk.

Helaas zie je nu dat 99% van het wetenschappelijk onderzoek vooral op dit gedeelte zwaar tekort komt en dat is precies waar kwantitatieve onderzoeken eigenlijk hun geloofwaardigheid aan zouden moeten ontlenen... Maar de huidige druk om altijd iets significants te rapporteren laat mensen toch vaak de 'opgepoetste' resultaten die in de juiste richting hinten presenteren...

[GoldenLeafBird]

Het zou fijn zijn als iedereen die zichzelf serieus neemt als wetenschapper nou eens zou afstappen van excel als database (of überhaupt).

Oneens, het probleem zit m.i. niet in het programma Excel, maar in hoe er mee gewerkt wordt. Deel van gedegen onderzoek is ook continu controleren waarmee je bezig bent. In dat opzicht biedt Excel juist vele mogelijkheden omdat je eenvoudig je data kan visualiseren en daarmee kan controleren.

[Melones]

Daarom zeg ik ook primair "als database".
Indien je data in een DB staat (niet acces...) dan kan je gewoon met Excel of PowerBI desktop die data visualiseren (met een read only login natuurlijk). Dan kan je makkelijker aantonen dat er niet met je metingen gerommeld is.

[SunnieNL]

Dat is natuurlijk ook weer onhandiger met delen. Moet je dan een SQL backup meeleveren?
Anders heb je weer een SQL beheerder nodig die de database opzet, zorgt voor backups, zorgt dat anderen toegang gaan krijgen. Dus dan zit er steeds iemand tussen de onderzoeker en zijn data. Dat is ook heel onhandig voor de onderzoekers.

[Melones]

Voor het delen gebruik je natuurlijk een fatsoenlijk formaat zoals json of xml, het liefst mens-leesbaar dus dan valt parquet af.
Mijn oproep is vooral om er wat fatsoenlijker en vooral ook controleerbaarder mee om te gaan. Dat dit meer werk is dan gewoon wat in excel 'prototypen' moge duidelijk en terecht zijn. Bij laboratoriumwerk zorg je ook voor steriel materiaal, goede procedures en medewerkersveiligheid en in die vergelijking vind ik 'data en logica hygiene' wel degelijk cruciaal om vervuilingen zowel in het werken alsook de conclusie te voorkomen en de onderzoeker te beschermen tegen beschuldigingen van vooringenomenheid of beïnvloeding.

[elmariachi]

Zo oldskool allemaal. Dit doe je toch niet meer op deze manier.
Tijd om naar de cloud te gaan voor je datastorage, analytics, data sharing, visualisaties, backup, ...
Dan kan je ook AI, ML en MLops gaan gebruiken.

[HenkEisDS]

Maar in welke toekomstbestendige database dan?

Vragenlijsten worden online ingevuld in systemen als Qualtrics. Die wil en kun je daar niet oneindig laten staan. Meer technische datasets, zoals bijvoorbeeld DNA zullen uit specialistische hardware/software komen die geenszins universele standaarden hebben en al helemaal niet geschikt zijn voor lange termijn opslag.

En een SQL server is overkill en ook niet toekomstbestendig.

[Youckle]

SQL Server is ook geen database, als je met Oracle hebt gewerkt.
Maar SQL Server is zeker een betere optie om data in te verzamelen dan in in Excel.

[Reactie gewijzigd door Youckle op 23 juli 2024 18:44]

[goarilla]

Gebruiken die onderhuids (MS access, MS SQL server) niet allemaal de JET engine ?

[the_stickie]

MS SQL gebruikt geen JET (meer)

[the_stickie]

Wat is MS SQL dan wel
Er zijn wat verschillen, waar Oracle soms boven uitkomt, maar ook soms onder. Bijvoorbeeld dat MS SQL je een arm en een been kost in licenties, maar dat je voor Oracle DB er ook nog je romp en oren mag bijleggen
Ik heb in redelijk wat 'global enterprises' gezeten als niet-DBA. In mijn ervaring is een (ver geschaalde) database zowel op Oracle DB als MS SQL zo goed/krachtig als de DBA + de infra.

[Admiral Freebee]

Veel universiteiten hebben echter niet de kennis of infrastructuur om met "de juiste" tools te werken. Denk maar aan de sociale wetenschappen waar veel data bijvoorbeeld uit vragenlijsten komt. Dat levert meestal een CSV file op die gebruikt kan worden om in een specialistisch programma statistische analyses op te doen. Maar wat doe je ondertussen om de data op te schonen? Vaak kom je dan toch gewoon bij Excel terecht want dat is een tool die iedereen heeft staan en waar iedereen de basis van kent.

Na de analyse moet je de data ook weer exporteren en visualiseren. Wederom ligt Excel voor de hand want die kan je data inlezen en grafieken maken. Zijn er betere tools? Vast. Maar die zijn niet altijd voorhanden of men heeft er niet de kennis van. Vergeet niet dat wetenschappers ook maar mensen zijn en geen universele allesweters. En doorgaans is de IT infrastructuur ook niet zo geweldig geregeld aan een universiteit.

[goarilla]

Ok als snelle controle, alhoewel Origin daar misschien beter voor bedoelt is maar niet als data opslag.
Je hebt geen idee welke datatype en dus welke precisie je exact gaat krijgen wanneer je de save-knop op Excel drukt.

[Lord Anubis]

Ik denk beide; het is niet altijd handig hoe Excel nog werkt na al die jaren. Nog zoveel eigenaardigheden. Kijk eens buiten wat je zelf tegen komt bij de publieke bugreporters sites
Gewoon een moderne versie met python ( ipv vba ) erin, naast de huidige versie gooien. De oude versie voor bestaande geregistreerde gebruikers gratis in 3 jaar uitfaseren. Geen nieuwe aanmeldingen voor de oude versie maar gelijk nieuwe versie leveren. En gelijk alles OS versies met gelijke features

[Sleurhutje]

In dat geval zou je Excel kunnen gebruiken als frontend voor je dataset in een database. Dan doet het probleem met automagische ongevraagde conversies zich namelijk niet voor.

[latka]

Excel bied heel veel mogelijkheden maar gebruikers kennen die vaak niet of willen die niet kennen. Het controleren van computers is voor de meeste mensen een brug te ver qua moeite of kennis. Het pakket moet "het gewoon doen". Dus het zit wel in het pakket, maar de oplossing is wellicht clippy terugbrengen met als heuristiek: "ik zie dat je Excel probeert te gebruiken als database. Ik alles gekopieerd naar MS Access en je Excel weggegooid"

[HenkEisDS]

Wat stel je voor als alternatief? Excel is imho juist een goed open en toekomstbestendig formaat. Nu zal ik niet zo snel een excel bestand bijvoegen bij een paper, dan zou ik liever kiezen voor CSV of XML, maar die zou ik wel laten genereren door Excel en Excel zou ook mijn eerste database zijn.

Ik denk verder dat er amper wetenschappers zijn die hun berekeningen in Excel doen. Want hoewel het in theorie mogelijk is om complexe statistiek toe te passen vermoed ik dat ze hier andere software voor gebruiken. SPSS was in mijn studententijd DE tool, weet niet of dit nog steeds zo is.

[Jahe1990]

Voor mij (afgestudeerd van Wageningen in 2021) was SPSS ook nog steeds heer en meester tijdens de studie hoor. Echter waren er wel een paar mensen die het durfden om met R te klooien. Excel werd veel gebruikt maar zeker niet voor statistiek!

[curkey]

Het produceren van csv met Excel is een gevaarlijke operatie met vele onverwachte wendingen.
Het is vermoedelijk ontwikkeld door hetzelfde team dat in Word zorgt voor automatische nummeringen.

[theobril]

Ja is nog zo . Dat is, bij de sociale wetenschappen met name.

[Andreas01]

Eens! Daarnaast is Excel als proprietary software ook niet heel erg geschikt om open science en herhaalbaarheid/controleerbaarheid mee te bevorderen. Immers zul je toch een licentie moeten hebben om volledig gebruik te kunnen maken van zo'n bestand.

[HenkEisDS]

Het hangt er een beetje af waarvoor je excel gebruikt. Data opslag, opschonen, etc, kan prima in excel in een open bestandsformaat (.ods). Dit is vervolgens te openen met ieder ander spreadsheet programma. Meer dan dat moet je ook eigenlijk niet doen in Excel, zo wel dan zul je het naar andere formaten moeten exporteren zoals pdf.

https://dans.knaw.nl/en/file-formats/spreadsheets/

[Andreas01]

Ah tuurlijk. Je kunt natuurlijk ook CSV'tjes bekijken en bewerken in Excel. Het probleem zit hem meer bij het .xlsx bestandsformaat. Maar ik ben een beetje bang dat de mensen die Excel gebruiken om hun data op te schonen, ook wel xlsx zouden gebruiken...

[mjl]

Pre iets, als je iets serieus doet met genen dan gebruik je geen excel voor je data. 15 jaar geleden kon je er nog net mee wegkomen maar een beetje alignment van sequencing data heb je betere pipelines en tools voor om die te visualiseren.

[Schway]

EIndelijk!
Dit is ook zo vervelend als je met telefoonnummers werkt. Altijd ben je de 0 kwijt, en ook nog eens zie je ze met e er in staan.
Nu wachten tot de werkgever de fix uitrolt 😅

[japie06]

Cel formatteren als tekst of de invoer met een apostrof ( ' ) beginnen.

[curkey]

Dat is leuk als je met de hand dingen invoert en er met je brein bovenop zit. Maar met een copy-paste gaan er al eens dingen scheef, laat staan met automatische invoer vanuit een database, of het inlezen van CSV bestanden.

Met name dat laatste is al jaren een grote puinzooi. Hoe vaak ik wel niet vernachelde bestanden heb gekregen vanuit de business vanwege Excel zijn "intelligentie".

[MeltedForest]

csv importen is knap irritant ja. Handmatig die kolommen instellen is ook geen beginnen aan als je er meer dan 30 hebt. En Excel denkt het altijd beter te weten op de automatische stand.

Wat overigens wel goed werkt, csv importeren in een datamodel via power query en dan als tabel in een sheet laden.

[Reactie gewijzigd door MeltedForest op 23 juli 2024 18:44]

[curkey]

Ja powerquery is een godsgeschenk, zeker met terugkerende uploads. Eén keer een template maken en klaar. Ook hele folders opslurpen gaat geweldig.

[latka]

De reden dat ik CSV en Excel niet mix. LibreOffice gaat veel zinniger met CSV om is mijn ervaring.

[Schway]

Ik weet wel hoe het op te lossen is. Ik ben gewoon blij dat ik het straks kan voorkomen.

[theobril]

Oeps, dank voor deze apostrof-oplossing. Met name datums gedragen zich heel eigenzinnig in (exporten van) excel, Deze kan ik gebruiken om het dataformaat vast te zetten. Bijvoorbeeld mailmerge naar word, dan wil hij bij mij nog wel eens de datum wijzgen in het mergeproces qua formattering

[juke1349]

"gewoon als mens je in rare, obscure bochten wringen, omdat de 'slimheid' van je software te ontwijken"..

Ik ben al zoooo vaak tegen deze "behulpzame" functies aangelopen..
En het is onrealistisch om van mensen te verwachten om bij iedere keer dat je dubbelklikt op een spreadsheet, een paar dozijn kolommen op "text" te moeten zetten..

Ze hadden zó veel leed kunnen voorkomen als ze dit op kolom-niveau zouden dubbelchecken.
Dus alleen wijzigen als de conversie op meerdere cellen werkt, niet opportunistisch op iedere cel waar het gaat.

[iqcgubon]

Breek me de bek niet open over IP adressen...

[SunnieNL]

kwestie van de kolom laten weten wat de value is. Als je er geen berekeningen mee gaat doen (lijkt me namelijk sterk) dan moet je er gewoon tekst van maken. Dan blijft Excel er gewoon van af.

[juke1349]

Dat is leuk als je één spreadsheet per week opent..
Bij mijn vorige baan (daadwerkelijk CSV files met genetische data) was ik dagelijks bij een dozijn van die dingen aan het inspecteren.
Dan wordt je heeeeel snel zat hoeveel kliks 'kolom > text" kost.

[masterfragger]

Python import scriptje ....

[Ayporos]

of gewoon met MS Access werken.
Als je toch al per se binnen microsoft office wil blijven, gebruik dan gewoon Access?

[bussie66]

Precies!

[juke1349]

Acces is geen optie bij 5 petabyte

Database was Postgres, en ondergetekende had libreoffice calc, en heeft dat bij meerdere collega's aanbevolen.

[Ayporos]

en wat doet Excel precies wat je niet met Postgres kan doen?
Ongetwijfeld zijn er betere visualisatie tools dan Excel om met die data te babbelen toch?

[juke1349]

Je hebt een CSV-viewer nodig om te inspecteren of je fancy nieuwe wetenschappelijke script een beetje zinnige output geeft, of dat alle kolommen weg zijn omdat je een tab verkeerd hebt gezet in je python script (en nee, dat is géén sarcasme)

[Reactie gewijzigd door juke1349 op 23 juli 2024 18:44]

[juke1349]

De eigenlijke verwerking ging met groovy, python, R of C, afhankelijk van welke phd de software geschreven had.

Neemt niet weg dat je regelmatig gewoon even met je eigen ogen een blik moet werpen, dus excel als viewer..

Of nouja, dus Libreoffice, wat duidelijk minder data vernaggeld, en veel minder opdringerig is met z'n autocorrect. (voorbeeld: in Libreoffice maakt ctrl+Z eerst de autocorrect ongedaan, en pas de tweede Ctrl+Z ook de menselijke invoer. Microsoft sleurt de autocorrect én je moeizame invoer samen de afgrond in bij de eerste..)

[Reactie gewijzigd door juke1349 op 23 juli 2024 18:44]

[kidde]

Dat is wel interesant, want ik vind Excel juist de beroerdste CSV viewer die er is.

Als je op een CSV dubbelklikt in Windows en laat openen met Excel, hangt het van je datum instellingen af wat je te zien krijgt, en of de kolommen kloppen.... Dus ik leer juist alle collega's dat Excel totaal ruk is voor CSV. En voor machines hebben we gespecificeerd dat we Europese CSV's als exportfotmaat willen.

[Ayporos]

Gewoon een regel toevoegen bovenin met de gebruikte separator, dan maken je datuminstellingen niet uit.
sep=,
Ik produceer wel eens CSV bestanden op 't werk en gemakshalve voeg ik dat altijd toe zodat men het kan lezen ongeacht hun instellingen want ja, mensen hebben nou eenmaal bepaalde voorkeuren voor hun regionale instellingen..

[goarilla]

Excel modelines in csv files ? Interessant. Is dat de field/column seperator of the thousand seperator of ... ?

[kidde]

Bedankt, die kende ik nog niet!

We hebben wel machines waarbij het door PLC's of extern geleverde software wordt weggeschreven, dat kunnen we niet zo makkelijk aanpassen.

[Paul]

"Gewoon" geen IPv4-adressen gebruiken waarvan de laatste drie octetten alle drie boven de 100 zitten

Technisch gezien zijn IPv4-adressen 32 bits integers, maar het is inderdaad een groot gemis dat Excel nog altijd de dotted quad niet als datatype of opmaak kent.

[Tjidde]

Bij IP adressen begin je toch nooit met een nul?

Als je volgens mij meer dan 1 punt in een nummer zet maakt Excel er toch ook automatisch een string van? Althans wel in de versie die ik heb.

[beerse]

Het valt nog mee dat je de voorloop-0 kwijt bent en het nummer niet wordt aangepast. Op andere systemen betekend een getal dat met een 0 begint dat het een octaal getal is. Dan zou het getal ingevoerd als "0123" terug te vinden zijn als 83. Zo zijn er wel meer conventies die binnen excel anders gaan dan op andere platformen en/of andere software. Altijd iets om rekening mee te houden.

Wat automatisch gaat, gaat automatisch een keer fout.

[curkey]

We hebben hier in het bedrijf artikelnummers met significante voorloopnullen. Dus materiaal 0123 is iets anders dan 123. Niet heel handig als mensen zaken uit ERP copy-pasten in hun werkblad.

[beerse]

Leer die gebruikers om de kolom (of het hele spreadsheet) het type op tekst of zo te zetten in plaats van de standaard 'automatisch', zoals tekst of zorg er voor dat er een eigen type komt onder 'speciaal' of zo.

Maak gebruikers bewust van wat ze doen. Daarmee voorkom je de meeste fouten.

[curkey]

Op nieuwe medewerkers na weet de business prima dat Excel bestanden vernachelt. Het probleem is vooral dat je op sommige dagen haast hebt een data uit verschillende bronnen moet kopiëren.

Dan heb je naast voorloopnullen nog andere quirks van Excel. Zoals dingen als een datum formatteren indien een waarde erop lijkt. Wat vrij ruim is.

Dan heb je nog dat hij dag en maand in datumvelden voor je wil omdraaien als je regional settings afwijken, maar dat doet hij alleen indien de dag groter dan 12 is.

En al deze irritante workarounds moet je iedere keer weer opnieuw doen.

Godzijdank kun je nu powerquery gebruiken om csv in te lezen, zodat je herbruikbare sheets hebt. Maar veel Tante Annies en Handige Henkies in de business kennen alleen maar de Text To Columns optie.

Helaas is Excel de meestgebruikte database en interface tool, want het is de meest waardeloze.

De csv export is ook zo eentje. Ik heb nu bij een aantal lui parallel de Libre Office Calc erbij laten zetten, waar je niet je Windows regional settings hoeft te verkloten om specifieke csv export opties in te stellen, want je krijgt hier keurig en dialoogscherm.

[Schway]

In theorie. In de praktijk kun je beter de gebruikers voor zijn en anticiperen op hun fouten.
Gebruikers zijn mensen, en mensen maken fouten.

[curkey]

Ik zit vooral aan ontvangende zijde, dus dan is het leed al geschied. Sommige fouten kun je nog redelijk makkelijk spotten, maar andere veel minder.

Stel een voorloopnul verdwijnt, maar het record codeert nog wel naar een bestaand (ander) product. Zo'n fout kan best lang duren voordat deze gespot wordt.

[latka]

Significante voorloopnullen.... dat is nog erger dan white-space sensitive programmeertalen imho.

[Twanne]

aaaah, dat roept herinneringen op van programmeren in Cobol of Python.

[menke]

Dit is ook zo vervelend als je met telefoonnummers werkt. Altijd ben je de 0 kwijt

Lijkt mij wel prettig om het herkennen van getallen als feature in een spreadsheetprogramma te houden ;-)

[curkey]

Maar blijf dan wel af van voorloopnullen, of desnoods VRAAG het.

[Arokh]

En in bevolkingsprognoses heb je meestal leeftijdscategorieën zoals 0-4 5-10 Etc. Die converteert die dus ook altijd automatisch naar 5 oktober. Om gek van te worden als je daar veel mee bezig bent.

[reinouts]

Daar kun je misschien wel omheen werken door een ander type liggend streepje te gebruiken, zoals een em-dash?

[johnvanwaard]

Cel of reeks van cellen selecteren, dan Ctrl-1 of rechtermuistoets - celeigenschappen
kies Speciaal - telefoonnummer.
Deze functie zat al in Excel 97

[Admiral Freebee]

Excel heeft, zoals iedereen die het programma gebruikt wel weet, zijn eigenaardigheden. Als je de applicatie in het Engels gebruikt met de autocorrect in het Nederlands dan gaat hij standaard de formule TEXT omzetten naar TEKST waardoor die niet meer werkt. Dan krijg je =TEKST(

Je kan het wel verwijderen uit de lijst maar na elke reinstall is het weer een (kleine) frustratie.

[Reactie gewijzigd door Admiral Freebee op 23 juli 2024 18:44]

[DeCo]

Sowieso, formules taalafhankelijk maken heb ik altijd een slecht idee gevonden in Excel.

[pepsiblik]

Vergeet niet hoe oud Excel is. Begin jaren negentig, met de slechte Engelse taal kennis die er toen in veel landen was (Frankrijk, Spanje, Duitsland), was dit echt een goed verkooppunt.

[Paul]

Dat het de gelokaliseerde naam van een functie kent vind ik helemaal prima. Maar, accepteer dan OOK de Engelse variant! Die naam kent het programma sowieso, want als je een .xlsx opent met een zip-programma en dan bijvoorbeeld Sheet1.xml bekijkt, dan zie je gewoon de Engels namen staan.

Op die manier kun je tenminste ook van Excel gebruiken als je ergens komt waar iemand bijvoorbeeld de Franse versie heeft geïnstalleerd, zonder dan je naar Google moet grijpen om de simpelste dingen voor elkaar te krijgen.

[urk_forever]

Dat lijkt me ook inderdaad wel handig, maar zal wel ivm backwards compatibility niet mogelijk zijn omdat dan iemands Excel sheet uit 1993 niet meer goed werkt
Misschien moeten ze daar ook een opt-in setting voor maken...

[Paul]

Als dat een .xls-bestand is dan doen ze dat zichzelf aan (en vraag ik me af hoe ze dat voor elkaar krijgen).

Als het een .xlsx is dan kan dat niet, omdat de Engelse namen al worden gebruikt in het bestand en de tekst al als tekst staat gemarkeerd.

In beide gevallen is er de optie dat de Engelse formule er staat maar nu ook niet werkt; in dat geval geeft Excel nu "#NAME?" weer, en zou het na de "fix" mogelijk ineens wel werken (al wordt er bij mijn testje in het bestand "_xludf." voor de "foutieve" formule gezet).

[Alex3]

Dat kan in LibreOffice. Als je de Nederlandstalige interface gebruikt kun je omschakelen tussen Engelse en Nederlandse functienamen zonder je bestand opnieuw te openen.

[Auryon]

Of de separator tussen de verschillende argumenten van een functie, zijnde puntkomma, of komma (en die is dan weer niet afhankelijk van taal, maar van locatie). Hoeveel keer ik al niet heb gevloekt bij het kopieren van een functie van een site naar mijn werkblad...

[haam]

Zo herkenbaar. Maar blijkbaar wordt die info wel ergens in de file opgeslagen, want als ik een bestand open wat gemaakt is op een anders ingestelde machine gaat het wel goed.

[Finraziel]

In de file staat voor elk veld wat het voor datatype is. Het probleem zit in als jij gewoon wat in typt dan weet Excel nog niet wat het is en moet het aan de hand van wat je typt een inschatting maken.
Je kunt in de geavanceerde opties geloof ik de separator en decimal character overrulen. Ik vink dat gewoon even snel aan als ik iets moet plakken in Excel met een decimale punt ipv komma en als ik het vinkje daarna weer afhaal staat het ook goed.

[Finraziel]

Ja, maar daar is dan weer niet zoveel aan te doen... Tenzij je wil dat de Amerikanen zich aan ons aanpassen, wat niet gaat gebeuren.

[curkey]

Het zit inderdaad in je regional settings, de List Separator Character, maar je kunt het naar believen aanpassen met eigen invoer.

Ik gebruik van de pipe of tilde, wat fijn is bij csv export. Echter, de Excel formules gebruiken het ook voor de separator van parameters in functies. Dus daar krijg je dan bv =LEFT(A1~3).
Zucht.

[CivLord]

Maar dan worden in veel landen waar Engels niet zo gangbaar is als in Nederland de formulenamen onbegrijpelijke tekenreeksen die je standaard allemaal uit je hoofd moet kennen wil je ze kunnen gebruiken.

[MneoreJ]

Dat is geen supersterk argument, gegeven dat dat in het Engels niet veel anders is. `AMORDEGRC`? `STDEVP`? En hoe weet ik nou dat ik `SUBSTITUTE` moet hebben en niet `REPLACE` als ik tekst wil vervangen? Het kleine voordeeltje dat je in het begin misschien hebt met taalspecifieke functienamen (als ze niet net zo cryptisch zijn als Engels) wordt naar mijn mening ruimschoots teniet gedaan door de incompatibiliteit. Op het moment dat je die formules regelmatig gaat gebruiken blijft het echt wel hangen, zo werkte het voor mij in ieder geval wel lang geleden toen ik met BASIC begon en nog geen Engels kende. Ik had bijvoorbeeld geen idee wat een `QUANTITY` was of hoe je dat uitsprak (kwan-TIE-tie? ) maar ik wist wel wat er fout was als de computer `ILLEGAL QUANTITY ERROR` uitspuugde.

MS zou zoals door anderen voorgesteld op z'n minst gewoon altijd ook de Engelse functienamen toe moeten staan, of zelfs gewoon on the fly vertalen, als het toch moet. Zoals ze het nu doen lusten de honden er geen brood van en worden alleen de echte taalchauvinisten er blij van.

[Reactie gewijzigd door MneoreJ op 23 juli 2024 18:44]

[nandervv]

Voor Nederlands, misschien, maar voor Frans, of Duits, echt niet. Niet iedereen ter wereld spreekt Engels, en het is heel goed dat Microsoft daar rekening mee houdt.

[MneoreJ]

Mijn reactie was op het idee dat als je geen Engels spreekt de formules "onbegrijpelijke tekenreeksen" worden, wat dan zogenaamd beter zou worden met lokale namen. Maar het zijn vaak onbegrijpelijke tekenreeksen ondanks de taal, en als MS echt rekening wilde houden met andere talen dan hadden ze ervoor gezorgd dat je Engelse spreadsheet ook bruikbaar was in Frankrijk, zonder dat de Franse Excel een "désolé, je ne parle pas Anglais" doet (of omgekeerd natuurlijk).

[Reactie gewijzigd door MneoreJ op 23 juli 2024 18:44]

[CivLord]

Nu heb je het wel meteen over de meer geavanceerde functies. En wanneer je weet wat het betekent (wanneer je weet waar je ze voor kunt gebruiken) dan kan je de betekenis wel uit de naam halen.
Wanneer je een functie zoekt, dan kan je uit de lijst met namen al een idee krijgen welke je nodig kan hebben, wanneer je de taal begrijpt. Wanneer je de taal niet begrijpt, moet je elke functie aanklikken om uit de omschrijving de werking te kunnen halen.

De meeste Excelsheets zullen binnen hetzelfde taalgebied gebruikt worden (meestal zelfs binnen hetzelfde bedrijf of afdeling), waardoor de imcompatibiliteit van de verschllende taalversies voor de meeste gebruikers geen rol spelt. Terwijl voor de meeste niet-Engelssprekende landen Engelstalige formules een groot obstakel is voor het gebruik van de formules.
Jij wil heel graag een probleem maken van iets dat voor de meeste mensen geen probleem is en jouw oplossing is om voor de meeste gebruikers daadwerkelijk een probleem te creëren.

[MneoreJ]

Er zou geen enkel probleem zijn als Excel in alle versies ook de Engelse variant accepteerde, ook al hielden gebruikers gelokaliseerde namen. Nog beter was het als die Engelse versie gewoon was wat opgeslagen werd zodat de boel on the fly vertaald werd als je het opende en de hele incompatibiliteit weg was -- of er nu weinig mensen last van hebben of niet. De mensen die het helemaal te gek gaaf vinden dat Excel snapt wat `SUBSTITUEREN` is komen dan nog steeds aan hun trekken.

[pastafan]

Ik snap niet dat ze daar geen instelling voor maken. Formules in taal xxx (te selecteren), zodat je zelf kunt kiezen.

En dan ookk bij het importeren / inladen van een andere taal hierbij rekening houden uiteraard.

[ZinloosGeweldig]

=TEKST.SAMENVOEGEN()

[kevlar01]

Er is geen manier om te voorkomen dat Excel dat doet. MARCH1 heet nu MARCHF1 en SEPT1 heet sindsdien SEPTIN1

Beetje een bold statement (no pun intented), maar je kan prima de celeigenschappen omzetten als tekst toch? Ja, het is een workaround, maar dat betekent niet dat dit onmogelijk is?

[Melkunie]

En dat wordt dus al jaren gedaan, maar is nu niet meer nodig

[kevlar01]

Klopt, heel handig dat het nu automatisch goed gaat
Maar er waren dus wel manieren om het te voorkomen (omslachtig, maar toch).

[Melkunie]

Zeker! Ik bekijk net ook even het plaatje bij het artikel en blijkbaar gaat de update niet alleen over de genetische notatie maar zijn er nu ook meer auto-conversie zaken die je uit kunt schakelen.

Heb zelf jaren in de telecom gezeten en daar zag ik het met telefoonnummers vaak mis gaan, ook door collega's die er ook al jaren me bezig waren. Hopelijk binnenkort ook verleden tijd dus!

[zeemeerman2]

Al even geen Excel meer gebruikt, maar is niet deel van het probleem dat als je een cel omzet in tekst en daarna er uit je klembord een datum in plakt, dat Excel er automatisch terug een datum-cel van maakt? (Op basis van het plaksel)

[Ghoelian]

Kun je dat niet voorkomen door te plakken als ongeformatteerde tekst (ctrl+shift+v)?

[theobril]

nee werkt niet, heb ik zojuist proefondervindelijk bewezen. Is ook wel een beetje logisch: met op die manier er in plakken, haal je de formattering van je bron weg. Maar ongeacht of de datum in de bron/op het klembord geformatteerd of ongeformatteerd is, als excel iets ziet wat voldoet aan zijn eisen van wat een datum is, dan wordt het een datum. edit reactie minder slecht gemaakt

[Reactie gewijzigd door theobril op 23 juli 2024 18:44]

[curkey]

Mits van tevoren gedaan ja, en consistent doorgevoerd. Maar het inlezen van CSV moet je zeer voorzichtig doen, evenals copy-paste acties. Die kunnen soms ook rekenen op het toepassen van "jaren '90 AI-functies" en zodoende naar de knoppen geholpen worden.

[Alex3]

Inderdaad. Als je iets gebruikt moet je weten hoe je er mee moet omgaan. Met een hamer kun je op je vingers slaan. Moeten ze die dan ook aanpassen?

[pc-freakz]

Zou mooi zijn als ze ook een optie maken om alleen nog Engelse formules te gebruiken.
Welke gek bedacht heeft formules te vertalen... Echt een drama als niet iedereen die de bestanden gebruikt 1 Office taal voert.

[Tintel]

Welke gek bedacht heeft formules te vertalen...

Idd en dan ook nog 1-way en niet alleen de visualisatie.... totaal onbegrijpelijk en een veel echter probleem dan deze auto-convert die wat mij betreft simpel te omzeilen is.

[Rob Coops]

En toch he vraag ik me heel erg af of voor veel van de toepassingen waar mensen Excel voor gebruiken het wel echt de juiste tool is. Ik bedoel ik heb zeer veel bedrijven gezien die vrijwel geheel op Excel draaien en dingen als een Excel file van +13MB voor er data is ingevoerd als heel normaal zien.
Als we nu al op een punt zijn gekomen dat wetenschappers namen van genen aan moeten passen omdat Excel er anders niets van snapt dan gebruiken we misschien niet helemaal de juiste tool...

Aan de andere kant een van de dingen die ik geleerd heb is dat je ook maar een heel klein beetje handig bent met Excel je in veel bedrijven vrijwel 100% zeker bent van je baan omdat niemand snapt hoe die sheet werkt en het in middels een cruciaal onderdeel van de bedrijfsvoering is geworden. Helaas, in ieder geval in mijn ervaring, wordt je er zeker geen fijne collega van als je je een langere tijd in die positie bevind. En al helemaal niet als iemand anders dan op eens een aantal bugs in jouw sheet oplost na dat je de business jaren lang hebt verteld dat het nu eenmaal zo werkt...

[MneoreJ]

Excel is zelden de juiste tool, maar wel zeer vaak de tool die makkelijk en voorhanden is, en die twee eigenschappen triomferen bijna altijd over wat het beste is op de lange termijn. In zekere zin is de belachelijke effectiviteit van spreadsheets ook het nadeel ervan. Het is ook niet echt op te lossen in de zin dat het "probleem" zit bij eindgebruikers die werk gedaan moeten krijgen, en ga maar tegen eindgebruikers zeggen dat ze gestructureerd moeten leren werken en de "juiste" tools moeten hanteren, die ze meer beperkingen opleggen (als die tools al bestaan -- als ze eerst in-house ontwikkeld moeten worden ben je natuurlijk nog verder van je perfecte oplossing). De voordelen op de lange termijn zijn duidelijk, maar de drempel is hoog. Zo grijp je als eerste toch naar de spreadsheet en tegen de tijd dat het een onhandelbaar monster geworden is is het te laat.

[Reactie gewijzigd door MneoreJ op 23 juli 2024 18:44]

[fire-breath]

Deed bij mij wel pijn toen mijn excelbaby me afgenomen werd doordat we naar een ecd gingen dat niet een halve boekhouding in excel nodig had.

Maar ja. ik was inderdaad de enige die met het excelbestand kon werken. Baan zekerheid 100%
Helpt ook niet als je collega's al glazig kijken bij het woord 'draaitabel'.

[DeDooieVent]

Je hebt het ook met CAS nummers als je niet uitkijkt

[m2011]

Het wordt ook tijd dat Namibië z'n naam verandert https://stackoverflow.com...turning-na-value-into-nan

[Heroic_Nonsense]

Ah, ja, Excel dat aanneemt dat iets een datum is. Dat is van alle tijden.

https://www.reddit.com/r/...ts/ho0bce/incel_vs_excel/

[DD-IRM]

Goede verbetering. Was vooral met telefoonnummers een ramp, met een verdwijnende 0. Met een streepje tussen netnummer en abonneenummer werd er ook soms van alles van gemaakt behalve het goede.
Heb me al aangeleerd om bij het inkloppen van een tel nummer met een ' te beginnen, dat voorkwam veel.