Warum so umständlich wenn es auch einfach geht. Einfach unlocker starten und löschen.
Überflüssige Algorithmen (Programmierabfall)
-
p. specht -
20. August 2009 um 01:14 -
Geschlossen
-
-
-
Hast du schon die API MoveFileEx() ausprobiert? Du kannst die Funktion so benutzen, dass sie Dateien sofort nach dem nächsten Booten löscht, bevor diese durch Benutzung vorm Löschen gesperrt sind.
-
Besten Dank, p.specht! Ich aufgrund deines Postings hier habe gerade gemerkt, das FileSnapper wegen des $12019-Fixes für Pipes die index.dat gar nicht listet. Update hochgeladen: Der Fix lässt sich nun bei Bedarf mittels Rechtsklick auf den jeweiligen Prozess für einzelne Prozesse abschalten.
-
Büddägeanäh!
-
Zitat von Frabbing;726843
Ja, es wird eben immer schwerer, ein geeignetes Programmprojekt zu finden. Es gibt halt schon (fast) alles. :cool:
Hallo Frank, vlt. wäre das hier was für Dich: http://xprofan.com/p/?54194
Salve.
-
Voxel können sich aber mit OGL nicht messen. In punkto Geschwindigkeit, aber auch visuell nicht.
-
Per OGL habe ich ja schon vorgemacht ( http://xprofan.com/t/?6830 ) - Voxel ( http://xprofan.com/p/?54194 ) ist aber eine eigene Spezialität.
Salve.
-
Ist aber eher nichts für mich momentan.
-
Weiterer Schwachfug, den die Welt nicht braucht: Geripse
-
Zitat von p. specht;729491
Weiterer Schwachfug, den die Welt nicht braucht: Geripse
Mittagspausencommanche:
[Blockierte Grafik: http://xprofan.com/files/zwischenablage01.png_1252542012_1_99183.png][Blockierte Grafik: http://xprofan.com/files/zwischenablage01.png_1252572960_1_29837.png]
Spielen: http://xprofan.com/p/?54210
-
Offenbar bin ich wieder mal der letzte, der´s erfährt:
EXCEL-2007-Bug!
77.1 * 850 sollte 65535 ergeben, zeigt aber angeblich 100.000 an.
Hier ein Artikel, der erklärt warum:
Explaining the Excel Bug - Joel on SoftwareOpenOffice CALC scheint nicht betroffen, zumindest nicht von DIESEM Bug.
Dafür ignoriert der Subtotal-Befehl dort Zellen in der 1. Zeile. Details hier: oooforum.org/ -
Zitat
Dafür ignoriert der Subtotal-Befehl dort Zellen in der 1. Zeile.
Wird sicher bald gefixt.
-
Was zum neidisch werden: Prof. Ken Perlin`s Homepage, dort insbesondere http://mrl.nyu.edu/~perlin/duck/ und unbedingt http://mrl.nyu.edu/~perlin/experiments/head/Face.html ansehen!
Gruss -
Unmenschlich dichter C-Code von Prof. Ken Perlin´s Homepage:
main(k){float i,j,r,x,y=-16;while(puts(""),y++<15)for(x=0;x++<84;
putchar(" .:-;!/>)|&IH%*#"[k&15]))for(i=k=r=0;j=r*r-i*i-2+x/25,
i=2*r*i+y/10,j*j+i*i<11&&k++<111;r=j);}Aus Neugier was obiger Code macht, hier der Versuch einer Umsetzung in Xpro11.2a
Code
Alles anzeigenwindow %maxx,%maxy declare i!,j!,r!,x%,k% var y%=-16 while (y%<15) inc y% print "" x%=0 while x%<84 inc x% k% = k% & 15 print mid$(" .:-;!/>)|&IH%*#",k%,1); i!=0:r!=0:k%=0 while 1 j!=r!*r!-i!*i!-2+x%/25 i!=2*r!*i!+y%/10 r!=j! inc k% case (k%>111) or ((j!*j!+i!*i!)>11) : break endwhile endwhile endwhile beep WaitInput
oder etwas dichter:
Codewindow %maxx,%maxy:declare i!,j!,r!,x%,k%:var y%=-16:while y%<15:x%=0:inc y%:print "" while x%<84:inc x%:k%=k% & 15:print mid$(" .:-;!/>)|&IH%*#",k%,1);:i!=0:r!=0:k%=0 while 1:j!=r!*r!-i!*i!-2+x%/25:i!=2*r!*i!+y%/10:r!=j!:inc k% case ((k%>111) OR ((j!*j!+i!*i!)>11)):break:endwhile:endwhile:endwhile:beep:WaitInput
Und wieder hat der sinnlose Programmierteufel zugeschlagen! -
-
Zitat
Und wieder hat der sinnlose Programmierteufel zugeschlagen!
Aber ein sehr guter Teufel
-
Weiteres zur Stringsuche, hier für den Fall von Tippfehlern, wo dennoch Übereinstimmung gefunden werden soll: Levenshtein-Distanzen.
Für verspieltere Typen gibt´s hier eine verbesserte Version des bekannten PowderGame. Und für 3D-Fans hier der 'State of the art': euphoria.
Und hier hat sich ein fleissiger Mensch mal die Mühe gemacht, bekannte Algorithmen nach Datum ihrer Erfingung zusammenstellen: Timeline_of_algorithms. Erstaunlich, wie alt manche Methoden sind: Unsere Urahnen waren eben auch nicht doof.
-
Überflüssiger Hinweis zu "PRINT" (hier: Xprofan 11.2a)
Eine Ausgabe mit dem Print-Befehl läuft über den unteren Rand des (Haupt-)Fensters hinaus. Korrekterweise wird das Fenster nun nach oben gescrollt.
Scrollbalken kommt keiner. Die darzustellende Liste (z.B. Preise im Zeitablauf) wird also mit den jüngsten Werten angezeigt, was für Übersichtszwecke völlig ausreicht. Nun will man diese Werte vergleichen mit einer Liste in einem anderen Fenster:Fall 1: Ein anderes Fenster wird aktiv, das nicht abdeckt, bei dem auch keine Ecke überdeckt: Das Listenende bleibt angezeigt (etwa zum Vergleichen).
Fall 2: Das andere Fenster wird aktiv, wobei sich ein winziges Eck mit der bisher aktiven Liste überdeckt. Folge:
Die Anzeige der Liste steht nun plötzlich am Beginn der vorhin ausgegebenen Liste.Kein Fehler i.e.S. - muß man nur wissen, warum sich plötzlich "Werte ändern". Sonst wird´s Selbstüberlistung
Gruss
-
Aus unbekannten Gründen wird das nachstehende Ding falsch kompiliert (Beendet sich bei der 2. Eingabe, schätze wegen Stackoverflow). Die Interpreterversion läuft aber brav.
Vorsicht, es gibt durchaus mehrere Varianten von Graycodes, nämlich alle Codes, die von einer Ziffer zur nächsten lediglich 1 bit ändern. Bei einer Codelänge von 3 bit sind das schon 6 Varianten. Diese hier ist bei Drehgebern aber die gängigste. Nur sucht man sie in den Bauplänen deshalb vergeblich, weil die Spurdetektoren im Kreis versetzt angeordnet sind - der elektronische Output stimmt aber überein.
Code
Alles anzeigenWindowTitle "Integerzahl nach Graycode (z.B. Drehgeber-Emulator)" ' (C) 2009 P. Specht, reiner Beta-Democode. Nur für Lernzwecke! Window %maxx*2/3,%maxy*2/3 declare h%,j&,g&,f$ f$=@mkstr$("0",32) set("decimals",0) AppendMenuBar 10," BINÄR (Dez)(Gray als Dez) "+\ "GRAY (Probe durch Rückrechnung von Gray nach Dezimal)" rpt: locate 2,1 print " Binärbreite (max 31):", input h% case h%<1:h%=1 if h%>31 print " Max. bis 2^31 (Signed Longint)!" goto "rpt" endif rpt2: locate 3,1 print " Ab Position (0 bis dezimal ";2^h%-1;"):", input j& if j&>(2^h%-1) print " Zw. 0 und 2^";h%,"-1 =",2^h%-1 goto "rpt2" endif print while j&<(2^h%) g&=@XOR(j&,(j& >> 1)) print ,right$(f$+@BIN$(j&),h%),,j&,g&,right$(f$+@BIN$(g&),h%), gray2bin(g&) inc j& if %CsrLin>33 print " mehr..."; waitkey case @IsKey(27):end cls endif endwhile print " ------ " WaitInput End ' Rückrechnung (Test) proc gray2bin parameters n& 'Drehgebermesswert, zB. via unbenutztem Parallelport ' - möglichst optisch entkoppelt: electrosofts.com/parallel/ declare sh&,nn& sh&=1:nn&=(n& >> sh&) while nn&>0 n&=@XOr(n&,nn&) sh&=(sh& << 1) nn& = (n& >> sh&) endwhile return n& endproc
-
Sensation: Verhältnis zwischen Kreiszahl Pi und der Basis des natürlichen Logarithmus e (Eulersche Zahl, exp(1) ) entdeckt!!!!
Oops, ist doch keine Sensation. Das Verhältnis lautet:
Circa 1.16 , oder etwas genauer:
XProfan: 1,155727349790921730
Taschenrechner von Windows: 1,1557273497909217179100931833127
AriBas-W: 1.15572734979092171791009318331269629912085
1023164415820499706535327288631840916939440188434235673558804486653687020700914219048007856360834437788613604544109645138219699555760622688895095637
70805852198635121805853707231355565921333354095807331307283225899471359728
62258741687174951500204902423801143612102533542480051216203817074364575818
...(Edit: Gekürzt)auf 2047 +/- 0.5 Stellen genau. Gebraucht wird so eine "Genauigkeit" ausschließlich von Zahlentheoretikern, die ihre Thesen möglichst glaubwürdig machen wollen.
Echte Beweise liefern Computer aber nur, wenn sie symbolisch rechnen. Beispielsweise wurde so der Satz von der unterschiedlichen Einfärbbarkeit jeder Grenzkarte mit maximal 4 Farben bewiesen: Da rechneten 4 unterschiedliche Programme alle Möglichkeiten durch. Link (englisch): Robertson-Sanders-Thomas.P.S.: Im Komplexen gibts doch noch einen tiefsinnigeren Zusammenhang: -%e^%i=1+%e^pi
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!