Cast: String oder new String

[pl]

s. Thema. In einer Funktion wird der übergebene String str nicht als type String anerkannt, so daß ein str.replace() unmachbar ist. Mit String(str).replace() jedoch funktioniert es. An einer anderen Stelle will ich sicherstellen, daß der return Value von Type String ist. Was ist da besser bzw. der Unterschied zwischen return new String(str) und return String(str) ?

Bitte mal um Hinweises.

[dedlfix]

Tach!

Was ist da besser bzw. der Unterschied zwischen return new String(str) und return String(str) ?

Siehe Thema. Das eine ist ein Typecast zum Typ string, das andere erzeugt ein Objekt. Genaueres weiß das MDN (Distinction between string primitives and String objects). Was besser ist? Entscheide selbst. Im Allgemeinen gibt es jedenfalls keine Veranlassung in Javascript mit den Objekt-Pendants der primitiven Typen zu hantieren.

An einer anderen Stelle will ich sicherstellen, daß der return Value von Type String ist.

Meinst du mit "String" das Ergebnis von typeof oder ein String-Objekt.

dedlfix.

[pl]

Ok, dann entscheid ich halt mal selbst.

[Rolf B]

Hallo dedlfix,

es scheint damals in Mode gewesen zu sein, außer primitiven Typen auch geboxte Counterparts zu verwenden. JavaScript macht das, Java macht das, und .net macht es auch. Aber nur JavaScript macht es auch für Strings.

Die Existenzberechtigung der primitiven Typen ist klar - Performance. Es ist immer aufwändiger, mit einem Objekt zu hantieren statt mit einem primitiven Wert. Bei Zahlen ist es einsichtig. Da redefiniert man einen Teil der Objektreferenz-Struktur und schmeißt den primitiven Wert direkt hinein, statt jedesmal im Heap herumzuturnen. Aber ein String? Der lebt doch größtenteils eh auf dem Heap.

Rolf

[pl]

Hi @Rolf B

die Typisierung nervt einfach nur: Nämlich da wo man sie gar nicht gebrauchen kann. So wird in Templates grundsätzlich nur mit Strings operiert, was jedoch fehlschlägt sobald JS der Meinung ist, es handele sich um eine Zahl. Deswegen der Cast.

MfG

[dedlfix]

Tach!

die Typisierung nervt einfach nur: Nämlich da wo man sie gar nicht gebrauchen kann. So wird in Templates grundsätzlich nur mit Strings operiert, was jedoch fehlschlägt sobald JS der Meinung ist, es handele sich um eine Zahl. Deswegen der Cast.

Du meinst mit einem unspezifischen Typecast bekommst du ein besseres Ergebnis als wenn man die Methoden toExponential(), toFixed(), toPrecision(), toString() oder toLocalString() verwendet?

dedlfix.

[pl]

@dedlfix

die Typisierung nervt einfach nur: Nämlich da wo man sie gar nicht gebrauchen kann. So wird in Templates grundsätzlich nur mit Strings operiert, was jedoch fehlschlägt sobald JS der Meinung ist, es handele sich um eine Zahl. Deswegen der Cast.

Du meinst mit einem unspezifischen Typecast bekommst du ein besseres Ergebnis als wenn man die Methoden toExponential(), toFixed(), toPrecision(), toString() oder toLocalString() verwendet?

Du sprichst in Rätseln. Ob i.toString() besser ist als String(i) kann ich nicht beurteilen. Vielleicht kannst ja mal den Unterschied erklären, wäre ganz nett.

.

[dedlfix]

Tach!

Du sprichst in Rätseln. Ob i.toString() besser ist als String(i) kann ich nicht beurteilen. Vielleicht kannst ja mal den Unterschied erklären, wäre ganz nett.

Ich kann es erst recht nicht beurteilen, ich kenne deinen Anwendungsfall nicht. Wichtiger als toString() waren mir eigentlich die anderen genannten Funktionen.

dedlfix.

[pl]

@dedlfix

Du sprichst in Rätseln. Ob i.toString() besser ist als String(i) kann ich nicht beurteilen. Vielleicht kannst ja mal den Unterschied erklären, wäre ganz nett.

Ich kann es erst recht nicht beurteilen, ich kenne deinen Anwendungsfall nicht. Wichtiger als toString() waren mir eigentlich die anderen genannten Funktionen.

Es gibt bestimmt einen Unterschied. Und der ist mit Sicherheit unabhängig von meiner Anwendung.

Wichtiger als toString() waren mir eigentlich die anderen genannten Funktionen.

Hier gehts nur um Strings!

MfG

[Rolf B]

Hallo dedlfix,

try this:

let a = 5, b;
console.log(String(a));
console.log(a.toString());
console.log(String(b));
console.log(b.toString());

Was einem bei b nun lieber ist, muss man für sich entscheiden. EIGENTLICH ist beides nicht gut, d.h. man braucht im Prinzip eine eigene Cast-Funktion in der man einen fachlich passenden Default setzen kann.

Rolf

[dedlfix]

Tach!

try this:

let a = 5, b;
console.log(String(a));
console.log(a.toString());
console.log(String(b));
console.log(b.toString());

