Zufall in Pure Basic"programmieren"

[Little John]

Noch ein kleiner Zusatztipp:
Ich würde Random(99)+1 nehmen, das ergibt Zahlen von 1 bis 100 statt von 0 bis 99. Das ist in diesem Zusammenhang etwas übersichtlicher.

Code: Alles auswählen

Select Random(99)+1
  Case 1 To 20
     MessageRequester("zufall","die 20% chance ist eingetroffen")
  Case 21 To 30
     MessageRequester("zufall","die 10% chance ist eingetroffen")
  Case 31 To 100
     MessageRequester("zufall","die 70% chance ist eingetroffen")
EndSelect

Gruß, Little John

[Special-Agent-J]

woah danke so ist es gleich viel leichter verständlich

[STARGÅTE]

jo das soll jeder selber entscheiden, ich fange meistens bei 0 an, und das nicht nur weil es bei den Programmiersprachen immer bei 0 losgeht (Stichwort: Array, usw.) sondern auch weil man es im täglichen Leben auch so macht:

Der Tag fängt ja auch bei 0h:00m:00s an und endet bei 23h:59m:59s
Die Unterteilung in zwei Hälften wäre dann:
0h:00m:00s bis 11h:59m:59s und 12h:00m:00s bis 23h:59m:59s

Aber wenn es dir Leichter fällt von 1 bis 100 zu gehen, dann mach es halt so ...

[Kaeru Gaman]

auch wenn es verwirrend scheint, eigentlich ist das bei 0 anfangen intuitiver.

z.B. fängt die zählung der Jahre beim Jahr 1 an, es gibt kein Jahr 0.
das führt dazu, dass das 20te Jahrhundert Anfang 1901 angefangen hat,
das dritte Jahrtausend begann Anfang 2001, usw.

spontan sagt jemand, der sich das nicht explizit gemerkt hat,
"das Jahrhundert beginnt 1900, ist doch logisch"

wenn man mit 0 zu zählen beginnt, dann stimmt das auch.

[Little John]

> und das nicht nur weil es bei den Programmiersprachen immer bei 0 losgeht (Stichwort: Array, usw.) sondern auch weil man es im täglichen Leben auch so macht

> auch wenn es verwirrend scheint, eigentlich ist das bei 0 anfangen intuitiver

Das kann man nicht so allgemein sagen, sondern es kommt immer auf die Situation drauf an. Wenn z.B. Bauer Hansen zählen will wieviel Kühe er hat, wird er ganz sicher nicht bei 0 anfangen. Ebenso ist es bei Hausnummern u.v.m. Mit 0 zu beginnen ist v.a. sinnvoll bei Offsets (Addierwerte), d.h. bei Abständen von irgendwas (z.B. Speicheradressen). Es kommt also immer auf den Zusammenhang drauf an.

Es ist keine Frage, dass ein geübter Programmierer kein Problem damit hat, immer und überall bei 0 anzufangen zu zählen, aber das kommt v.a. daher, dass er es gewohnt ist und nicht weil das immer die intuitivste und für Ungeübte die einfachste Zählweise ist.
Warum wohl schrieb Special-Agent-J
> woah danke so ist es gleich viel leichter verständlich
?

Gruß, Little John

[KeyKon]

Warum wohl schrieb Special-Agent-J
> woah danke so ist es gleich viel leichter verständlich

Klingt für mich doch sehr sarkastisch...

[Kaeru Gaman]

... ich glaube nicht, dass das sarkastisch war...

@Topic
hier noch ne kleine Procedure für ein Ereignis mit Prozentualer Wahrscheinlichkeit.

siehe unten

[STARGÅTE]

@Kaeru Gaman

Das ist glaube ich falsch das da n Random(100) , weil es ja dann jedes mal 101 Möglichkeiten gibt

Beweis:

Code: Alles auswählen

Procedure.i YesNoPercent( Percentage.l ) 
Protected Result.i 
  If Percentage <= 0 
    Result = #False 
  ElseIf Percentage >= 100 
    Result = #True 
  Else 
    If Random(100) <= Percentage 
      Result = #True 
    Else 
      Result = #False 
    EndIf 
  EndIf 
  ProcedureReturn Result 
EndProcedure

For n = 1 To 10000
 If YesNoPercent(1)
  v + 1
 EndIf
Next
Debug v/10000.0

hier bekommt man ca 0.02 heraus also 2% statt 1% wie wir wollten
liegt daran das bei 1 die 0 und die 1 als TRUE durchgehen ..

Es muss also Random(99)+1 sein


EDIT: oder so ^^ das du immer so schnell Editierst


EDIT 2 also das nachfolgende:

Bei mir steht ja auch WENN DANN Random(99)+1 wenn es <= ist !

[Kaeru Gaman]

du antwortest einfach zu schnell xD

hier die verbesserte Version:

Code: Alles auswählen

Procedure.i YesNoPercent( Percentage.l )
Protected Result.i
  If Percentage <= 0 
    Result = #False
  ElseIf Percentage >= 100
    Result = #True
  Else
    If Random(99) < Percentage
      Result = #True
    Else
      Result = #False
    EndIf
  EndIf
  ProcedureReturn Result
EndProcedure

Yes = 0
No = 0
Perc = 64
For n=0 To 99999
  If YesNoPercent(Perc)
    Yes +1
  Else
    No +1
  EndIf
Next

Debug "Ergebnis: "
Debug Str(Perc)+"% Soll-Wahrscheinlichkeit"
Debug Str(Yes)+" Yes, "+Str(No)+" No"
Debug StrF(Yes/1000,2)+"% Ist-Wahrscheinlichkeit"

mit Random(99) hast du recht, aber die Bedingung muss "<" heißen, nicht "<=".
der statistische Test belegt das.

PS:
ich hatte erst überlegt, eine Float als Argument zu akzeptieren und
mit 2 oder 3 Nachkommastellen zu arbeiten für die Eingangs-Prozente,
aber das ist überflüssig, weil die tatsächliche Verteilung sowieso schwankt.

[STARGÅTE]

Ist jetzt vllt ein bisschen OFFTOPIC,
aber mit Hilfe von meinem DimP kann mann dann auch sowas hier basteln:

ACHTUNG, Code erfordert das Macro aus dem Link oben

Code: Alles auswählen

Procedure SpecialRandom(DimP(Percent, 0))
 Protected Random = Random(99)
 Protected Delta, n
 For n = 0 To 15 
  If Random < Delta+Percent(n)
   ProcedureReturn n+1
  EndIf
  Delta + Percent(n)
 Next
 ProcedureReturn 0
EndProcedure

Dim Test1(3)
For n = 1 To 10000
 Ergebnis = SpecialRandom(60, 20, 15)
 ; Erzeugt ein Ergebnis was zu
 ;  60% ==> 1
 ;  20% ==> 2
 ;  15% ==> 3
 ;   5% ==> 0
 ; ist
 Test1(Ergebnis) + 1
Next
Debug "kein Ergebnis :"+Str(Test1(0))
Debug "Ergebnis 1 :"+Str(Test1(1))
Debug "Ergebnis 2 :"+Str(Test1(2))
Debug "Ergebnis 3 :"+Str(Test1(3))

Damit hätte man eine Procedure, die dann bis zu 16 Wahrscheinlichkeiten aufnehmen kann und dann das Ergebnis ausgibt, was dann dem entspricht was oben mit Select oder If ermittelt wurde.
Ergeben die Prozente nicht 100, gibt es auch "kein Ereignis" also Default also 0, ansonsten entspricht das Ergebnis der Parameterstelle