On Thu, 21 May 2015, Michael Ferguson wrote:
> On 5/21/15, 7:42 AM, "Damian McGuckin" <[email protected]> wrote:
>>
>> Why would a 32 bit floating point number multiplied by a 32 bit integer
>> yield a 64 bit quantity? Is Chapel trying to avoid overflow?
>
> Yes.
That's admirable. But there are a gazillion other cases where you could
try and do that and it would just buy you trouble. Luckily you do not try
and you do not have the problems.
> This behavior matches the language specification.
I saw that. My original question was the reason behind that.
> In section 9.1.1, it says that int(32) won't coerce to real(32)
> since a real(32) can't represent an int(32) without loss of precision.
> Note though that int(64) can coerce to real(64) as "an important
> convenience."
I would prefer the rigour of saying that
int(width) can coerce to real(width)
and let the program(mer) address overflow issues which should be addressed
anyway by them. Just my 2c. Anytime you have a rule and then break it as
an "important convenience" is bound to buy you grief and make a rod for
your own back.
> I'd be interested to know your thoughts on this property - do
> you think that int(32) should coerce to real(32)?
Yes. See below. From what I can see
A) Remove the concept that
var x : real;
and
var x : real(64)
are the same and and make the default width of real a compile time
option, e.g.
chpl --default-width=32 ....
or
chpl --default-width=64 ....
(where the latter is the default case to match what it is now)
B) Enforce .. int(width) can coerce to real(width)
and with procedure overloading, you pretty much have a language which can
have a single source that can be used to build both 32-bit versions and
64-bit versions of say a finite element code or an optimization code or
whatever.
And by 32-bit or 64-bit version, I do not mean address space sizes, I mean
where the number crunching uses either IEEE854 binary32 and binary64. And
while binary32 computations run quicker than binary64, we will always need
such multiple versions.
This transparency of floating point sizes solves the holy grail of many
programs, an area which is just not really addressed by anything native.
Some people address the problem with preprocessors but that is grubby and
makes debugging painful.
Have a language whose default precision depends on how you conpile It
makes Chapel today's solution to a important problem, even outside the
main "raison d'etre" of Chapel.
Another few 2c replies. I still have a long way to go to get to a buck!
Regards - Damian
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
