Nog heel veel meer ontwerptips en domme fouten

Hoeben

Special Member

Op 18 juli 2019 19:57:25 schreef testman:
...de installatie was ook hobbywerk 1e rang, ouwe tweelingkabels overal gespijkerd..

Zoals het hoort door de kabel?

nee, in verf vastzittend en t bekende knoopwerk.

[Bericht gewijzigd door testman op 19 juli 2019 06:57:11 (69%)]

waar rook was, werkt nu iets niet meer

Op 29 oktober 2013 21:27:41 schreef darkpinguin:
Nu komt het vervelende: alle LED's zijn wit uitgeslagen van de secondelijm. Nu moet ik ze allemaal gaan schoonmaken zonder dat ze losgaan of dat het plexiglas beschadigd. Heeft iemand hier ook een oplossing voor toevallig?

Krabben! Laatste keer dat ik dat inruilde voor "oplosmiddel" kreeg ik een CD doosje waar doorheen niks meer leesbaar was. :o

Op 26 oktober 2013 21:48:02 schreef MAH:
Op sommige avonden had je beter een cursus kantklossen kunnen volgen dan de soldeerbout te hanteren!

Kantklossen is ook een veel leukere hobby dan solderen! :) Disclaimer: nog nooit gedaan...

fatbeard

Honourable Member

Op 18 juli 2019 18:11:09 schreef Arco:
Ik vind haakjes toch altijd een stuk duidelijker. Vooral omdat er verschillende bewerkingsvolgordes bestaan...
(ik heb nog geleerd dat delen voor vermenigvuldigen gaat. En dat werd tot eind vorige eeuw vaak gebruikt)

Dit kreeg ik op de lagere school al mee: Meneer Van Dalen Wacht Op Antwoord.
Machtsverheffen
Vermenigvuldigen
Delen
Worteltrekken
Optellen
Aftrekken

Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.

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.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

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:

ik hou van werken ..., ik kan er uren naar kijken

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...

code:


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...

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

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.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

blablabla Wat sparky zegt. +1

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

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... :)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

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.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

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... ;)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

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?

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Jochem

Golden Member

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.

Heb geduld: alle dingen zijn moeilijk voordat ze gemakkelijk worden.
Hoeben

Special Member

"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%)]

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com
Jochem

Golden Member

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.

Heb geduld: alle dingen zijn moeilijk voordat ze gemakkelijk 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.

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com
Jochem

Golden Member

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.

Heb geduld: alle dingen zijn moeilijk voordat ze gemakkelijk worden.

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.

"vroeger" was alles beter'.
Jochem

Golden Member

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

Heb geduld: alle dingen zijn moeilijk voordat ze gemakkelijk worden.

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.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

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.

Bezoek mijn neefjes' site: www.tinuselectronics.nl

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.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken