Man könnte für die Motoren auch eine Art Factory-Pattern und zur Berechnung eine Art Interface (~Protocol) verwenden..

from typing import Protocol

class Zylinder:
def __init__(self,hoehe,breite,tiefe):
self.hoehe = hoehe
self.breite = breite
self.tiefe = tiefe

class Motor:
def __init__(self ...

Ich weiß zwar nicht genau, was du da an Zeitdifferenzen berechnen willst, aber Python hat da schon etwas on board, nennt sich "relativedelta"..

import datetime
from dateutil.relativedelta import relativedelta



def zeitspanne_ermitteln(start,end):
return relativedelta(end, start)



def main ...

So wie ich es verstehe, akzeptieren Sie meine Version des Beweises.
Oder?


Die Ansätze mit "reversen Bäumen" sind zumindestens nicht neu und haben bisher keine anerkannten Beweise der Collatz-Vermutung geliefert.

Dazu müsstest du mind. beweisen, dass der reverse Baum

1. zusammenhängend ist ...

Ja, das wohl eher ein mathematisches Problem :)

Die Summe aller Einsen bis zu einer Zweierpotenz 2^k-1 ist k*2^(k-1) (zb. für 0 bis 3=2^2-1 sind das in Summe 2*2^1=4 Einsen).

Das kann man sich zB. durch vollständige Induktion klar machen:

A(k) für 2^k-1:
k*2^(k-1)

A(k+1) für 2^(k+1)-1:
Dazu ...

__blackjack__ hat geschrieben: Mittwoch 28. Februar 2024, 14:25 Wobei `terminate()` auch die freundlichere Wahl an der Stelle wäre.

Ja, aber wohl mit einer Warnung..
https://docs.python.org/3/library/multi ... .terminate

@Qubit: Das bricht aber die anderen noch laufenden `Futures` an der Stelle nicht ab. Die werden trotzdem weiter berechnet.


Ja, das stimmt wohl.
Da hilft wohl dann nur, die Workerprozesse zu killen, wenn man das Future hat..


from concurrent import futures

def viaexponent(n):
result = n**5 ...

Mit futures.FIRST_COMPLETED sollte das auch funktionieren..


from concurrent import futures

def viaexponent(n):
result = n**5
# hier sollte der Befehl stehen der "viamulti" killt
return result

def viamulti(n):
result = n*n*n*n*n
# hier sollte der Befehl stehen der "viaexponent" killt ...

@Qubit: Wie willst du einen Datentyp für reelle Zahlen definieren, wenn fast alle reellen Zahlen nicht berechenbar sind?


Sorry, ich glaube, wie sprechen auch einander vorbei..

Unstrittig ist, dass Computer mit Maschinenzahlen rechnen.
Und Maschinenzahlen sind keine Dezimalzahlen der ...

@Qubit: Wie willst du einen Datentyp für reelle Zahlen definieren, wenn fast alle reellen Zahlen nicht berechenbar sind? Also wirklich für reelle Zahlen und nicht für irgendeine Untermenge? Wenn das nicht geht, dann ja, man kann mit Computern nicht richtig runden. Unter anderem, weil man fast alle ...

`round` würde versagen, wenn sich `round` anders verhalten würde als in der Doku beschrieben. Da aber beschrieben ist, was `round` kann und wie es sich in bestimmten Fällen verhält, ist es dann Anwendersache, die für seine Ansprüche richtige Funktion auszusuchen.


Das kann man natürlich so sehen ...

@Qubit: In Python eben nicht. Da gibt es keine reellen Zahlen. Kann es auch gar nicht, weil man im allgemeinen Fall nicht wirklich damit rechnen kann. Unter anderem, weil fast alle reellen Zahlen nicht berechenbar sind (es kann also keine Turing-Maschine (und damit auch kein Python-Programm) geben ...

@Qubit: Das Verhalten, das du bemängelst, wird in der Doku von round explizit angesprochen und wie von Sirius3 und narpfel beschrieben erklärt (https://docs.python.org/3/library/functions.html#round). Daher würde ich das nicht als Fehler sehen. Der Begriff "wissenschaftliches Runden" taucht in der ...

@Qubit: 2.635 ist keine reelle Zahl, sondern ein 64-Bit-IEEE-754-Wert. Und in dieser Darstellung ist 2.635 == 2.6349999999999997868371792719699442386627197265625, und das ist eben klar näher an 2.63 als an 2.64.


Doch "2.635" ist eine reelle Zahl.
Was du meinst, sind "Maschinenzahlen", also die ...

@qubit: Deine Rundung ist aber falsch, wenn ich die Zahl 2.63499999999999978684 runden möchte, wird fälschlicherweise aufgerundet.

Du hast nur den einen nummerischen Fehler durch einen anderen ersetzt. Zum Glück ist klar definiert, wie gerundet werden sollte, und das ist nicht die Näherungsformel ...

@Qubit: Das ist jetzt aber nicht richtig, weil 2.635 näher an 2.63 als an 2.64 ist.


Was heisst näher?

Der Abstand ist in den reellen Zahlen R über eine (Standard-) Metrik definiert ("Euklidische Metrik"), und da gilt:

|2.635-2.64| = |2.635-2.63|=0.005

Was heisst falsch?

Es geht um die ...

@Qubit: Dezimalzahlen können nicht immer exakt durch binäre Floats dargestellt werden, 2.635 ist in Wirklichkeit
f"{2.635:.20f}"
# 2.63499999999999978684
Und damit kleiner als 2.635 und wird deshalb abgerundet.


Jup, wobei ja auch diese Float-Darstelllung so nur max. auf 8 Stellen genau sein ...

Zustandsautomaten zur Worterkennung gibt's ja netterweise schon fertig:


Sehr schöne Lösung :D

Könnte man jetzt auch mit einem Dictionary verwursten..

import re

ZAHLWOERTER = {
'null': '0', 'zero': '0',
'eins': '1', 'one': '1',
'zwei': '2', 'two': '2',
'drei': '3', 'three': '3',
'vier ...

Nebenbemerkung zu round: 'round' rundet wissenschaftlich, während in der Schule i.d.R. kaufmännisches Runden gelehrt wird. Dies könnte dann bei denen, die die Software verwenden sollen, zu Verwirrung sorgen.


Aber das macht "round" auch nicht ganz korrekt..

>>> print(round(2.35,1))
2.4 ...

Also mit Rust oder C++ sollten da mindestens eine, wenn nich zwei Groessenordnungen an Speicher einsparbar sein. Und damit wird es dann auch schneller, weil weniger cache-misses und was nicht. Da ist IMHO Python fehl am Platz. Ausser man kann das so stricken, dass die eigentliche Arbeit ...

Mich würde mal interessieren wie ich selbst ein smartes Verhältnis von Workern und Chunksize wähle.

Und wo verdammt kommt der Speicherbedarf her? :-O


Das Optimieren von Multiprozess-Anwendungen ist eine "Kunst" für sich und lässt sich nicht pauschal sagen.
Wichtig ist, dass der Dispatcher ...