2021-04-12 18:45 - Kezer in Beitrag No. 5 schreibt:
... ans Herz legen, die Definition einer (mathematischen) Funktion zu wiederholen/studieren.
Genau darum geht es ja gerade, dass jeder Professor denkt, dass seine Definition eindeutig sei! Für "seine Gedankenwelt" mag es auch stimmen, ABER sobald man auch nur etwas abweicht, werden Zeichen & Symbole anders verwendet! Schon innerhalb der Mathematik (Statistik anders als Mengen-Logik usw.)
Ich könnte Dir zig Beispiele nennen, dass sie - über ALLE Wissenschaftsgebiete - nicht eindeutig sind!
| mal "Teiler von", mal "Menge oder Klasse der Elemente ..., die die Bedingung ... erfüllen
x mal Produkt-Symbol, mal kartesisches Produkt, ...
\ mal Differenz der Mengen ... und ...; mal floor(.../...)
|...| mal Absolutbetrag; mal Mächtigkeit, mal Determinante ,...
...
Sobald man "echt wissenschaftlich" arbeitet und mehrere Wissenschaftsgebiete ohne starres Schubfachdenken verbindet, darf es keine Missverständnisse oder Inkompatibilitäten geben!
Dann die oft "in der Luft hängenden Variablen". Für Mathematiker in ihrer Gedankenwelt reicht das (wird oft als "für alle").
Eine Möglichkeit für mehr Eindeutigkeit für ein Algorithmus ist oft der Pseudocode.
Er könnte in diesem Fall etwa so aussehen (wenn ich alles richtig verstanden habe):
Pseudocode
geg.: aA =Array{...} mit n Gliedern
n=Len(aA)
prod=1
if (aA[n]>n)or(aA[n]<1) return Err
for k=1 to n-1
if (aA[k]>n)or(aA[k]<1) return Err
for j=k+1 to n
if aA[j]==aA[k] return 0;
prod*=(aA[j]-aA[l])/(j-k)
next j
next k
return prod
2021-04-12 17:59 - Kezer in Beitrag No. 3 schreibt:
...
Sowas wie "fehlende Zahl" gibt es nicht.
Doch, in der exakten Definitionswelt gibt eine sauber definierte Funktion für undefinierten "Zweig" Error {sauber definierter Abbruch} zurück.
(Um Abstürze oder Endlosschleifen zu vermeiden)
Für beide verbal formulierten Teile
- "1-Schritt-Vertauschungen 2er Glieder bis Muster ... erreicht"
- "für alle p,q mit der Eigenschaft ... wende Funktion ... an"
gibt's bestimmt auch bessere Funktionen...
Das habe ich selbst im Wiki-Beitrag NICHT gefunden.
Soll das bedeuten:
f(9,8,7)=Error? {da nicht definiert}
Außerdem bedeutet eine Aufzählung {Spektrum-Version} in einem Case-Verteiler mit Komma normalerweise "UND"
Die engl. Wiki-Version spricht aber von ODER!
Allein das zeigt, wie schwammig das alles ist & dass sich allein schon diese beiden Artikel widersprechen!
Ich habe selbst studiert & immer wenn was Schwammig war, habe ich nachgefragt. (Professoren kürzen gern ab)
Das p & q steht weiterhin offen zur Frage.
Wenn das alles so einfach ist, wie sieht's mit fehlender Zahl aus?
Also f(3,2,1,5) -> auch Error?
Dann die Definition von "Vertauschung": immer 2 Glieder?
Also f(3,4,1,2)
Weiter unten wird dann ein Beispiel genannt:
"Anzahl der nötigen Vertauschungen, um das Zahlenmuster {1,2,3} zu bekommen" -> also habe ich das so verstanden:
\ \epsilon(i,j,k)=cases(0,i=j=k;((''Anzahl der nötigen Vertauschungen, um das Zahlenmuster {1,2,3} zu bekommen''+1) mod 2)*2-1,sonst)
Aber was ist mit
\ \epsilon(9,8,7)
? Denn selbst mit unendlich vielen Vertauschungen bekomme ich damit kein "Muster" {1,2,3} hin...
In der engl. Version unter en.wikipedia.org/wiki/Levi-Civita_symbol
steht dann wieder was von i==k OR j==k
ABER auch nicht von dem Fall: eine Variable hat einen Wert größer 3
Habe Matrix nochmals vergrößert und innerhalb der DLL eine weitere Zeitmessung eingebaut, um die einzelnen Teile genauer zu wichten:
Mathematica
...
Mathematica mit Zeilen=1600 in 4.8113637 s (20Threads)
##########################################################
ToString-Zeit= 2.0932562 s für Stringlänge=50724392Out[60]= 130447345940674970221040119937474534622|134141310587451575514436998016498418451|132434804116790553911875000497573729388|132444398777051631491804143650344953404|148230478352533030088373115458006404763Gesamt= 24.2130332 s; interne DLL-Schleifen: 23.65 s (1Thread)24.213-23.65=0.563 s für Übertragung +Wandlung+Speicheranforderung+Rückwandlung +Speicherfreigabe+Wertrückgabe
Solch 39stelligen Zahlen sind schon gewaltig.
Bei den bereits optimierten Dot-Befehlen lohnt es sich natürlich nicht.
Dann doch gleich "nur ToString", was bei mir 1.15 s dauert.
Den Replace-Teil, der bei Mathematica 0.9 s dauert,
lasse ich dann in der DLL in 0.03 s erledigen.
Die Stringlänge vergrößert sich auf 28533074 Zeichen.
Grüße Gerd
P.S.: Die vergrößerte Stringlänge ist schon in den 0.03 s mit enthalten.
Effektiv verbessert sich also mit "nur ToString" die Wandlungsgeschwindigkeit um den Faktor 4 s/(1.15 +0.03 s)=3.39 !
Super, dass wir zusammen auch hier bei der 28 Mio. Bytes Übertagung noch was herausholen konnten.
P.S.: @StrgAltEntf:
Folgender Teil Deiner "expliziten Funktion" verstehe ich nicht & er ist bestimmt auch für viele andere missverständlich:
\(\max\{k~:~2^k\mid n\}
\)
Variable k hängt für mich im "undefinierten Raum" und "|" kann alles mögliche sein (vermutlich was mit "Teiler" -> aber welche von Wem?).
Kannst Du das mit verständlichen Funktionen ausdrücken
(die wenigstens WolframAlpha oder Mathematica versteht)?
Oder soll das eine umständliche Umschreibung von ggT sein?
2021-04-08 16:15 - Primentus in Beitrag No. 15 schreibt:
Hallo hyperG,
... Strings mit 9000 Zeichen realisiert hast. Es wundert mich nur, dass Du sagst, Dir genügt das schon. Bei den Datenmengen, die ich sonst von Dir kenne, dachte ich eher an Strings mit mehreren Millionen Zeichen....
LG Primentus
Also gut: Matrix mit 1200 * 1200 uint128 Zahlen = 27091438 Zeichen
Mathematica V12 schlägt sich hier sehr gut mit 2.14 s, weil ALLE 20 Kerne einbezogen werden!
Hingegen benötigt die einfache Array -> String Konvertierung schon 4 s !?!
Kann man
mathematica
A={{12, 345}, {14567099999987654321, 11304444444444444441}};
StringRiffle[Flatten[A], ","]
out
12,345,14567099999987654321,11304444444444444441
noch beschleunigen?
Meine Wandlung mit 1 Kern wandelt {String -> uint128-Array} + rechnet {Matrix-Mul + 128Bit-ToString + sb2@ToString[]} dann zusammen in 6.67 s
Gestern habe ich nun endlich Strings als Übergabetyp hinbekommen, ohne den komplizierten Umweg
-> MakeNETObject -> Marshal`Copy -> NETObjectToExpression
gehen zu müssen: sb2 = NETNew["System.Text.StringBuilder", (Anzahl der maximal möglichen Stringzeichen)+1]
Bei 9000 Zeichen habe ich aufgehört, das reicht mir -> super schnell!
Diese neue Technik mit der 128-Bit-Welt von cpp (g++ Compiler) verbunden
-> und schon ist man bis zu 80 mal schneller! (alles noch ohne Multithreadding & ohne AVX)!
Wichtig bei Geschwindigkeitstests: kleinste Vergleichsgeschwindigkeit sollte 1 s nicht unterschreiten, da sonst
Schwankungen & Daten-Übergabetechnik mehr Wichtung als eigentlich zu vergleichende Berechnung bekommen.
Als ich weiter testete, war Mathematica manchmal nur 63 mal langsamer. Ob das nun am Cache oder an den Zwischenergebnissen
lag (die ja auch mal in den schnellen 64-Bit Bereich fallen), kann ich nicht sagen.
Mit "AMD ignoriert" meinte ich nur AVX512! AVX (256 Bit) gibt es schon über 10 Jahre & AVX2 (256 Bit Mul + add zusammen)
mindestens 5 Jahre auch bei AMD.
Nun fängt Intel sogar an, die AVX512 bei der 10. Genaration zu verändern (AVX512IFMA52), so dass diese selbst auf meinem i9 (AVX512F) nicht mehr laufen.
Was für eine kurzlebige Zeit...
2021-04-07 00:18 - Primentus in Beitrag No. 10 schreibt:
... Restriktionen der C-Datentypen liegt, weil Mathematica kann ja an sich schon mit extrem großen Zahlen arbeiten.
...
Große Zahlen ja, aber da gibt es einen sprunghaften Unterschied, sobald man die "Grenzen von double & int64" überschreitet -> dann wird intern mit Hex-Arrays gerechnet, die bei Konvertierung in dezimale Ausgaben einen großen Umrechnungs-Zeitanteil beanspruchen.(aber beim Timing ignoriert werden -> deshalb nutze ich immer AbsoluteTime[] Differenzen für meine Zeitmessungen!)
Genau mit dem internen 127-Bit Zwischenergebnis konnte ich ja überhaupt erst die 38 fache Geschwindigkeit erreichen. Mit dem Datentyp uint128_t (den einige c-Compiler optimiert haben) kann man schön einfach Programme erzeugen (im Gegensatz zu anderen Typen wie in GMP & YMP).
Den größten Unterschied hatte ich ja hier im Forum schon vorgestellt:
Matrix-Multiplikation großer Datenmengen:
- ab Version 12 mit double & 10 Kernen super schnell {leider hat Mathematica nur diesen einen Dot-Befehl optimiert}
- nur 2 Stellen mehr (z.B. N[,18]) -> über 1000 mal langsamer & nur 1 Kern!
2021-04-07 00:18 - Primentus in Beitrag No. 10 schreibt:
...
Zum Beispiel wenn man 2 hoch 100.000.000 und 3 hoch 100.000.000 nimmt und beide Zahlen multipliziert, ermittelt Mathematica in weniger als 30 Sekunden, dass das Ergebnis eine Zahl mit 77815126 Dezimalstellen ist und gibt dabei noch z. B. die 11 Ziffern ab der 50000000. Dezimalstelle aus...
Dein "weniger als 30s" kam mir langsam vor :-)
Also meine Tests:
a) kostenlose Cloud -> This computation has exceeded the memory limit for your plan.
b) i9 mit V12: in 17.3865196 s
Das geht selbst mit Mathematica schneller, da ja wie oben beschrieben die Wandlung von hex nach dez einen großen Teil der Zeit ausmacht!
Also erst alles hex berechnen -> und dann nur die 11 Ziffern nach dez ausgeben:
mathematica
Quotient[Mod[2^100000000*3^100000000, 10^(77815126+1-50000000)],
10^(77815126+1-50000000-11)]
c)Cloud: 12.0 s
d) i9 V12: 3.13 s
Selbst mit "mehr drumherum" (gewünschte Position; Berechnung der Stellenanzahl; Ausgabe führender Nullen mit PaddedForm[] usw.) bleibt es bei 3.13 s
Mit YMP wird das dann nochmals um einiges schneller und man kann mit genug RAM in Zahlenbereiche vordringen, die so schnell keine andere Software berechnen kann. -> das wäre mal eine schöne Knobelaufgabe :-)
Auch bei YMP macht die hex -> dec Wandlung viel Zeit & RAM aus (bei etwa 20 Mrd. kam ich dann selbst mit 32 GB an die Grenzen).
Wenn nur so um die 11 Stellen nach dec gewandelt werden müssen, sollten mindestens Zwischenergebnisse bis 50 Mrd. drin sein.
Wenn ich Zeit habe, werde ich endlich den String als Übergabetyp für DLLs angehen...
In der Praxis scheint der Datentyp uint128 selten aufzutauchen.
Gerade Grafikkarten reduzieren eher die Stellenanzahl und rechnen nur mit single statt double...
Auch bei den AVX-Befehlen ist bei double oder int64 Schluss :-(
Bei AVX512 können zwar viele "kleine Datentypen" parallel berechnet werden:
__m512i _mm512_mulhi_epu16 (__m512i a, __m512i b)
berechnet
Pascal
FOR j :=0to31
i := j*16
tmp[31:0]:= a[i+15:i]* b[i+15:i]
dst[i+15:i]:= tmp[31:16]
ENDFOR
-> also 32 Multiplikationen (je 16 Bit) mit einem einzigen Maschinenbefehl!
Aber bei double & int64 ist Ende:
__m512i _mm512_mullox_epi64 (__m512i a, __m512i b)
FOR j := 0 to 7
i := j*64
dst[i+63:i] := a[i+63:i] * b[i+63:i]
ENDFOR
und so richtig habe ich noch keine praktischen Anwendungen gefunden... Außerdem ist das Einsammeln (und Ausgeben) der vielen Variablen in AVX-Register zeitfressend...
AMD ignoriert diesen Typ selbst bei den neusten CPUs komplett.
ich habe meine ASM-Funktion MulMod mit 127.1 Bit Zwischenergebnissen in eine cpp-DLL eingebunden.
Damit habe ich dann eine schöne Iterationsschleife gebastelt, um die DLL-Aufrufe zu minimieren.
Zusammen mit Deinem Beispiel 2 "Compile,...CompilationTarget -> "C"
haben wir nun 4 schöne Ergebnisse:
a) Mio. DLL-Aufrufe über Umweg .NET sind "grotten" langsam
b) Mathematica mit 1.18 s war ja die Referenz
c) die optimierte DLL mit 1 Aufruf schafft es 38 mal schneller!
(mit dem LINUX-Code könnte ich noch schneller werden und die 128 Bit als internes Zwischenergebnis voll ausreizen!... und meine 20 Kerne voll nutzen!!)
d) "Compile" bringt hier bei diesen großen Zahlen nichts. (etwas langsamer; )
Zu den Strings als Rückgabeparameter bin ich noch nicht gekommen.
Die müssen nicht mal groß sein. Ich dachte wie im Beitrag 1 an die StringSplit[] Funktion, also DLL-Ausgabe:
"123|456|... n Elemente |999".
Dann könnte ich 128-Bit Zahlen relativ einfach ohne NETObject übergeben und in c direkt damit rechnen...
Den Datentyp bei DefineDLLFunction konnte ich nun auf "UInt64" erweitern, womit nun statt 2^31 - 1 auch bis 2^64-1 übergeben werden kann!
Während der Berechnung läuft ein 2. Kern beim DLL-Aufruf unter Wolfram.InstallableNET, was bei extremer Häufung (1441619 mal) alles verlangsamt:
mathematica
startT0=AbsoluteTime[];
a64=18446744073709451639;Table[a64=Mod[k*a64,10000000000000000051],{k,18446744073309551000,18446744073310992619}];
Print[k, " | ",a64," in ",AbsoluteTime[]-startT0," s"];
k | 4365759282222754366 in 1.1872199 s
DLL:
startT0=AbsoluteTime[];
a64=18446744073709451639;Table[a64=MulMod64[k,a64,10000000000000000051],{k,18446744073309551000,18446744073310992619}];
Print[k, " | ",a64," in ",AbsoluteTime[]-startT0," s"];
k | 4365759282222754366 in 169.4125134 s
Man muss dann alles in c optimieren und die Aufrufe minimieren...
vielen DANK!!! Genau so ein Code habe ich gesucht!
Nicht nur, dass da ein VS Solution-File dabei war (einfach 32- oder 64-Bit, oder Debug/Release-Umschaltung), sondern auch noch der Syntax vom Doppel-Pointer für beide Welten (cpp & Mathematica).
Transfer + Berechnung + Zeichnung von 1000 Werten sank von 27.86 s
auf 2.39 s (Bild links) !
Wenn man ein ganzes Array von 1000 "DismalLunarPrimzahlen" mit 1 Funktionsaufruf überträgt
(nicht verwechseln mit "echten Primzahlen"; auch die Summe dieser ist nicht LunarPrimePi !)
dauert es incl. 2 maliger Wandlung + Ausgabe nur 0.2 s !
Allerdings ist der Umweg mit
- NetNew -> Funktionsaufruf -> MakeNETObject -> Marshal`Copy -> NETObjectToExpression
schon höchst umständlich, bis man endlich Mathematica-Befehle anwenden kann. Der RAM-Verbrauch steigt damit etwa um das 4fache...
Wenn ich das mit längeren Strings hinbekomme (kurze gehen schon),
kann man sich den kompletten Umweg über NET... schenken.
Dein Run ist ja ähnlich zum
ToExpression@RunProcess[{$LunarArithmeticRuntimePath,"mul",ToString...
was mir aber zu langsam ist.
Auch vom CUDA bin ich etwas enttäuscht, da es oft langsamer als meine schnelle CPU ist.
Alles was mit internen Compiler zu tun hat, bring nur sehr selten Vorteile. Die parallelen Code-Beispiele funktionieren meist, aber sobald man etwas abweicht, erreicht man oft nicht mal Geschwindigkeitsfaktor 2.
Was für mich das meiste Potential hat, ist die unter Beitrag 1 & 2 vorgestellte
DefineDLLFunction
wo ich meine selbst optimierten Cpp DLL einbinden kann:
- 128 Bit Ganzzahl Technik (da wird Mathematica schlagartig langsam)
- AVX2 & AVX512, was nur wenige Compiler & Assembler können
- Multitasking
- YMP Bibliothek (besonders ab 1 Mio. zig mal schneller )
- keine Verzögerung beim Starten von Prozessen (mit Run...)
Also eine Zahl mit fast 2*10^619 (2E619) Stellen.
Da das Weltall nur etwa 10^80 (1E80) Atome hat, kann man sie nie in Dezimalschreibweise ganz exakt aufschreiben!
PowVG[n]=A173566[n+1]
da ich den Index 0 auf Funktionswert 2 festgelegt hatte.
A173566[0]=e^ProductLog(log(2))=1.559610469462369349970388768765002993284883511843...
Wenn der Startwert statt 2 eine 10 ist:
10
10^10
(10^10)^(10^10)=10^10^11
ähnelt sie en.wikipedia.org/wiki/Double_exponential_function
aber das wäre 10^10^n (steigt also langsamer) als gewünscht...
Home / Seite ohne Frame
Wie unterstütze ich den Matheplaneten mit Geld?
