On Sun, 10 Oct 2010 09:04:13 -0700
Andrew Poelstra wrote:
> 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.
+1
With int, you know what is going on behind the scenes. It is
Rick Collins writes:
> At 03:36 PM 10/9/2010, you wrote:
>>Rick Collins 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 nee
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
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 Sun, 2010-10-10 at 13:38 +0200, Karl Hammar wrote:
>
> I'm also very surprised that we are still discussion this.
>
> I got into this thread due to some faulty assumptions about floats.
I think most of us know, that floating point operation today is similar
in speed than integer operations --
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 ap
> 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 valu
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
Karl Hammar wrote:
The claims about floating point so far are:
1, they have too great rounding error
2, equality operator ("==") is unusful
I assure you, this is a serious problem, not minor detail, at least in
mechanical CAD where everyone uses float or double. How I know this?
By programmi
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
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 e
Hello,
Felix Ruoff wrote:
The second one (0004...) introduces the gtk-default-dialog for
'overwrite-existing-file - confirmation'.
gtk_file_chooser_get_do_overwrite_confirmation() was introduced in gtk-2.8;
PCB current requirement is 2.4.0.
___
ged
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 ap
Am 10.10.2010 02:55, schrieb Peter Clifton:
On Sat, 2010-10-09 at 23:29 +0200, Felix Ruoff wrote:
Hello,
today I am trying to make patches from my recent days work. I am new to
git, so it takes much more time than I expected...
But, here are two more patches.
The first one (0002...) removes s
14 matches
Mail list logo
