|
|
|
|
|
|
|
| | Zitat von Wraith of Seth
Konvergenzradius.
| |
Bingo. Jetzt fällt mir wieder ein, dass wir das sogar mal kurz besprachen, aber dann relativ schnell wieder unter den Tisch haben fallen lassen; vermutlich aufgrund der von Irdo genannten Abweichungen, die ja nicht kontinuierlich von "innen" nach "außen" anwachsen müssen.
|
|
|
|
|
|
|
|
|
|
|
Meine Kenntnisse dazu sind bereits vollstaendig erschoepft. 
Vorm inneren Auge flimmern dimm irgendwelche Funktionentheorieflashbacks, bei komplexwertigen Funktionen geht das irgendwie (magisch) einfacher, aber es gibt, glaube ich, auch Resultate im Reellen...aber wie gesagt, da muss jemand anderes ran.
Konvergenzradius auf jeden Fall ein wichtiger Begriff, haette auch in meinen Post gehoert! Der sagt dir sozusagen, wie gross dein Intervall ueberhaupt sein darf.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Wraith of Seth
Iirc sind die Stichworte "Taylor-Glied" (SBI!)
| |
Bei "das n-te Glied" musste ich mich in der Vorlesung immer zusammenreissen. Entenglieder. Gnühühü
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Trotzspender
Das ist ein sehr guter Punkt, den bisher überhaupt noch nicht bedacht habe. Shit.
| |
Das ist uebrigens nicht so schlimm, wie du vielleicht denken magst, ist ja ne ganz typische Problemstellung. Siehe das "uniform estimate" im Wikilink.
Bei der Gelegenheit faellt mir ein, was fuer ein Analysisnachschlagewerk koennt ihr empfehlen? Ich hab meinen Forster verloren (verliehen?), der hatte meiner Erinnerung nach viele Ergebnisse aber war mir auch etwas zu knapp mit den Erklaerungen.
Hab dann mal auf Empfehlung hin Brand: Advanced Calculus gekauft, aber da fehlen mir viele Resultate und er geht nicht tief genug.
|
|
|
|
|
|
|
|
|
|
|
Ich mag Zorich als Lehrbuch zu Analysis, weil recht umfassend, aber halt nicht wirklich als Nachschlagewerk geeignet.
Zum Nachschlagen hat imho wenig Wikipedia bisher schlagen können...
Die Taylorgliedabschätzungen gibt es, iirc, auch durchaus in einer Form, die valide für den ganzen Konvergenzradius sind, aber das ist dann etwas komplexer (no pun intended) und halt nur obere Schranken. (big surprise, there...)
Boo knows! Do not stow thrones in grass houses!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 04.03.2021 14:16]
|
|
|
|
|
|
|
|
|
Stehe grade auf dem Schlauch... habe in python zwei Listen, die nur mit integern gefüllt sind und will jeweils Position 1 der liste2 mit der Position 1 der liste1 addieren.
| |
| Code: |
liste1 = [1,2,3]
liste2 = [3,4,5]
#jetzt sollen die Listen so miteinander addiert werden,
dass liste2 = [4,6,8] ergibt.
Gemacht habe ich es jetzt so:
liste2[0] += liste1[0]
liste2[1] += liste1[1]
liste2[2] += liste1[2]
|
|
geht das nicht auch irgendwie schlanker?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
traumhaft! So ähnlich hatte ich es versucht und bin gescheitert, range(len(liste1)) war das fehlende Puzzlestück 
|
|
|
|
|
|
|
|
|
|
|
|
Was für eine schöne Sprache.
|
|
|
|
|
|
|
|
|
|
|
Sehr.
|
|
|
|
|
|
|
|
|
|
|
Ja sehr hübsch, wär toll wenn es Sprachen gäbe wo sowas geht.
liste1 <- c(1,2,3)
liste2 <- c(3,4,5)
liste3 <- liste1+liste2
Warum feiern eigentlich soviele Phyton?
Acid
|
|
|
|
|
|
|
|
|
|
|
|
Weil gilt: liste1 + liste 2 = [1, 2, 3, 4, 5, 6]
|
|
|
|
|
|
|
|
|
|
|
Nicht in meiner Welt.
R macht das genau so und seitdem ich das benutze verhau ich mich in anderen Sprachen immer 
> liste1 <- c(1,2,3)
> liste2 <- c(3,4,5)
> liste3 <- liste1+liste2
> print(liste3)
[1] 4 6 8
Acid
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von AcidPils am 04.03.2021 20:23]
|
|
|
|
|
|
|
|
|
|
Ein faszinierender Dialog. Man schreibt eine möglichst ungeschickte Implementierung eines simplen Problems hin und beschwert sich dann, dass die Sprache nicht elegant ist.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 04.03.2021 20:23]
|
|
|
|
|
|
|
|
|
lol !
| | >>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those! | |
|
|
|
|
|
|
|
|
|
|
| | Zitat von AcidPils
Nicht in meiner Welt.
R macht das genau so und seitdem ich das benutze verhau ich mich in anderen Sprachen immer
> liste1 <- c(1,2,3)
> liste2 <- c(3,4,5)
> liste3 <- liste1+liste2
> print(liste3)
[1] 4 6 8
Acid
| |
Jetzt hast du einen Array, der "liste" heißt, aber keine Liste.
|
|
|
|
|
|
|
|
|
|
|
liste1 = np.array(liste1)
liste2 = np.array(liste2)
liste3 = liste1 + liste2
|
|
|
|
|
|
|
|
|
|
|
| |
| Code: |
list(map(add, liste1, liste2))
|
|
Ohne import:
| |
| Code: |
[sum(x) for x in zip(liste1, liste2)]
|
|
Die Waffe ist immer so scharf wie man sie führt. Ähnlich meinem Hosenskalpell.
|
|
|
|
|
|
|
|
|
|
|
Skalpell eher sehr dünn, mein Java 7 Freund.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
| |
| Code: |
list(map(add, liste1, liste2))
|
|
Ohne import:
| |
| Code: |
[sum(x) for x in zip(liste1, liste2)]
|
|
Die Waffe ist immer so scharf wie man sie führt. Ähnlich meinem Hosenskalpell.
| |
An operator.add (das meinst du wohl?) stoert mich, dass es nur zwei Argumente nimmt.
Zip finde ich die eleganteste* Loesung: + fuer Listen reiht sie eben aneinander, zip legt sie "nebeneinander" - und das wollen wir schliesslich fuer die elementweise Summe.
*Also nach Numpy. Wenn es sich wie ein Vektor verhalten soll, soll es ein Vektor sein.
|
|
|
|
|
|
|
|
|
|
|
from operator import add, daher der Kommentar mit dem ohne Import 
|
|
|
|
|
|
|
|
|
|
|
|
Mach mal die Penispumpe aus, du brauchst mehr Sauerstoff oben
|
|
|
|
|
|
|
|
|
|
|
|
The penis pump is sentient.
|
|
|
|
|
|
|
|
|
|
|
In Scala kann man sich wenigstens Titten einbilden!
| |
| Code: |
(liste1, liste2).zipped.map(_ + _)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pah, wenn schon JVM, dann doch bitte Kotlin. Ohne boxing und mit.
| |
| Code: |
IntArray(a1.size) { a1[it] + a2[it] }
(a1 zip a2).map { (a, b) -> a + b }
|
|
Oder einfach eine extension function definieren und dann die verwenden:
| |
| Code: |
infix fun IntArray.add(that: IntArray) = IntArray(size) { this[it] +that[it] }
a1 add a2
|
|
Man kann damit auch Operatoren überladen, aber für Arrays definiert Kotlin + schon.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Irdorath
liste1 = np.array(liste1)
liste2 = np.array(liste2)
liste3 = liste1 + liste2
| |
liste3 = np.add(liste1, liste2).tolist()
Rechnen ohne numpy, lol.
|
|
|
|
|
|
|
|
|
|
|
|
Fast interessanter als die verschiedenen Varianten finde ich ja eher die verschiedenen Anwendungsgebiete. Ich habe noch nie Numpy benutzt.
|
|
|
|
|
|
|
|
|
|
|
SBI jetzt String-Schubser?
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XXIII |
![AUP [smith] 29.07.2010](./avatare/upload/U1066026--zeratul.png)
