Matroids Matheplanet Forum Index
Moderiert von matroid
Informatik » Algorithmen / Datenstrukturen » DNA/RNA des Coronavirus optimal komprimieren
Druckversion
Druckversion
Antworten
Antworten
Autor
Kein bestimmter Bereich DNA/RNA des Coronavirus optimal komprimieren
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Themenstart: 2020-03-14


Unter findet man ja die DNA vom Coronavirus. Die 38374 Zeichen fand ich zu groß!
TXT
gttctctaaa...aaa ohne Leerzeichen          29903 Bytes
mit Konvertierung {A,T,G,C,}={1,2,3,0} in eine Zahl Basis 4 ergibt das dezimal:
10337436781167...9221               Größe: 18004 Ziffern
dann nach Hex:
1a57ea642...d15555555555555555      Größe: 14952 Zeichen
dann binär speichern (2 Zeichen in 1 Byte): 7476 Bytes
dann ZIP:                                   7442 Bytes
7442/29903=0.2488713507 .. also  "auf 24,89 % " komprimiert.

Wer mitsuchen will, kann sich die Dezimalzahl hier anschauen/herunterladen.

Noch mehr ginge mit Formelkomprimierung (x^y, x!,...)
Primfaktorzerlegung: 268909 * 1188339241399679 * 17983stellige Zahl
die Alpertron nach 1,5 h noch nicht zerlegen konnte...

Andere Ideen? Komprimierungen... Algorithmen...?

Ach so -> in den Dezimalstellen von Pi verschlüsselt -> aber so weit hinten, dass die Positionsangabe länger als die Zahl wird...
...und mit den Atomen unseres Weltalls nicht mehr machbar ... :-)

Höhere Basen bringen nichts, da ja in Byte gespeichert wird:
Basis 36: ic7xqq8brngtqgbzzny... ergeben 11568 Zeichen.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
ligning
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 07.12.2014
Mitteilungen: 3081
Aus: Berlin
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.1, eingetragen 2020-03-14


Das ist doch Mumpitz. Die eigentliche Komprimierung war von 7476 Bytes auf 7442 Bytes.


-----------------
⊗ ⊗ ⊗



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
Delastelle
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 17.11.2006
Mitteilungen: 1464
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.2, eingetragen 2020-03-15


Hallo hyperG!

Bereits komprimierte Inhalte kann man normalerweise nicht weiter komprimieren. Ich komme auf 18.004 Bytes für Deine Dezimalzahl ohne Kompression, mit zip 9.202 Bytes.

Aus dem Ursprungsdokument:
"1 atta
...
29881 aaaa..."
mit ca. 38.381 Bytes liefert zip eine Länge von 13.274 Bytes.

Mir erschließt sich momentan nicht, warum man den mathematischen Inhalt eines Gencodes komprimieren muss!

Viele Grüße
Ronald



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.3, vom Themenstarter, eingetragen 2020-03-15


Ich kann die Überschrift/Frage leider nicht umbenennen. Besser wäre gewesen:

"Wer schafft die 38381 Bytes am stärksten verlustlos zu komprimieren?"

Denn für mich ist JEDER Algorithmus, der die Byte-Zahl verringern und das Original wieder herstellen kann, eine Komprimierung!

Ich hätte meinen "Trick" nicht sofort verraten sollen, denn dann wäre ligning vermutlich noch bei etwa 13000 Byte.

Da steckt kein "muss" dahinter, sondern der logische Wunsch möglichst wenig "Ballast" zu übertragen.
zu "Bereits komprimierte Inhalte kann man normalerweise nicht weiter komprimieren" -> bei gleichem Algorithmus "Ja", aber wenn man einen "besseren Algorithmus findet" geht noch was...



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.4, vom Themenstarter, eingetragen 2020-03-15


Danke für den Hinweis -> konnte nun die Stelle für bessere Titelüberschrift optimieren.
Rekord
Neuer Rekord: 7318 Byte
7318/38381=0,190667.. also auf 19,07 %

(solange hier immer "Schlaumeier" alles nur "heruntermachen" , werde ich zunächst nichts weiter dazu schreiben und warte, ob das noch verbessert werden kann)

