Die Mathe-Redaktion - 23.09.2019 10:01 - Registrieren/Login
Auswahl
ListenpunktHome
ListenpunktAktuell und Interessant ai
ListenpunktArtikelübersicht/-suche
ListenpunktAlle Links / Mathe-Links
ListenpunktFach- & Sachbücher
ListenpunktMitglieder / Karte / Top 15
ListenpunktRegistrieren/Login
ListenpunktArbeitsgruppen
Listenpunkt? im neuen Schwätz
ListenpunktWerde Mathe-Millionär!
ListenpunktFormeleditor fedgeo
Schwarzes Brett
Aktion im Forum
Suche
Stichwortsuche in Artikeln und Links von Matheplanet
Suchen im Forum
Suchtipps

Bücher
Englische Bücher
Software
Suchbegriffe:
Mathematik bei amazon
Naturwissenschaft & Technik
In Partnerschaft mit Amazon.de
Kontakt
Mail an Matroid
[Keine Übungsaufgaben!]
Impressum

Bitte beachten Sie unsere Nutzungsbedingungen, die Distanzierung, unsere Datenschutzerklärung und
die Forumregeln.

Sie können Mitglied werden. Mitglieder können den Matheplanet-Newsletter bestellen, der etwa alle 2 Monate erscheint.

Der Newsletter Okt. 2017

Für Mitglieder
Mathematisch für Anfänger
Wer ist Online
Aktuell sind 440 Gäste und 16 Mitglieder online.

Sie können Mitglied werden:
Klick hier.

Über Matheplanet
 
Zum letzten Themenfilter: Themenfilter:
Matroids Matheplanet Forum Index
Moderiert von Wauzi
Zahlentheorie » Primzahltests » Mögliche Untersuchung für Primzahl
Thema eröffnet 2016-02-18 09:39 von
monarch87
Druckversion
Druckversion
Antworten
Antworten
Seite 2   [1 2]   2 Seiten
Autor
Ausbildung Mögliche Untersuchung für Primzahl
stpolster
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 27.03.2014
Mitteilungen: 1009
Aus: Chemnitz
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.40, eingetragen 2016-04-25


Hallo,
ich habe mal mein eigenes Delphi-Programm zur Faktorisierung mit einem quadratischen Sieb aus dem Gesamtprojekt ausgekoppelt und es am Ende der Seite
mathematikalpha.de/faktorisierung-von-zahlen
zum Download bereitgestellt.
Vielleicht will ja jemand mal testen, wie schnell die oben genannte 80stellige Zahl auf seinem Rechner zerlegt wird. Bei mir, wie gesagt, 28 Minuten.

Beste Grüße
stpolster



  Profil  Quote  Link auf diesen Beitrag Link
Ehemaliges_Mitglied
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.41, eingetragen 2016-04-25


2016-04-25 17:33 - stpolster in Beitrag No. 36 schreibt:
Hallo Jürgen,
Nur(!) 18 min ist eine sehr starke Leistung.
Welchen Algorithmus verwendest du in deinem Programm?
Beste Grüße
stpolster

[Die Antwort wurde nach Beitrag No.34 begonnen.]

siehe www.alpertron.com.ar/ECM.HTM

Benutzt elliptische Kurven,ich hab aber keine Ahnung wie das geht. der Quelltext in Java:
www.alpertron.com.ar/ecm.zip

Ich hab das noch was modifiziert, so dass man etwa for i =
75485489758585856865486586434534537498573948700000 to
75485489758585856865486586434534537498573948800000 faktorisieren kann.
Gruß




  Profil  Quote  Link auf diesen Beitrag Link
weird
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 16.10.2009
Mitteilungen: 4952
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.42, eingetragen 2016-04-25


2016-04-25 18:16 - stpolster in Beitrag No. 40 schreibt:
Vielleicht will ja jemand mal testen, wie schnell die oben genannte 80stellige Zahl auf seinem Rechner zerlegt wird. Bei mir, wie gesagt, 28 Minuten.

Bei mir sind es mit deinem Programm 26 min 6s, d.h., da ist jetzt nicht soviel Unterschied, was die Rechnerleistung unserer Computer betrifft.



  Profil  Quote  Link auf diesen Beitrag Link
stpolster
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 27.03.2014
Mitteilungen: 1009
Aus: Chemnitz
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.43, eingetragen 2016-04-25


Hallo,
2016-04-25 20:40 - weird in Beitrag No. 42 schreibt:
Bei mir sind es mit deinem Programm 26 min 6s, d.h., da ist jetzt nicht soviel Unterschied, was die Rechnerleistung unserer Computer betrifft.
Das bedeutet wohl, dass Maple 2015 schneller ist als MSieve. Das ist sehr interessant.

Danke für den Test
stpolster



  Profil  Quote  Link auf diesen Beitrag Link
Amateur
Senior Letzter Besuch: vor mehr als 3 Monaten
Dabei seit: 01.10.2012
Mitteilungen: 826
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.44, eingetragen 2016-04-26


Hallo,

ein eigenes Programm zur Faktorisierung großer Zahlen habe ich nicht. YAFU 1.34 liefert mit 2 Threads auf einem i3-Notebook(!) für die 80-stellige Zahl folgende Ergebnisse (Median aus drei Läufen):
yafu
siqs(25389739913858345524208216151645759882986445317021182277812631082013053557679073)
 
SIQS elapsed time = 139.2044 seconds.
 
***factors found***
 
P40 = 5784129575911828826747325399392132675137
P40 = 4389552408990738265259608301074256807329

Viele Grüße A.



  Profil  Quote  Link auf diesen Beitrag Link
stpolster
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 27.03.2014
Mitteilungen: 1009
Aus: Chemnitz
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.45, eingetragen 2016-04-26


Hallo Amateur,
ich habe mir yafu-1.34 heruntergeladen und getestet.
Für die 80stellige Zahl bekomme ich

prp40 = 4389552408990738265259608301074256807329
prp40 = 5784129575911828826747325399392132675137
Lanczos elapsed time = 2.7970 seconds.
Sqrt elapsed time = 0.0320 seconds.
SIQS elapsed time = 257.7793 seconds.
Total factoring time = 318.4856 seconds

also deutlich schlechtere Werte als bei dir.
Interessant ist aber, dass im Protokoll vor dem Start des SIQS steht

==== post processing stage (msieve-1.38) ====

Sehr merkwürdig.

Beste Grüße
stpolster



  Profil  Quote  Link auf diesen Beitrag Link
Amateur
Senior Letzter Besuch: vor mehr als 3 Monaten
Dabei seit: 01.10.2012
Mitteilungen: 826
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.46, eingetragen 2016-04-26


Hallo stpolster,

möglicherweise liegt es an der Anzahl der Threads? Ich habe entsprechend der Anzahl der physischen Kerne meines i3-Prozessors explizit zwei Threads angefordert, dies aber nur im Text erwähnt und nicht im Quelltextbereich dokumentiert. Sorry. Hole ich hiermit nach. Meine Eingabe war wie folgt:
DOS-Batch
yafu-x64.exe  "siqs(Zahl)" -threads 2 > ausgabe.txt

Viele Grüße A.



  Profil  Quote  Link auf diesen Beitrag Link
stpolster
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 27.03.2014
Mitteilungen: 1009
Aus: Chemnitz
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.47, eingetragen 2016-04-26


Hallo Amateur,
Danke für den Hinweis. Ich habe jetzt 4 Threads angefordert und das Ergebnis ist

starting SIQS on c80: 25389739913858345524208216151645759882986445317021182277812631082013053557679073
SIQS elapsed time = 73.8164 seconds.
P40 = 5784129575911828826747325399392132675137
P40 = 4389552408990738265259608301074256807329

Das ist sehr beeindruckend. Eine 80stellige Zahl in etwas mehr als 1 Minute.
Da muss ich mich mit meinem Programm schämen.  frown Und ich war so stolz darauf.

Beste Grüße
ein deprimierter stpolster  wink



  Profil  Quote  Link auf diesen Beitrag Link
