Kanske möjligvis för enkla saker som kräver snabbhet så används detta. Men estimering vet jag inte om det skulle användas. Man ska bli klar också. Tid är pengar.TomasL skrev:Därför att de allra flesta som jobbar inom embedded använder just heltalsaretmetik, eftersom det är fasiken så mycket snabbare, jämfört med flyttal.
Allokering utav minne - Acceptabelt inom inbyggda system?
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
Eftersom det historiskt sett inte funnits någon flyttalsprocessor i embeddedhårdvara, så har man helt enkelt fått göra det i heltal.
Och naturligtvis fortsätter man med det, eftersom det ger lika hög noggrannhet, i vissa fall högre än flyttal, och dessutom i regel är snabbare.
Och som baronen skriver, heltal är vanligt i spelmotorer mm.
Och naturligtvis fortsätter man med det, eftersom det ger lika hög noggrannhet, i vissa fall högre än flyttal, och dessutom i regel är snabbare.
Och som baronen skriver, heltal är vanligt i spelmotorer mm.
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
(Och man får vad man betalar för.) Men bara för att man kör flyttal så blir det inte automatiskt "rätt". Flyttal ser liksom på ytan ut som att de motsvarar reella tal, men det gör de ju inte alls. Ett 32-bitars flyttal kan ha så lite som sex signifikanta siffror!Kanske möjligvis för enkla saker som kräver snabbhet så används detta. Men estimering vet jag inte om det skulle användas. Man ska bli klar också. Tid är pengar.
- Krille Krokodil
- Inlägg: 4062
- Blev medlem: 9 december 2005, 22:33:11
- Ort: Helsingborg
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
Det är lite pill men inte inte så svårt i C++ att ersätta float/double som internt räknar med heltal.DanielM skrev:Skulle uppskatta om någon löste följande med ints only.
Det komplicerade fortfarande i de numeriska beräkningarna och felanalysen där, har man delberäkningar
som drar iväg mot 1/oändligheten eller +- oändligheten så kan det kvitta om man representerar talet med
32 eller 64 bitar, man har ändå noll koll på vad som händer i den svarta lådan och vilka fel man har på det
som kommer ut.
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
Historiskt så fanns det 4 och 8 bits processorer så varför använda längre ordlängd, dög det att landa på månen med så duger det än idag.
Känns lite som en DDR tråd fast för datorer.
Varför inte köra analog reglering, det dög ju även förr?
Känns lite som en DDR tråd fast för datorer.
Varför inte köra analog reglering, det dög ju även förr?
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
> Historiskt så fanns det 4 och 8 bits processorer så varför använda längre ordlängd, dög det att landa på månen > med så duger det än idag.
Därför att längre ordlängd (än 4 och 8 bitar) gör att det blir betydligt effektivare att göra praktiska beräkningar.
Historiskt fanns även t.ex. 36 bitars processorer, en byte var nio bitar. De är ungefär lika vanliga som 4-bits processorer idag(?).
> Känns lite som en DDR tråd fast för datorer.
> Varför inte köra analog reglering, det dög ju även förr?
Därför att tiden inte står stilla. När såg du senast ett analogt kalmanfilter?
Därför att längre ordlängd (än 4 och 8 bitar) gör att det blir betydligt effektivare att göra praktiska beräkningar.
Historiskt fanns även t.ex. 36 bitars processorer, en byte var nio bitar. De är ungefär lika vanliga som 4-bits processorer idag(?).
> Känns lite som en DDR tråd fast för datorer.
> Varför inte köra analog reglering, det dög ju även förr?
Därför att tiden inte står stilla. När såg du senast ett analogt kalmanfilter?
Allokering utav minne - Acceptabelt inom inbyggda system?
Snigelen, du missade ironin i mitt inlägg. Där ser man hur svårt det är med internet debatter, nyanserna är svåra att förmedla.
Även jag ser framtiden an med spänning.
Även jag ser framtiden an med spänning.
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
Jag håller med att räkna med binärt är mer nogrannt och mer effektivt vid körning. Men det finns en annan aspekt också - ork & tid.
FORTRAN är ett språk som räknar så?
FORTRAN är ett språk som räknar så?
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
Skulle gärna vilja se ett exempel på hur det har gått till när programmeraren använder avancerade algoritmer. Nej, PID är inte en avancerad algoritm.Krille Krokodil skrev:Det är lite pill men inte inte så svårt i C++ att ersätta float/double som internt räknar med heltal.DanielM skrev:Skulle uppskatta om någon löste följande med ints only.
Det komplicerade fortfarande i de numeriska beräkningarna och felanalysen där, har man delberäkningar
som drar iväg mot 1/oändligheten eller +- oändligheten så kan det kvitta om man representerar talet med
32 eller 64 bitar, man har ändå noll koll på vad som händer i den svarta lådan och vilka fel man har på det
som kommer ut.
Rekrusiv minsta kvadratmetod är avancerad.
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
I MATLAB så utför jag numeriska beräkningar. Mitt resultat blir 27.7106
I C utför jag mina numeriska beräkningar. Mitt resultat blir 27.71065
Det är circa 1000 snurror med for-loopar åt olika håll och divideringar.
Detta är väldigt bra med tanke på att i C använder jag endast floats. Det blir mer och mer intressant det ni säger om att summera binärt än att addera flyttal. Jag kan få så det blir exakt men orken och tiden vet jag inte om jag har.
I C utför jag mina numeriska beräkningar. Mitt resultat blir 27.71065
Det är circa 1000 snurror med for-loopar åt olika håll och divideringar.
Detta är väldigt bra med tanke på att i C använder jag endast floats. Det blir mer och mer intressant det ni säger om att summera binärt än att addera flyttal. Jag kan få så det blir exakt men orken och tiden vet jag inte om jag har.
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
En 32-bitars µC kan - med en 32-bitars variabel - enkelt jobba med värden mellan 0 och 4 294 967 295.
En enkel omskrivning ger att 27,71065 kan multipliceras med 10000 och blir 2 771 065 som ligger väl innanför området.
Så utan att känna till de exakta uträkningar vill jag påstå att om det fungerar med float (OBS: inte double) fungerar det ganska säkert med unsigned long också om man bara ser till att in-signalen skalas med.
På en µC med FPU inbyggd kan skillnaden mellan float & unsigned long vara mindre, utan FPU kan tiden uträkningerna tar minskas en del.
En enkel omskrivning ger att 27,71065 kan multipliceras med 10000 och blir 2 771 065 som ligger väl innanför området.
Så utan att känna till de exakta uträkningar vill jag påstå att om det fungerar med float (OBS: inte double) fungerar det ganska säkert med unsigned long också om man bara ser till att in-signalen skalas med.
På en µC med FPU inbyggd kan skillnaden mellan float & unsigned long vara mindre, utan FPU kan tiden uträkningerna tar minskas en del.
- Krille Krokodil
- Inlägg: 4062
- Blev medlem: 9 december 2005, 22:33:11
- Ort: Helsingborg
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
Det är precis samma sak som innan, man ersätter bara sina float/double med sin "MyFloat" som internt räknarDanielM skrev:Skulle gärna vilja se ett exempel på hur det har gått till när programmeraren använder avancerade algoritmer. Nej, PID är inte en avancerad algoritm.
Rekrusiv minsta kvadratmetod är avancerad.
på ett sätt som är optimerat för den plattform man kör på.
Det komplicerade arbetet ligger i Matlab där man behöver analysera varje steg i algoritmerna och se till
att de inte i något steg är beroende av hög precision nära 32 bitar. Exempel på sådan felanalys och
omstukning av beräkningar finns i grundböcker i numerisk analys. Fel ordning på beräkningarna i en
ekvationslösare kan leda till beräkningar typ 0.0000000000000000022362525/0.0000000000000000023324256
vilket mer liknar matematiken i lotto eller kaos, någon modellering av (relativt) tröga reglersystem är det inte, de
är i tidshorisonten 1 ms saker som går att approximera med snälla linjära system.
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
Hur mycket mindre då? Kan man få en siffra från ett exempel?Icecap skrev: På en µC med FPU inbyggd kan skillnaden mellan float & unsigned long vara mindre, utan FPU kan tiden uträkningerna tar minskas en del.
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
Skapade en ny tråd om ämnet för att undvika utbredning av diskussionsämnet.
Senast redigerad av DanielM 9 oktober 2019, 19:15:18, redigerad totalt 3 gånger.
Re: Allokering utav minne - Acceptabelt inom inbyggda syste
Så jag behöver bara byta ut float mot long? Inge mer? Det finns inte risk att talen blir för stora?Krille Krokodil skrev:Det är precis samma sak som innan, man ersätter bara sina float/double med sin "MyFloat" som internt räknarDanielM skrev:Skulle gärna vilja se ett exempel på hur det har gått till när programmeraren använder avancerade algoritmer. Nej, PID är inte en avancerad algoritm.
Rekrusiv minsta kvadratmetod är avancerad.
på ett sätt som är optimerat för den plattform man kör på.
Det komplicerade arbetet ligger i Matlab där man behöver analysera varje steg i algoritmerna och se till
att de inte i något steg är beroende av hög precision nära 32 bitar. Exempel på sådan felanalys och
omstukning av beräkningar finns i grundböcker i numerisk analys. Fel ordning på beräkningarna i en
ekvationslösare kan leda till beräkningar typ 0.0000000000000000022362525/0.0000000000000000023324256
vilket mer liknar matematiken i lotto eller kaos, någon modellering av (relativt) tröga reglersystem är det inte, de
är i tidshorisonten 1 ms saker som går att approximera med snälla linjära system.