Was einem bei b nun lieber ist, muss man für sich entscheiden.

b ist keine Zahl und damit erstmal nicht von dem betroffen, was von der Aufgabenstellung bekannt ist. Abgesehen davon gibt es neben dem Typecast auch noch andere Wege, für einen falsy Wert einen Defaultwert zu bekommen, beispielsweise b || 0 oder b || ''.

dedlfix.

[Rolf B]

Hallo dedlfix,

nicht von dem betroffen, was von der Aufgabenstellung bekannt ist

Doch. PL sagt:

An einer anderen Stelle will ich sicherstellen, daß der return Value von Type String ist.

Sicherstellen heißt: Mache aus jedem möglichen Input-Typ einen String. Und stürze dabei nicht ab. Ich wollte ja nur auf folgendes hinaus: Blindlings x.toString() aufrufen kann das Script abstürzen lassen. Bei String(x) passiert das nicht, dafür bekomme ich da ggf die blöden Werte 'null' und 'undefined'.

Ob jeder falsy-Wert zu 0 oder '' gewandelt werden soll, ist auch offen. Noch schlimmer: nicht jeder truthy-Wert ist true. Ganz böses Beispiel:

Boolean.prototype.identifyYourself = function(t) {
    console.log("I am " + (this ? 'true' : 'false'));
};
false.identifyYourself();

// I am true

Rolf

[dedlfix]

Tach!

Ob jeder falsy-Wert zu 0 oder '' gewandelt werden soll, ist auch offen. Noch schlimmer: nicht jeder truthy-Wert ist true. Ganz böses Beispiel:

Boolean.prototype.identifyYourself = function(t) {
    console.log("I am " + (this ? 'true' : 'false'));
};
false.identifyYourself();

// I am true

Nicht alles was ein Programmierfehler ist, ist eine gültiger Aussage. So wäre es richtig:

Boolean.prototype.identifyYourself = function() {
    console.log("I am " + (this.valueOf() ? 'true' : 'false'));
};
false.identifyYourself();

Wenn an einem primitiven Typ eine Objekt-Methode aufgerufen werden soll, wird der Wert in ein Objekt konvertiert. Objekte sind nie falsy, weswegen der einfache boolsche Test nicht richtig ist. Stattdessen muss man den Wert testen, nicht das Objekt selbst.

dedlfix.

[1unitedpower]

Boolean.prototype.identifyYourself = function(t) {
    console.log("I am " + (this ? 'true' : 'false'));
};
false.identifyYourself();

// I am true

Ja, das ist eine Tücke von boxed Primitives, wenn man eine Methode auf einem Primitiven Datentypen aufruft, wird er zu einem Boxed Primitive gecoerced, und dadurch ist this in der Methode ein Objekt und Objekte sind truethy. Deshalb muss man in so einem Fall this ist erst wieder unboxen, das geht mit .valueOf():

Boolean.prototype.identifyYourself = function(t) {
    console.log("I am " + (this.valueOf() ? 'true' : 'false'));
};
false.identifyYourself();

// I am false

Zu Primitves und Boxed Primitives lohnt sich das Kapitel 3 von Kyle Simpsons Buch You Don't Know JS zu lesen.

[1unitedpower]

die Typisierung nervt einfach nur: Nämlich da wo man sie gar nicht gebrauchen kann.

Den Frust kann ich nachvollziehen, so sehr ich JavaScript auch mag, das Typsystem ist nicht zu gerbauchen. Probier mal TypeScript oder Flow aus, dafür gibt es auch Editor-Plugins, so siehst du bei den allermeisten Typfehlern schon beim Tippen, was du falsch gemacht hast.

[pl]

die Typisierung nervt einfach nur: Nämlich da wo man sie gar nicht gebrauchen kann.

Den Frust kann ich nachvollziehen,

Oh danke 😉

Nun, für die Daten mit denen eine TE gefüttert wird sicherzustellen, daß da nur Strings reinkommen ist nicht immer möglich. Andererseits funktioniert der Griff in einen Arrayindex sowohl mit Number als auch mit String:

var a = ['foo','bar'];
console.log( a[0], a['1'] ); // foo bar

Aber richtig böse wirds, wenn das Vorhandensein einer bestimmten Eigenschaft eines JS Objects zu prüfen ist zu welcher der Werte sowohl String als auch Number sein kann.

MfG

[ursus contionabundo]

return new String(str)

Gibt das fürchterlich komplizierte Objekt vom Typ String zurück.

return String(str)

Gibt etwas vom krass einfachen Datentyp String zurück. Du kannst Dich mit

console.log(typeof(new String(5.3)));
console.log(typeof(String(5.3)));

überzeugen:

object
string

Der Datentyp "string" ist ein primitiver Datentyp. Er hat keine Methoden, ist nur ein Zeiger auf einen Speicherbereich mit raw-Daten und bietet einen schnellen wahlfreien Zugriff.

Wird auf den primitiven String eine der Methoden oder Eigenschaftsabfragen des Objekts String angewendet, dann wrappt (boxt, ummmantelt) JS zur Laufzeit die Daten in ein Objekt.

Richtig interessant ist übrigens:

console.log( typeof( new String(5.3) ) );
console.log( typeof( new String(5.3).replace('.', ',') ) ) ;

Ups:

object
string

Das JS als Ergebnis der Anwendung einer Methode auf ein String-Objekt einen String (und nicht das Objekt) zurückliefert sollte Dir zu denken geben. Etwas anderes kann gelten, wenn Du unbedingt ein Objekt brauchst:

o = new String(5.3);
o.foo = 'bar';
console.log(o);

Das dürfte aber eher selten sein.

Noch was:

String.prototype.decToGerman = function() {
    return this.replace('.', ',');
}
o = new String(5.3);
console.log( o.decToGerman() );
o = String(5.3);
console.log( o.decToGerman() );

(Achte auf die Kommas)

5,3
5,3

Ich denke, die Entscheidung fällt jetzt leicht.

[dedlfix]

Tach!

Noch was:

String.prototype.decToGerman = function() {
    return this.replace('.', ',');
}

Number.prototype.toLocaleString() existiert.

dedlfix.

[ursus contionabundo]

Hehe.

Noch was:

String.prototype.decToGerman = function() {
    return this.replace('.', ',');
}

Number.prototype.toLocaleString() existiert.

Es ging augenscheinlich um eine Demo für das Prototyping und dass hierfür etwas wie s=new String(n) nicht nötig ist. Die Methode replace() habe ich wegen der Augenscheinlichkeit gewählt und weil PL genau diese explizit anwenden wollte. Da lag der Kommata-Tausch einfach mal nahe.

Das Number.prototype.toLocaleString() existiert ist aber ein netter Hinweis an PL. Vielleicht sucht er ja eigentlich danach...

[pl]

Der Datentyp "string" ist ein primitiver Datentyp. Er hat keine Methoden,

Doch hat er. Sonst würde ja ein String(str).replace() nicht funktionieren. Und console.log( typeof String('asdf') ); zeigt string

MfG

[ursus contionabundo]

Der Datentyp "string" ist ein primitiver Datentyp. Er hat keine Methoden,

Doch hat er. Sonst würde ja ein String(str).replace() nicht funktionieren.

Lese noch mal nach, was ich zum "Ummanteln" geschrieben habe. Im Speicher ist beim Typ String kein Objekt, sondern nur die trockenen Daten - also keine Methode, Eigenschaft e.t.c. - Der Grund? Das spart offensichtlich eine Menge Platz.

Wenn Du auf dieses ETWAS von Typ String die String-Methoden anwendest oder nach String-Eigenschaften abfragst, dann packt JS die Daten temporär in ein anonymes Objekt, führt die Methode aus und vergisst das dafür angelegte Objekt spätestens dann wieder, wenn es nicht noch mal gebraucht wird. Davon sieht man freilich nichts, der Vorgang ist völlig transparent.

Und console.log( typeof String('asdf') ); zeigt string

Ja. Klar. Aber eben nicht "object" wie es bei

console.log( typeof( new String('asdf') ) );

der Fall ist.

[pl]

Ein Cast like:

var n = 123;
n += '';
n.replace();

tuts auch.

[ursus contionabundo]

Ein Cast like:

var n = 123;
n += '';
n.replace();

tuts auch.

Etwas wie

s = String(123.45).replace(',', '.');

ist aber kürzer und augenscheinlicher. "tuts auch" ist also "schmutzig". Und der Name "n" für eine Variable mit String als Inhalt ist "ganz böse".

[pl]

Mir gehts hier nur ums Verständnis, wie eine Variable heißt oder ob Du einen Code schmutzig nennst, das ist mir völlig wurst.

.

[ursus contionabundo]

Ich sag's mal so:

Ich hab mir für die Antwort auf Deine Frage …

Was ist da besser bzw. der Unterschied zwischen return new String(str) und return String(str)

einige Mühe gemacht und bin wegen dieser und jener Antwort recht enttäuscht, weil ich den Eindruck habe, dass Du Dich für das Ergebnis nicht, gar nicht oder wenigstens "nicht wirklich" interessierst.

Aber Ok. Ich hab mich einem bisher mangels eigenem Interesse ignorierten Thema befasst und dabei selbst was gelernt. Die technische Hälfte meiner Erkenntnisse kann ich nunmehr anderen gegen Geld verkaufen. Mit den anderen kann ich wohl meine Erwartungshaltung neu justieren.

[pl]

Nun, ich habe ja auch recherchiert. Schon von daher kann ich absolut nicht nachvollziehen, warum es Dir in Deiner Antwort zu meinem Beispiel, was anderweitig sogar als best practice propagiert wird, wichtig ist darauf hinzuweisen, daß n als Name für eine Stringvariable böse ist und der Code schmutzig sei.

Das geht am Thema völlig vorbei.

PS:

Und wenn Du Deinen Code zu Geld machen kannst, das ist schön für Dich. Bei meinem Code ist es so, daß ich der Letzte bin der ihn zu Gesicht bekommt. So sind meine diesbezüglichen Erfolge auch anderer Natur als Deine.

[ursus contionabundo]

warum es Dir in Deiner Antwort zu meinem Beispiel, was anderweitig sogar als best practice propagiert wird