Amateur
Senior Letzter Besuch: vor mehr als 3 Monaten
Dabei seit: 01.10.2012
Mitteilungen: 826
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.48, eingetragen 2016-04-26


Hallo stpolster,

kein Grund zur Traurigkeit! smile
Ich selbst habe noch nie ein Programm zur Faktorisierung von großen Zahlen geschrieben, sondern statt dessen Routinen aus entsprechenden Bibliotheken oder fertige Programme benutzt. Will sagen: Hut ab!

Wegen des msieve-Eintrages habe ich mal in die docfile.txt geschaut. Dort gibt es Anmerkungen unter [nfs] (make use of msieve library calls) und [siqs] (using a port of Jason Papadopoulos's msieve filtering and block Lanczos implementations).

Viele Grüße A.



  Profil  Quote  Link auf diesen Beitrag Link
Folgende Antworten hat der Fragesteller vermutlich noch nicht gesehen.
Er/sie war noch nicht wieder auf dem Matheplaneten
juergenX
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 08.07.2019
Mitteilungen: 53
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.49, eingetragen 2019-08-24


2016-02-22 19:59 - gonz in Beitrag No. 23 schreibt:
2016-02-22 13:05 - juergen007 in Beitrag No. 20 schreibt:
Habe aber noch keine Methode zum ziehen der Wurzel (in php mit BigInteger) gefunden.

Hallo Juergen,
wenn du Addition, Multiplikation und Division zur Verfügung hast in deiner bigint implementierung, dann kannst du gut das Verfahren von Heron benutzen, um Wurzeln zu bestimmen :)

Beste Grüsse
gonz
Von mir auch:)

Um eine Primfaktorzerlegung sehr grosser Zahlen zu bekomen wollte ich die brute force methode anwenden.
Addition, Multiplikation und Division habe ich zur Verfügung. Ich starte mit einer mir vorliegenden Liste von Primzahlen bis 10 000 000 integer 32 bit.
Wenn ich nach dem ersten echten Teiler von $n>10^{20}$ schaue oder praezise den ersten Teiler von $n=65 328725 267678 906761$ suche, nur Divisionen bis zur $\sqrt{n}$ durchfuehren startend mit $m=2,3,5,7,...$ und brauche eine relativ laxe Abschaetzung eines $m >\sqrt{n}$, bei der ich abbrechen kann, denn dann ist n Prim, falls keine Division aller  $n/m$ aufing:
$\forall p<m: n\mod p \ne 0$. Bzw nicht prim wenn eine Division vorher mit Rest 0 endete.
Fuer die Naeherung eines $m >\sqrt(n)$ koennten wenige Schritte Heron genuegen. Die anderen Verfahren MPQS etc sind besser aber ich wollts eben selber schreiben in biginteger. Die mir auch die genaue PFZ der nicht prims in eine (Riesen-)array abspeichert.
Wuesste nicht ob es so was schon gibt, ne Einzeluntersuchung mit der ECM methode liegt ja vo wie oben erwähnt. aber ne ist vollstaendige Liste bis 10^20 oder so zum durchnsuche ectl sinvoller, da isch auf bereits vorleiegende Zerlegungen zurueckgreifen kann.
Wenn ich die Zerlegung von c= 123 456 789 121 weiss dann schnell die von 370370367363. und andere vielfache von c, kann mich succesive hocarbeiten.

Man kann sich fragen ob es immer sinnvoll ist bei 2 anzufangen oder eine liste Der $2,3,5,7,11,...$ teilbaren mit Erathostenes vorfertigt, so dass vorherige binaere Suche Zeit spart. eher nicht.


Anm.: Nachteil brute force sehr langsam wenn  p1 und p2 sehr nahe beieinander liegen $p1\cdot p2: 9999289 \cdot 9999299=99985780505521$.
andere Methode wäre dann die quadratische Sieb methode. Evtl kann man das multitasken.
Wenn ich beim ein oder mehrmaligen Teilen ein schonmal vorgekommene erziele bin ich fertig. Deren PFZ habe ich ja.

