Weder noch!

Ob man es "leichter" oder "schwerer" hat, hängt kaum mit dem Geschlecht, als viel mehr dem Elternhaus, Bildung, etwaigen Behinderungen, der finanziellen Situation, der Herkunft, dem Wohnort, uvm. zusammen.

Das Geschlecht spielt - verglichen mit diesen Punkten - nur eine untergeordnete Rolle. :)

...zur Antwort

Nimm mal einen Esslöffel in die Hand, und halte diesen ca. 10cm über die brennende Kerze für ca. 30 Sekunden.

Den Ruß, den du dann siehst, atmest du normalerweise ein, und der ist alles andere als Gesund.

Etwaige Duftstoffe können die Sache prinzipbedingt nur noch schlimmer machen, aber nicht besser.

An deiner Stelle würde ich mir Duftkerzen verkneifen, aber das ist letztendlich deine Entscheidung. Mach den Test mit dem Löffel ruhig mal und entscheide dnn selbst! :)

...zur Antwort

Wenn das alles ist, so 1€ bis 2€ pro Monat inkl. Domain ... kommt auf den Provider an, aber dafür reichen i. d. R. die billigsten Tarife völlig aus.

Also mit 10€ bis 20€ pro Jahr kannst du rechnen. :)

...zur Antwort

Ja, ist technisch möglich, und wird sogar auch gemacht.

Es gibt Unternehmen, die darauf spezialisiert sind, um automatisiert Urheberrechtsverstöße aufzudecken.

Davon abgesehen ist es völlig egal, ob es nachweisbar ist, oder nicht, da es grundsätzlich ohne Einverständnis des ursprünglichen Erzeugers nicht erlaubt ist.

...zur Antwort
constexpr size_t bufsz { 8 };
using arr_type = int;

arr_type * const arr { new arr_type[bufsz] {} };
// oder ...
// arr_type * const arr { malloc(sizeof(*arr) * bufsz) };

cout << sizeof(arr) << endl;
cout << (sizeof(arr) * bufsz) << endl;

for (size_t i {}; i < bufsz; ++i) {
  arr[i] = static_cast<arr_type>(i);
  cout << arr[i] << endl;
}

delete[] arr;
// oder ...
// free(arr);
...zur Antwort

Bei C89/C90 war es nur möglich, Variablen innerhalb von Funktionen am Anfang zu deklarieren, und weil die Compiler damals noch nicht so helle waren, hat man aus Optimierungsgründen auf eine Initialisierung verzichtet.

Das sah dann ungefähr so aus:

void foo(void) {
  unsigned char * buf;

  /* ... */
}

Aber da sich deshalb immer wieder Fehler eingeschlichen haben, und z. B. in diesem Beispiel der Zeiger "buf" dereferenziert wurde, ohne ihm vorher einen gültigen Speicherbereich zuzuweisen, war das eine "beliebte" Quelle für Bugs und Sicherheitslücken.

Normalerweise, solltest du Zeiger immer mit NULL bzw. nulltptr initialisieren, und jeder gängige Compiler wird dir diese "unnötige" Initialisierung vor der ersten Nutzung, sowieso weg optimieren.

Seit C99 ist es aber möglich, Variablen an der Stelle zu deklarieren, an der sie benötigt werden, und das solltest du sowohl bei C, als auch C++, dringend beherzigen!

Das erlaubt es dir, Zeiger fast immer auf const setzen zu können, womit schon mal eine riesen große Fehlerkategorie komplett ausgeschlossen wird.

Das sieht dann so bei C aus:

void foo(void) {
  unsigned char * const buf = malloc(sizeof(*buf) * BUFSZ);
  /* ... */
}

Bzw. in C++ sieht das so aus:

void foo(void) {
  unsigned char * const buf = new buf[BUFSZ];
  /* ... */
}

