Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New issue] f_locals in sys.exc_info()
--
ISSUES
1. [New issue] f_locals in sys.exc_info()
http://ironpython.codeplex.com/workitem/34029
User
I do indeed get output that looks like yours -
c:\Program Files (x86)\IronPython
2.7>c:\users\x\Downloads\corflags.exe ipy64.exe
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version
2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
Version : v4.0.30
I find that the following works (on all versions I have tested, including
Jython):
> import sys
def Python_is_64bit():
> if sys.platform == 'cli': #IronPython
> import System
> return System.IntPtr.Size == 8
> else:
> try:
> return sys.maxsize > 214748
Hi,
Just as a side note:
It seems that sys.float_info.min and epsilon are not correct in IronPython.
Activestate Python 2.7.2:
>>> sys.float_info.min
2.2250738585072014e-308
>>> sys.float_info.epsilon
2.220446049250313e-16
IronPython 2.7.3:
>>> sys.float_info.min
-1.7976931348623157e+308
>>> sy
Hi,
http://www.johndcook.com/blog/2010/06/08/c-math-gotchas/ explains the problem:
The double.MinValue and double.Epsilon in C# have different meanings thant
DBL_MIN and DBL_EPSILON in C.
I'm looking for a way how to get the wanted values... :)
Best regards
Markus Schaber
CODESYS(r) a tradem
On Wed, May 8, 2013 at 4:07 AM, Markus Schaber wrote:
> Hi,
>
> ** **
>
> http://www.johndcook.com/blog/2010/06/08/c-math-gotchas/ explains the
> problem: The double.MinValue and double.Epsilon in C# have different
> meanings thant DBL_MIN and DBL_EPSILON in C.
>
> ** **
>
> I'm looking f
You can get precise values of these without depending on the compiler's
ability to convert text to floating point values by saying
sys.float_info.min =
System.BitConverter.Int64BitsToDouble(0x0010) # i.e. 2^-1023
sys.float_info.epsilon =
System.BitConverter.Int64BitsToDouble(0x3cb
Hi,
I tried to find a way to calculate it reliably, but did not find an easy, nice
and fast way.
I guess setting the IEC bits directly is the best way for now, together with a
comment why we don't use the false friends provided by .NET.
However, as far as I read the docs of DoubleToInt64Bits()
You may be able to avoid endian-ness issues by using BitConverter.ToDouble
with a byte array instead. (I'm never sure how endian-ness and IEEE-754
interact.)
On Wed, May 8, 2013 at 9:06 AM, Markus Schaber wrote:
> Hi,
>
> ** **
>
> I tried to find a way to calculate it reliably, but did not
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...)
Best regards
Markus Schaber
CODESYS(r) a trademark of 3S-Smart Software Solu
On Wed, May 8, 2013 at 9:15 AM, Markus Schaber 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-end
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 cra
ARM, the architecture, is endianess agnostic.
But AFAIT all major OS run over little-endian processors, including all Windows
flavors.
Hernán MF S
El 08/05/2013, a las 22:44, Slide escribió:
> Unless Microsoft really wants pain and anguish, they are likely running in
> little endian mode. I'v
13 matches
Mail list logo
