Hi Damian - Vass already pointed out numBytes(type t). numBytes is only supported for certain types (such as int and real types for sure). I think it would be possible to support that query for more types, but it's challenging because of the way Chapel generates C code and then runs a C compiler. (Normally, the C compiler makes decisions about how structure fields are padded, for example).
You said: >P.S. And while we are at it, on a philsophical point, > >Is something as fundamental to a variable as say the absolute value of a >number 'x', floating or integral, or even say its sign, given by > >a) attribute of the number, i.e. given by > > x.abs > >b) method applied to that number, i.e. given by > > x.abs() > >c) some function call > > abs(x : T) : T > >Not looking for a religious war here. Just some feedback. I'd probably prefer a method for namespace reasons. For something like frexp, the reason to use a function call is that some programmers might be familiar with it. In the case from your example, 'abs' is typically a function in other programming languages or in math, not a method (math doesn't really have methods...) so it seems more natural for it to be a function. So, I'd probably make abs and frexp functions (assuming that they do the same thing as what a programmer might already be familiar with). I'd reserve the no-parenthesis method version for situations where it really could be a field (and maybe was in one implementation). So if you're defining a record type, and you just want to access one field, I wouldn't worry too much about that since you could always replace the field with a method later. But, I probably wouldn't use the parenthesis-less method from the start unless the method did something that people might reasonably expect to be a field (like .size). In some ways my_real.mantissa or my_real.exponent are appealing though... But then you have to answer the question of whether or not mantissa is a int or a real? I wouldn't want to have my_real.intMantissa and my_real.fractionalMantissa, for example, since that will confuse people who don't know about parenthesis-less methods. Assuming you're thinking about frexp... I'd probably plan to provide frexp that corresponds to the C version: * proc frexp(x:real, out exponent:int): real and then also provide versions that return the mantissa as an integer as methods on reals. Beyond that, it might be more Chapel-y to have functions unpacking a real to return a tuple instead of through an out argument. That's just my two cents though. Doesn't necessarily represent consensus or anything. -michael >Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW >2037 >Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted >here >Views & opinions here are mine and not those of any past or present >employer > >-------------------------------------------------------------------------- >---- >One dashboard for servers and applications across Physical-Virtual-Cloud >Widest out-of-the-box monitoring support with 50+ applications >Performance metrics, stats and reports that give you Actionable Insights >Deep dive visibility with transaction tracing using APM Insight. >http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >_______________________________________________ >Chapel-users mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/chapel-users ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
