[PD] "good" phasor~ in B16.long-varispeed.pd not looping?

[Christof Ressi]

> I think it would be super nice if PD could have a 32 bit integer datatype.
 
Double precision Pd gives you 52-bit integer precision out of the box. Some scripting languages actually use doubles internally as the only number type, e.g. JavaScript, Lua (up to 5.2), 

> Perl has something Larry Wall calls "transmogrification".
> In Perl, there is just a single Scalar data type, which can be internally represented as a string, float, or integer.

This just sounds like a glorified tagged union and I don't think this is much different to Pd's atoms. Pd certainly *could* add integers to the set of possible atom types, but see below.

> It would probably require a major architecture change.

Yes, and a highly unlikely one :-). If I'm not mistaken, the original Max had integers (and recent Max/Msp certainly does), so it has been an intentional decision by Miller not to use integers in Pd.

Christof 
 

Gesendet: Montag, 06. Januar 2020 um 00:43 Uhr
Von: "William Huston" <williamahuston at gmail.com>
An: "Sebastian Shader" <sebfumaster at aol.com>
Cc: pd-list <pd-list at iem.at>
Betreff: Re: [PD] "good" phasor~ in B16.long-varispeed.pd not looping?

I think it would be super nice if PD could have a 32 bit integer datatype.
(I realize there would be a lot of underlying complexity)
 
Some quantities are naturally reals/floats
(voltages, instantaneous sound pressure levels)
 Other quantities are naturally integers
(counters, memory addresses).
 
IMO trying to force single-precision floats to represent numbers
which the programmer knows will always be integers, is like
banging a square peg into a round hole.
 
A much simpler approach would be to allow for an integer data type.
 
Yes, then you have to solve the problem of how you handle conversions
(connect an integer outlet to a float inlet, etc).
 
It would probably require a major architecture change.
 
I just want to throw this out there...
 
Perl has something Larry Wall calls "transmogrification".
In Perl, there is just a single Scalar data type, which can be
internally represented as a string, float, or integer.
 
The Perl interpreter tries to infer from the context whether
to represent the value as an integer or a float.
 
Just something to consider...
 
BH
 

--
William Huston:  WilliamAHuston at gmail.com[mailto:WilliamAHuston at gmail.com]
Binghamton NY

Public Service Mapping / Videography / Research / Education / Safety Advocacy
Blog[http://WilliamAHuston.blogspot.com] -- Facebook[http://facebook.com/billhuston] -- Twitter [http://twitter.com/WilliamAHuston] -- Youtube[https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1] -- Podcast Blog[https://billhustonpodcast.blogspot.com/]
Document collections: VirtualPipelines[http://TinyURL.com/VirtualPipelines] -- BHDCSDimockArchive[http://bit.ly/BHDCSDimockArchive]
Please support my work! -- TinyURL.com/DonateToBillHuston[http://TinyURL.com/DonateToBillHuston]
 

  

On Sun, Jan 5, 2020 at 6:29 PM Sebastian Shader via Pd-list <pd-list at lists.iem.at[mailto:pd-list at lists.iem.at]> wrote:
Is the reason that the "offset" inlet isn't a signal inlet mainly for performance in most use-cases?
Because if it were it seems like users could give 32-bit floats to both inlets, and have them added as doubles internally?

-Seb_______________________________________________
Pd-list at lists.iem.at[mailto:Pd-list at lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]_______________________________________________ Pd-list at lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]