[C++] float, double, pow(f)

[MarcHeijerman]

Hi all,

ben bezig met wat wiskundige oefeningen met C++. Nu heb ik een vraag, of eigenlijk ook meteen een voorbeeld.

op de screenshot is voorbeeld code uit een course te zien. Dit werkt voor de meneer die het uitlegt, maar voor mij met mijn Visual Studio niet.



de lijn met area = pi * pow(radius, 2); werkt bij mij niet, wanneer ik pow verander naar powf, werkt het wel.

Waarom werkt dit bij mij alleen met powf en bij de video meneer met pow ?

Zie de logica even niet.

[ZaPPZion]

Gebruikt de videomeneer dezelfde strictheid en dezelfde ontwikkelomgeving? Het kan zijn dat verschillende compilers en zelfs verschillende compiler flags andere regels hebben.

[MarcHeijerman]

In de course wordt gebruik gemaakt van code blocks, maar ik ging er eigenlijk een beetje vanuit dat de C++ functies toch wel het zelfde zouden moeten zijn (over het algemeen)

Heb nu het zelfde met:

sqrt(144); // werkt niet
sqrtf(144); // werkt wel.

[farlane]

Welke melding krijg je dan?

[MarcHeijerman]

more than one instance of overloaded function "sqrt" matches the argument list.

[Nactive]

nvm,. mijn post klopt niet denk ik

[ Voor 93% gewijzigd door Nactive op 27-05-2012 13:47 ]

[IceM]

Volgens de msdn heeft sqrt twee drie overloads, 1 met een float als argument en 2 met een double als argument. Waarschijnlijk gaat het mis omdat je een int opgeeft die zowel naar een float als een double gecast kan worden. Zelfde geld voor pow, powf

[MarcHeijerman]

Nactive schreef op zondag 27 mei 2012 @ 13:46:
powf is pow alleen voor floats dus kan hij ondubbelzinnig converteren.
pow gewoon heeft verschillende definities, dus hij weet niet naar welke hij uw radius moet casten, definieer uw radius als double en het is waarschijnlijk opgelost:

code:

   double pow (      double base,      double exponent );
long double pow ( long double base, long double exponent );
      float pow (       float base,       float exponent );
     double pow (      double base,         int exponent );
long double pow ( long double base,         int exponent );

Hij kan gewoon niet kiezen tussen de laatste twee denk ik.


Btw, in het voorbeeld compileert hij daar ook met visual studio, of met een andere compiler ?

Hij gebruikt inderdaad een andere compiler, code blocks.

[MarcHeijerman]

IceM schreef op zondag 27 mei 2012 @ 13:47:
Volgens de msdn heeft sqrt twee drie overloads, 1 met een float als argument en 2 met een double als argument. Waarschijnlijk gaat het mis omdat je een int opgeeft die zowel naar een float als een double gecast kan worden. Zelfde geld voor pow, powf

Ik vond het in ieder geval appart dat het dus niet met verschillende compilers hetzelfde werkt, terwijl dit volgens mij gewoon echt basic en build in functions van C++ zijn.

[Orwell]

MarcHeijerman schreef op zondag 27 mei 2012 @ 13:50:
Ik vond het in ieder geval appart dat het dus niet met verschillende compilers hetzelfde werkt, terwijl dit volgens mij gewoon echt basic en build in functions van C++ zijn.

Hangt ervan af aan wie je het vraagt.

Maar ehm, even over het probleem: probeer je constante 2 is als 2.0f mee te geven. Hiermee geef je aan de compiler aan dat die constante een float is, en geen double of wat dan ook.

Alles met een 'f' erachteraan wordt als float gezien, alles zonder, maar wel met kommagetallen als double, en integers gewoon als integers natuurlijk. Nu moet die arme compiler maar gokken welke pow hij moet gebruiken.

[ Voor 17% gewijzigd door Orwell op 27-05-2012 13:54 ]

[IceM]

Hier staat ook geen overload die een int als argument neemt, dus ik vind het vrij normaal gedrag van de VS compiler.

[MarcHeijerman]

Het zal ook ongetwijfeld normaal gedrag zijn, ik vond het alleen appart (imo) dat dezelfde functies niet hetzelfde reageren in 2 verschillende compilers.

Zal ook ongetwijfeld aan mij liggen... :-)

[MarcHeijerman]

Orwell schreef op zondag 27 mei 2012 @ 13:52:
[...]


Hangt ervan af aan wie je het vraagt.

Maar ehm, even over het probleem: probeer je constante 2 is als 2.0f mee te geven. Hiermee geef je aan de compiler aan dat die constante een float is, en geen double of wat dan ook.

