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.
Karl heinz Buchegger schrieb:
> Vielleicht gehts nur mir so:
nö
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.
Man kann auch das optimieren (0->0),(3->1),(6->2),(9->3) 0 -> 0 0b0000 -> 0b0000 3 -> 1 0b0011 -> 0b0001 6 -> 2 0b0110 -> 0b0010 9 -> 3 0b1001 -> 0b0011 Invertieren ~0b00000000 = 0b11111111 ~0b00000011 = 0b11111100 ~0b00000110 = 0b11111001 ~0b00001001 = 0b11110110 + 1 0b00000000 0b11111101 0b11111010 0b11110111 & 3 0b00000000 0b00000001 0b00000010 0b00000011
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.