• Christof Ressi christof.ressi@gmx.at [2020-01-06 00:37]:

there's the [tabread4~~] external in zexy which doesn exactly that. The help patch is missing, though. I guess [tabwrite4~] could also do that. Maybe enable it with a flag?

A flag could be avouded if the object would accept signals at the right inlet by default as messages would be casted to signals automatically (as you told me a few weeks ago).

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@gmail.com An: "Sebastian Shader" sebfumaster@aol.com Cc: pd-list pd-list@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@gmail.com[mailto: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] -- 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@lists.iem.at[mailto: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[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l... Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]