Hi,
Maybe we'd use some conditional initializiation, checking for the properties of
the number, like the following:
// The definition of Epsion and MinValue differ between .NET and
Python/C,
// so we need to define our own values.
// Approx. -2.2204460492503131e-16 - the byte order reversed value is
approx.
// 2.2290265677773679e-319, so this code delivers the correct value
independently
// of the byte order of the machine.
private static readonly double EPSILON = Math.Max(
System.BitConverter.Int64BitsToDouble(0x3cb0000000000000),
System.BitConverter.Int64BitsToDouble(0x000000000000b03c));
// Approx. 2.2250738585072014e-308 - the byte-order reversed value is
approx.
// 2.0236928853657458e-320, so this code delviers the correct value
independently
// of the byte order of the machine.
private static readonly double MIN = Math.Max(
System.BitConverter.Int64BitsToDouble(0x0010000000000000),
System.BitConverter.Int64BitsToDouble(0x0000000000001000));
public static floatinfo float_info = new floatinfo(Double.MaxValue,
1024, 308, MIN, -1021, -307, 15, 53, EPSILON, 2, 1);
This trick relies on the fact that for the given values, the reversed byte
order produces an zero-Exponent, which are denormalized numbers, and in both
cases, the wanted number is a normalized one which (by definition) is larger
than the denormalized one.
This code is as elegant as checking for the endianness explicitly, and we are
even safe for machines where the integer and float endianness are different
(see https://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness -
although I doubt that those hardware is relevant for our user base...) :)
Best regards
Markus Schaber
CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
________________________________
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: [email protected]<mailto:[email protected]> | Web:
codesys.com<http://www.codesys.com> | CODESYS store:
store.codesys.com<http://store.codesys.com>
CODESYS forum: forum.codesys.com<http://forum.codesys.com>
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade
register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Von: Slide [mailto:[email protected]]
Gesendet: Mittwoch, 8. Mai 2013 22:44
An: Jeff Hardy
Cc: Markus Schaber; Curt Hagenlocher; [email protected]
Betreff: Re: [Ironpython-users] IronPython float_info values (was: IronPython
always in 32-bit mode on 64bit machine even when running ipy64.exe)
Unless Microsoft really wants pain and anguish, they are likely running in
little endian mode. I've never run across an ARM setup that actually runs in
big endian (nor do I want to), so I'm pretty sure its little endian. I'd be
more than willing to test an app on my phone since Windows Phone is crap
anyway, so you couldn't damage it any worse than it is now :-)
Alex
On Wed, May 8, 2013 at 12:54 PM, Jeff Hardy
<[email protected]<mailto:[email protected]>> wrote:
On Wed, May 8, 2013 at 9:15 AM, Markus Schaber
<[email protected]<mailto:[email protected]>> wrote:
> Hi,
>
>
>
> The main problem for now is that I can't test whatever solution we find,
> because I don't have access to any hardware with non-intel Byte Order and a
> Microsoft .NET. (I don't want to rely on Mono for this test...)
Is ARM big-endian? If so, any Windows 8 ARM tablet (i.e. Surface RT)
or Windows Phone should do. Heck, even the emulator might do. It
shouldn't be too hard to whip up an app that prints those two values,
and I think Alex has a Windows Phone if he'd be willing to test it.
If ARM is little-endian (or Windows/ARM runs in little-endian mode)
then I don't think it matters; we'd have to try Mono on a PowerPC or
something like that.
- Jeff
--
Website: http://earl-of-code.com
_______________________________________________
Ironpython-users mailing list
[email protected]
http://mail.python.org/mailman/listinfo/ironpython-users
