amiga-news 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: 7716
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:
Original von AGSzabo:
hää, hmm .... und wie mach ich es richtig?

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: 7716
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:
Original von AGSzabo:
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!

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:
ps: bevor ichs vergesse zu sagen: bei ner länge von ca unter 250 bytes geht es immernoch nicht auf!
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: 7716
Nutzer

Zitat:
d0 sollte jetzt einen wert von 0 bis 100 haben

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:
Original von AGSzabo:
done und size können bis zu $FFFFFFFF große werden,

Dann knallt es natürlich, wenn Du zuerst mit hundert multiplizierst und dann dividierst => ($FFFFFFFF * 100) passt nicht in ein LONG.
Zitat:
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.
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:
Original von AGSzabo:
der prozent modus beinhaltet die ausgabe des textes "<zahl>%" im innern der bar.

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:
int mul48(int x, int a, int b) {
  int q = x / b;
  int r = x - q * b;
  return a * q + r * a / b;
}


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