Re: [PD] tanh~ (core dumped)

[Claude Heiland-Allen]

On 15/08/17 23:46, Matt Davey wrote to :
> I've always used:
>
> tanh(x) ~= x*(27+x*x) / (27+9*x*x)
>
> works well and is pretty CPU cheap

Nice.

That seems accurate to about 5 or 6 bits in my tests (over the range -4
to 4). A slightly more accurate (about 7 or 8 bits) variant is:

x * (27.2837670294674 + 1.22070209109864 * x * x)
  / (27.2837670294674 + 9.86205301460732 * x * x)

A higher degree version is accurate to about 16 or 17 bits:

x * (44220389.1067293 + 4672204.74255456 * x * x
  + 34604.8550273853 * x * x * x * x)
  / (44220389.1067293 + 19409074.7654446 * x * x
  + 612890.122925575 * x * x * x * x)

(Though I realize now, later, that there is some redundancy and they
could be normalized to have a leading "1 +" instead of these large
values...)

I found these using gnuplot's fit functionality:

F(x) = x * (a + b * x * x) / (a + c * x * x)
fit F(x) 'tanh.dat' via a,b,c

and similarly for the higher degree version.  'tanh.dat' contains 1024
equally spaced samples of x,tanh(x) in [-4,4], calculated in double
precision with a small C program, similar to the input generation in the
help patches.

I evaluated the accuracy visually in gnuplot:

bits(x,y) = log(abs(y - tanh(x))+2**(-53)) / log(2.0)
plot [-4:4] bits(x,F(x))

I don't know if single-precision rounding will affect the results much.
 I put the full precision coefficients into the patches using a text
editor, so  double precision Pd can benefit just in case.

It's probably also best to use [clip~ -4 4] before these functions, to
avoid possible Inf or NaN explosions, or maybe [clip~ -1 1] afterwards
would  be enough to be safe?

I haven't benchmarked yet.

Consider the patches placed into the Public Domain.  Message-rate
versions are left as an exercise.


Claude
-- 
https://mathr.co.uk


tanh~.tar.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] Debian/stretch: Pd-0.48

[IOhannes m zmölnig]

this is just to announce, that the latest and greatest Pd is now also
available pre-packaged for Debian 9 ("stretch").

Debian/stretch has been released in June 2017, *before* Pd-0.48 was
released. Debian policy does not allow updating packages after a Debian
release, which often means that users end up with out-of-date packages
(after all, Debian does a release every 2 years or so; which means that
available packages can be several years old - esp. if people insist on
not upgrading to the latest Debian/stable).

in comes Debian/backports, which allows users to install up-to-date
packages on their stable Debian systems, with full Debian support.

For instructions on how to enable this, see:

  http://backports.debian.org/

I intend to provide backports for all Pd related packages (Pd-vanilla
and all those externals available).
I do not intend to provide backports for Debian/jessie (RaspberryPi
users are advised to upgrade to Debian/stretch; really anybody is
advised to do that)

mfgsdr
IOhannes

sidenote: i generally recommend to use Debian/stable on servers, and use
Debian/testing (constantly updating) for anything multimedia related (as
you usually don't want to use multimedia applications that are several
years old). with Debian/backports you can have the best of two worlds -
a rock solid OS with some select up-to-date applications.



signature.asc
Description: OpenPGP digital signature
___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] hexloader incorporated into vanilla?

[IOhannes m zmoelnig]

On 08/04/17 06:27, Jonathan Wilkes via Pd-list wrote:
>> Sorry, I just noticed this message.
> 
> 
>> Pd's default loader mechanism has a "hexloader" in it.
> Nevermind-- it appears to be vestigial, as only the non-hexmunged name is 
> used 
> for the filename.

this is intentional.
filenames have way less restrictions than C-symbols, so there is little
reason to hexmunge them and make them even more unreadable by the
ordinary human.


On 08/04/17 01:30, Jonathan Wilkes via Pd-list wrote:
> Curious-- if the user tries to create [foo], what is the use case for
> the default loader trying to load "foo/foo.$pd_extension" and
> "foo/foo.pd"?

like: loading libraries that keep all their stuff (e.g. documentation)
local in a directory, trying not to pollute your path too much?
i very much prefer to look at:
  bar/
  foo1/
  foo2/
  foo3/
  foo4/
  foo5/
  foo6/
  foo7/
  foo8/
  foo9/
than to look at:
  bar.pd
  bar-help.pd
  foo1.pd
  foo1-help.pd
  foo2.pd
  foo2-help.pd
  foo2.txt
  foo3.pd
  foo3-help.pd
  foo4.pd
  foo4-help.pd
  foo5.pd
  foo5-help.pd
  foo5a.txt
  foo5b.txt
  foo6.pd
  foo6-help.pd
  foo7.pd
  foo7-help.pd
  foo8.pd
  foo8-help.pd
  foo9.pd
  foo9-help.pd
when i'm really only interested in the [bar] object.



sgdfmars
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [text] - notify outlet

[IOhannes m zmoelnig]

On 08/31/17 17:13, oliver wrote:
> BTW: i don't know if the list is the right place for feature requests,
> would it be the GITHUB site instead ?

a tracker (like github) is generally a better place, as these things
tend to get lost pretty easily.

> i didn't manage to open a pull
> request there despite being logged in.

why would you want to do a "pull request" (submitting code for
inclusion) if you want only want to request a feature to be implemented
(asking *others* to submit code).
use
   https://github.com/pure-data/pure-data/issues/new

fgamsdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list