Warum interessiert mich das  so? Ich suche random Zahlen sehr kleiner Radikale $rad(c) << c$ was man natuerlich einfacher haben kann..um dann partitionen a+b=c auf abc tripel zu untersuchen.
Allgemein $c=2^{i_2}\cdot 3^{i_3}\cdot ..p_n^{i_n} << p_1\cdot p_2...\cdot p_n$.
bspweise $9 = 3^2=1+2^3=2+7=4+5$ ist nur 1+8 =9 ein sog. abc-tripel mit $rad(abc)=6<9$
und ander abc-tripel:
$5+27= 32$,
$rad (abc)=30<32$,
$32+49= 81$
$rad (abc)=42<81$

Was ist mit anderen Partitionen hochpotenter  "c" mit niedrigem Radikal?
wobei $ggt(a,b)=1$.
Je weniger primzahlen $p_i$ der zerlegung von c hat und je hoehere Potenzen die einzelnen Exponenten sind, desto wahrscheinlicher ist es
dass es ein a+b=c gibt so dass es ein abc-tripel ist.
Das mache ich aus Lust an Zahlenprogrammierung und mich mal wieder der herrlichen abc-Vermutung zu widmen..nachdem in dem mochizucki Beweis wohl ein Fehler ist...

ich weiss nicht ob er sich dazu äeusserte? Oder ob das noch offen ist.

Wenn wir die pfz von c=9998559 wissen und $rad(c)<c$ lohnt sich Partitionen von c zu untersuchen.




  Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 744
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.50, eingetragen 2019-08-25


Ich würde gern die 204stellige "Nicht-RSA-ähnliche" Zahl
293881793250088298254883951432018348703263903839725008584333452078564250461720415805987498495622652722421429761086686267650047941152784363166128693299636579072587976510866963036046215201586963715210261589
( die mit meinem c++ Programm und auch mit mathematica {für Carmichael-ähnliche...} nicht mal 1 s benötigt)
mit yafu testen, da
80stellige RSA-ähnliche Zahl
25389739913858345524208216151645759882986445317021182277812631082013053557679073
(Beiträge 46, 47) mit 8 threads weniger als 28 s benötigt
{mathematica weit über 3 min !}.

Aber schon ab 164stellige Zahlen meldet yafu + siqs Befehl :
"input too big for SIQS"

Wenn ich Befehl "factor(...)" verwende, dauert es mehrere Minuten
( auch www.alpertron.com.ar/ECM.HTM
benötigt weit über 22 min für die 204 stellige).

Kann man SIQS nicht doch für größere Zahlen verwenden?
Warum ist factor so viel langsamer als siqs?

Es scheinen sich verschiedene Programme auf bestimmte Zahlen-Typen spezialisiert zu haben.

Die Zertifizierung meiner letzten 6116stelligen Zahl hatte auch extreme Unterschiede:
- www.alpertron.com.ar/ECM.HTM 1 min
- PRIMO Windows 1 Thread etwa 700 Stunden
- PRIMO LINUX 20 Threads 5,2 Stunden



  Profil  Quote  Link auf diesen Beitrag Link
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 979
Aus: Thüringen,Erfurter Raum
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.51, eingetragen 2019-08-25


Ryzensystem mit YAFU

SIQS elapsed time = 20.8426 seconds.
Total factoring time = 24.4306 seconds


***factors found***

P40 = 5784129575911828826747325399392132675137
P40 = 4389552408990738265259608301074256807329

ans = 1
Das ist aber neu für mich, SIQS allein

starting SIQS on c80: 2538973991385834552420821615164575988298644531702118227781
2631082013053557679073

==== sieving in progress (12 threads):   46016 relations needed ====
====            Press ctrl-c to abort and save state            ====


SIQS elapsed time = 2.3712 seconds.


***factors found***

P40 = 5784129575911828826747325399392132675137
P40 = 4389552408990738265259608301074256807329

ans = 1



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



  Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 744
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.52, eingetragen 2019-08-25


2016-04-26 16:25 - stpolster in Beitrag No. 47 schreibt:
Hallo Amateur,
Danke für den Hinweis. Ich habe jetzt 4 Threads angefordert und das Ergebnis ist