Alles met een 'f' erachteraan wordt als float gezien, alles zonder, maar wel met kommagetallen als double, en integers gewoon als integers natuurlijk. Nu moet die arme compiler maar gokken welke pow hij moet gebruiken.

Hoe kan je dit volgens jou het beste uitvoeren dan ?

[Orwell]

MarcHeijerman schreef op zondag 27 mei 2012 @ 13:55:
Het zal ook ongetwijfeld normaal gedrag zijn, ik vond het alleen appart (imo) dat dezelfde functies niet hetzelfde reageren in 2 verschillende compilers.

Zal ook ongetwijfeld aan mij liggen... :-)

Dat komt doordat Microsoft en de mensen van GCC het niet helemaal eens zijn over heel wat dingen. En omdat Microsoft een hele rits overloads heeft toegevoegd. Ook pakken MSVC en GCC het waarschuwen over het gokken met overload kiezen anders aan.

[Nactive]

Ik heb juist getest.

In Windows kan ik met visual studio alleen compileren met double als radius. In Unix kan ik met gcc ook met int compileren .

Dus is in ieder geval een compiler verschil (denk ik).

[MarcHeijerman]

Nactive schreef op zondag 27 mei 2012 @ 13:57:
Ik heb juist getest.

In Windows kan ik met visual studio alleen compileren met double als radius. In Unix kan ik met gcc ook met int compileren .

Dus is in ieder geval een compiler verschil (denk ik).

Had mijn Linux nog niet opgestart :-), maar dat is inderdaad een handige test

[Orwell]

Hmm, hier met TDM-GCC (lijkt op de compiler van Code::Blocks) kan ik er met elke mogelijke warningoptie geen warning of error uitkrijgen.

Maar heb je die .f suffix nog geprobeerd?

[MarcHeijerman]

Orwell schreef op zondag 27 mei 2012 @ 13:59:
Hmm, hier met TDM-GCC (lijkt op de compiler van Code::Blocks) kan ik er met elke mogelijke warningoptie geen warning of error uitkrijgen.

Maar heb je die .f suffix nog geprobeerd?

Nog niet, zit nu met:

cout << sqrt(144);

144 is volgens mij een int ?
waarom dit dus alleen werkt met:

cout << sqrtf(144);

is nog niet duidelijk, mischien zie ik het gewoon even niet.

[Orwell]

Omdat de compiler dan weet welke versie van de functie je dan wilt hebben.

Hoe moe die arme compiler nu weten (in het geval van pow) dat je die ene pow(iets,int) wilt hebben? Hij kan kiezen uit een stuk of drie versies (elk met een andere base), maar hij gaat niet zelf voor je kiezen. En dat is precies wat de warning (of error) zegt: je code is te dubbelzinnig.

Het is trouwens wel zo dat GCC hier heel wat makkelijker over doet.

Maar ehm, geef in het geval van constantes waar het nut heeft zoveel mogelijk het een suffix aan wat voor type je wilt hebben. Zo kan je dus duidelijk maken dat het tweede argument van pow bijvoorbeeld een float is. En als dat een float is, kan de compiler maar uit één functie kiezen.

[ Voor 32% gewijzigd door Orwell op 27-05-2012 14:11 ]

[Nactive]

Vanop de msdn

C++:

double sqrt(
   double x 
);
float sqrt(
   float x 
);  // C++ only
long double sqrt(
   long double x
);  // C++ only
float sqrtf(
   float x 
);

sqrt is niet gedefinieerd voor een int, hij zal dus moeten converteren. Bij het converteren weet hij niet naar waar dus geeft hij u een error in visual studio. sqrtf is maar gedefineerd alleen voor floats. Dus convert hij uw int gewoon naar een float zonder problemen.

[MarcHeijerman]

Ok, nu klinkt het logisch :-)
gewoon van te voren even aangeven welk type 144 is dus

double i =144;
cout << sqrt(i);

werkt

[MarcHeijerman]

volgende keer maar de zelfde compiler als de course meneer gebruiken :-)

[Orwell]

Ja, dat dus. Of korter met suffixes:

MSDN: C++ Floating-Point Constants (C++)

Floating-point constants default to type double. By using the suffixes f or l (or F or L — the suffix is not case sensitive), the constant can be specified as float or long double, respectively.

Daarmee fix je dus die dubbelzinnigheid.

[ Voor 5% gewijzigd door Orwell op 27-05-2012 14:13 ]

[MarcHeijerman]

