octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MinGW and 3 exponent digits


From: Rik
Subject: Re: MinGW and 3 exponent digits
Date: Tue, 12 Nov 2013 12:57:50 -0800

On 11/12/2013 12:33 PM, John W. Eaton wrote:
> On 11/12/2013 03:18 PM, Rik wrote:
>> 11/12/13
>>
>> All,
>>
>> Apparently MinGW provides a work-around for the non-standard Windows
>> behavior of printing 3 exponent digits through the environment variable
>> PRINTF_EXPONENT_DIGITS.  If this variable is set to 2 then only two digits
>> will be displayed.
>>
>> Sample code:
>>
>> octave-cli:1> format short e
>> octave-cli:2> pi
>> ans =   3.1416e+000
>> octave-cli:3> setenv ("PRINTF_EXPONENT_DIGITS", "2")
>> octave-cli:4> pi
>> ans =    3.1416e+00
>>
>> Should we look to put something in Octave's start-up code which sets this
>> environment variable when MinGW is detected?
>
> What does it do when this environment variable is set?
Exactly, I don't know.  This announcement on the MinGW mailing list
(http://marc.info/?l=mingw-notify&m=121692138826851) seems to suggest that
they inserted a printf shim layer between user's code and MSVCRT.  It seems
to suggest that it calls _set_output_format when it is possible to do so,
otherwise it takes care of the printing issues itself.
>
> Is it not possible to call _set_output_format if we are compiling with
> MinGW?
Yes, if the windows systems has MSVCR80.DLL and MinGW can take advantage of
it.  Brief reports suggest that this is sometimes difficult for MinGW.  But
it would also make us dependent on the particulars of the Windows system. 
If the user doesn't have this dll then they are out of luck, whereas MinGW
will always be around by definition.

This post seems to suggest that the particular way PRINTF_EXPONENT_DIGITS
got implemented can be slow
(http://stackoverflow.com/questions/13970675/massive-fprintf-speed-difference-without-std-c99).
 
But this might have been fixed by now.

--Rik


reply via email to

[Prev in Thread] Current Thread [Next in Thread]