Fazit: Ein uninitialisierter "nackter" Zeiger an sich, ist nicht schädlich, aber eine der Hauptursachen für schwere Bugs und Sicherheitslücken, falls jemand es wagen sollte, darauf (schreibend) zuzugreifen. :)

Übrigens solltest du calloc() einem einfachen malloc() vorziehen, bzw. ein "new buf[SIZE] {}" einem "new buf[SIZE]". Initialisierungen - auch hinter dem Pointer - sind wichtig, guter Stil und sorgen selten für Performance-Einbußen, die ins Gewicht fallen. :)

...zur Antwort

Du solltest dabei folgende Punkte beachten:

  1. Nichtinitialisierte Zeiger sind kein guter Stil. Initialisiere sie wenigstens mit NULL (bei C) oder nullptr (bei C++).
  2. Die dynamische Speicheralokation mit malloc (bei C) bzw. mit new oder new[] (bei C++) solltest du in einem Schritt mit der Deklaration durchführen.
  3. Reservierten Speicher solltest du am Ende auch immer mit free (bei C) bzw. delete oder delete[] (bei C++) freigeben.
  4. Dein Code ist C, aber deine Frage bezieht sich auf C++, deshalb nutze lieber Smartpointer.
  5. Deine Zeigervariable kannst du als const markieren, damit du nicht wieder ausversehen den gleichen Fehler machst, wie in deinem Beispiel.
  6. Damit es keine Probleme gibt, falls du mal den zugrunde liegenden Typ deiner Variable "p" ändern willst, solltest du das sizeof() innerhalb von malloc() anpassen.

Lange Rede, kurzer Sinn, dein Code sollte so aussehen, falls du tatsächlich C meinst:

#include <stdio.h> /* fprintf, printf, stderr */
#include <stdlib.h> /* free, EXIT_FAILURE, malloc */

int main(void) {
  int result = EXIT_FAILURE;

  int * const p = malloc(sizeof(*p));

  if(p) {
    *p = 99;
    printf("%p => %i\n", (void *)p, *p);

    free(p);
    result = EXIT_SUCCESS;
  } else {
    fprintf(stderr, "malloc() streikt :(\n");
  }

  return result;
}

Falls du hingegen wirklich C++ meinst, mach es auf die C++ Art:

#include <iostream> // cerr, cout, endl
#include <cstdlib> // EXIT_FAILURE, EXIT_SUCCESS
#include <new> // nothrow

int main(void) {
  using namespace ::std;
  
  int result = EXIT_FAILURE;

  int * const p = new(nothrow) int;

  if(p) {
    *p = 99;
    cout << p << " => " << *p << endl;

    delete p;
    result = EXIT_SUCCESS;
  } else {
    cerr << "new() kaputt :(" << endl;
  }

  return result;
}

Allerdings würde man sich bei C++ a) eher auf Exceptions verlassen und b) bei modernem C++ Smartpointer nutzen, sodass der Code letztendlich so aussieht:

#include <iostream> // cerr, cout, endl
#include <memory> // make_unique

int main(void) {
  using namespace ::std;

  auto p = make_unique<int>();

  *p = 99;
  cout << p.get() << " => " << *p << endl;
}

Genau genommen gibt es noch mehr Möglichkeiten und Kombinationen, und noch viel mehr dazu zu sagen, aber ich glaube, das wird jetzt zu viel. :)

Ansonsten beachte bitte die anderen Antworten, die sehr gut deine eigentliche Frage beantworten. :)

...zur Antwort
lists = [[1,2,3], [4,5,6], [3,4,5]]

for sublist in lists:
  print(sublist)

# ... oder ...

for i in range(len(lists)):
  sublist = lists[i]
  print(sublist)
...zur Antwort

Frag dich mal selbst, wie es für dich wäre, wenn dir in Deutschland ein Japaner begegnet, der sich "Der Schuh des Manitu" auf seinen Rücken hat tätowieren lassen.

