El lunes, 2 de noviembre de 2015, 7:58:17 (UTC-6), Stefan Karpinski escribió: > > I think we should probably make it possible to access the full string of > a numeric literal in a macro but that is a substantial change to the parser. >
That would be great. Off-topic: Jeffrey, will your Float128 library be correctly-rounded? > > On Monday, November 2, 2015, David P. Sanders <[email protected] > <javascript:>> wrote: > >> >> >> El lunes, 2 de noviembre de 2015, 6:35:46 (UTC-6), Milan Bouchet-Valat >> escribió: >>> >>> Le lundi 02 novembre 2015 à 00:58 -0800, Jeffrey Sarnoff a écrit : >>> > I have many values like >>> > 0.6584871727288045313850172023417636020375045372547107712468813403 >>> > that come from Maple and I would like to avoid doing this by >>> > copy/paste for each one: >>> > Float128(parse(BigFloat,"0.658487172728804531385017202341763602037504 >>> > 5372547107712468813403")) >>> > >>> > I tried writing a macro that would put quotes around the value and >>> > then affix the rest -- without good result. >>> > julia>@fromMaple >>> > 0.6584871727288045313850172023417636020375045372547107712468813403 >>> > Float128(parse(BigFloat,"0.658487172728804531385017202341763602037504 >>> > 5372547107712468813403")) >>> > >>> > The REPL converts the unenquoted value to a Float64 before I get at >>> > it. >>> > >>> > Help is appreciated. >>> I don't think you can work around this at the moment. The best you can >>> do is to define a non-standard string literal by creating a @f128_str >>> macro, so that you can type these numbers as >>> f128"0.6584871727288045313850172023417636020375045372547107712468813403 >>> ". >>> >> >> There is already a `big` macro: >> >> Float128(big"0.65848717272880453138501720234176360203750453725471077124688134") >> >> Instead of copying and pasting in the REPL, couldn't you write these >> numbers to a file >> and read them in as strings in Julia? >> >> There has been some discussion in the past about forwarding strings like >> this to the parser >> already wrapped in a macro (as is done for large integer values); I don't >> recall what the >> issue with this was. >> >
