It is currently Thu Jul 04, 2024 4:57 am


All times are UTC - 5 hours [ DST ]



Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: python "str()" vs tiny-fu "number->string"
PostPosted: Mon Jun 22, 2015 9:06 am  (#1) 
Offline
GimpChat Member
User avatar

Joined: Jan 20, 2013
Posts: 14816
Location: roma, italy
GIMP Version: 2.8.14
Operating System: Windows
GIMP Experience: Basic Level



@Ofnuts
I came back just a little to Python and it seems to me that the simple use of the Python built-in function str return a decimal number in a format acceptable to G'MIC, without asking any specific editing; I mean: if my filter calculates a value from a,b,c such as value = (a+b)/c the returned value is:
iiiiiii.ddddd
the whole part + a dot + the decimal part
provided c has decimals
this consideration came out from a few simple tests
using a=1250, b=750, c=3000 the result value seems to be only 0, but
using a=1250, b=750, c=3000.00 the result value comes out as 0.666666666
is it really so simple to interface G'MIC from Python?
or did I miss something?
thanks

_________________
"Where am I ?"


Last edited by dinasset on Mon Jun 22, 2015 10:04 am, edited 1 time in total.

Share on Facebook Share on Twitter Share on Orkut Share on Digg Share on MySpace Share on Delicious Share on Technorati
Top
 Post subject: Re: python "str()" vs tiny-fu "number->string"
PostPosted: Mon Jun 22, 2015 9:36 am  (#2) 
Offline
Script Coder
User avatar

Joined: Jun 22, 2010
Posts: 1171
Location: Here and there
Make sure at least one of your variables is a float, otherwise they get presumed to be integers:

>>> a = 1250
>>> b = 750
>>> c =3000
>>> (a + b)/c
0
>>> (a + b)/(c * 1.0)
0.6666666666666666
>>> (a + b)/ float(c)
0.6666666666666666
>>> a = float(1250)
>>> (a + b)/c
0.6666666666666666


Top
 Post subject: Re: python "str()" vs tiny-fu "number->string"
PostPosted: Mon Jun 22, 2015 10:14 am  (#3) 
Offline
GimpChat Member
User avatar

Joined: Jan 20, 2013
Posts: 14816
Location: roma, italy
thanks Kevin
this confirms my simple test above (where I set c=3000 result was integer 0, where I set c=3000.00 result was float 0.666666...)
I'm curious to know from users of python whether:
- the integer part is always expressed as a sequence of digits without any "disturbing" editing char
- the integer part is always separated by a decimal point (the only format accepted by G'MIC)
so that a value of 100000 divided by a value of 3.0 (float) gives in any local system the result as 33333.3333333333333333

_________________
"Where am I ?"


Top
 Post subject: Re: python "str()" vs tiny-fu "number->string"
PostPosted: Mon Jun 22, 2015 5:02 pm  (#4) 
Offline
Script Coder
User avatar

Joined: Oct 25, 2010
Posts: 4756
Yes, as far as I can tell from the docs and some experimenting:
  • Python uses the C locale by default (the decimal separator is a dot and there is no grouping)
  • You can set Python to use the user's locale or another locale you specify, but even then, str() and plain formating of numbers ("%3.2f" % 1234.5678) will still use the C locale, only the functions in the locale module are affected by this.

_________________
Image


Top
 Post subject: Re: python "str()" vs tiny-fu "number->string"
PostPosted: Tue Jun 23, 2015 1:31 am  (#5) 
Offline
GimpChat Member
User avatar

Joined: Jan 20, 2013
Posts: 14816
Location: roma, italy
thanks Ofnuts
I will prepare my first Python+G'MIC filter soon

_________________
"Where am I ?"


Top
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


   Similar Topics   Replies 
No new posts Attachment(s) Tiny Christmas Tree Brushes

12

No new posts Attachment(s) tiny text, aspect ratio, batch watermarking, instagram/twitter

1

No new posts Attachment(s) String Art Plug-in

26

No new posts Attachment(s) Columbine String Art.

6

No new posts Attachment(s) String Trussed Dalia

5



* Login  



Powered by phpBB3 © phpBB Group