Nog heel veel meer ontwerptips en domme fouten

Op 18 juli 2019 16:28:53 schreef Arco:
Moet zijn: (R1+R2)/(R2/1.204)

Er staat (R1+R2)/ R2 x 1.204 en dat is correct. Vermenigvuldigen en delen wordt gewoon van links naar rechts gedaan dus de uitkomst van R1+R2 deel je door R2 en de uitkomst daarvan vermenigvuldig je met 1.204. Zo je wilt: ((R1+R2)/ R2) x 1.204, maar dat bevalt volgens de normale rekenregels onnodige haakjes.

Op 19 juli 2019 06:19:41 schreef fatbeard:
[...]
Dit kreeg ik op de lagere school al mee: Meneer Van Dalen Wacht Op Antwoord.

Die heeft iedereen hier op school denk ik wel geleerd. En het is fout.

(Vermenivuldigen en Delen gaan van links naar rechts) gaan voor
(Optellen en Aftrekken gaan van links naar rechts)

Op 19 juli 2019 08:13:44 schreef rew:
[...]
Er staat (R1+R2)/ R2 x 1.204 en dat is correct. Vermenigvuldigen en delen wordt gewoon van links naar rechts gedaan dus de uitkomst van R1+R2 deel je door R2 en de uitkomst daarvan vermenigvuldig je met 1.204. Zo je wilt: ((R1+R2)/ R2) x 1.204, maar dat bevalt volgens de normale rekenregels onnodige haakjes.

omdat dit bij typen verwarrend is, is het wel duidelijk als je eht zou uitschrijven met de hand:

Haakjes zijn wel zo duidelijk, ook omdat er bij bijv. compilers subtiele verschillen zijn bij het parsen van complexe vergelijkingen...
Zo maakt Powerbasic verschil tussen integer en floating point delingen...

Operator Precedence:

· parentheses ( ) 
· exponentiation (^) 
· negation (-) 
· multiplication (*), floating point division (/) 
· integer division (\) 
· modulo (MOD) 
· addition (+), subtraction (-) 
· relational operators (<, <=, =, >=, >, <>) 
· NOT, ISFALSE, ISTRUE 
· AND 
· OR, XOR (exclusive OR) 
· EQV (equivalence) 
· IMP (implication) 

Heb in het verleden ook wel eens een compiler gehad die van rechts naar links werkte bij vergelijkingen...

Misschien moet je dan ook stoppen met zulke basic beun compilers, GCC doet het gewoon goed, en de regels voor andere operators (zoals bitwise, logic, etc.) zijn vastgelegd.

Nu ben ik zeker met je eens dat extra haakjes waarmee je onduidelijkheid wegneemt voor jezelf en de volgende programmeur die de code leest meestal een goed idee is, maar als je dat moet doen omdat je compiler zich niet aan de regels houdt, betekend dat die compiler in de digitale afvalbak hoort.

blablabla Wat sparky zegt. +1

Haakjes maken code en/of formules universeel uitlegbaar en toepasbaar. Voorkomt misverstanden.
Ik ben er voor om zaken duidelijk en niet voor verkeerde uitleg vatbaar op te schrijven. Een extra haakje ga ik me niet over opwinden...

Ik ook niet. Iemand had een patch ingestuurd voor een stuk open source code wat ik onderhoud. Eerste wat ik doe is twee setjes haakjes toevoegen.

Maar, wat sparky zegt: een compiler die zich niet aan de gepubliceerde regels houdt, die moet in de vuilnisbak. Je weet dan niet wanneer ie zich weer ineens anders dan wat je verwacht gaat gedragen.

Toen wij voor het eerst hier met AVR gingen werken kwamen we na een tijdje er achter dat met -O2 de compiler case constructies niet goed compileerde. Dat geeft een heel vervelend gevoel: Je kan er niet meer van uitgaan dat a = b+c; doet wat je wilt.

Maar goed, in de "taal" van formules mag er van uit gegaan worden dat je "vandale" kent.

Vaak weet je niet wat voor compiler de andere partij gebruiken gaat, dus beter universeel werkende code maken.
We hebben in het verleden ook zo'n 'haakjes' probleem gehad met een HC11 compiler.

