[petsc-dev] [petsc-users] PetscPrintf

[Jed Brown]

"Smith, Barry F." <bsmith at mcs.anl.gov> writes:

>> Is the postprocessing of output in PetscVSNPrintf really necessary?
>
> PetscVSNPrintf does two things
>
> 1) handles %D to have a common way of printing PetscInt regardless of if they are 32 or 64 bit integers

This is just modifying the format string, so not an issue.

> 2) insures that all floating point numbers printed have a . in them so Petscdiff can accurately determine what is a 
> floating point number in output (standard C formats don't put the . in floating point numbers like 1. that don't need them. I could not find 
> any decent numerical diff for PETSc output to use in place of our cumbersome home-brew thing.

I don't think it's possible to write a printf format string that behaves
like %g except always includes the decimal point.  We could insist on
using %e or %.1f style format strings always -- many uses of %g are
gratuitous and not actually better for the user.  But it would be
disruptive and occasionally weird.

One alternative would be to escape everything but the %g, count and
extend the storage for the %g, snprintf that part, then pass along the
rest.  But that won't reduced the dirtiness.

> If there are alternative ways of handling 1) and 2) then PetscVSNPrintf() and its cumbersomeness are not needed.
>
> Barry
>
> Note that PetscVSNPrintf() does not handle printing of PetscReal, we have to manually put a caste of (double) in the calling sequence (for __float128). I tried to add this support with %G but gave up because it was a rat hole.
>
>
>
>
>
>> On Apr 12, 2018, at 8:22 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>> 
>>>> On Apr 12, 2018, at 3:59 AM, Patrick Sanan <patrick.sanan at gmail.com> wrote:
>>>> 
>>>> I also happened to stumble across this yesterday. Is the length restriction for the default printer (l assume from the array of 8*1024 chars in PetscVFPrintfDefault() ) intended behavior to be documented, or a bug to be fixed?
>>> 
>>>     You could call it either. My problems are 
>>> 
>>> 1) that given a format string I don't know in advance how much work space is needed so cannot accurately malloc, for sure, enough space
>>> 
>>> 2) since this can be called in an error handler I really don't want it calling malloc().
>>> 
>>>   Hence it lives in this limbo. I don't even know a way to add a good error checking that detects if the buffer is long enough. All in all it is bad ugly code, any suggestions on improvements would be appreciated.
>> 
>> Is the postprocessing of output in PetscVSNPrintf really necessary?
>> Without it, you would call vfprintf instead of vsnprintf followed by
>> fprintf("%s", string) [1].
>> 
>> 
>> [1] fputs would be preferable.
>> 
>>> 
>>>   Barry
>>> 
>>>> 
>>>> 2018-04-12 2:16 GMT+02:00 Rongliang Chen <rongliang.chan at gmail.com>:
>>>> Thanks Barry. I found petsc-3.6 and older versions did not have this restriction.
>>>> 
>>>> Best,
>>>> Rongliang
>>>> 
>>>> 
>>>> On 04/12/2018 07:22 AM, Smith, Barry F. wrote:
>>>>   Yes, PetscPrintf() and related functions have a maximum string length of about 8000 characters.
>>>> 
>>>>    Barry
>>>> 
>>>> 
>>>> On Apr 11, 2018, at 6:17 PM, Rongliang Chen <rongliang.chan at gmail.com> wrote:
>>>> 
>>>> Dear All,
>>>> 
>>>> 
>>>> When I tried to print a long string using PetscPrintf() I found that it truncated the string. Attached is a simple example for this (run with single processor). I used PetscPrintf() and printf() to print the same string and the printf() seems OK. I am using petsc-3.8.4.
>>>> 
>>>> 
>>>> Best,
>>>> 
>>>> Rongliang
>>>> 
>>>> <ex111.c>