Deshalb DNSTunnel - Resolver lösen manchmal noch im Internet auf auch wenn der Anschluß gesperrt wurde wegen VoIP (man muß ja anrufbar bleiben)!

sehe gerade eien fehler im code natürlich (rnd % RND) und wundere mich
das ist aber gar nicht mein fehler! -> manipulierte zwischenablage.

NACHWEIS der Manipulation des Systems: code nachher gegen code vorher!

ES FEHLT DIE KOMMENATRZEILE

// TESTEN WIR DAS MAL MIT NER ZAHL DIE GROESSER IST!

MAL BAGESHEN DAVON DAS MAN DAS NICHT TESTEN KANN WEL RAND NICHT DAS LIEFERT WAS ES SOLL.

~~~

Das ist regelrecht fahrlässig.

Wenn ich eien Zahl zwischen 0 und 61 (26 Kleinbuchtsaben [a-z], 26 Grossbuchstaben [A-Z] und 10 Ziffern [0-9] das sind insegsdamt 26+26+10 Zeichen 62 Werte also wie gesagt eine Zahl zwischen 0-61) udn mein Zufallszahlengenerator leifert mr eien vie zu grossen Wert dann kann ich entweder den Zufallszahlengenrator so lange neue Zhalen generieren lassen bis die ausgespucke Zahl zufällig mal in den Bereich >= 0 und <= 61 fällt oder ich teile den Wert auf - Was aber totaler Unfug ist:

nehmen wir an die  ausegegbene zahl wäre 7442 (integer divided/geteilt) durch 61 ist das 122 udn 122 ist unebstreitbar doppelt so vile wie 61.
nach http://www.codingunit.com/c-reference-stdlib-h-function-rand-generate-a-random-number wäre aber 122 <= 61!

richtig ist sich eien algo zu suchen basteln der das sol lange teilt (oder halbiert) bis der wert passt. den wert durch den gesuchten wert zu teilen statt zu halberen udn dann immer zu schaune ob er shon eien zahl im angegebenen fenster zwichen 0 udn 61 ausgibt macht sinn weil dann aller voraussicht nach kein Rest anfällt.