De code was naar een Chinees verstuurd die er iets aan moest veranderen.
Aangezien de compiler een Chinees-achtig iets was, en de goede man zeer 'geblekkig' Engels sprak, was het moeilijk om erachter te komen wat er mis ging.
In ieder geval was het probleem na plaatsen van flink wat haakjes in vergelijkingen opgelost...

Op 19 juli 2019 14:27:15 schreef Arco:
We hebben in het verleden ook zo'n 'haakjes' probleem gehad met een HC11 compiler.

Laat me raden: een Basic compiler? Ik zie een patroon.

99% van de embedded wereld gebruikt GCC, of een compiler die is afgeleid van GCC, met ondersteuning voor een specifieke core. Is het dat je altijd al bij "de 1%" wilde horen?

Ik moet eerlijk zeggen dat ik het met SparkyGSX eens moet zijn: Je zou voor een bepaalde taal gewoon zeker moeten weten hoe de operator-precedence is. Ik kan me ook bij de HC11 niet herinneren dat dat ineens anders was; als je niet uit kunt gaan van K&R of ANSI-C (voor je C-compiler dus) dan wil je het hele ding eigenlijk helemaal niet meer gebruiken.

Dit is overigens ook één van de redenen dat ik BASIC-varianten mijdt: het is altijd nét weer even anders dan een andere BASIC.

"Mijnheer van Dalen wacht op antwoord" zou elke compiler moeten aanhouden. En dat doet deze ook.

Heeft niks met basic te maken, was een C compiler...
Er zijn behoorlijk wat afwijkende compilers, daar zul je mee moeten leven.
Klant heeft er niets aan als je zegt dat z'n compiler niet deugt; beter universeel toepasbare code schrijven dan...
(spaart ergernis en onnodige lange discussies uit)

