Hallo, ich habe ein Programm entwickelt, welches Primzahllücken findet, z.B zwischen 2.000.000.000 und 2.002.000.000. Deklariere ich die Variablen mit Dim As ULong braucht mein Programm für das genannte Beispiel 8:28 min, bei Dim As Long nur 11 s (bei Integer übrigens nur 5,5 s). Wie erklärt sich dieser Unterschied, da doch beide Datentypen die gleiche Bitgröße belegen, nämlich 64 bit. Wichtiger noch, wie kann ich die Typdeklaration den Eingabezahlen anpassen, ohne (!) das Programm zu verändern? Wenn ich die Variablen explizit konvertiere wenn die größere Zahl < Integer.MaxValue, etwa mit Convert oder CInt, dann bleibt die Rechendauer hoch. Gibt es eine Lösung?

Mit freundlichen Grüßen von Werner

IL-Code für foo (ULong):


Dagegen bar (Long)


Wie man sieht, wird bei UL mit objekten rumgepuscht, während bei L nur elementare Operationen nötig sind.

Vielen Dank für die Antwort. Ich verstehe zwar den Zwischencode nicht, aber ich kann erkennen, dass er für ULong viel umständlicher ist als für Long. Ist ULong nun ein Werttyp oder Verweistyp (Referenztyp)? In den mit zugänglichen Büchern habe ich keinen Hinweis gefunden, dass ULong so erheblich langsamer ist als Long. Und mir ist auch unklar, was die Entwickler von VB damit bezwecken.

Da die Übersetzung des Quellcodes nun einmal so ist wie sie ist, bleibt für mich die Frage, kann ich im Programm eine zahlenangepasste Deklarierung erreichen? Ein Programm, welches Zahlen auf ihre Primeigenschaft untersucht oder die Faktoren einer Zahl errechnet, soll ja für unterschiedliche Zahlengrößen gelten. Wenn ich z.B. die Zahl 1.111.111.111.111.111.111 (19 mal die 1) untersuche (sie ist prim), macht es schon einen Zeitunterschied ob sie als Long oder ULong deklariert wird.

Viele Grüße Werner

Der Grund, warum ULong so langsam ist, ist, dass die Zahl vor der Rechenoperation in eine Decimal-Zahl umgewandelt wird.
msdn.microsoft.com/en-us/libra…m.decimal%28VS.71%29.aspx

The Decimal value type represents decimal numbers ranging from positive 79,228,162,514,264,337,593,543,950,335 to negative 79,228,162,514,264,337,593,543,950,335.

Dieser Datentyp muss mit extrem großen Zahlen umgehen und dabei noch extrem genau sein (Gleitkommazahl). Dadurch erhöht sich der Speicherverbrauch und der Prozessor braucht einige Zyklen, un Decimal-Zahlen zu berechnen. Dazu kommt noch die ständige Konvertierung von ULong zu Decimal und wieder zurück.

Zu deiner Frage: das ist nicht möglich. Du kannst aber ein Object deklarieren, dann per Long.MaxValue / ULong.MaxValue / Decimal.MaxValue usw. herausfinden wo die Zahl noch "rein passt". Dann weist du dem Object diese Zahl zu und das Object hat dann den richtigen Typ. Nach der Zuweisung ruft du deine überladene (für jeden in Frage kommenden Datentyp) Funktion auf und übergibst als Parameter CType(<Object-Variable>,Datentyp). So würde ich das machen.

lg SeriTools

Es sieht so aus als ob ULong die Addition der Decimalstruktur überlässt, also erst mal ein Objekt von Decimal erstellt (warum eigentlich, Decimal ist doch ein Werttyp?), dann Decimal.One, aslo 1 lädt, dann Decimal.Add aufruft und dann das ganze wieder in ULong zurückkonvertiert. Umständlich was? Aber anscheinend ist Decimal der einzige Typ, der mit Zahlen größer als Int64.MaxValue umgehen kann.

ich glaube ab .Net 4 gibt es einen BigInteger, ebenso sollte zu BigInteger einiges zu finden sein, z.B. zum rechnen mit Strings(natürlich nicht "1" + "2"^^)

Weki38 schrieb:

kann ich im Programm eine zahlenangepasste Deklarierung erreichen? Ein Programm,

Du könntest auf jeden Fall schon mal ZWEI identsiche Funktionen schreiben. Die eine mit L die andere mit UL. Dann wird erst die eine und danach wenn nötig die andere verwendet.