kicad-developers team mailing list archive

[Miguel Ángel Ajo <majopela@xxxxxxxxxx>]

I was just testing that.

  Python floats (in all architectures) are double, so the 52 bit fraction (11 bit exp) is always
going to hold more information that the 32bits wxPoint /wxSize can hold.

   So that’s not a point.

   I’m experimenting with both options, to see what’s more readable.  

Miguel Ángel Ajo


On Sunday, 25 de January de 2015 at 02:48, Tomasz Wlostowski wrote:

> On 25.01.2015 02:04, Piers Titus van der Torren wrote:
> > While I understand that for internal units it's good to use integers and
> > hence small units, for this high level python api I don't see much benefits
> > for not using floats and sensible default  
> >  
>  
>  
> Dear Peter,
>  
> 32-bit float is bad simply because the set of 32-bit floats is not a
> superset of 32 bit integers. This means merely converting an integer
> coordinate to float and back to int may loose accuracy. In case of
> tightly packed primitives, one might end up with unwanted DRC errors.
>  
> As for small vs big units - units matter on the UI side, when the user
> inputs some parameters for the script in a dialog window.
> Inputting/outputting values with units should be therefore made as easy
> as possible. Processing the data is IMHO a different story - computers
> don't care if they do calculations in milli- or nanometers. So why
> create yet another unit definition?
>  
> Tom
>  
> units like degrees and mm.
> > Keeping the internal api intact still allows for low level scripting and
> > using internal units. Even combined with this api, as the internal object
> > currently is easily available as ._module for example.
> > I see this api as a user interface, where internal units may be hidden just
> > like in the gui.
> > Also the * inch syntax can be used if preferred with inch = 25.4.
> >  
> > Piers
> > Op 24 jan. 2015 23:48 schreef "Miguel Ángel Ajo" <majopela@xxxxxxxxxx (mailto:majopela@xxxxxxxxxx)>:
> >  
> > > Hmm, I’m actually liking Tom’s suggestion, sounds quite natural to me.
> > >  
> > > pcb.create_module(ref=‘A1’, position=(10 * mm, 10 * mm))
> > >  
> > > but also accepting pcb.create_module(ref=‘B1’, position=Point(10 * mm, 10
> > > * mm))
> > >  
> > > I’d do the function parameter translation into Point automatically, even
> > > if I believe parameter
> > > input should be easy, having a class for points or sizes makes them easier
> > > to manipulate,
> > > for example if we wanted to rotate them:
> > >  
> > > point.rotate(2 * rad)
> > >  
> > > point.rotate(90 * deg, around=(5 * mm, 5 * mm))
> > >  
> > > or
> > >  
> > > new_point = point.rotated(90 * deg)
> > >  
> > > --
> > > Side note, not sure why I thought IUs were 10nm, but they are 1nm (and
> > > 10nm for gerbview, I suppose the
> > > reason for the gerview change is being able to stack the biggest boards
> > > 10x10)
> > >  
> > > http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/include/convert_to_biu.h#L44
> > >  
> > > Miguel Ángel Ajo
> > >  
> > > On Saturday, 24 de January de 2015 at 22:37, tiger12506 wrote:
> > >  
> > > I have no weight in the discussion, but I really like Tom's suggestion
> > > here.
> > >  
> > > It allows you to use them as if they were units. 10 * mm is almost
> > > syntactically identical to 10mm.
> > > And they don't get in the way with a bunch of boilerplate, like some of
> > > the other suggestions do.
> > >  
> > > ~JS
> > >  
> > > On 1/24/2015 3:55 PM, Tomasz Wlostowski wrote:
> > >  
> > > On 16.01.2015 18:43, Miguel Ángel Ajo wrote:
> > >  
> > > The user shouldn’t need to know what an IU is unless he really wants, for
> > > some
> > > reason.
> > >  
> > > Hi Miguel,
> > >  
> > > Why make things complicated here? Given that the choice of IUs in pcbnew
> > > is very reasonable and easy to understand, I see no reason for hiding
> > > that knowledge from script writers. A nanometer after all, is just
> > > one-millionth of a millimeter. No rocket science here...
> > >  
> > > On the other hand, we need to provide a sensible way of
> > > inputting/presenting values with units. For hardcoded values, defining
> > > units could be just multiplying by a fixed scalefactor:
> > >  
> > > from pcbnew import mm, inch, mils
> > >  
> > > #pcbnew.mm = 1000000
> > > #pcbnew.inch = 25400000
> > > #pcbnew.mils = 25400
> > >  
> > > p = Point(10 * mm, 12 * mm)
> > >  
> > > Concerning UI input/output (dialogs) - recently I had to do some dialogs
> > > for P&S with lots of values in mm/inches, so to avoid repeatable unit
> > > conversion code, I developed a class tiny called WX_UNIT_BINDER [1]. It
> > > binds together a WX text control with an unit label:
> > >  
> > > class MyDialog : public dialog_generated_by_wxfb_base {
> > > WX_UNIT_BINDER m_myValueInUnits;
> > > };
> > >  
> > > MyDialog::MyDialog() :
> > > m_myValueInUnits ( m_myValueText, m_myValueUnitLabel )
> > > {
> > > m_myValueInUnits.SetValue ( value_in_iu_here )
> > > // x = m_myValueInUnits.GetValue();
> > > }
> > >  
> > > All unit conversion is done inside the binder class, according to the
> > > current units setting. All the user needs to do is to get/set the value
> > > in IUs. Maybe a similar method could be used in the scripting API?
> > >  
> > > Cheers,
> > > Tom
> > >  
> > > [1]
> > >  
> > > https://github.com/twlostow/kicad-dev/blob/tmp-crap/include/wx_unit_binder.h
> > >  
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help : https://help.launchpad.net/ListHelp
> > >  
> > >  
> > >  
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help : https://help.launchpad.net/ListHelp
> > >  
> > >  
> > >  
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help : https://help.launchpad.net/ListHelp
> > >  
> >  
> >  
> >  
> >  
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help : https://help.launchpad.net/ListHelp
> >  
>  
>  
>