Hier noch das Original (bevor ich es im Beitrag 1 wandelte):

wobei die 1. Spalte mit "Offsetzählung", Leerzeichen und "Neue Zeile" (0D 0A) weggelassen werden können.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
Delastelle
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 17.11.2006
Mitteilungen: 1464
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.5, eingetragen 2020-03-15


Hallo hyperG!

Wenn Du Zugriff auf verschiedene Komprimierungsalgorithmen hättest, könntest Du mal diese an der Beispieldatei testen!
Ich erinnere mich, das es beispielsweise Algorithmen mit Bäumen oder gleitenden Fenstern (sofern sich Gensequenzen wiederholen kann das viel bringen) gibt. Auch gibt es die Arithmetische Codierung.
Siehe auch:





Viele Grüße
Ronald



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.6, vom Themenstarter, eingetragen 2020-03-15


Danke Ronald,

ich habe mal das "Arithmetische Komprimieren" mit dem Code vom rangecoder
getestet. Die Basis4 Datei (29903 Byte) schafft er besser als ZIP
auf gute 7723 Byte.
(die kleinere Dezimaldatei hat für ihn weniger "Muster" und ergibt ein größeres komprimiertes Ergebnis; bin Datei kann er vermutlich nicht)

Damit ist er jedoch schlechter als mein primitives Basis16.bin.

Mal sehen, ob man unter 7000 Byte kommt...



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.7, vom Themenstarter, eingetragen 2020-03-15


Und bevor hier jemand auf die Idee mit Unicode kommt:


Das sind zwar nur 3738 Zeichen, ABER die verbrauchen nun mal je 2 Byte, was 7476 Bytes ergibt.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 1388
Aus: Thüringen
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.8, eingetragen 2020-03-15


Ich hatte die 4 Buchstaben mit einer Anzahl versehen, falls größer 1

at2a3g2t3....da ist es unkomprimiert auf 90% gefallen. So 9.3k komprimiert.

Vielleicht kann man dort ansetzten...


-----------------
Pech in der Liebe , Glück im Verlieren !!!



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.9, vom Themenstarter, eingetragen 2020-03-15


2020-03-15 22:51 - pzktupel in Beitrag No. 8 schreibt:
Ich hatte die 4 Buchstaben mit einer Anzahl versehen, falls größer 1

at2a3g2t3....da ist es unkomprimiert auf 90% gefallen. So 9.3k komprimiert.

Vielleicht kann man dort ansetzten...

Was Du beschreibst ist eine primitive Komprimierung, die von zip, rar, LZW usw. viel effektiver gelöst wird.

Durch meine Erfahrungen mit Pi-Zahlenkomprimierung hatte ich im Beitrag 1 bereits eine sehr effektive Methode beschrieben, die meist noch besser als ZIP & co ist.

Was ich aber eigentlich suche ist kein universeller Algorithmus, sondern eine ganz speziell für diese Zahl

zugeschnittene Formel, die extrem kürzer als alle bekannten Komprimiermethoden ist!
Es gibt über 300 Funktionen. Mit geeigneter Zusammenstellung gibt es garantiert eine Formel mit weniger als 6000 Zeichen...
Nur eine Frage der Zeit und ob sich jemand an der Suche beteiligen will.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 1388
Aus: Thüringen
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.10, eingetragen 2020-03-16


Eine Theorie hätte ich noch, werde sie aber nicht umsetzen.

Idee.

Wir lesen immer zwei Zeichen aus

Wir wissen, es gibt nur a,c,t,g. Wir weisen a=1,c=2,t=3 und g=4 zu.

Ein 1 Byte=8 Bit, wir codieren 1. Zeichen
a als [00000001]
c als [00000010]
t als [00000100]
g als [00001000]

, wir codieren 2. Zeichen
a als [00010000]
c als [00100000]
t als [01000000]
g als [10000000]

???

dann Komprimieren

denkbar wäre auch, alle a-t Kombinationen von 5 Zeichen  im Byte zu kodieren, wegen 5!<256
aaaaa=00000000
aaaac=00000001

usw
dann Komprimieren


-----------------
Pech in der Liebe , Glück im Verlieren !!!



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.11, vom Themenstarter, eingetragen 2020-03-16


