Retro Preservation Workspace

Monitorn

Browse archived Monitorn möten and the ABC80 mailing list, with full-text and text-number search.

← Back to ABC Tools

Meetings · ABC800 · Thread

"Reaktionstest", bladet 1986,1 sid 42

37 posts in thread

Kristoffer Eriksson <5357> · Text 3543 · w8 · inlagg

1986-04-29 01:28

Ärende: "Reaktionstest", bladet 1986,1 sid 42

Jag har en del synpunkter på Sven Wickbergs artikel "Reaktionstest" i senaste numret av bladet. Jag tar dem i tur och ordning: 1. Avrundning. Sven tycker att två decimalers noggrannhet på medelvärdet av testerna är för stor pga att tiden mäts i 50-dels sekunder. Egentligen ökar noggrannheten ju fler försök man gör, vilket utnyttjas flitigt vid fysikaliska experiment. Om man mäter en tid på en 50-del när får man redan efter två mätningar en noggrannhet på en 100-del, efter tio mätningar en 500-del, osv (om det är samma slags händelse som mäts hela tiden). 2. Avrundning. Så vitt jag kan förstå måst det vara enklare att skriva INT(M*100+0.5)/100 än INT((M*1000+5)/10)/100 3. GET ... GET-instruktionen är gjord så att den VÄNTAR på en tangenttryckning om ingen sådan redan har gjorts. Därför kan raderna 210 IF INP(56)<127 THEN 210 210 IF SYS(5) GET W¤ ELSE 210 i ABC80- resp 800-versionen helt enkelt ersättas av 210 GET W¤ som dessutom fungerar lika bra på båda ABC80 och 800. 4. Klockan i ABC800 Femtiondedelarna i PEEK(-11) är ingefemtiondedelar, utan 93-delar (eller 94-delar?). Så tidsberäkningen blir felaktig så som den har skrivits. Faktiskt. 5. Heltal i ABC800 Det är som i ABC80 att positiva heltalskonstanter tar mindre plats och är snabbare än negativa. Dock tar små negativa heltal samma plats som stora positiva (gränsen vid ca -30). Det hela beror på att de negativa talens minstecken behandlas som en funktion för sig, och absolutbeloppet (0-65535) som en annan, samt att små heltal lagras i en byte i stället för tre. 6. PRINT USING Ordet "USING" känn bara igen av BASIC-en om det står först i en PRINT-sats (på sin höjd efter "#Filnr"). Lämpligen används USING-formateringen för en hel rad i taget, t ex PRINT USING "### ### ##.##" I, J%, M men att skriva som Sven gjort pårad 600 är också fullt legitimt. Kanske ska titta lite närmare på de andra artiklarna också...
- Sven Wickberg <1384> · Text 3546 · w8 · kommentar
  
  1986-04-29 14:59
  
  Ärende: "Reaktionstest", bladet 1986,1 sid 42
  
  Det är uppmuntrande med kommentarer till artiklar man har fått in i Bladet. (Det vore inte dumt om det kunde bli fler som skriver för Bladet, ta chansen!) Kristoffers synpunkter fordra några kommentarer (kanske är det fel möte och då får väl någon flytta oss): 1. Om man avläser många mätvärden med dålig noggrannhet, behöver ju inte slutresultatet bli bättre noggrannhet. Det förutsätter att noggrannheten slumpvarierar lika mycket uppåt som nedåt. Om man däremot i stället för att avläsa 10 händelser var för sig kan avläsa 100 sådana händelser i följd på samma tidsmätning, då kan man få bättre noggrannhet för medelvärdet. 2. Jag har inte tänkt på den möjligheten. Verkar korrekt. 3. Är intressant som fenomen. Kristoffer har alldeles rätt i att GET W¤ vore det riktiga i detta fall. Anledningen till INP(56) etc är att programmet från början ritade en linje på skärmen till dess man tryckte på en tangent. Alltså ungefär som 205 ;chr¤(127%); och 210 .... GOTO 205 I så fall kan man inte stanna exekveringen med GET utan måste ha de rader jag använde. Sedan bestämde jag mig för att slopa det visuella och bara reagera på ljud, men SYS(5) och det där blev kvar (det fungerar ju...). Så kan det gå. 4. Om femtiondelarna i ABC800:s klocka i själva verkat är 93-delar förklarar det varför jag fick "snabbare reaktion" i BASCI II. Men det förklarar inte varför PEEK(-11) avläser 93-delar. Det kunde väl Kristoffer utreda närmare. Övriga punkter fordrar inga kommentarer, annat än att det kanske skulle vara till glädje för oss alla om Kristoffer gjorde allvar av sin fundering på att titta närmare på de andra artiklarna också - under förutsättning att resultatet kan bli några ytterligare artiklar (i Bladet).
  - Nils Hansson <519> · Text 3547 · w8 · kommentar
    
    1986-04-29 17:28
    
    Ärend: PEEK(-11) Vad jag har kommit fram till stegas TIC (=PEEK(-11)) från noll till 93 på en sekund. Mvh Nils Hansson
    - Lars Hedberg <2497> · Text 3548 · w8 · kommentar
      
      1986-04-29 20:11
      
      Ärend: PEEK(-11) För att vara ytterligare noggran: den räknar till 93 3 gånger och så en gång till 94. Detta gör 93.75 gånger/sekund. TFP
      - Patric Ljung <5455> · Text 3549 · w8 · kommentar
        
        1986-04-29 20:51
        
        Ärend: PEEK(-11) ok Det råkar förhålla sig som sålunda att. CTC-kretsen är programmerad att avge interupt med ett intervall på 10.6 ms (millisekunder, ej metersekund). Detta ger att följande ekvation måste vara uppfylld: 10.6 x konst = 1000 => konst = 1000 / 10.6 = 94.339622.... Därav att räknaren räknas till 93 (0 - 93) vilket ger 94 uppräkningar innan Sekund ökas. Detta medför även att ett fel uppkommer. Felets storlek är: 10.6 x 0.339622... = 3.5999932... Sålunda kommer klockan att gå 3.6 ms fel för varje sekund, vilket blir 216 ms fel per timme. Vilket innebär ett fel på 0.36 %, som i sin tur innebär att efter knappt fem timmar har den gått en sekund extra. Synd va??? mvh / Patric Vår batteriklocka i 806an går däremot massor fel. Är väl inne i december 1986. DS.
        
        Kristoffer Eriksson <5357> · Text 3550 · w8 · kommentar
        
        1986-04-29 23:42
        
        Ärend: CMOS-klockan Det sitter ju en liten trimkondensator i närheten av CMOS-klockan. Du kanske kan prova att vrida lite på den om klockan går illa?
        
        Patric Ljung <5455> · Text 3568 · w8 · kommentar
        
        1986-05-01 22:20
        
        Ärend: CMOS-klockan Jo visst, men det vore väl bäst att kolla med mätinstrument, det tar ju sin tid att kolla om den går litet fel. Och det är ju de felen man vill undvika, eller? Moss / Patric
        
        Gerry Eriksson <4842> · Text 3552 · w8 · kommentar
        
        1986-04-30 01:58
        
        Ärend: PEEK(-11) ok Du glömde kristallocillatorns inverkan på onoggranheten -:)
        
        Patric Ljung <5455> · Text 3569 · w8 · kommentar
        
        1986-05-01 22:23
        
        Ärend: PEEK(-11) ok Ajdå, då rasar ju alltihop... Moss / Patric
        
        Kristoffer Eriksson <5357> · Text 3558 · w8 · kommentar
        
        1986-04-30 23:54
        
        Ärend: PEEK(-11) ok När jag nu tar en extra titt på klock-rutinen i datorn lägger jag märke till en extra finess: Om sekunderna är jämnt delbara med fyra (kollas med IF (Sekunder AND 3)=0) räknar den till 93, annars till 94. Hur stort blir felet om man tar hänsyn till detta? (Man kan förövrigt stoppa klockan, utom 93/94-delarsräknaren, med POKE 65521,0 som är detsamma som att ställa dagen till noll.)
        
        Patric Ljung <5455> · Text 3570 · w8 · kommentar
        
        1986-05-01 22:46
        
        Ärend: PEEK(-11) ok Det har skall bli kul.....fram med hjärnan (miniräknar'n). Klockintervall (Ci) = 10.6 ms Eftersom nu rutinen räknade till 93 tre gånger av fyra och 94 en gån av fyra, och antalet sekunder är 60, som är delbart med 4. Detta innebär att vi inte behöver ta någon hänsyn till om det skulle bli 14 ggr 4 plus 3 (vilket är lika med 59). Tid att räkna till 93 (T93) = 94 x 10.6 = 996.4 ms Tid att räkna till 94 (T94) = 95 x 10.6 = 1007.0 ms Genomsnittslig tid per sekund (Tsg) = (3 x T93 + T94) / 4 = 999.05 ms Fel per sekund (Fps) = 1000 - Tsg = 0.95 ms Vilket i procent blir Fps / 10 = 0.095 % Detta är ju bra mycket bättre än vad vi först trodde, eller hur? Ja, jag säger det, 800 är en bra maskin, har inte sagt nåt annat. För att kanske visa på vad det blir litet mer konkret så blir det. 3600 s (= 1 h) * 0.00095 = 3.42 s/h. (Är det mycket? Vad blev det förut?) Moss / Patric
        
        Patric Ljung <5455> · Text 3571 · w8 · kommentar
        
        1986-05-01 22:56
        
        Ärend: PEEK(-11) ok Tänkte väl det, det blev litet fel i den tidigare uträkningen. Efter en timme skulle den ha gått 12.96 sekunder fel mot 3.42 som den nu tydligen går försakta. Tja, om det är speciellt bra det vet jag ju inte, det beror sig ju på vad den skall användas till. I annat fall kan man ju labba fram felet. - Sätt på datorn - Ställ klockan (exakt efter ditt eget ur, ev digitalur) - Låt den gå några timmar. - Kolla hur mycket fel den går. Moss / Patric
        
        Kristoffer Eriksson <5357> · Text 3606 · w8 · kommentar
        
        1986-05-06 00:31
        
        Ärend: PEEK(-11) ok Vad jag kan förstå av disassembleringen räknar den tre av fyra gånger till 94 och den fjärde gången till 93, inte tvärtom. Desutom går den direkt från 93 resp 94 till 0 eftersom uppräkningen görs omedelbart före testet och ev nollställning, vilket innebär att det går 93.75 avbrott på en sekund och inte 94.75. Dessvärre verkar ju inte detta vara någon vidare korrekt korrigering.
  - Kristoffer Eriksson <5357> · Text 3551 · w8 · kommentar
    
    1986-04-29 23:45
    
    Ärende: "Reaktionstest", bladet 1986,1 sid 42
    
    4. Jag tycker det här med 93-delarna borde göra att du får för HÖGA tider i BASIC-II-varianten, inte för låga.
    - Harald Nautsch <4479> · Text 3556 · w8 · kommentar
      
      1986-04-30 12:53
      
      Ärende: "Reaktionstest", bladet 1986,1 sid 42
      
      Tänk igen...
      - Kristoffer Eriksson <5357> · Text 3607 · w8 · kommentar
        
        1986-05-06 00:37
        
        Ärende: "Reaktionstest", bladet 1986,1 sid 42
        
        Som Svens reaktionstestprogram i BASIC-II-varianten står i bladet ger det för HÖGA reaktionstider, det har jag till och med testat nu. Detta kan alltså inte vara förklaringen till att det enligt artikeln ger kortare tider än ABC80-varianten. När man delar med 50 i stället för 93.75 (eller vad det nu ska vara) blir det ju så att redan strax efter att en halv sekund gott och räknaren kommit till 50 ger divisionen resultatet att en hel sekund har gått (50/50=1 i stället för 50/93.75=0.5333). Var så god och tänk om själv. (Jag kan förstås inte garantera att någon urgammal version av ABC800C inte verkligen kör med 50-delar i ställe för 93-delar.)
        
        Harald Nautsch <4479> · Text 3613 · w8 · kommentar
        
        1986-05-06 16:44
        
        Ärende: "Reaktionstest", bladet 1986,1 sid 42
        
        Naturligtvis har du rätt. Nästa gång ska jag titta på programmet oxo och inte bara slänga ur mig något.
  - Kristoffer Eriksson <5357> · Text 3608 · w8 · kommentar
    
    1986-05-06 01:03
    
    Ärende: "Från 80 till 800", Bladet 1,1986 sid 40
    
    Några synpunkter på denna artikel kan jag väl klämma fram också, men sen är det nog stopp: 1. Min erfarenhet av ".BAC"-program på ABC800 är att de tar samma eller aningen mindre utrymme att lagra än ".BAS"-program. Att skriva GOTO som en byte med koden 128 tar ju mindre plats än med de fyra tecknen G, O, T och O. Dock tar många instruktioner mer än en byteäven i ".BAC"-form. 2. ASC() omvandlas till ASCII() på alla maskiner jag sett eftersom båda orden finns i instruktionslistan som synonymer. När det listas bir det alltid ASCII eftersom den varianten står före ASC i instruktionslistan. Detsamma gäller t ex MID¤ kontra MID (utan ¤). 3. I allmänhet går IF ... THEN ... : REM ... bra , och det fins ingen anledning till åtgärd om man inte får något flmeddelande vid laddningen från ".BAS"-form. Det är ingen risk för problem med olikaBASIC-II-versioner om programmet sparas med SAVE, eftersom ingen ny kontroll görs förrän man försöker ändra i programmet. Dock tror jag alla BASIC-II-versioner är lika på den här punkten (OBS: tror). Det som inte är tillåtet är att GOTO utan "GOTO" dvs THEN <radnr> inte får följas av ytterligare satser, däribland ": REM". (Dock är denna konstruktion flitigt använd i vissa program). Detta gäller även t ex END. Något annat otillåtet är konstruktionen "IF ... <radnr> : <annat>" där det är meningen att <annat> ska utföras om villkoret är falskt, dvs ELSE efter hopp är utbytt mot kolon. 4. Att ABC80 skulle sätta in mellanslag runt kolon i CHAIN "DR0:MENY" fattar jag inte alls. DATA DR0:MENY vet jag inget om, men kan det verk- ligen fungera ens i ABC80:n om det är som Sven säger? 5. Att man före inladdnig av ABC80-program ställer in FLOAT och NO EXTEND, är nog intebara ett klokt, utan för det mesta helt nödvändigt. 6. Påståendet att Z=SYS(6):GET W¤ på ABC800 skulle vara helt ekvivalent med W=INP(56):W¤=CHR¤(W) är lite tveksamt. Det beror mycket på hur det ska användas, särskilt i spelprogram kan det vara knepigt eftersom man vill ha reda på om en tangent är netryckt just i det ögnblicket, och inte bara helt nyligen. Detta kan man skrva hela inlägg om. 7. I ABC80 tas alla mellanslag bort, inte bara vid INPUT och DATA, utan även när program laddas (eller knappas in). De mellanslag som syns när programmet listas sätts in på nytt av LIST-kommandot och finns inte lagrade. Därför går förstås "INPUT LINE" in lika bra som "INPUTLINE". Vad som däremot inte går är att få in "INPUTLINE" i en ABC800 i EXTEND- läge, men det ska man ändå inte ha när man jobbar med ABC80-program. 8. PEEK(39) ger i ABC800-serien en kod för maskintyp, och PEEK(38) version av denna typ. I ABC80 tycks den mycket riktigt bli noll. I gamla ABC800:or ger dessa adresser koderna för CR-LF, med dessa är också skilda från noll. Adress 14 ingår i ABC800 i en instruktion och finns åtminstone ur 800-synpukt ingen anledning att kolla.
    - Kristoffer Eriksson <5357> · Text 3668 · w8 · kommentar
      
      1986-05-14 00:38
      
      Ärende: Granskning av Bladet 1,1986
      
      Artikeln "Mera räknekul med CBS" på sidan 39: 1. Åtminstone på ABC800 anser funktionen COMP% att "0.1" och "0.10" är lika. Antagligen är det så även på ABC80. Därför tror jag Sven (i beskrivningen) har blandat ihop vanlig strängjämförelse med COMP%, eftersom sådan jämförelse mycket riktigt skulle anse att "0.1" och "0.10" var olika. Så när han skriver att han har "struntat i kontrollen", underskattar han sig själv, eftersom COMP% utför just denna kontroll. 2. På rad 150 i programmet har Sven helt onödigt för oss ABC800-användare skrivit "END" mitt på raden. Det ger som bekant ett felmeddelande vid inskrivning. Över huvud taget är konstruktionen "IF ... THEN END ELSE <radnr>" onödigt komplicerad när med helt enkelt kan skriva IF NOT ... THEN 130 END Artikeln "Kommentarer till ett bokstavspel" på sid 14-15: Sven, är du säker på att alla problem programmet framställer går att lösa? Jag har läst någonstanns om att det finns olösliga kombinationer i 15-spelet som du nämner i inledningen. (Eller kan det vara Rubiks kub det gällde?) Vill man ha en utgångsställning som garanterat går att lösa, ska man vid utslumpandet av positionerna låta slumpen välja den motsatta sortens operationer som användaren sedan för använda för att lösa problemet. Då måste det ju gå att lösa åtminstone genom att upprepa slumpningen baklänges. (För att illustrera ett dylikt olösligt problem kan du tänka dig att du har en urtavla som du ska få i den vanliga ställningen med tolvan upp och siffrorna medurs runt tavlan. Dina tillåtna drag består enbart av att vrida urtavlan medurs eller moturs. Om man nu skapar utgångsläget genom att vrida urtavlan ett par snäpp moturs, löser du lätt och elegant problemet genom att vrida lika många snäpp åtandra hållet. Om man däremot skapar utgångsläget genom att byta plats på 7 och 4 kommer du snart underfund med att problemet inte går att lösa med de tillåtna dragen.)
      - David Andersson <5201> · Text 3669 · w8 · kommentar
        
        1986-05-14 02:04
        
        Ärende: Granskning av Bladet 1,1986
        
        'Kommentarer till ett bokstavsspel' sid 14. Jag är tämligen säker på att om utgångsläget för 15-spelet slumpas fram så kan man få olösliga kombinationer. Risken (sannolikheten) för det blir i storleksordningen 50% skulle jag tro. Även Rubiks kub kan ha oläsliga kombinatoner. Om man gör flera slumpvisa utgångslägen för kuben blir bara 1/6 av dem lösliga. Eller kanske det blir ännu färre? Angående att hoppa ur en FOR-NEXT loop med GOTO står det i högra spalten 'för vissa slag av (FOR-NEXT) slingor reserveras .. ytterligare en minnesadress om den gamla slingan inte är avslutad.' Den typen av slinga känner inte jag till. Vad jag vet så reserveras 10-16 byte för varje FOR-NEXT slinga i programmet oavsett hur många gånger de används, om de avbryts eller om de inte används alls.
        
        Kristoffer Eriksson <5357> · Text 3673 · w8 · kommentar
        
        1986-05-14 18:57
        
        Ärende: FOR-NEXT
        
        Har du någon aning om var dessa 10-16 bytes förvaras?
        
        David Andersson <5201> · Text 3683 · w8 · kommentar
        
        1986-05-15 15:14
        
        Ärende: FOR-NEXT
        
        Även svar på inlägg 3680. Nu uttalar jag mig om ABC80 men jag tror inte att skillnaden är så stor mot ABC800. Varje FOR-NEXT loop i ett program får en post på HEAP:en. Posten läggs upp när man gör RUN. Den ligger på HEAP:en mitt bland alla variabelposter som också läggs på HEAP:en vid RUN. Jag tror att posten innehåller adresserna till var loopen börjar och slutar. Dessa adresser initieras en gång för alla, loopen flyttar ju inte på sig. När FOR-satsen exekveras beräknas slutvärdet (efter TO) och stegvärdet (efter STEP), dessa värden lagras sedan i posten och behöver inte beräknas för varje varv i loopen. Eventuellt lagras även adressen till loopvariabeln där, dock ej loopvariabelns värde. Posten är 10 byte för heltalsloopar (FOR I%=) och 16 bytes för flyttal (FOR I=). Detta gäller som sagt ABC80. Det finns inget som tar mera plats när loopen körs och inget minne som frigörs när loopen har kört färdigt. Ur den synpunkten är det ofarligt att gå ur FOR-NEXT loopar med GOTO.
        
        Sven Wickberg <1384> · Text 3678 · w8 · kommentar
        
        1986-05-14 20:02
        
        Ärende: Granskning av Bladet 1,1986
        
        Rubiks kub Är det verkligen så att 1/6 av slumpvis hopsatta kuber ger olösliv kombination? Jag har plockat ihop kuberna många gänger men änner ännu aldrig funnit en olösl,ig kombination. FOR-NEXT Gäller det är för ABC80 att en avbruten FOR-NEXT-slinga inte blockerar minnesutrymme med en gammal återhoppsadress? Jag har inte kvar något protokoll, men jag har prövat ganska många varianter av avbrutna operationer (t ex GOSUB som avbryts innan man kommer till RETURN och diverse andra saker man kan göra med GOTO) öoch jag vill minnas att det gällde även FOR-NEXT att minnet kunde bli fullt med gamla återhoppsadresser. Men det gäller alltså ABC80.
        
        Mikael Hovmöller <4688> · Text 3679 · w8 · kommentar
        
        1986-05-14 21:14
        
        Ärende: Granskning av Bladet 1,1986
        
        Rubiks kub: Du har bara haft tur, gör så här så förstår du: 1. Lös kuben 2. Vrid en hörnabit ett snäpp. 3. Försök nu... (Detta bevisar att mer än 1/6 av alla kombinationer är olösliga!) M.v.h. Micke
        
        David Andersson <5201> · Text 3685 · w8 · kommentar
        
        1986-05-15 15:45
        
        Ärende: Rubiks Kub
        
        Nja, jag menade att max 1/6 var * lösliga * Så här: På en färdiglöst kub kan en hörnkloss vridas i tre olika lägen. Bara i en av dessa kan man lösa kuben igen. En av kantklossarna kan vridas i två lägen. Bara i det ena läget kan kuben lösas. Om man slumvis rör om EN hörnkloss och EN kantkloss så är chansen 1 av 6 att kuben sedan går att lösa. Jag antar att kanter och hörn är oberoende av varandra. Om alla klossar slumpvrids och kantvridningar resp. härnvridningar tar ut varandra så blir fortfarande 1 av 6 kombinationer lösliga. Om vridningar av två hörnklossar ger en ny kombination som inte motsvarar vridningen av EN hörnkloss så är chansen att få en lösbar kub mindre än 1 av 6. Men att det skulle vara så är inte troligt. (inte mycket om ABC80 i det här inlägget, inte)
        
        Patric Ljung <5455> · Text 3690 · w8 · kommentar
        
        1986-05-17 12:53
        
        Ärende: Granskning av Bladet 1,1986
        
        Man kommer troligtvis att få en olöslig variant om man slumpar ut inne- hållet. Anta att du plockar isär kuben och sedan sätter ihop hur som helst, En del bitar kommer då att vara 'felvända'. Den måste 'vridas' i oordning. Moss / Patric
        
        Mikael Hovmöller <4688> · Text 3708 · w8 · kommentar
        
        1986-05-20 22:54
        
        Ärende: Granskning av Bladet 1,1986
        
        Säker på det? Man har ju möjligheten att en gång låta två brickor som står bredvid varandra byta plats, men det kanske inte räcker? M.v.h. Micke
        
        Patric Ljung <5455> · Text 3716 · w8 · kommentar
        
        1986-05-21 20:43
        
        Ärende: Granskning av Bladet 1,1986
        
        (.Ähh, lägg avrå, ja fattar inte asså.) Jag hänger inte med riktigt. Kan man byta två brickor bredvid varandra på nåt Dataprogram eller på en KUB?
        
        Mikael Hovmöller <4688> · Text 3717 · w8 · kommentar
        
        1986-05-22 13:57
        
        Ärende: Granskning av Bladet 1,1986
        
        I programmet ROTERA.BAS (av SW, finns i bladet), kan man, förutom att man roterar 'som vanligt' (se bladet) byta plats på två brickor som står bredvid varandra. Detta gör att det troligen är möjligt att lösa alla kombinationer. M.v.h. Micke
        
        Patric Ljung <5455> · Text 3718 · w8 · kommentar
        
        1986-05-22 15:06
        
        Ärende: Granskning av Bladet 1,1986
        
        Okey då är jag med på noterna. Men sånt kallas fusk. Och sådant hade jag inte räknat med.
        
        Mikael Hovmöller <4688> · Text 3722 · w8 · kommentar
        
        1986-05-22 19:02
        
        Ärende: Granskning av Bladet 1,1986
        
        Det är väl inte fusk? Har man inte den möjligheten är det ju omöjligt! M.v.h. Micke
        
        Patric Ljung <5455> · Text 3738 · w8 · kommentar
        
        1986-05-24 10:50
        
        Ärende: Granskning av Bladet 1,1986
        
        Dator 'fuskar' ju när den blandar kuben så det är väl ömsesidigt? Om datorn inte fuskade hade det ju varit möjligt utan 'fusket' som du själv gör. Moss / Patric (Om jag fattat det rätt, att datorn blandar hej vilt, datorn borde vrida kuben i oordning).
      - Sven Wickberg <1384> · Text 3677 · w8 · kommentar
        
        1986-05-14 19:57
        
        Ärende: Granskning av Bladet 1,1986
        
        Det är jätteroligt att se att mina skriverier, som ABC-Bladets redaktör flitigt publicerar, väcker gensvar och leder till ytterligare kommentarer och utveckling. Jag tror redaktören skulle bli tacksam om ni ville formulera er direkt för Bladet också, där kommentarerna har sin givna plats. Bara några kommentarer till kommentarerna. Det där med att COMP% inte skulle se att '0.1' och '0.10' är lika har jag från en för flera år sedan publicerad artikel av samlingspseudonymen Kaj och Monty i Bladet. Detaljer kommer jag inte ihåg, och jag har - som jag sa i artikeln - inte gjkort någon koll, jag bara antyder att här kan finnas problem. Om felet är borttaget i senare versioner är det ju bra, men i de första ABC80 fanns det alltså någon bug. Ang. bokstavsspelet undrar jag om Kristoffer Eriksson försökt spela det eller om han bara kommenterar programlistan och texten. Det framgår av spelförklaringarna att man ibland (statistiskt sett varannan gång) får en spelplan som inte kan lösas om man inte vid lämpligt tillfälle kastar om två närstående bokstäver. Jag fick från en medlem ett tips på en programrad som gjorde det möjligt att i stället för att skriva in (det osynliga) rutnumret kunde skriva den bokstav som står i den aktuella rutan. Jag har infört den ändringen plus några mindre konsekvens- ändringar och fått en snabbare och möjligen trevligare version. Om någon vill ha den kan jag sända in den (men jag har inte kontrollerat att den fungerar i ABC800).
        
        Kristoffer Eriksson <5357> · Text 3680 · w8 · kommentar
        
        1986-05-15 01:10
        
        Ärende: Granskning av Bladet 1,1986
        
        Menar du att det i ABC80 kan finnas en bugg som konstrar till det med just värdena "0.1" och "0.10" ? I så fall blir förstås situa- tionen en annan. Bokstavspelet har jag inte provspelat, eller ens lusläst artikeln, utan det var bara en reflektion jag haft i bakhuvudet en längre tid. Har du något teoretiskt underlag för påståendet att det skulle räcka ens med det extra draget att byta plats på två bokstäver ibland?
        
        Sven Wickberg <1384> · Text 3682 · w8 · kommentar
        
        1986-05-15 10:07
        
        Ärende: Granskning av Bladet 1,1986
        
        Ja, i ABC80 (den första med checksumma 11xxx) fanns en sådan bug, eller i varje fall visade sig ett sådant resultat. Efter inlägget testade jag min ABC80 med cs 9913 och där fungerade det korrekt. Jag har också nu verkligen testat uthopp ur FOR-NEXT och kunnat konstatera att det tydligen inte kostar något extra minne att göra så. Jag gissar att det beror på att ev pekare nollställs när man nästa gång börjar köra FOR-NEXT-delen och att de alltså alltid upptar samma minnesutrymme. Om man däremot hoppar ur en subrutin blir det med tiden MINNET FULLT. Ex 10 GOSUB 100 100 GOTO 10 200 RETURN Beträffande bokstavsspelet ROTERA har jag inte själv gjort några teoretiska undersökningar, men i min ungdom läste jag en artikel om 15-spelet som talade om att det berodde på antalet inversioner i spelet om det kunde gå ut eller inte. Det handlade om udda/jämna antal, varav jag har dragit slutsatsen att EN ny inversion skall vara tillräckligt. Jag har provspelet några hundra gånger och erfarenheten stämmer med ovanstående teori-fundering. Betr KRubiks kub kan jag inte sätta emot någon teori, men jag är förvånad över att jag kunnat ha sådan tur att jag aldrig satt ihop en omöjlig kub. Medan flugan var i full svagn för några år sedna häll jag på rätt mycket med den, just genom att plocka isär alltihop och sätta ihop det slumpvis. Jag minns inte att jag fick någon omöjlig kub, och det borde ha varit i varje fall några, statistiskt sett. (Nu är vi säkert i fel möte, men jag har inte mer att säga. Den som vill fortsätta får föreslå vart diskussionen skall ta vägen.)
        
        David Andersson <5201> · Text 3686 · w8 · kommentar
        
        1986-05-15 15:50
        
        Ärende: Rubiks kub
        
        (. Du kanske är så bra på att lösa Rubiks kub att det inte spelar någon roll att den får en omöjlig kombination .)
        
        David Andersson <5201> · Text 3684 · w8 · kommentar
        
        1986-05-15 15:25
        
        Ärende: COMP% i ABC80
        
        På ABC80 ger COMP%("0.1","0.10") rätt resultat. Det finns ett fel på checksumma 11273 som gör att resultatet av gämförelsen blir fel om båda talen är negativa, jämförelsen görs som om de vore positiva. Det Sven hade i tankarna var nog att en jämförelse med IF "0.1"="0.10" THEN ger 'fel' resultat.