Was "anderweitig sogar als best practice propagiert wird" kann "bad practice" sein. Dein Beispiel mit impliziter Typumwandlung zeigt genau das: n += ''; zeigt nicht was beabsichtigt wird. Abzug bei Pflegbarkeit (und Performance) → also "bad practice".

Nun, ich habe ja auch recherchiert.

Wohl. Aber mit dem falschen Ergebnis.

[pl]

Es gibt keine falschen Ergebnisse. Es gibt höchstens mehrere Möglichkeiten!

[ursus contionabundo]

Es gibt höchstens mehrere Möglichkeiten!

Im dem Fall genau eine: Deine Aussage war schlicht falsch. Und jetzt hör auf mit den Widerworten. Ich hab als Soldat (nicht: Gefreiter) in den 18 Monaten bei den "Muckern" mehr UvDs "gestanden" als Du in drei Jahren an der Grenze. Und wenn ein Buckel in meinem Gang schreien wollte, dann konnte er bei mir mal den Antrag stellen, dass ich für ihn herumbläke - aber das definitiv nicht selbst tun.

Verstanden?

[Felix Riesterer]

Lieber ursus,

auch wenn Du in der Sache sicherlich den richtigen Standpunkt vertrittst, so solltest auch Du manchmal einsehen, dass es Momente gibt, in denen Du den Unsinn von @pl einfach so stehen lassen musst (auch wenn sich vielleicht alles in Deiner kampferprobten Natur dagegen sträubt). Deine Reaktion hier ist leider kontraproduktiv... und stellt Dich allein der Form wegen tendenziell ins Unrecht.

Liebe Grüße,

Felix Riesterer.

[pl]

@Felix Riesterer

dass es Momente gibt, in denen Du den Unsinn von @pl einfach so stehen lassen musst

Eigentlich hatte ich nur eine Frage. Die im Übrigen immer noch nicht beantwortet ist!

MfG

[dedlfix]

Tach!

Eigentlich hatte ich nur eine Frage. Die im Übrigen immer noch nicht beantwortet ist!

Die Ursprungsfrage oder eine andere? Die Eingangsfrage war:

Was ist da besser bzw. der Unterschied zwischen return new String(str) und return String(str) ?

Der Unterschied wurde erklärt, das eine erzeugt ein Objekt, das andere einen primitiven Wert von Typ string. Die Frage nach dem "besser" ist ohne ein "für welchen konkreten Fall?" nicht beantwortbar.

dedlfix.

[pl]

hi @dedlfix

solche und ähnliche Fragen kannst Du auch auf Stackoverflow verfolgen. Es ist so, daß JS keinen Castoperator kennt etwa wie in c. Vielmehr findet in JS stets eine Typumwandlung statt wohingegen ein Cast in c lediglich auf die Operation Einfluß nimmt, der Typ also erhalten bleibt.

In JS ist es auch möglich, Methoden die normalerweise von Instanzen aufgerufen werden, auch als Klassenmethoden zu verwenden wie untenstehendes Beispiel zeigt:

var n = 123;
n = String.replace(n,1,9);  // n wird übergeben
console.log(n, typeof n);   // 923 string

Wobei aber auch hier eine Typumwandlung stattfindet.

MfG

[Felix Riesterer]

Lieber pl,

Wobei aber auch hier eine Typumwandlung stattfindet.

wenn Du String.replace(<integer>,1,9) notierst, dann ist klar, dass vor der String-Operation der Integer-Wert in einen String umgewandelt werden muss! Was für eine Binsenweisheit!

Was war eigentlich hierbei Deine Frage?

Liebe Grüße,

Felix Riesterer.

[pl]

@Felix Riesterer

Was war eigentlich hierbei Deine Frage?

Gar keine. Vielmehr zeigte ich den Unterschied zwischen

 1. Klassenmethode => wird mit dem Namen der Klasse aufgerufen
 2. Objektmethode => wird mit der Instanz (Objekt) aufgerufen

wobei in beiden Fällen eine Übergabe stattfindet. Und das es mehrere Mölichkeiten gibt die u.U. zu mehreren oder auch verschiedenen Ergebnissen führen, haben wir ja bereits festgestellt.

MfG

[dedlfix]

Tach!

In JS ist es auch möglich, Methoden die normalerweise von Instanzen aufgerufen werden, auch als Klassenmethoden zu verwenden wie untenstehendes Beispiel zeigt:

Diese Aussage stimmt so nicht. Das ist nicht allgemein in Javascript möglich. Es gibt auch keine Klassen, jedenfalls nicht so wie du es hier meinst.

var n = 123;
n = String.replace(n,1,9);  // n wird übergeben
console.log(n, typeof n);   // 923 string

Das funktioniert zwar so im Firefox, wird aber mit

String.replace is deprecated; use String.prototype.replace instead

beanstandet. Und nein, auch String.prototype.replace(123, 1, 9) ist auch kein gleichwertiger Ersatz.

In Chrome und Edge wird es hingegen mit

Uncaught TypeError: String.replace is not a function

und

Object doesn't support property or method 'replace'

komplett abgelehnt.

