Hallo zusammen,
Im Zuge der Zeit-Optimierung einer Interruptroutine habe ich aus einem
zweidimensionalen Array ein eindimensionales gemacht. Wo ich vorher aus
der Spalte [0..3] bequem auf ein weiteres Array zugreifen konnte,
T[0..3], tauchen jetzt die Werte 0,3,6,9 auf.
Ich kann mich nicht entscheiden, einen zweiten Zähler von 0..3 mitlaufen
zu lassen oder ein wenig Speicher zu opfern und ein Array[10] anzulegen,
die anderen Werte liegen dann eben brach.
Aber vieleicht gibt es ja einen schnellen, in C zu programierenden
Zusamenhang, der mir entgangen ist.
(0->0),(3->1),(6->2),(9->3), eigendlich ist die Art der Zuordnung nicht
so wichtig, sie müsste nur eindeutig und schnell sein.
Ich könnte natürlich noch mehr Zeit sparen, wenn ich auf Assembler
ausweichen würde, aber darum soll es hier nicht gehen.
Irgendwelche Vorschläge oder Hineise?
Schönen Dank im Vorraus.
Lutz
Vielleicht gehts nur mir so:
Ich finde deine Beschreibung reichlich verwirrend.
Warum zeigst du nicht einfach den Code her, den es zu optimieren gilt
und jemand hier sieht sich die Sache mal an.
Hab grad meine Glaskugel aus der Spülmaschine geholt und folgenden
"Zusammenhang" rausorakeln können: f(i) = i/3
Schwarzen Hahn opfern war nicht notwendig, jetzt brauch ich was anderes
zu Mittag :(
Sind die Werte die Du mappen willst denn Konstant oder Variable?
Wenn Konstant, dann case bei so wenigen Werten, wenn Variable, nimm ein
Arrray[10]
Tom
Guten Morgen zusammen,hallo Lutz
hab dich schon verstanden, brauchst aber nicht lange rumgrübeln. Du hast
da ein zweidimensionales array 3x4, 3 ist aber eine Primzahl. Es gibt
manchmal "zufällige" beziehungen, wenn man mit Primzahlen arbeitet, aber
entweder springen sie sofort ins Auge oder sie lassen sich(bei extrem
großen Primzahlen) in bares Geld verwandeln, dann hat man aber gleich
CIA,Mossat und andere Firmen im Nacken.
Mein genereller Tipp und an alle:Kommen Primzalen in einem Problem vor
und es muss schnell gehen, probiert die Methoden von Thomas Burkhart
aus. Takte zählen und wenn es nicht reicht, Methode komplett neu
umschreiben. Solche Probleme haben schon Leute in den Wahnsinn
getrieben, also vorsicht!
Zwiter Tip: hilfsbereitschaft in allen ehren, wenn ich eine Frage in
einem forum nicht versthe, dann suche ich die ursachen zunächst bei mir
und schweige. Diese Bescheidenheit stünde anderen auch gut zu Gesicht.
Und jetzt aus den Federn mit Euch, der frühe Vogel fängt den (Code-)
Wurm.
Erik schrieb:
> Zwiter Tip: hilfsbereitschaft in allen ehren, wenn ich eine Frage in> einem forum nicht versthe, dann suche ich die ursachen zunächst bei mir> und schweige. Diese Bescheidenheit stünde anderen auch gut zu Gesicht.
Dann erklär uns Nichtverstehern doch, was der TO frägt. Zeig doch mal
den Code, den er deiner Meinung nach optimiert haben möchte anstatt dich
da in nichtssagende Ergüsse über Primzahlen und den Mossad zu ergehen.
Je nachdem, wie sein Code tatsächlich aussieht, GIBT es nämlich
Möglichkeiten da etwas zu optimieren. Aber die haben absolut nichts mit
Primzahlen zu tun, sondern drehen sich um die alte Regel "Space for
Time". Je nachdem was sein Code macht, gibt es auch noch andere
Möglichkeiten, wobei die Compiler viele davon beherrschen.
Ohne den Code zu sehen, kann man nur im Nebel stochern. Es kann auch
sein, dass das hier
> Im Zuge der Zeit-Optimierung einer Interruptroutine habe ich> aus einem zweidimensionalen Array ein eindimensionales gemacht.
schon kontraproduktiv war. Im µC ist alles linear auch ein 2d Array ist
nur eine lineare Abfolge von Bytes und Compiler sind ziemlich gut darin,
zb in ineinandergeschachtelten Schleife Indexzusammenhänge zu finden und
auszunutzen.
Vielleicht liegt eine mögliche Lösung seines 'Problems' darin, ein
Zwischenarray mit Pointern einzuführen. Wer weiß?
Ausserdem ist dir anscheinend entgangen, dass er von Indizes im Bereich
0..3 spricht, die Arrays also eine Größe von 4 haben. 4 ist in der Tat
eine magische Zahl, da es eine 2-er Potenz ist. Und dann greifen auch
wieder Optimiermöglichkeiten, die allerdings der Compiler auch mit
einiger Sicherheit kennt.
Vielleicht ist sein 'Problem' aber in Wirklichkeit gar kein Problem und
der Originalcode ist nur ungeschickt geschrieben. Wäre nicht das erste
mal, dass jemand etwas zu optimieren versucht, wo es nichts mehr zu
optimieren gibt, nur weil der C Code etwas unhandlich aussieht.
Vielleicht hat er auch einfach nur 'teure Operationen' benutzt, wie zb
irgendwas<<i, die man umformen kann ....
Möglichkeiten und Variationen gibt es viele. Und es wäre allen Helfern
schon geholfen, wenn sich Nachwuchsprogrammierer über diesen Umstand
klar wären und einfach ihren Code posten würden anstatt ihn zu
beschreiben zu versuchen, was meistens sowieso in die Hose geht und erst
recht dazu führt, den Code posten zu müssen weil kein Mensch die
Beschreibung versteht.
Erik schrieb:
> Zwiter Tip: hilfsbereitschaft in allen ehren, wenn ich eine Frage in> einem forum nicht versthe, dann suche ich die ursachen zunächst bei mir> und schweige. Diese Bescheidenheit stünde anderen auch gut zu Gesicht.
Das Verhältnis der aufgrund von Unwissen der Helfenden nicht
verstandenen Fragen und der aufgrund von formulierungstechnischer
Unfähigkeit der Fragenden nicht verstandenen Fragen beträgt geschätzte
1:100, wenn nicht gar noch weniger.
Daher ist die Annahme, daß der Hilfesuchende auch in diesme Fall hier es
nicht geschafft hat, sein Problem verständlich zu formulieren, durchaus
angemessen.
Hallo zusammen, hier ist der Fragesteller.
Danke allen, die sich Mühe gemacht haben, mich zu verstehen.
Inzwischen habe ich auch ein paar Begriffe aufgeschnappt, die meine
Frage vielleicht deutlicher machen würden: Das Programm muss einige
[Kardnalzahlen zu Ordinalzahlen wandeln], um damit einen Wert aus einer
Tabelle zu holen.
Es ging um das wandeln.
Die oben angegeben Funktion f(x)=x/3 war natürlich richtig, aber:
Meine irrige Meinung war, das es dazu einen Buchhaltertrick geben
müsste, der das ganze in ein paar Takten erledigt.
Also sowas wie Schieben,verodern, rückschieben.Verixen,verknüddeln.
Im Binärsystem geht das ja mit der Zwei,Vier usw. ganz gut.
WENN es so etwas gegeben HÄTTE, DANN wäre es gut gewesen, wenn man das
in C hätte Formulieren könnte.
Aber, nachdem ich tatächlich schon schier am Verzweifeln war, die
Antwort:So etwas geht NIE, wenn eine Primzahl im Spiel ist, in meinem
Fall tatsächlich die Drei. Nicht ganz offensichtlich, was ?
Zumal die Zwei auch eine Primzahl ist, also lassen wir die mal aussen
vor.
Ich glaube, das dies der Grund ist, weshalb Primzahlen so gerne zum
Chiffrieren von Nachrichtendiensten genutzt werden , zumindest in der
Trivialliteratur und in billigen Agentenfilmen, ich habe aber auch
einiges dazu ergoogeln können. Allerdings nicht durchgelesen.
Was ich gesucht habe, waren "Buchhaltertricks mit der Drei", ihr wisst
schon, Leute die ohne Computer ellenlange Zahlenreihen bearbeiten
mussten, damals, mit Ärmelschonern und Rechenkugeln auf Papier.
Ich würde die Frage gerne mit "geklärt" betiteln, ich finde dazu aber
nichts.
Gruß von Lutz.
Wieso 3?
Du hast 0, 1, 2, 3
Das sind 4 Zahlen!
Du hast jetzt zwar jede Menge geschrieben. Aber das Einzige, wobei wir
dir hätten weiterhelfen können, hast du wieder nicht gezeigt: Deinen
Code!
Lutz Dünnbier schrieb:
> Ich glaube, das dies der Grund ist, weshalb Primzahlen so gerne zum> Chiffrieren von Nachrichtendiensten genutzt werden ,
Primzahlen werden deswegen so gerne benutzt, weil es trivial ist 2
hundertstellige Primzahlen miteinander zu multiplizieren, es aber
verdammt schwer ist, aus dem Produkt wieder die Primzahlen zu erhalten.
Primzahlen benutzt man dann deswegen, weil es dann nur 1 eindeutige
Zerlegung eines Produktes in 2 Zahlen gibt.
29 * 31 = 899
wenn du aber nur die 899 hast, ist es schwierig herauszufinden, dass sie
aus 29 und 31 enstanden ist.
Letztenendes bleibt dir nur durchprobieren welche Division aufgeht. Mit
den von mir gewählten kleinen Primzahlen ist das machbar. Aber mit
100-stelligen oder 200-stelligen ist das schon nicht mehr so einfach. Du
erschlägst die Lösung mit der schieren Menge der zu testenden Zahlen.
