Re: Re: Re: Problem mit Forum-Skript - baseportal Forum - Web-Anwendungen einfach, schnell, leistungsfähig!
baseportal
English - Deutsch "Es gibt keine dummen Fragen - jeder hat einmal angefangen"

 baseportal-ForumDie aktuellsten 10, 30, 50, 100 Einträge anzeigen.  

 
 Ausgewählter Eintrag: Zur Liste 
    Beitrag von M. Sjuts (26 Beiträge) am Mittwoch, 15.Juli.2009, 08:33. WWW: www.krankenkassentarife.de
    Re: Re: Re: Problem mit Forum-Skript

      Hallo Dennis,

      danke für Deine Antwort. 33 direkte Follow-Ups sind zwar selten, kommen aber in unseren Foren durchaus vor. Ich schon gesucht, ob es in Perl eine Möglichkeit gibt, explizit zu sagen, dass eine Zahl mehr als 20 Nachkommastellen hat wie z. B. eine precision float, aber bislang noch nichts gefunden. Das würde das Problem ebenfalls lösen.

      Für die Testergebnisse mit
      $newPos=($Pos+3*$newPos)/4;
      
      wäre ich Dir dankbar, vielleicht bekomme ich so eine Lösung hin.

      Gruß, Mathias


    Antworten

 Alle Einträge zum Thema: Zur Liste 
    Beitrag von M. Sjuts (26 Beiträge) am Dienstag, 14.Juli.2009, 11:56.
    Problem mit Forum-Skript

      Hallo,

      ich habe ein Problem mit dem altgedienten Forum-Skript. Es ist so, dass Antwortbeiträge in langen Threats nicht die korrekte "$Pos", sondern die $Pos vom Eltern-Beitrag erhalten.
      Z.B.:

      Beitrag: $Pos=695.00000000000001
      Antwort: $Pos=695.00000000000001
      statt $Pos=695.000000000000005

      Hat das irgend was mit der Rechengenauigkeit zu tun (Perl verwendet doch standardmäßig double)?
      Der Fehler muss irgendwo hier stecken:

      $newPos=($Pos+$newPos)/2;
      my $mx=$newPos; chop $mx; $newPos=$mx if($mx>$Pos);
      

      Wer weiß Rat?

      Gruß, Mathias

     Antworten

    Beitrag von Pouraga (1396 Beiträge) am Dienstag, 14.Juli.2009, 14:07.
    Re: Problem mit Forum-Skript

      Also ich kenne jetzt gerade nicht die Float definition von perl auswendig (habe jetzt auch auf die schnelle keine Quelle gefunden, kommt sicher auch drauf an..) Aber duch die Addition komme ich auf 20 nötige Stellen in der Mantisse um die Rechnung duchzuführen, das ist schon eine ganze Menge. Duch automatische Typumwandlungen, könnte auch noch was verloren gehen.

      Eine einfache Lösung wüsste ich jetzt nicht für das Problem, da müssten wir uns schon eine ganz anderes Schema für Pos ausdenken. (gibt sicherlich schöneres) Wobei altes in der Datenbank geändert werden müsste und vorhandene Links unbrauchbar werden. Ist das eine Alternative?

      Ich komme mit dem vorhandenen auf ca. 33 direkte Follow ups. Wann hat man die schon mal? (voallem ohne Claus ;) )

      Gruss
      Dennis

     Antworten

    Beitrag von Pouraga (1396 Beiträge) am Dienstag, 14.Juli.2009, 14:24.
    Re: Re: Problem mit Forum-Skript

      Ah, mir ist doch noch was eingefallen.

      mit $newPos=($Pos+3*$newPos)/4; sollte man die Zeit bis zum Überlauf verdoppeln und altes kann bestehen bleiben. Ich bin aber gerade nicht fit genug um das in allen Konstellationen mit Baumtread's zu duchdenken. Also probiere damit erstmal ausgiebig in einer Testumgebung herum.

     Antworten

    Beitrag von M. Sjuts (26 Beiträge) am Mittwoch, 15.Juli.2009, 08:33. WWW: www.krankenkassentarife.de
    Re: Re: Re: Problem mit Forum-Skript

      Hallo Dennis,

      danke für Deine Antwort. 33 direkte Follow-Ups sind zwar selten, kommen aber in unseren Foren durchaus vor. Ich schon gesucht, ob es in Perl eine Möglichkeit gibt, explizit zu sagen, dass eine Zahl mehr als 20 Nachkommastellen hat wie z. B. eine precision float, aber bislang noch nichts gefunden. Das würde das Problem ebenfalls lösen.

      Für die Testergebnisse mit
      $newPos=($Pos+3*$newPos)/4;
      
      wäre ich Dir dankbar, vielleicht bekomme ich so eine Lösung hin.

      Gruß, Mathias

     Antworten

    Beitrag von Pouraga (1396 Beiträge) am Mittwoch, 15.Juli.2009, 10:05.
    Re: Re: Re: Re: Problem mit Forum-Skript

      Ich sag es dir ungern, aber das, was sich in C "precision float" nennt, hat auch nur 32 bits. ;)

      Aber hier scheint der Überlauf schon bei 64 Bit zu liegen. Ich Rate einfach mal 6 bit für den Exponenten, noch zwei bit weg für die Vorzeichen, dann bleiben 56 Bit für die Mantisse

       2^56 = 
       72057594037927936
       
       69500000000000001 < 72057594037927936 < 2*69500000000000001
      

      Klingt für mich also durchaus plausible, warum es gerade da an Genauigkeit verliert.

       >Für die Testergebnisse mit wäre ich Dir dankbar
      

      Hatte ich gesagt das ICH das ausgiebig teste? ;) Ok, ich habe es zumindest mal probiert ... geht scheinbar. Aber es sollte dir klar sein, dass damit zwar horizontale Treads länger sein können, bei vertikalen aber es früher zu Problemen kommt. (aber die hat man seltener)

      So genial einfach das mit dem pos ist, ist dein Problem doch eine Konzeptschwäche. Bevor man jetzt hingeht und sich dicke Workarounds einfallen lässt (z.b. behandeln der Zahl als string und nur mit teilen davon rechnen und wieder zusammenfügen), würde ich da doch eher über ein ganz neues Konzept nachdenken.

     Antworten

    Beitrag von M. Sjuts (26 Beiträge) am Mittwoch, 15.Juli.2009, 17:14.
    Re: Re: Re: Re: Problem mit Forum-Skript

      ... ja, Konzeptschwäche, mangelnde Skalierbarbeit, schade. Ansonsten kann man echt tolle Sachen damit machen.
      Die Idee mit den zusammengebastelten Stringteilen war mir übrigens auch schon gekommen :)


      Danke jedenfalls für das Testen von
      $newPos=($Pos+3*$newPos)/4;
      
      (ich hatte Deinen Satz so verstanden :))

      Gruß, Mathias

     Antworten


     
 Liste der Einträge von 8100 bis 8250:Einklappen Zur Eingabe 
Neueste Einträge << 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | Neuere Einträge < Zur Eingabe  > Ältere Einträge | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 >> Älteste Einträge


Zurück zur Homepage

© baseportal.de. Alle Rechte vorbehalten. Nutzungsbedingungen



powered in 0.09s by baseportal.de
Erstellen Sie Ihre eigene Web-Datenbank - kostenlos!