dedlfix.

[pl]

Object doesn't support property or method 'replace'

Mit typeof prüfen!

[dedlfix]

Tach!

Object doesn't support property or method 'replace'

Mit typeof prüfen!

Was genau soll ich da prüfen?

typeof String ergibt function. Das hat keine Methode namens replace. Demzufolge liefert typeof String.replaceauch undefined.

Außer im Firefox, aber das sagte ich ja bereits, dass das da eine missbilligte Ausnahme ist.

dedlfix.

[pl]

@dedlfix

Denkmodelle passen eben auch nicht immer. Ein Modell was nicht alles abdeckt ist jedoch immer noch besser als Intuition.

MfG

[pl]

dass es Momente gibt, in denen Du den Unsinn von @pl einfach so stehen lassen musst

Wie niedrig dem @Felix Riesterer seine Gründe auch sein mögen mich auf diese Art zu beleidigen, den Anlass dazu habe ganz bestimmt nicht ich gegeben!

[Felix Riesterer]

Lieber pl,

Wie niedrig dem @Felix Riesterer seine Gründe auch sein mögen mich auf diese Art zu beleidigen, den Anlass dazu habe ganz bestimmt nicht ich gegeben!

es ist Dein Recht meine scharfen Worte als Beleidigung zu verstehen. Aber Deine Aussage...

Es gibt keine falschen Ergebnisse. Es gibt höchstens mehrere Möglichkeiten!

... ist (nicht nur für diesen Fall) weder zielführend noch richtig. Eine der negativen Bewertung dafür stammt übrigens von mir. Ehre wem Ehre gebührt.

Desweiteren empfinde ich in anderen Fällen oft, dass Deine Threaddrift bezüglich Politik und Geschichte auf der einen Seite unangemessen ist, und auf der anderen nicht dazu geeignet ist, Lösungen zu finden. Daher mein scharfes Urteil mit "Unsinn". Dazu stehe ich jederzeit.

Liebe Grüße,

Felix Riesterer.

[pl]

@Felix Riesterer

es ist Dein Recht meine scharfen Worte als Beleidigung zu verstehen.

Natürlich ist das eine Beleidigung zu behaupten ich würde hier Unsinn schreiben! Außerdem ist es hinterhältig! Und ja, Du stellst damit auch Deine pädagogischen Fähigkeiten selbst in Frage!

Aber Deine Aussage...

Es gibt keine falschen Ergebnisse. Es gibt höchstens mehrere Möglichkeiten!

Ist vollkommen richtig. Als Ergänzung: Es gibt mehrere Möglichkeiten die ggf. zu mehreren und möglicherweise zu verschiedenen Ergebnissen führen.

Ob meine Ergebnisse richtig oder falsch sind kannst Du doch gar nicht beurteilen. Und schon gar nicht jemand der es vorzieht sich mit mir rumzustreiten anstatt fachlich zu diskutieren.

MfG

[Gunnar Bittersmann]

@@pl

Natürlich ist das eine Beleidigung zu behaupten ich würde hier Unsinn schreiben!

Nein, das ist eine Tatsachenbehauptung.

Außerdem ist es hinterhältig!

Nein, es ist öffentlich. Öffentlich und hinterhältig schließen sich aus.

Und ja, Du stellst damit auch Deine pädagogischen Fähigkeiten selbst in Frage!

Für manche reichen auch die besten pädagogischen Fähigkeiten nicht aus.

Es gibt keine falschen Ergebnisse. Es gibt höchstens mehrere Möglichkeiten!

Ist vollkommen richtig. Als Ergänzung: Es gibt mehrere Möglichkeiten die ggf. zu mehreren und möglicherweise zu verschiedenen Ergebnissen führen.

1 + 1 = ? Oh, da gibt es mehere Möglichkeiten … verschiedene Ergebnisse – aber die sind alle richtig.

Merkste selber? (Ich zweifel.)

Ob meine Ergebnisse richtig oder falsch sind kannst Du doch gar nicht beurteilen.

Die Aberkennung der Urteilsfähigkeit geht jetzt schon eher in Richtung Beleidigung.

Und schon gar nicht jemand der es vorzieht sich mit mir rumzustreiten anstatt fachlich zu diskutieren.

Man kann sich mit dir rumstreiten oder auch nicht, aber mit dir fachlich zu diskutieren ist kaum möglich.

LLAP 🖖

[dedlfix]

Tach!

1 + 1 = ? Oh, da gibt es mehere Möglichkeiten … verschiedene Ergebnisse – aber die sind alle richtig.

Mir fallen da schon drei Möglichkeiten ein:

1+1=2 1+1=10

und auch

1+1=1

Du hast den Kontext vergessen anzugeben.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

1 + 1 = ? Oh, da gibt es mehere Möglichkeiten … verschiedene Ergebnisse – aber die sind alle richtig.

Mir fallen da schon drei Möglichkeiten ein:

• 1+1=2
• 1+1=10

Das ist dasselbe Ergebnis. Nur die Notation ist unterschiedlich.

und auch

1+1=1

Den verstehe ich nicht.

LG,
CK

[dedlfix]

Tach!

Mir fallen da schon drei Möglichkeiten ein:

