|
|
 | bit check ?
Fra : Lasse Madsen |
Dato : 29-09-02 14:47 |
|
Hej alle sammen :)
Jeg kunne godt tænke mig at aflæse LSB (første bit) af en 8bit variabel
feks.
0b0000000x
Hvor der så er x jeg gerne vil aflæse uden at kigge på de andre bit.
Umildbart tror jeg at jeg skal OR dem sammen for at undgå at manipulere
nogen af de andre bit nogenlunde sådan:
if ((0b0000000x | ???????))
{
xxx
}
men hvordan OR'er jeg, så jeg finder ud af om X er 1 eller 0 ???
Håber at i skulle have nogle ideer :)
M.v.h.
L. Madsen
| |
 Kent Friis (29-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 29-09-02 14:56 |
|
Den Sun, 29 Sep 2002 15:46:58 +0200 skrev Lasse Madsen:
>Hej alle sammen :)
>
>
>Jeg kunne godt tænke mig at aflæse LSB (første bit) af en 8bit variabel
>feks.
>
>
>0b0000000x
>
>Hvor der så er x jeg gerne vil aflæse uden at kigge på de andre bit.
>
>
>Umildbart tror jeg at jeg skal OR dem sammen for at undgå at manipulere
>nogen af de andre bit nogenlunde sådan:
>
> if ((0b0000000x | ???????))
> {
> xxx
> }
Nix, for at checke en bestemt bit, skal du bruge and. Du and'er bare din
variabel med 1 (værdien af den bit du vil checke):
if(variabel & 1) ...;
Mvh
Kent
--
You haven't seen _multitasking_ until you've seen Doom and
Quake run side by side
| |
Thomas Lykkeberg (29-09-2002)
| Kommentar
Fra : Thomas Lykkeberg |
Dato : 29-09-02 17:22 |
|
On Sun, 29 Sep 2002 15:46:58 +0200, "Lasse Madsen"
<lasse.madsen@elektronik.dk> wrote:
>Hej alle sammen :)
>Umildbart tror jeg at jeg skal OR dem sammen for at undgå at manipulere
>nogen af de andre bit nogenlunde sådan:
>
> if ((0b0000000x | ???????))
> {
> xxx
> }
Som Kent siger skal du AND'e, men din notation 0b00000 duer ikke her.
Du kan kun bruge Octal, Decimal or Hexadecimal notation i C, desværre.
#define MASK_BIT(vALUE,bIT) ((vALUE) & (1UL<<bIT))
Denne makro kan du roligt bruge.
Iøvrigt skal du nok bruge dk.edb.programmering.c gruppen til sådan
noet her. 
/Thomas
| |
Thomas Lykkeberg (29-09-2002)
| Kommentar
Fra : Thomas Lykkeberg |
Dato : 29-09-02 17:23 |
|
On Sun, 29 Sep 2002 18:21:41 +0200, Thomas Lykkeberg
<thomasDOTlykkeberg@privatDOTdk> wrote:
>Iøvrigt skal du nok bruge dk.edb.programmering.c gruppen til sådan
>noet her.
SORRY Jeg sad lige i min egen verden... Doh!!
/Thomas
| |
Lasse Madsen (29-09-2002)
| Kommentar
Fra : Lasse Madsen |
Dato : 29-09-02 20:34 |
|
Hej Thomas.
> Som Kent siger skal du AND'e, men din notation 0b00000 duer ikke her.
> Du kan kun bruge Octal, Decimal or Hexadecimal notation i C, desværre.
Nu er jeg lidt i tvilv ... mener du at man kun kan bruge Hex,Oct, Dec når
man vil lave bit check eller generelt ... for alle de embedded c compilere
jeg kender kan tage feks
PORTC = 0b00000000;
If ( PORTC == 0b00100000 );
> #define MASK_BIT(vALUE,bIT) ((vALUE) & (1UL<<bIT))
>
> Denne makro kan du roligt bruge.
Er det ikke lidt voldsk ?
M.v.h.
L. Madsen
| |
 Byrial Jensen (30-09-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 30-09-02 05:54 |
|
Lasse Madsen <lasse.madsen@elektronik.dk> skrev:
> Hej Thomas.
>
>
>> Som Kent siger skal du AND'e, men din notation 0b00000 duer ikke her.
>> Du kan kun bruge Octal, Decimal or Hexadecimal notation i C, desværre.
>
> Nu er jeg lidt i tvilv ... mener du at man kun kan bruge Hex,Oct, Dec når
> man vil lave bit check eller generelt
Det gælder generelt.
>... for alle de embedded c compilere
> jeg kender kan tage feks
>
> PORTC = 0b00000000;
> If ( PORTC == 0b00100000 );
Det er i så fald en privat udvidelse af sproget og derfor ikke
portabelt. Der findes også embeddede C-oversættere som ikke kender
til "0b".
>> #define MASK_BIT(vALUE,bIT) ((vALUE) & (1UL<<bIT))
>>
>> Denne makro kan du roligt bruge.
>
> Er det ikke lidt voldsk ?
Nej, det er en udmærket makro selvom der burde have været en
parentes omkring brugen af bIT. Andre nyttige makroer kunne være:
#define set_bit(var,bit) ((var) |= (1UL << (bit)))
#define clear_bit(var,bit) ((var) &= ~(1UL << (bit)))
#define toggle_bit(var,bit) ((var) ^= (1UL << (bit)))
| |
Thomas Lykkeberg (30-09-2002)
| Kommentar
Fra : Thomas Lykkeberg |
Dato : 30-09-02 18:31 |
|
On Mon, 30 Sep 2002 04:54:22 GMT, Byrial Jensen <bjensen@nospam.dk>
wrote:
>Det er i så fald en privat udvidelse af sproget og derfor ikke
>portabelt. Der findes også embeddede C-oversættere som ikke kender
>til "0b".
Ja, jeg har til dato ikke stødt på nogle embeddede C-compilerer som
forstår "0b". Egentlig kan man jo undre sig, da det ofte ville være
mere behageligt
/Thomas
| |
Bertel Lund Hansen (30-09-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 30-09-02 06:30 |
| | |
Igor V. Rafienko (30-09-2002)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 30-09-02 12:17 |
|
[ Bertel Lund Hansen ]
[ ... ]
> >#define MASK_BIT(vALUE,bIT) ((vALUE) & (1UL<<bIT))
>
> Hvorfor skriver du vALUE og bIT på den måde?
l337 h4XX0r?
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
Thomas Lykkeberg (30-09-2002)
| Kommentar
Fra : Thomas Lykkeberg |
Dato : 30-09-02 18:29 |
|
On 30 Sep 2002 13:16:51 +0200, igorr@ifi.uio.no (Igor V. Rafienko)
wrote:
>> Hvorfor skriver du vALUE og bIT på den måde?
>
>l337 h4XX0r?
???
| |
Bertel Lund Hansen (30-09-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 30-09-02 19:15 |
| | |
Igor V. Rafienko (30-09-2002)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 30-09-02 20:11 |
|
[ Bertel Lund Hansen ]
[ ... ]
> > >l337 h4XX0r?
> >
> > ???
>
> Det første ord er jeg i tvivl om ("lee?"), men det sidste er
> "hacker".
"elite hacker". Hvem ellers innfører "kamelhumpene" der det ikke er
nødvendig?
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
Kent Friis (30-09-2002)
| Kommentar
Fra : Kent Friis |
Dato : 30-09-02 20:23 |
|
Den Mon, 30 Sep 2002 20:15:25 +0200 skrev Bertel Lund Hansen:
>Thomas Lykkeberg skrev:
>
>>>l337 h4XX0r?
>>???
>
>Det første ord er jeg i tvivl om ("lee?"), men det sidste er
>"hacker".
Der står "leet haxxor", dvs. "elite hacker". Typisk script-kiddie sprog,
men efterhånden brugt af alle der skal gøre grin med dem.
Selv google kan det http://www.google.com/intl/xx-hacker/
Mvh
Kent
--
Indlæringskurven til Linux er stejl, til tider lodret... Men for katten
hvor er udsigten på toppen dog fantastisk
- Michael G. Vendelbo i dk.snak
| |
Thomas Lykkeberg (30-09-2002)
| Kommentar
Fra : Thomas Lykkeberg |
Dato : 30-09-02 18:27 |
|
On Mon, 30 Sep 2002 07:29:31 +0200, Bertel Lund Hansen
<nospam@lundhansen.dk> wrote:
>Thomas Lykkeberg skrev:
>
>>#define MASK_BIT(vALUE,bIT) ((vALUE) & (1UL<<bIT))
>
>Hvorfor skriver du vALUE og bIT på den måde?
Gammel vane.. Nogle bruger _value og _bit, men det er vel en smags
sag. Den egentlige grund er at sikre sig at ingen har defineret en
marko som hedder vALUE eller bIT. Det må antages at muligheden for at
VALUE og BIT kan være defineret som makro et andet sted, er til stede.
Det bunder sådan set i nogle interne C kode regler vi har opstillet
der hvor jeg arbejder. :)
Egentlig definerer vi faktisk makroer som:
#define M_MaskBit(vALUE,bIT) ((vALUE) & (1UL << (bIT)))
Hvor M_ skal sikre at det ikke tolkes som et funktions kald.
/Thomas
| |
Byrial Jensen (30-09-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 30-09-02 19:16 |
|
Thomas Lykkeberg <thomasDOTlykkeberg@privatDOTdk> skrev:
> On Mon, 30 Sep 2002 07:29:31 +0200, Bertel Lund Hansen
><nospam@lundhansen.dk> wrote:
>>Thomas Lykkeberg skrev:
>>
>>>#define MASK_BIT(vALUE,bIT) ((vALUE) & (1UL<<bIT))
>>
>>Hvorfor skriver du vALUE og bIT på den måde?
> Gammel vane.. Nogle bruger _value og _bit, men det er vel en smags
> sag. Den egentlige grund er at sikre sig at ingen har defineret en
> marko som hedder vALUE eller bIT.
Hvorfor vil du sikre dig det? Det har ingen betydning om der er
defineret makroer med de navne da der ikke sker makroekspansion af
makroers parameternavne.
| |
Igor V. Rafienko (30-09-2002)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 30-09-02 20:14 |
|
[ Thomas Lykkeberg ]
[ ... ]
> Gammel vane.. Nogle bruger _value og _bit, men det er vel en
> smags sag.
Det ser ut som at det er tillatt i denne konteksten i C++. Er du
sikker på at det er lov i C?
[ ... ]
ivr, som synes at det ville være mye bedre å skrive dette som en
funksjon.
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
Byrial Jensen (06-10-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 06-10-02 21:03 |
|
Igor V. Rafienko <igorr@ifi.uio.no> skrev:
> [ Thomas Lykkeberg ]
>
> [ ... ]
>
>> Gammel vane.. Nogle bruger _value og _bit, men det er vel en
>> smags sag.
>
>
> Det ser ut som at det er tillatt i denne konteksten i C++. Er du
> sikker på at det er lov i C?
Ja, det er lovligt i C at bruge disse navne som identifikatorer
uden filscope.
| |
Bjarke Dahl Ebert (29-09-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 29-09-02 22:55 |
|
"Lasse Madsen" <lasse.madsen@elektronik.dk> wrote in message
news:an70ai$1tve$1@news.cybercity.dk...
> Jeg kunne godt tænke mig at aflæse LSB (første bit) af en 8bit variabel
> feks.
>
> 0b0000000x
>
> Hvor der så er x jeg gerne vil aflæse uden at kigge på de andre bit.
>
> Umildbart tror jeg at jeg skal OR dem sammen for at undgå at manipulere
> nogen af de andre bit nogenlunde sådan:
Det er ligegyldigt. Du kan bruge både AND og OR.
> if ((0b0000000x | ???????))
> {
> xxx
> }
>
> men hvordan OR'er jeg, så jeg finder ud af om X er 1 eller 0 ???
Tja, siden de andre ikke vil svare på dit spørgsmål (hvordan OR'er man), så
må jeg jo gøre det 
Du skal selvfølgelig OR'e med noget, sådan at resultatet ikke afhænger af de
bits du ikke vil kigge på, men afhænger af den mindstbetydende bit. Der er
kun en mulighed: 0b11111110.
Som C-kode:
unsigned char foo /* ... den som du gerne vil læse 0'te bit af */
if ((unsigned char)(foo | ~1) == (unsigned char)~0) {
/* ... */
Jeg skal dog skynde mig at sige at den løsning er noget uortodoks.
Den konventionelle måde at gøre det på er at AND'e med et tal, hvor kun de
bits (den bit) man er interesseret i, er sat - som andre allerede har
beskrevet.
Mvh. Bjarke
| |
Ivan Johansen (29-09-2002)
| Kommentar
Fra : Ivan Johansen |
Dato : 29-09-02 23:14 |
|
Bjarke Dahl Ebert wrote:
> Tja, siden de andre ikke vil svare på dit spørgsmål (hvordan OR'er man), så
> må jeg jo gøre det
>
> Du skal selvfølgelig OR'e med noget, sådan at resultatet ikke afhænger af de
> bits du ikke vil kigge på, men afhænger af den mindstbetydende bit. Der er
> kun en mulighed: 0b11111110.
>
> Som C-kode:
>
> unsigned char foo /* ... den som du gerne vil læse 0'te bit af */
> if ((unsigned char)(foo | ~1) == (unsigned char)~0) {
> /* ... */
Ja ja, du bruger bare DeMorgan's theorem til at omskrive AND til OR. Som
bekendt er følgende to linier det samme:
z = x & y;
z = ~(~x | ~y);
Hvis compileren er god, kan den optimere det sidste om til det første.
Ivan Johansen
| |
Bjarke Dahl Ebert (30-09-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 30-09-02 21:52 |
|
"Ivan Johansen" <NG@Padowan.dk> wrote in message
news:3D977B2E.7020609@Padowan.dk...
> Bjarke Dahl Ebert wrote:
> > Som C-kode:
> >
> > unsigned char foo /* ... den som du gerne vil læse 0'te bit af */
> > if ((unsigned char)(foo | ~1) == (unsigned char)~0) {
> > /* ... */
>
> Ja ja, du bruger bare DeMorgan's theorem til at omskrive AND til OR.
Vel gør jeg ej! 
Jeg har ikke omskrevet noget som helst - jeg kan lige så godt påstå at jeres
udgangspunkt var OR, og at I ved hjælp af DeMorgan har omskrevet det til
AND.
Og kineserne påstår at det er os der går med hovedet nedad. DeMorgan viser
os bare hvordan vi kan vende verden på hovedet.
> Som
> bekendt er følgende to linier det samme:
> z = x & y;
> z = ~(~x | ~y);
>
> Hvis compileren er god, kan den optimere det sidste om til det første.
Jep, men compileren behøver ikke bruge DeMorgan for at optimere min 'if'
ovenfor.
Det skulle da lige være fordi det nok er billigere at sammenligne med 0 end
med ~0
Bjarke
| |
Bertel Lund Hansen (30-09-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 30-09-02 22:03 |
|
Bjarke Dahl Ebert skrev:
>> Ja ja, du bruger bare DeMorgan's theorem til at omskrive AND til OR.
>Vel gør jeg ej!
Okay, så forklar lige med kode hvordan du vil aflæse om bit 0 er
sat i variablen a's værdi. Antag at a er en int (bestem selv
antal bytes hvis det er vigtigt).
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Bjarke Dahl Ebert (30-09-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 30-09-02 22:14 |
|
"Bertel Lund Hansen" <nospam@lundhansen.dk> wrote in message
news:usehpuou9o5dhii7rj29b92t5ebc55fmd3@news.telia.dk...
> >> Ja ja, du bruger bare DeMorgan's theorem til at omskrive AND til OR.
> >Vel gør jeg ej!
> Okay, så forklar lige med kode hvordan du vil aflæse om bit 0 er
> sat i variablen a's værdi. Antag at a er en int (bestem selv
> antal bytes hvis det er vigtigt).
Hm - er det ikke lige det jeg har gjort i mit tidligere kodeeksempel? Dér
var det bare en byte.
Hvis jeg skal afgøre om bit 0 er sat, kan jeg starte med at sætte alle de
andre bits og så aflæse om alle bits er sat.
Jeg antager 32 bit ints (det er ikke en konkurrence i portabel kode - det
kan blive portabelt med ~-operatoren).
if ((a|0xfffffffe) == 0xffffffff) {
// bit 0 er sat...
}
Mvh. Bjarke
| |
Bertel Lund Hansen (30-09-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 30-09-02 22:17 |
|
Bjarke Dahl Ebert skrev:
> if ((a|0xfffffffe) == 0xffffffff) {
> // bit 0 er sat...
> }
Åh ja, det tænkte jeg ikke på. Men det vil nok være tydeligere at
læse den normale test (også for andre bitpladser):
if (a&1) {}
eller
if (a&1>0) {}
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Klaus Petersen (03-10-2002)
| Kommentar
Fra : Klaus Petersen |
Dato : 03-10-02 15:00 |
|
> Jeg kunne godt tænke mig at aflæse LSB (første bit) af en 8bit variabel
> feks.
>
>
> 0b0000000x
>
> Hvor der så er x jeg gerne vil aflæse uden at kigge på de andre bit.
#define BIT0 0x001
#define BIT1 0x002
...
#define BIT8 0x100
Sætte en bit \"test |= BIT3\"
Checke om en bit er sat \"if (test & BIT3)\"
fjern en bit \"test &= ~BIT3\"
det kan ikke være nemmere
| |
Christian Hemmingsen (03-10-2002)
| Kommentar
Fra : Christian Hemmingsen |
Dato : 03-10-02 15:13 |
|
"Klaus Petersen" <spektual@hotmail.com> writes:
> #define BIT0 0x001
> #define BIT1 0x002
> ..
> #define BIT8 0x100
En anden måde at skrive det på er
#define BIT0 (1 << 0)
#define BIT1 (1 << 1)
....
#define BIT8 (1 << 8)
men husk at sætte paranteserne!
Jeg måtte lære det på den hårde måde
--
Christian Hemmingsen
| |
Jens Christian Larse~ (05-10-2002)
| Kommentar
Fra : Jens Christian Larse~ |
Dato : 05-10-02 15:54 |
|
| |
Igor V. Rafienko (05-10-2002)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 05-10-02 16:28 |
|
[ Jens Christian Larsen ]
[ ... ]
> Hvis LSB er 1 er tallet ulige, hvis LSB er 0 er tallet lige.
Ikke alltid.
> Den viden kan du også bruge, hvis du har problemer med at forstå bit
> operatorene. For at checke om tallet er ulige, kan du evt. bruge
> modulus operatoren, det er let (og langsomt).
Nei, det er ikke tilfellet. Kan ikke du teste antagelsene dine
litegrann før du poster?
Man skal skrive koden som ligger nærmest den matematiske definisjonen
og/eller er klarest, inntil effektivitetshensyn _beviselig_ krever noe
annet. Kompilatoren må være særdeles defekt, dersom den ikke greier å
se likheter mellom "x & 1" og "x % 2" i de kontekstene der de er
ekvivalente. Fx. gcc 3.2 og Sun Forte 6 genererer _identisk_ kode for
begge metodene, på de maskinene der setningene over er semantisk
ekvivalente.
Så, har du noen _gode_ grunner for å foretrekker "x & 1" framfor "x %
2", specielt med tanke på at "x & 1" ikke virker, og "x % 2" er
nøyaktig like rask, er korrekt og er uavhengig av den underliggende
bitrepresentasjonen? Jeg vil gjerne høre begrunnelsen, om du har en.
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
Jens Christian Larse~ (05-10-2002)
| Kommentar
Fra : Jens Christian Larse~ |
Dato : 05-10-02 16:54 |
|
| |
Igor V. Rafienko (05-10-2002)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 05-10-02 17:51 |
|
[ Jens Christian Larsen ]
[ ... ]
> Errrr...nej, jeg ser ingen gode grunde til at han skal bruge AND
> istedet for modulus. Det var jo ligesom derfor jeg forslog at han
> kunne bruge modulus.
Nå ble jeg enda mer forvirret -- Lasse Madsen skulle sjekke verdien av
LSB. Han skrev ingenting om hva han trengte det til. Verdien av LSB
trenger ikke å ha noe som helst å gjøre med hvorvidt tallet er et
partall eller et like tall. Dermed er ikke modulus en aktuell løsning,
og han trenger egentlig & (hvilket man har allerede foreslått).
> Der var ingen i tråden, der havde gjort ham opmærksom på at modulus
> sikkert kunne bruges i hans tilfælde, så det gjorde jeg.
Kanskje fordi at like tall ikke innebærer LSB == 0?
> Hvis du forstod det som at jeg ville fraråde modulus, har du
> misforstået min besked totalt.
Tja, jeg er egentlig enda mer forvirret nå enn før.
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
Jens Axel Søgaard (05-10-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 05-10-02 18:32 |
|
Igor V. Rafienko wrote:
> [ Jens Christian Larsen ]
>> Errrr...nej, jeg ser ingen gode grunde til at han skal bruge AND
>> istedet for modulus. Det var jo ligesom derfor jeg forslog at han
>> kunne bruge modulus.
> Kanskje fordi at like tall ikke innebærer LSB == 0?
>> Hvis du forstod det som at jeg ville fraråde modulus, har du
>> misforstået min besked totalt.
>
> Tja, jeg er egentlig enda mer forvirret nå enn før.
Er det fordi Jens Christian ikke har opdaget, at han har
overset indianer-problemet? [bigendian / littleendian]
--
Jens Axel Søgaard
http://info.astrian.net/jargon/terms/l/little-endian.html
http://info.astrian.net/jargon/terms/b/big-endian.html
| |
Jens Christian Larse~ (05-10-2002)
| Kommentar
Fra : Jens Christian Larse~ |
Dato : 05-10-02 19:07 |
|
| |
Jens Axel Søgaard (05-10-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 05-10-02 19:18 |
|
Jens Christian Larsen wrote:
> On Sat, 5 Oct 2002, Jens Axel Søgaard wrote:
>
>> Er det fordi Jens Christian ikke har opdaget, at han har
>> overset indianer-problemet? [bigendian / littleendian]
>
> Hvad??
> Bigendian /littleendian refererer som regel til bytes, de kan også
> referere til bits, men det har jeg ikke tit set.
Jeg havde glemt, spørgsmålet drejede sig om ku en byte.
Jeg sad og tænkte i heltal.
--
Jens Axel Søgaard
| |
Jens Christian Larse~ (05-10-2002)
| Kommentar
Fra : Jens Christian Larse~ |
Dato : 05-10-02 19:54 |
|
| |
Jens Axel Søgaard (07-10-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 07-10-02 15:58 |
|
Jens Christian Larsen wrote:
> On Sat, 5 Oct 2002, Jens Axel Søgaard wrote:
>> Jeg havde glemt, spørgsmålet drejede sig om ku en byte.
>
> Min løsning med modulus er vel underordnet om variablen er en byte
> eller flere, big-endian eller ej? Så længe computeren kan hitte ud af
> at tage modulus af to tal, kan man finde LSB på den måde. Hvis
> processoren internt reprsæenter variablene som big-endian skulle det
> da ikke påvirke resultatet af modulus?
Nu kræver det, at man tænker.
Lad os sige, at en byte indeholder 3 bits[1]. Lad os så sige, at
to-byte variablen x indeholder 010 111.
Kigger vi på x med bit-briller, vil man sige, at den højreste bit er 1.
Hvis x repræsenterer et heltal (uden fortegn) så kan x tolkes som
enten 2*8+7=25 eller 7*8+2=58. Kun det ene af disse er er lige.
Om modulo-2 beregner den højreste bit eller ej afhænger altså
af endian-typen (hvad siger man på dansk?).
Tilbage er så at blive enige om, om LSB er et synonym til højreste
(hvilket jeg tænkte, da talen faldt på and og or) eller om LSB
referer til det mindste ciffer, når to-byten fortolkes som
et fortegnsløst heltal (hvilket jeg tænkte på, da talen faldt på
maskinrepræsentation).
Min personlige konklusion er, at jeg ikke tør bruge LSB uden at
gøre det klart, om jeg tænker "højreste" eller "mindste ciffer".
> Med venlig hilsen
> Jens-Christian (der gik til datalogi på gymnasiet med Jens Axel) ;)
Det var godt husket! Lidt fordele ved at have et usædvanligt navn
er der åbenbart
--
Jens Axel Søgaard
[1] Ikke helt urimeligt - da Knuth skrev sine bøger gik der 6 bits på en byte.
| |
Bertel Lund Hansen (07-10-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 07-10-02 17:40 |
|
Jens Axel Søgaard skrev:
>Om modulo-2 beregner den højreste bit eller ej afhænger altså
>af endian-typen (hvad siger man på dansk?).
"Endiantypen" eller "indianertypen" hvis man er i det morsomme
hjørne.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Jens Axel Søgaard (07-10-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 07-10-02 18:26 |
|
Bertel Lund Hansen wrote:
> Jens Axel Søgaard skrev:
>
>> Om modulo-2 beregner den højreste bit eller ej afhænger altså
>> af endian-typen (hvad siger man på dansk?).
>
> "Endiantypen" eller "indianertypen" hvis man er i det morsomme
> hjørne.
Var det ikke noget med, at det stammede fra Gullivers rejser:
big-endian adj. [common; From Swift's "Gulliver's Travels" via the
famous paper "On Holy Wars and a Plea for Peace" by Danny Cohen,
Hvordan er endian oversat i den danske udgave af Gullivers rejser?
Den engelske kan læses her:
http://ibiblio.org/gutenberg/etext97/gltrv10h.htm
It is computed that eleven thousand persons have at several times
suffered death, rather than submit to break their eggs at the smaller end.
Many hundred large volumes have been published upon this controversy:
but the books of the Big-endians have been long forbidden, and the whole
party rendered incapable by law of holding employments.
Nå ja. Det kommer an på i hvilken ende, man slår sit æg itu
--
Jens Axel Søgaard
| |
Bertel Lund Hansen (07-10-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 07-10-02 22:21 |
| | |
Jens Christian Larse~ (05-10-2002)
| Kommentar
Fra : Jens Christian Larse~ |
Dato : 05-10-02 18:38 |
|
| |
Jens Axel Søgaard (05-10-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 05-10-02 18:49 |
|
Jens Christian Larsen wrote:
> Forvirringen er gensidig :)
>
> Jeg tog som udgangspunkt at Lasse gerne ville have LSB for en 8 bit
> variabel.
En uge er lang tid. Jeg havde glemt, det oprindelige spørgsmål
kun drejede sig om en byte.
--
Jens Axel Søgaard
| |
Bertel Lund Hansen (05-10-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 05-10-02 22:05 |
|
Jens Axel Søgaard skrev:
>En uge er lang tid. Jeg havde glemt, det oprindelige spørgsmål
>kun drejede sig om en byte.
Det er ligegyldigt. Indianerformatet er gennemsigtigt for
programmøren så længe der ikke skiftes system.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Byrial Jensen (05-10-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 05-10-02 20:14 |
|
Jens Christian Larsen <madcow@control.auc.dk> skrev:
> Forvirringen er gensidig :)
>
> Jeg tog som udgangspunkt at Lasse gerne ville have LSB for en 8 bit
> variabel. Her er en lille stump kode der forklarer hvad jeg mener.
>
> char t = 100;
> printf("AND %d \n", t&0x01);
> printf("MODULUS %d \n", t%2);
>
> Som jeg ser det, vil begge printf udskrive LSB for t.
Nej, de vil ikke. Igor har fuldstændig ret i sin kritik af dit
forslag.
>(Hvis char er
> negativ ulige vil modulus give -1 i stedet for 1 hvilket man skal tage
> højde for). Er vi enige om det?
Ja, men det siger ikke noget om værdien LSB. Når man vil vide noget
om LSB, kan man ikke bruge modulo-operatoren.
>> Kanskje fordi at like tall ikke innebærer LSB == 0?
>
> Huh? Du mener Least Significant Bit, ik?
> Er det mig, der er helt forkert på den, eller er det ikke indlysende?
Det er dig der er helt forkert på den. Hvis en implementation vælger
at repræsentere negative tal som en-komplement-værdier, vil negative
ulige tal have LSB lig med 0.
> Er vi ikke enige om at LSB er den mindst betydende bit, der skifter mellem
> 1 og 0 fortløbende?
Nej, det er vi ikke enige om.
| |
Jens Christian Larse~ (06-10-2002)
| Kommentar
Fra : Jens Christian Larse~ |
Dato : 06-10-02 16:54 |
|
| |
Igor V. Rafienko (06-10-2002)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 06-10-02 17:43 |
|
[ Jens Christian Larsen ]
[ ... ]
> Kan du komme med et konkret eksempel på hvor (x & 0x01) fungerer og
> hvor (x % 2) fejler med at finde LSB?
Har ikke du allerede fått en forklaring på hvorfor notasjonene ikke er
ekvivalente? Hva skal du med et _eksempel_?
> Du må meget gerne skrive noget C kode. Hvilke systemer kører idag
> med one's compliment? Jeg har desværre ikke adgang til sådan et
> system.
Og hvordan er dette relevant for problemstillingen?
[ ... ]
> Med henhold til hastighed, så er det rigtigt at gode compilere
> optimerer modulus operatoren til shifting i visse tilfælde som Igor
> nævner, men det er ikke noget, der er givet med sikkerhed.
Yeah, right, og 2's complement er liksom gitt med sikkerhet? En
kompilator er _defekt_ dersom den ikke kan foreta elementær "strength
reduction" optimalisering.
> I maskinekode er modulus operatoren "dyr", hvis den ikke er
> optimeret væk, det var det jeg ville pointere. Desuden nævner I (dig
> & Igor) sjældne systemer med one's compliment, så det er vel helt I
> jeres ånd at påpege at modulus operatoren potientielt er meget
> langsommere end AND, da man ikke kan forvente at compileren
> optimerer for sig.
Modulo operatoren og bitwise and gjør to forskjellige ting. Når man
først har innsett det, så faller resten av bitene på plass -- der det
gir mening å bruke &, bruker man det. Der det gir mening å bruke %,
bruker man det. Vil man plukke ut en bit, bruker man &. Trenger man
resten etter divisjon, bruker man %. Det er såpass enkelt.
Når det gjelder hastigheten, er gnålingen om hvor treg % måtte være i
beste tilfellet usaklig:
* Hastigheten skal ikke vike for korrektheten.
* En kompilator _skal_ foreta slike optimaliseringer, der det er
mulig, fx. "% 2" <=> "& 1" på en 2'er komplement maskin.
* Hastigheten er _irrelevant_ inntil profiler sier noe annet.
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
Byrial Jensen (06-10-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 06-10-02 21:03 |
|
Jens Christian Larsen <madcow@control.auc.dk> skrev:
> Kan du komme med et konkret eksempel på hvor (x & 0x01) fungerer og hvor
> (x % 2) fejler med at finde LSB?
Det er tilfældet når x er negativ og repræsenteret som 1-komplement.
> Hvilke systemer kører idag med one's compliment?
Aner det ikke. Det har heller ingen relevans for det principielle i
sagen.
> Lasse skal selvfølgelig vurdere tingene inden han implmenterer en løsning.
> Det kunne evt. være han valgte at bruge udtrykket x - 2*(x/2) i stedet for
> mod og AND. Hvis han har problemer med at forstå AND er det da på sin
> plads at nævne alternative løsninger.
Ja, hvis man også nævner de alternative løsningers begrænsning. I
dette tilfælde at det er en implementationsafhængig, uportabel
løsning.
> Med henhold til hastighed, så er det rigtigt at gode compilere optimerer
> modulus operatoren til shifting i visse tilfælde som Igor nævner, men det
> er ikke noget, der er givet med sikkerhed.
Det er heller ikke givet med sikkerhed at "%" er langsommere end "&".
Så skal man ikke påstå det.
> I maskinekode er modulus
> operatoren "dyr", hvis den ikke er optimeret væk, det var det jeg ville
> pointere. Desuden nævner I (dig & Igor) sjældne systemer med one's
> compliment, så det er vel helt I jeres ånd at påpege at modulus operatoren
> potientielt er meget langsommere end AND, da man ikke kan forvente at
> compileren optimerer for sig.
Det ville jeg nu forvente af en moderne oversætter. Jeg har endnu
ikke mødt en som ikke kunne reducere (x % 2) til noget hvor den ikke
behøver at dividere (men de findes da utvivlsomt).
| |
Igor V. Rafienko (06-10-2002)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 06-10-02 13:34 |
|
[ Jens Christian Larsen ]
[ ... ]
> char t = 100;
> printf("AND %d \n", t&0x01);
> printf("MODULUS %d \n", t%2);
>
> Som jeg ser det, vil begge printf udskrive LSB for t. (Hvis char er
> negativ ulige vil modulus give -1 i stedet for 1 hvilket man skal
> tage højde for). Er vi enige om det?
Nei, vi er ikke det. Før det første, sier C standarden ingenting om
hva verdien av (-5) % 2 skulle være. Det kan være enten 1 eller -1.
Det eneste som kreves er at:
(a/b)*b + a%b == a
En annen ting er at "t & 1" og "t % 2" vil kunne gi forskjellige svar
selv om man bare ser på absoluttverdien (selv om datamaskiner der
dette vil skje er i mindretall i disse dager (meg kjent)).
> > Kanskje fordi at like tall ikke innebærer LSB == 0?
>
> Huh? Du mener Least Significant Bit, ik? Er det mig, der er helt
> forkert på den, eller er det ikke indlysende?
[ ... ]
> Er vi ikke enige om at LSB er den mindst betydende bit, der skifter
> mellem 1 og 0 fortløbende?
Du antar 2's complement notasjon.
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
Byrial Jensen (06-10-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 06-10-02 21:03 |
|
Igor V. Rafienko <igorr@ifi.uio.no> skrev:
> Nei, vi er ikke det. Før det første, sier C standarden ingenting om
> hva verdien av (-5) % 2 skulle være. Det kan være enten 1 eller -1.
> Det eneste som kreves er at:
>
> (a/b)*b + a%b == a
Jo, C99 (ISO/IEC 9899:1999) siger:
6.5.5 Multiplicative operators
[#6] When integers are divided, the result of the / operator
is the algebraic quotient with any fractional part
discarded.87) If the quotient a/b is representable, the
expression (a/b)*b + a%b shall equal a.
____________________
87)This is often called ``truncation toward zero''.
Jeg læser det som at -5 / 2 skal give -2, og følgelig at -5 % 2 skal
give -1, hvilket betyder at den valgfrihed som tidligere standarder
gav på dette punkt, er blevet indskrænket.
| |
Igor V. Rafienko (07-10-2002)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 07-10-02 21:04 |
|
[ Byrial Jensen ]
[ ... ]
> Jo, C99 (ISO/IEC 9899:1999) siger:
>
> 6.5.5 Multiplicative operators
>
> [#6] When integers are divided, the result of the / operator is the
> algebraic quotient with any fractional part discarded.87) If the
> quotient a/b is representable, the expression (a/b)*b + a%b shall
> equal a.
> ____________________
>
> 87)This is often called ``truncation toward zero''.
>
>
> Jeg læser det som at -5 / 2 skal give -2, og følgelig at -5 % 2 skal
> give -1, hvilket betyder at den valgfrihed som tidligere standarder
> gav på dette punkt, er blevet indskrænket.
Hvorfor er ikke -5 % 2 => 1, og -5 / 2 => -3 en mulig tolkning?
Riktignok er ikke dette "truncation toward zero", men det strider ikke
mot
(a/b)*b + a%b == a
.... eller er det noe veldig opplagt jeg ikke ser? Regnestykket holder
såvel for "mine" verdier som for "dine".
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
Byrial Jensen (07-10-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 07-10-02 21:50 |
|
Igor V. Rafienko <igorr@ifi.uio.no> skrev:
> [ Byrial Jensen ]
>
>> Jo, C99 (ISO/IEC 9899:1999) siger:
>>
>> 6.5.5 Multiplicative operators
>>
>> [#6] When integers are divided, the result of the / operator is the
>> algebraic quotient with any fractional part discarded.87) If the
>> quotient a/b is representable, the expression (a/b)*b + a%b shall
>> equal a.
>> ____________________
>>
>> 87)This is often called ``truncation toward zero''.
>>
>>
>> Jeg læser det som at -5 / 2 skal give -2, og følgelig at -5 % 2 skal
>> give -1, hvilket betyder at den valgfrihed som tidligere standarder
>> gav på dette punkt, er blevet indskrænket.
>
>
> Hvorfor er ikke -5 % 2 => 1, og -5 / 2 => -3 en mulig tolkning?
Fordi der står "with any fractional part discarded". -5 delt med 2
giver -2,5, og når man fjerner delen efter kommaet bliver der -2
tilbage.
Afrundingsreglen er ny i C99. Tidligere var frit valg for en
implementation hvilken vej den skulle afrundes i sådanne tilfælde.
| |
Igor V. Rafienko (07-10-2002)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 07-10-02 22:55 |
|
[ Byrial Jensen ]
[ ... ]
> Fordi der står "with any fractional part discarded". -5 delt med 2
> giver -2,5, og når man fjerner delen efter kommaet bliver der -2
> tilbage.
Ah, selvsagt.
Da tok jeg feil, beklager.
> Afrundingsreglen er ny i C99. Tidligere var frit valg for en
> implementation hvilken vej den skulle afrundes i sådanne tilfælde.
Min bekjent stakk dessverre av med C90, så det får jeg ikke sjekket
før i morgen, men en kjapp titt i K&R2 avslører at nettopp noe slikt
sannsynligvis er tilfellet. K&R er veldig påpasselige hva angår
verdien av resultatet med % og / i tilfellet signed aritmetikk blir
brukt.
Takk for rettelsen,
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
Bjarke Dahl Ebert (05-10-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 05-10-02 22:56 |
|
"Igor V. Rafienko" <igorr@ifi.uio.no> wrote in message
news:xjvit0gx5v5.fsf@kollern.ifi.uio.no...
> > Hvis LSB er 1 er tallet ulige, hvis LSB er 0 er tallet lige.
> Ikke alltid.
Kære Igor - kan vi ikke slippe for dette juridiske pedanteri. Det er så
trættende når nyhedsgruppeindlæg skal disekeres for at se om man kan finde
nogle formelt set ugyldige udsagn.
Hvis vi endelig skal være pedantiske - JO, gu' er LSB 1 netop for ulige tal.
LSB er Least Significant Bit. "Bit" er "Binary Digit". Det har slet ikke
noget med maskinrepræsentationer at gøre. Modulus og LSB er begreber der har
det fint uden for datamaskiner. Det binære tal -10101b er ulige, og LSB er
1. Uanset intern maskinrepræsentation. Det kan da godt være at nogle
mærkelige maskiner repræsenterer -10101 som bitmønsteret 11101010, men det
ændrer ikke ved at Least Significant Binary Digit i -10101 er 1.
Cifrene i -123 er "1, 2 og 3", og fortegnet er "-". Der er ingen grund til
at blande eventuelle maskinrepræsentationer ind i billedet her.
Hvis du, Igor, endelig vil blande C-standardens (manglende) meninger om
bitrepræsentationer for signed integers ind i billedet, så er du jo selv ude
om det. Ingen har bedt dig regne med "signed char". Så vidt jeg kan se, har
alle kodeforslag i tråden da også benyttet unsigned.
> Så, har du noen _gode_ grunner for å foretrekker "x & 1" framfor "x %
> 2", specielt med tanke på at "x & 1" ikke virker, og "x % 2" er
> nøyaktig like rask, er korrekt og er uavhengig av den underliggende
> bitrepresentasjonen? Jeg vil gjerne høre begrunnelsen, om du har en.
Hvem har talt om maskinens "underliggende bitrepræsentation"? Den spiller
ingen rolle her, medmindre man er så dum at bruge "&"-operatoren på signed
heltal uden at konvertere til unsigned først.
Iøvrigt prøvede Jens jo ikke at fremhæve den ene operation frem for den
anden, blot at forklare en sammenhæng mellem dem for at give lidt perspektiv
til spørgeren, som da vist nu må være efterladt temmeligt forvirret efter
dine unødvendige sprog-juristerier.
Mvh. Bjarke
| |
Byrial Jensen (06-10-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 06-10-02 05:00 |
|
Bjarke Dahl Ebert <bebert@worldonline.dk> skrev:
> "Igor V. Rafienko" <igorr@ifi.uio.no> wrote in message
>
>> > Hvis LSB er 1 er tallet ulige, hvis LSB er 0 er tallet lige.
>> Ikke alltid.
>
> Kære Igor - kan vi ikke slippe for dette juridiske pedanteri.
Nej, tak. Jeg vil ikke slippe for det. Jeg vil faktisk mene at
pedanteri er på plads og velkomment i en programmeringsgruppe.
Datamaskiner og oversættere er pedantiske, og hvis et program ikke
er korrekt, så er det ikke korrekt. Der er ikke noget der hedder
"næsten korrekt" i den verden.
Og kære Bjarke - kan du ikke lade være med at udtale dig på vegne
af andre af gruppens læsere end dig selv?
> Det er så
> trættende når nyhedsgruppeindlæg skal disekeres for at se om man kan finde
> nogle formelt set ugyldige udsagn.
Hvis gruppen er for trættende for dig, så lad være med at læse med.
> Hvis vi endelig skal være pedantiske - JO, gu' er LSB 1 netop for ulige tal.
> LSB er Least Significant Bit. "Bit" er "Binary Digit". Det har slet ikke
> noget med maskinrepræsentationer at gøre. Modulus og LSB er begreber der har
> det fint uden for datamaskiner. Det binære tal -10101b er ulige, og LSB er
> 1. Uanset intern maskinrepræsentation.
Nej. LSB er et begreb som knytter sig til intern
maskinrepræsentation.
Og i øvrigt med din fortolkning af LSB er de svar her i gruppen
(inkl. dine) som bruger binære operatorer (| og &) forkerte - eller
det mindste svært mangelfulde fordi de ikke tog forbehold for
negative tal. Hvorfor protesterede du ikke mod disse tilsyneladende
efter din opfattelse forkerte svar?
> Det kan da godt være at nogle
> mærkelige maskiner repræsenterer -10101 som bitmønsteret 11101010, men det
> ændrer ikke ved at Least Significant Binary Digit i -10101 er 1.
> Cifrene i -123 er "1, 2 og 3", og fortegnet er "-". Der er ingen grund til
> at blande eventuelle maskinrepræsentationer ind i billedet her.
>
> Hvis du, Igor, endelig vil blande C-standardens (manglende) meninger om
> bitrepræsentationer for signed integers ind i billedet, så er du jo selv ude
> om det. Ingen har bedt dig regne med "signed char". Så vidt jeg kan se, har
> alle kodeforslag i tråden da også benyttet unsigned.
Nej, De fleste svar virkede med både signed og unsigned typer, og
Jens-Christian brugte "char" i sit forkerte kode-eksempel.
>> Så, har du noen _gode_ grunner for å foretrekker "x & 1" framfor "x %
>> 2", specielt med tanke på at "x & 1" ikke virker, og "x % 2" er
>> nøyaktig like rask, er korrekt og er uavhengig av den underliggende
>> bitrepresentasjonen? Jeg vil gjerne høre begrunnelsen, om du har en.
>
> Hvem har talt om maskinens "underliggende bitrepræsentation"? Den spiller
> ingen rolle her, medmindre man er så dum at bruge "&"-operatoren på signed
> heltal uden at konvertere til unsigned først.
> Iøvrigt prøvede Jens jo ikke at fremhæve den ene operation frem for den
> anden, blot at forklare en sammenhæng mellem dem for at give lidt perspektiv
> til spørgeren, som da vist nu må være efterladt temmeligt forvirret efter
> dine unødvendige sprog-juristerier.
Hvis han er forvirret, må det være på grund af fejlagtige svar som
Jens-Christians. Det blev hævdet at det er langsommere at udregne (t
% 2) end (t & 0x01), men at de giver samme resultat når t har type
char. Begge dele er forkert.
| |
Bjarke Dahl Ebert (06-10-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 06-10-02 10:37 |
|
"Byrial Jensen" <bjensen@nospam.dk> wrote in message
news:slrnapvd72.9f8.bjensen@ask.ask...
> Datamaskiner og oversættere er pedantiske, og hvis et program ikke
> er korrekt, så er det ikke korrekt. Der er ikke noget der hedder
> "næsten korrekt" i den verden.
Nu var Jens Christians indlæg ikke et program, men en venlig (og iøvrigt
korrekt) forklaring i et sprog med vag semantik, nemlig dansk.
> Nej. LSB er et begreb som knytter sig til intern
> maskinrepræsentation.
Det oprindelige spørgsmål var ellers
"Jeg kunne godt tænke mig at aflæse LSB (første bit) af en 8bit variabel
feks. 0b0000000x"
En 8-bit variabel er netop en variabel indeholdende 8 bits. Hvordan en
given maskine eventuelt vælger at repræsentere *negative* tal ved hjælp af
en flok bits er fuldkommen uinteressant her. Vi har bits til at starte
med, ikke en "signed char". Vil man opfatte '10101010b' som et tal, er det
naturligvis en unsigned char.
> Og i øvrigt med din fortolkning af LSB er de svar her i gruppen
> (inkl. dine) som bruger binære operatorer (| og &) forkerte - eller
> det mindste svært mangelfulde fordi de ikke tog forbehold for
> negative tal.
> Hvorfor protesterede du ikke mod disse tilsyneladende
> efter din opfattelse forkerte svar?
Forkerte? Sikke noget vrøvl. Så længe man regner med unsigned (som man
naturligvis gør, for at '&' og '|' giver mening) så er der slet ikke noget
problem.
> Nej, De fleste svar virkede med både signed og unsigned typer, og
> Jens-Christian brugte "char" i sit forkerte kode-eksempel.
Hvis du lægger mærke til det, så står der "char t = 100". Så vidt jeg husker
er 100 et positivt tal .
Selvfølgelig var "char" en svipser, men Igor begyndte pedanteriet inden da.
> Hvis han er forvirret, må det være på grund af fejlagtige svar som
> Jens-Christians. Det blev hævdet at det er langsommere at udregne (t
> % 2) end (t & 0x01), men at de giver samme resultat når t har type
> char. Begge dele er forkert.
Okay, lige det med langsommere - det afhænger selvfølgelig af compileren.
Påstanden var "For at checke om tallet er ulige, kan du evt. bruge modulus
operatoren". Og det er jo fuldstændigt korrekt - det er ligefrem
definitionen på ulige.
Mvh. Bjarke
| |
Byrial Jensen (06-10-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 06-10-02 21:03 |
|
Bjarke Dahl Ebert <bebert@worldonline.dk> skrev:
> "Byrial Jensen" <bjensen@nospam.dk> wrote in message
> Det oprindelige spørgsmål var ellers
> "Jeg kunne godt tænke mig at aflæse LSB (første bit) af en 8bit variabel
> feks. 0b0000000x"
> En 8-bit variabel er netop en variabel indeholdende 8 bits. Hvordan en
> given maskine eventuelt vælger at repræsentere *negative* tal ved hjælp af
> en flok bits er fuldkommen uinteressant her. Vi har bits til at starte
> med, ikke en "signed char". Vil man opfatte '10101010b' som et tal, er det
> naturligvis en unsigned char.
Hvorfor det? Der er slet ikke noget som hedder 10101010b i C, men
heltalskonstanter uden et efterfølgende suffiks (u, U, l, L, ll
eller LL) bliver ellers altid opfattet som en signed værdi af type
int når værdien kan repræsenteres i en int.
>> Og i øvrigt med din fortolkning af LSB er de svar her i gruppen
>> (inkl. dine) som bruger binære operatorer (| og &) forkerte - eller
>> det mindste svært mangelfulde fordi de ikke tog forbehold for
>> negative tal.
>> Hvorfor protesterede du ikke mod disse tilsyneladende
>> efter din opfattelse forkerte svar?
>
> Forkerte? Sikke noget vrøvl. Så længe man regner med unsigned (som man
> naturligvis gør, for at '&' og '|' giver mening) så er der slet ikke noget
> problem.
& og | er definerede for og giver mening med signed typer.
> Okay, lige det med langsommere - det afhænger selvfølgelig af compileren.
> Påstanden var "For at checke om tallet er ulige, kan du evt. bruge modulus
> operatoren". Og det er jo fuldstændigt korrekt - det er ligefrem
> definitionen på ulige.
Ja, men spørgsmålet gik ikke på lige eller ulige. Det gik på LSB
som er noget andet.
| |
Igor V. Rafienko (06-10-2002)
| Kommentar
Fra : Igor V. Rafienko |
Dato : 06-10-02 13:53 |
|
[ Bjarke Dahl Ebert ]
[ ... ]
> Hvis vi endelig skal være pedantiske - JO, gu' er LSB 1 netop for
> ulige tal.
I en maskin som bruker 2's complement -- definitivt. Du finner kanskje
et sted i standarden som _krever_ at all heltallsaritmetikk skal
foregå i 2's complement notasjon?
Det opprinnelige spørsmålet hadde _ingenting_ med tallrepresentasjon å
gjøre, og nettopp derfor er det unødvendig å gå fra bitutplukking til
modulus operasjonen. Ikke bare er det unødvendig, men det er også lett
å bli lurt av "vanlige" premisser, hvilket er nettopp det som har
skjedd.
> Det binære tal -10101b er ulige, og LSB er 1. Uanset intern
> maskinrepræsentation.
Som sagt, nei, det er ikke tilfellet.
> Hvis du, Igor, endelig vil blande C-standardens (manglende) meninger
> om bitrepræsentationer for signed integers ind i billedet, så er du
> jo selv ude om det.
_Jeg_ vil ikke det. Men "viten om at like tall har LSB lik 0" er
_nettopp_ det å blande inn bitrepresentasjonen av underliggende tall.
_Det_ er unødvendig, da & vil gi det riktige svaret uten å bry seg om
hvordan _tall_ måtte bli representert.
[ ... ]
> Hvem har talt om maskinens "underliggende bitrepræsentation"?
Jens Christian Larsen har gjort det.
> Den spiller ingen rolle her, medmindre man er så dum at bruge
> "&"-operatoren på signed heltal uden at konvertere til unsigned
> først.
Det er nok lurt. Bitfikling er generelt lurest med unsigned typer.
Men, siden
abs( a % 2 ) != abs( a ) % 2
hvorfor skulle man bruke % for å finne ut verdien av LSB i det hele
tatt? Vel å merke, ulikheten over er holder på et mindretall av
eksisterende maskiner i dag, men det å ikke ta hensyn til slike ting
vil medføre utelukkende flere problemer.
> Iøvrigt prøvede Jens jo ikke at fremhæve den ene operation frem for
> den anden, blot at forklare en sammenhæng mellem dem for at give
> lidt perspektiv til spørgeren, som da vist nu må være efterladt
> temmeligt forvirret efter dine unødvendige sprog-juristerier.
Han glemte å gjøre eksplisitt en meget viktig forutsetning (2's
complement representasjon). Han påstod også at "% 2" vil være tregere
enn "& 1". Det er ikke tilfellet.
ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
-- pederst på irc
| |
Byrial Jensen (06-10-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 06-10-02 21:03 |
|
Igor V. Rafienko <igorr@ifi.uio.no> skrev:
> Det er nok lurt. Bitfikling er generelt lurest med unsigned typer.
> Men, siden
>
> abs( a % 2 ) != abs( a ) % 2
>
> hvorfor skulle man bruke % for å finne ut verdien av LSB i det hele
> tatt? Vel å merke, ulikheten over er holder på et mindretall av
> eksisterende maskiner i dag, men det å ikke ta hensyn til slike ting
> vil medføre utelukkende flere problemer.
Det er ikke korrekt. De to regneudtryk vil altid have samme værdi
(0 eller 1) hvis man fraregner de tilfælde hvor udregning af
højresiden vil give udefineret adfærd. Det er når a er signed og
indeholder det mest negative tal af sin type, og tallet
repræsenteres som et 2-komplement tal.
| |
Anders J. Munch (07-10-2002)
| Kommentar
Fra : Anders J. Munch |
Dato : 07-10-02 14:00 |
|
"Igor V. Rafienko" <igorr@ifi.uio.no> skrev blandt andet:
> Han glemte å gjøre eksplisitt en meget viktig forutsetning (2's
> complement representasjon). Han påstod også at "% 2" vil være tregere
> enn "& 1". Det er ikke tilfellet.
Som påpeget andetsteds i tråden, så har "x % 2" og "x & 1" forskellig
semantik hvis x er signed. Implementationen er derfor, i hvert fald på
2-komplement platforme hvor heltalsdivision runder mod 0, også
forskellig.
"% 2" _er_ faktisk langsommere end "& 1".
mvh. Anders
| |
Martin Moller Peders~ (07-10-2002)
| Kommentar
Fra : Martin Moller Peders~ |
Dato : 07-10-02 15:08 |
|
In <3da185b1$0$91367$edfadb0f@dspool01.news.tele.dk> "Anders J. Munch" <andersjm@dancontrol.dk> writes:
>"Igor V. Rafienko" <igorr@ifi.uio.no> skrev blandt andet:
>> Han glemte å gjøre eksplisitt en meget viktig forutsetning (2's
>> complement representasjon). Han påstod også at "% 2" vil være tregere
>> enn "& 1". Det er ikke tilfellet.
>Som påpeget andetsteds i tråden, så har "x % 2" og "x & 1" forskellig
>semantik hvis x er signed. Implementationen er derfor, i hvert fald på
>2-komplement platforme hvor heltalsdivision runder mod 0, også
>forskellig.
>"% 2" _er_ faktisk langsommere end "& 1".
#include <stdio.h>
int main() {
unsigned int i;
scanf("%i",&i);
printf("%d",i&1);
return 0;
}
og
#include <stdio.h>
int main() {
unsigned int i;
scanf("%i",&i);
printf("%d",i%2);
return 0;
}
giver praecis denne samme kode, hvis det blivet kompileret med gcc
med option -O3 nemlig:
.file "modules.c"
.section .rodata.str1.1,"aMS",@progbits,1
..LC0:
.string "%i"
..LC1:
.string "%d"
.text
.align 4
..globl main
.type main,@function
main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
subl $8, %esp
leal -4(%ebp), %edx
pushl %edx
pushl $.LC0
call scanf
popl %eax
movl -4(%ebp), %eax
popl %edx
andl $1, %eax
pushl %eax
pushl $.LC1
call printf
addl $16, %esp
xorl %eax, %eax
leave
ret
..Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 3.0.4 (Red Hat Linux 7.2 3.0.4-1)"
| |
Anders J. Munch (07-10-2002)
| Kommentar
Fra : Anders J. Munch |
Dato : 07-10-02 15:47 |
|
"Martin Moller Pedersen" <tusk@daimi.au.dk> wrote:
> In <3da185b1$0$91367$edfadb0f@dspool01.news.tele.dk> "Anders J. Munch"
<andersjm@dancontrol.dk> writes:
>
> >"Igor V. Rafienko" <igorr@ifi.uio.no> skrev blandt andet:
> >> Han glemte å gjøre eksplisitt en meget viktig forutsetning (2's
> >> complement representasjon). Han påstod også at "% 2" vil være tregere
> >> enn "& 1". Det er ikke tilfellet.
>
> >Som påpeget andetsteds i tråden, så har "x % 2" og "x & 1" forskellig
> >semantik hvis x er signed. Implementationen er derfor, i hvert fald på
> >2-komplement platforme hvor heltalsdivision runder mod 0, også
> >forskellig.
>
> >"% 2" _er_ faktisk langsommere end "& 1".
>
> #include <stdio.h>
>
> int main() {
> unsigned int i;
>
> scanf("%i",&i);
> printf("%d",i&1);
> return 0;
> }
>
> og
[snip]
> giver praecis denne samme kode [...]
Vi taler om signed int, prøv med det.
Pas i øvrigt på med scanf formatstrengen: til en unsigned int skal
bruges %u.
mvh. Anders
| |
Kim Hansen (07-10-2002)
| Kommentar
Fra : Kim Hansen |
Dato : 07-10-02 16:27 |
|
"Anders J. Munch" <andersjm@dancontrol.dk> writes:
> [snip]
> > giver praecis denne samme kode [...]
>
> Vi taler om signed int, prøv med det.
and.c:
-------------------------------------------------------
signed int and(signed int c) {
return c & 1;
}
-------------------------------------------------------
mod.c:
-------------------------------------------------------
signed int mod(signed int c) {
return c % 2;
}
-------------------------------------------------------
Jeg oversætter det med gcc-3.0 (resultatet var det samme med gcc-2.95,
men gcc-3.0 formaterer assemblerkoden pænere). Jeg brugte -O1, da
resultatet var det samme for -O1, ..., -O6.
Her er resultatet med * foran de linjer der er forskellige.
and.s:
-------------------------------------------------------
.file "and.c"
.text
.align 4
..globl and
.type and,@function
and:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
* andl $1, %eax
popl %ebp
ret
..Lfe1:
.size and,.Lfe1-and
.ident "GCC: (GNU) 3.0.4"
-------------------------------------------------------
mod.s:
-------------------------------------------------------
.file "mod.c"
.text
.align 4
..globl mod
.type mod,@function
mod:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
* movl %eax, %edx
* shrl $31, %edx
* leal (%edx,%eax), %edx
* andl $-2, %edx
* subl %edx, %eax
popl %ebp
ret
..Lfe1:
.size mod,.Lfe1-mod
.ident "GCC: (GNU) 3.0.4"
-------------------------------------------------------
Er der nogen der kan forklare hvad der sker i mod.s og om det betyder
at gcc ikke er så smart som den kunne være?
--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.
| |
Anders J. Munch (08-10-2002)
| Kommentar
Fra : Anders J. Munch |
Dato : 08-10-02 08:25 |
|
"Kim Hansen" <k-tahf.qvxh@oek.dk> wrote:
>
> Er der nogen der kan forklare hvad der sker i mod.s og om det betyder
> at gcc ikke er så smart som den kunne være?
Pointen er at en simpel 'and' virker for positive tal men ikke for
negative tal. Koden bliver omstændelig fordi gcc vil undgå en branch,
som er dyrt på moderne pipelinede cpu'er. Det er faktisk ikke så dumt.
- Anders
| |
Morten Boysen (06-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 06-10-02 14:44 |
|
"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote in message
news:XlJn9.74926$Qk5.3240652@news010.worldonline.dk...
> Hvis vi endelig skal være pedantiske - JO, gu' er LSB 1 netop for
ulige tal.
> LSB er Least Significant Bit. "Bit" er "Binary Digit". Det har slet
ikke
> noget med maskinrepræsentationer at gøre. Modulus og LSB er begreber
der har
> det fint uden for datamaskiner. Det binære tal -10101b er ulige, og
LSB er
> 1. Uanset intern maskinrepræsentation. Det kan da godt være at nogle
> mærkelige maskiner repræsenterer -10101 som bitmønsteret 11101010,
men det
> ændrer ikke ved at Least Significant Binary Digit i -10101 er 1.
> Cifrene i -123 er "1, 2 og 3", og fortegnet er "-". Der er ingen
grund til
> at blande eventuelle maskinrepræsentationer ind i billedet her.
Hvad hvis vi snakker om fixed-point kommatal? Så har LSB ikke noget at
gøre med, om tallet er ulige eller ej.
--
Morten Boysen
| |
Bertel Lund Hansen (06-10-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 06-10-02 15:18 |
|
Morten Boysen skrev:
>Hvad hvis vi snakker om fixed-point kommatal? Så har LSB ikke noget at
>gøre med, om tallet er ulige eller ej.
Det er da korrekt, men så er den også mere eller mindre
tilfældig.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Morten Boysen (07-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 07-10-02 15:43 |
|
"Bertel Lund Hansen" <nospam@lundhansen.dk> wrote in message
news:ngh0qugkooaalnj9l0hkpretgtag19k4eo@news.telia.dk...
> >Hvad hvis vi snakker om fixed-point kommatal? Så har LSB ikke noget
at
> >gøre med, om tallet er ulige eller ej.
>
> Det er da korrekt, men så er den også mere eller mindre
> tilfældig.
Hvorfor i alverden skulle LSB være mere tilfældig ved fixed-point
kommatal end ved enhver anden talmæssig tolkning af et binært mønster?
--
Morten Boysen
| |
Bjarke Dahl Ebert (07-10-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 07-10-02 16:43 |
|
"Morten Boysen" <morten.boysen@aub.dk> wrote in message
news:ans6fp$mi8$1@sunsite.dk...
> > >Hvad hvis vi snakker om fixed-point kommatal? Så har LSB ikke noget
> at
> > >gøre med, om tallet er ulige eller ej.
> > Det er da korrekt, men så er den også mere eller mindre
> > tilfældig.
> Hvorfor i alverden skulle LSB være mere tilfældig ved fixed-point
> kommatal end ved enhver anden talmæssig tolkning af et binært mønster?
Det er fuldkommen ligegyldigt med fixed-point kommatal.
"&"-operatoren i C giver kun mening for integral-typer, dvs. typer hvor
bitmønsteret opfattes som heltal.
At C så har defineret "&" for signed int til at være bitvis AND af den
*interne* repræsentation, kan man jo så undres over ;)
Situationen for unsigned int er bedre, idet standarden bestemmer hvordan
bitrepræsentationen (i hvert fald den der er synlig udefra) skal være.
Mvh. Bjarke
| |
Morten Boysen (07-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 07-10-02 21:48 |
|
"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote in message
news:%Yho9.82048$Qk5.3586629@news010.worldonline.dk...
> Det er fuldkommen ligegyldigt med fixed-point kommatal.
> "&"-operatoren i C giver kun mening for integral-typer, dvs. typer
hvor
> bitmønsteret opfattes som heltal.
Nu er heltal en form for fixed-point kommatal, og & giver fint mening
for denne type talrepræsentationer.
Pointen er sådan set bare, at den oprindelige spørger havde et problem
med et bitmønster, hvor han ville hive den ene bit ud. Dette er
grundlæggende et bitmøssigt problem, som har en simpel binær løsning.
Ved at forelså brug af modulus, lægges der endnu et abstraktionslag
ovenpå. Det er vel og mærke et abstraktionslag, som er unødvendigt, og
som ydermere bygger på antagelser, der ikke altid er korrekte.
--
Morten Boysen
| |
Bertel Lund Hansen (07-10-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 07-10-02 17:42 |
|
Morten Boysen skrev:
>Hvorfor i alverden skulle LSB være mere tilfældig ved fixed-point
>kommatal end ved enhver anden talmæssig tolkning af et binært mønster?
Der er afrundingsfejl ved alle kommatalstyper.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Morten Boysen (07-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 07-10-02 21:33 |
|
"Bertel Lund Hansen" <nospam@lundhansen.dk> wrote in message
news:9ae3qucio8v825lulmp7c3ur8hf0g7d2c6@news.telia.dk...
> >Hvorfor i alverden skulle LSB være mere tilfældig ved fixed-point
> >kommatal end ved enhver anden talmæssig tolkning af et binært
mønster?
>
> Der er afrundingsfejl ved alle kommatalstyper.
Afrundingsfejlen ved fixed-point kommatal er præcis den samme som ved
heltals typer. Faktisk er fortolkningen af fixed-point kommatal meget
lig med heltalstyper. Fixed-point kommatyprer er karakteriseret ved,
at man indsætter et komma på en fast plads i bitrækken. På den måde er
heltalstyper bare en form for fixed-point kommatypre, hvor kommaet
står til højre for LSB.
--
Morten Boysen
| |
Jens Christian Larse~ (07-10-2002)
| Kommentar
Fra : Jens Christian Larse~ |
Dato : 07-10-02 22:12 |
|
| |
Morten Boysen (07-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 07-10-02 22:48 |
|
"Jens Christian Larsen" <madcow@control.auc.dk> wrote in message
news:Pine.GSO.4.10.10210072304140.11809-100000@sigurd.control.auc.dk..
..
> > at man indsætter et komma på en fast plads i bitrækken. På den
måde er
> > heltalstyper bare en form for fixed-point kommatypre, hvor kommaet
> > står til højre for LSB.
>
> ..eller til venstre for LSB alt efter arkitekturen. Det er meget
vigtigt
> at huske.
Hvis vi lige ser bort fra big-endian og little-endian problemet, så
skriver vi trods alt for højre mod venstre i denne del af verdenen.
Det gælder også for tal, så ligesesom 2 er det mindst betydende ciffer
i tallet 102, så vil 1 også være det i 0b001. Problemet med
arkitekturer er egentlig irrelevant her.
--
Morten Boysen
| |
Bjarke Dahl Ebert (07-10-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 07-10-02 22:35 |
|
["Bertel Lund Hansen"]
> > Der er afrundingsfejl ved alle kommatalstyper.
["Morten Boysen"]
> Afrundingsfejlen ved fixed-point kommatal er præcis den samme som ved
> heltals typer.
Eh... Hvad giver 1,1 * 1,1?
Regn gerne binært for den sags skyld.
Mvh. Bjarke
| |
Morten Boysen (07-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 07-10-02 22:51 |
|
"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote in message
news:z6no9.82356$Qk5.3658347@news010.worldonline.dk...
> > Afrundingsfejlen ved fixed-point kommatal er præcis den samme som
ved
> > heltals typer.
>
> Eh... Hvad giver 1,1 * 1,1?
> Regn gerne binært for den sags skyld.
Hvad giver resultatet med heltal? Regn gerne binært for den sags
skyld.
P.S. Jeg har på fornemmelsen, at du godt ved, hvad jeg mener. Ret mig
gerne, hvis jeg tager fejl.
--
Morten Boysen
| |
Bjarke Dahl Ebert (07-10-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 07-10-02 23:03 |
|
"Morten Boysen" <morten.boysen@aub.dk> wrote in message
news:ansviq$er3$1@sunsite.dk...
> "Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote in message
> > Eh... Hvad giver 1,1 * 1,1?
> > Regn gerne binært for den sags skyld.
> Hvad giver resultatet med heltal? Regn gerne binært for den sags
> skyld.
Jeg antager at du med *fixed* point mener at vi på forhånd vælger et antal
decimaler efter kommaet. Ellers er det jo ikke fixed men floating point.
Lad os bare regne i titalssystemet - problemet bliver det samme i
totalssystemet:
Med fixed point:
1,1*1,1 = 1,21 - afrundes til 1,2
Med heltal:
11 * 11 = 121
(eller 1*1 = 1, alt efter hvordan du vil udregne det "tilsvarende" med
heltal)
Pointen er at når man regner med fixed point, opstår der situationer hvor
man må runde af. Med heltal er resultatet eksakt (i hvert fald indtil vi får
overflow :).
Mvh. Bjarke
| |
Morten Boysen (08-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 08-10-02 15:42 |
|
"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote in message
news:yxno9.82378$Qk5.3662943@news010.worldonline.dk...
> Pointen er at når man regner med fixed point, opstår der situationer
hvor
> man må runde af. Med heltal er resultatet eksakt (i hvert fald
indtil vi får
> overflow :).
Den eneste grund til, at du kan vise en forskel, er at du med 11
vælger et tal, som kan repræsenteres eksakt med en heltals type. Da
1,1 ikke kan dannes ved at dividere et heltal med en potens af 2, så
kan 1,1 ikke repræsenteres eksakt i fixed-point kommatal. Vælger du
derimod to kommatal, som kan repræsenteres eksakt i fixed-point, så er
der ingen problemer. Hardwaren til multiplikation af fixed-point og
heltal er alligevel fuldstændigt identisk.
--
Morten Boysen
| |
Bertel Lund Hansen (08-10-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 08-10-02 17:28 |
|
Morten Boysen skrev:
>Den eneste grund til, at du kan vise en forskel, er at du med 11
>vælger et tal, som kan repræsenteres eksakt med en heltals type. Da
>1,1 ikke kan dannes ved at dividere et heltal med en potens af 2, så
>kan 1,1 ikke repræsenteres eksakt i fixed-point kommatal. Vælger du
>derimod to kommatal, som kan repræsenteres eksakt i fixed-point, så er
>der ingen problemer.
Hvad så med 25,6 * 25,6?
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Morten Boysen (08-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 08-10-02 20:25 |
|
"Bertel Lund Hansen" <nospam@lundhansen.dk> wrote in message
news:ip16qu8h9p8lc9hvgr6a94b4o78k5l290d@news.telia.dk...
> Hvad så med 25,6 * 25,6?
Kan 25,6 dannes ved at dividere et heltal med en 2^n, hvor n også er
et heltal?
--
Morten Boysen
| |
Bertel Lund Hansen (08-10-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 08-10-02 23:12 |
|
Morten Boysen skrev:
>Kan 25,6 dannes ved at dividere et heltal med en 2^n, hvor n også er
>et heltal?
Jeg påpegede at kommatal giver afrundingsfejl. Dermed har jeg
ikke benægtet at en vilkårlig slags kommatal kan puttes i en
kravlegård og opføre sig pænt.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Bjarke Dahl Ebert (08-10-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 08-10-02 20:31 |
|
> "Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote in message
> news:yxno9.82378$Qk5.3662943@news010.worldonline.dk...
> > Pointen er at når man regner med fixed point, opstår der situationer
> hvor
> > man må runde af. Med heltal er resultatet eksakt (i hvert fald
> indtil vi får
> > overflow :).
"Morten Boysen" <morten.boysen@aub.dk> wrote in message
news:anuqro$ja6$1@sunsite.dk...
> Den eneste grund til, at du kan vise en forskel, er at du med 11
> vælger et tal, som kan repræsenteres eksakt med en heltals type. Da
> 1,1 ikke kan dannes ved at dividere et heltal med en potens af 2, så
Jeg valgte at regne decimalt, og 1,1 kan udtrykkes eksakt med et (decimalt)
ciffer efter kommaet. Når man udregner A*B hver med n decimaler (i 2- eller
10-talssystemet, det er ligegyldigt) efter kommaet, skal man bruge 2*n
decimaler i det generelle tilfælde for at repræsentere resultatet eksakt.
Der gælder n>=2n kun hvis n er 0, dvs. vi regner med heltal.
Lad os gentage udregningen binært - dvs. tallene er "halvanden" - 1,1
binært, eller 1,5 decimalt.
Binært (i titalssystemet)
1,1 * 1,1 (1,5 * 1,5)
= 10,01 (2,25)
Eksemplet viser den generelle situation: Man skal bruge dobbelt så mange
cifre efter kommaet.
> kan 1,1 ikke repræsenteres eksakt i fixed-point kommatal. Vælger du
> derimod to kommatal, som kan repræsenteres eksakt i fixed-point, så er
> der ingen problemer.
1,1 kan netop repræsenteres eksakt som fixed-point decimaltal (det er jo det
der står: 1,1 er repræsentation for 1,1). Der er samme problem uanset om
"maskineriet" regner binært eller decimalt (fx v.hj.a. BCD).
> Hardwaren til multiplikation af fixed-point og
> heltal er alligevel fuldstændigt identisk.
Ja, men kommaet skal flyttes. Så man skal bruge floating-point og/eller
afrunding.
Mvh. Bjarke
| |
Morten Boysen (08-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 08-10-02 21:51 |
|
"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote in message
news:ioGo9.84621$Qk5.3803438@news010.worldonline.dk...
> Eksemplet viser den generelle situation: Man skal bruge dobbelt så
mange
> cifre efter kommaet.
Ja, og før kommaet. Ligeså med normale heltal. Der skal også bruges
summen af bits i de to operander ved multiplikation, for at sikre at
resultatet kan lagres uden afrunding. Hvad vil du egentlig sige med
dit eksempel? De problemer du viser er skam også tilstede ved heltal,
simpelthen fordi heltal fundamentalt er en speciel udgave af
fixed-point kommatal.
> 1,1 kan netop repræsenteres eksakt som fixed-point decimaltal (det
er jo det
> der står: 1,1 er repræsentation for 1,1). Der er samme problem
uanset om
> "maskineriet" regner binært eller decimalt (fx v.hj.a. BCD).
Jeg havde ikke gennemskuet, at du skrev i det bninære talsystem. Det
lignede umiskendeligt et tal i titalssystemmet.
> Ja, men kommaet skal flyttes. Så man skal bruge floating-point
og/eller
> afrunding.
Eller også skal man bruge en store bitbredde til resultatet.
--
Morten Boysen
| |
Bjarke Dahl Ebert (08-10-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 08-10-02 22:31 |
|
"Morten Boysen" <morten.boysen@aub.dk> wrote in message
news:anvgdq$ijb$1@sunsite.dk...
> [Bjarke:]
> > Ja, men kommaet skal flyttes. Så man skal bruge floating-point
> og/eller
> > afrunding.
> Eller også skal man bruge en store bitbredde til resultatet.
Dette er lige præcis min pointe!
Hvis du kan bestemme antallet af decimaler efter kommaet efter
forgodtbefindende, er der tale om floating-point.
Heltal (og også heltal modulo 2^32) er en ring under sædvanling + og *.
Det er fixed-point ikke, uanset hvad du vælger antal decimaler til (>=1).
(En ring er kort sagt en mængde med + og * der overholder de sædvanlige
regneregler for disse, og hvor det er underforstået at to tal i ringen lagt
sammen eller ganget sammen igen ligger i ringen).
Penslet helt ud:
1) Tag to heltal. Gang dem sammen. Resultatet er eksakt. (Jeg ser bort fra
overflow, som ikke har noget med afrunding at gøre).
2) Vælg nu i stedet et antal (gerne binære) decimaler, n. Tag to næsten
vilkårlige fixed-point tal med dette antal decimaler. Gang dem sammen (inden
for den valgte fixed-point-mængde). Resultatet vil generelt være afrundet
(der er selvfølgelig specielle undtagelser, som fx hvis du vælger ene 0'er
efter kommaet).
Det er såmen hele humlen i den historie.
Eller for at quote fra starten af hele denne tråd:
--------
Morten Boysen skrev:
>Hvorfor i alverden skulle LSB være mere tilfældig ved fixed-point
>kommatal end ved enhver anden talmæssig tolkning af et binært mønster?
Der er afrundingsfejl ved alle kommatalstyper.
--
Bertel
--------
Og det er jo så sandt.
Okay, okay, man kan vel tage et eller andet "Arbitrary precision numeric
library", og så kører det bare derudad med flere og flere decimaler . Men
det er bestemt ikke fixed-point.
Bjarke
| |
Morten Boysen (09-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 09-10-02 15:39 |
|
"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote in message
news:D8Io9.84705$Qk5.3830774@news010.worldonline.dk...
> Heltal (og også heltal modulo 2^32) er en ring under sædvanling + og
*.
> Det er fixed-point ikke, uanset hvad du vælger antal decimaler til
(>=1).
>
> (En ring er kort sagt en mængde med + og * der overholder de
sædvanlige
> regneregler for disse, og hvor det er underforstået at to tal i
ringen lagt
> sammen eller ganget sammen igen ligger i ringen).
Kan to (2^16 - 1) * (2^16 -1) repræsenteres i en 16 bit integer? Nej,
vel.
> Penslet helt ud:
> 1) Tag to heltal. Gang dem sammen. Resultatet er eksakt. (Jeg ser
bort fra
> overflow, som ikke har noget med afrunding at gøre).
Overflow ved heltal og afunding ved fixed-point er to sider af samme
sag. Årsagen til de to problemer er den samme. Nemlig at
multiplikation af to fixed-point tal med bitbredden m og n, vil kunne
genere et resultat, som kræver m + n bit for at kunne repræsenteres.
> >Hvorfor i alverden skulle LSB være mere tilfældig ved fixed-point
> >kommatal end ved enhver anden talmæssig tolkning af et binært
mønster?
>
> Der er afrundingsfejl ved alle kommatalstyper.
>
> Og det er jo så sandt.
> Okay, okay, man kan vel tage et eller andet "Arbitrary precision
numeric
> library", og så kører det bare derudad med flere og flere decimaler
. Men
> det er bestemt ikke fixed-point.
Nej, det er netop ikke sandt. Hvad, hvis værdien stammer fra en DAC?
Vil LSB så være mere tilfældig, bare fordi vi vælger at opfatte
bitmønsteret som fixed-point istedet for heltal? Selvfølgelig vil den
ikke det.
Det er det, der er hele min pointe. Der er ingen af os, der kender
kilden til bitmønsteret hos den opindelige spørger. Derfor er det også
dumt at begynde at lave antagelser om, hvilke interne repræsentationer
hans CPU bruger. Han kunne f.eks. sidder og programmer en DSP eller
lignende.
Netop fordi vi ikke aner, hvilke forhold der gør sig gældende, er det
uklogt at bruge en aritmetisk løsning til et rent bitmæssigt problem.
Vil man regne, så kan man bruge regnefunktioner. Vil man bitkneppe, så
bø man bruge AND, OR osv.
--
Morten Boysen
| |
Jens Axel Søgaard (09-10-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 09-10-02 17:03 |
|
Morten Boysen wrote:
> Nej, det er netop ikke sandt. Hvad, hvis værdien stammer fra en DAC?
Ruhig jetzt. Hvad er en DAC?
--
Jens Axel Søgaard
| |
Ivan Johansen (09-10-2002)
| Kommentar
Fra : Ivan Johansen |
Dato : 09-10-02 17:18 |
|
Jens Axel Søgaard wrote:
>
> Ruhig jetzt. Hvad er en DAC?
Digital to Analog Converter
Han mente højst sandsynligt ADC (Analog to Digital Converter)
Ivan Johansen
| |
Jens Axel Søgaard (09-10-2002)
| Kommentar
Fra : Jens Axel Søgaard |
Dato : 09-10-02 18:57 |
|
Ivan Johansen wrote:
> Jens Axel Søgaard wrote:
>>
>> Ruhig jetzt. Hvad er en DAC?
>
> Digital to Analog Converter
Nåh - var det bare det. TLA'er burde forbydes.
--
Jens Axel Søgaard
| |
Morten Boysen (09-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 09-10-02 19:42 |
|
"Ivan Johansen" <NG@Padowan.dk> wrote in message
news:3DA4569C.8010805@Padowan.dk...
> > Ruhig jetzt. Hvad er en DAC?
>
> Digital to Analog Converter
>
>
> Han mente højst sandsynligt ADC (Analog to Digital Converter)
Det var nemlig lige, hvad jeg mente. Tak for korrektionen!
--
Morten Boysen
| |
Thomas Lykkeberg (08-10-2002)
| Kommentar
Fra : Thomas Lykkeberg |
Dato : 08-10-02 20:56 |
|
On Tue, 8 Oct 2002 16:42:29 +0200, "Morten Boysen"
<morten.boysen@aub.dk> wrote:
>Den eneste grund til, at du kan vise en forskel, er at du med 11
>vælger et tal, som kan repræsenteres eksakt med en heltals type. Da
>1,1 ikke kan dannes ved at dividere et heltal med en potens af 2, så
>kan 1,1 ikke repræsenteres eksakt i fixed-point kommatal. Vælger du
>derimod to kommatal, som kan repræsenteres eksakt i fixed-point, så er
>der ingen problemer. Hardwaren til multiplikation af fixed-point og
>heltal er alligevel fuldstændigt identisk.
Sludder, tallet 1,1 udtrykkes med lige stor nøjagtighed hvad enten det
er fixed point eller floating point. Den eneste fordel ved floating
point er at "dynamik området" er MEGET størrer.
Husk at et floatingpoint tal betår af en mantissa og en exponent.
1,1 udtrykkes som 1E1+0,1 (hvor 0,1 er repræsenteret ved fixed point)
/Thomas
| |
Morten Boysen (08-10-2002)
| Kommentar
Fra : Morten Boysen |
Dato : 08-10-02 21:46 |
|
"Thomas Lykkeberg" <thomasDOTlykkeberg@privatDOTdk> wrote in message
news:ntd6qugne9s1vejdccossg40c2rq4trkof@4ax.com...
> Sludder, tallet 1,1 udtrykkes med lige stor nøjagtighed hvad enten
det
> er fixed point eller floating point. Den eneste fordel ved floating
> point er at "dynamik området" er MEGET størrer.
Hvilken relevans har floating point for denne debat? Derudover er der
en anden meget stor forskel på floating point og fixed-point. Ved
fixed-point er den numeriske afstand imellem to på hinanden følgende
tal konstant. Det er den ikke ved floating point.
--
Morten Boysen
| |
Bjarne Laursen (08-10-2002)
| Kommentar
Fra : Bjarne Laursen |
Dato : 08-10-02 21:45 |
|
"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote:
>["Bertel Lund Hansen"]
>> > Der er afrundingsfejl ved alle kommatalstyper.
>["Morten Boysen"]
>> Afrundingsfejlen ved fixed-point kommatal er præcis den samme som ved
>> heltals typer.
>
>Eh... Hvad giver 1,1 * 1,1?
>Regn gerne binært for den sags skyld.
Ved multiplikation fås generelt lige så mange bits som de to faktorer
har tilsammen. Man skal også vælge en variabel til resultatet med lige
så mange bits efter kommaet som de to faktorer har efter kommaet
tilsammen.
1,1 * 1,1 = 10,01
0001,1000 * 0001,1000 = 00000010,01000000
Hvis man forsøger at placere det i en mindre variabel resikerer man at
miste information som afrunding eller overflow.
Hvis man skal forstå 1,1 decimalt har man et problem da det ikke kan
representeres nøjagtig binært, men så kan man jo f.eks bruge BCD
-Bjarne
| |
Lasse Madsen (06-10-2002)
| Kommentar
Fra : Lasse Madsen |
Dato : 06-10-02 21:46 |
|
Whow !
I går da helt amok ... jeg er nu 1000% mere forvirret end jeg var til at
starte med :)
Tillad mig at lave et assembler equvilant:
SBIS UCSRA, 0
Tester om LSB i UCSRA registret er 1
SBIC UCSRA, 0
Tester om LSB i UCSRA registret er 0
Hvis jeg så skulle teste det i C ville man så skulle skrive
if ( USCRA | 0b00000001 )
{
printf("UCSRA var lig med 1");
}
men hvad så hvis man vil teste om den er nul skal jeg så teste sådan?
if ( UCSRA | 0b11111110 )
{
printf("UCSRA var lig med 0");
}
M.v.h.
L. Madsen
"Lasse Madsen" <lasse.madsen@elektronik.dk> wrote in message
news:an70ai$1tve$1@news.cybercity.dk...
> Hej alle sammen :)
>
>
> Jeg kunne godt tænke mig at aflæse LSB (første bit) af en 8bit variabel
> feks.
>
>
> 0b0000000x
>
> Hvor der så er x jeg gerne vil aflæse uden at kigge på de andre bit.
>
>
> Umildbart tror jeg at jeg skal OR dem sammen for at undgå at manipulere
> nogen af de andre bit nogenlunde sådan:
>
> if ((0b0000000x | ???????))
> {
> xxx
> }
>
> men hvordan OR'er jeg, så jeg finder ud af om X er 1 eller 0 ???
>
> Håber at i skulle have nogle ideer :)
>
> M.v.h.
> L. Madsen
>
>
>
| |
Bertel Lund Hansen (06-10-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 06-10-02 22:33 |
|
Lasse Madsen skrev:
>SBIS UCSRA, 0
Jeg kender ikke SBIS (eller andre nymodens assemblerkoder).
>Hvis jeg så skulle teste det i C ville man så skulle skrive
>if ( USCRA | 0b00000001 )
>{
>printf("UCSRA var lig med 1");
>}
Nej. "USCRA & 0x1" vil have samme værdi som bit 0 i USCRA.
"0x" betyder hexværdi.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Lasse Madsen (06-10-2002)
| Kommentar
Fra : Lasse Madsen |
Dato : 06-10-02 23:26 |
|
Hej Bertel.
> Jeg kender ikke SBIS (eller andre nymodens assemblerkoder).
Det var da en skam ... assembler er ellers et flot sprog :)
jeg kan fortælle (til de interesserede) at SBIS og SBIC kommandoerne er
taget fra Atmel AVR Assembler
(Assembler til 8bit mikroprocessorere)
>
> Nej. "USCRA & 0x1" vil have samme værdi som bit 0 i USCRA.
Ok mange tak.
> "0x" betyder hexværdi.
Det gør det sjovt nok også i assembler :)
kan man forresten bruge $01 i C ligsom man kan i assembler ?
eller 01h ?
M.v.h
L. Madsen
| |
Bertel Lund Hansen (07-10-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 07-10-02 06:33 |
| | |
Thomas Lykkeberg (08-10-2002)
| Kommentar
Fra : Thomas Lykkeberg |
Dato : 08-10-02 21:01 |
|
On Mon, 7 Oct 2002 00:26:20 +0200, "Lasse Madsen"
<lasse.madsen@elektronik.dk> wrote:
>kan man forresten bruge $01 i C ligsom man kan i assembler ?
>eller 01h ?
Nej. Læser du slet ikke det du selv skriver For at sige det igen
(kig længere tilbage i tråden)
Følgende pre-fix bruges i C
Hexadecimale tal (HEX)
0x
Octale tale (OCT)
0 <-- Det er et nul, ikke et o som i Ole.
Decimale tal (DEC)
INTET
Eks. på decimal tallet 100
100 -- HEX --> 0x64
100 -- OCT --> 0144 (Husk 0 foran)
/Thomas
| |
Jens Christian Larse~ (06-10-2002)
| Kommentar
Fra : Jens Christian Larse~ |
Dato : 06-10-02 22:46 |
|
| |
Lasse Madsen (06-10-2002)
| Kommentar
Fra : Lasse Madsen |
Dato : 06-10-02 23:24 |
|
Hej Jens
> Som det er nævnt flere gange i tråden skal du bruge AND i stedet for
> OR.
Ok jeg blev bare lidt i tvilv når folk skriver i øst og vest :)
> Desuden er der desværre ikke noget der hedder 0b i C.
Det er muligt at det ikke findes i ANSI C men den compiler jeg bruger
"CodeVisionAVR C" er den funktion fuldt understøttet ... man undre sig
egentligt også over hvorfor denne funktion ikke er tilgænglig i ANSI C
Hvor klager jeg :)
> Din kode kunne se
> sådan her ud:
>
> if (USCRA & 0x01) {
> printf("LSB er 1");
> } else {
> printf("LSB er 0");
> }
Alle tider nu er jeg med :)
> andre løsninger er åbentbart ikke fuldt ud så korrekte som AND
> operatoren, og kan muligvis crashe computeren på dit lokale museum,
> og det kan vi jo ikke
Nej det går skam ikke :)
men koden er nu ikke til en PC men en mikroprocessor ...
men den vil nok også begynde at lave nogle underlige ting hvis udtrykket
ikke passe (been there done that, more than tweice)
> Held og lykke med C koderiet..
Mange tak !
det får jeg også brug for
M.v.h.
L. Madsen
| |
Bertel Lund Hansen (07-10-2002)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 07-10-02 06:36 |
|
Lasse Madsen skrev:
>"CodeVisionAVR C" er den funktion fuldt understøttet ... man undre sig
>egentligt også over hvorfor denne funktion ikke er tilgænglig i ANSI C
Der kunne komme 20 personer med hver deres individuelle ønsker
til hvordan hexkoder skulle skrives. Man opnår ingen
funktionsmæssig fordel ved at tillade mange muligheder, og
oversættelsen ville blive langsommere.
Men du kan lave en makro der klarer det lille nummer:
#define $ 0x
Så skal du bare være sikker på at der ikke er andre dollartegn
for de vil alle blive udskiftet uden nogen form for tjek.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
| |
Kent Friis (07-10-2002)
| Kommentar
Fra : Kent Friis |
Dato : 07-10-02 16:37 |
|
Den Mon, 07 Oct 2002 07:35:57 +0200 skrev Bertel Lund Hansen:
>Lasse Madsen skrev:
>
>>"CodeVisionAVR C" er den funktion fuldt understøttet ... man undre sig
>>egentligt også over hvorfor denne funktion ikke er tilgænglig i ANSI C
>
>Der kunne komme 20 personer med hver deres individuelle ønsker
>til hvordan hexkoder skulle skrives. Man opnår ingen
>funktionsmæssig fordel ved at tillade mange muligheder, og
>oversættelsen ville blive langsommere.
>
>Men du kan lave en makro der klarer det lille nummer:
>
> #define $ 0x
Som jeg læser det, var det nu at skrive binære tal han manglede.
Mvh
Kent
--
Hvis man ikke kan lide klassisk musik, er det sandsynligvis fordi
lydkvaliteten er for dårlig. Klassisk musik kræver et godt anlæg.
| |
Bjarke Dahl Ebert (07-10-2002)
| Kommentar
Fra : Bjarke Dahl Ebert |
Dato : 07-10-02 16:45 |
|
"Kent Friis" <leeloo@phreaker.net> wrote in message
news:ans9m9$2c8$3@sunsite.dk...
> Hvis man ikke kan lide klassisk musik, er det sandsynligvis fordi
> lydkvaliteten er for dårlig. Klassisk musik kræver et godt anlæg.
Anlæg? Hører du playback? Hvor "klassisk" er det lige?
Mvh. Bjarke
| |
Byrial Jensen (07-10-2002)
| Kommentar
Fra : Byrial Jensen |
Dato : 07-10-02 17:27 |
|
Bertel Lund Hansen <nospam@lundhansen.dk> skrev:
> Men du kan lave en makro der klarer det lille nummer:
>
> #define $ 0x
Det vil ikke virke. Grunden til det kan deles i to situationer:
1) Et makronavn skal være en gyldig identifikator. Det er ikke
krav at dollartegn skal kunne indgå i en identifikator, så måske
er makrodefinitionen ugyldig.
2) Implementationer har ret til at tillade dollartegn i
identifikatorer, men hvis de gør det, vil tegnsekvenser som for
eksempel "$73AB" blive opfattet som en udelelig enhed uden
makroekspansion af dollartegnet.
| |
|
|