No viable conversion from 'double' to 'half'

[Deepak Ingole]

Hi,

Thank you for developing this library.
I am doing some arithmetic tests. Like double or flot, I want to assign vraiable with some value like
half a = 3.4;
but I am getting error for this as
error: no viable conversion from 'double' to 'half' (aka 'half_float::half')
Would you plesae suggest me work around to fix this error.

Looking forward to hearing from you.
Thank you.

Regards
Deepak

[Christian Rau]

Hello,

This should actually work and I don't quite understand why it doesn't. The
half type has implicit constructors and assignment operators taking float
arguments. These constructors are implicit and the compiler should thus
allow the expression using an implicit conversion from 3.4 to 3.4f and then
calling the float constructor. You could try with 3.4f directly and see if
that works, but it should actually work with 3.4 already. There seems to be
something else wrong, but without more code it's hard to judge what.

Regards,

Christian Rau

Am Di., 29. Okt. 2019 um 15:20 Uhr schrieb Deepak Ingole ingole@users.sourceforge.net:

Hi,

Thank you for developing this library.
I am doing some arithmetic tests. Like double or flot, I want to assign
vraiable with some value like
half a = 3.4;
but I am getting error for this as
error: no viable conversion from 'double' to 'half' (aka 'half_float::half')
Would you plesae suggest me work around to fix this error.

Looking forward to hearing from you.
Thank you.

Regards
Deepak

---

No viable conversion from 'double' to 'half'

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/half/discussion/general/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Deepak Ingole]

Hi Chirstian,

Thank you for your reply and suggestion. Sorry to say but it is not working for me. Following is the test code:

#include <iostream>
#include "half.hpp"

using half_float::half;

int main() {

    half b(5);
//    half a = half(0.0); // works well
//    half a = 0.0; // not working (expected to work like double)
    half a = 3.4; // not wokring
//    half a (3.4); // works well
    half c = a * b;
    c += 3.5;
    if(c > a)
    std::cout << c << std::endl;

}

I am using Apache NetBeans 11.1 on macOS and GNU compiler, C++11. Would you please try above code on your system.

Thank you.

Regards
Deepak

[Christian Rau]

Hello,

Yes, you're right. Explicit construction ('half a(3.4);') works and
assignment ('half a; a = 3.4;') works too. But when using initialization
with assignment operator ('half a = 3.4;') is should actually first use the
'float' constructor and then the copy constructor, but it seems it can't
use the 'float' constructor as long as that is 'explicit'. This surprises
me and I have to look if that has changed somehow since C++11 or if that
has always been the case. Unfortunately, the 'float' constructor has to
stay explicit because it reduces precision.

But I'll look into this and if this can be solved somehow, thanks for
bringing this up. In the meantime, just using explicit constructor syntax
would be the easiest workaround.

Regards,

Christian Rau

Am Mi., 30. Okt. 2019 um 17:21 Uhr schrieb Deepak Ingole ingole@users.sourceforge.net:

Hi Chirstian,

Thank you for your reply and suggestion. Sorry to say but it is not
working for me. Following is the test code:

~~~

include <iostream></iostream>

include "half.hpp"

using half_float::half;

int main() {

half b(5);

// half a = half(0.0); // works well
// half a = 0.0; // not working (espected to work like double)
half a = 3.4; // not wokring
// half a (3.4); // works well
half c = a * b;
c += 3.5;
if(c > a)
std::cout << c << std::endl;

}
~~~

I am using Apache NetBeans 11.1 on macOS and GNU compiler, C++11. Would
you please try above code on your system.

Thank you.

Regards
Deepak

---

No viable conversion from 'double' to 'half'

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/half/discussion/general/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Emilio Mª López Riñón]

Would a simple explicit constructor and assignment operator taking a double not work in this case?

[Christian Rau]

The problem is I'd have to provide constructors like these for every type
then and I'd like to avoid that. But I'm thinking about it, maybe I'll
reconsider that.

Am Sa., 18. Jan. 2020 um 15:40 Uhr schrieb "Emilio Mª López Riñón" redorav@users.sourceforge.net:

Would a simple explicit constructor taking a double not work in this case?

---

No viable conversion from 'double' to 'half'

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/half/discussion/general/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Matt]

I think you should consider adding implicit casting from float to half rather than explicit. Even though this is a narrowing conversion, it would be really helpful if the half type behaved the same as built-in float types.

Otherwise, I am running into many issues when trying to convert code that worked before with all the built-in float types to start using the half float type, having to add in explicit conversions all over.

In some cases, I have to add custom code when templating to check if type is half so that it will cast in a different way than with the other types, especially when using std::complex<half>.</half>

In almost all the cases I encounter, the problem boils down to their not being an implicit conversion from float to half.

[Christian Rau]

The problem is that code that implicitly casts from double to float is
already problematic and narrowing conversions should be taken care of in
templated code like that. So either you are already operating with mixed
types even when using builtin types, in which case you might want to care
for proper type-safety and narrowing conversions there, too. Or you only
work within a single type, which should as well work when switching that
type to half. I really don't intend to add implicit conversions from float
to half as that is not particularly type-safe and might also cause
additional ambiguity problems for mixed-type operations.

Am Mi., 4. März 2020 um 16:39 Uhr schrieb Matt mattgately@users.sourceforge.net:

I think you should consider adding implicit casting from float to half
rather than explicit. Even though this is a narrowing conversion, it would
be really helpful if the half type behaved the same as built-in float types.

Otherwise, I am running into many issues when trying to convert code that
worked before with all the built-in float types to start using the half
float type, having to add in explicit conversions all over.

In some cases, I have to add custom code when templating to check if type
is half so that it will cast in a different way than with the other types,
especially when using std::complex<half>.</half>

In almost all the cases I encounter, the problem boils down to their not
being an implicit conversion from float to half.

---

No viable conversion from 'double' to 'half'

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/half/discussion/general/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Matt]

How about adding integer to half conversion? Even though this is actually an error-prone conversion, int-to-float conversion is still done implicitly as part of c++ standard.

I'm just trying to make this work better for code templates that may be used with or without half library present.

Alternatively, if want to avoid all implicit narrowing conversions, could we at least support implicit uint8_t or int8_t to half conversion? This is a lossless conversion and when I tried that it also didn't work. That was one way I was trying to load constant values '0' or '1' into a Type variable that could work for any built-in or half floating type.

[Christian Rau]

That seems to get messy quickly. I will consider broadening type
conversions to more types in general in the future, to adress some of the
above problems with double initializations maybe, but specifically allowing
uint8_t conversion sounds like a bit of an inconsistent mess just to
support 0 and 1. I know it's unfortunate when template code just uses these
all over the place, it's why I usually use T(1) and T() in such completely
type-agnostic code. That's ugly too, but such is the case if you want 100%
perfectly templated code. Meanwhile, using 1.f and 0.f instead would be a
half-way compromise, since these should work when using assignment,
construction and initialization. I know that's still not a satisfying
solution, but I guess this is where the library just can't achieve the full
functionality of a builtin type. Unfortunately you can't quite define
warnings rather than errors (unless with extensive TMP magic or C++20
features maybe?) or prioritize user-defined type conversions
hierarchically. But these are also the cases where too lax type policies in
libraries intended for builtin arithmetic types can reach their limits.

Am Mi., 4. März 2020 um 17:32 Uhr schrieb Matt mattgately@users.sourceforge.net:

How about adding integer to half conversion? Even though this is actually
an error-prone conversion, int-to-float conversion is still done implicitly
as part of c++ standard.

I'm just trying to make this work better for code templates that may be
used with or without half library present.

Alternatively, if want to avoid all implicit narrowing conversions, could
we at least support implicit uint8_t or int8_t to float conversion? This
is a lossless conversion and when I tried that it also didn't work. That
was one way I was trying to load constant values '0' or '1' into a Type
variable that could work for any built-in or half floating type.

---

No viable conversion from 'double' to 'half'

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/half/discussion/general/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>