Browsed by
Month: September 2013

Modulo dans tous ses états

Modulo dans tous ses états

Une de mes autres passions est les mathématiques, outil indispensable à l’informaticien .

Nous allons nous pencher aujourd’hui sur un élément assez controversé dans l’algorithmique et dans les mathématiques : le modulo.

Classiquement, on sait qu’un modulo est le reste de la division de deux nombres. Pour l’instant, on a juste, mais comment doit se comporter notre modulo quand on a des nombres négatifs ?

Imaginons que nous souhaitons faire la rotation d’une image selon un angle donné en argument. La fonction rotation de la librairie Imaging SDK par exemple, prend en paramètre uniquement des nombres compris entre 0 et 360. Solution : utiliser un modulo.

angle % 360

Si nous avons en entrée l’angle de 375°, un petit modulo 360 et nous passons à 15°, logique et normal. Maintenant imaginons que l’on passe l’angle de -15° en paramètre. Nous allons nous attendre à avoir 345°, mais non… le modulo nous retourne -15. Alors bug ou pas ?

Les modulos

En fait non, la subtilité est qu’il n’y a pas un type de modulo mais trois :

  • le modulo entier qui retourne un nombre entre 0 et le diviseur (si celui-ci est négatif, le résultat sera négatif)
  • le modulo tronqué qui retourne un nombre du même signe que le dividende
  • le modulo euclidien qui retourne toujours un nombre positif

Au niveau algorithmique, à titre personnel, je préfère le modulo euclidien mais dans le cas du framework .Net,c’est un modulo tronqué, dommage pour nous, c’est le seul qui ne respecte pas la loi modulaire : (x+n) mod n = x mod n

En effet,

-5 % 11 == -5

(-5+11) % 11 = 6

Le modulo euclidien en .Net

Dans notre exemple précédent, nous souhaitons utiliser un modulo euclidien, qui retourne toujours un résultat positif.

Voici une implémentation :

a<0?((a % n) + n) % n:a%n

Un peu plus lourd, mais plutôt efficace.

Et C++?

Jusqu’à C++/11, le comportement du modulo negatif n’était pas indiqué (et de façon explicite), c’était au compilateur/processeur de choisir, pas top pour la portabilité.

The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined; otherwise (a/b)*b + a%b is equal to a. If both operands are nonnegative then the remainder is nonnegative; if not, the sign of the remainder is implementation-defined.

 

Ceci dit, dans la majorité des cas, le modulo suivait les règles héritées par le Fortran, c’est à dire, le modulo tronqué.

Avec C++/11 les choses sont devenus plus clair et le choix a été fait d’utiliser obligatoirement le modulo tronqué.

The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined. For integral operands the / operator yields the algebraic quotient with any fractional part discarded;81 if the quotient a/b is representable in the type of the result, (a/b)*b + a%b is equal to a.

 

Bilan

Attention aux a priori et vérifiez toujours ce que les fonctions .Net retournent

Tester l’in-app purchase dans son application like a boss

Tester l’in-app purchase dans son application like a boss

Lorsque l’on développe une application avec in-app purchase, viens le moment où on veut la tester.

Pour cela, deux méthodes sont proposées par microsoft, histoire de gagner du temps, je vous conseille de lire l’article de Florian Rousselet qui résume très bien avec détails les deux solutions : http://blog.soat.fr/2013/09/windows-phone-8-ajouter-lin-app-purchase-a-votre-application/

Je n’aime pas la première méthode, elle est très bien pour tester rapidement, mais ce n’est pas un test en situation réelle. La seconde méthode est mieux, mais est longue (2h) et surtout impossible de déboguer son app depuis visual.

Personnellement, j’utilise une 3ème méthode, non documentée et beaucoup plus efficace. Nous allons passer par une application beta mais sans les inconvénients (attendre 2h, pas de déboguage, etc…)

Explication

Commençons par créer notre application beta, puis ajoutons lui des in-app purchase. Pour l’instant c’est très classique. Voici donc l’astuce : récupérez le product-id de votre application beta et utilisez le dans votre projet visual. C’est très simple mais pourtant “terriblement efficace”. Mieux encore, il n’est même pas nécessaire de soumettre votre application beta, voire même d’envoyer un xap.

Une fois votre application déployée sur votre téléphone, elle va interroger les serveurs de microsoft en utilisant son product-id pour savoir quels sont les in-app purchase qui lui sont accessible, mais comme le product-id correspond à une vrai application (beta), le serveur va bel et bien vous retourner les in-app purchase de votre application beta.

Vous pourrez ainsi déboguer votre application dans des vrais conditions, sans attendre et surtout directement depuis votre visual.

Comment récupérer le product id de mon application beta.

  • Créer une nouvelle application et indiquez bien que c’est une application beta.
  • Ne passez pas par l’étape 2, retournez sur le dashboard puis dans apps et retournez sur la fiche de votre application

Capture

 

  • cliquez sur “Products” et sur “add products”

Capture

 

  • ajoutez vos in-app purchase
  • une fois tout ceci fait, regardez l’url de votre page, celle-ci doit ressembler à :

https://dev.windowsphone.com/en-us/ApplicationDetails?productId=2017469a-6b04-467f-b57d-90a892a7ed8b&applicationDetailsView=2

Votre product-id est dedans, dans notre cas : 2017469a-6b04-467f-b57d-90a892a7ed8b

  • changez la valeur du product-id dans votre WMAppManifest.xaml
  • dites vous que vous avez gagnez bcp de temps et d’énergie