Thank you, Robert & Haravikk
Please allow me to respond in-line hereunder, thanks.
Ted.
> On 30.03.2016, at 16:15, Haravikk <[email protected]> wrote:
>
> I’m in favour of implicit conversion for integers where no data can be lost
> (UInt32 to Int64, Int32 to Int64 etc.), in fact I posted a similar thread a
> little while ago but can’t find it; there’s something being done with numbers
> so this may be partly in the works.
>
> I definitely think that implicit conversion for floating point should be
> avoided, as it can’t be guaranteed
Why? and What cannot be guaranteed?
> except in certain edge cases; for example, Javascript actually technically
> uses a double for all of its numeric types, effectively giving it a 52-bit
> (iirc) integer type,
awful, didn’t know that
> so in theory conversion of Int32 to Double is fine, and Int16 to Float might
> be as well, but I’m not certain if it’s a good idea or not, as it’s not quite
> the same as just extending the value.
It simply would cause a float with less precision as an integer like
10000 -becomes e.g - 9999.999999, (depending on magnitude, of course)
but that is normal in a floating point domain; E.g. also with:
var v:Double = 10000.0 // Double to Double
v would have the same imprecision… and could be anywhere between
9999.9998…10000.00001
(rough estimation, depending on magnitude and the floating point type used)
>
>> On 30 Mar 2016, at 14:57, Developer via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> What you describe, all those cases where one fixes losing precision by
>> simply "ignoring it", that's part of why I'm hesitant about simply throwing
>> in C-like promotion rules into any language.
E.g. if I assign an Int to a Double, then I know very well what I am doing.
often occurring simple example here:
for i in 0..<10
{
dTemperature = dInterval * i / / Double = Double *
Int (not possible yet in Swift)
foo(dTemperature)
}
Here I still have to write:
dTemperature = dInterval * Double(i)
However, Swift will accept:
dTemperature = dInterval * 3 // 3 inferred to Double.
could be regarded as an implicit conversion?
>> Once you add implicit type coercions, even just between integer or floating
>> point types, your language gains a hundred unspoken rules
Could you please explain these “unspoken rules” you mention more in detail?
>> and little guard rails you have to cling to lest you slip and hit the next
>> pitfall.
I am counting on the average intelligence of programmers.
>> Though you may be dismissive of information loss, it is a serious issue in
>> coercions, and one with implications that are never completely grokked by
>> experts
In practice, the implications/effects/behavior of a programming language
cannot be fully predicted and understood, there are simply too many
possibilities,
Functional Programming attempts to solve this, trying to make/do everything
mathematically
correct but fails for the aforementioned reason.
>> and serve as yet another hindrance to novices trying to adopt the language.
I don’t agree here. Even novices should have a good understanding
of the basic data types of a programming language,
Also note that concepts of integer, natural, rational, irrational numbers etc.
is very basic mathematics as learned in high school.
or your country’s equivalent education.
So aDouble = anInt should -in the programmer’s mind-
appear as an explicit conversion, that is, he/she should realize the
consequences.
The same applies also doing it explicitly like so:
aDouble = Double(anInt)
Same effect: even a fool can use this as well and not knowing the implications.
>>
>> So, I don't think coercion under this scheme is the complete end-all-be-all
>> solution to this problem, [though it may certainly feel right]. Sure, it is
>> always defined behavior to "downcast" a value of a lower bitwidth to one of
>> a higher bitwidth, but to dismiss Int -> Float, Float -> Int,
I wrote that I don’t want implicit conversion for Float -> Int.
>> and Double -> Float, etc. coercions as mere trifles is an attitude I don't
>> want enshrined in the language's type system.
>>
Could you give me an example where Double -> Float is problematic (apart from
loosing precision) ?
>> Perhaps there is a middle ground. Say, one could declare conformance to a
>> special kind of protocol declaring safe implicit convertibility (see: Idris'
>> solution of having an `implicit` conversion mechanism).
Please spare me from this kind of contraptions.
-=side note: =-
Thanks for bringing Idris to my attention. Investigating...
Idris is a FP language. I am not against it, but to me, FP is almost unreadable.
I doubt if I will ever use it.
I use strictly OOD/OOP. It’s natural. Like in Smalltalk. Proven. Solid.
For now, the only reason I use protocols in Swift are to accommodate
delegating/callbacks.
-= end side note =-
>> Or perhaps a good first step may be to not deal with information loss at
>> all, and only keep the parts of this proposal that are always defined
>> behavior.
To me, there is no unintended information loss, because I know what I am doing
regarding implicit conversion.
Then again, in all the cases for which I suggested implicit data type
conversion, there is no data loss (apart from precision)
TedvG
>>
>> ~Robert Widmann
>>
>> 2016/03/30 8:01、Ted F.A. van Gaalen via swift-evolution
>> <[email protected] <mailto:[email protected]>> のメッセージ:
>>
>>> Currently, one has to deal with explicit conversion between numerical types,
>>> which in many cases is unnecessary and costing time to code
>>> for things that are quite obvious,
>>> and cluttering the source, making it less readable.
>>>
>>> Especially dealing all the time with often unavoidable intermixing
>>> of floating point types CGFloat, Float, and Double
>>> is really very annoying.
>>>
>>> Conversion beween floating point types is always harmless as
>>> floating point types are essentially the same.
>>> They differ only in precision.
>>>
>>> Therefore, I would recommend allowing the following implicit type
>>> conversions:
>>>
>>> -between all floating point types e.g. Double, Float, CGFloat
>>>
>>> -from any integer type to floating point types
>>>
>>> -Also, personally, I wouldn’t mind assigning from a float to a (signed)
>>> integer
>>> because I know what I am doing: that the fraction is lost
>>> and that assigning a too large float to an Integer would then cause
>>> a run time error, which I can try/catch, of course.
>>>
>>> -from unsigned integer to signed integer
>>> (nothing is lost here, but overflow should cause a run time error)
>>>
>>> but no implicit conversion for:
>>> - from integer to unsigned integer (loosing sign here)
>>> - from a larger integer type to a smaller one e.g. Int32 <- Int64
>>> (truncation)
>>>
>>> Note however, that the compiler should issue warnings
>>> when you do implicit conversions, but these warnings
>>> are for most programmers of the “Yeah I know, don’t bug me.”
>>> type, so one should be able to switch off these type of warnings.
>>>
>>> Even a programmer with little experience simply knows
>>> that bringing integers into the floating point domain
>>> causes precision loss.
>>> He/she also knows that assigning a Double to a smaller floating
>>> point type also cause precision loss.
>>> the reverse is not true.
>>>
>>>
>>> Very much interested in your opinion!
>>>
>>> ----
>>> N.B. the above does not yet include
>>> the fixed decimal numerical type as this type is not yet
>>> available in Swift. However, it should be implemented
>>> *as soon as possible* because the fixed decimal type
>>> is really needed for applications working with financial data!
>>> E.g.
>>> var depositPromille: Decimal(10,3)
>>> typealias Money = Decimal(20,2)
>>>
>>> For more info on how this could be implemented
>>> in Swift. please read a PL/1 manual, ( i grew up in this world)
>>> like this one:
>>>
>>> http://www.ibm.com/support/knowledgecenter/#!/SSY2V3_4.3.0/com.ibm.entpli.doc_4.3/lr/preface_plugin.htm
>>>
>>> <http://www.ibm.com/support/knowledgecenter/#!/SSY2V3_4.3.0/com.ibm.entpli.doc_4.3/lr/preface_plugin.htm>
>>>
>>> especially under sub-topic “Data elements”
>>>
>>> (however, don’t take everything for granted, PL/1 is still a very young
>>> language :o)
>>> Unfortunately OOP never made it into PL/1 because with it, it would be
>>> nearly perfect.)
>>>
>>> Should I make a new swift-evolution topic for fixed decimal?
>>>
>>> Kind Regards
>>> TedvG
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