• 1+1=2
• 1+1=10

Das ist dasselbe Ergebnis. Nur die Notation ist unterschiedlich.

Ja, aber die ist unterschiedlich und somit auch nachfolgende Dinge wie die Zeichenfolge die für die Darstellung benötigt wird.

und auch

1+1=1

Den verstehe ich nicht.

Der Kontext ist hier nicht die Mathematik, sondern das ist zu lesen als: Fügt man ein Teil und ein weiteres Teil zusammen, ergibt sich ein (anderes/neues) Teil.

dedlfix.

[Tabellenkalk]

Hallo,

1+1=1

Den verstehe ich nicht.

Der Kontext ist hier nicht die Mathematik, sondern das ist zu lesen als: Fügt man ein Teil und ein weiteres Teil zusammen, ergibt sich ein (anderes/neues) Teil.

Ich hatte es als „True AND True ist True“ gelesen, wobei natürlich „+“ für „AND“ ungewöhnlich ist.

Gruß
Kalk

[Gunnar Bittersmann]

@@Tabellenkalk

Ich hatte es als „True AND True ist True“ gelesen, wobei natürlich „+“ für „AND“ ungewöhnlich ist.

Das ist es. Gewöhnlich steht es für oder. Und ist mal.

| 0 + 0 = 0 | 0 · 0 = 0 | 0 + 1 = 1 | 0 · 1 = 0 | 1 + 0 = 1 | 1 · 0 = 0 | 1 + 1 = 1 | 1 · 1 = 1

LLAP 🖖

[Gunnar Bittersmann]

@@dedlfix

1+1=1

Den verstehe ich nicht.

Der Kontext ist hier nicht die Mathematik, sondern das ist zu lesen als: Fügt man ein Teil und ein weiteres Teil zusammen, ergibt sich ein (anderes/neues) Teil.

Hm, ich hatte das im Kontext Mathematik gelesen: Aussagenlogik.

1 steht für wahr, + für oder. Wahr oder wahr ist wahr.

LLAP 🖖

[dedlfix]

Tach!

Hm, ich hatte das im Kontext Mathematik gelesen: Aussagenlogik.

Jeder hat da so seine eigenen Interpretationsmöglichkeiten.

Immer wenn Wind weht, bewegen sich die Bäume. Sind die Bäume die Ursache für den Wind? Die Frage oder diese Schlussfolgerung ist unsinnig, aber das weiß man erst, wenn man mehr Wissen zum Thema hat. Setzt natürlich voraus, dass man anderes Wissen an sich heranlässt und nicht nur seinen eigenen Kosmos für das maß aller Dinge hält. Allerdings ist das auch nicht immer einfach, besonders wenn man sich im Recht wähnt.

dedlfix.

[MudGuard]

Hi,

Immer wenn Wind weht, bewegen sich die Bäume. Sind die Bäume die Ursache für den Wind?

Ne, der wird doch von den Windrädern gemacht.

Merkt man doch daran, daß die Zahl der Windräder in den letzten Jahren zugenommen hat, und in der Folge dann auvh die Anzahl starker Stürme!

:-)

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@dedlfix

Immer wenn Wind weht, bewegen sich die Bäume. Sind die Bäume die Ursache für den Wind?

Ja, Wind entsteht, wenn die Bäume sich schütteln. Weiß man doch™ von Tery Pratchett.

LLAP 🖖

[JürgenB]

Hallo Christian,

1+1=1

Den verstehe ich nicht.

Logic: Wahr (1) verodert (+) mit Wahr = Wahr

Gruß
Jürgen

[Felix Riesterer]

Lieber JürgenB,

1+1=1 Logic: Wahr (1) verodert (+) mit Wahr = Wahr

dafür gibt es einen von + abweichenden Operator! Der sieht so ähnlich aus wie v.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

dafür gibt es einen von + abweichenden Operator! Der sieht so ähnlich aus wie v.

Im englischen Pendant: “The logical connective that represents this operator is typically written as ∨ or +.”

LLAP 🖖

[Gunnar Bittersmann]

@@dedlfix

Mir fallen da schon drei Möglichkeiten ein:

Musst du mir in den Rücken fallen?

1+1=2 1+1=10

https://forum.selfhtml.org/cites/543

1+1=1

Das ist logisch.

Du hast den Kontext vergessen anzugeben.

Ich würd sagen, ohne weitere Angabe gilt der übliche.

LLAP 🖖

[Tabellenkalk]

Hallo,

Ich würd sagen, ohne weitere Angabe gilt der übliche.

„Üblich“ ist für jeden was anderes, und da waren wieder unsre drei Probleme: Komm, Uni, Kation…

Gruß
Kalk

[Gunnar Bittersmann]

@@Tabellenkalk

Ich würd sagen, ohne weitere Angabe gilt der übliche.

„Üblich“ ist für jeden was anderes

In dem Fall: nein. Üblich ist das Dezimalsystem. Für jeden.

LLAP 🖖

[Rolf B]

Hallo Gunnar,

Üblich ist das Dezimalsystem

frag mal einen Historiker mit Schwerpunkt Mesopotamien…

Rolf

