CLAD ciekawe pytania testowe część 1

[jacus]

Witam,

Dawno dawno temu gdzieś w sieci znalazłem poniższe pytania testów na które ciężko jest mi samemu odpowiedzieć. Nie chodzi o o samą odpowiedź, ale spokojne wytłumaczenie każdej odpowiedzi z testu. Jeżeli znajdzie ktoś chwilę to proszę o odpowiedź. Poniżej zrzuty ekranu. Może być więcej niż jedna odpowiedź poprawna.

[Daniel PCL]

Haj

Odpowiedź na pytanie 19 - ( B )

Dlaczego ??

Przetwornik 12-bitowy dzieli zakres pomiarowy 0-10V na 2^12 poziomów, czyli na 4096 poziomów. Na każdy poziom przypada 0,002441 V (10V / 4096), czyli 2,44 mV.

Przetwornik 16-bitowy dzieli zakres pomiarowy 0-10V na 2^16 poziomów, czyli na 65536 poziomów. Na każdy poziom przypada 0,000153 V (10V / 65536), czyli 0,153 mV.

My chcemy wykryć zmianę o 2,1 mV, czyli przetwornik 12-bitowy może tej zmiany nie wykryć, ponieważ jest ona mniejsza od 2,44 mV (najmniejsza zmiana wartości, którą wykrywa).

Przetwornik 16-bitowy na pewno sobie z tym poradzi, ponieważ wykrywa nawet zmianę o 0,153 mV


Coś w ten deseń.

Z pozdrówkami
Daniel

[SNT]

40 - B (nie jestem pewien)
38 - A
27 A

[PiDi]

40 - B
Dlaczego? Bo nie ma takiej opcji.
Dlaczego? Bo programista DAQ-A nie zaimplementował
Dlaczego? Bo nikt nie zapisał tego w projekcie
Dlaczego? Bo nie było tego w wymaganiach
Dlaczego? Bo do zaawansowanej generacji sygnałów używa się zwykłych bloczków DAQmx

38 - B
Operacje na całej tablicy są szybsze niż na poszczególnych jej elementach (stąd A jest szybsze od B). - to tutaj nieprawda, patrz dyskusja niżej
W C dodawanie jest zupełnie bezsensowne (kabel między dodawaniem a indykatorem jest typu DBL). Gdyby nie było Add, to C i A miałyby identyczne działanie.
Natomiast wchodząc w bardziej zaawansowane tematy, można by się zastanowić, czy kompilator sam sobie by sprytnie każdego tego przypadku nie zoptymalizował.

27 - A
Dlaczego? Bo tak.


Ed. Zmieniłem odpowiedź na 38.

[aaddaas]

38 - A
Operacje na całej tablicy są szybsze niż na poszczególnych jej elementach (stąd A jest szybsze od B). W C dodawanie jest zupełnie bezsensowne (kabel między dodawaniem a indykatorem jest typu DBL). Gdyby nie było Add, to C i A miałyby identyczne działanie.
Natomiast wchodząc w bardziej zaawansowane tematy, można by się zastanowić, czy kompilator sam sobie by sprytnie każdego tego przypadku nie zoptymalizował.

C odpada, ponieważ LabView poprzez coercion dot konwertuje do "szerszej" reprezentacji (by nie tracić części danych), więc wynik nie byłby single precision array.

[PiDi]

C nie odpada. Popatrz na reprezentację indykatora.

[aaddaas]

Fakt, nie zwróciłem uwagi. Nie mniej jednak takie dodawanie mogło by mieć sens, gdyby konwersja była do szerszego typu danych (pomijając indykator), o czym warto pamiętać na egzaminie;)

[vugie]

40 - B
38 - A
Operacje na całej tablicy są szybsze niż na poszczególnych jej elementach (stąd A jest szybsze od B). W C dodawanie jest zupełnie bezsensowne (kabel między dodawaniem a indykatorem jest typu DBL). Gdyby nie było Add, to C i A miałyby identyczne działanie.
Natomiast wchodząc w bardziej zaawansowane tematy, można by się zastanowić, czy kompilator sam sobie by sprytnie każdego tego przypadku nie zoptymalizował.

Aż benchmark zrobiłem - i wychodzi A (szybciej o jakieś 15%). To co piszesz o operacjach na całych tablicach jest prawdą, ale:
- zmienia się tutaj fizyczny rozmiar tablicy
- pętla już jest, więc robienie operacji w niej nie jest dodatkowym overheadem

Poza tym operacja na całej tablicy to też pętla, tyle że wewnętrznie kompilator potrafi wykryć że robisz ich ileś pod rząd i wrzuca to w jedną pętlę.

[PiDi]

Ok, masz rację, jak na to teraz spojrzałem, to to co napisałem wcześniej jest głupie Zrobienie rzutowania po zbudowaniu tablicy powoduje zaalokowanie całej nowej tablicy nowego typu, co jest kosztowne.

[Nowszy]

jacus, możesz mi podesłać linka do miejsca, gdzie znalazłeś te pytania?

[Jamal79]

Tak generalizujac,
Te pytania sa tendencyjne.

Np, pytanie nr: 27.
Poco to komu pamietac jak moze spojzec na pomoc i zobaczyc.

Pytanie nr: 19.
Rozumiem sens i slusznosc takich pytan, ale jestem zwolennikiem rozgraniczenia tych dziedzin. tzn, kwesti hardware and software. Laczenie tych dziedzin, zabija kreatywnosc. Jezeli chcemy wyniesc sie na wyzyny i doprowadzic do tego statusu, ze nasze programy beda mega wydajne i mega funkcjonalne musimy przekraczac wszelkie granice. A pomiar 0,1 mV jest przez wiekszosc ludzi malo prawdopodobny (Fluke multimeter: dokladnosc z zakresu 0,1-1000V to 0,1 % +1). Rozumiem ze chcac pracowac w NASA lub CERN bedziemy to wykozystywac, ale i tak wtedy najpier musimy miec doktorat z inzynierii...