[elektro] mikroC PRO for PIC32 ceil probléma

[Nagy Sándor]

"Hogy érted, hogy két tömböt összehasonlítani?"

pl:
char egyik[8];
char masik[8];

if(egyik == masik) {.....}

" Nem mellesleg
lebegőpontos számolásnál ezt mindig át kell gondolni, nagyon sok
kellemetlen meglepetéstől óvhatod meg magad."

nem tudom, használ e valaki közületek mikroelektronikás mikroC-t, de
abban sajnos nincs más tizedesekkel boldoguló számformátum, van még a
double, de minden tesztelésem szerint, semmi különbség nincs a
kerekítésekkel kapcsolatban.

"Ha átgondolod a műveletek sorrendjét és megfelelő helyen kerekítesz,
stb. azzal sokat javíthatsz."
itt a gond, mert mindegy hol kerekítek, ugye a kivesézett okoknál fogva,
mindegy hol teszem, nem minden esetben lesz pontos.

Lassan ott tartok hogy BCD -re (binárilas kódolt decimális) csinálok egy
teljes függvény gyűjteményt. De BCD- nem egy memória optimalizált dolog,
a vele végzett műveletek sem lesznek gyorsak.

---

Üdvözlettel: Nagy Sándor

2013-11-19 11:21 időpontban SZIGETI Szabolcs ezt írta: 

> Hali!
> 
> Ez 10 hatványos ábrázolásnál ez a jelenség ugyanúgy létezik, csak más
> számokkal értelemszerűen. Vagyis számábrázolási alap változtatásával nem
> fogod tudni kikerülni. (Lebegőpontos ábrázolás külön bezavar a véges
> mennyiségű tizedes (kettedes?) jegy által okozott pontosságvesztésnél
> különböző nagyságrendű számokkal végzett műveltnél.) Nem mellesleg
> lebegőpontos számolásnál ezt mindig át kell gondolni, nagyon sok
> kellemetlen meglepetéstől óvhatod meg magad.
> 
> Ha átgondolod a műveletek sorrendjét és megfelelő helyen kerekítesz, stb.
> azzal sokat javíthatsz.
> 
> Szabolcs
> 
> 2013. november 19. 11:05 Nagy Sándor írta, <nasa at 68.hu>:
> Már lassan kezdek belenyugodni, csak azért mégsem értem azt, hogy a mikroC-ben nincs egy olyan számformátum, amivel akár 2 tizedes jegyig sem lehet törtekkel számolni! Nem azt jelenti hogy nem tudom megcsinálni, de ha kitalálok magamnak egy számformátumot, akkor ezek használatakor minden matematikai művelet saját függvényt igényel! emellett biztos van olyan alkalmazás, ahol megfelelhet ez a szám ábrázolási mód, de hiába töröm a fejem, nem jut eszembe olyan, ahol ez megfelelő lehet, persze tuti van, és csupán hatalmas kíváncsiságom miatt érdekelni is, hogy mi lehet az a terület, ahol azt feltételezem egy szoftverben, hogy az általam használt matematikai műveletek 2 tizedes jegyig pontosak, de ez mégsem igaz Alapvetően, mint teljesen kezdő mikroC felhasználó, nagyon sok mindent furcsállok, például nem tud két tömböt összehasonlítani, még nem is az a nagyobb gond, hanem az, hogy a fordító sem figyelmeztet rá, hogy ez nem
  fog
helyes eredményt adni! --- Üdvözlettel: Nagy Sándor 2013-11-19 10:30 időpontban Gergely Vakulya ezt írta: Udvozletem! Ez azert van, mert a lebegopontos szamokat az egyetek tulnyomo reszeben nem az altalunk megszokott normal alakban (mantissza*10^exponens) alakban taroljuk, hanem mantissza*2^exponens alakban. Es ha te egy egeszet leosztasz 100-zal (ami nem 2-hatvany), akkor ott kis kerekitesi hibak adodhatnak. 73/DX HA4UC Gergo On 11/16/13, Nagy Sándor <nasa at 68.hu> wrote: Sziasztok. nem tudom mi lehet a gond, de már kiborultam tőle. adott egy
 float változóban tárolt szám, ezt szeretném 2 tizedesre kerekíteni. ez
ugye ennyi lenne: kerekített_ket_tizedesre = (ceil(kerekítendo_float *
100)) /100); pl 22.95666 lenne 22.96 a legfurább dolog, hogy kb 10
esetből nyolcszor jól csinálja, kétszer nem. amikor nem jó akkor eleve
nem kát tizedest ad vissza, hanem az eredeti számnak megfelelő
tizedesekkel, de ráadásul nem is azt: egy I2C-s hőmérsékletet olvasok
ki, ez teszem egy signed int -be ezzel az alábbi műveletet kell
végezzem: float_eredmeny = (olvasott_int/480)+42,5 ez a táblázat első
sora, ma olvasott_int float_eredmeny float_kerekitett -9455 22,80208
22,80999 -9219 23,29375 23,29999 -9379 22,96041 22,96999 minden esetben
a plusz tizedes jegyek az a 3 db kilences. a float_eredmeny -t
FloatToStr() függvénnyel konvertálom át lehet a hiba oka a FloatToStr
függvény, hogy az szedi össze valahonnan a kilenceseket? de amikor jól
működik akkor meg miért nem? -- Üdvözlettel: Nagy Sándor
----------------------------------------- elektro[-flame|-etc]
----------------------------------------- elektro[-flame|-etc] 

-----------------------------------------
 elektro[-flame|-etc]