Pan PeJot napisał:

> W dzisiejszych czasach, w których króluje bylejakość często nie idzie
> o zysk, ale o to by przetrwać na rynku.

Nie mając zysku i dokładając do interesu nie da się przetrwać na rynku
(to wiadomo nawet bez obliczania w Excelu).

--
Jarek

do góry

On 17/07/2019 09:05, Dawid Rutkowski wrote:
> Swoją drogą ciekawe, jaką reprezentację liczb miał VisiCalc...

To bez znaczenia, reprezentacja liczb to tylko mały pikuś w porównaniu z
resztą debilizmów koncepcji arkuszy w finansach.

do góry

Jakich?
Poza oczywiście tym, że sama koncepcja arkusza kalkulacyjnego polega na tym, by
umożliwić "programowanie komputerów" laikom, co jest błędem założycielskim.
Podobną sytuację widziałem, jak klient/zleceniodawca pokazywał mi skądinąd bardzo
fajną płytkę z renesasem super h8, tym największym wypasem, z obsługą parallel LCD i
SDRAM liczonego w MB - i do kompletu był soft: eCos z interpreterem TCL jako
aplikacją.
Ten, który mu to sprzedał, twierdził, że "docelowy software będzie mógł napisać nawet
grafik" - oczywiście nie ma co dodawać, jak to się skończyło - ale płytkę+LCD mam ;>

do góry

On 18/07/2019 07:58, Dawid Rutkowski wrote:
> Jakich?

1) Moim zdaniem najważniejszy: brak pojęcia "wszystko". Zamiast tego w
typowym arkuszu znajdziesz range od:do. Czyli zamiast posługiwać się
pojęciem "zsumuj wszystkie miesiące" posługujesz się pojęciem "zsumuj
miesiące od do". Już drugi arkusz z doradztwa finansowego który dostałem
do ręki miał ten bug. Co ciekawe na niekorzyść instytucji. A co
najciekawsze, kiedy mój kolega brał kredyt rok później dostał arkusz
zupełnie inaczej wyglądający ale z tym samym bugiem, w tym samym
miejscu, w tej samej firmie. No, ale kolorki były inne ... a buga
zgłosiłem i jak widać wyszło jak zwykle czyli kontrole wersji uzyskuje
się poprzez jej nieuzyskiwanie bo się nie da

2) Wklejenie czegoś komórkę niżej oznacza problem z punktu 1). Efektem
czego wiargodność wyniku wymaga precyzji nieosiągalnej dla białka po 8h
gapienia się w tabelki. Wisiała kiedyś lista studentów ze stypendiami na
pewnej prywatnej uczelni. Przesunięta o jeden wiersz. I niestety wypłaty
na konto tez były przesunięte ...

3) Pisanie formuł to tak naprawdę cieżkie programowanie czegoś z okolic
lambd. Sekretarki tego nie potrafią. Efekt: po mniej więcej pół roku
obiegu pewnego arkusza część formuł została przerobiona na stałe.
Dowiedziałem się od pewnej księgowej "że tak jest łatwiej coś zmienić
tylko trzeba pamiętać żeby ..."

4) Ukrywanie algorytmiki. W zasadzie nie da się rozsądnie wygenerować
ścieżki obliczeniowej w dużym arkuszu. Szukanie buga jest mordęgą
ponieważ arkusz zasłania tak naprawdę algorytmikę i utrudnia do niej
dostęp recukujac formuły do liczb i uniemożliwiając wygodnie śledzenie
flow obliczeniowego.

5) Brak prawdziwego współdzielenia danych. Arkusze to najzwyczajniej
miliardy copy-paste z innych arkuszy o niejasnym stanie spójności danych
akumulując błędy. Pamiętam panikę w pewnej instytucji kiedy jeden z
oddziałów zmienił nazwę i było "a ze sto chyba" arkuszy do przerobienia.

6) Udawanie że trudne rzeczy można łatwo osiągnąć. Na przykład taki
solver. Rachu ciachu i liczy magicznie gdzie się opłaca kupić taniej
kaszę. Tylko że praktycznie nikt z księgowych nie wie jak działa. Efektm
czego działa przypadkowo. Swego czasu widziałem sporą hurtownię
organizującą zakupy pod kątem logistyki wlasnie na arkuszu z solverem.
Wychodziły bzdury do czasu aż ktoś na kalkulatorze nie pokazał że nie
znajduje najlepszej oferty tylko jakąś przypadkową. Ponad pół roku nie
zauważyli. Komputery się nie mylą.

7) Brak typowości. Arkusz łyknie tak samo łatwo puste pole jak "0" choć
powinno to spowodować błąd przy arytmetyce. Typy pól to tylko taka
wizualizacja. Wiele starych arkuszy potrafi dodać 29 sierpnia do "dupa"
i podzielić przez 13.5. I dostać wynik. I co ważne to jest potrzebne,
jak się dowiedziałem od pewnego sentymetalnie nastawionego nauczyciela
wspominającego bodaj Lotusa z okolic MS-DOSa.

8) Brak oddzielenia algorytmu od danych. Wszystko na kupie łacznie z
wizualizacją kolorowych kresek. Ludzie od antywzorców projektowych
dostają biegunki na samą myśl.

9) Tendencja do akumulacji błędów. Ponieważ nowy arkusz powstaje prawie
na pewno ze starego arkusza to i błędy się akumulują. To raczej
charakterystyczne problemy zarządzania danymi przez pliki a nie
dedykowane narzędzie jak db

10) Udawanie profesjonalnej bazy danych w sytuacji gdy to jest tylko
gówniane narzedzie do rysowania wykresów na laborki. Miałem okazję
ogladać duży arkusz gdzie ktoś zadał sobie trud zorganizowania go jak
bazę danych z indeksami itp. I nie wiadomo po co. Najzwyczajniej. Nie
wiadomo.

11) Kiepskie przystosowanie do obliczeń finansowych, enkodowanie binarne
floating pointów tutaj nie pomaga, nowe koncpecje nie potrafią się
przebić bo nikt z zainteresowanych nie pojmuje w ogóle o co chodzi.

12) Mit że księgowa dostaje arkusz excela i tylko wklepuje dane. Nie, w
wyniku zwykłych błedów białkowych arkusz taki ulega degradacji i ciężko
to stwierdzić gapiąc się tylko na wyniki że gdzieś ktoś skasował formułe
lub zrobił inne kuku. Wszystkie do tej pory arkusze jakie miałem w
rękach miały albo niezabezpieczone algorytmy przed ingerencją albo
zabezpieczone tylko niewielką część jak się komuś przypomniało że
trzeba. Na kretaywność księgowych ogólnie zabezpieczenia nie ma. Arkusz
przypomina odbezpieczony granat zlepiony gumą do zucia.


Oczywiscie można zabezpieczyć arkusze w lepszy lub gorszy sposób. Ale
takie przykłady pokazują że *ABSOLUTNIE* nikt tego nie robi, nawet jesli
to miało by kosztować miliardy dolców strat to dalej cieżko sobie
wyobrazić śrubki bez młotków do wkręcania:

https://www.forbes.com/sites/timworstall/2013/02/13/
microsofts-excel-might-be-the-most-dangerous-softwar
e-on-the-planet/#4108466a633d

Istnieje powszechny mit że komputery liczą dobrze i można im zaufać.
Nikt nie widzi ton białka które te komputery używają jako input do
danych i algorytmów. I to białka często skrajnie tępego technicznie w
przypadku excela dostającego do ręki cholernie niebezpieczne narzędzie
decydujące o miliardach dolców.

do góry

W dniu 16.07.2019 o 12:07, yabba pisze:

> Dział księgowości w firmie jest odpowiedzialny tylko za
> rejestrowanie zdarzeń gospodarczych (zakupy, sprzedaż, amortyzacja
> środków trwałych, wytwarzanie towarów handlowych i usług, koszty
> wynagrodzeń) zgodnie z obowiązującymi przepisami podatkowymi w celu
> przygotowania sprawozdania finansowego i obliczanie należnego podatku
> dla Urzędu Skarbowego.

Tylko? A przytulanie inżynierów? ;-)

pzdr
mk

do góry

Fajnie piszesz, jest co poczytać - ale to wszystko sprowadza się do tego, że m$
zdołał przekonać nawet wielkie korporacje (bo że aż miliardy - trudno uwierzyć, ale
przeczytam ten artykuł) do tego, że sprzeda im oprogramowanie, dzięki któremu będą
mogli zaoszczędzić na programistach - czyli że dobry program w excelu - zwany dla
niepoznaki "arkuszem" - napisze nawet księgowy.
A prawda jest taka, że i księgowego należy NAUCZYĆ dobrego używania programu - i
wtedy da się zaoszczędzić, ale na liczbie księgowych.
Kto jednak bogatemu zabroni być głupim?

To tak, jak fragment tego mitycznego wywiadu ze Strustrupem na temat tego, dlaczego
powstało C++ - że dawno temu bodajże IBM się wkurzył, że programistom trzeba tyle
płacić i zaczęli uczyć programowania ludzi z działu wprowadzania danych. W ten sposób
pogorszono i ogólną jakość programistów - i wyczyszczono dział wprowadzania danych z
ludzi, którzy to w miarę dobrze robili.

do góry

W dniu piątek, 19 lipca 2019 08:16:37 UTC+2 użytkownik mk napisał:
> W dniu 16.07.2019 o 12:07, yabba pisze:
>
> > Dział księgowości w firmie jest odpowiedzialny tylko za
> > rejestrowanie zdarzeń gospodarczych (zakupy, sprzedaż, amortyzacja
> > środków trwałych, wytwarzanie towarów handlowych i usług, koszty
> > wynagrodzeń) zgodnie z obowiązującymi przepisami podatkowymi w celu
> > przygotowania sprawozdania finansowego i obliczanie należnego podatku
> > dla Urzędu Skarbowego.
>
> Tylko? A przytulanie inżynierów? ;-)

O, masz jakieś ładne księgowe w firmie? ;>

do góry

W dniu 19.07.2019 o 11:34, Dawid Rutkowski pisze:
> W dniu piątek, 19 lipca 2019 08:16:37 UTC+2 użytkownik mk napisał:
>> W dniu 16.07.2019 o 12:07, yabba pisze:
>>
>>> Dział księgowości w firmie jest odpowiedzialny tylko za
>>> rejestrowanie zdarzeń gospodarczych (zakupy, sprzedaż, amortyzacja
>>> środków trwałych, wytwarzanie towarów handlowych i usług, koszty
>>> wynagrodzeń) zgodnie z obowiązującymi przepisami podatkowymi w celu
>>> przygotowania sprawozdania finansowego i obliczanie należnego podatku
>>> dla Urzędu Skarbowego.
>>
>> Tylko? A przytulanie inżynierów? ;-)
>
> O, masz jakieś ładne księgowe w firmie? ;>

A masz jakichś przystojnych elektroników inżynierów? :-P

pzdr
mk

do góry

heby wrote:

> A po co używać w księgowości obliczeń floating point o precyzji zależnej
> od potęgi 2 :D ?

Kto używa, ten używa. Nasi klienci dostają wyniki przeliczone na
34-cyfrowym decimalu.

Pozdrawiam, Piotr

do góry

heby wrote:

> Jakies nascie lat temu zasugerowano standardem aby wprowadzić kodowanie
> dziesiętne do floating pointów, niewiele by pomogło, ale zawsze coś. I
> co? I nic, jakiś mainframe używa i tyle.

Mylisz się, są wdrożenia komercyjne w produktach przewidzianych do
poważnych obliczeń finansowych. Zauważalną część swojej kariery
poświęciłem na znalezienie sposobów, jak to robić wydajnie, bo okienka
na obliczenia są jakie są, a wolumen danych jest potężny.

A mainframe nie "używa", tylko dostarcza wsparcia na poziomie
sprzętowym, które inni muszą symulować w oprogramowaniu.

> Excel jest super jak trzeba narysować wykres na laborkę. A tu prosze,
> imbecyle podejmują cezycje biznesowe warte miliardy zielonych oczywiście
> z wiadomym skutkiem. Młotkiem faktycznie da się czasem wykręcić śrubkę.

Tak to już działa, że następca imbecyla kupi już właściwy program. :-)

Pozdrawiam, Piotr

do góry