Sig,
Something that I would very much like to go on not really understanding<g> is that complexity of returning a double, and its further impact on callbacks. Aside from the usual myriad uses, my biggest interest in callbacks is for numerical analysis where double return values are very common. Is that something that you can make work by near magic? I don't really care if they require special handling, but it would be very nice if they are at least not very difficult to set up. Bill _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On 25 September 2010 21:45, Schwab,Wilhelm K <[hidden email]> wrote:
> Sig, > > Something that I would very much like to go on not really understanding<g> is that complexity of returning a double, and its further impact on callbacks. Aside from the usual myriad uses, my biggest interest in callbacks is for numerical analysis where double return values are very common. Is that something that you can make work by near magic? I don't really care if they require special handling, but it would be very nice if they are at least not very difficult to set up. > In short: yes. In long: you can always create own numeric type (like MyDouble) in smalltalk with its own storage format/fields. And with NativeBoost you can implement C<->smalltalk coercions for instances of this class. NativeBoost type lookup logic allows you to control types and/or aliases on a per-class basis. So, you can still use 'double' in function specification, and then make it to use MyDouble instances, instead of default Float. Btw, in Squeak Float using same storage size (64 bits) as C double, except that it stores them in big-endian format. In Cog VM, they are stored in little-endian, since cog runs on little-endian machines. > Bill > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Sat, Sep 25, 2010 at 12:06 PM, Igor Stasenko <[hidden email]> wrote: On 25 September 2010 21:45, Schwab,Wilhelm K <[hidden email]> wrote: Um, no. In Cog they are stored in the format of the host machine. The Cog Stack interpreter is not x86-specific. If you compile it on SPARC or big-endian PowerPC you'll find that floats are stored big-endian there-on.
cheers Eliot
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/9/25 Eliot Miranda <[hidden email]>:
> > > On Sat, Sep 25, 2010 at 12:06 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 25 September 2010 21:45, Schwab,Wilhelm K <[hidden email]> >> wrote: >> > Sig, >> > >> > Something that I would very much like to go on not really >> > understanding<g> is that complexity of returning a double, and its further >> > impact on callbacks. Aside from the usual myriad uses, my biggest interest >> > in callbacks is for numerical analysis where double return values are very >> > common. Is that something that you can make work by near magic? I don't >> > really care if they require special handling, but it would be very nice if >> > they are at least not very difficult to set up. >> > >> In short: yes. >> >> In long: you can always create own numeric type (like MyDouble) in >> smalltalk with its own storage format/fields. >> And with NativeBoost you can implement C<->smalltalk coercions for >> instances of this class. >> >> NativeBoost type lookup logic allows you to control types and/or >> aliases on a per-class basis. >> So, you can still use 'double' in function specification, and then >> make it to use MyDouble instances, instead of default Float. >> >> Btw, in Squeak Float using same storage size (64 bits) as C double, >> except that it stores them in big-endian format. >> In Cog VM, they are stored in little-endian, since cog runs on >> little-endian machines. > > Um, no. In Cog they are stored in the format of the host machine. The Cog > Stack interpreter is not x86-specific. If you compile it on SPARC or > big-endian PowerPC you'll find that floats are stored big-endian there-on. > cheers > Eliot > Thanks for clarification. In NB, apparently i have to be aware if it runs on Cog or Squeak, since in squeak Floats are always big-endian, and as you said, on Cog they using a host platform endian format. >> >> > Bill >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |