Roten ur 2^6^2^1^4^4?

Ja då är det bara att starta räjset och hitta a b n som är störst.

Jag pratar inte om någon inneboende rimlighet, utan enbart utifrån det faktum att potenstorn är väldefinierade.

Inte om det är så att betydelsen (a^b)^c naturligt uppkommer betydligt oftare än a^(b^c)

Trots allt är det liknande skäl till att multiplikation har högre prioritet än addition. Det är för att slippa skriva så mycket parenteser.

Mitt resonemang utgår alltså från att det redan finns ett etablerat regelverk för det hela. Det handlar inte utifrån om regelverket i sig är vettigt. Ett mer extremt exempel för att tydliggöra: Det kanske inte finns några inneboende egenskaper hos + och - som gör att + bör betyda addition och - subtraktion, men du håller väl med om att det vore oerhört märkligt att skapa ett programmeringsspråk där man byter plats på dem? Eller för den delen byta plats på betydelsen av "if" och "else"?




Så är det, men to be fair är det en sak man fuskar friskt med i matematik också.

Sen har jag ju pratat om att man bör följa konventioner, men det går att applicera på andra saker också. Det finns en poäng i att när man definierar matematiska symboler i ett programmeringsspråk så bör det vara likt matematiken, men det finns också en poäng i att programmeringsspråk liknar varandra. Vilket iof också är ett argument som går att använda för att säga att a^b^c bör betyda (a^b)^c, just eftersom det redan finns programmeringsspråk som betyder så. Så mitt resonemang är egentligen bara fullt ut applicerbart på de första programmeringsspråken.

Tror jag har stött på frågan om a^b^c betyder (a^b)^c eller a^(b^c) max 3 gånger under min långa intensiva karriär och har inte lagt regeln på minnet. Det viktiga är att det finns i programspråkets dokumentation. Annars är det ganska lätt att prova.

Du har rätt att i om (a^b)^c naturligt uppkommer betydligt oftare än a^(b^c) så sparar man 2 bytes i programkoden på att skriva a^b^c istället för (a^b)^c om det är den konvention programspråket använder. Maskinkoden blir väl likadan oavsett. Men visst om du ska spara programkoden på en magnetremsa från 1971 så sparar du ett par ören.

Maskinkoden blir lika ja. Fast i ett interpreterande språk som basic så är det även en prestandavinst.

Men sen vet jag ju inte om det verkligen fanns en motivering till att associativiteten blev som den blev. Det kan ju vara så enkelt att de behövde välja och bara tog något. Dock vet jag att liknande beslut har tagits historiskt för att spara minne. Och det har inte främst med just lagringen på magnetremsa att göra, utan helt enkelt hur mycket koden tar upp i minnet vid kompilering. Den dator som var det främsta målet för språket C var en PDP-7 som hade ca 9kB minne. Varje byte räknades.

(Som referens kan nämnas att det här inlägget tar upp 1360 bytes, dvs 15% av minnet i en PDP-7)

Prestandavinst? Förklara!

Färre bytes som ska läsas

I så fall borde någon slags kodning tillämpas. Till exempel ersätta det vanligen förekommande ordet "PRINT" med något annat.

Sådant gjordes på C64-tiden

Det kan jag tro.

Ja jag får ge dig i princip rätt i den här diskussionen att det kan ha varit så att tolkningen a^(b^c) eller (a^b)^c kan vara styrd av minneskapacitet. Men jag tror att det inte är så.

Ja, som sagt så är det bara en hypotes.

En annan är att det kan ha bestämts för att det ska bli lättare att skriva in när man kodar.