~~~
ein für ausführungsgeschindigkeit optimierter  algorythmus würde eine GEFUDENE_ZUFALLSZAHL zwischen RAND_MAX und GESUCHTER_WERT so lange halbieren bis er in die nähe der gesuchten zahl kommt (gesuchte zahl * 2) das ist schneller falls die ausgangszahl sehr groß ist. (eine mischform aus halbieren (gegenteil von POW ?= quadratwurzel ?) aber das lohnt hier den aufwand nicht.
~~~
Das aus der drocku funktioniert in shell-scripts rein zufälig wenn man die ausgeba nachher in ein %c character oder Pascal Datentyp Byte packt.Da sorgt dann das printf fürs random indme es durch wrapover des seicherbreichs teilt . das ist imshellscript also wurst.

nächster Screenshot (ich wundere mich eben noch daß da ein fehler drinne =< satt <= ist) und nien, das ist kein abgestürztes SqaushFS.   Das ist ANGEBLICH Debian auf ANGEBLICH VMWare.

UND nein, ihr Deppen das ist richtig wie ich das geschrieben hatte. nicht der schnellste code aber der zuverlässigere (durch das teilen druch %61 geht weniger von dem ?genrierten zufall? verloren weil das bei der extrem grossen zahl die anfangs geteilt wird ein wert von 0-61 der durch die intgere division als modulus verlorengeht in realtion zum urprungswert gerinegr ausfällt als wenn ich nachher druch zwo teil udn mir die hälfte der enthrpy flöten geht.).

Es gibnt mehrer Löäsungen. Immer. und die Frage wenn man wurzeln zieht (halbiert) ist immer ob man am dene nicht viel zu kleine zahlen bekommt weil dann das ergebnis daß in den range passt egrebnis eienr halbierung egwesen wäre. der STREUVERLUST ist also erwartunsgemäß höher wenn ich die halbe nerophie bei der zeilwertsuche verliere, ich erwarte für eien solche auf gechwindigkeit optimierte funktion nur kleinere zahlen im ergebis weil dei oebre häfte des zufallswerts wahsrcheinlich verloren geht.

?MEIN ERGEBNIS IST SOGAR RICHTIGER/BESSER ALS DAS DES VEBRÖLDETEN ?BESSERWISSERS?

wenn ich von zwo metern 1 cm abschneide ist das im verhältnis weniger als wenn ich zwo meter halbiere (nur noch eien meter habe) udn dann davon 1 cm abschnide. die funktion die der edv lehre nutzenwolte ist shcnell aber ungenau. ICH BIN DOUBLE PRECISION.

. das ist also mehr als nur grober unfug was die da angeblich wieder zu optimieren versuchen. die frage kannauch niemand weiklich beantworten wei es um zufallszahlen geht. man lönnte nur einen veruchriehe oghne jegliche aussgekrfat dazu machen. (weil dei eingasparameter nicht wiederholbar wären). ABER WIRD HABEN JA EIN DEFEKTES /DEV/RANDOM (das man auch nicht einfach augf de7c/tty udn falsl da niemnd sitzt /dev/eth linken könnte)

Defektes Rand() udn wennder code als ?Workaraound? daran angepasst soll das dann wieder falsch sein. Wenn kein leder lieferbar ist und die autobezüge mit stoff bezogen werden dann ist das auto dank dieses wojkaurounds tortzdem fahrbereit. das wäre ein workaraound (begriffserklärung). das umegehn eiens problems.

https://de.wikipedia.org/wiki/Streamer  Qic-80
https://de.wikipedia.org/wiki/Quarter-Inch_Cartridge

RANDOM Basic/Pascal/glibc

Das rand der glibc erezugt anders als das in (pascal oder) basic keien wert zwischen 0 und 1 sondern einen wert zwischen 0 und RAND_MAX! Das was sie sagen das man einen Wert mal 10 irgendwas nimmt wenn man eine Zufalls.zahl von 0-10 haben will und dann integer druch 1 teilt um den rest wegzubekomment stimmt nur für Basic und/oder Pascal.

weiteres problem die funktion rand() ezeugt eine wert und wenn der erneut ausgelesen wid ist ist es ein anderer, wenn er das dritte mal wieder ausgeslen wird wieder der erste. das hat nichts mit eienr fehelnden intialisierung zu tun (randmieze in basic und/oder pascal)? dannwären alle drei werte derselbe.

typecasting? Wen ich eien belibigen Wert als

printf (?%c?, rand());

nutze erledigt das wrapover den job zwischen 0 und 255!

http://www.javacoffeebreak.com/faq/faq0047.html

das ist aber nicht genauso präzise wie meine lösung. denn es macht eien prozentualen unetrschied ob ich von 2 m Zufall 1 cm wegnehme oder von 1 m 1 cm meines ist sozusagen double precision

http://www.freepascal.org/docs-html/rtl/system/random.html
https://github.com/lattera/glibc/blob/master/stdlib/random_r.c
https://en.wikibooks.org/wiki/BASIC_Programming/Random_Number_Generation

das dürfte sein was sie meienen sie lösen das druch kommaverschiebung

das funktioniert aber nur wenn sie von 0 bis 9 gehen und wenn sie
würfel immitieren wollen 1-6 satt 0-9 dann haben sie einen verlust
von 0 und 7-9 (das sind 40% ungenauigkeit).

0 bis 10 // 10 = anzahl vorkommastellen

r = ((double) rand() / (RAND_MAX)) * 10;

schönen gruß, ?DER TELLERWÄSCHER?!


https://de.wikipedia.org/wiki/Entropie_%28Informationstheorie%29

jetzt kommt noch hinzu daß RAND_MAX eine 2^irgendwas ist wenn sie elektronsich ist also 2,4,88,16,32,64,128,256 ?das beduete daß sie aller voraussich nach keien wert von 0-9 herausgibt sodnern einen der nach oben im integer, oder float bereich begrenz tsit. ein byte wären 456 möglihckiten von -127 bis +128 aber eben nicht von 0-100. auch deiser rest wird übersehen was die Entropie angeht.

ist in jeder Sprache so hie rmal java

http://openwritings.net/content/public/java/boundaries-primitive-data-types-java

Datatype LONG ist definiert von

min = -9,223,372,036,854,775,808 , max = 9,223,372,036,854,775,807

und nicht von

min = -9,999,999,999,999,999,999 , max = 9,999,999,999,999,999,999 

das bedeute allein weil jede compzterspeichergenze ein potenz von 2 ist
werden warscheinlich die zahlen von 9,223,372,036,854,775,808 bis 999,999,999,999,999,999 (potitv wie negatiuv) unterschlagen was die
entropie angeht.

Wäre die Entropie normalvertelt wären die punkte auf der RANDOMART gleichmässig verteilt nehme ich mal an.

hier das problem. http://superuser.com/questions/22535/what-is-randomart-produced-by-ssh-keygen nur weil rand / RAND-MAX gut aussieht als code ist es nicht richtig. 


DROP BEER (bring bier mit vorbei) schreibt sich mit EE und nicht
mit EA.