Bedankt voor de verschillende uitleg, heeft weer wat duidelijkheid gegeven :-)

[Soultaker]

Orwell schreef op zondag 27 mei 2012 @ 13:56:
Dat komt doordat Microsoft en de mensen van GCC het niet helemaal eens zijn over heel wat dingen.

Met onenigheid heeft het weinig te maken; Microsoft lapt de standaard aan z'n laars en GCC niet.

Ook pakken MSVC en GCC het waarschuwen over het gokken met overload kiezen anders aan.

Het gaat niet om een waarschuwing; het gaat om een foutmelding. Als je overloaded versies van een functie introduceert krijg je in GCC precies dezelfde foutmelding (zoals het ook hoort).

[ Voor 5% gewijzigd door Soultaker op 27-05-2012 18:18 ]

[Orwell]

Soultaker schreef op zondag 27 mei 2012 @ 18:18:
[...]

Met onenigheid heeft het weinig te maken; Microsoft lapt de standaard aan z'n laars en GCC niet.

Ja, vooruit, als je uitgaat van ISO C++ bijvoorbeeld is het natuurlijk Microsoft die het, voor de verandering, niet 'goed' doet. Dat had ik inderdaad moeten zeggen.

Het gaat niet om een waarschuwing; het gaat om een foutmelding. Als je overloaded versies van een functie introduceert krijg je in GCC precies dezelfde foutmelding (zoals het ook hoort).

Zou je me dan kunnen vertellen wanneer GCC (of MinGW) dan echt gaat zeuren over het feit dat hij geen overload kan kiezen? Voor zover ik weet krijg je dat niet voor elkaar met int/float/double doordat 'ie naar de suffixes kijkt. Net zoals hierboven is dus bijvoorbeeld .0f genoeg (in GCC) om aan te geven dat 'ie de floatversie moet nemen.

[Soultaker]

Ik ken de exacte regels voor het kiezen van overloaded functies niet uit m'n hoofd, maar die staan wel in de C++ standaard, en ik neem aan dat zowel GCC als MSVC++ die correct implementeren. Als je bijvoorbeeld het scenario met overloaded pow() recreëert:

C++:

float pow(float, float);
double pow(double, double);
long double pow(long double, long double);

int main() { pow(3, 2); }

Dan geeft ook GCC een foutmelding bij het compileren:

test.cpp: In function 'int main()':
test.cpp:5:22: error: call of overloaded 'pow(int, int)' is ambiguous
test.cpp:1:7:  note: candidates are: float pow(float, float)
test.cpp:2:8:  note:                 double pow(double, double)
test.cpp:3:13: note:                 long double pow(long double, long double)

Of bedoelde je dit niet?

[Orwell]

Hmm, ja, dat is dan een voorbeeld ja. Maar in het voorbeeld stond toch echt zonder dubbelzinnigheid (double,int), en toch begon MSVC++ te zeuren. En dat was dus eigenlijk een beetje het vage ervan.

[Soultaker]

Volgens mij begrijpen we elkaar niet helemaal. In de screenshot van de TS worden twee ints gebruikt. Als je van één van de twee een double (of een float) maakt wordt inderdaad wel één van de overloaded functies gekozen.

[Compizfox]

Losstaand hiervan; waarom gebruik je niet gewoon?

code:

area = pi * radius * radius;

Dan hoef je cmath niet te includen en dat scheelt weer resources

[Orwell]

Soultaker schreef op zondag 27 mei 2012 @ 22:04:
Volgens mij begrijpen we elkaar niet helemaal. In de screenshot van de TS worden twee ints gebruikt. Als je van één van de twee een double (of een float) maakt wordt inderdaad wel één van de overloaded functies gekozen.

Vraag me alsjeblieft niet waarom ik al die tijd double radius heb gelezen.

Sorry voor het verknallen van uw tijd.

[.oisyn]

Soultaker schreef op zondag 27 mei 2012 @ 18:18:
[...]

Met onenigheid heeft het weinig te maken; Microsoft lapt de standaard aan z'n laars en GCC niet.

Hoe lapt MS de regels aan zijn laars dan? Als de code uit de TS door GCC wel gecompileerd wordt dan is het toch echt GCC die de mist in gaat. ISO C++ dicteert een foutmelding in die code.

.edit: net even geprobeerd, de code faalt ook gewoon in GCC met een ambiguity error zoals het hoort. We hebben het hier over C++ he, niet over C.

[ Voor 15% gewijzigd door .oisyn op 27-05-2012 23:44 ]

[Soultaker]