In Japan wirst du mit deinem Wunschtattoo garantiert ausgelacht werden. Gerade wenn du Japan magst, und vor hast, in Zukunft mal dort hin zu fahren, würde ich mir so ein Tattoo verkneifen.

Ich habe letzte Woche eine Frau in der Schlange vor mir gesehen, die hatte sich "水風土火" auf den Rücken tätowieren lassen. Da denkt man sich eigentlich nur "Uuuääääähhhhh" wenn man so etwas sieht. :)

...zur Antwort
Java Ellipse aus Linien zeichnen - Fehler wegen nur ganzzahlig möglichen Winkeln?

Hallo,

ich möchte in Java einen Farbkreis in Form eines Ellipse zeichnen; dafür zeichne ich Linien verschiedener Farben vom Mittelpunkt aus in einem bestimmten Winkel zum Endpunkt, der auf der imaginären Form einer Ellipse liegt. So weit so gut, das funktioniert auch.

Mein Problem allerdings ist, dass die Farbkreis-Ellipse nach dem Zeichnen ganz und gar nicht so aussieht, wie sie aussehen sollte:

Ich vermute, dass es daran liegt, dass die Berechnungen Gleitkommazahlen ergeben, die ich aber ganzzahlig runden muss, damit ich damit das Ende einer Linie als Punkt kennzeichnen kann. Dadurch liegen die Linien womöglich an manchen Stellen aufeinander und an anderen Stellen existieren keine Linien (ist das so?).

Hier der Code zum Definieren der Linien mit Farbe und Index:

Line[] lines = new Line[3*255]; 
int[] color = {255,0,0}; 
for(int i=0; i<3; i++) 
   for(int j=0; j<255; j++){ 
      color[i]--; color[(i+1)%3]++; 
      lines[i*255 + j] = new Line(i*255 + j + 1, new Color(color[0], color[1], color[2])); 
} 

Zeichne ich die Linien mit aufsteigender Länge nebeneinander, funktioniert der Farbübergang so wie geplant - nur die Farbellipse macht Probleme.

Hier der Konstruktor der Line-Klasse (mehr enthält sie mom. noch nicht):

Line(int index, Color color){
	this.index = index;
	this.color = color;
	this.angle = this.index*360./765; //3*255 Farben
    int a = Ellipse.a, b = Ellipse.b;
    double x = (a*b/Math.sqrt(b*b+Math.pow(a*Math.tan(angle), 2))),
           y = x*Math.tan(angle);
    if(angle > 90 && angle < 270) x = -x;
    this.end = new Point((int) x, (int) y);
    this.length = Point.distance(0, 0, end.x, end.y);
}

Die paint-Methode der Frame Klasse (ja, ich programmiere in Swing, die Ellipse ist eher ein quick&dirty-Projekt):

@Override public void paint(Graphics g){
	for(int i=0; i<3*255; i++){ 
       g.setColor(lines[i].color); 
       g.drawLine(m.x, m.y, lines[i].end.x+m.x, lines[i].end.y+m.y); 
    } 
} 

Warum sieht die gezeichnete Ellipse so grausam im Gegensatz zum Dreieck aus und separiert optisch so stark zwischen rot und blau? Woran liegt das bzw. wie kann ich es beheben?

Vielen Dank schon mal im Voraus.

LG

...zum Beitrag

Der Effekt ähnelt einem Problem, dass ich mal beim "händischen" Drehen von Bildern hatte, ohne AffineTransform zu nutzen.

Ich habe dabei fälschlicherweise die Koordinaten eines Pixels des Quellbildes, um das Zentrum gedreht, und den Pixel an den Zielkoordinaten auf die Farbe des ursprünglichen Pixels gesetzt. Klingt naheliegend, oder? Funktioniert aber nicht und ergibt viele leere Stellen, die entfernt an die leeren Bereiche deiner Ellipse erinnern.

Die Lösung war, den Pixel aus dem Zielbild entgegengesetzt (!) zu drehen, und falls diese Koordinaten innerhalb des Quellbildes lagen, die entsprechende Pixelfarbe von dort zu übernehmen.

