I just want to avoid to get problems if there is some math behind that
pin and we do round to much.
If you take a new glas scale, you may have a intersection of 1µm and
that can be interpolated 20 times, so you get a very small value for the
increment in mm. Now change that one to inch and you do not get very far
with 4 digits!
If you make some maths, it does getting worth and worth with every
calculation and eaven old calculators do calculate with more than 20
digits, so why should we cut digits?
The print code I added, was just to show the rounding of the value we
get with the mentioned patch. I do agree, that we will not need to
display such small numbers in a Widget.
Norbert
Am 07.04.2016 um 18:19 schrieb EBo:
> I would vote for a high level configuration. Very few people need less
> than 0.0001", so a %.4f is fine. I know of very few machines that need
> to be parametrized in millionths or less. I also know of few machines
> which are also parametrized in meters or larger units.
>
> Can you explain why you would want to print a position out in very
> small fractions of a nanometer?
>
> EBo --
>
> On Apr 7 2016 10:19 AM, Niemand Sonst wrote:
>> I also do not like the patch as it is, as:
>>
>> print (float(0.0000000001)) gives 0.000000
>> so only 6 digits
>> print (".10f" %float(0.000000000000000001)) gives 0.0000000001
>> so 10 digits.
>>
>> Or we make it configurable or we set a higher digits number.
>>
>> I recommend as default to set it to "%.20f" and make it adjustable.
>>
>> Norbert (gmoccapy)
>>
>>
>>
>> Am 07.04.2016 um 03:33 schrieb EBo:
>>> On Apr 6 2016 6:17 PM, andy pugh wrote:
>>>> Discussed on IRC, jepler came up with
>>>>
>>>>
>>>> https://emergent.unpythonic.net/files/sandbox/0001-untested-work-around-1e-10-problem.patch
>>>>
>>>> (if Glade ends up with a very small number it might display
>>>> "0.0000"
>>>> but sent "1e-10" and then G-code says "unknown operator begining
>>>> with
>>>> e")
>>>>
>>>> Is that fix too clever? The parameters being substituted can only
>>>> ever
>>>> be hal pin values.
>>>> The only numeric type in G-code is float.
>>>> So simply changing float() to the %f formatting method is probably
>>>> a
>>>> universal fix?
>>> It would make sense to have the format sent in the number of digits
>>> precision user specified. I guess that is what you mean by a %f
>>> above
>>> (I would have said set the format to output the proper type like
>>> 'char
>>> *fmt = "%8.4f";', or better yet build it sprintf(fmt, "\%%d\.%df",
>>> length, decimal);) That would be a configurable universal fix.
>>>
>>> EBo --
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Emc-developers mailing list
>>> Emc-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
