Re: [Kicad-developers] VECTOR2I and VECTOR2D

Hi Tom, On 23/06/2019 4:10 AM, Tomasz Wlostowski wrote: On 22/06/2019 17:41, Reece R. Pollack wrote: While it is true that you can add two point coordinates and multiply by scalar 0.5 to get the midpoint, this is not true in the general case for arbitrary scalar multipliers. However,

Re: [Kicad-developers] VECTOR2I and VECTOR2D

A specification for substantial changes like this should document clearly the hierarchy of inheritance, each class's functions and expected returns. There are some very good references out there on how to write specs [1][2][3]. This is not to dismiss Reece's suggestion. I think it is a good

Re: [Kicad-developers] VECTOR2I and VECTOR2D

Isn't Reece's original post the spec? In summary, the name VECTOR is confusing and the type structure could be expanded on to offer more compile time checks. He proposes a KiPoint and KiDelta, and describes their behavior clearly enough for anyone that does geometry calculations. What's

Re: [Kicad-developers] 6.0 Zone filling differences

Le 22/06/2019 à 20:23, Jeff Young a écrit : > Hi JP, > > Can you point me to some of the clearance violation issues? > > I’m aware of the one where a track that goes within the thermal clearance > radius can produce a DRC error, but I’d consider that what DRC is for. But > it sounds like

Re: [Kicad-developers] 6.0 Zone filling differences

Hi JP, Can you point me to some of the clearance violation issues? I’m aware of the one where a track that goes within the thermal clearance radius can produce a DRC error, but I’d consider that what DRC is for. But it sounds like there are others? Thanks, Jeff. > On 22 Jun 2019, at 18:58,

Re: [Kicad-developers] 6.0 Zone filling differences

Le 22/06/2019 à 18:37, Jeff Young a écrit : > New, higher-performance bits in, with some (perhaps all) of the bugs fixed. > > Testing would be appreciated. > > Cheers, > Jeff. > Hi Jeff, Usually, when 2 bugs are fixed, one new bug is created. Thermal stubs are missing for pads having a

Re: [Kicad-developers] 6.0 Zone filling differences

Ok, I guess that is the safest option and if one requires a track there one could just draw it manually. lør. 22. jun. 2019 18.52 skrev Jeff Young : > Yes. > > On 22 Jun 2019, at 17:39, Nick Østergaard wrote: > > Ah, ok, it os the chamfers. I didn't realise that. What are you > proposing, to

Re: [Kicad-developers] 6.0 Zone filling differences

Yes. > On 22 Jun 2019, at 17:39, Nick Østergaard wrote: > > Ah, ok, it os the chamfers. I didn't realise that. What are you proposing, > to remove the spoke if the zone does not touch? > > lør. 22. jun. 2019 18.36 skrev Jeff Young >: > There’s no piece of the zone in

Re: [Kicad-developers] 6.0 Zone filling differences

Ah, ok, it os the chamfers. I didn't realise that. What are you proposing, to remove the spoke if the zone does not touch? lør. 22. jun. 2019 18.36 skrev Jeff Young : > There’s no piece of the zone in the middle; that’s just the chamfers on > the ends of the spokes. > > The zone doesn’t go

Re: [Kicad-developers] 6.0 Zone filling differences

New, higher-performance bits in, with some (perhaps all) of the bugs fixed. Testing would be appreciated. Cheers, Jeff. > On 22 Jun 2019, at 17:36, Jeff Young wrote: > > There’s no piece of the zone in the middle; that’s just the chamfers on the > ends of the spokes. > > The zone doesn’t

Re: [Kicad-developers] 6.0 Zone filling differences

There’s no piece of the zone in the middle; that’s just the chamfers on the ends of the spokes. The zone doesn’t go between the two pads because their thermal relief value doesn’t allow enough room. Cheers, Jeff. > On 22 Jun 2019, at 17:04, Nick Østergaard wrote: > > Mmm, I am not sure I

Re: [Kicad-developers] VECTOR2I and VECTOR2D