[Orlok]

Hallo dedlfix

Mir fallen da schon drei Möglichkeiten ein:

1+1=2 1+1=10

und auch

1+1=1

Na, dann habe ich auch noch eine:

1+1=0

Gilt im Galoiskörper GF(2), also abelsche Gruppen (G, +) und (G\{0}, ⋅), für welche die Distributivgesetze gelten, mit G = {0, 1}, also den Restklassen modulo 2.

Die additive und multiplikative Verknüpfung erfolgt jeweils modulo Anzahl der Körperelemente, es gilt also

0+0 = Rest(0, 2) = 0 ∈ G,

0+1 = Rest(1, 2) = 1 ∈ G,

1+0 = Rest(1, 2) = 1 ∈ G und insbesondere eben auch

1+1 = Rest(2, 2) = 0 ∈ G

Viele Grüße,

Orlok

[Gunnar Bittersmann]

@@Gunnar Bittersmann

1 + 1 = ?

“When 1 + 1 = 2, that happens every day, that’s not magic. […]
“But when 1 + 1 = 3, that’s when your life changes. […] It’s the essential equation of rock and roll.”
—Bruce Springsteen, Intro to ♫ Tenth Avenue Freeze-Out, Springsteen on Broadway

LLAP 🖖

[Gunnar Bittersmann]

@@pl

Nicht, dass ich nicht genügend Punkte auf dem Konto hätte, aber mal so als Idee:

Könnten wir nicht eine Liste mit Nutzern^[1] führen, wo man nicht mit Punktabzug bestraft wird, wenn man deren Postings negativ bewertet?

(Frage für einen Freund.)

LLAP 🖖

---

1. Plural, um nicht den Anschein zu erwecken, ich hätte hier einen bestimmten im Visier. ↩︎

[ursus contionabundo]

Im Hinblick auf Dein "codiertes PS" wirst Du wohl mit "Wald-Schall-Hall-Prinzip" leben müssen.

Oder glaubst Du, dass es mir nicht aufgefallen ist dass Du von "Code verkaufen" schreibst und weiter davon, dass Du der letzte seist, der den Deinen zu Gesicht bekäme, - nachdem ich davon schrieb, dass ich die auf Grund Deiner Fragestellung gewonnenen "technischen Erkenntnisse" verkaufen könne?

In dieser Situation bist Du nicht derjenige, der sich darüber echauffieren dürfte, dass man ihm das Notieren von "Unsinn" bescheinigt.

Aber kommen wir zu "was ist besser". Ein Unterscheidungsmerkmal könnte die Performance sein.

Vorstellbar wäre, dass das mehrfache Anwenden von Methoden auf ein Objekt String (ohne dessen Inhalt zu verändern!) leicht performanter ist als etwas vom Datentyp String herzunehmen und es immer wieder neu in ein Objekt wrappen zu lassen.

Also. Dieser Test benutzt mehrfach die Eigenschaft length und die Methode replace (was konkret gemacht ist allerdings nicht sinnvoll):

var s = new String('Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu');
var o = new String(s);

var tStart;
var tEnd;

console.log ('String: length ist ' +  s.length );
tStart = new Date().getTime();
for ( let i=1; i < 1000; i++ ) {
	for ( let p = 0; p < s.length; p++ ) {
	  let a = s.replace( s[p], ' ' );
	}
}
tEnd = new Date().getTime();

console.log ( 'Mit String: '  + String( tEnd-tStart ) + ' Millsekunden.');

console.log ('Objekt: length ist ' +  o.length );
tStart = new Date().getTime();
for ( let i=1; i < 1000; i++ ) {
	for ( let p = 0; p < o.length; p++ ) {
	  let a = o.replace( o[p], ' ' );
	}
}
tEnd = new Date().getTime();

console.log ( 'Mit Objekt: '  + String( tEnd-tStart ) + ' Millsekunden.');

In den meisten meiner Tests (zu rund 80%, übrigen mit sehr volatilen Laufzeiten) war hier die Bearbeitung des primitiven Strings rund 10% schneller.

Das kann aber an Optimierungen des Interpreters (hier: Node.js unter Linux) liegen.

[ursus contionabundo]

Das kann aber an Optimierungen des Interpreters (hier: Node.js unter Linux) liegen.

Und daran, dass neben dem Zugriff auf eine Ojekt-Methode (und also das als "teuer" vermutete Wrappen) auch ein wahlfreier Zugriff auf den Inhalt stattfindet. Da hat der primitive Datentyp ja Vorteile.

Wenn Du also hinsichtlich der Performance mikro-optimieren willst kommst Du kaum umhin, eigene Tests zu machen. Es sei denn, Du legst Dir sehr große Tabellen mit Laufzeiten für die verschiedenen Operationen (Zugriffe auf Eigenschaften, Methoden, Inhalte des Strings) - in Abhängigkeit von der Stringlänge - an und berechnest dann individuell was wohl schneller ist.

[Rolf B]

Hallo ursus,

da hättest Du in Zeile 1 wohl besser String("...") statt new String("...") geschrieben. So hast Du ja 2 Objekte.

Mit String und new String komme ich beim Objekt auf die 3-4 fache Laufzeit in Chrome und die 6-fache Laufzeit in Firefox. Wow!

Soviel zum Thema "Boxing kostet Zeit" bei Strings - offenbar optimieren die Browser da ordentlich.

Fazit: new String ist Mist. JSFiddle unterstreicht einem das new bei new String auch sofort und sagt: Lass das!

Rolf

[ursus contionabundo]

Tatsächlich!

Da hab ich wohl gesehen, was ich schreiben wollte - nicht was ich geschrieben habe. Die Optimierungen des menschlichen Hirns sind nicht unter allen Umständen optimal...

Hier mal eine Fassung ohne wahlfreien Zugriff.

var s = String('Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu');
var o = new String(s);

var tStart;
var tEnd;

console.log ('String: length ist ' +  s.length );
tStart = new Date().getTime();
var l = s.length;

for ( let i=1; i < 1000; i++ ) {
	for ( let p = 0; p < l; p++ ) {
	  let a = s.replace( 'foobar', ' ' );
	}
}
tEnd = new Date().getTime();

console.log ( 'Mit String: '  + String( tEnd-tStart ) + ' Millsekunden.');

console.log ('Objekt: length ist ' +  o.length );
tStart = new Date().getTime();
for ( let i=1; i < 1000; i++ ) {
	for ( let p = 0; p < l; p++ ) {
	  let a = o.replace( 'foobar', ' ' );
	}
}
tEnd = new Date().getTime();

console.log ( 'Mit Objekt: '  + String( tEnd-tStart ) + ' Millsekunden.');

Ergebnis:

String: length ist 996
Mit String: 102 Millsekunden.
Objekt: length ist 996
Mit Objekt: 347 Millsekunden.

Du hast Recht: In diesem Test sieht das Objekt "alt" aus.

Aber eigentlich ist das auch erklärbar: Wenn der Interpreter selbst die primitiven Daten in ein ihm gut bekanntes Objekt pokt, dann braucht er hinterher nicht bei jedem Zugriff untersuchen ob das Objekt diese oder jene Eigenschaft und diese oder jene Methode hat, denn das ist ja schon bekannt. Das spart ziemlich viele "Wenn-Dann-Sonst-" oder "try-catch-Konstrukte".

[Rolf B]

Hallo ursus,

es ist gar nicht so einfach, das zu benchmarken, weil ich zumindest beim Firefox Laufzeiten bekomme die sich nur durch "wegoptimieren" erklären lassen. um Umfeldeinflüsse auszuschließen, habe ich die Messschleife mal so geändert:

Schleife 1 - soll eine Baseline liefern.

let q = [];
for ( let i=1; i < 1000; i++ ) {
	for ( let p = 0; p < len; p++ ) {
    let tt = s[p];
    q.push(s)
	}
}

Läuft im Fuchs (v60.3 esr) unter 20ms durch. Chrome (v70) gut 30ms.

Schleife 2 - konstanter Replace:

let q = [];
for ( let i=1; i < 1000; i++ ) {
	for ( let p = 0; p < len; p++ ) {
    let tt = s[p];
    q.push(s.replace('a', ' '));
	}
}

Firefox etwas über 20ms. Chrome um 400-500ms (starke Schwankungen, verdammte virtuelle Maschine). Das bedeutet jetzt nicht, dass der Fuchs beim Replace rasend schnell ist, sondern dass der schlaue Fuchs offenbar erkannt hat dass hier eine Operation herausfaktoriert werden konnte.

Schleife 3 - variabler Replace:

let q = [];
for ( let i=1; i < 1000; i++ ) {
	for ( let p = 0; p < len; p++ ) {
    let tt = s[p];
    q.push(s.replace(tt, ' '));
	}
}

Firefox jetzt bei 250-300ms, mit Ausreißern unter 200 und über 400. Chrome unverändert.

D.h. die hochgelobte V8 Engine von Chrome ist hier tatsächlich vom Mozilla-Fuchs abgehängt worden. Ist natürlich nicht repräsentativ für allgemeine Performance.

Mit Objekten sieht das so aus:

Schleife 1: Fuchs 130-140ms, Chrome ebenso, scheint leicht langsamer

Schleife 2: Fuchs um 1400ms!!!!, Chrome um 750ms

Schleife 3: Zeiten unverändert.

Hier ist die Mozilla-Herrlichkeit am Ende.

Aber egal ob V8 oder Spidermonkey, es ist viel langsamer, das String-Objekt vorzuhalten statt ihn beim Aufruf ständig boxen zu lassen. Offenbar ist dieses Boxing eine Lüge für Kinder und die Wahrheit ist ganz anders...

Rolf

[ursus contionabundo]

Offenbar ist dieses Boxing eine Lüge für Kinder und die Wahrheit ist ganz anders…

Klar. Letztendlich werden doch nur Bytes in den Speicher gepookt und aus diesem herausgepeekt.

[Rolf B]

Hallo ursus,

werden doch nur Bytes in den Speicher gepookt

Pook them, peak them, their sneeky! ^[1]

Rolf

---

1. Bei Fairstenntnisproblehmen laut aussprechen und genau zuhören. ↩︎