Re: gEDA-user: pcb crooked traces
On Tue, 12 Oct 2010 22:12:41 +0200 Armin Faltl armin.fa...@aon.at wrote: Btw. while being a different topic, how about getting rid of the lefthanded coordinate system, when all numeric computations have to be checked anyway? This should make the cs consistent with trigonometric functions. +1 I think you refer to the fact that X coordinates should grow left to right; Y should grow from duwn to up. -- Kovacs Levente leventel...@gmail.com Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Andrew Poelstra wrote:
Well, the C standard says that long must be ``at least'' 32 bits,
maybe more. To the best of my knowledge, gcc uses a 32-bit long
even on 64-bit systems, to maintain compatibility with old code.
This was true last I checked, a year or two ago.
Tested 5 minutes ago:
[ a...@ajf5 ~]
uname -a
Linux ajf5 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010
x86_64 GNU/Linux
[ a...@ajf5 ~]
cat long.c
#include limits.h
#include stdio.h
int main()
{
int i;
long int l;
long long int L;
i = INT_MAX;
printf(i = %d\n, i);
l = LONG_MAX;
printf(l = %ld\n, l);
L = LLONG_MAX;
printf(L = %lld\n, L);
}
[ a...@ajf5 ~]
./long
i = 2147483647
l = 9223372036854775807
L = 9223372036854775807
[ a...@ajf5 ~]
exit
long long is ``at least'' 64 bits, which is why gcc does its emulation.
And yes, it might be better to use long long even on 32-bit machines,
if the performance hit is not too great. But we'll have to do testing
to see.
Andrew
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
DJ Delorie wrote: On Mon, 2010-10-11 at 15:25 -0700, Andrew Poelstra wrote: I think we want to allow negative locations. It would be nice to set parts outside of the pcb boundary, for example when initially placing everything. We limit ourselves to half so that *distances* can fit in a signed same-size value. The range of computable distances on a board will always be twice the range of coordinates. More if you do 2-D distance, but we can use floating point there (we'd be doing a sqrt() anyway) When using signed integers for coordinates and offsets (vectors), by restricting to the positive quadrant, allowing a 2x2m board will still yield a 32-bit overflow, if you try to place a large footprint at the right edge of the board. So I think forbidding negative board coordinates doesn't guard against anything. If one wants to enforce range-savety, the boards and footprints better be +-1m maximum. Personally I favour 32-bit integers on 32-bit machines, because I think that 64-bit emulation must be at least 3x slower than native ops. Enable 64-bit coords on 32-bit machines with a configure flag. On 64-bit machines of course 64-bit, since 32 is probably slower. s ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 11:26 AM 10/12/2010, you wrote: But if we limited everything to 2m, using unsigned integers, we'd be okay with 32 bits. I'm not sure what you're saying here. Having said that, I still want negative coordinates. So do we need to limit things to 1m? Yuck. He is saying that to avoid overflow in internal calculations, you could have parts up to 1 meter on a board up to 1 meter with the part placed at the upper edge of the board putting the upper edge of the part at 2 meters. Well, ``probably slower'' isn't a good reason for anything. I doubt your speculation on both 32- and 64-bit machines, so testing will need to be done. WHOA!!! We should actually measure how much the application would slow rather than speculate or use pointless metrics such as how fast a test program doing nothing but a math operation runs... what a concept!!! So who is going to bell the cat? Another thought. Using 1 nm as the base unit does everything anyone wants, but limits the max size board on 32 bit machines. But do we really need 1 nm resolution? This allows exact representation in nm of 0.01 mil in inches. Do we need exact representation of 0.01 mil? Would 0.1 mil be adequate? Using 10 nm as the base unit internally gives exact representation down to 0.1 mil and allows much finer resolution, just not exact representation in inches. With a 10 nm base unit the max board size goes to 20 meters which certainly is enough for everyone, including those wishing to design kitchens! Durn metric system! Why can't our system be good enough for the rest of the world? :-\ Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Internally the origin of the grid should go to the middle of the board, but have the board translate the coords to physical of the upper left, or even lower left. Make some folks happy about their y decreasing or somthing or another. This removes the loss from the other three quadrents of area and gives us 4.29 meter boards. Using a signed number and just using the 1st quadrent is a waste, of about 2 meters. ;-) normally the folks won't need to set the origin other than the upper left of the board, but for those 4 meter boards you'll have it. and HUGE boards sets it to 64 bit integers. For those large or miniscule boards a nice scale setting solves any scale issue. Steve On Tue, Oct 12, 2010 at 11:44 PM, Rick Collins gnuarm.2...@arius.com wrote: At 11:26 AM 10/12/2010, you wrote: But if we limited everything to 2m, using unsigned integers, we'd be okay with 32 bits. I'm not sure what you're saying here. Having said that, I still want negative coordinates. So do we need to limit things to 1m? Yuck. He is saying that to avoid overflow in internal calculations, you could have parts up to 1 meter on a board up to 1 meter with the part placed at the upper edge of the board putting the upper edge of the part at 2 meters. Well, ``probably slower'' isn't a good reason for anything. I doubt your speculation on both 32- and 64-bit machines, so testing will need to be done. WHOA!!! We should actually measure how much the application would slow rather than speculate or use pointless metrics such as how fast a test program doing nothing but a math operation runs... what a concept!!! So who is going to bell the cat? Another thought. Using 1 nm as the base unit does everything anyone wants, but limits the max size board on 32 bit machines. But do we really need 1 nm resolution? This allows exact representation in nm of 0.01 mil in inches. Do we need exact representation of 0.01 mil? Would 0.1 mil be adequate? Using 10 nm as the base unit internally gives exact representation down to 0.1 mil and allows much finer resolution, just not exact representation in inches. With a 10 nm base unit the max board size goes to 20 meters which certainly is enough for everyone, including those wishing to design kitchens! Durn metric system! Why can't our system be good enough for the rest of the world? :-\ Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Andrew Poelstra wrote: When using signed integers for coordinates and offsets (vectors), by restricting to the positive quadrant, allowing a 2x2m board will still yield a 32-bit overflow, if you try to place a large footprint at the right edge of the board. So I think forbidding negative board coordinates doesn't guard against anything. If one wants to enforce range-savety, the boards and footprints better be +-1m maximum But if we limited everything to 2m, using unsigned integers, we'd be okay with 32 bits. I'm not sure what you're saying here. 1m to the edge of the board, 1m from the center of the footprint (positioned at the edge of the board) outwards. If you don't adhere to that, the outer pins of the footprint will turn up at the opposite side of the board (because of overflow). Having said that, I still want negative coordinates. So do we need to limit things to 1m? Yuck. It's still possible to design a 2x2m board when the coordinate center is in the middle of the board. It is also possible, to do some offset on IO and show only positive numbers to the user. And one can limit footprint sizes more and add that to board dimesions. If you use unsigned ints for coordinates and signed for offsets, you have to make sure, no negative number results from subtracting, meaning you might shift the valid range of center-coordinate for footprints to 1/4*UINT_MAX to 3/4*UINT_MAX internally. Then again, this is clumsy, so stick to signed int and [1/2*INT_MIN .. 1/2*INT_MAX]. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Tue, 2010-10-12 at 11:44 -0400, Rick Collins wrote: WHOA!!! We should actually measure how much the application would For x86 architecture you may read http://en.wikipedia.org/wiki/X86 http://en.wikipedia.org/wiki/X86-64 it mentions MMX and similar, which made fast 64 bit integer operation available for 32 bit systems -- if the employed compiler supports it. Do you intend to use our PCB in future or even start coding? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Wed, Oct 13, 2010 at 12:33:26AM +0800, Steven Michalske wrote: Internally the origin of the grid should go to the middle of the board, but have the board translate the coords to physical of the upper left, or even lower left. Make some folks happy about their y decreasing or somthing or another. I don't think the middle of the board is an internal concept, especially if you're translating it to the top-left of the physical board. So this doesn't make sense to me. What would the user see? This removes the loss from the other three quadrents of area and gives us 4.29 meter boards. Using a signed number and just using the 1st quadrent is a waste, of about 2 meters. ;-) normally the folks won't need to set the origin other than the upper left of the board, but for those 4 meter boards you'll have it. and HUGE boards sets it to 64 bit integers. I think we'll be okay with a ~1m limit for the 32-bit version; then we can use signed integers for all lengths, set the origin arbitrarily (I assume by shifting the outline layer(s) around). If you want giant boards, you can edit the scale factor in the .pcb file or just use a 64-bit version of pcb. For those large or miniscule boards a nice scale setting solves any scale issue. Exactly. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Wed, 2010-10-13 at 00:48 +0800, Steven Michalske wrote: We should have NO base unit internally, and only scale to internal units on import, export, open, and save. OK, but we have snap to grid, and grid will have units, and display of coordinates. And arbitrary scale for output makes not much sense, because it influences pitch of footprints. I think now I understand why the developer list is only accessible with wrote permission for core developers ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 12:46 PM 10/12/2010, you wrote: On Tue, 2010-10-12 at 11:44 -0400, Rick Collins wrote: WHOA!!! We should actually measure how much the application would For x86 architecture you may read http://en.wikipedia.org/wiki/X86 http://en.wikipedia.org/wiki/X86-64 it mentions MMX and similar, which made fast 64 bit integer operation available for 32 bit systems -- if the employed compiler supports it. Do you intend to use our PCB in future or even start coding? Do you have to code to use PCB? I thought this was the user mailing list??? BTW, who exactly is meant by our? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Steven Michalske wrote: Internally the origin of the grid should go to the middle of the board, but have the board translate the coords to physical of the upper left, or even lower left. Make some folks happy about their y decreasing or somthing or another. Occasionally someone is changing the size of the board while placing/routing. While it's possible, to move the contents on resize, just leaving the coordinate center where it is - preferably where the designer wanted it to be, e.g. at a certain fiducial - makes more sense to me. Btw. while being a different topic, how about getting rid of the lefthanded coordinate system, when all numeric computations have to be checked anyway? This should make the cs consistent with trigonometric functions. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
John Doty:
On Oct 10, 2010, at 5:38 AM, Karl Hammar wrote:
On the downside for integers we have, if I may cite John Doty:
There are subtle problems with carrying real number analytic
geometry into a discrete domain.
So far I have not found any good reasons for using integers, and John
has presented a wery good one for NOT using them. If we can get rid of
thoose subtle problems, we will have a more healthy program and it
will also be easier for new developers to join (in that part).
You misunderstand.
Well, that is always possible.
Computer floats are not real numbers: they are discrete elements of
a finite set.
Yes, I now that. Ok, I thought you meant floats in the cited paragraph.
Their behavior is more difficult to comprehend than the behavior of
integers.
It seems some people are scared by floats, is it that you mean?
And --- integers have their trouble spots also, consider:
A,
Is -1/2 equal to -1 or -0
Is -1%2 equal to -1 or +1
B,
Why does
#include stdio.h
int main(void) {
char cc = 0xc4 // 'ä' in latin1
short str = cc;
printf(0x%04hx\n, str);
}
print 0xffc4 instead of 0x00c4 ?
But the comprehension dimension of numbers is not for me to discuss, but
if someone has problems with it, I'm willing to help out.
Regards,
/Karl Hammar
-
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Wed, 2010-10-13 at 00:05 +0200, Karl Hammar wrote:
Why does
#include stdio.h
int main(void) {
char cc = 0xc4 // 'ä' in latin1
short str = cc;
printf(0x%04hx\n, str);
}
print 0xffc4 instead of 0x00c4 ?
It is because 0xc4 is inserted into a char, not an unsigned char,
and is in binary:
1100 0100
Which is a _negative_ number. (-60 in decimal)
The compiler will (correctly) sign-extend the assigned value in str when
performing the type conversion.
I wasn't sure this was a question you already knew the answer two or
not.. but it is certainly a nice example of why you have to be careful
mixing different types, and signed-ness in general.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Peter Clifton:
On Wed, 2010-10-13 at 00:05 +0200, Karl Hammar wrote:
Why does
#include stdio.h
int main(void) {
char cc = 0xc4 // 'ä' in latin1
short str = cc;
printf(0x%04hx\n, str);
}
print 0xffc4 instead of 0x00c4 ?
It is because 0xc4 is inserted into a char, not an unsigned char,
and is in binary:
1100 0100
Which is a _negative_ number. (-60 in decimal)
The compiler will (correctly) sign-extend the assigned value in str when
performing the type conversion.
Close, but you missed to point out that a char is signed on my box.
It could as well be unsigned, but then the problem would not show up.
I wasn't sure this was a question you already knew the answer two or
not.. but it is certainly a nice example of why you have to be careful
mixing different types, and signed-ness in general.
Yes, and there are portability issues also.
Regards,
/Karl Hammar
-
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Wed, Oct 13, 2010 at 12:59:42AM +0200, Karl Hammar wrote: Peter Clifton: The compiler will (correctly) sign-extend the assigned value in str when performing the type conversion. Close, but you missed to point out that a char is signed on my box. It could as well be unsigned, but then the problem would not show up. Well, that is an oddity of the C language, not an oddity of integer computer math in general. But I see your point. I wasn't sure this was a question you already knew the answer two or not.. but it is certainly a nice example of why you have to be careful mixing different types, and signed-ness in general. Yes, and there are portability issues also. Again, the C language fails to define a lot of things (ironically, in the name of portability) and therefore causes problems that can't be properly blamed on the use of ints. Many other languages do not pull this kind of crap, though they still do unintuitive things regarding overflow and sign extension. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, Oct 08, 2010 at 05:07:45PM -0400, DJ Delorie wrote: So... if pcb were to be limited to a 2 meter by 2 meter board, would it actually be a painful limitation to anyone? MAXINT nm is 84.5 inches (just over 7 feet). Anyone who needs more than 84x84 inch boards can re-compile PCB with 64-bit units. I seem to remember that I saw a rigid PCB manufacturer which alowed up to 2 meters or a bit more, but I can't find it any more. Another data point is that Rogers will ship some aminates from their antenna series with sizes up to 50x110 or almost 1.3mx2.8m. This is only on special order, so some (limited) demand must exist. Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, Oct 08, 2010 at 11:14:04PM +0100, Peter Clifton wrote: On Fri, 2010-10-08 at 15:42 -0400, DJ Delorie wrote: Any idea of the loss of performance given that virtually all PCs these days are actually 64 bit machines? My dual-core 3.2GHz machine supports 64-bit, but I installed a 32-bit OS for compatibility. So, 64-bit math is a performance hit for me. I'm not certain that is true.. or are you compiling with CFLAGS for a non 64-bit CPU? I thought the 32/64 bit OS issue was mostly to do with address pointers, rather than aritmetic. I was fairly sure one could execute 64bit native CPU arithmetic instructions under a 32-bit OS, just that the executable would not be portable to machines which didn't support those instructions. Not on the 64 bit version of x86 for integer computations. The most significant half of the 64 bit integer registers are not accessible at all in 32 bit mode. On other architectures, I think it works (for PPC I'm sure, Sparc and MIPS I believe so), but we are in an x86 monoculture these days. ARM does not (yet) have a 64 bit version AFAIK. Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Sat, Oct 09, 2010 at 10:15:15AM +0200, Armin Faltl wrote: DJ Delorie wrote: Please forgive my ignorance, but can't one just define a 64bit integer on a 32bit system? Yes, but there's a loss of performance if you do that. if one really is anal about it, use 'long long int' which is an 80-bit integer on Intel That's so wrong that I don't know where to start. long double is 80 bit floating point and going away (it was introduced with the aberration known as the stack-based x87 floating point unit)- machines and they are handled by the floatingpoint unit, despite they are real integers (and, xor, shift, rot, mod, ...) No. Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Sat, Oct 09, 2010 at 07:41:09PM -0400, DJ Delorie wrote: I think we got it right the first time we discussed it way back when. We're just rehashing old arguments, no new info is being added. I know what we're going to do, and we all seem to agree it's the right thing to do... I've sat down and started playing with this idea. Doing a simple search-and-replace of the types `Dimension' and `BDimension' to `Length' gets us this: -b...@odadjian ~/Code/pcb-andrew$ git status # On branch nanometers # Changed but not updated: # (use git add file... to update what will be committed) # # modified: src/autoplace.c # modified: src/autoroute.c # modified: src/change.c # modified: src/change.h # modified: src/create.c # modified: src/create.h # modified: src/crosshair.c # modified: src/draw.c # modified: src/find.c # modified: src/find.h # modified: src/global.h # modified: src/misc.c # modified: src/mtspace.c # modified: src/mtspace.h # modified: src/parse_y.y # modified: src/polygon.c # modified: src/polygon.h # modified: src/rotate.c # modified: src/rubberband.c # modified: src/search.c # modified: src/search.h # modified: src/set.c # modified: src/set.h # modified: src/thermal.c # modified: src/undo.c # That gives us a vague idea of the scope of this project. Not as wide as I thought, but still pretty wide. Also, there are two types of variables that were originally set to `BDimension': distances and scale factors. My thinking is, we should replace BDimension with two units: 1. length_t (long long) (or long, on 32-bit machines, if it turns out to matter) which is used to store lengths in base units. 2. scale_t (double) which is used to scale things for GUI zoom, very large or very small boards, etc. Most of these variables are already named `scale' so they should be easy to find. Most of the oddball types we have (Dimension, BDimension, Cardinal, Position, etc) should be consolidated into those two. I'm just throwing ideas into the air. What do you guys think? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Mon, 2010-10-11 at 11:26 -0700, Andrew Poelstra wrote: I'm just throwing ideas into the air. What do you guys think? Andrew, I am not sure if you know that there was already a transition from mil to 0.01 mil long time ago -- maybe that is useful information, but that was before I started PCB, so I have no detailed information. What is your conclusion -- if we use 32 bit integer and nm base unit, will we have maximun board size of 2m or 4m. That was not fully clear in our discussion two years ago -- it does not really matter, but may be good to know and to proof our understanding. One funny point -- KiCAD developers have a similar discussion currently. Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Mon, Oct 11, 2010 at 10:19:39PM +0200, Stefan Salewski wrote: On Mon, 2010-10-11 at 11:26 -0700, Andrew Poelstra wrote: I'm just throwing ideas into the air. What do you guys think? Andrew, I am not sure if you know that there was already a transition from mil to 0.01 mil long time ago -- maybe that is useful information, but that was before I started PCB, so I have no detailed information. Thanks, I'll look through the mailing list logs to see if there were any oddities I should be aware of. What is your conclusion -- if we use 32 bit integer and nm base unit, will we have maximun board size of 2m or 4m. That was not fully clear in our discussion two years ago -- it does not really matter, but may be good to know and to proof our understanding. For the people who need to make giant PCBs on 32-bit systems, we should introduce a scale factor to the file format (254 by default, to maintain compatibility with existing .01mil files). Maybe the scale factor should be a float, so that boards can be made with sub-nanometer precision? In any case, I don't think the scale factor should be accessible from the GUI, just there for edge cases and people who like to hand-edit their pcb files. It could cause problems importing footprints whose grid is smaller than the base unit. One funny point -- KiCAD developers have a similar discussion currently. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Oct 11, 2010, at 1:43 PM, Stefan Salewski wrote: -- may long default to 64 bit on 64 bit systems A well, that depends on the programming model that the system developers chose. 64 bit systems have been done two ways: LP64 or ILP64, that is longs and pointers are 64, ints are 32 or ints, longs, and pointers are 64. On a 64 bit systems, pointers are going to be 64 bits -- after all, that is why you are going to 64 bits. The C spec says longs shall be big enough to hold a pointer so that you can cast pointers and longs, and can union pointers and longs. The debate of what to do about ints can go on for years (... trust me I've been there) If you make ints default to 64 bits, all of a sudden recompiled programs get much larger, and the cache pressure is much higher, all for no good reason. If you make ints default to 32 bits, beelyuns of badly coded programs that expect to cast pointers to ints or do other sloppy things that work in an ILP32 world break right and left. So... w.r.t. the debate about pcb going to 64 bits instead of 32 bits is going to make the memory footprint much bigger (not a big deal) and the cache footprint much bigger (could be a big deal). TL;DR: It varies. Check for your system and compilers. -dave -- may it be better to use long long on 32 bit machines to enforce there 64 bit (emulation) when 64 bit is desired? Sorry, I should better be quiet. http://en.wikipedia.org/wiki/Long_integer ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Mon, Oct 11, 2010 at 11:15:54PM +0200, Stefan Salewski wrote: On Mon, 2010-10-11 at 13:57 -0700, Andrew Poelstra wrote: What is your conclusion -- if we use 32 bit integer and nm base unit, will we have maximun board size of 2m or 4m. That was not fully clear in our discussion two years ago -- it does not really matter, but may be good to know and to proof our understanding. For the people who need to make giant PCBs on 32-bit systems, we should introduce a scale factor My question was related to a post of Peter C. 2^32 nm is about 4.3 meters, large enough for any PCB I've ever seen. 2^64 nm is about 0.12 astronomical unit ;-) Well.. I can't recall if we use signed or unsigned numbers throughout, so we might end up limited at half those. http://archives.seul.org/geda/user/Nov-2008/msg00448.html May it be that signed integers are used, but that only the positive half can be used for locations? I was only curious. I think we want to allow negative locations. It would be nice to set parts outside of the pcb boundary, for example when initially placing everything. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Tue, Oct 12, 2010 at 12:29:32AM +0200, Stephan Boettcher wrote:
Andrew Poelstra as...@sfu.ca writes:
... To the best of my knowledge, gcc uses a 32-bit long
even on 64-bit systems, to maintain compatibility with old code.
This was true last I checked, a year or two ago.
main(){printf(%lx\n,(long)(-1));}
yields
with
gcc (Debian 4.4.4-13) 4.4.5 20100902 (prerelease)
in aggreement with
On a 64 bit systems, pointers are going to be 64 bits -- after all,
that is why you are going to 64 bits. The C spec says longs shall be
big enough to hold a pointer so that you can cast pointers and longs,
and can union pointers and longs.
You're right. Just checked with
gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC)
gcc version 4.3.2 (Debian 4.3.2-1.1)
gcc version 4.4.4 20100624 (Red Hat 4.4.4-9) (GCC)
Having said that, I think using the stdint.h types as John Doty suggested
would be the best option.
Andrew
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
John Doty: On Oct 9, 2010, at 5:41 PM, DJ Delorie wrote: I'm surprised we're still discussing this *at all*. You can't build a solid system on a shaky foundation. This is precisely the kind of thing we need to get right, or it will continue to cause unexpected artifacts to appear. I think we got it right the first time we discussed it way back when. We're just rehashing old arguments, no new info is being added. I know what we're going to do, and we all seem to agree it's the right thing to do. Where is this shaky foundation you're accusing us of? I'm not accusing. The point is that this is apparently important, and hasn't been done yet. I'm not sure there is agreement. I'm also very surprised that we are still discussion this. I got into this thread due to some faulty assumptions about floats. The rationale is that if I do something, it should be for the right reasons, not for any bogus reasons. The claims about floating point so far are: 1, they have too great rounding error 2, equality operator (==) is unusful 3, integer arithmetics is for the performance of it Well, I/we have found out that 1, the rounding error is less than the size of an atom 2, so is any integers eqaulity operator when 1 == 1 nm 3, the gain isn't 100times, not even 10 times, it's a mere one digit figure, and the bottlenet is elsewhere Up to now my only intent in this has been to say that claim is false, nothing else. But now I'm starting to feel that using integers is actually the root cause of the jagged lines and mil/mm problems. On the downside for integers we have, if I may cite John Doty: There are subtle problems with carrying real number analytic geometry into a discrete domain. So far I have not found any good reasons for using integers, and John has presented a wery good one for NOT using them. If we can get rid of thoose subtle problems, we will have a more healthy program and it will also be easier for new developers to join (in that part). Yes, there is one reason against a change to doubles since that would force us to reevaluate the formulas, and that is hard work. Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Rick Collins wrote: While accumulation of error is an issue with floating point, the connector or any predefined shape is a particularely bad example: At least I wouln't convert the spacing and then sum up the erratic value but convert all the original values, which gives exactly 1 conversion error per position, irrespective of the number of pins/position. And that's exactly how the read routines operate. To do it the wrong way, they would need to be fortune tellers, because there is no 'array' element in new-lib files. Then please come up with some of your own. I am sure there is no shortage of examples just because I haven't thought of them. I believe such an example will be hard to find in a well programmed CAD application. The reason is, that significant accumulation of discretization errors happens when nummerous small values get added to a large value or with small differences of large numbers. Typical examples for these problems are: *) solving large badly conditioned linear equation systems *) numerical treatment of initial value problems of ordinary differential equations *) statistical computations Even for those apps there are algorithms that account for the problem - skilled developers are aware of it and avoid it. The general procedure in a CAD system is, to place primitives in a virtual space with as few operations as possible and derive some data (screen view, gerbers, drill coordinates,...) from this model as straight forward as possible, again involving only a hand full of operations per primitive. Since the primitives are independent of each other, there is no accumulation of error. One example of the tiny difference of large numbers is, to fill an area with parallel traces, using the same trace width as center distance. Depending on the display scale you might see chinks. As far as I know, this is known bad practice. I'm not a developer of pcb, so if there really are issues with this, others speak up please. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
I don't think you are trying very hard. If the value input by the user in metric is rounded off to a value that is not exact, there is a loss of precision that can not be recovered no matter how well programmed the application is. I gave an example of when this would be significant and you seem to think that the programmer can make special cases to work around this. I'll lay it out again working in the abstract to show the possibilities. If you don't like the abstract, just adjust for a 0.8 mm pin spacing and you will see a real example that is close to the limit. The user has a connector with metric spaced pins. When the metric value is input, the value is rounded off to the nearest 0.01 mil giving an error of 0.005 mil. At this point there is no way to recover that error, it is recorded in the system that way and the precision is lost. This value is used to calculate the position of all the pins in the connector resulting in an accumulated error of 0.005 * N. At 100 pins this the accumulated error is 0.5 mil. That may not be a show stopper, but I would prefer to avoid it if possible. At 200 pins the accumulated error is 1.0 mil, etc. Clearly this is quickly reaching a point of being very unacceptable. Earlier you suggested that this can be dealt with by doing the pin position calculations in metric before converting to inches. Great idea, but who does the calculations? The user? The tool that generates the footprint? How do you educate the users so they all are aware of this problem so they can always work around it? I think this is a poor solution since it first requires that the limitation of the tool be known and worked around by everyone in the solution path. OR... the tool can be changed to remove the limitation by using 1 nm as the base unit which can represent both metric and inches ***WITHOUT ANY LOSS OF PRECISION***. It is that simple. Why adopt a messy, complex, error prone solution when a solution is available that deals with the problem simply, accurately and permanently? Rick At 10:12 AM 10/10/2010, you wrote: Rick Collins wrote: While accumulation of error is an issue with floating point, the connector or any predefined shape is a particularely bad example: At least I wouln't convert the spacing and then sum up the erratic value but convert all the original values, which gives exactly 1 conversion error per position, irrespective of the number of pins/position. And that's exactly how the read routines operate. To do it the wrong way, they would need to be fortune tellers, because there is no 'array' element in new-lib files. Then please come up with some of your own. I am sure there is no shortage of examples just because I haven't thought of them. I believe such an example will be hard to find in a well programmed CAD application. The reason is, that significant accumulation of discretization errors happens when nummerous small values get added to a large value or with small differences of large numbers. Typical examples for these problems are: *) solving large badly conditioned linear equation systems *) numerical treatment of initial value problems of ordinary differential equations *) statistical computations Even for those apps there are algorithms that account for the problem - skilled developers are aware of it and avoid it. The general procedure in a CAD system is, to place primitives in a virtual space with as few operations as possible and derive some data (screen view, gerbers, drill coordinates,...) from this model as straight forward as possible, again involving only a hand full of operations per primitive. Since the primitives are independent of each other, there is no accumulation of error. One example of the tiny difference of large numbers is, to fill an area with parallel traces, using the same trace width as center distance. Depending on the display scale you might see chinks. As far as I know, this is known bad practice. I'm not a developer of pcb, so if there really are issues with this, others speak up please. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Sun, Oct 10, 2010 at 10:45:45AM -0400, Rick Collins wrote: OR... the tool can be changed to remove the limitation by using 1 nm as the base unit which can represent both metric and inches ***WITHOUT ANY LOSS OF PRECISION***. It is that simple. Why adopt a messy, complex, error prone solution when a solution is available that deals with the problem simply, accurately and permanently? I think we have all agreed to use nm as the base unit. Karl is arguing the merits of floating point versus integer math as an entirely separate issue. Personally, I don't see the point. Rounding to the nearest nm is easy to understand and more than precise enough for any non-CPU-core work (and even then..). Floating point is not so easy to understand, because you are rounding to a floating degree of precision -- which will nearly always be sufficient, but still hard to calculate. Plus, floating point is scary. That's a real argument, because it affects developer confidence in the code, confuses analysis, and might discourage future developers. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Replying personally, because this is getting nowhere: Rick Collins wrote: I don't think you are trying very hard. If the value input by the user in metric is rounded off to a value that is not exact, there is a loss of precision that can not be recovered no matter how well programmed the application is. I gave an example of when this would be significant and you seem to think that the programmer can make special cases to work around this. I'll lay it out again working in the abstract to show the possibilities. If you don't like the abstract, just adjust for a 0.8 mm pin spacing and you will see a real example that is close to the limit. The user has a connector with metric spaced pins. When the metric value is input, the value is rounded off to the nearest 0.01 mil giving an error of 0.005 mil. At this point there is no way to recover that error, it is recorded in the system that way and the precision is lost. This value is used to calculate the position of all the pins in the connector resulting in an accumulated error of 0.005 * N. Wrong: the input data of a footprint is listed pin by pin. If a generator tool, that can handle metric and say uses double numbers, is used to create the footprint it will: a) compute the true positions of all pins to double accuracy b) then convert this value to some fractional mil-number, pin by pin c) round that position to 1/100th mil to make pcb happy, pin by pin The footprint file format as I said lists all the pin/pads and gets read sequentially by pcb - pcb doesn't have the slightest idea, what spacing the pins are - they could be at random positions. Double is probably more than sufficient to get 100 increments of 0.8mm right to 1/100-mil, but if it weren't, use a Sparc with Quad-precision floats to generate the footprint. Say the true increment in 1/100th mil were 548.6-periodic. Then a good generator will produce the following differences in the footprint file: 549, 549, 548, 549, 549, 548, 549,549, 548,... If pcb itself is used as a generator by e.g. using a 0.1mm pitch grid and manually painting the pins, it's up to the implementation, to round values of a foreign grid to the correct internal number - I can't answer this for pcb. In principle it is possible, to precompute a sequence for every metric pitch offered, that will convert the N'th construction grid position to the correct 1/100th mil. What pcb really does in this respect you must ask the developers. All I want to say is, that a 100-pin footprint not necessarily has anything to do with adding up a single-pitch roundoff error 100x and that pcb by it's structure does not have the notion of arrays and multipliers in a geometrical sense. It treats all pin positions as where they are according to footprint one by one. If you found this useful, you may post it ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Ooops... Armin Faltl wrote: Replying personally, because this is getting nowhere: ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces [OT]
On Mon, Oct 11, 2010 at 12:18:57AM +0800, Steven Michalske wrote: If floating point numbers wer the end all solution why do banks still use BCD math? Because it removes the errors you are talking about. But we wouldn't use BCD math it's not required. I would suspect that this has more to do with the use of COBOL, than the benefits of floating-point versus fixed-point math. (And anyway, everything banks do is iterative, so the error we are discussing applies far more to them than it does to us.) Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Only slow on a 386. Oh, I forgot. Most of Lunix enthusiasts are still using that. On 9 Oct 2010 18:23, Levente Kovacs [1]leventel...@gmail.com wrote: On Fri, 8 Oct 2010 14:55:10 -0400 DJ Delorie [2...@delorie.com wrote: Yes, but there's a loss of performance if you do that. So, I'd put there a compiling option like 'enable huge boards (might be slow on 32bit systems) Levente ___ geda-user mailing list [3]geda-u...@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:leventel...@gmail.com 2. mailto:d...@delorie.com 3. mailto:geda-user@moria.seul.org 4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Hi timecop, your first message I just deleted which is a rare exception on this list. Since DJ did, I'll waste some seconds and joules on you: a) 2010 - 16 = 1994 b) http://en.wikipedia.org/wiki/Ext2 - Jan 1993, 1 file max 2TB c) the first versions of NTFS had limits completly different than now Please stay under your rock. timecop wrote: Whaat. Please keep your off-topic bullshit *off* this list. I was pointing out that NTFS, created ~16 years ago, had support for 64bit filesizes etc way before lunix even knew what a file 4GB is. *AND* that I can use *ANY* windows app and have it properly work with large filesizes WITHOUT having to recompile it or otherwise waste my time. Having to rebuild something with ./configure --enable-shit-that-should-be-on-by-default is freaking ridiculous. P.s. who the fuck is john lennon? On Sat, Oct 9, 2010 at 11:14 AM, John Griessen j...@ecosensory.com wrote: On 10/08/2010 07:32 PM, timecop wrote: Ah, this is where opensource way of thinking fails it. http://www.google.com/search?q=John+Lennonct=lennon10-hpoi=ddle John Lennon Advanced search About 47,600,000 results (0.15 seconds) http://www.google.com/#hl=enexpIds=17259,18168,25567,26614,26644,26997,27006,27015sugexp=ldymlsxhr=tq=timecopcp=6pf=psclient=psyaq=faqi=g5aql=oq=timecogs_rfai=pbx=1fp=54a191137d571141A About 2,540,000 results (0.24 seconds) and timecop seems to be Time warner cable for the first 60 pages of google results, and includes http://www.travelgrove.com/community/users/timecop/ Is that you, timecop? If it was it would probably be 1 hit worth out of 47,600,000. Probably not, you won't come out from under your rock. Not for anything that matters. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Is this seriously turning into a pissing match between the year a professional filesystem was released vs a home brew hack? NTFS in 1993 was lightyears ahead of anything Lunix had to offer. Undelete, anyone? How about being able to delete a 20gb file without locking entire system up? On 9 Oct 2010 18:37, Armin Faltl [1]armin.fa...@aon.at wrote: Hi timecop, your first message I just deleted which is a rare exception on this list. Since DJ did, I'll waste some seconds and joules on you: a) 2010 - 16 = 1994 b) [2]http://en.wikipedia.org/wiki/Ext2 - Jan 1993, 1 file max 2TB c) the first versions of NTFS had limits completly different than now Please stay under your rock. timecop wrote: Whaat. Please keep your off-topic bullshit *off* this list. I was pointing out that NTFS, created ~16 years ago, had support for 64bit filesizes etc way before lunix even knew what a file 4GB is. *AND* that I can use *ANY* windows app and have it properly work with large filesizes WITHOUT having to recompile it or otherwise waste my time. Having to rebuild something with ./configure --enable-shit-that-should-be-on-by-default is freaking ridiculous. P.s. who the fuck is john lennon? On Sat, Oct 9, 2010 at 11:14 AM, John Griessen [3]j...@ecosensory.com wrote: On 10/08/2010 07:32 PM, timecop wrote: Ah, this is where opensource way of thinking fails it. [4]http://www.google.com/search?q=John+Lennonct=lennon10-hpoi=ddle John Lennon Advanced search About 47,600,000 results (0.15 seconds) [5]http://www.google.com/#hl=enexpIds=17259,18168,25567,26614,26644,26 997,27006,27015sugexp=ldymlsxhr=tq=timecopcp=6pf=psclient=psyaq= faqi=g5aql=oq=timecogs_rfai=pbx=1fp=54a191137d571141A About 2,540,000 results (0.24 seconds) and timecop seems to be Time warner cable for the first 60 pages of google results, and includes [6]http://www.travelgrove.com/community/users/timecop/ Is that you, timecop? If it was it would probably be 1 hit worth out of 47,600,000. Probably not, you won't come out from under your rock. Not for anything that matters. JG ___ geda-user mailing list [7]geda-u...@moria.seul.org [8]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [9]geda-u...@moria.seul.org [10]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [11]geda-u...@moria.seul.org [12]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:armin.fa...@aon.at 2. http://en.wikipedia.org/wiki/Ext2 3. mailto:j...@ecosensory.com 4. http://www.google.com/search?q=John+Lennonct=lennon10-hpoi=ddle 5. http://www.google.com/#hl=enexpIds=17259,18168,25567,26614,26644,26997,27006,27015sugexp=ldymlsxhr=tq=timecopcp=6pf=psclient=psyaq=faqi=g5aql=oq=timecogs_rfai=pbx=1fp=54a191137d571141A 6. http://www.travelgrove.com/community/users/timecop/ 7. mailto:geda-user@moria.seul.org 8. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 9. mailto:geda-user@moria.seul.org 10. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 11. mailto:geda-user@moria.seul.org 12. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
timecop wrote: Is this seriously turning into a pissing match you name it, you get it: it's no longer about technical arguments, it's about the amount of shit one can produce: you won!!! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
John Doty: Karl Hammar wrote: So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? The problem is that in engineering documentation, dimensions are generally given as decimal fractions of inches or meters. Yes. Cumulative roundoff error can be avoided if the numeric encoding can exactly represent such numbers. Yes. Scaled integers or scaled floating point may be used, Yes. but scaled integers are a bit easier to use and understand, Yes (but we are talking about internal values, the user don't have to see them, only the developers, think of todays 1mm). and are usually more efficient. You choose the most efficient one, to do that you test. But I was not talking about performance. Unscaled binary floating point is troublesome because it cannot exactly represent most decimal fractions, so it is prone to cumulative error. Yes. Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Rick Collins: At 05:04 PM 10/8/2010, you wrote: Rick Collins: At 02:28 PM 10/8/2010, you wrote: Andrew Poelstra: On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: ... With integer types you get aliasing artifacts, which actually is a rounding error. We have this problem in the current incarnation of pcb. That is what you aren't getting. The problem is not aliasing in any way I understand aliasing. ... Maybe I should use the word truncation instead. I thought that the aliasing effect would make my point obious because most of you have experienced it. Wikipedia: In signal processing and related disciplines, aliasing refers to an effect that causes different signals to become indistinguishable (or aliases of one another) when sampled. So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? Floats aren't any worse if they have the resolution... but they aren't any better either! Agree, though there are corner cases e.g. x/3 gives truncation for integers, and big_value * big_value2 can give overflow where a double will thrive. ... C, As a side note, if you use double's for the internal representaion, then you don't loose precision compared to having an int32_t. You can convert an int32_t to an double and back without loosing precision. The issue is not using singles or doubles. The issue is whether the base unit is metric (which can perfectly represent inch units of interest) or whether the base unit are inch based which can't represent inch units perfectly. I suppose they could always change the base units to some small fraction of a mil so that even the accumulated error would always be negligible. But why bother changing and only getting an approximation if you can get it perfect? Ack. I know that using a basic unit of mm's or part thereof will solve the mil/mm problem. My point was that this does not have anything with integer vs. floating points. Ok, I agree. I guess all this was about nothing. Yes, don't dissmiss floating-point on false grounds. If it is for the performance, fine, but then you have to test. If ints and doubles comes out equally in a performance test, I'd choose doubles, since arcs, sin() etc. is done in doubles (unless you are using your own function tables). And I also hinted the reader that he/she could swap the 32bit ints for doubles and you would get the exactly the same results (unless you divide of cause, then doubles comes out better). Now I'm lost again... maybe. If you stick with inches, no, using doubles buys nothing. Well, it buys me a little, but it is not the solution for the mil/mm problem. The point about using doubles is that to use metric, it seems like going with a unit of nm is appropriate. Then you are limited to 2 or 4 meter max value with 32 bit ints. Going to double resolves that problem by giving you another factor of 4 billion in your range. I guess we are talking past each other while agreeing... yes? Absolutely. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
DJ Delorie: The root cause of the problem is that the grid setting is a floating point number. ... No, the problem is that the grid setting (e.g.) cannot be exactly represented in *either* integers or floats (with the current basic unit). Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Armin Faltl: DJ Delorie wrote: Please forgive my ignorance, but can't one just define a 64bit integer on a 32bit system? Yes, but there's a loss of performance if you do that. if one really is anal about it, use 'long long int' which is an 80-bit integer on Intel machines and they are handled by the floatingpoint unit, despite they are real integers (and, xor, shift, rot, mod, ...) The best solution is to set the internal basic unit to nm (it seems to be the consensus), so that the number 1 == 1nm, and make a typedef in some header file. Then Armin can have his long long, I can have my doubles, some can have their int64_t, and most can have their simple int. And we can all test and make sure that pcb is typeagnostic regarding that typedef. Then, whoever wants forestsize_pcbs/kitchens/antennas/etc., simply choose their right type (and no scaling factor would be needed). Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Then Armin can have his long long, I can have my doubles, some can have their int64_t, and most can have their simple int. Sounds like a support nightmare in the making. uint_fast32_t http://www.dinkumware.com/manuals/?manual=compleatpage=stdint.html#uint_fast32_t With a compiler that properly implements 'fast' it gets what you want. 32bits on 32 bit machine, 64bits on a 64bit machine, 128bits on a 128bit machine etc. In the Windows world today there is usually the choice of downloading a 32bit or a 64bit program implementation. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Does anyone on this list honestly believe that in 2010 a difference between slow emulated 64bit and native 64bit integer on any hardware made in the last decade is going to be even noticeable. Just make it 64bit and be done with it. Those who still use PCB on 386 can use the old version. It seems most of these discussions that I see here tend to get stuck in the most minute/worthless details that don't affect end user... all the while there are some gaping missing features that prevent end users from properly getting their work done... and then you ask why opensource pcbs use eagle or something. .. simply because it lets them do their job instead of bickering around about stuff. In the Windows world today there is usually the choice of downloading a 32bit or a 64bit program implementation. Except even that '32bit' program will have proper handling for 64-bit values, such as large file sizes, etc, where as on Lunix this means you need to download the source and 20 dependent libs source and recompile them all with -D_LARGE_FILE_OFFSET or some other ridiculous shit. Will the 64-bit version be faster because its native? Probably. Will anyone notice? No. On Sat, Oct 9, 2010 at 9:27 PM, Bob Paddock bob.padd...@gmail.com wrote: Then Armin can have his long long, I can have my doubles, some can have their int64_t, and most can have their simple int. Sounds like a support nightmare in the making. uint_fast32_t http://www.dinkumware.com/manuals/?manual=compleatpage=stdint.html#uint_fast32_t With a compiler that properly implements 'fast' it gets what you want. 32bits on 32 bit machine, 64bits on a 64bit machine, 128bits on a 128bit machine etc. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
timecop:
Does anyone on this list honestly believe that in 2010 a difference
between slow emulated 64bit and native 64bit integer on any
hardware made in the last decade is going to be even noticeable.
...
You have to test to know, and you can get a first impression by
this simplistic test:
$ cat testb.c
#include math.h
#include stdint.h
#include stdio.h
#include sys/time.h
#define TESTIT(op, str) \
gettimeofday(sta, NULL); \
for (ix = 0; ix 10; ix++) { \
(op); \
} \
gettimeofday(end, NULL); \
timersub(end, sta, diff); \
printf(str %ld.%06ld\n, diff.tv_sec, diff.tv_usec);
int main(void) {
struct timeval sta;
struct timeval end;
struct timeval diff;
int32_t xi;
int64_t xl;
double xd;
int ix;
double sqrt2 = sqrt(2);
xd = xl = xi = 0;
printf(Loop time for x++\n);
TESTIT(xi++, int32_t);
TESTIT(xl++, int64_t);
TESTIT(xd++, double );
xd = xl = xi = 1;
printf(\nLoop time for x *= 5\n);
TESTIT(xi *= 5, int32_t);
TESTIT(xl *= 5, int64_t);
TESTIT(xd *= 5, double );
xd = xl = xi = 1;
printf(\nLoop time for x *= sqrt2\n);
TESTIT(xi *= sqrt2, int32_t);
TESTIT(xl *= sqrt2, int64_t);
TESTIT(xd *= sqrt2, double );
return 0;
}
$ gcc -lm testb.c -o testb
$ ./testb
Loop time for x++
int32_t 3.600433
int64_t 4.301995
double 7.725700
Loop time for x *= 5
int32_t 5.205665
int64_t 8.391968
double 7.733138
Loop time for x *= sqrt2
int32_t 22.415493
int64_t 22.022103
double 7.911313
$ grep 'name' /proc/cpuinfo
model name : AMD Athlon(TM) XP 2400+
$
On another box:
$ ./testb
Loop time for x++
int32_t 2.429795
int64_t 2.664763
double 5.269211
Loop time for x *= 5
int32_t 2.641352
int64_t 4.079825
double 5.107343
Loop time for x *= sqrt2
int32_t 14.814515
int64_t 14.814356
double 4.951645
$ grep 'name' /proc/cpuinfo | head -1
model name : AMD Phenom(tm) II X4 925 Processor
$
As you can see from above:
int32_t is fastest for simple + and *
double has an almost constant operator time
The performance choise is between int32_t and double:
for + int32_t wins with a factor 2, and for * double wins
with a factor 3.
What operation is the most common in pcb ?
Regards,
/Karl Hammar
-
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Sat, Oct 09, 2010 at 04:02:37PM +0200, Karl Hammar wrote: As you can see from above: int32_t is fastest for simple + and * double has an almost constant operator time The performance choise is between int32_t and double: for + int32_t wins with a factor 2, and for * double wins with a factor 3. What operation is the most common in pcb ? I think we should also test sin and cos -- and since for integers, there will be casts involved on either side, I suspect there will be a performance hit. Also sqrt and pow. (In Lisp, isqrt beats sqrt, but I just tested in C (gcc -O3 -lm), and sqrt wins by a factor of 10!) Perhaps I simply have a crappy isqrt implementation, but this seems like an argument in favor of floating-point. How common are these ops in pcb? How common would they be if we had a decent DRC? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Sat, Oct 09, 2010 at 12:22:52PM +0200, Karl Hammar wrote: You cannot dissmiss floating point on the ground of rounding error when in fact the rounding error of integers (aliasing, truncation) are in fact greater. You cannot dissmiss floating point on the ground of a non exact equality operator, boot integers and floats, when 1 == 1nm, suffers from beeing too fine grained. You will not see any difference for +/- 100 basic units when looking at the board, even with a microscope. My concern is not with ordinary numbers and their rounding error, but with extremely large ones. Once you get past the 52 digits in an IEEE-754 double (about 4500km in nanometers, so maybe I am being silly), you lose precision. You will no longer be able to place things with nanometer precision, which means that your 254-nm mils will no longer be accurate. Then, you've got rounding error and you're in the same place we are now. In other words, using a double artificially limits us to 52 bits versus 64 for an integer type. Having said that: 1. As you pointed out, sin and cos use double, so we'll have to at some point anyway. 2. 52-bit double is probably far more prevalent than 64-bit int. So there's no need for the silly 64-versus-32-bit version argument. 3. Doubles give us a lot of hardware-math, so my suspicion (confirmed by the few tests we have done here) is they are a net performance win. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Andrew Poelstra wrote: I think we should also test sin and cos -- and since for integers, there will be casts involved on either side, I suspect there will be a performance hit. Also sqrt and pow. (In Lisp, isqrt beats sqrt, but I just tested in C (gcc -O3 -lm), and sqrt wins by a factor of 10!) Perhaps I simply have a crappy isqrt implementation, but this seems like an argument in favor of floating-point. How common are these ops in pcb? How common would they be if we had a decent DRC? sin, cos, sqrt and other heavy functions are most likely avoided, even for design rule checks and don't (frequently) occur for placement operations, since normally rotation matrices are used, that are set up once and then used for all coordinates of the relevant object (e.g. an oblique footprint). For DRC distances on would compare the square of distance to the square of the limit, giving the same truth value. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
$ ./testb Loop time for x++ int32_t 2.429795 int64_t 2.664763 Loop time for x *= 5 int32_t 2.641352 int64_t 4.079825 We're not storing our core units as doubles. We do a *lot* of Px = Cx * m + b type of operations; scalar multiplication is going to be a factor. We also do a *lot* of comparisons like if (min x x max) For DRC we do a lot of sqrt(x*x+y*y) operations, but we can switch to doubles for that (and the optimizer and puller). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Once you get past the 52 digits in an IEEE-754 double How would such numbers be represented in a file? One of gEDA/PCB's strengths is they are easy to script. Scripting (u)ints seems a lot easier. -- http://blog.softwaresafety.net/ http://www.designer-iii.com/ http://www.wearablesmartsensors.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Sat, 2010-10-09 at 08:37 -0700, Andrew Poelstra wrote: that your 254-nm mils will no longer be accurate. Will you make chips? I think they are already below 32nm. Confused with um? Sorry, I will not follow this discussion, I am sure the smart PCB developers will do it right. But my feeling is that 32 bit integer is more than enough precision -- if you do it right, at least not too wrong. Using 64 bit is like driving with a tank to your local milk store -- yes there may be benefits, you do not have to watch for the traffic. Its similar to numeric computing/simulations: 1969 they made it too the moon, smart people with 8 bit computers. Today we tend to use largest available precision, just because we have it, and because so we need not to think about the possible (numeric) problems. And please don't forget other architectures, i.g ARM and Mips, not all may support native 64 bit precision. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Andrew:
On Sat, Oct 09, 2010 at 12:22:52PM +0200, Karl Hammar wrote:
You cannot dissmiss floating point on the ground of rounding error
when in fact the rounding error of integers (aliasing, truncation)
are in fact greater.
You cannot dissmiss floating point on the ground of a non exact
equality operator, boot integers and floats, when 1 == 1nm, suffers
from beeing too fine grained. You will not see any difference for
+/- 100 basic units when looking at the board, even with a microscope.
My concern is not with ordinary numbers and their rounding error,
but with extremely large ones.
Once you get past the 52 digits in an IEEE-754 double (about 4500km in
nanometers, so maybe I am being silly), you lose precision. You will
no longer be able to place things with nanometer precision, which means
that your 254-nm mils will no longer be accurate.
Ok, if you really want that great precision, you could either use
a long double or some for of arbitrary-precision arithmetic, see
http://en.wikipedia.org/wiki/Bigint or e.g http://gmplib.org/.
But I would consider that clearly out of scope for pcb.
Then, you've got rounding error and you're in the same place we are
now.
Regarding the rounding error claim.
The error is there and it is easy to prove it. But I think you should
not overestimate it. Take a look at:
$ cat testc.c
#include stdio.h
int main(int argc, char *argv[]) {
double ui = 1e6 * 25.4; // um per inch
int ix;
double inch = 0;
int um = 0;
int umpitch = argc 1 ? atoi(argv[1]) : 800; // pitch in um
double inpitch = umpitch/ui; // dito but in inches
for (ix = 0; ix 1000; ix++) {
inch += inpitch;
um += umpitch;
}
printf(%g %g %i\n, inch, inch*ui, um);
printf(%g\n, inch*ui - um);
return 0;
}
$ ./testc
0.0314961 80 80
-2.04558e-08
$ ./testc 30
11.811 3e+08 3
6.77645e-06
$ ./testc 300
0.011811 30 30
3.38861e-09
$
This test shows that if we have inches as our basic unit, and using
a hypotetical 1000pin connector, the error we get is clearly below
the um range for 0.8mm, 0.3m, and 0.3mm pitch.
I consider thoose errors insignificant.
Regards,
/Karl Hammar
-
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Oct 9, 2010, at 4:30 AM, Karl Hammar wrote: but scaled integers are a bit easier to use and understand, Yes (but we are talking about internal values, the user don't have to see them, only the developers, think of todays 1mm). In an open source toolkit, the distinction between developer and user is blurry. This is a good thing, as far as I'm concerned. In any case, the developers have to understand the geometry calculations. There are subtle problems with carrying real number analytic geometry into a discrete domain. These are easier to deal with if the granularity is fixed, so if scaled integers have adequate dynamic range, they are to be preferred. I am surprised by the efficiency debate. I would think that for pcb, the vast bulk of calculation involves rendering graphics in device coordinates, not board geometry in board coordinates. Board coordinates are extremely important as *anchors* for rendering, so precise calculations are important here, but rendering itself is a different thing. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
I am surprised by the efficiency debate. I'm surprised we're still discussing this *at all*. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Sat, 2010-10-09 at 11:06 -0600, John Doty wrote: I am surprised by the efficiency debate. I would think that for pcb, the vast bulk of calculation involves rendering graphics in device DRC checks, clearing polygons,... Auto-Router may be distinct problem, I think Anthony did export/import. But maybe we want a push and show done inside of PCB. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Rick Collins gnuarm.2...@arius.com writes: To be perfectly correct, anyone who needs more than 84x84 inch boards will need to recompile PCB with 64-bit units. If it is me, I have no idea how to, so I can not. But I don't plan to. If I need boards larger than 84x84 inches, I will hire one of you to either layout the board for me or to recompile the tools. :^) Any 64-bit Linux distro will provide it ready to go. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
DJ Delorie wrote: I am surprised by the efficiency debate. I'm surprised we're still discussing this *at all*. I think/hope, this is future developers getting a feel for the project :-) ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Oct 9, 2010, at 11:18 AM, DJ Delorie wrote: I am surprised by the efficiency debate. I'm surprised we're still discussing this *at all*. You can't build a solid system on a shaky foundation. This is precisely the kind of thing we need to get right, or it will continue to cause unexpected artifacts to appear. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
I'm surprised we're still discussing this *at all*. You can't build a solid system on a shaky foundation. This is precisely the kind of thing we need to get right, or it will continue to cause unexpected artifacts to appear. I think we got it right the first time we discussed it way back when. We're just rehashing old arguments, no new info is being added. I know what we're going to do, and we all seem to agree it's the right thing to do. Where is this shaky foundation you're accusing us of? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 05:44 AM 10/9/2010, you wrote: Is this seriously turning into a pissing match So stop pissing on each other. I'm getting tired of the blow-by. This goes for Armin as well. Is there some reason we can't keep this civil? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 06:51 AM 10/9/2010, you wrote: Rick Collins: At 05:04 PM 10/8/2010, you wrote: Rick Collins: At 02:28 PM 10/8/2010, you wrote: Andrew Poelstra: On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: ... With integer types you get aliasing artifacts, which actually is a rounding error. We have this problem in the current incarnation of pcb. That is what you aren't getting. The problem is not aliasing in any way I understand aliasing. ... Maybe I should use the word truncation instead. I thought that the aliasing effect would make my point obious because most of you have experienced it. Wikipedia: In signal processing and related disciplines, aliasing refers to an effect that causes different signals to become indistinguishable (or aliases of one another) when sampled. So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? Floats aren't any worse if they have the resolution... but they aren't any better either! Agree, though there are corner cases e.g. x/3 gives truncation for integers, and big_value * big_value2 can give overflow where a double will thrive. ... C, As a side note, if you use double's for the internal representaion, then you don't loose precision compared to having an int32_t. You can convert an int32_t to an double and back without loosing precision. The issue is not using singles or doubles. The issue is whether the base unit is metric (which can perfectly represent inch units of interest) or whether the base unit are inch based which can't represent inch units perfectly. I suppose they could always change the base units to some small fraction of a mil so that even the accumulated error would always be negligible. But why bother changing and only getting an approximation if you can get it perfect? Ack. I know that using a basic unit of mm's or part thereof will solve the mil/mm problem. My point was that this does not have anything with integer vs. floating points. Ok, I agree. I guess all this was about nothing. Yes, don't dissmiss floating-point on false grounds. If it is for the performance, fine, but then you have to test. If ints and doubles comes out equally in a performance test, I'd choose doubles, since arcs, sin() etc. is done in doubles (unless you are using your own function tables). And I also hinted the reader that he/she could swap the 32bit ints for doubles and you would get the exactly the same results (unless you divide of cause, then doubles comes out better). Now I'm lost again... maybe. If you stick with inches, no, using doubles buys nothing. Well, it buys me a little, but it is not the solution for the mil/mm problem. The point about using doubles is that to use metric, it seems like going with a unit of nm is appropriate. Then you are limited to 2 or 4 meter max value with 32 bit ints. Going to double resolves that problem by giving you another factor of 4 billion in your range. I guess we are talking past each other while agreeing... yes? Absolutely. Unfortunately, you argue each little point and have not stated much. My point is that switching to a metric internal representation will allow inches to be represented exactly down to 0.01 mil as well as metric down to 1 nm. This will eliminate some of the current problems and introduce none other than changing the current size limit to 2 meters. In reality, this is extremely unlikely to be any issue, but because it is smaller than the solar system, some folks seem to think we need to have an alternate solution. Using 64 bit doubles would allows the entire solar system to be represented on a PCB in 1:1 scale, but might create a noticeable slow down, however we don't know that for sure since no one can say how much the slow down would be. Using floating point would allow perhaps the entire galaxy to be represented on a 1:1 PCB, but I am speculating now since there may not be equipment large enough to build such a board. Do we both agree on this? Anyone else disagree? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 03:36 PM 10/9/2010, you wrote: Rick Collins gnuarm.2...@arius.com writes: To be perfectly correct, anyone who needs more than 84x84 inch boards will need to recompile PCB with 64-bit units. If it is me, I have no idea how to, so I can not. But I don't plan to. If I need boards larger than 84x84 inches, I will hire one of you to either layout the board for me or to recompile the tools. :^) Any 64-bit Linux distro will provide it ready to go. 64 bit Linux distos include a 64 bit version of PCB? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Oct 9, 2010, at 5:41 PM, DJ Delorie wrote: I'm surprised we're still discussing this *at all*. You can't build a solid system on a shaky foundation. This is precisely the kind of thing we need to get right, or it will continue to cause unexpected artifacts to appear. I think we got it right the first time we discussed it way back when. We're just rehashing old arguments, no new info is being added. I know what we're going to do, and we all seem to agree it's the right thing to do. Where is this shaky foundation you're accusing us of? I'm not accusing. The point is that this is apparently important, and hasn't been done yet. I'm not sure there is agreement. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Thu, Oct 07, 2010 at 04:23:34PM -0700, Andrew Poelstra wrote: On Fri, Oct 08, 2010 at 01:00:50AM +0200, kai-martin knaak wrote: I prefer 1 mm, sometimes 0.5 mm :-) (Are there any plans to make inside pcb metric?) I would vote for this. +1 Really, the inch is by definition 2540µm, not the other way around since over 50 years ago. Besides that, the vast majority of the packages I use are defined in metric dimensions (1mm BGA, 0.65mm TSSOP, 0.5mm QFN). There are some still defined in inch but they have too few pins (=8) to matter. (But no, not that I've heard.) Neither. Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Thu, Oct 07, 2010 at 04:48:37PM -0700, Andrew Poelstra wrote: On Thu, Oct 07, 2010 at 05:37:48PM -0600, John Doty wrote: On Oct 7, 2010, at 5:00 PM, kai-martin knaak wrote: (Are there any plans to make inside pcb metric?) A couple of years ago I suggested making the fundamental units nanometers, since that would make decimal fractions of inches exactly representable as integers down to 0.01 mil. 0.01 mil = 254 nm by definition. Even on a 32-bit system, this would allow 4-meter boards, unless I'm going crazy. So if anyone has the tenacity to actually switch the units, this seems like a better idea than millimeters. Besides that 64 bit have become commonplace now. You really need signed integers in some places, and there boards which are larger than 2 meters (for some antennas AFAIK). I think that it should have done when switching from mil to finer units. 0.01 mil is 254nm, and using 2nm (exactly 127 times finer) as an unit does not sound right. On the other hand, 1mil was 25.4µm so 100nm would have worked. Unless you wanted to design chips with PCB (you don't want, use the right tool for the job). Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Gabriel Paubert wrote: Really, the inch is by definition 2540µm, not the other way around since over 50 years ago. As far as I know, 1 = 25400um, but I see your point ;-) The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). Assuming 32-bit signed numbers with 1/100mil this gives: 254nm resolution and +-545.46m coordinate range 32-bit signed and 1nm gives: 1nm resolution ;-) and +-2.147m coordinate range I don't know, if pcb really uses fix-point arithmetics, but even if not a reasonable internal unit has some importance. AFAIK with floating point, the average internal number should be around 1. HTH, Armin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, Oct 8, 2010 at 5:46 PM, Armin Faltl armin.fa...@aon.at wrote: Gabriel Paubert wrote: Really, the inch is by definition 2540µm, not the other way around since over 50 years ago. As far as I know, 1 = 25400um, but I see your point ;-) The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). Assuming 32-bit signed numbers with 1/100mil this gives: 254nm resolution and +-545.46m coordinate range 32-bit signed and 1nm gives: 1nm resolution ;-) and +-2.147m coordinate range I don't know, if pcb really uses fix-point arithmetics, but even if not a reasonable internal unit has some importance. AFAIK with floating point, the average internal number should be around 1. HTH, Armin No floating point, all integer to avoid rounding errors. DJ, are the pcb units still wrapped in the accessor macros for converting between internal representation and real world values? If so... Guys change the converters and have at your hearts content. It should be a 2 hour patch. Now for conversion errors, are you really seeing errors in your metric PCBs? As far as I am concirned the internal unit is meaningless provided it is fine enough. I know no fab house that is going to have a tolerance as good as 254nm or .01mil So as far as it matters in the real world, getting other things done in pcb is much more important, than a conversion to metric base units. meaning proposing that we make PCB 64 bit and nanometers is redicolus. We will double our ram usage and not gain ANY benifits. And to think this started out cause I suggested to use a really corse grid to start layouts, and keep things pretty. Use metric if your primarally using metric parts and use mils if your using inch defined parts. Chances are that people arn't placing their parts by snapping to pin one to move it on grid when placing anyhow. BTW, I'd vote for 1 unit, and a scale value. That is if you are making a 10 meter antenna, Then you set the PCB's scale to 0.1mm. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, 2010-10-08 at 18:31 +0800, Steven Michalske wrote: Now for conversion errors, are you really seeing errors in your metric PCBs? Sure -- there was a long discussion started by me two years ago. With mm grid we sometimes get 0.01mil garbage segments when we do diagonal lines. There was an explanation by DJ, it may be due to the fact that length of the diagonal is not ... Sorry, will stop before writing nonsense. See http://archives.seul.org/geda/user/Nov-2008/msg00425.html That 0.01mil garbage segments is for me an indication for not really good design/programming -- if I had seen that during first testing of PCB, maybe I never started using it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 06:31 AM 10/8/2010, you wrote: On Fri, Oct 8, 2010 at 5:46 PM, Armin Faltl armin.fa...@aon.at wrote: Gabriel Paubert wrote: Really, the inch is by definition 2540µm, not the other way around since over 50 years ago. As far as I know, 1 = 25400um, but I see your point ;-) The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). Assuming 32-bit signed numbers with 1/100mil this gives: 254nm resolution and +-545.46m coordinate range 32-bit signed and 1nm gives: 1nm resolution ;-) and +-2.147m coordinate range The point is that using 1 nm allows both metric and inch coordinates to be represented without introducing errors. Working in units of 0.01 mil does not allow metric to be expressed without rounding error. This error may show up in most designs, but if a consideration is to allow boards larger than 2 meters across, I would think that the possibility of rounding error for metric measurements accumulating to a significant error could be a problem. I don't know, if pcb really uses fix-point arithmetics, but even if not a reasonable internal unit has some importance. AFAIK with floating point, the average internal number should be around 1. HTH, Armin No floating point, all integer to avoid rounding errors. DJ, are the pcb units still wrapped in the accessor macros for converting between internal representation and real world values? If so... Guys change the converters and have at your hearts content. It should be a 2 hour patch. Now for conversion errors, are you really seeing errors in your metric PCBs? As far as I am concirned the internal unit is meaningless provided it is fine enough. I know no fab house that is going to have a tolerance as good as 254nm or .01mil That is not the concern. The problem is that on input a metric value will have a rounding error. When that error is compounded by the arithmetic (for example accumulative error in a large connector or chip pin spacing) the final error can become significant. So as far as it matters in the real world, getting other things done in pcb is much more important, than a conversion to metric base units. meaning proposing that we make PCB 64 bit and nanometers is redicolus. We will double our ram usage and not gain ANY benifits. Going to 64 bits buys you nothing if you don't increase the resolution of your internal units... other than allowing you to design PCBs nearly the size of the solar system. And to think this started out cause I suggested to use a really corse grid to start layouts, and keep things pretty. Use metric if your primarally using metric parts and use mils if your using inch defined parts. Chances are that people arn't placing their parts by snapping to pin one to move it on grid when placing anyhow. Why not? That is exactly what I do. I put my parts on grid and where practical, set the grid to match my parts. That keeps my traces from having jaggies. BTW, in the program I use, I can turn on snap to grid and route orthogonal and 45 degrees only. This allows me to route from pins to the grid without having any trace segments that are not on a 45 degree angle. Does PCB also support this? BTW, I'd vote for 1 unit, and a scale value. That is if you are making a 10 meter antenna, Then you set the PCB's scale to 0.1mm. I'm not sure what that even means. Are you suggesting that the internal representation be adjusted by the user? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: Gabriel Paubert wrote: Really, the inch is by definition 2540µm, not the other way around since over 50 years ago. As far as I know, 1 = 25400um, but I see your point ;-) The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). Assuming 32-bit signed numbers with 1/100mil this gives: 254nm resolution and +-545.46m coordinate range 32-bit signed and 1nm gives: 1nm resolution ;-) and +-2.147m coordinate range I don't know, if pcb really uses fix-point arithmetics, but even if not a reasonable internal unit has some importance. AFAIK with floating point, the average internal number should be around 1. HTH, Armin I don't think we could reasonably use floating-point. There is no room for rounding error when designing tight areas of a PCB. As for board limitations, I think that if you are designing boards bigger than 2m (and cannot make a small board then scale the gerbers after-the-fact), chances are you've got a 64-bit system. Of course, then we need to worry about file-format compatibility between 32- and 64- bit systems... Suppose we stored a scaling factor in the .pcb files, of x10, x100, x254, etc? Then we could use nanometer precision by default and go bigger if we need a bigger board. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, Oct 08, 2010 at 06:31:33PM +0800, Steven Michalske wrote: If so... Guys change the converters and have at your hearts content. It should be a 2 hour patch. Then we have file-format compatibility to deal with, and I'm sure there are weird cases that implicitly depend on the base unit (which should be rooted out at some point anyway, I know). For file-format compatibility, setting the scale-factor to 254 if none is specified, should do the trick. Now for conversion errors, are you really seeing errors in your metric PCBs? Maybe not, but we -do- see the cursor position given as 8., 7. instead of whole numbers, and these long strings overlap the GUI sometimes (I put a patch on the tracker about this when I first got here.) Hard to read, and irritating. As far as I am concirned the internal unit is meaningless provided it is fine enough. Yes, but millimeters cannot be expressed as a whole number of mils. Mils, however, can be expressed as a whole number of nanometers. So there's an important distinction. ... BTW, I'd vote for 1 unit, and a scale value. That is if you are making a 10 meter antenna, Then you set the PCB's scale to 0.1mm. +1 Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, Oct 08, 2010 at 08:41:06AM -0400, Rick Collins wrote: At 06:31 AM 10/8/2010, you wrote: BTW, I'd vote for 1 unit, and a scale value. That is if you are making a 10 meter antenna, Then you set the PCB's scale to 0.1mm. I'm not sure what that even means. Are you suggesting that the internal representation be adjusted by the user? Not quite. The ``internal resolution'' would be the same, but the visible units (on the gui and in the exports) would be scaled by the scale factor, on a per-.pcb basis. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Andrew Poelstra wrote: On Fri, Oct 08, 2010 at 06:31:33PM +0800, Steven Michalske wrote: If so... Guys change the converters and have at your hearts content. It should be a 2 hour patch. Then we have file-format compatibility to deal with, and I'm sure there are weird cases that implicitly depend on the base unit (which should be rooted out at some point anyway, I know). I don't think it would be a 2 hour patch: 100., .01, 10. and so on are used in many places to convert from PCB units to mils or inches; there is no couple of macros used consistently for this purpose. Now for conversion errors, are you really seeing errors in your metric PCBs? Maybe not, but we -do- see the cursor position given as 8., 7. instead of whole numbers, and these long strings overlap the GUI sometimes (I put a patch on the tracker about this when I first got here.) Hard to read, and irritating. I deal with it without changing PCB units: http://repo.or.cz/w/geda-pcb/dti.git/shortlog/refs/heads/ineiev-annoyingdecimals.squashed (and BTW the Lesstif HID provides another way to avoid that tail of nines). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 10:01 AM 10/8/2010, you wrote: On Fri, Oct 08, 2010 at 08:41:06AM -0400, Rick Collins wrote: At 06:31 AM 10/8/2010, you wrote: BTW, I'd vote for 1 unit, and a scale value. That is if you are making a 10 meter antenna, Then you set the PCB's scale to 0.1mm. I'm not sure what that even means. Are you suggesting that the internal representation be adjusted by the user? Not quite. The ``internal resolution'' would be the same, but the visible units (on the gui and in the exports) would be scaled by the scale factor, on a per-.pcb basis. If I understand correctly, this would not solve the problem. The problem results from working with data in metric format which can not be represented exactly using an inch based internal integer. If the internal representation is metric, then inches can be represented exactly. Are you suggesting that 32 bit integers representing nm could be used and the 2/4 meter limitation could be resolved by using a scale factor? Am I up to speed now? Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, 08 Oct 2010 10:31:10 -0400 Rick Collins gnuarm.2...@arius.com wrote: Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? I ended up designing my kitchen layout using PCB. I started with QCAD, gave a try for SweetHome (for java), and IKEA's tool. I realised that PCB was good for the job. Levente ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Andrew Poelstra wrote: As for board limitations, I think that if you are designing boards bigger than 2m (and cannot make a small board then scale the gerbers after-the-fact), chances are you've got a 64-bit system. Of course, then we need to worry about file-format compatibility between 32- and 64- bit systems... The files are ASCII text, so the numbers are not in binary anyway. The only potential problem would arise, if you try to read a 64-bit generated file with a board bigger than 2m into the 32-bit-app. Suppose we stored a scaling factor in the .pcb files, of x10, x100, x254, etc? Then we could use nanometer precision by default and go bigger if we need a bigger board. Sounds good for me as a transition path. As stated by others, no factor or just old version number in the file means x254, then nothing and new version could mean 1x, any other value means what it says. The scale factor and a version number of interpretation would be very practial in new-lib footprint definitions as well: Just say unit = 1000[nm] and write everything in micrometers, saving the numerous ums. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Oct 8, 2010, at 8:57 AM, Levente Kovacs wrote: On Fri, 08 Oct 2010 10:31:10 -0400 Rick Collins gnuarm.2...@arius.com wrote: Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? FYI -- the largest dimension I ever did on a board was 54 inches. The board was 54 x 5 inches. It was a specialized back-plane board. As I recall (this was in the 1980's) the 54 limit was determined by the maximum panel size of our vendor. The actual raw pcb panel was a little larger, but 54 inches allowed appropriate margins. Even as it was, the board was odd-ball enough that we had to hunt for a vendor that actually wanted the business (of course, it was a controlled-impedance board also, so it had some other unusual specification in addition). I couldn't say what the standard panel sizes are in the industry, but I could make an effort to find out. Of course, that could grow over time, but somehow I don't think a 4m x 4m board is likely even in the long term. IMHO, pcb design decisions should be based around making pcb a good tool for designing pcb's... if people find other uses or it, OK fine, but don't drive design decisions around odd-ball uses. There are other tools for mechanical CAD, architectural, etc. -dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, Oct 08, 2010 at 10:31:10AM -0400, Rick Collins wrote: At 10:01 AM 10/8/2010, you wrote: Not quite. The ``internal resolution'' would be the same, but the visible units (on the gui and in the exports) would be scaled by the scale factor, on a per-.pcb basis. If I understand correctly, this would not solve the problem. The problem results from working with data in metric format which can not be represented exactly using an inch based internal integer. If the internal representation is metric, then inches can be represented exactly. Are you suggesting that 32 bit integers representing nm could be used and the 2/4 meter limitation could be resolved by using a scale factor? Yes. Set the scale-factor to 1000, and now your base-unit is um, in that the smallest PCB object you can make will be scaled to a micrometer, and you can have 2km boards if you want. Am I up to speed now? Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
DJ, are the pcb units still wrapped in the accessor macros for converting between internal representation and real world values? They're supposed to be, but likely they're not. We'd need to extend the file format to specify a global default unit (defaults to 0.01 mil for backwards compatibility) and teach the save function to be smart about auto-detecting what the units probably are (mm vs mil vs raw) and putting the right units on them to (1) save space, (2) make the files more robust vs change, and (3) make them more readable. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Of course, then we need to worry about file-format compatibility between 32- and 64- bit systems... Files are text, no problem there. The routines that *read* files need to parse them as 64-bit integers always, but we can complain if (1) they don't fit in 32-bit and (2) PCB is built for 32-bit. Thus, people who need more than 2 meter boards can just rebuild pcb and get past the errors, but people who don't won't have subtle errors. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
FYI -- the largest dimension I ever did on a board was 54 inches. The largest board I've done in PCB was a quarter mile... I had a my house element. It was tiny. But I was only testing pcb's limits at the time... I couldn't say what the standard panel sizes are in the industry, but I could make an effort to find out. I'm guessing they're around 0.5 to 1.0 meter, based on the size of the drill machines... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 02:10 PM 10/8/2010, you wrote: FYI -- the largest dimension I ever did on a board was 54 inches. The largest board I've done in PCB was a quarter mile... I had a my house element. It was tiny. But I was only testing pcb's limits at the time... I couldn't say what the standard panel sizes are in the industry, but I could make an effort to find out. I'm guessing they're around 0.5 to 1.0 meter, based on the size of the drill machines... To find out would probably require a few calls to some of the larger PCB fab houses. If the drill machine were the ultimate limit, I would think that would only limit one dimension. Even if the table doesn't travel enough to cover the whole board, it can be repositioned after the first pass. But you can't drill further into the board than the machine will reach. I guess it may not be the same as CNC work, but I've done this with my drill press a number of times. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, 8 Oct 2010 14:10:39 -0400 DJ Delorie d...@delorie.com wrote: I'm guessing they're around 0.5 to 1.0 meter, based on the size of the drill machines... A couple of days ago, checked Eurocircuits (.com). They have a max of 425 x 425 mm (410 x 410 in tech pool). John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
All the drilling machines I've seen are limited in both directions. The board stack needs to be firmly pinned in place to ensure accuracy. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Andrew Poelstra: On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: ... The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). ... That might be true, but if you are talking about an internal representation with nm resolution, then you have the same problem as for the floating point, there are too many separate values that basically is the same value and you can't tell them apart looking at a board. ... I don't think we could reasonably use floating-point. There is no room for rounding error when designing tight areas of a PCB. That is nonsense, it is all about tolerances. 1, going from physical components to footprint file is basically a big averageing operation 2, going from pcb-file to physical pcb is a big rounding operation with some added noise, or do you believe you can make pcb's with nm's precision? ... Suppose we stored a scaling factor in the .pcb files, of x10, x100, x254, etc? Then we could use nanometer precision by default and go bigger if we need a bigger board. A, What is an integer plus a scaling factor? -- it is a floating point value. B, If you implement it as an integer (value) and an integer (scale), you could just as well do the scaling thing in some postprocessing step, outside of the pcb program. That is basically how gschem handles dimensions, it doesn't care. C, As a side note, if you use double's for the internal representaion, then you don't loose precision compared to having an int32_t. You can convert an int32_t to an double and back without loosing precision. Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Personally, I can't imagine a PCB larger than 2 meters much less 4 meters. Or is the possibility of uses other than PCB design being considered here? Someone once asked about doing a road bill-board sized sign. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Ok, I dont really think that PCB has to have the ablity to handle a house, or kitchen in terms of length. Yes. Set the scale-factor to 1000, and now your base-unit is um, in that the smallest PCB object you can make will be scaled to a micrometer, and you can have 2km boards if you want. Basically, I like this idea, but something tells me to stick to some unit. Let's say 10nm, which is OK for inch and mm; and you have 20m total board size, wich is more then enough. Even for a small kitchen. :-) Personally I'm okay with 2m as limitation. (my kitchen is ready, and I have a 64bit system :-)) Levente ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, 8 Oct 2010 14:08:12 -0400 DJ Delorie d...@delorie.com wrote: Files are text, no problem there. The routines that *read* files need to parse them as 64-bit integers always, but we can complain if (1) they don't fit in 32-bit and (2) PCB is built for 32-bit. Thus, people who need more than 2 meter boards can just rebuild pcb and get past the errors, but people who don't won't have subtle errors. Please forgive my ignorance, but can't one just define a 64bit integer on a 32bit system? I defined 32bit integers on a 8bit system with no problem. (atmel AVRs) Levente ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Please forgive my ignorance, but can't one just define a 64bit integer on a 32bit system? Yes, but there's a loss of performance if you do that. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
And a board can be secured easily from two sides. It is the alignment that requires some effort, but it can be done. At 02:28 PM 10/8/2010, you wrote: All the drilling machines I've seen are limited in both directions. The board stack needs to be firmly pinned in place to ensure accuracy. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 02:55 PM 10/8/2010, you wrote: Please forgive my ignorance, but can't one just define a 64bit integer on a 32bit system? Yes, but there's a loss of performance if you do that. Any idea of the loss of performance given that virtually all PCs these days are actually 64 bit machines? The laptop I am typing this on is a 64 bit, dual core 2 year old bargain basement priced machine I bought in a hurry for $550. It would have been a $400 machine, but I wanted the 17... er, 430 mm display. But then I forget about the people who want to design kitchens on their iPads... ;^) As someone pointed out, couldn't that be a build option? If someone needs to design boards larger than 2 meters, would it be a hard thing to do to build a 64 bit version? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 02:28 PM 10/8/2010, you wrote: Andrew Poelstra: On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: ... The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). ... That might be true, but if you are talking about an internal representation with nm resolution, then you have the same problem as for the floating point, there are too many separate values that basically is the same value and you can't tell them apart looking at a board. ... I don't think we could reasonably use floating-point. There is no room for rounding error when designing tight areas of a PCB. That is nonsense, it is all about tolerances. 1, going from physical components to footprint file is basically a big averageing operation 2, going from pcb-file to physical pcb is a big rounding operation with some added noise, or do you believe you can make pcb's with nm's precision? Yes, it is about tolerance... and error. How much error will be introduced into a design if the system rounds all metric measurements to 0.01 mils? How much tolerance is acceptable? When you can answer these two questions for all designs and all users you can't expect anyone to believe this is nonsense! If you have a connector, for example, with 100 pins spaced on metric centers, the accumulated error can approach a half mil or 0.0127 mm. That may be a significant fraction of the pin spacing and likely not a good idea. Larger connectors would have more accumulated error. I think your response above shows you don't actually understand the issue. Of course the issue is one that would not be of concern to most users, most of the time for most designs, by far. But it started with an issue of traces that were showing up as multiple jagged traces where a straight one was expected because... a metric grid was selected and the round off error was making grid points off center. There are other possible issues. When a metric input value is rounded off and then replicated, as someone said, for large connectors or mechanical attachments, the accumulated error can become significant and parts not fit. ... Suppose we stored a scaling factor in the .pcb files, of x10, x100, x254, etc? Then we could use nanometer precision by default and go bigger if we need a bigger board. A, What is an integer plus a scaling factor? -- it is a floating point value. No, it is a block floating point value. In this case the scale factor is not applied to the entire design until you display values or produce output. The internal calcs are still all integer. B, If you implement it as an integer (value) and an integer (scale), you could just as well do the scaling thing in some postprocessing step, outside of the pcb program. That is basically how gschem handles dimensions, it doesn't care. Or you can do it inside of PCB so that the user doesn't have to remember that all the displayed units are off by a factor of 10 or 2 or 5. C, As a side note, if you use double's for the internal representaion, then you don't loose precision compared to having an int32_t. You can convert an int32_t to an double and back without loosing precision. The issue is not using singles or doubles. The issue is whether the base unit is metric (which can perfectly represent inch units of interest) or whether the base unit are inch based which can't represent inch units perfectly. I suppose they could always change the base units to some small fraction of a mil so that even the accumulated error would always be negligible. But why bother changing and only getting an approximation if you can get it perfect? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
FYI -- the largest dimension I ever did on a board was 54 inches. The largest board I've done in PCB was a quarter mile... I had a my house element. It was tiny. But I was only testing pcb's limits at the time... I couldn't say what the standard panel sizes are in the industry, but I could make an effort to find out. I'm guessing they're around 0.5 to 1.0 meter, based on the size of the drill machines... To find out would probably require a few calls to some of the larger PCB fab houses. If the drill machine were the ultimate limit, I would think that would only limit one dimension. Even if the table doesn't travel enough to cover the whole board, it can be repositioned after the first pass. But you can't drill further into the board than the machine will reach. I guess it may not be the same as CNC work, but I've done this with my drill press a number of times. For flexible PCBs which are made on roll to roll machinery, the laser drills can make the required holes in a section, and then advance the web (roll) align to the previous holes, and continue. If they use a laser imager the same could be done on that step. All of the wet process steps are done roll to roll, so in reality you could make a continuous PCB thousands* of feet long. The main restriction is if their equipment could handle a gerber file that would need to be sectioned into hundreds or thousands of process steps (instead of their normal step and repeat). *The biggest constraint on roll length is how thick the rolls of material are when wound up, since the winding/unwinding machines have a diameter and weight limit. Andrew Miner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Any idea of the loss of performance given that virtually all PCs these days are actually 64 bit machines? My dual-core 3.2GHz machine supports 64-bit, but I installed a 32-bit OS for compatibility. So, 64-bit math is a performance hit for me. We can have the default unit be whatever the native long size is, 32-bit on 32-bit, 64-bit on 64-bit, so you always get the biggest fastest size. But we can still detect when your fastest size isn't big enough for some odd HUGE layout file. As someone pointed out, couldn't that be a build option? If someone needs to design boards larger than 2 meters, would it be a hard thing to do to build a 64 bit version? Of course it can. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Oct 8, 2010, at 12:42 PM, Andrew Miner wrote: For flexible PCBs which are made on roll to roll machinery, Good point, I forgot that a few months ago I saw some of these at a show. The vendor said you could do printed circuits 8 inches wide by arbitrarily long. Nice flex boards, too. -dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Oct 8, 2010, at 10:27 AM, Dave N6NZ wrote: I couldn't say what the standard panel sizes are in the industry, but I could make an effort to find out. FWIW, A quick poll of my friends indicates that 18x24 inches seems to be a standard panel size, but 48 x 22 inch boards used to be common in telecom, fabbed on 48 x 48 inch panels. A friend at Cisco says they regularly do 16x26 inch backplanes now. (and 14x21 inch 14 layer (!) boards that's a lot of layers in 21 inches. When I was at Amdahl, we did boards with 50 signal layers (and 12 or so power layers) but that was a smaller board, and we weren't trying to build thousands of them) Max size seems to vary a lot depending on the fab's equipment. I think the fab house that did my 54 inch board in the 1980's used panels around 60 inches long. So... if pcb were to be limited to a 2 meter by 2 meter board, would it actually be a painful limitation to anyone? Now that I think of it, my 54 inch board had to be done in two pieces because of the CAD software... but it was easy to line up the pieces because it was all transmission lines crossing the middle, and so vendor somehow got his photoplotter to paint left and right half files on the film with good registration. I also had an adventurous tech working for me who enjoyed challenges...) -dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Rick Collins: At 02:28 PM 10/8/2010, you wrote: Andrew Poelstra: On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: ... The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). ... That might be true, but if you are talking about an internal representation with nm resolution, then you have the same problem as for the floating point, there are too many separate values that basically is the same value and you can't tell them apart looking at a board. ... I don't think we could reasonably use floating-point. There is no room for rounding error when designing tight areas of a PCB. That is nonsense, it is all about tolerances. 1, going from physical components to footprint file is basically a big averageing operation 2, going from pcb-file to physical pcb is a big rounding operation with some added noise, or do you believe you can make pcb's with nm's precision? Yes, it is about tolerance... and error. How much error will be introduced into a design if the system rounds all metric measurements to 0.01 mils? How much tolerance is acceptable? When you can ... Please, I was commenting about the misunderstandings about floating-point, not about mils and mm's. With integer types you get aliasing artifacts, which actually is a rounding error. We have this problem in the current incarnation of pcb. So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? There are other possible issues. When a metric input value is rounded off and then replicated, as someone said, for large connectors or mechanical attachments, the accumulated error can become significant and parts not fit. ... Suppose we stored a scaling factor in the .pcb files, of x10, x100, x254, etc? Then we could use nanometer precision by default and go bigger if we need a bigger board. ... C, As a side note, if you use double's for the internal representaion, then you don't loose precision compared to having an int32_t. You can convert an int32_t to an double and back without loosing precision. The issue is not using singles or doubles. The issue is whether the base unit is metric (which can perfectly represent inch units of interest) or whether the base unit are inch based which can't represent inch units perfectly. I suppose they could always change the base units to some small fraction of a mil so that even the accumulated error would always be negligible. But why bother changing and only getting an approximation if you can get it perfect? Ack. I know that using a basic unit of mm's or part thereof will solve the mil/mm problem. My point was that this does not have anything with integer vs. floating points. And I also hinted the reader that he/she could swap the 32bit ints for doubles and you would get the exactly the same results (unless you divide of cause, then doubles comes out better). Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
So... if pcb were to be limited to a 2 meter by 2 meter board, would it actually be a painful limitation to anyone? MAXINT nm is 84.5 inches (just over 7 feet). Anyone who needs more than 84x84 inch boards can re-compile PCB with 64-bit units. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, Oct 08, 2010 at 11:04:59PM +0200, Karl Hammar wrote: Please, I was commenting about the misunderstandings about floating-point, not about mils and mm's. With integer types you get aliasing artifacts, which actually is a rounding error. We have this problem in the current incarnation of pcb. So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? The concern is with /binary/ floating point, not floating point in general. In binary floating point, your scale is always a power of 2, so some numbers cannot be represented - particularly, some numbers cannot be represented that /can/ be represented in decimal (like 0.3), so we will introduce an error when somebody types .3 into pcb. With integers, anything the user can type, can be represented. Importantly, 1/254 = 1/2 * 1/127 cannot be represented in binary floating point, which brings us back to the mm/mil problem. This is the crucial difference between our scaling idea (fundamental units + an arbitrary multiplier) and binary floating point. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Fri, 2010-10-08 at 15:42 -0400, DJ Delorie wrote: Any idea of the loss of performance given that virtually all PCs these days are actually 64 bit machines? My dual-core 3.2GHz machine supports 64-bit, but I installed a 32-bit OS for compatibility. So, 64-bit math is a performance hit for me. I'm not certain that is true.. or are you compiling with CFLAGS for a non 64-bit CPU? I thought the 32/64 bit OS issue was mostly to do with address pointers, rather than aritmetic. I was fairly sure one could execute 64bit native CPU arithmetic instructions under a 32-bit OS, just that the executable would not be portable to machines which didn't support those instructions. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
On Oct 8, 2010, at 3:04 PM, Karl Hammar wrote: So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? The problem is that in engineering documentation, dimensions are generally given as decimal fractions of inches or meters. Cumulative roundoff error can be avoided if the numeric encoding can exactly represent such numbers. Scaled integers or scaled floating point may be used, but scaled integers are a bit easier to use and understand, and are usually more efficient. Unscaled binary floating point is troublesome because it cannot exactly represent most decimal fractions, so it is prone to cumulative error. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 03:42 PM 10/8/2010, you wrote: Any idea of the loss of performance given that virtually all PCs these days are actually 64 bit machines? My dual-core 3.2GHz machine supports 64-bit, but I installed a 32-bit OS for compatibility. So, 64-bit math is a performance hit for me. We can have the default unit be whatever the native long size is, 32-bit on 32-bit, 64-bit on 64-bit, so you always get the biggest fastest size. But we can still detect when your fastest size isn't big enough for some odd HUGE layout file. I am asking how much of a performance hit. Has anyone actually done anything to calibrate this? Unless we have some idea of how much the performance hit would be, there is not much point in discussing it. A 1% slowdown is not worth talking about. A 1000% slowdown would be an issue. Numbers in between would be worth discussing. Performance issues fall into three categories in terms of impacting the user. A delay up to 0.3 seconds is not really noticeable as a delay to the user. From there up to 3 seconds is noticeable, but not enough to lose focus on your task. About 3 seconds to 30 seconds delay you lose focus on your task which significantly impacts your productivity and is very irritating. Beyond about 30 seconds and the user is inclined to leave the work station. Do you think the 64/32 bit performance issue would push any of the current operational delays across any of these thresholds? As someone pointed out, couldn't that be a build option? If someone needs to design boards larger than 2 meters, would it be a hard thing to do to build a 64 bit version? Of course it can. Then why should we worry about the remote possibility that a user will want a PCB larger than 2 meters? Their problem could be solved by creating a 64 bit version. I just saw your later post that clearly states your position so I guess I have my answer. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
At 05:04 PM 10/8/2010, you wrote: Rick Collins: At 02:28 PM 10/8/2010, you wrote: Andrew Poelstra: On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote: ... The only practical consideration I see is, that the internal unit of PCB allows handling with integer-arithmetic (makes comparisons a lot faster and safer than floating point). ... That might be true, but if you are talking about an internal representation with nm resolution, then you have the same problem as for the floating point, there are too many separate values that basically is the same value and you can't tell them apart looking at a board. ... I don't think we could reasonably use floating-point. There is no room for rounding error when designing tight areas of a PCB. That is nonsense, it is all about tolerances. 1, going from physical components to footprint file is basically a big averageing operation 2, going from pcb-file to physical pcb is a big rounding operation with some added noise, or do you believe you can make pcb's with nm's precision? Yes, it is about tolerance... and error. How much error will be introduced into a design if the system rounds all metric measurements to 0.01 mils? How much tolerance is acceptable? When you can ... Please, I was commenting about the misunderstandings about floating-point, not about mils and mm's. With integer types you get aliasing artifacts, which actually is a rounding error. We have this problem in the current incarnation of pcb. That is what you aren't getting. The problem is not aliasing in any way I understand aliasing. It is that you can't represent an exact metric value in an inch system. When you multiply an arbitrary number of few digits by 2.54 (convert inches to metric) you get two or three more digits than you started with. Try dividing the same by 2.54 (convert metric to inches) and you get a lot more digits than you started with, maybe infinite, I'm not sure. So in an inch based system you will never be able to represent metric numbers exactly. The opposite is not true, a metric based system can represent an inch value exactly. So you will not get a round off error of an input value. All points you need to calculate will be exact and the jaggies won't happen. This is not the same a finite resolution of a display or other bit mapped output. We aren't talking about the pixels lighting up on a CRT... er, LCD. We are talking about the end point of a trace not being in the right position so that a 45 degree trace can not connect them... exactly. That is what produces the jagged traces the OP complained about, if I understand the discussion correctly. So, in what way are floats worse than ints (I'm talking about representaion, not about performance) and why could we not reasonably use floating-point? Floats aren't any worse if they have the resolution... but they aren't any better either! There are other possible issues. When a metric input value is rounded off and then replicated, as someone said, for large connectors or mechanical attachments, the accumulated error can become significant and parts not fit. ... Suppose we stored a scaling factor in the .pcb files, of x10, x100, x254, etc? Then we could use nanometer precision by default and go bigger if we need a bigger board. ... C, As a side note, if you use double's for the internal representaion, then you don't loose precision compared to having an int32_t. You can convert an int32_t to an double and back without loosing precision. The issue is not using singles or doubles. The issue is whether the base unit is metric (which can perfectly represent inch units of interest) or whether the base unit are inch based which can't represent inch units perfectly. I suppose they could always change the base units to some small fraction of a mil so that even the accumulated error would always be negligible. But why bother changing and only getting an approximation if you can get it perfect? Ack. I know that using a basic unit of mm's or part thereof will solve the mil/mm problem. My point was that this does not have anything with integer vs. floating points. Ok, I agree. I guess all this was about nothing. And I also hinted the reader that he/she could swap the 32bit ints for doubles and you would get the exactly the same results (unless you divide of cause, then doubles comes out better). Now I'm lost again... maybe. If you stick with inches, no, using doubles buys nothing. The point about using doubles is that to use metric, it seems like going with a unit of nm is appropriate. Then you are limited to 2 or 4 meter max value with 32 bit ints. Going to double resolves that problem by giving you another factor of 4 billion in your range. I guess we are talking past each other while agreeing... yes? Rick ___ geda-user