starting SIQS on c80: 25389739913858345524208216151645759882986445317021182277812631082013053557679073
SIQS elapsed time = 73.8164 seconds.
P40 = 5784129575911828826747325399392132675137
P40 = 4389552408990738265259608301074256807329

Das ist sehr beeindruckend. Eine 80stellige Zahl in etwas mehr als 1 Minute.
Da muss ich mich mit meinem Programm schämen.  frown Und ich war so stolz darauf.

Beste Grüße
ein deprimierter stpolster  wink

Hallo stpolster,

yafu scheint sich auf "RSA-ähnliche" Zahlen mit mehreren Threads spezialisiert zu haben. (Du brauchst nicht deprimiert zu sein. Mit der 204stelligen Zahl aus Beitrag 50 kannst Du locker schneller werden)
Dei diesen 80 Stellen unter 11 s -> wirklich unschlagbar schnell:
Bat
yafu-x64.exe  "siqs(25389739913858345524208216151645759882986445317021182277812631082013053557679073)" -threads 20 > ausgabe80.txt
 
...
49495 rels found: 24941 full + 24554 from 252149 partial, (30013.41 rels/sec)
 
 
SIQS elapsed time = 10.6694 seconds.
 
 
***factors found***
 
P40 = 5784129575911828826747325399392132675137
P40 = 4389552408990738265259608301074256807329
 

Aber bei "carmichael-ähnlichen" Zahlen
( de.wikipedia.org/wiki/Carmichael-Zahl aber statt "echte Carmichael", können es auch 2 Faktoren sein)
genau so langsam.

Es zeigt sich hier sehr deutlich, dass man nicht
1 Zahl mit 1 Programm,
sondern verschiedene Zahlentypen mit verschiedenen Programmen testen muss, da sich fast jeder auf 1 Sorte spezialisiert hat.

Da die 204 Stellige Zahl aus Beitrag 50 schon mit nur 1 Thread
mit 2 verschiedenen Programmen je unter 1 s lösbar ist,
könnte ich auch noch 6000stellige Zahlen vorschlagen, damit die Unterschiede eindeutiger hervortreten.

Zwischen den "carmichael-ähnlichen" gibt es auch noch Abstufungen
beim Schwierigkeitsgrad...

Und auch bei den RSA-Zahlen, gibt es "echt harte Brocken", die bis heute nicht faktorisiert sind (hier)
und solche mit "Angriffsschwäche", die etwas leichter zu durchschauen sind...

[Die Antwort wurde nach Beitrag No.50 begonnen.]



  Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 744
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.53, eingetragen 2019-08-25


2019-08-25 22:29 - pzktupel in Beitrag No. 51 schreibt:
Ryzensystem mit YAFU

... SIQS allein

starting SIQS on c80: 2538973991385834552420821615164575988298644531702118227781
2631082013053557679073

==== sieving in progress (12 threads):   46016 relations needed ====
====            Press ctrl-c to abort and save state            ====

SIQS elapsed time = 2.3712 seconds.
***factors found***
P40 = 5784129575911828826747325399392132675137
P40 = 4389552408990738265259608301074256807329
ans = 1

Hallo Norman,

welche Parameter hast Du denn genau verwendet, dass Du mit
12 Threads 4,47 mal schneller als ich mit 20 Threads bist?

Oder gibt es da so etwas wie "Vorsieben"?
Oder was meintest Du mit "SIQS allein"?



  Profil  Quote  Link auf diesen Beitrag Link
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 744
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.54, eingetragen 2019-08-25


Ahhh,

Du hattest die exe ohne BAT gestartet und erst danach der
SIQS-Befehl gestartet -> da werden Faktoren-Arrays angelegt, bevor die Zeit läuft.