[Bericht gewijzigd door Arco op 19 juli 2019 19:18:04 (70%)

Een C compiler die geen K&R of ANSI-C doet is geen C-compiler. Het is fijn dat je dan een workaround met haakjes kunt doen, maar de compiler bevat op dat moment gewoon een bug die gefixt moet worden.

Niet erg klantgericht ingesteld, he?...
Er zijn nu eenmaal compilers die afwijken. Als je dan iedere keer zegt 'koop maar een andere, ik doe er niks aan', dan houd je niet veel klanten over...
Terwijl een simpele syntaxverandering de boel op kan lossen. Ik heb nu eenmaal geen invloed op welke compiler klanten/dealers gebruiken...

Om over twee haakjes (die verder niets aan de code veranderen, maar alleen verduidelijken) ruzie met klanten te gaan maken vind ik zinloos.

Het gaat niet om ruzie met klanten. Als die compiler stuk is, dan werk je daaromheen, dat begrijp ik ook.

Ik moest een keer iets doen met een specifieke C-compiler die de mist in ging met switch-statements. Viel op een bepaalde manier (na inspectie van de resulterende assembly) omheen te werken, dus op die manier het probleem maar opgelost, immers moet het product van de klant zsm werken.
Maar... tevens bij de fabrikant van de compiler een bug-report ingediend.

Als jij standaard overbodig veel haakjes gaat gebruiken, niet vanwege leesbaarheid maar puur met als reden dat de compiler het misschien niet doet zoals het hoort... dat is gewoon een heel ander verhaal.
Dan kun je net zo goed in elke functie je by-value doorgegeven parameters eerst maar even voor de zekerheid in een andere variabele zetten, voor het geval dat de compiler toch per ongeluk veranderingen teruggeeft aan je aanroepende code. Slaat ook helemaal nergens op.

Of wat minder exotisch: mensen die menen dat je er niet vanuit mag gaan dat de rechter operand in een logic-OR (||) of logic-AND (&&) niet wordt geëvalueerd als de linker operand reeds respectievelijk true of false blijkt.

Voor al die dingen geldt: het is gewoon vastgelegd dat de compiler zo MOET werken. Doet hij dat niet, dan is hij stuk.

Op 19 juli 2019 08:13:44 schreef rew:
[...]
Er staat (R1+R2)/ R2 x 1.204 en dat is correct. Vermenigvuldigen en delen wordt gewoon van links naar rechts gedaan dus de uitkomst van R1+R2 deel je door R2 en de uitkomst daarvan vermenigvuldig je met 1.204. Zo je wilt: ((R1+R2)/ R2) x 1.204, maar dat bevalt volgens de normale rekenregels onnodige haakjes.

Ik zou het weer anders opschrijven:

(R1+R2 / R2) x 1.204

Mogelijk zit ik er volkomen naast, rekenen is niet mijn sterkste kant..
Maar ik moet het toch even kwijt.

Op 19 juli 2019 23:34:46 schreef Martin V:
(R1+R2 / R2) x 1.204

Nu moet je dus eerst R2 delen door R2. De uitkomst wordt opgeteld bij R1, en daar het resultaat van gaat nog even maal 1204.

Lijkt me niet wat je wilt, want dan had je de formule al meteen kunnen schrijven als (R1+1) x 1204

Op 19 juli 2019 23:34:46 schreef Martin V: (R1+R2 / R2) x 1.204

Dat geeft wel echt een ander resultaat!

Als je dit in integers zou berekenen, wordt de volgorde van de berekeningen wel belangrijk voor een nauwkeurigheid van je resultaat; eerst delen en dan vermenigvuldigen is dan een slecht idee, omdat je bij het delen resolutie weggooit.

Is niet altijd een goede oplossing. Als je begint met een groot getal, dan krijg je overflow na vermenigvuldiging en moet je dus wel beginnen met delen.

Ja, dat had ik er eigenlijk nog bij willen schrijven; wel oppassen dat je niet uit het bereik van je integers loopt. Als de deler een constante is (zoals vaak bij het omrekenen van ADC samples e.d.), kun je de deling in 2 stukken splitsen; eerst wat nodig is om nooit uit het bereik te lopen, en de rest aan het eind, en bij voorkeur doe je die eerste (als het kan beide) dan met een bitshift, dat is eigenlijk altijd significant sneller dan een integer deling.

Veel moderne microcontrollers (zoals de STM32F4 die ik veel gebruik; die gaat toch al een tijdje mee) hebben dedicated floating-point hardware aan boord. Een vermenigvuldiging van 2 single precision floats kost 1 cycle, aangenomen dat de operants als geladen zijn, en een deling 14 cycles. Een integer bitshift kost 1 cycle (ongeacht de shift count), maar een integer deling kost 2 tot 12 cycles, afhankelijk van de waarde van de deler.

Het verschil tussen de worst-case 12 cycles van een integer deling, en de vaste 14 cycles van een floating point is erg klein. Zelfs als je de (2+12)/2 = 7 cycles als gemiddelde neemt voor integer delingen, scheelt het maar een factor 2 op die ene instructie. Je kunt je dan afvragen of het de moeite loont om nog met fixed-point te werken.

Voor controllers zonder floating-point hardware (zoals oude 8-bitters) ligt dat natuurlijk anders.

M'n ex-vriendin kwam vandaag aanlopen met zo'n solar lampje. Nieuw gekocht, had al een jaar ongebruikt gelegen want hij "deed het niet".

Ik: "Ik kijk zo wel even. Kan nooit moeilijk zijn te ontdekken wat er aan mankeert. Die dingen zit bijna niks in: een zonnecel, accu, LEDje en scha...."
Inderdaad: een ON/OFF schakelaar. Had 't zelf ook bijna over het hoofd gezien.

Van mij mogen fabrikanten van solar lampjes die schakelaars wel weg laten...

In theorie gaan ze eerder stuk omdat de hele winter de accu zo goed als leeg is, je moet ze dan ook voor gebruik opladen met de knop op off (al kom ik ze tegen met de schakelaar aan de batterij) en daarna pas aanzetten, en in de winter naar binnen.

Meestal gaat het printje eerder...

met een pir op die dingen werkt beter, dan kom je met een accu in de winter nog wel rond. verders is het ontwerp echt in een warm land gedaan, een accucel laden bij 0 graden is al 1 ding, laat staan 8 uur licht tegen 16 uur donker..

Holy overflow batman, tijd voor een nieuw deel

[Bericht gewijzigd door Sine op 13 augustus 2019 09:45:25 (34%)