kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/27/2011 11:14 AM, Vladimir Uryvaev wrote:
> At Sunday 27 of November 2011 19:07:36 from Dick Hollenbeck:
>> On 11/27/2011 08:56 AM, Dick Hollenbeck wrote:
>>> On 11/26/2011 03:15 PM, Vladimir Uryvaev wrote:
>>>> At Saturday 26 of November 2011 23:49:27 from Lorenzo Marcantonio:
>>>>> On Sat, Nov 26, 2011 at 09:30:59PM +0400, Vladimir Uryvaev wrote:
>>>>>> May be I'm not human, but for me as being scientist and engineer it
>>>>>> sound weird to truncate significant digits.
>>>>>> 1, 1.0, 1.00 are different for me, as they carry different precision.
>>>>>> So I'm all for %*f and to keep all significant digits, whatever they
>>>>>> are, zeroes, or not.
>>>>> If we're talking about storage I'd says omitting zero is better. On the
>>>>> screen or on a report, you need to show the 'right' amount of zeroes.
>>>> In GUI we do not know what precision user mean (or we have to store it),
>>>> so it is no useful information.
>>>>
>>>> In file precision mean storage precision and is known. Anyway, fixed
>>>> format is preferable in machine read data. Note, if you speak about
>>>> human readability, not storage efficiency, such precision would be
>>>> precious information. If you're about efficiency, you would prefer
>>>> binary file or BASE64 at least.
>>>>
>>>> Also as I noted above %g may switch to exponent format (AFAIR it is not
>>>> specified by standard -- when it happen), which could be undesirable.
> I was wrong here, format define choose of format: %f if -4 <= X < P, %e 
> otherwise, where X is an exponent in e-format, P is a precision in format 
> specifier.
>> I hope in the biu-plan.txt we understand that I am only talking about
>> saving to disk, when I talk about FMT_ENG.
> I've got it.
>
>> Vladimir you will have different concerns in the UI, and there are some
>> tough design choices there which will take you to different format
>> strings.
> In my edits in GUI I cut trailing zeros.
>
>> Each context needs to be evaluated separately.  I am not saying anything
>> here about those other choices, only that I have made the choice to use a
>> certain format string for the saving to disk.
> I do not stand for human readability in files, I would ever prefer binary, or 
> simple ASCII like in gerbers (as machine readability/writability is worth more 
> for me, than human readability, 'cause I do not read them myself). But if I 
> design human-readable format, i prefer numbers with clearly defined precision.
>
> I'll better write short own number formatting function for saving/loading, 
> which:
> - configurable (all you want: precision, removing trailing 0s...),
> - independent from locale settings,
> - possibly faster than printf.

Good catch on the %g going to exponent format when fabs( double ) <= .0001  !

If using a number in the e notation below 0.0001 bothers you, I will revisit the strategy.

I used this format %g format string with good luck in the specctra_export code, but it
seems we were working with larger numbers there.

I don't share your views on the human readability of data files.  I believe that one of
KiCad's main value propositions is human readability of data files.  SWEET takes this to
the extreme, and s-expressions are arguably even "self documenting".

So it is not clear to me that a function written by you for this purpose would serve
previously stated goals.

If you are insistent on no exponents in the number, I am insistent on the smallest files
including trailing zero removal where we can.

I think now the best thing to do is to split the BIU formatting from the actual output
string formatting.  This means doing it in two steps, and this way we can control white
space padding as a separate control using %8s for example.  %s style formatting can be
used in the output where the millimeter numeric value goes.

std::string biuFmt( BIU aValue )  // plugin member function.

can then be used as the fprintf() parameter for the %s argument.

fprintf( fp, "example coord: %3s %3s\n",
    biuFmt( pad.x() ).c_str(), biuFmt( pad.y() ).c_str() );

The fact that we create a std::string for each of these is a minor drawback, but I don't
know how much that is really.  The bottleneck is probably the disk drive really.

Is there any agreement here?  At least this way we push the discussion into biuFmt() an
isolated function, which can also do the scale from

a) nanometers to millimeters, and/or

b) decimils to millimeters, and/or

c) decimils to decimils for testing with unity scaling factor, so I can run the diff tests.

See attached potential biuFmt().

What I like about this variation on the original plan is that it puts the formatting into
one small controllable place, and we can easily do whitespace padding as a separate,
context specific control.

Dick

#include <limits.h>
#include <stdio.h>
#include <math.h>
#include <string>
#include <string.h>


typedef int             BIU;
typedef double          BFU;

#define MM_PER_BIU      1e-6
#define UM_PER_BIU      1e-3


double  scale = MM_PER_BIU;

std::string biuFmt( BIU aValue )
{
    BFU     engUnits = scale * aValue;
    char    temp[48];

    if( engUnits != 0.0 && fabsl( engUnits ) <= 0.0001 )
    {
        sprintf( temp,  "%.6f", engUnits );

        int len = strlen( temp );

        while( --len > 0 && temp[len] == '0' )
            temp[len] = '\0';
    }
    else
    {
        printf( "g: " );
        sprintf( temp, "%.10g", engUnits );
    }

    return temp;
}


int main( int argc, char** argv )
{
    //int i = INT_MAX;
    //int i = 1;

    printf( "%s\n", biuFmt( 0 ).c_str() );

    printf( "%s\n", biuFmt( 1 ).c_str() );

    printf( "%s\n", biuFmt( 10 ).c_str() );

    printf( "%s\n", biuFmt( 99 ).c_str() );
    printf( "%s\n", biuFmt( 100 ).c_str() );

    printf( "%s\n", biuFmt( 199 ).c_str() );

    printf( "%s\n", biuFmt( 1000 ).c_str() );
    printf( "%s\n", biuFmt( -1000 ).c_str() );

    printf( "%s\n", biuFmt( INT_MAX ).c_str() );
}