Hallo pzktupel,

Dein Teil 1 entspricht etwa "Basis 4"
und der 2. Teil fast "Basis 5".

Da es immer mehr Formate werden, habe ich mal meine Messungen in einer farbigen Tabelle zusammengefasst:



Grüße Gerd



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.12, vom Themenstarter, eingetragen 2020-03-21


News zur RNA-Sequenz:

a) neue Komprimier-Formate in der Tabelle (auch Bildkomprimierung!)
Es fehlt noch fraktale Komprimierung. (die meisten sind leider verlustbehaftet -> also unbrauchbar!)

b) Vergleich RNA aus Whuhan & Nepal
( sollen das wirklich so viele Unterschiede sein, oder wie kommen die Wissenschaftler dazu, diese beiden dem selben Stamm zuzuordnen?)

Details zu a) & b) unter DNA_Komprimierung.htm

c) Aus der dezimalen Sequenz habe ich mal 64 Blöcke in ein Array aus je 40 Ziffern kopiert und alle in den Nachkommastellen von Pi suchen lassen.
Trotz mehrerer durchsuchter Terabytes (!) wurde noch KEINE Übereinstimmung gefunden. Mit der "mathematischen Komprimierung" wird es nicht so einfach...
Auch Fibonacci-Zahlen und Potenz-Formeln konnte ich in der dezimalen Sequenz noch nicht finden.




Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.13, vom Themenstarter, eingetragen 2020-03-24

Komprimierungsrekord
Neuer Rekord: 7207 Byte
7207/38381=0,18777... also auf 18,78 %

Bei derart hohen Optimierungen leidet natürlich die Geschwindigkeit
und der RAM-Verbrauch ist enorm (für die paar Byte über 9 GB !).

Man sieht in der Tabelle deutlich, wie sehr sich die Ergebnisgröße einem Grenzwert annähert (fast unabhängig von der Basis der Inputdatei).
Warum die Programmierer allerdings ihre Größe (bei Quelle Basis 10) nicht mit der kleineren in ms berechenbaren Hex/bin Größe vergleichen, bleibt mir ein Rätsel.

