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
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:
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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'
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
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
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
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
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
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.
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
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
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
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,
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
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
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
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
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
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
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
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
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
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ö
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
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
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
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:
$
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
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
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
$ ./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
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/
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
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
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
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
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
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
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:
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
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
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
___
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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-
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 --
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
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
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
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
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
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
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
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
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
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.
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
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
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.
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
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
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
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
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.
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
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
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.
___
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
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
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
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
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
1 - 100 of 131 matches
Mail list logo