On 22/06/2019 17:41, Reece R. Pollack wrote: > > While it is true that you can add two point coordinates and multiply by > scalar 0.5 to get the midpoint, this is not true in the general case for > arbitrary scalar multipliers. However, calculating the vector distance > between two points,

Re: [Kicad-developers] 6.0 Zone filling differences

Mmm, I am not sure I under stamd that screenshot. Why are the zone not touchimg the thermal track between the pads while it looks like there is a part of zone area on the middle of the thermal track? lør. 22. jun. 2019 17.58 skrev Jeff Young : > Our current algorithm will produce thermal

Re: [Kicad-developers] 6.0 Zone filling differences

Our current algorithm will produce thermal connections between two pads (with no connections to the zone): I assume no one will lose any sleep over dropping those? Cheers, Jeff. > On 21 Jun 2019, at 19:49, Jean-Paul Louis wrote: > > Wayne, > > Except in very hugh frequency design (higher

Re: [Kicad-developers] VECTOR2I and VECTOR2D

On 22/06/2019 16:32, hauptmech wrote: > After reading through vector2d.h and matrix3x3.h, I agree with Reece > more or less. There is ambiguity in the word vector, between math > vectors, spatial vectors, and c++ vectors. Context implies that VECTOR2 > refers math vectors, but then MATRIX3x3 *

Re: [Kicad-developers] VECTOR2I and VECTOR2D

On 6/22/19 10:52 AM, Seth Hillbrand wrote: On 2019-06-21 22:54, Reece R. Pollack wrote: Doing this now, before we go too far down the path of replacing wxWidgets types with non-OOB arrays would enhance readability and make the code more robust. Using VECTOR2I is going the wrong way. Hi Reece-

Re: [Kicad-developers] VECTOR2I and VECTOR2D

On 6/22/19 3:09 AM, Greg Smith wrote: Adding two points and dividing by two results in a point that is minimally equidistant from both points (I.e. The midpoint of the line formed by the points). While it is true that you can add two point coordinates and multiply by scalar 0.5 to get the

Re: [Kicad-developers] VECTOR2I and VECTOR2D

On 2019-06-21 22:54, Reece R. Pollack wrote: Doing this now, before we go too far down the path of replacing wxWidgets types with non-OOB arrays would enhance readability and make the code more robust. Using VECTOR2I is going the wrong way. Hi Reece- Codebase cleaning like you suggest can go

Re: [Kicad-developers] Additional parameters on simulation dialog

On 2019-06-21 15:00, Sylwester Kocjan wrote: Hi, I prepared some changes in KiCad simulation dialog. They are about additional simulation parameters. According to tutorial, which I've found on website, I store them on GitHub repository in branch "Sim_InitialConditions_SK" here:

Re: [Kicad-developers] VECTOR2I and VECTOR2D

After reading through vector2d.h and matrix3x3.h, I agree with Reece more or less. There is ambiguity in the word vector, between math vectors, spatial vectors, and c++ vectors. Context implies that VECTOR2 refers math vectors, but then MATRIX3x3 * VECTOR2 is allowed which violates

Re: [Kicad-developers] VECTOR2I and VECTOR2D

The evolution from untyped variables to weakly-typed variables to strongly-typed variables to OOP techniques has never been about what is easiest for the programmer nor fastest running. It's about producing correct, reliable, maintainable software. The argument that "it'll be too slow" is

Re: [Kicad-developers] VECTOR2I and VECTOR2D

On 22/06/2019 09:09, Greg Smith wrote: > > I think the biggest point I am making is that, mathematically, a point > is identical to a vector from 0,0. > Hi Greg & Reece, This is precisely the reason why we don't have separate point and vector classes. Tom

Re: [Kicad-developers] VECTOR2I and VECTOR2D

In graphics/CAD packages, a point can be considered a vector from point 0,0. This is an interpretation that makes sense to me. Adding two points and dividing by two results in a point that is minimally equidistant from both points (I.e. The midpoint of the line formed by the points). In