So komme ich auf:
YAFU.log
...
==== sieving started (20 threads) ====
08/25/19 23:29:11 v1.34.5 @ GL_I9, trial division touched 0 sieve locations out of 0
08/25/19 23:29:11 v1.34.5 @ GL_I9, 49496 relations found: 24941 full + 24555 from 252150 partial, using 0 polys (-1 A polys)
08/25/19 23:29:11 v1.34.5 @ GL_I9, on average, sieving found 1.#J rels/poly and 1108621.20 rels/sec
08/25/19 23:29:11 v1.34.5 @ GL_I9, trial division touched 0 sieve locations out of 0
08/25/19 23:29:11 v1.34.5 @ GL_I9, ==== post processing stage (msieve-1.38) ====
08/25/19 23:29:11 v1.34.5 @ GL_I9, begin with 277090 relations
08/25/19 23:29:12 v1.34.5 @ GL_I9, reduce to 70824 relations in 2 passes
08/25/19 23:29:12 v1.34.5 @ GL_I9, recovered 70824 relations
08/25/19 23:29:12 v1.34.5 @ GL_I9, recovered 50712 polynomials
08/25/19 23:29:12 v1.34.5 @ GL_I9, freed 24 duplicate relations
08/25/19 23:29:12 v1.34.5 @ GL_I9, attempting to build 49471 cycles
08/25/19 23:29:12 v1.34.5 @ GL_I9, found 49471 cycles in 1 passes
08/25/19 23:29:12 v1.34.5 @ GL_I9, distribution of cycle lengths:
08/25/19 23:29:12 v1.34.5 @ GL_I9,    length 1 : 24938
08/25/19 23:29:12 v1.34.5 @ GL_I9,    length 2 : 24533
08/25/19 23:29:12 v1.34.5 @ GL_I9, largest cycle: 2 relations
08/25/19 23:29:12 v1.34.5 @ GL_I9, matrix is 45952 x 49471 (7.0 MB) with weight 1450269 (29.32/col)
08/25/19 23:29:12 v1.34.5 @ GL_I9, sparse part has weight 1450269 (29.32/col)
08/25/19 23:29:12 v1.34.5 @ GL_I9, filtering completed in 4 passes
08/25/19 23:29:12 v1.34.5 @ GL_I9, matrix is 32415 x 32479 (5.0 MB) with weight 1055510 (32.50/col)
08/25/19 23:29:12 v1.34.5 @ GL_I9, sparse part has weight 1055510 (32.50/col)
08/25/19 23:29:12 v1.34.5 @ GL_I9, saving the first 48 matrix rows for later
08/25/19 23:29:12 v1.34.5 @ GL_I9, matrix is 32367 x 32479 (4.3 MB) with weight 876509 (26.99/col)
08/25/19 23:29:12 v1.34.5 @ GL_I9, sparse part has weight 798813 (24.59/col)
08/25/19 23:29:12 v1.34.5 @ GL_I9, matrix includes 64 packed rows
08/25/19 23:29:12 v1.34.5 @ GL_I9, using block size 12991 for processor cache size 14080 kB
08/25/19 23:29:12 v1.34.5 @ GL_I9, commencing Lanczos iteration
08/25/19 23:29:12 v1.34.5 @ GL_I9, memory use: 3.9 MB
08/25/19 23:29:13 v1.34.5 @ GL_I9, lanczos halted after 513 iterations (dim = 32365)
08/25/19 23:29:13 v1.34.5 @ GL_I9, recovered 15 nontrivial dependencies
08/25/19 23:29:13 v1.34.5 @ GL_I9, prp40 = 5784129575911828826747325399392132675137
08/25/19 23:29:13 v1.34.5 @ GL_I9, prp40 = 4389552408990738265259608301074256807329
08/25/19 23:29:13 v1.34.5 @ GL_I9, Lanczos elapsed time = 1.3440 seconds.
08/25/19 23:29:13 v1.34.5 @ GL_I9, Sqrt elapsed time = 0.1090 seconds.
08/25/19 23:29:13 v1.34.5 @ GL_I9, SIQS elapsed time = 1.7027 seconds.
 

1.7 s -> mit diesen (Teil-Faktoren schon im RAM)
also 6,27 mal schneller als mit BAT (Erst-Start)



  Profil  Quote  Link auf diesen Beitrag Link
Seite 2Gehe zur Seite: 1 | 2  
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-2019 by Matroids Matheplanet
This web site was made with PHP-Nuke, a web portal system written in PHP. 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]