kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

>> Simply changing the internal unit to a new fixed quantum is the best path
>> in my opinion.  From there you only need 2 scaling factors to generate
>> mils or your most preferred metric unit.
> I do not pretend to change this in any way. My class is just a wrapper to do 
> the conversion in nice way, and help to trace all the length quantities.

I think a nice way to do a conversion is to call a function.  I don't think
hiding the conversion in an operator overload or constructor is superior to
calling an obvious conversion function such as:

1) mm2internal()
2) mil2internal()
3) internal2mm()
4) internal2mil()

An int is perfectly capable of storing the internal unit of nanometers.


> > I see a need for only two engineering units
>> in the file PCB formats:
>>
>>
>> 1) Imperial.  The blueprint says 1/100th of a mil.  But I would argue
>> adding a decimal point to the numbers, and simply saving them as mils in
>> files.  I do not think we'd have to use exponents, simply numbers with
>> decimal points.  Such as 70.378 (mils).  Exponents are not desirable.
>>
>> (See below for why a decimal point is helpful in the files.)
>> 2) Metric.  Somebody pick, if a decimal point is used in the number, it can
>> even be millimeters.
> I see only the problem with decimal separator: it should be handled carfully:
> parsed manually, or first converted to FP number with high precision, then 
> converted to inernal storage.

Yes of course, obviously.  When it didn't work any other way, you'd eventually
come back to this, just to get it to work.  :)


> If it helps keep backward compatibility, would be fine if saved unit will stay 
> the same. (E.g. 1575.4475 decimils old version should read as 1575, and new in 
> full precision)
>
>>
>> Each PCB file type can name which of the two units it is using (with
>> perhaps a third being what we have now).  On file loading, these numbers
>> can be converted to the 1 nanometer internal unit without error or any
>> rounding, exactly.
>>
>> On file saving, things are a little different.  Because you have such fine
>> granularity in the 1 nm internal unit, converting to say 1/100th of a mil
>> *whole number* cannot be done without some rounding.  To avoid the
>> rounding on the conversion in this direction, we can use a decimal point
>> in the numbers saved within the PCB files.  If this is done, then I see no
>> problems with my plan, somewhat modified from the blueprint.
>>
>> Dick
>>
> I do not ever see a need to keepmore than one unit supproted.


Where?  What context are you talking about?  I think we need to store board and
footprint files in both imperial and metric both.


These can come together in the RAM resident BOARD structure, where internal
units of nano-meters are used.

Again, I think if we use the decimal point in the files, we can save files in
either of the two engineering units:

    1) millimeters (mm)
    2) thousands of an inch (mil).

We just have to record in the file which of the two are being used, and then
perform the conversion to nanometers on load, and reverse on save.

Internally the int is sufficient to store the nanometers.  

So the question is, what problem(s) are you solving by introducing class LENGTH?
And please don't say that hiding the conversion is solving a problem.   I don't
want the conversion to be hidden.  It becomes a problem when it is hidden in my
opinion.



>  If you convert 
> nm to decimils with 1/10000 precision it would read back to nm fine, without 
> any loss (however this thick shoul only be done on files, not in any internal 
> computation)
>
> In SWEET we can choose any unit we like (even fractional meters).

I assume you mean a new S-expression format applied to boards and footprints.
The name SWEET refers only to the schematic *part* format (not even to the full
schematic). 

Dick