Discussion :

[camer12]

Salut ,
j'aimerai calculer dans mon code le temps qu'un avion fait de l'aeroport A à l'aeropor B connaissant la distance de A à B et la vitesse de l'avion. En realité la distance est en km et la vitesse en km/h, donc je devrais avoir temps en heure. Au depart j'ai pri la distance en "int" et la vitesse aussi en "int" donc temps que je trouve est en "int", pour la suite de mon programme j'ai besoin du temps en "heure". Il y a t-il une correspondace du km et du km/h en c#?

[Nathanael Marchand]

Bon déjà manipuler des entiers c'est pas super genial pour la précision... Je conseille des float ou des double.
Ensuite, si tu divises des km par des km/h alors tu auras des heures... Ton entier et donc le nombre d'heures.

[camer12]

ca veut dire que le double que j'obtiens je le transforme en DateTime?

[giova_fr]

non

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new SpanTime(resultat, 0,0);

0 car tu travaille avec des entiers, donc tu ne semble pas etre à la minute ou seconde pres

[tomlev]

Au depart j'ai pri la distance en "int" et la vitesse aussi en "int" donc temps que je trouve est en "int", pour la suite de mon programme j'ai besoin du temps en "heure".

J'ai l'impression que tu mélanges 2 concepts... int est un type de données qui représente un nombre entier sur 32 bits. heure est une unité de mesure, pas un type ; il n'y a pas de type particulier pour représenter des heures (bien qu'on pourrait le créer). Dans le code tu représentes le nombre d'heures par un nombre (int, double...), mais ce nombre ne contient pas d'information sur l'unité, c'est à toi de savoir que ce sont des heures.

A noter que certains langages, comme F#, intègrent le principe des unités ; par exemple si on divise des km par des km/h, on obtient bien des heures... une fonctionnalité que j'aimerais bien avoir en C#

EDIT: exemple en F# :

Code F# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
[<Measure>] type km
[<Measure>] type h
 
let speed = 200.0<km/h>
let distance = 1500.0<km>
let time = distance / speed

[theMonz31]

bonjour

Pour adresser un tel problème, je travaillerais tout en unité SI (système international), donc, pour moi, les vitesses seraient en m/s, les distances en mètres et tous les calculs fait en double ou float.