Hmz, ik was in de veronderstelling dat die overloads niet-standaard zijn, maar daarin schijn ik me te vergissen. Dat gezegd hebbende, het compileert voor mij wél gewoon (en blijkbaar voor MarcHeijerman's docent ook).

Als ik pow() aanroep zonder argumenten (expres verkeerd dus) dan raporteert de compiler vijf opties:

double pow(double, double)
long double std::pow(long double, int)
float std::pow(float, int)
double std::pow(double, int)
long double std::pow(long double, long double)
float std::pow(float, float)

De eerste is dus de standaard C-functie, de andere vier zijn overloaded versies. De twee met ints als tweede parameter heb ik nog niet eerder gezien; wellicht wordt één daarvan gekozen, maar dan zou ik denken dat het resultaat nog steeds ambigu is.

De compiler output callt echter een hele andere (template) functie:

__gnu_cxx::__promote_2<__gnu_cxx::__enable_if<(std::__is_arithmetic<int>::__value)&&(std::__is_arithmetic<int>::__value), int>::__type, int>::__type
std::pow<int, int>(int, int)

Er lijkt dus een templatefunctie te zijn die pow() implementeert voor twee integer argumenten.

Ik laat het aan de C++ experts om te bepalen wat hier nu exact het juiste gedrag is.

edit:
In c++0x-mode ontbreken de opties met int als tweede argument weer! Maar de boel compileert nog steeds.

[ Voor 4% gewijzigd door Soultaker op 28-05-2012 06:21 ]

[farlane]

Soultaker schreef op maandag 28 mei 2012 @ 06:18:
edit:
In c++0x-mode ontbreken de opties met int als tweede argument weer! Maar de boel compileert nog steeds.

De namespace lijkt idd te suggereren dat het een GNU extensie is. Vraag is wel welke versie GCC dan wel selecteert als de extensies uit staan?

[MSalters]

Ik vermoed dat de oorzaak 'm ligt in de "nieuwe" C99 math extensies. MSVC++ ondersteunt C99 niet, GCC wel. GCC ondersteunde ze vervolgens ook als C++ extensie, maar in C++11 worden de C99 functies overgenomen en is het dus geen extensie meer.

Je kunt dus niet zomaar naar de standaard wijzen.

[ Voor 5% gewijzigd door MSalters op 28-05-2012 14:06 ]

[Soultaker]

farlane schreef op maandag 28 mei 2012 @ 10:42:
De namespace lijkt idd te suggereren dat het een GNU extensie is. Vraag is wel welke versie GCC dan wel selecteert als de extensies uit staan?

En hoe zet ik die überhaupt uit? Meestal werkt -ansi wel aardig, maar dat lijkt hier niet de oplossing te zijn.

MSalters schreef op maandag 28 mei 2012 @ 14:04:
Ik vermoed dat de oorzaak 'm ligt in de "nieuwe" C99 math extensies. MSVC++ ondersteunt C99 niet, GCC wel.

Hm, zou kunnen, maar welke extensies doel je dan precies op? C ondersteunt helemaal geen overloading, dus lijkt me dat aan een functie als pow() zelf weinig veranderd kan zijn.

[.oisyn]

farlane schreef op maandag 28 mei 2012 @ 10:42:
[...]

De namespace lijkt idd te suggereren dat het een GNU extensie is.

Maar pow() zelf leeft in std. Wat je verder aan gcc namespaces ziet is type traits support om pow() te implementeren - niet echt van belang dus.

MSalters schreef op maandag 28 mei 2012 @ 14:04:
Ik vermoed dat de oorzaak 'm ligt in de "nieuwe" C99 math extensies.

Bedoel je tgmath.h? Maar ook daar bestaat geen pow(int, int)

[ Voor 27% gewijzigd door .oisyn op 28-05-2012 18:47 ]

[Soultaker]

Grappig, tgmath kende ik ook nog niet. Ergens een beetje jammer dat daar op een complexe manier (via compiler-specifieke macros) een soort function overloading wordt geïntroduceerd in een taal die dat verder niet kent (wel voor built-in operators, maar die kun je als gebruiker ook niet overloaden).

Volgens de man-page zouden die macros ook voor integers moeten werken:

Otherwise, if any argument for generic parameters has type double or is of integer type, the type determined is double.

Maar dat is hier niet aan de orde, want tgmath.h wordt hier helemaal niet geïnclude en pow() is niet een macro. Ik neig toch naar de conclusie dat libstdc++ een meer generieke versie van pow() implementeert dan officieel de bedoeling is, al is me nog steeds niet duidelijk waar die precies vandaan komt.

[.oisyn]

De GCC waarmee ik die code probeerde te compilen was trouwens 4.1.2, best oud.

Soultaker schreef op maandag 28 mei 2012 @ 20:41:
want tgmath.h wordt hier helemaal niet geïnclude en pow() is niet een macro.

Maar het tweede gedeelte van je zin ("pow() is niet een macro") is natuurlijk vollledig afhankelijk van het al dan niet geïncluded zijn van tgmath.h

[ Voor 68% gewijzigd door .oisyn op 28-05-2012 22:18 ]

[farlane]

.oisyn schreef op maandag 28 mei 2012 @ 18:37:
Maar pow() zelf leeft in std. Wat je verder aan gcc namespaces ziet is type traits support om pow() te implementeren - niet echt van belang dus.

De templates die gebruikt worden leven in een gnu extensie namespace, dus de resulterende template zal niet werken zonder die extensies lijkt me, ook al zit deze in de std:: namespace.

Overigens ziet die template er zo uit:

C++:

  template<typename _Tp, typename _Up>
    inline
    typename __gnu_cxx::__promote_2<
    typename __gnu_cxx::__enable_if<__is_arithmetic<_Tp>::__value
                    && __is_arithmetic<_Up>::__value,
                    _Tp>::__type, _Up>::__type
    pow(_Tp __x, _Up __y)
    {
      typedef typename __gnu_cxx::__promote_2<_Tp, _Up>::__type __type;
      return pow(__type(__x), __type(__y));
    }

Hij lijkt dus wel iets te doen met de types van de parameters, maar mijn template magic kennis is beperkt

@Soultaker
Er staan geen conditionals omheen, dus ik denk niet dat ze weg kunnen?

[ Voor 4% gewijzigd door farlane op 28-05-2012 22:40 ]

[.oisyn]

farlane schreef op maandag 28 mei 2012 @ 22:38:
[...]

De templates die gebruikt worden leven in een gnu extensie namespace, dus de resulterende template zal niet werken zonder die extensies lijkt me, ook al zit deze in de std:: namespace.

Mijn punt was dat dergelijke implementatie-details niet eens in de std mogen zitten, maar ik snap wat je bedoelt.

Hij lijkt dus wel iets te doen met de types van de parameters, maar mijn template magic kennis is beperkt

De functie bestaat alleen als de twee template parameters van arithmetic type zijn, en het return type is de meest gepromotete type van de twee (dus bij short en int is het returntype een int, bij int en long is het een long, etc)

Wel apart overigens, want deze pow<int, int>(int, int) roept dus gewoon weer pow(int, int) aan. Ik vraag me af waarom hij dan niet gewoon weer pow<int, int>(int, int) zal kiezen als overload, want dat was blijkbaar eerst ook de beste match.

[ Voor 45% gewijzigd door .oisyn op 28-05-2012 23:44 ]

[Soultaker]

Dat laatste komt dan weer doordat promote_2 eerst de integer arguments promoveert naar double (zoals in C99 ook gebeurt, maar dan zonder de template magic, natuurlijk). Dat blijkt niet uit de code die farlane quotte, maar via deze templates uit ext/type_traits.h:

C++:

  // For complex and cmath
  template<typename _Tp, bool = std::__is_integer<_Tp>::__value>
    struct __promote
    { typedef double __type; };

  template<typename _Tp>
    struct __promote<_Tp, false>
    { typedef _Tp __type; };

  template<typename _Tp, typename _Up>
    struct __promote_2
    {
    private:
      typedef typename __promote<_Tp>::__type __type1;
      typedef typename __promote<_Up>::__type __type2;

    public:
      typedef __typeof__(__type1() + __type2()) __type;
    };

Vandaar dus dat std::pow<int,int>(int,int) gewoon std::pow(double,double) callt.

farlane schreef op maandag 28 mei 2012 @ 22:38:
Er staan geen conditionals omheen, dus ik denk niet dat ze weg kunnen?

Geen idee waaraan je refereert...?

[.oisyn]

Ah. Ik had de definitie opgezocht en dacht dat het louter om regel 18 uit jouw code ging - 14 en 15 had ik even gemist

[farlane]

Soultaker schreef op dinsdag 29 mei 2012 @ 01:05:
Geen idee waaraan je refereert...?

Soultaker schreef op maandag 28 mei 2012 @ 17:40:
En hoe zet ik die überhaupt uit? Meestal werkt -ansi wel aardig, maar dat lijkt hier niet de oplossing te zijn.

[Soultaker]

Ah, dat bedoel je. Mja, dan kan het blijkbaar niet. Stom.