|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > rest runden bei long-divide? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
28.10.2009, 17:27 Uhr AGSzabo Posts: 1663 Nutzer |
hi, der szabo muss mal wieder beim dividieren runden, diesmal aber bei longwords! routinen die long-dividieren hab ich jetzt schon genug, aber keine liefert mir einen rest zusätzlich zum ergebnis. auch dann nicht wenn das ergebnis in 16 bit passt. diesmal suche ich ganz explizit nach einer fertigen funktion, die ich NICHT verstehen brauche. grüssi Andreas -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 ps: da ist die routine die ich momentan verwende, es würde schon reichen wenn diese routine um die (auf-)rundungsfunktion erweitert wird: code:; D0.L = D0.L / D1.L unsigned ; this divison routine fails (?) with a div by zero ; when d1 is greater than d0 (?) divul MOVEM.L D2/D3,-(SP) SWAP D1 TST.W D1 BNE.B .long_divisor SWAP D1 ; fall 1: divisor in d1 <= 65535 MOVE.W D1,D3 MOVE.W D0,D2 CLR.W D0 SWAP D0 DIVU.W D3,D0 MOVE.L D0,D1 SWAP D0 MOVE.W D2,D1 DIVU.W D3,D1 MOVE.W D1,D0 CLR.W D1 SWAP D1 .rausda MOVEM.L (SP)+,D2/D3 RTS .long_divisor SWAP D1 ; fall 2: divisor in d1 > 65535 MOVE.L D1,D3 MOVE.L D0,D1 CLR.W D1 SWAP D1 SWAP D0 CLR.W D0 MOVEQ #16-1,D2 .duloop ADD.L D0,D0 ADDX.L D1,D1 CMP.L D1,D3 BHI.B .dublah SUB.L D3,D1 ADDQ.W #1,D0 .dublah DBRA D2,.duloop bra .rausda [ Dieser Beitrag wurde von AGSzabo am 28.10.2009 um 17:34 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
28.10.2009, 17:39 Uhr thomas Posts: 7718 Nutzer |
Was willst du mit dem Rest ? Du kannst einfach vor der Division die Hälfte des Divisors zum Dividend addieren, dann ist das Ergebnis gerundet. TRUNC(a / b + .5) = TRUNC((a + b / 2) / b) Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
28.10.2009, 17:42 Uhr AGSzabo Posts: 1663 Nutzer |
@thomas: hey, das ist eine großaretig idee, danke ich probiere es gleich aus! -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
28.10.2009, 17:54 Uhr AGSzabo Posts: 1663 Nutzer |
äh, ja, jetzt rundet es. aber im umfeld der rechnung scheint trotzdem was anderes noch nicht zu stimmen: es geht um einen progressbar der die position beim durchsuchen des speichers anzeigt, also es geht um sehr große zahlen. die formel ist: 100% * done / size soweit so gut, aber wenn size nur 256 ist, endet der bar bei trotz runden nur bei 99%! und bei 96 bytes bei 98%. kann das ein fehler oder über/unterlauf oder sowas in der berechnung sein? [ Dieser Beitrag wurde von AGSzabo am 28.10.2009 um 18:01 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
28.10.2009, 19:47 Uhr Der_Wanderer Posts: 1229 Nutzer |
Pfostenproblem! Das ist kein Arithmetischer Fehler, sondern ein Denkfehler deinerseits. Pfostenproblem will sagen: Für 3 Meter Zaun mit einem Pfosten pro Meter benötigst du 4 Pfosten, und nicht 3 wie man naiv meinen mag. Übertragen auf deinen Progressbar: Wenn er von 0 bis 100 wandert, dann hat er 101 Positionen. -- HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
28.10.2009, 20:14 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: ja schon, aber in meinem fall mit großen werten fuer SIZE geht es doch bis 100. blos mit sehr kleinen nicht! in allen anderen kommunikationen zb ueber die connect-klasse zeigt der gauge die zahlen richtig von 0 bis 100 an! -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
28.10.2009, 20:35 Uhr Der_Wanderer Posts: 1229 Nutzer |
Das kommt nur mit Runden auf 100. Sonst nicht. Runden reicht aber halt nicht. Wenn du 96 Werte beackerst wird dein höchster Prozent Wert: 100 * 95 / 96 = 98,9... -- HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
28.10.2009, 21:00 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: hää, hmm .... und wie mach ich es richtig? ünbrigens, der scan für den der bar steht geht jetzt über einen eigenen task. :-) -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2009, 14:59 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das ist jetzt schon eine eher philosophische Frage. Schließlich ist die Erwartungshaltung bei einem Prozess, dass die Anzeige von 100% bedeutet, dass die Arbeit vollendet ist. Wenn der Dialog aber u.U. minutenlang bei 100% stehen bleibt und die CPU rödelt, weil Du den Wert so rundest, dass schon vorher 100% angezeigt werden, ist das für viele Anwender falsch. Wenn der Dialog aber beim Erreichen von 100% geschlossen wird, ist es dagegen irrelevant, ob er für eine Millisekunde 100% angezeigt hat. Wenn der Dialog, warum auch immer, stehen bleibt, sollte er nach getaner Arbeit bei 100% stehen, auch wenn man eben den Balken explizit auf 100% setzen muss. Also, auch wenn es schon gesagt wurde: Wenn Du 100 Arbeitsschritte hast, setzt Du den Fortschritt auf 0%, wenn Du mit dem ersten Arbeitsschritt beginnst und auf 1%, wenn der erste Schritt beendet ist und der zweite begonnen wurde. Dementsprechend setzt Du den Balken auf 99%, wenn der 100. Schritt begonnen wird und auf 100%, wenn der 100. beendet wurde. Da man üblicherweise nicht doppelte Arbeit macht und bei Beginn und Ende den Balken aktualisiert, setzt man eben den Wert, wenn man einen Schritt beginnt, muss dann aber einmal zusätzlich nach dem letzten Schritt aktualisieren (oder den Dialog schließen). Oder man setzt am Anfang explizit auf 0 und zählt vollendete Schritte. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2009, 16:29 Uhr AGSzabo Posts: 1663 Nutzer |
@Holger: eh, das sieht mir zu sehr nach einem workaround aus. gibts keine formel? immerhin funktioniert es ja mit großen zahlen. -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2009, 16:59 Uhr thomas Posts: 7718 Nutzer |
@AGSzabo: Ist das wirklich zuviel Mathematik für dich ? Bisher: prozent = 100 * done / size size ist 256 und done geht von 0 bis 255. Also prozent = 100 * 255 / 256 Wie könnte man denn Prozent jetzt auf 100 kriegen ? vielleicht mit prozent = 100 * 255 / 255 ? also prozent = 100 * done / (size - 1) Vielleicht solltest du dir doch lieber ein anderes Hobby suchen. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2009, 17:31 Uhr AGSzabo Posts: 1663 Nutzer |
@thomas: > Ist das wirklich zuviel Mathematik für dich ? TRUE > Vielleicht solltest du dir doch lieber ein anderes Hobby suchen. FALSE, gillt außerdem dann auch für holger mit seiner philosophischen lösung. mal im ernst, ich habe für simple dreisatzrechnungen zb fuer ein proportionalgadget in diveresn foren schon die wüstesten antworten und un-formeln gelesen! das thema war nicht nur für micht nicht leicht. aber die veranschaulichung von dir hat es bewirkt dass ich es jetzt verstehe. proportionalen dank ps: bevor ichs vergesse zu sagen: bei ner länge von ca unter 250 bytes geht es immernoch nicht auf! -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ Dieser Beitrag wurde von AGSzabo am 29.10.2009 um 17:38 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.11.2009, 12:03 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nun ja, Proportionalgadgets besitzen den verschiebbaren Bereich, der eine eigene Größe besitzt, die von der Gesamtgröße abgezogen werden muss, wenn man den Bewegungsspielraum ermitteln will. Genauso hat man auch bei einer Statusanzeige einen solchen Bereich, nämlich die Größe/Zeit die ein Arbeitsschritt ausmacht. Wenn man das begriffen hat, ist es auch ganz leicht. Zitat:Dann hast Du entweder die dahinterstehende Logik immer noch nicht richtig erfasst oder aber bei der Umsetzung eine Fehler eingebaut. Was davon zutrifft, können wir natürlich bestenfalls raten. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
01.11.2009, 12:47 Uhr AGSzabo Posts: 1663 Nutzer |
@Holger: das ist der stand der dinge: code:calc_percent move.l xfrO_done(a0),d2 move.l xfrO_size(a0),d3 subq.l #1,d3 move.l #100,d0 move.l d2,d1 bsr mulul ; d0 = d0 * d1 move.l d3,d1 beq.b .no_null lsr.l #1,d3 add.l d3,d0 bsr divul ; d0 = d0 / d1 .no_null ; d0 sollte jetzt einen wert von 0 bis 100 haben was ist falsch? mfg -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ Dieser Beitrag wurde von AGSzabo am 01.11.2009 um 12:49 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.11.2009, 13:06 Uhr Holger Posts: 8116 Nutzer |
@AGSzabo: Bist Du Dir denn sicher, dass Deine Routinen zum Multiplizieren und Dividieren das Richtige tun? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
01.11.2009, 13:06 Uhr thomas Posts: 7718 Nutzer |
Zitat: Um das zu prüfen, mußt du noch dazuschriebe, welche Werte done und size annehmen können und vor allem die Relation von done und size, z.B. kann done jemals size erreichen oder was ist der größte Wert von done. Außerdem frage ich mich, warum du zwischen 0 und 100 berechnest. Ich würde zwischen links und rechts des Fortschritsbalkens berechnen. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
01.11.2009, 13:43 Uhr AGSzabo Posts: 1663 Nutzer |
> Bist Du Dir denn sicher, dass Deine Routinen zum Multiplizieren und Dividieren das Richtige tun? nein, aber vielleicht könnte ich die mathematik-lib benutzen falls die muldiv.l kann? > welche Werte done und size annehmen können und vor allem die Relation von done und size, z.B. done und size können bis zu $FFFFFFFF große werden, was sie aber praktisch nie erreichen. das problem gibts ja auch nur mit kleinen werten um die 100. > kann done jemals size erreichen oder was ist der größte Wert von done. das könnte ein brauchbarer hinweis sein! es ist wahrscheinlich (ich schrieb die sache 2003) echt so dass DONE niemals SIZE wird weil es keinen sinn macht an der position SIZE auf ein soundformat zu testen. da ist ja nix mehr, höchstens fremder speicher den ich nicht antasten darf. kann man das irgendwie in der rechnung einbeziehen dann wär das problem gelöst. dazu muss man wissen, dass der step von addresse zu addresse 2 beträgt weil an ungeraden addressen in den meisten fällen nichst getestet wird. DONE ist also höshstens SIZE-2. evtl muss ich von d3 statt 1 also 2 abziehen? ich probiere es aus! > Außerdem frage ich mich, warum du zwischen 0 und 100 berechnest. Ich würde zwischen links und rechts des Fortschritsbalkens berechnen. das nun verstehe ich so nicht was du meinst. die progressbar-klasse kennnt zwei input modi: einen prozentwert ODER eine zahl zwischen 0 und $fff. das problem trat in beiden modi auf. mfg ps: ah ja tatsächlich, mit -2 satt -1 passt es jetzt tatsächlich! im falle von scan an ungeraden addressen muss man eben blos 1 abziehen und sonst 2.DANKE! -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ Dieser Beitrag wurde von AGSzabo am 01.11.2009 um 13:49 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.11.2009, 14:26 Uhr Holger Posts: 8116 Nutzer |
Zitat:Dann knallt es natürlich, wenn Du zuerst mit hundert multiplizierst und dann dividierst => ($FFFFFFFF * 100) passt nicht in ein LONG. Zitat:Der zweite Modus klingt ziemlich unsinnig. Die Frage zielt auf Einfachheit und Effizienz. Die Progressbar muss sowieso den Prozentwert auf ihre Pixel-Größe skalieren. Du kannst das API sowohl für den Anwendungsprogrammierer einfacher machen, als auch Divisionen sparen, wenn Du zwei Parameter anbietest: Gesamtanzahl Schritte und Anzahl erledigter Schritte. Dann führt die Progressbar-Klasse die Skalierung auf Pixelgrößen durch. Den Spezialfall Prozentwerte hast Du damit auch abgedeckt. Dazu muss die Anwendung ja nur eine Gesamtzahl von 100 angeben. Aber im Normalfall braucht man die Prozentzahl ja nicht. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
01.11.2009, 16:32 Uhr AGSzabo Posts: 1663 Nutzer |
@Holger: > Dann knallt es natürlich, wenn Du zuerst mit hundert multiplizierst und dann dividierst => ($FFFFFFFF * 100) passt nicht in ein LONG. klar aber das kommt praktisch nie vor. und wenn, wäre ich nicht der erste der dann pech hat. > Dazu muss die Anwendung ja nur eine Gesamtzahl von 100 angeben. Aber im Normalfall braucht man die Prozentzahl ja nicht. der prozent modus beinhaltet die ausgabe des textes "<zahl>%" im innern der bar. -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
01.11.2009, 22:53 Uhr Holger Posts: 8116 Nutzer |
Zitat:Dann musst Du tatsächlich zwei Berechnungen machen. Ändert aber nichts, dass die Berechnung der Pixelgröße und des Prozentwertes identisch sind, und es deswegen unnötige Code-Doppelung wäre, wenn die Anwendung den Prozentwert und das Toolkit die Pixelgröße berechnet. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
02.11.2009, 12:10 Uhr Der_Wanderer Posts: 1229 Nutzer |
code: Die Function oben berechnet y = x * a / b, wobei x*a größer als 32 bit sein darf. Damit solltest du Slider Werte umrechnen. Man schiesst schneller über 32bit aus als man denkt. Hier das gleiche in ASM: (x ist in D0, a in D1 und b in D2) code:--; d0=x ; d1=a ; d2=b ; d5=y MOVE.l d0,d3 DIVU.l d2,d3 ; q = x / b d3=q MOVE.l d3,d4 MULU.l d2,d4 SUB.l d4,d0 ; r = x-q*b d0=r MOVE.l d3,d5 MULU.l d1,d5 ; a*q d5=a*q MOVE.l d1,d6 MULU.l d0,d6 ; r*a d6=r*a MOVE.l d2,d7 ASR.l #1,d7 ; d7=b/2 ADD.l d7,d6 DIVU.l d2,d6 ADD.l d6,d5 HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
02.11.2009, 14:38 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: in der kürze liegt... ich staune nicht schlecht! diese routine macht alles? incl runden? warum ist dann meine routine die ich im ersten posting dieses threads gepostet habe sooo lang? -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
02.11.2009, 16:15 Uhr thomas Posts: 7718 Nutzer |
@AGSzabo: Weil deine Routine auch auf einem 68000 läuft und diese erst ab einem 68020 (divu.l, mulu.l). Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
02.11.2009, 16:35 Uhr AGSzabo Posts: 1663 Nutzer |
man kann sich ausrechnen ab welcher dateigröße mein progressbar versagt. da ich nicht weis ob die jetzige routine mit werten höher als 7fffffff ohne an vorzeichen zu denken umgehen kann, setze ich die maximale größe der erstern multipliaktion auf $7fffffff. das nun teilen wir durch 100 und haben die maximale dateilänge: 21474836. sind knapp 22 megabyte. auf den ersten blick nicht viel, wird aber von der anwendung so gut wie garnie erreicht. theortische könnte es aber sein, das jemand eine karte mit 128 mb ram hat und darin nach was zum rippen scannen will. -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ Dieser Beitrag wurde von AGSzabo am 02.11.2009 um 16:53 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
02.11.2009, 17:15 Uhr thomas Posts: 7718 Nutzer |
@AGSzabo: Was hat denn jetzt die Dateigröße in Bytes mit dem Fortschrittsbalken zu tun ? Wenn du Bytes nicht in deinem Datentyp gespeichert kriegst, dann rechne halt mit Kilobytes. Das ist doch aber vollkommen unabhängig von der Implementierung der Fortschrittsanzeige. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > rest runden bei long-divide? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|