Statt also das Quellbild im Uhrzeigersinn zu drehen, wird das Zielbild entgegen gesetzt dem Urzeigersinn gedreht.

Die Lösung war also - wie so oft in der Mathematik - das Ganze von hinten anzugehen!

Zu deinem Problem mit der Ellipse: Das kannst du lösen, indem du keine Linien mehr zeichnest, sondern Dreiecke, bei denen zwei Punkte benachbarte Linienenden am Rand sind, und der dritte Punkte im Mittelpunkt der Ellipse liegt.

Wie du den tollen Effekt mit der Rot- / Blau-Separation hinbekommen hast, weiß ich aber nicht. Sieht aber interessant aus! :)

...zur Antwort
... denn vor mehreren Tausend Jahren lag der CO2 Anteil viel höher als heute (0,04%). 
Das stimmt einfach nicht.

Die Klima- und CO2-Daten der letzten paar hundert tausend Jahre findest du von verschiedenen Forschungseinrichtungen und Universitäten öffentlich im Internet, sodass du dir daraus auch selber z. B. mit Excel ein Diagramm erzeugen kannst.

Der CO2-Gehalt war in den letzten 800000 Jahren nie so hoch wie heute, und ist in diesem Zeitraum auch nicht mal ansatzweise so schnell angestiegen, wie in den letzten 150 Jahren.

Dass der CO2 Gehalt in der Atmosphäre noch wesentlich früher (Präkambrium) um ein vielfaches höher war, ist auch kein Argument, weil zu dieser Zeit gar kein Leben wie heute möglich gewesen wäre. Menschen wären in dieser Atmosphäre damals erstickt.

Es gibt unzählige Quellen zu dem Thema, u. a.:

http://www.climatecentral.org/news/the-last-time-co2-was-this-high-humans-didnt-exist-15938

Wie will man die Temperatur exakt voraussagen, wenn der Wetterbericht kaum 1 Woche zuverlässig voraussagen kann?

Hat niemand behauptet, es geht um den Durchschnitt!

Außerdem ist Klima und Wetter etwas ganz anderes. Aber darauf werden dich schon genügend andere Leute hingewiesen haben. :)

...zur Antwort
Frauen müssen in Männerberufen hart arbeiten um Anerkennung zu bekommen.

So wird eher ein Schuh draus:

Menschen müssen in Berufen hart arbeiten um Anerkennung zu bekommen.

Das hat überhaupt NICHTS mit Männlein und Weiblein zu tun. Denkst du ernsthaft, Männer liegen in "Männerberufen" die ganze Zeit auf der faulen Haut, kümmern sich um nichts, und ihnen fliegt die Anerkennung zu? Dem ist NICHT so!

Es wäre ja noch schöner, wenn Frauen nicht hart arbeiten müssten, um Anerkennung zu bekommen, ganz egal um welchen Beruf es sich handelt.

Und mit dem Gender-Pay-Gap ist das so eine Sache: Der sog. "bereinigte" GPG liegt nicht mehr so um die 20%, sondern eher um die 2%.

Das Problem an der Sache ist, dass das im Bereich jeder Standardabweichung liegt, und man deshalb eigentlich gar keine vernünftige Aussage treffen kann. (Wer etwas anderes behauptet: Bitte nochmal die Statistik-Vorlesungen wiederholen!)

Darüber hinaus wird das Thema "unbezahlte Überstunden" neben vielen vielen anderen wichtigen Punkten überhaupt nicht berücksichtigt, und hier liegen Männer eindeutig weit "vorn".

Deshalb sollte es mich nicht wundern, wenn es am Ende tatsächlich einen GPG von 20% gibt, nur eben genau in die andere Richtung. :)

