Bonjour,

 Cliquez pour afficher

On observe que 3²=9 donc 1 chiffre et que 4²=16 donc 2 chiffres
le passage se fait dès 10 qui n'est pas entier donc 4.
Ce passage aura lieu tous les multiples de10
par exemple 31²-->3 chiffres mais 32 ²--->4 chiffres

Je vais dire  si n possède c chiffres n² en possèdera 2c-1 si n< |(10^c)| et 2 si n

Suite,
En testant,je corrige ...

 Cliquez pour afficher

soit n avec c chiffres:
n² --->2c-1 chiffres si  n<|(10^2c-1)|
et --->2c si n

Bonjour

Pour un entier n le nombre de chiffres de n² est :

 Cliquez pour afficher

Bonjour et bravo
Une expression simple pour le nombre de chiffres de n²:
N =E(2.log(n))+1

Mon système fonctionne sans logarithme.
l'expression de imod  est bonne avec ln
celle de flight est bonne avec log

C'est une question d'âge sans doute, mais pour moi et on j'écris explicitement pour le log en base b.

La formule vient simplement du fait qu'un nombre p a n chiffres en base b si et seulement si , parce que le plus grand nombre à n-1 chiffres a pour écriture .
Cette inégalité est équivalente à , qui équivaut à son tour à .

Un autre truc rigolo mais sans rapport est le fait que pour tout réel x, , ce qui veut dire que .
Donc en python, pas besoin de se fatiguer à écrire importer math.ceil

import math
def div_ceil(a, b):
  return math.ceil(a / float(b))

def div_ceil(a, b):
  return -( (-a) // b )

Désolé, il y a des coquilles mais dans le code je voulais dire

return int(math.ceil(a / float(b)))

>Ulmiere,
Comme les formules  de Imod et de flight différent, c'est qu'ils ont utilisé le logarithmes de façon différente.

@Ulmiere
Je ne suis pas sûr qu'en python ce soit intéressant de rendre si peut clair le code pour un gain de performance plutôt minime.

En python 3.10+, math.ceil retourne déjà un entier.
En python 3.x, il n'y a pas besoin de convertir b en float, l'opérateur de division retourne déjà un float.
Mais je suis d'accord qu'il n'y a pas besoin de passer par les floats et que ça peut poser problème pour les grand nombres entiers.
J'utilise personellement (a+b-1)//b

J'ai déjà vu la notation tableau[~i] pour indexer depuis l'arrière. Je la trouve élégante. Mais en partique elle est très peu utilisée et apporte plus de confusion qu'autre chose.
Note: On écrit habituellement tableau[-1-i] pas besoin de rajouter la longueur du tableau en python.

Il y a encore beaucoup de code qui tourne encore sous python 3.x avec x < 10, voire même python 2.
Si on peut éviter les imports inutiles ou les __import__("math").ceil()...
La seule objection que j'ai contre (a+b-1)//b, c'est que b est référencé deux fois, donc il faut d'abord créer une variable b = f() avant d'inliner cette formule, alors que tu peux écrire directement -((-a)//f()).

L'intérêt de ~i, c'est surout pour éviter les offset by one.
Par exemple si tu as deux tableaux de longueur n

for i in range(n):
  a = tab1[i]
  b = tab2[-1-i]

La dernière version de python 2.x est sortie il y plus de 4 ans. 2.x est obsolete depuis bien plus longtemps que celà.
Python 3.10 est sorti il y a plus de 2 ans.

Le standard dans ma profession est mettre à jour vers 3.11 et utiliser 3.12 pour le nouveau code.

Après je ne tout dépend de ce que tu fais avec. Je préfère de loin un import (d'une librairie incluse d'office de plus) qu'un code difficile à lire et maintenir.
De la même façon, donner un nom à une valeur aide à la lisibilité et donc je préfère de loin déclarer b plutôt qu'inliner f() et tous ses arguments.

Pour tab[~i], je suis d'accord avec toi. Sauf que l'opérateur ~ est trop rarement utilisé (en python) pour que cette notation soit évidente pour la plupart des gens.
Je l'ai vu dans des 'code golf' (on essaie de minimiser le nombre de caractères) et avec numpy pour inverser une sélection. Par exemple: array[~array.isnan()].