[swift-evolution] floating point numbers implicit conversion
Ted F.A. van Gaalen
tedvgiosdev at gmail.com
Sat Jun 17 15:21:50 CDT 2017
Hi Xiaodi
in 1966-1970 PL/I, a static-typed procedural block-structured programming language
far ahead of its time, with the purpose of giving "all things to all programmers”
was introduced by IBM as their main (mainframe) programming flagship.
I’ve worked with PL/I very often during my life. It is truly general purpose and has tons
of features and is because of that quite overwhelming for starters like me in 1976 after
Fortran as my first PL. PL/I is a bit like riding a gigantic powerful motor cycle without
much instruction from the start and without training wheels back then of course.
Took some time to master PL/I (no screens let alone IDEs back then), however, with
the great reward to be in control of one of the most powerful PLs on the planet.
You might ask, what’s the context of this somewhat nostalgic emission: :o)
PL/I also has many data types like Binary, Bit, Character Complex, Decimal
Fixed, Float,Picture etc. of various lengths and storage
.
Implicit data type conversion (coercion) between almost all PL/I data types has
been available in PL/I right from the start. No problem - that is if you know what you are doing.
What exactly to expect from conversions in PL/I is always predictable, also
because it is described in detail in the programming manuals.
Furthermore PL/I diagnostics and warnings are excellent.
So, implicit data type conversion (coercion) has been successfully implemented and used in an
already complex programming language (in some cases far more advanced as Swift - apart from
OOP) almost 40 years ago…
It is now 2017 and you’re telling me that coercion is too difficult to implement in Swift ??
> On 16. Jun 2017, at 18:19, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> Implicit promotion has been brought up on the list before, many times over many years. The scale and implications of the change not to be underestimated.
>
It should be not so difficult I think… as it simply replaces
explicit casts and the compiler can detect implicit conversions easily;
be it in assignments, with expression operands or as call parameters.
> To give a taste of what would be involved, consider that new integer protocols were recently implemented that allow heterogeneous comparison; these have proved to be tricky to implement in a way that preserves user expectations in the context of integer literals. (I will write shortly with thoughts on revisiting certain specifics.)
Yes, can’t react on this need more information, I don’t see this in context of “user expectations” either.
btw, I was merely discussing Floating Point conversion <=> Integers?
> Implicit promotion would be much more complicated.
Why do you think so?
float = double // compiler inferred type conversion, what’s so difficult about this assignment?
Currently you’d have to use
float = Float(double) // and you’re doing (explicitly) exactly the same thing.
> There is little point in discussing whether such a feature in the abstract is desirable or not.
Abstract? I don’t think so and have described this subject fairly concrete,
illustrated with some examples.
To me and certainly also many others this feature is desirable.
As your say yourself
“it has been brought forward so many times”
Obviously many desire this feature and find this important.
> It would be necessary to have a detailed proposed design and evaluate whether the specific design is desirable, in light of its interactions with other parts of the system.
after gathering more insight, yes.
> For one, I think it’s important that no code that is currently legal produce a different result: this in itself is not trivial to achieve.
As you know, Swift currently does not facilitate implicit conversion (coercion),
which implies that current code (which of course does not contain implicit conversions)
will function exactly as it does now, when it was compiled in a Swift version in which
implicit conversion were implemented.
Kind Regards,
TedvG
www.tedvg.com
> On Fri, Jun 16, 2017 at 11:08 Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Hello,
>
> Appr. a year ago I suggested to allow implicit conversion between floating point number types,
> that is between Float, CGFloat Double..Float80 …
> (Note that CGFloat IS a Double on 64-bit systems btw),
>
> E.g I am currently making things using SceneKit 3D, wich obviously involves a lot
> of floating point arithmetic, using functions from several libraries where
> some use Floats, others Double or CGFloat etc..
> That wouldn't be so bad, were it not that all the work that I do contains
> a lot of of unavoidable explicit Floating point conversions like so:
>
> let ypos = CGFloat(1080.0 - (yGravity * yfactor)) // double in expression to CGFloat
>
> camera1.reorientate (
> SCNVector3(x: Float(motionGravityY * -0.08),
> y: Float(motionGravityX * -0.1),
> z: roll ) )
>
> This is tedious and makes source less readable.
>
> With implicit floating point number conversion It could be like this
>
> var float1,float2,float3: Float
> var double1,double2,double3: Double
> var cgfloat1, cgfloat2, ccgfloat3 CGFloat
>
> float1 = cgfloat2 * double3 + float1 // implicit conversion should be allowed (whereby everything
> in the expression should be promoted to the highest precision var in the expression (Double here)
> which then would be type wise:
> Float = CGFloat(implicitly. promoted to Double) * Double) + Float (imp. promoted to Double)
>
> Also, implicit conversion when passing function parameters would be very convenient as well e.g.
>
> This function:
> func someMath(p1: Float, p2: Float, result: Inout Float) {…}
>
> could then be called without explicit conversion like so:
>
> someMath(p1: double1, p2: cgfloat1, result: &double3)
>
> // yes, also on inout parameters. This is done 2 times during the call and when returning.
>
>
> As I vaguely remember there were objections to this implicit conversion of FP numbers,
> because this was (as viewed back then) too complicated to implement?
>
> Note that people that regularly work with floating point numbers are
> well aware about having a precision loss when e.g. when converting
> from Double to Float, or indeed between other numerical types as well
> no problem.
>
> For those not desiring such flexibility, there could be a new compiler option(s)
> that disallows this freedom of implicit floating point number conversion.
>
> or have at least (suppressible) compiler warnings about precision loss,
> e.g when doing this: float = double..
>
> ?
>
> Kind Regards from Speyer, Germany
> TedvG
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170617/11d8cd8f/attachment.html>
More information about the swift-evolution
mailing list