Leider sind bei dieser Diskussion beide Seiten so borniert, und ausschließlich auf die eigenen Vorteile fixiert, dass so ziemlich alle Studien zu dem Thema schwerste methodologische Fehler aufweisen und man diese deshalb im Grunde nicht ernst nehmen kann. Hier wird relativ ungeniert Rosinenpickerei betrieben ... das hat mit Studien, Statistik und allgemein Wissenschaft nichts mehr zu tun.

Wäre das Ganze nicht so sehr von extremen Maskulinisten und extremen Feministen vergiftet, könnte man vielleicht mal ganz trocken und unvoreingenommen an die Sache heran gehen, aber das wird wohl noch einige Jahrzehnte dauern ...

Und um deine Frage zu beantworten: Bisher waren ALLE Frauen, die ich kennen gelernt habe und die sich Feministinnen nannten, ziemlich verbittert und ständig auf Krawall aus. Wirklich ruhig konnte man nicht mit einer einzigen von denen Diskutieren. Das gleiche gilt für Frauenhasser, Chauvis und Maskulinisten.

Die nehmen sich alle nichts, und wirklich glücklich scheinen die auch nicht zu sein. Wer wirklich glücklich ist, verhält sich anders! :)

...zur Antwort

Das hier ist eine schnelle Lösung, wenn du Zahlen aus Listen extrahieren willst, egal wie tief diese verschachtelt sind:

a = [[1,2,3], [2,3,4], [1,4,6]]

b = list(eval(''.join(c for c in repr(a) if c not in '[]')))

print(b) # [1, 2, 3, 2, 3, 4, 1, 4, 6]

Eine ordentlichere Lösung wäre natürlich, über die Sublisten zu iterieren, aber dann wäre es kein Einzeiler mehr. :)

Falls du dir aber sicher bist, dass es immer nur exakt eine Ebene tief geht, ist die Lösung von Isendrak wesentlich besser und performanter! :)

...zur Antwort

Dafür gibt es standardmäßig bereits das "csv" Modul:

import codecs, csv

with codecs.open('data.csv', 'r', 'utf-8', 'strict') as fh:
  cr = csv.reader(fh, delimiter=' ', quotechar='"')

  for row in cr:
    print(row)

Weitere Details findest du in den offizellen API-Docs:

https://docs.python.org/3/library/csv.html

...zur Antwort

Das ist illegal, denn es verstößt gegen die DSGVO!

IP-Adressen gelten ausdrücklich als Personenbezogene Daten und ein IP-Logging ist ausdrücklich verboten, erst recht in "nackten" Textdateien, ohne Verschlüsselung und vor allem ohne Anonymisierung!

Du wirst dein Skript wegschmeißen, und dir andere Möglichkeiten der Spam- / Betrug-Erkennung suchen müssen.

Informiere dich DRINGENST zu dem Thema und erfrage evtl. bei einem Anwalt etwaige Details. Aber so in der jetzigen Form ist dein Skript bzw. die Speicherung der IP-Adressen für diesen Einsatzzweck definitiv zu 100% illegal und zieht u. U. unangenehme Strafen in Form von möglicherweise hohen Geldbußen nach sich.

...zur Antwort

Ich halte grundsätzlich nichts von der Todesstrafe, neben vielen anderen Gründen u. a. auch weil es keine Strafe, sondern für den Betroffenen ein einmaliges Ereignis darstellt, wonach nichts mehr kommt.

Eine wirklich lebenslange Haftstrafe halte ich für wesentlich wirksamer / abschreckender als eine Todesstrafe.

Wenn ich betroffen wäre, würde ich nicht wollen, dass der Täter so schnell und komfortabel "erlöst" wird, sondern er sollte lieber noch viele Jahrzehnte im Knast schmoren.

Hinzu kommt, dass nachweislich immer wieder Unschuldige durch die Todesstrafe ums Leben kommen. Aber das ist ein grundsätzliches Problem mit dem Justizsystem, nicht nur in Ländern mit Todesstrafe. :)

...zur Antwort