[Haskell-cafe] transcoding - Haskell?!

[Joachim Durchholz]

Am 14.06.20 um 12:25 schrieb Henning Thielemann:
> 
> On Sun, 14 Jun 2020, Joachim Durchholz wrote:
> 
>> Am 12.06.20 um 21:51 schrieb Henning Thielemann:
>>
>>> It could have its use to convert legacy code in legacy languages to 
>>> shiny new Haskell code. :-)
>>
>> Well, the AI would have to know what "shiny" code is.
> 
> I thought that this is the point of the AI approach and the training.

In that case, the trainer needs to know it.
Plus the trainer needs to know how to make the AI recognize it.

>> Otherwise, you'll just get a C++/VB/Cobol program written in Haskell.
> 
> This would still be helpful. Imagine we transcode LAPACK to Haskell. It 
> would be still FORTRAN or C encoded in Haskell with the same old FORTRAN 
> API, but we can easily generalize the code to any floating point number 
> type that any Haskell library provides, e.g. numbers with extended 
> precision, with decimal numbers or with interval arithmetics.

No, you wouldn't be able to generalize.
Well, sort of. Some things will work.
But there are corner cases where e.g. float and double behave 
differently. E.g. your lists of interpolation points may round 
differently, so you need adjustments to the algorithms that uses these 
tables. I haven't looked into Lapack itself but I know that 
floating-point is infamous for the amount of fiddly detail that you have 
to consider, sometimes separately for each bit width.

Fun fact: Numeric algorithms can break, i.e. produce incorrect results, 
if you do intermediate calculations with additional mantissa bits. This 
hurt the 8087 badly because they added an internal stack, which had 
80-bit mantissas, because, more precision so why not?

So... I tend to be scared if somebody claims to generalize 
floating-point code. Either because that person knows too little, or 
because that person knows so much more than me that they actually know 
how to deal with these complications :-)

Regards,
Jo