Meine Suche von je 40 Ziffern in den Pi Nachkommastellen (die letzten 340 Blöcke nicht alle 31 TB sondern nur bis zur Pos 130 Mrd. + 999...1000 Mrd. + 1401...1479 Mrd.) blieb leider ohne Erfolg :-(

Das zeigt deutlich, wie unser linear denkender Menschenverstand die Größe von Zahlen unterschätzt... und die Häufigkeit von 450 (40stelligen) "Mustern" in zig Bio. Nachkommastellen überschätzt.

Die Bildkompressionen schneiden besonder schlecht ab. Nach Hex-Bildern nun weitere Versuche mit der Basis 4 Zahl. Ein unkomprimiertes BMP-Bild ergab nach dem Packen so schlechte Werte, dass eine Auflistung nicht lohnt.
Negativrekord ist ppm: 108 kB, also auf über 277,79 % vergrößert!
Dass sich die "Erfinder" von
nicht schämen... (oder von Festplattenindustrie gesponsert)

Alle Daten auf der bereits genannten Internetseite.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.14, vom Themenstarter, eingetragen 2020-03-24

Komprimierungsrekord unter 7k
Neuer Rekord: 6228 Byte
6228/38381=0,1622678... also auf 16,23 %

Mehr dazu hier.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
rlk
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 16.03.2007
Mitteilungen: 10762
Aus: Wien
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.15, eingetragen 2020-03-25


Hallo hyperG,
(2020-03-24 18:36 - hyperG in Beitrag No. 1
Man sieht in der Tabelle deutlich, wie sehr sich die Ergebnisgröße einem Grenzwert annähert (fast unabhängig von der Basis der Inputdatei).
wenn ich Dich richtig verstehe, ist der Grenzwert die Entropie der Daten.
(2020-03-24 18:36 - hyperG in Beitrag No. 1
Warum die Programmierer allerdings ihre Größe (bei Quelle Basis 10) nicht mit der kleineren in ms berechenbaren Hex/bin Größe vergleichen, bleibt mir ein Rätsel.
Welche Programmierer meinst Du und was ist die Hex/bin Größe?
(2020-03-24 18:36 - hyperG in Beitrag No. 1
Negativrekord ist ppm: 108 kB, also auf über 277,79 % vergrößert!
Dass sich die "Erfinder" von
nicht schämen... (oder von Festplattenindustrie gesponsert)
Niemand hat behauptet, dass das portable pixmap (PPM) Format speichereffizient ist.
schreibt:
The PPM format is not compressed, and thus requires more space and bandwidth than a compressed format would. For example, the above 192×128 PNG (Portable Network Graphics) image has a file size of 166 bytes. When converted to a 192×128 PPM image, the file size is 73,848 bytes. The PPM format is generally an intermediate format used for image work before converting to a more efficient format, for example the PNG format, without any loss of information in the intermediate step.
Servus,
Roland

PS: Willst Du den Titel noch ändern?



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.16, vom Themenstarter, eingetragen 2020-03-25


Hallo Roland,

a) mit Grenzwert meine ich die "normalen Komprimier-Algorithmen", denn kein mir bekanntes schafft die 7 k Grenze zu unterbieten.

b) Nur gute Programme mit Priorität auf "minimale Größe" (meist Schalter "ultra") testen mehrere Algorithmen intern und suchen dann das Minimum heraus, da die Zeit sich dadurch vervielfältigen würde.

Und da sind wir auch schon beim nächsten Punkt:
Im Beitrag 1 hatte ich ja beschrieben, wie man mit superschneller HEX-Umwandlung und HEX-Speicherung  auf 7476 Bytes kommt. 99% aller Programme bleiben jedoch ihrem Algorithmus treu und ignorieren diesen Referenzwert. So zeigt die Tabelle deutlich, dass alle von mir getesteten Programme in Spalte "Basis10" den dazugehörigen Hex-Referenzwert ignorieren und mehr als die 7476 Bytes anbieten! Mit "Zeitverlust" hat das nichts zu tun, da die Wandlung bei kleinen Zahlen unter 1 ms liegt.

c) Die 7k Grenze konnte ich nur mit Optimierung der "Gensprache" unterschreiten. Einige nennen das auch "Wörterbuch"- oder "Silben"- Algorithmus. Ich habe hierzu die engl. Sprache geändert.

Wenn man extrem viel Zeit hat, kann man eine mathematische Formel für die Dezimalzahl (also Basis 10) finden. Da es über 300 Funktionen und unendlich viele irrationale Zahlen gibt -> eine endliche Rechenzeit.
Bis zu 40 Stellen leicht machbar, aber hier über 18000 Dezimalstellen. Theoretisch kann man die Komprimierung bis auf 5 Byte herunterschrauben:
5470!
Pi(xxxxx,18030)...
Ich habe schon zig Wege probiert, aber leider immer größer als der Referenzwert...
Das setzt natürlich voraus, dass das Programm zum entpacken auch alle 300 Funktionen & irrationale Zahlen kennen muss.
(was nicht mal Mathematica kann; z.B. AppellF2...AppellF4

dort auch nur unter 40 Stellen)

Grüße Gerd



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 1388
Aus: Thüringen
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.17, eingetragen 2020-03-25


Mein bestes Ergebnis bis jetzt 7828 Byte
Auszug vor ZIP: 7G5FPHFL9B0G2GA1VM6TVCHNNNE0C1VG1NNEJR8TKU9PUBI78P5J1S61OF3RDU2A265GER...(11973 Zeichen)


-----------------
Pech in der Liebe , Glück im Verlieren !!!



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.18, vom Themenstarter, eingetragen 2020-03-30


Trotz des Einsatzes von über 300 Funktionen sind exakte Treffer, die auch noch kürzer als die Zahl selbst sind, extrem selten!
Beispiel spezielle Funktion:
22698374052006863956975682=Fibonacci(123) (Komprimierung von 26 nach 14 Zeichen)

Je komplizierter/exotischer die Formeln werden, um so länger wird auch die Berechnungszeit (die dann zur Suchzeit noch hinzukommt!).
Beispiel AppellF1 Funktion:
1096977169733852400570972895984=[F1(0.3,0.4,2,1,0.2,0.1)*1e30] (Komprimierung von 31 nach 30 Zeichen)

Das Umstellen von Formeln bewirkt zu 99,99999999999% nur eine Verschiebung der Länge hin zu den Übergabeparametern (Argumenten).
Beispiel:
10337436781167807507928327372193831109435244409169    50 Ziffern
5893^13+931419670945872126941703337787816371857842876 53 Zeichen
(796^17-3774961108927126436531190964298230164485578078)/2 57 Zeichen

Bei der Suche große Zahlen mathematisch zu komprimieren, konnte ich nun eine schnelle Funktion
f(n,exe,I) erstellen, die:
- etwa 10 mal schneller als die Suche in Pi-Nachkommastellen ist (und auch längere Muster als 15 garantiert findet, was mit Pi kaum möglich ist)
- fast konstante Länge besitzt (Parameter I wächst nicht wie z in x^y+z;  kleine z sind ab 15 Stellen ultra selten)
- sich gut parallelisieren lässt (Parameter exe muss pro parallel laufender EXE unterschiedlich sein)
- bis zur Länge n=77 funktioniert

Hier nun die Laufzeiten, bis der Parameter I für eine n-stellige Zahl etwa gefunden wird:
n=Len(f(n,exe,I).Str) | Zeit bis zum Fund pro exe etwa
----------------------+-------------------------------
11                    | 20 s
12                    | 200...400 s
13                    | 2000 s
14                    | 20000 s = 5,5 h
15                    | 200000 s = 55 h
16                    | 555 h = 23 Tage
17                    | 5555 h = 231 Tage
18                    | 55555 h = 2314 d = 6 Jahre
19                    | 555555 h = 63 Jahre
20                    | 5555555 h = 634 Jahre
Natürlich gibt es auch so etwas wie Zufallstreffer -> aber seltener als beim LOTTO :-)  
Da sich die Laufzeit mit jeder weiteren dezimalen Ziffer verzehnfacht, werden Suchläufe
ab n > 18 jedoch extrem aufwendig :-(

Nochmalige Optimierung mit 2 weiteren Threads und 2 weiteren Suchmustern pro EXE verbesserten die Suchzeit bei n =12
von 200...400 s
auf  37...400 s.

Zusammenfassung:
Zwar würde ein mathematischer Algorithmus in/bei Spezialfällen extreme Komprimierung bedeuten, ABER universell betrachtet ist eine Suche ab 20stelligen Zahlen ultra Aufwendig. Man verschätzt sich da enorm,
da das linear denkende Gehirn solch exponentiell ansteigenden Aufwand total unterschätzt.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1083
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.19, vom Themenstarter, eingetragen 2020-04-01


So, die erste 15stellige "indirekte" Sequenz (Muster oder Teilstring)
mit meiner universellen "Spezialfunktion f(x,y)" in der behandelten dezimalen Ausgangszahl gefunden:
617958586165035 (15stellig)
f(86,503611)               12stellig
andere Formeln für diese Zahl, die aber "aufblähen" statt KOMPRIMIEREN:
85176³+10881833259         18stellig
ceil(68989187e14/11164047) 26stellig
floor((425*Pi*Pi!-69-5*Pi-596*Pi^2)/(187Pi)*1e14) 49stellig

Natürlich kann man floor & ceil durch Klammern mit "Knicken unten"
und "Knicken oben" weiter kürzen, aber das bringt nur 5 Bytes (also 21stellig).



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
hyperG hat die Antworten auf ihre/seine Frage gesehen.
Neues Thema [Neues Thema] Antworten [Antworten]    Druckversion [Druckversion]

 


Wechsel in ein anderes Forum:
 Suchen    
 
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001-2020 by Matroids Matheplanet
This web site was originally made with PHP-Nuke, a former web portal system written in PHP that seems no longer to be maintained nor supported. PHP-Nuke is Free Software released under the GNU/GPL license.
Ich distanziere mich von rechtswidrigen oder anstößigen Inhalten, die sich trotz aufmerksamer Prüfung hinter hier verwendeten Links verbergen mögen.
Lesen Sie die Nutzungsbedingungen, die Distanzierung, die Datenschutzerklärung und das Impressum.
[Seitenanfang]