Kétszer kettő néha öt

Kétszer kettő néha öt − szólt a nóta a hasoncímű filmben. No, a szorzásnál kevésbé bonyolult művelet sem mindig stimmel a nagytudású redmondi óriás alkotásában. Esetünkben a 4+3=5 ellentmondást kellene feloldani valahogy…
A vizsgált tartomány (C2:C5) celláinak száma 5, melyek.közül valójában csak 1 cella üres (C2), a többinek csak az értéke üres karakterlánc. Ezt az ÜRES() függvény (E2:E6) is, valamint a nem üres cellák összeszámlálása (H4) is tökéletesen bizonyítja. Mégis, a DARABÜRES() függvény szerint 3 üres cella található a vizsgált tartományban! "Don Corleone, tégy igazságot." ;)


Aki egy kicsit is ismeri a Microsoft sajátságos gondolkozásmódját és megoldásait, ezen az anomálián már egy cseppet sem csodálkozik.
A DARABÜRES() függvény a leírás szerint a megadott tartomány üres celláit számolja meg. Na, itt van a kutya elásva! A megoldást mint oly sokszor, most is a Súgóban találjuk egy szerényen meghúzódó megjegyzés formájában:
A függvény az üres szöveget ("") eredményező képleteket tartalmazó cellákat is figyelembe veszi, de a zérus értéket tartalmazókat nem.
Erről a cseppet sem mellékes körülményről persze a függvény leírása egy szót sem ejt, így aztán a gyanútlan felhasználó, aki jóhiszeműen abból a feltevésből indul ki, hogy a függvény azt csinálja, amit a neve sugall, áldozatul esik a Microsoft fondorlatos ármányának.
A függvény ilyetén viselkedése teljességgel értelmetlen, hiszen az üres karakterláncra történő vizsgálat (="") ugyanerre az eredményre vezet, ugyanakkor a fizikailag üres cellákat csak a kevéssé ismert CELLA() függvénnyel lehet vizsgálni.

Munkafüzet letöltése: 2007+ (xlsx) | 97-2003 (xls)

Hányas vagy? (Reloaded)

Egy korábbi írásban már foglalkoztam azzal, hogyan lehet kiszámítani valakinek a napra pontos életkorát. Lássunk most még egy módszert! A megjegyzések egyikében feltett kérdésre tekintettel kibővítem a lehetőségeket egy további formátummal is.

Van egy függvény az Excelben, amit még a súgó sem tartalmaz:
DÁTUMTÓLIG(kezdő dátum;záró dátum; egység)
A függvény két dátum különbségét számolja ki években, hónapokban vagy napokban. (Jellemző, hogy ez az amúgy kiváló függvény csupán a Lotus 1-2-3-mal való kompatibilitás okán került bele a programba. Úgy látszik, a Microsoft úgy vélte, az ő felhasználói nem méltóak erre az eszközre.)
A függvény részletes leírását magyar nyelven csak a SharePoint szerver kapcsán ismerteti a Microsoft, de ott is hibásan, minthogy magyarra fordították a függvény dátum argumentumait is. Ezekkel az argumentumokkal a függvény a #SZÁM hibaüzenetet eredményezi csupán. A helyes argumentumok tehát Y, M, D, MD, YM és YD. Amennyiben a dátum argumentumokat nem közvetlenül a képletbe írjuk, hanem dinamikusan adjuk meg, úgy nem kell idézőjelek közé tenni őket!

A DÁTUMTÓLIG és a szökőévek
A függvény az YD egység argumentum esetén a kezdő dátum évszáma alapján veszi figyelembe a szökőéveket. Például:

Kezdő dátum Záró dátum Egység Eredmény
2011.02.01 2012.03.01 YD 28
2012.02.01 2013.03.01 YD 29

Életkor: 51 év 11 hónap 4 nap
Ha a fenti formában szeretnénk egyetlen cellában megkapni valakinek a pontos életkorát, akkor − feltételezve, hogy a kezdő dátum a B1, illetve a záró dátum a B2 cellában van − az alábbi képletet kell beírnunk:
="Életkor: "&DÁTUMTÓLIG(B1;B2;"y")&" év " &DÁTUMTÓLIG(B1;B2;"ym")&" hónap "
&DÁTUMTÓLIG(B1;B2;"md")&" nap"
N. B.: A függvény neve angolul DATEDIF().

Fájl letöltése: 2007+ (xlsx) | 97-2003 (xls)

Jótékony melléütés

Alapesetben óriásméretű szóközök alakulhattak ki tömbös szedés (sorkizárás) esetén a kézi sortörés (Shift+Enter) sorában. Első sorban ezért nem is használtam soha kézi sortörést. :'(
Egy véletlen melléütésnek köszönhetem, hogy rájöttem, hogy ha közvetlenül a kézi sortörés elé egy TAB karaktert szúrunk be, akkor kulturáltan a két eljárást egymás mellett alkalmazni! :D
N. B. Ügyelni kell arra, hogy a kézi sortörés eltávolítása esetén a TAB karaktert is törölni kell.

Itt valami nem kerek...

Mielőtt tovább olvasod ezt az írást, kérlek, próbáld felidézni a kerekítéssel kapcsolatos ismereteidet. Megvan? ... OK.
Akkor most gondold át újra, mit is értesz azalatt, hogy valamit lefelé kerekítesz! Megvan? … Remek!


Ha te is arra jutottál, hogy lefelé kerekítés során a kerekítendő számhoz legközelebb eső (megfelelő pontosságú) kisebb vagy egyenlő − azaz a mínusz végtelen felé eső − számot tekintjük az eredménynek, akkor egyetértünk. Ha ezt a Microsoft is így gondolná, nem volna miről írnom. De Billre és csapatára bátran számíthatok, egy ideig még szolgálnak néhány rágni való csonttal.
Matematikai téziseit egészen eldugott helyeken publikálja a Microsoft. Ez alkalommal a súgó az, ahol a kutya el van ásva. Itt tudatják ugyanis a nagyérdeművel, hogy ŐK a lefelé kerekítést úgy értelmezik, hogy az mindig a 0 (nulla) felé történik. Csakhogy ez nem más, mint csonkolás, aminek elvégzésére külön függvény áll rendelkezésre.


A probléma természetesen periferikus, hiszen az eltérés csak negatív számok lefelé kerekítésekor mutatkozik, de ez mit sem változtat azon, hogy a Microsoftnak nem kellene felülbírálnia a matematika szabályait!