[varadinagypal]

De obicei, cand vin juniorii -- fiindca faculatea invata avioane in baza 13 si 16, dar nu si asta lucrurile importante, ma uit la tine acum, Babes-Bolyai -- , le dau exercitii de gandire de genul:

x == (x+1)
ori
(7*n) != (n+n+n+n+n+n+n, sper ca am scris de sapte ori)

si sigur se vor uita ciudat, ce vrea nenea cu "practica vs teorie". Tocmai ca nu, ca tot teorie e: nenea vorbeste despre alte avioane, complexitati si densitatea de informatie, sfidarea distributivitii si asociativitatii din cauza acumularii de erori de rotunjire, parfumuri din astea care devin importante cand comparam margini sau formulam SQL, ori devin perechi de adevarat-fals in functie de abordare, si in SQL va functiona intr-un fel (ca rotunjeste sau nu la doua zecimale), or

de ce oare, in softul meu de astro, in loc de arcsinus folosesc safeArcsinus?

Ori, de pilda acest "unit-test":

Online C Compiler.
Code, Compile, Run and Debug C program online.
Write your code in this editor and press "Run" button to compile and execute it.
*******************************************************************************/
#include <stdio>
#include <stdint>
int main(){
uint32_t uintA = 0xFFFFFF00;
float floatA = (float) uintA;
uint32_t inspectionStart = uintA+1;
uint32_t inspectionEnd = inspectionStart+128;
for (uint32_t a = inspectionStart; a < inspectionEnd; a++){
int e = ((float)a == floatA);
printf("Expecting 0 (not equal), getting %d %s for (%lu == %0.f)\r\n", e, e ? "(__equal__)" : "(not equal)", a, floatA);
}
return 0;
}

[nobody]

warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘uint32_t’ {aka ‘unsigned int’}

Poate asa este mai intuitiv ce se intampla cand inghesui 32bit de UINT in 23bit de FLOAT:

[AVD]

[auriga]

Tocmai la UBB se tine un curs de Radu Trambitas numit Calcul Numeric unde se studia si Teoria erorilor si aritmetica ın virgula flotanta.

[varadinagypal]

prima chestie e

int x = 123456 // mai mare decat 16 biti, chiar si fara bitul de semn
...
cat e range-ul intului pe arduino uno (sau nano, 328P e nucleul, hint: e garantat sa aiba minim 16 biti, dar...)?

https://www.geeksforgeeks.org/int-1-sign-b...word-in-c/

a se observa diferenta dintre int, long int, si int32_t si int64_t, respectiv daca era pe esp32 int-ul era...

INT_MAX, sizeof(int),

si mai vezi notatia cu de UL de pilda -- cand unei constante hard coded ii fortam marimea, e o nebunie cu type promotion etc

uint32_t x = 1234567UL;

[varadinagypal]

[nobody]

[AVD]

Daca tot am deturnat, din nou, pagina de proiect in discutii si tutoriale, sa adaug si eu ceva:

Cred ca am reusit sa imi rezolv problema. Aparent, daca impart 2 variabile int (fie ele long, uint16, uint32, etc.), nu va merge. Solutia a fost sa fac acele doua variabile de tip float si sa le adaug .0 la final.

Exemplu despre ce vreau sa spun in urmatoarele poze.

Logica mie mi-ar dicta ca nu are de ce sa functioneze ce am facut eu, pentru ca rezultatul impartirii il atribui unui numar float, deci nu vad de ce numerele de dinainte nu ar putea sa fie int.
Cel mai sigur imi scapa modul in care microprocesorul executa, de fapt, operatia de impartire.

Disclaimer, din nou: Nu sunt programator de meserie, n-am mai pus mana pe cod din liceu, de peste 10 ani. Go easy on me

[valy]

Sunt importante tipurile, sunt importante cast-urile automate, fiecare cu regula lui.
Impartirea e cea mai parsiva operatie, cateodata chiar si simpla adunare, de ex daca incrementezi 0 cu 0.01 de 100 de ori la final o sa ai anumite surprize...
Testarea este importanta, modul cum functioneaza compilatoarele, limbajele, hardwareul este important, chiar si cum definesti o simpla constanta poate fi crucial.

Este si o capcana asta cu sistemele "simple" gen arduino, cat timp te joci si aprinzi un led acasa e ok, cu conditia sa nu dai foc la ceva

[varadinagypal]

putina practica
=========

atribuirea se face la un float, dupa ce operatia s-a facut asupra unor inturi.


putine teorie
========

Daca te-ai intalnit cu notatia poloneza care reflecta precedenta, asociativitatea etc:

