Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!usenet.pasdenom.info!from-devjntp
Message-ID: <-LHcD7_J_uJwx86b1GkS6xcw6C8@jntp>
JNTP-Route: news2.nemoweb.net
JNTP-DataType: Article
Subject: Re: Puissance complexe
References: <HwTeGQkWMXTC_jEOcdWNdVgHJYM@jntp> <sq3v0q$1qbf$1@gioia.aioe.org> <R4Hq5aAGBttRUUh3BwrfRoXc2A0@jntp>
 <sq4hdk$1mtk$1@gioia.aioe.org> <RFOHtFeuO_L-7PrXkmYOlZ72lkM@jntp> <sq4l35$18ft$1@gioia.aioe.org>
 <5NVwTWcIMgJnmo4ciRQHjnauwEc@jntp> <sq4mgm$1svf$1@gioia.aioe.org> <ucBR9OpYq67wtk9Stf-Ymc0OJjg@jntp>
 <sq5bn5$169p$1@gioia.aioe.org>
Newsgroups: fr.sci.maths
JNTP-HashClient: ZDsenSlRbzJZBtTvxzlvrS-N4nE
JNTP-ThreadID: 0n0919F69IreuR1l8nnlTNB_YYY
JNTP-Uri: http://news2.nemoweb.net/?DataID=-LHcD7_J_uJwx86b1GkS6xcw6C8@jntp
User-Agent: Nemo/0.999a
JNTP-OriginServer: news2.nemoweb.net
Date: Sat, 25 Dec 21 16:46:06 +0000
Organization: Nemoweb
JNTP-Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36
Injection-Info: news2.nemoweb.net; posting-host="c1851bd4b4f9399f317e25a013e00109bcf90c00"; logging-data="2021-12-25T16:46:06Z/6426910"; posting-account="1@news2.nemoweb.net"; mail-complaints-to="newsmaster@news2.nemoweb.net"
JNTP-ProtocolVersion: 0.21.1
JNTP-Server: PhpNemoServer/0.94.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-JNTP-JsonNewsGateway: 0.96
From: Julien Arlandis <julien.arlandis@gmail.com>
Bytes: 4213
Lines: 49

Le 24/12/2021 à 21:48, Samuel DEVULDER a écrit :
> Le 24/12/2021 à 15:58, Julien Arlandis a écrit :
>> Autre façon de voir les choses, c'est d'évaluer l'expression pour toutes 
>> les valeurs entières de k modulo 8, c'est ce que j'ai fait et il n'y a 
>> que 4 valeurs différentes.
> 
> S'il n'y a qu'un seul "k" c'est pareil. Tu lie arbitrairement les deux 
> termes de 1^(1/2) + 1^(1/4). Je ne sais toujours pas si c'est légitime.
> 
> Je pense que le problème est mal posé en parlant de valeur de 
> l'expression numérique 1^(1/2) + 1^(1/4) "sans contexte".

On se retrouve devant une expression mal définie, comme lorsqu'on veut 
évaluer l'expression 1/2*2, en l'absence de parenthèses pour définir 
les priorités, seule une convention peut permettre de décider entre les 
valeurs 1 et 1/4.
Quand on écrit 1^(1/2) et qu'on attend une valeur dans C, l'information 
est incomplète car la fonction racine est sensible à la phase de 
l'argument.
L'expression exp(2iπ)^(1/2) ne souffre d'aucune ambiguïté et le 
résultat est incontestablement exp(iπ)=-1. Il faut alors considérer que 
les nombres exp(2iπ) et exp(4iπ) sont des nombres qui ne sont pas 
équivalents pour certaines applications et que le nombre 1 est une 
notation ambigüe qui désigne n'importe quel nombre parmi exp(2ikπ).
Dans ce cas 1^(1/2) est une expression mal définie, on pourrait 
compléter la notation en notifiant la phase entre crochets (forcément un 
multiple de 2π) pour lever l'indétermination :
(1[0])^(1/2) = 1 mais (1[2π])^(1/2) = -1.

1^(1/2) + 1^(1/4) pourrait très bien désigner (1[2π])^(1/2) + 
(1[4π])^(1/4) = -2 mais cette expression souffre d'un défaut d'accord de 
phase (*) entre les expressions. Cela pourrait faire l'objet d'une 
convention qui ferait le choix de conserver l'accord de phase, ce qui 
semble assez raisonnable. Cela présente l'avantage comme on l'a vu de 
conserver les propriétés de factorisation. Sous cette convention, on 
voit que les expressions 1^(1/2) et 1^(1/4) ne désignent jamais la valeur 
-1 lorsqu'ils sont en phase et par conséquent leur somme ne peut pas 
valoir -2.

Pour finir, je ne suis pas certain que les surfaces de Riemann nous soient 
d'un grand secours dans la manière d'évaluer des expressions comme 
1^(1/2) + 1^(1/4), il s'agit juste de se mettre d'accord sur les 
conventions à définir pour lever les ambiguïtés.

(*) Attention je fais une différence entre phase et argument, par exemple 
-1[0] désigne exp(iπ)
et i[2π] désigne exp(5iπ/2).