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)
(voltages, instantaneous sound pressure levels)
(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@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
*Document collections*: VirtualPipelines http://TinyURL.com/VirtualPipelines -- BHDCSDimockArchive http://bit.ly/BHDCSDimockArchive *Please support my work! -- *TinyURL.com/DonateToBillHuston
On Sun, Jan 5, 2020 at 6:29 PM Sebastian Shader via Pd-list < pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list