Ce n'est que pour la représentation et l'affichage des données que je basculerais dans un affichage plus approprié (Heure/Minute/seconde (si pertinent)..

En règle général, il est plus "logique" de travailler avec la "plus" petite unité quand on fait des calculs pour avoir un maximum de précision et uniquement à l'affichage, d'arrondir pour rentrer dans les unités usuelles d'affichage.

Maintenant, c'est ma vision des choses, elle n'est ni unique, ni forcément parfaite.. juste le fruit d'une "intense" réflexion et d'un peu d'expérience

[kheironn]

Je suis d'accord sur la manipulation des USI.

Après t=d/v, ce sont des maths (en fait de la physique) de base, et il faut avoir des mesures homogènes en termes d'unités (il faut faire les conversions).

Ainsi t=d/v, en équation aux dimensions, donne s=m/m.s^-1.

Par contre, pour des calculs, je ne suis pas fan des nombres à virgule flottante qui génèrent des erreurs d'arrondi.

[tomlev]

Par contre, pour des calculs, je ne suis pas fan des nombres à virgule flottante qui génère des erreur d'arrondi.

C'est pourtant la représentation recommandée dès lors que tu travailles sur des grandeurs physiques. Certes, la représentation n'est pas exacte, mais dans le cas d'une grandeur physique, la mesure au départ n'est pas exacte non plus, alors...

[Bluedeep]

Par contre, pour des calculs, je ne suis pas fan des nombres à virgule flottante qui génère des erreur d'arrondi.

Cet argument est peu pertinent.

D'une part il existe des règles d'arrondi (et elles sont normalisées, notamment d'un point de vue comptable) et si les performances ne sont pas ta priorité il existe en .Net le type decimal qui est un stockage ciblé sur le nombre de chiffres significatif (contrairement aux types double et float qui sont des stockages mantisse+exposant) qui limite considérablement ce type de problème.

[kheironn]

C'est pourtant la représentation recommandée dès lors que tu travailles sur des grandeurs physiques. Certes, la représentation n'est pas exacte, mais dans le cas d'une grandeur physique, la mesure au départ n'est pas exacte non plus, alors...

Je ne suis pas d'accord sur la précision, je me souviens avoir travaillé en fac sur des ordres de grandeur de 10^-17, ce qui est vraiment précis ! Tout dépend du domaine, en physique quantique il faut une précision... Quantique !
Et je trouve qu'un type qui fait 10.6-10 = 0.5999999999 n'est pas apte à servir pour des maths. Mais bon, je plus un scientifique qu'un informaticien dans l'âme. Pour moi, la précision dans les calculs est importante, d'autant plus si les valeurs calculées servent à refaire des calculs derrière.

De même, quant on travaille sur des grandes valeurs, la précision peut donner de graves erreurs. si l'on calcule une distance parcourue par la lumière en 1 an on a des suprises : aprox : c = 300Gm.s^-1 => 9467280000000 km
réel c = 299792458 m.s^-1 => 9460730472580,8 km
ça fait 6549527419,2 km d'écart sur 1 an, imagine sur 93 GAL qui est la taille estimée de l'univers. D'accord, celà ne représente qu'une faible erreur sur des estimations... par contre, place toi dans un cadre (hypothétique) où on maitrise le voyage hyperspatial et pouf ! dans une étoile à la place de l'orbite d'une planète choisie...
Mon exemple est peut-être fallacieux, mais il montre pourquoi, la précision est importante.

... Edit : oui, Bluedeep. Personnelement je préfère le type decimal. Et c'est pour ça que j'ai parlé de préférence et non d'argument (aussi bien ici que plus haut)

[Bluedeep]

J
A noter que certains langages, comme F#, intègrent le principe des unités ; par exemple si on divise des km par des km/h, on obtient bien des heures... une fonctionnalité que j'aimerais bien avoir en C#

Ben, en C# on peut faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MeterPerSecond mps = 100.0;
Meter distance = 10.0;
TimeSpan temps = mps / distance;

Suffit de rajouter un peu de code dans un coin
:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
  class MeterPerSecond
{
	private double _value;
	public MeterPerSecond(double value)
	{
		_value = value;
	}
	public static Meter operator /(MeterPerSecond vitesse, TimeSpan time)
	{
		return new Meter(vitesse._value / time.TotalSeconds);
	}
	public static TimeSpan operator /(MeterPerSecond vitesse, Meter distance)
	{
		return new TimeSpan(0, 0, (int)(vitesse._value / distance.Value));
	}
 
	public static implicit operator MeterPerSecond(double val)
	{
		return new MeterPerSecond(val);
	}
	public static implicit operator double(MeterPerSecond val)
	{
		return val._value;
	}
 
}
 
class Meter
{
	private double _value;
	public double Value
	{
		get { return _value; }
	}
 
	public Meter(double value)
	{
		_value = value;
	}
 
	public static implicit operator Meter(double val)
	{
		return new Meter(val);
	}
	public static implicit operator double(Meter meters)
	{
		return meters.Value;
	}
	public static MeterPerSecond operator /(Meter meter, TimeSpan time)
	{
		return new MeterPerSecond(meter.Value / time.TotalSeconds);
	}
}

[tomlev]

Je ne suis pas d'accord sur la précision, je me souviens avoir travaillé en fac sur des ordres de grandeur de 10^-17, ce qui est vraiment précis ! Tout dépend du domaine, en physique quantique il faut une précision... Quantique !

Double.Epsilon = 4.94065645841247e-324
C'est la plus petite différence possible entre 2 valeurs de double. Il me semble que c'est assez précis pour la plupart des usages, non ?

Et je trouve qu'un type qui fait 10.6-10 = 0.5999999999 n'est pas apte à servir pour des maths. Mais bon, je plus un scientifique qu'un informaticien dans l'âme. Pour moi, la précision dans les calculs est importante, d'autant plus si les valeurs calculées servent à refaire des calculs derrière.

Cette imprécision n'apparait que pour la représentation en base 10. En interne, le nombre est en binaire et a une précision de Double.Epsilon. Si tu as besoin de faire des calculs exacts en base 10, effectivement double n'est pas adapté, et tu vas utiliser plutôt decimal qui est fait pour ça.

Le type decimal que tu sembles préférer a été conçu pour une seule raison : faire des calculs exacts en base 10, notamment pour les calculs financiers. Pour tout le reste, notamment les grandeurs physiques, double est parfaitement adapté.

Si les représentations en virgule flottante existent depuis si longtemps dans tous les langages sans être remises en question, c'est qu'il y a de bonnes raisons... à moins que tu penses être plus malin que tous les gourous de l'informatique qui sont arrivés à cette solution

cf. ces questions sur StackOverflow pour de meilleures explications :
http://stackoverflow.com/questions/2...l-and-a-double
http://stackoverflow.com/questions/8...ead-of-decimal

Ben, en C# on peut faire :
...

Certes... mais c'est du spécifique : pour chaque unité tu vas devoir créer un type spécifique, avec les conversions et les opérateurs qui vont bien. Toutes les unités doivent être prédéfinies. Alors qu'en F#, si tu crées les unités km et h, il comprend tout seul que la division donne des km/h, sans que tu aies besoin de déclarer cette unité.

[Bluedeep]

Certes... mais c'est du spécifique : pour chaque unité tu vas devoir créer un type spécifique, avec les conversions et les opérateurs qui vont bien.

C'est bien pour cela que j'avais mis un smiley.

[Er3van]

Et puisqu'on chipote sur des grandeurs de l'ordre de 1E-324, je pense que je peux me permettre cette remarque :

A moins que l'avion ait une accélération infinie (physiquement impossible), et A et B soit séparés par une ligne parfaitement droite (quasi impossible sur Terre si la distance dépasse les 100km), y compris dans l'alignement des pistes de décollage et d'atterrissage, la durée du trajet entre A et B n'est pas tout à fait distance/vitesse, et là l'écart entre théorie et pratique est supérieur à Double.Epsilon

[Alikendarfen]

Ben dites donc... que de commentaires !! C'est intéressant, mais je n'ai pas l'impression que tout ça soit dans le scope de ce que cherche camer12

Je dirais quand même à camer12 qu'il devrait laisser tomber les entiers pour des doubles ou flottants : sinon, dans la pratique (trajet en France par exemple), tu vas toujours avoir 0 ou 1 (voire 2 au pire) comme résultat !! Sauf pour de tous petits avions qui ne vont pas vite !!



... pour info encore, je crois qu'il y en a sur ce site qui travaillent sur les unités de mesures : projet dvp.net http://www.developpez.net/forums/d10...n-0-4-dvp-net/

[tomlev]

... pour info encore, je crois qu'il y en a sur ce site qui travaillent sur les unités de mesures : projet dvp.net http://www.developpez.net/forums/d10...n-0-4-dvp-net/

En effet, mais ça ne répond pas vraiment à la problématique du PO... l'API actuelle ne permet pas de diviser ou multiplier des unités entre elles, seulement de manipuler des valeurs dans une unité donnée et de les convertir dans d'autres unités

[Pol63]

Ben dites donc... que de commentaires !! C'est intéressant, mais je n'ai pas l'impression que tout ça soit dans le scope de ce que cherche camer12

oui ... autant de discussion et de précision pour répondre à une question sur la modélisation d'un problème niveau primaire

[Alikendarfen]

En effet, mais ça ne répond pas vraiment à la problématique du PO... l'API actuelle ne permet pas de diviser ou multiplier des unités entre elles, seulement de manipuler des valeurs dans une unité donnée et de les convertir dans d'autres unités

J'ai bien vu, mais justement, c'est plutôt l'inverse : il faudrait enrichir cette lib des remarques de ce thread...

... car au fond : convertir des distances en temps, c'est possible pourvu qu'on connaisse la vitesse... c'est donc bien une conversion mais contextuelle

[tomlev]

J'ai bien vu, mais justement, c'est plutôt l'inverse : il faudrait enrichir cette lib des remarques de ce thread...

Oui, j'aimerais bien ajouter ce genre de fonctionnalité, mais ce n'est pas évident... en fait je voudrais pouvoir faire comme en F#, mais je n'ai pas l'impression que ce soit possible... pour ça il faudrait pouvoir définir des opérateurs génériques. Quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public static FractionalUnit<Meter, TOtherUnit> operator /<TOtherUnit>(Meter m, TOtherUnit o)
{
    return new FractionalUnit<Meter, TOtherUnit>(m.Value / o.Value);
}

Ce qui permettrait d'écrire ce genre de choses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Meter distance = 100.0;
Second time = 9.58;
var speed = distance / time;
// speed est de type FractionalUnit<Meter, Second>
// le symbole est "m/s", déterminé par les symboles des 2 composants

Malheureusement les opérateurs génériques ne sont pas supporté en C#, donc pas possible de faire comme ça.

Evidemment on pourrait coder en dur des divisions par différentes unités, par exemple pour que la division par des secondes renvoie des MeterPerSecond, mais :
1) c'est assez fastidieux, même si on utilise des templates T4 pour générer le code
2) à chaque fois qu'on ajoute une unité, il faudrait modifier toutes les autres pour gérer les divisions par cette nouvelle unité. Or je veux que l'API reste extensible, et que ça puisse fonctionner de la même manière avec des unités créées par l'utilisateur... donc cette option ne convient pas non plus...

Bref, tout ça pour dire que ça ne se fera probablement pas ; il reste possible de faire comme ça, à condition de définir les unités qui vont bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Meter distance = 100.0;
Second time = 9.58;
MeterPerSecond speed = distance.Value / time.Value;

Mais bon, ça n'a pas un intérêt fou il me semble... De toutes façons le but de cette API est avant tout la conversion d'unités, pas les calculs savants

(désolé pour ce long hors-sujet )

... car au fond : convertir des distances en temps, c'est possible pourvu qu'on connaisse la vitesse... c'est donc bien une conversion mais contextuelle

Ce n'est pas une conversion, c'est un calcul...

[Alikendarfen]

donc pour répondre à la question du PO (sur l'injonction de tomlev ! ) :

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

TimeSpan ts = TimeSpan.FromHours( (double)distance / (double)vitesse );

Ce qui reste vrai pour des vitesses raisonnables. Sinon le temps dépend du référentiel... (l'avion ou la terre, en l'occurrence)