1*(2+3) se scrie *+2,3,1

// varianta pentru muritori, cu functii de prototip: numar operator(operand1: numar, operand2: numar)

mul(1, add(2,3))

Sa se sesizeze ca si conversiile de tip (cast) dar si integer/float promotion (de pilda la sprintf, chiar si cand ele nu sunt scrise explicit) sunt functii cu un singur operand: f(x): y

unde x si y sunt variabile, adica perechi de { tip, valoare }

practica
=====

astfel, mai pe C-lang

int x = 3
int y = 1
int z = 1
// float a = toFloat(integerDivision(x, intAdd(y, z))
float a = x / (y+z);

rezultat: a == 1.00000000

teorie de limbaj si compilator
==================

python si cu javascript si cu php si c# si c si c++ si ce o mai fi, in functie de preferintele celor care au facut/comandat limbajul, de strictetea si garantiile / lejeritate care trebuie date de parser/compilator, la compiletime/runtime,

au alte idei despre type-inference, type-conversion, rotunjiri, despre teoria de tipuri, adica despre {tip, valoare} in general si conversiile de {tip1, valoare1} => {tip2, valoare2}, despre operator overload, in cazul c++ de pilda explicit, ori implicit la javascript unde problemele incep cu ordinea de numar+string sau string+numar, + fiind cu overload pentru concatenare si adunare aritmetica, dar - fiind doar scadere aritmetica

iti recomand, pe langa manualele de facultate sau liceu, unele de kkt, altele chiar bune, serialul lui Bartosz Milewski de pe youtube, despre teoria categoriilor, daca te intereseaza astfel de perversiuni intelectuale. Ca in practica, fix de din astea te vei lovi, si in python, si in C

[AVD]

Multumesc de recomandari!

Am rezolvat si problema cu PWR_TOTAL, si anume calculul ei in 2 pasi, cu PWR_TOTAL_S, apoi TOTAL_H. Aceeasi rezolvare: time1 si time2 ii initiam ca si long. I-am initiat ca float si acum nu mai am nicio problema. De asemenea, am facut un artificiu care sa imi masoare/estimeze puterea consumata intre cicluri.

time1=millis();
[...]
PWR_TOTAL = PWR_TOTAL+ ((((prev_pwr+PWR)/2)*(time1-time2))/3600000); // total power in W*h
prev_pwr=PWR;
time2=millis();
PWR_TOTAL = PWR_TOTAL+ ((PWR*(time2-time1))/3600000); // total power in W*h

Sper ca se intelege ce am vrut sa fac aici: tin minte puterea din ciclul trecut, fac media cu puterea din ciclul asta si le inmultesc cu diferenta de timp intre finalul ciclului trecut si inceputul ciclului actual. Apoi atribui valori noi pentru prev_pwr si time2 si calculez puterea consumata in ciclul curent.

[nobody]

Un pic mai simplu, asta depinde de cum interpreteaza compilatorul, microprocesorul doar executa codul generat de compilator.

[nobody]

Inca nu mai ai nicio problema ... inca ... dar ai o potentiala pierdere de precizie de la 32 bit (unsigned long) la 23 de bit (float) care poate duce la "Catastrophic cancellation" https://en.wikipedia.org/wiki/Catastrophic_cancellation

[valy]

Acel /360000...se aplica tuturor termenilor, fiecare aplicare duce la erori de aproximare, nu mai bine il aplici o singura data?

x/2+y/2 = (x+y)/2

Asa ai si optimizare, 3 vs 2 operatii per total.

Operatiile pe int sunt de obicei mai rapide si mai eficiente energetic decat float/double, la numarator poti face calcule doar pe int. O alta optimizare.
Casturile consuma si ele timp.

Dar sa vezi, tot adunand, sa nu depasesti capacitatea tipului de date.

[AVD]

Nu inteleg la ce te referi cu acel /3600000 care se aplica tuturor termenilor si poate fi aplicat o singura data... cum adica sa il aplic o singura data? Mie din calculul ala imi pare ca asta fac.. impart puterea calculata * timpul in milisecunde la 3600000, sa o transform in W*h.


Chiar nu imi pot da seama cum as putea imbunatati aici calculul, incat sa si functioneze cum trebuie. PWR total nu va depasi niciodata float, cu siguranta. time1 si time2, insa, cresc foarte rapid. Nu stiu daca pot depasi float intr-o sesiune de observatii, care va dura, in medie, sa zicem, 5 ore maxim. 5h * 3600000 inseamna 18 milioane de milisecunde.