 | | | | | |
If I rotate a part in LDDP the result may look like this:
1 16 4E-15 4 -20 0 0 1 0 -1 0 -1 0 0 stud4.dat
This can be read by LDView and MLCad as a valid number.
Is such notation allowed in official parts? It is nowhere explicit allowed or
disallowed. The value 4E-15 is surely very small, but it could also be 4E-2 for
example.
I just want to know how to deal with such numbers in DATHeader.
cu
mikeheide
| | | | | | | | | | | | | | | |
In lugnet.cad.dev, Michael Heidemann wrote:
> If I rotate a part in LDDP the result may look like this:
>
> 1 16 4E-15 4 -20 0 0 1 0 -1 0 -1 0 0 stud4.dat
>
> This can be read by LDView and MLCad as a valid number.
> Is such notation allowed in official parts? It is nowhere explicit allowed or
> disallowed. The value 4E-15 is surely very small, but it could also be 4E-2 for
> example.
> I just want to know how to deal with such numbers in DATHeader.
>
> cu
> mikeheide
Such notation is not noted in any specs.. neither allowed or forbidden. At
least, I can't find such. Maybe we should bring this up at LSC at some point?
-Santeri
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Santeri Piippo wrote:
> In lugnet.cad.dev, Michael Heidemann wrote:
> > If I rotate a part in LDDP the result may look like this:
> >
> > 1 16 4E-15 4 -20 0 0 1 0 -1 0 -1 0 0 stud4.dat
> >
> > This can be read by LDView and MLCad as a valid number.
> > Is such notation allowed in official parts? It is nowhere explicit allowed or
> > disallowed. The value 4E-15 is surely very small, but it could also be 4E-2 for
> > example.
> > I just want to know how to deal with such numbers in DATHeader.
> >
> > cu
> > mikeheide
>
> Such notation is not noted in any specs.. neither allowed or forbidden. At
> least, I can't find such. Maybe we should bring this up at LSC at some point?
>
> -Santeri
I think it should be forbidden in official files as the benefit is very small
and it is not good human readable.
Benefit would be smaller filesize, as 0.0004 (6 characters) has more characters
than 4E-4 (4 characters).
Against could be 0.4 (3 characters) to 4E-1 (4 characters).
If we would allow it in this direction why not also in the other direction:
4E1 vs. 40.
So in my eyes the easiest way to deal with this is to forbit this in official
files.
As currently it is not forbidden, DATHeader will do not correct such a notation
if everything else is ok. But if a line is changed in DATHeader it will never be
written with such a notation.
cu
mikeheide
| | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Michael Heidemann wrote:
> If I rotate a part in LDDP the result may look like this:
>
> 1 16 4E-15 4 -20 0 0 1 0 -1 0 -1 0 0 stud4.dat
>
> This can be read by LDView and MLCad as a valid number.
> Is such notation allowed in official parts? It is nowhere explicit allowed or
> disallowed. The value 4E-15 is surely very small, but it could also be 4E-2 for
> example.
> I just want to know how to deal with such numbers in DATHeader.
>
> cu
> mikeheide
Such notation is not noted in any specs.. neither allowed or forbidden. At
least, I can't find such. Maybe we should bring this up at LSC at some point?
(FWIW I sent this in yesterday but it seems the server ate the message..
resending it)
-Santeri
| | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Michael Heidemann wrote:
> If I rotate a part in LDDP the result may look like this:
>
> 1 16 4E-15 4 -20 0 0 1 0 -1 0 -1 0 0 stud4.dat
>
> This can be read by LDView and MLCad as a valid number.
> Is such notation allowed in official parts? It is nowhere explicit allowed or
> disallowed. The value 4E-15 is surely very small, but it could also be 4E-2 for
> example.
> I just want to know how to deal with such numbers in DATHeader.
>
> cu
> mikeheide
My suggestion would be to read numbers in that notation but never write them.
I'm not sure why LDDP would write them that way (it would require some strange
output routines) but if one thing writes them then it's best to read them.
Tim
| | | | | | | | | | | | | | | | | | | | | |
| |
|
> My suggestion would be to read numbers in that notation but never write them.
I mostly agree with this policy.
> I'm not sure why LDDP would write them that way (it would require some strange
> output routines) but if one thing writes them then it's best to read them.
There is nothing strange in the routines, it is the standard format used to
represent very large or very small numbers in a limited number of digits.
Actually since values never get very large in LDraw parts (biggest is probably
50x50 baseplate, thus 1000 ldu), it's all a matter of proper rounding. As far as
I can tell, 4 digits after comma is OK for position coordinates, and 6 digits is
enough for matrices coefficients. The problem mentionned with values such as
1e-15 should not have occured if I had properly rounded the file.
Note also that LDDP has an auto rounding feature (on by default) that would have
prevented the problem from the beginning. But I disable it since this may
accumulate errors during complex parts work.
Also note that MLCad also cherfully generates scientific notation numbers (eg.
9.9e-005) for any number below 0.0001
Philo
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Philippe Hurbain wrote:
> > My suggestion would be to read numbers in that notation but never write them.
> I mostly agree with this policy.
>
> > I'm not sure why LDDP would write them that way (it would require some strange
> > output routines) but if one thing writes them then it's best to read them.
> There is nothing strange in the routines, it is the standard format used to
> represent very large or very small numbers in a limited number of digits.
I definitely know this. I see them far too much in my job as a numerical
physicist ;)
My point is that to write in mixed format (some %f and others %e) requires some
strange coding unless there is a weird language which does it automatically. I'm
pretty sure that to do it in C or Fortran would be quite hard.
> Actually since values never get very large in LDraw parts (biggest is probably
> 50x50 baseplate, thus 1000 ldu), it's all a matter of proper rounding. As far as
> I can tell, 4 digits after comma is OK for position coordinates, and 6 digits is
> enough for matrices coefficients. The problem mentionned with values such as
> 1e-15 should not have occured if I had properly rounded the file.
Yes. Actually LDraw files should always use a fixed digit rounding and never a
percentage rounding.
> Note also that LDDP has an auto rounding feature (on by default) that would have
> prevented the problem from the beginning. But I disable it since this may
> accumulate errors during complex parts work.
>
> Also note that MLCad also cherfully generates scientific notation numbers (eg.
> 9.9e-005) for any number below 0.0001
>
> Philo
That is bad behaviour IMO. It implies an accuracy which is not there. You should
never display anything more accurate than the maximum error (give or take a
bit).
To expand on your comment about proper rounding: The nature of operations in
LDraw files is such that fixed digit rounding is better in almost all
circumstances (except where you have a scaling and rotation, a rotation of a
huge or poorly centered submodel or many multiples of rotations such as in
complex part design). In a model file you are only interested in results within
x LDU where x is something less than 1 and in a standard model x will be at
maximum around 1000 times the error in a rotation in the most extreme case.
Tim
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Timothy Gould wrote:
> My point is that to write in mixed format (some %f and others %e) requires some
> strange coding unless there is a weird language which does it automatically. I'm
> pretty sure that to do it in C or Fortran would be quite hard.
Actually, in C, %g does exactly this. Having said that, I think LDDP is a
Delphi app, so it uses Pascal, and I don't remember how Pascal does formatting.
--Travis
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Timothy Gould wrote:
> > My point is that to write in mixed format (some %f and others %e) requires some
> > strange coding unless there is a weird language which does it automatically. I'm
> > pretty sure that to do it in C or Fortran would be quite hard.
>
> Actually, in C, %g does exactly this. Having said that, I think LDDP is a
> Delphi app, so it uses Pascal, and I don't remember how Pascal does formatting.
>
> --Travis
Ahhh. I'd never heard of %g before now. I'm so used to %f and %e it had never
occured to me that there might be a mixed option. Handy to know as I suspect it
would be helpful in reading files of unknown format.
I'm sure Delphi has some hideous yet totally type-safe system ;)
Tim
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Timothy Gould wrote:
> Ahhh. I'd never heard of %g before now. I'm so used to %f and %e it had never
> occured to me that there might be a mixed option. Handy to know as I suspect it
> would be helpful in reading files of unknown format.
All float specifiers (e, E, f, g, G) are treated identically by the scanf
functions. When scanning floats, they always recognize all float formats.
One other thing about %g on output is that it automatically strips trailing
zeros, which %f doesn't do. So it can actually be quite useful for printing
things that don't trigger it to go into scientific notation.
--Travis
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Travis Cobbs wrote:
> In lugnet.cad.dev, Timothy Gould wrote:
> > Ahhh. I'd never heard of %g before now. I'm so used to %f and %e it had never
> > occured to me that there might be a mixed option. Handy to know as I suspect it
> > would be helpful in reading files of unknown format.
>
> All float specifiers (e, E, f, g, G) are treated identically by the scanf
> functions. When scanning floats, they always recognize all float formats.
>
> One other thing about %g on output is that it automatically strips trailing
> zeros, which %f doesn't do. So it can actually be quite useful for printing
> things that don't trigger it to go into scientific notation.
>
> --Travis
Thanks for the info. I've always used perl scripts to convert oddly formatted
data to a consistent format and then read it like that. Nice to know I don't
always have to. If it could only read some of the more bizarre Fortran formats
I'd never have to do a conversion again.
Tim
PS. FUT set correctly this time. Apologies to .cad.dev for the wandering.
| | | | | | | | | | | | | | | | | | | | | | | | |
Tim Gould wrote:
> I'm sure Delphi has some hideous yet totally type-safe system ;)
Yes, and no, or rather, maybe. In Delphi you would do something like
Write(Format('%g', [Value]));
i.e more or less the same format strings as in C. But, it is type-safe at
runtime :-)
--
Anders Isaksson
| | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Michael Heidemann wrote:
> If I rotate a part in LDDP the result may look like this:
>
> 1 16 4E-15 4 -20 0 0 1 0 -1 0 -1 0 0 stud4.dat
>
> This can be read by LDView and MLCad as a valid number.
> Is such notation allowed in official parts? It is nowhere explicit allowed or
> disallowed. The value 4E-15 is surely very small, but it could also be 4E-2 for
> example.
> I just want to know how to deal with such numbers in DATHeader.
>
> cu
> mikeheide
Hmm, I thought I killed that "feature". I'll look into it as I find time to
finish up LDDP 2.1
-Orion
| | | | | | |
