If I am not mistaken, IEEE 754-2008 
<https://en.wikipedia.org/wiki/IEEE_floating_point> only gives you 7 
digits of precision for a 32-bit float, and 16 digits with a 64-bit 
float.  So, writing out 20 digits is meaningless unless you are working 
with 128-bit floats (which I know we are not).  I still think the best 
way is to set it up with a configurable option.

On Apr 7 2016 11:38 AM, Niemand Sonst wrote:
> 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


------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to