Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2015-07-08

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:27 willthechill joined #perl11
05:04 travis-ci RPerl build passed. Will Braswell says 'Fix https://github.com/wbraswell/rperl/issues/23, Update Error Checking In Compiler Dependency Finder'
05:04 travis-ci https://travis-ci.org/wbraswell/rperl/builds/70007859 https://github.com/wbraswell/rperl/compare/cd9924947c4a...858503ad5d33
05:07 willthechill good deal
05:32 travis-ci RPerl build passed. Will Braswell says 'CPAN Release, v1.000004; Update POD-to-POD "See Also" Link'
05:32 travis-ci https://travis-ci.org/wbraswell/rperl/builds/70009853 https://github.com/wbraswell/rperl/compare/858503ad5d33...6c1fc92f3bb0
05:34 willthechill oh good
05:43 willthechill HOT OFF THE GRIDDLE
05:43 willthechill http://search.cpan.org/~wbraswell/RPerl-1.000004/
07:35 willthechill bulk88: please help me think about this problem   http://www.cpantesters.org/cpan/report/b29a3336-24a7-11e5-8b20-a5631ad7484d
07:35 willthechill the floating point number accuracy does not match
07:35 willthechill in some cases it gives more digits which are legitimate:
07:35 willthechill Failed test 'TNV08 number_to_string(3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679) returns correct value'
07:35 willthechill #   at t/04_type_scalar.t line 324.
07:35 willthechill #          got: '3.141_592_653_589_793_24'
07:35 willthechill #     expected: '3.141_592_653_589_79'
07:36 willthechill ...
07:36 willthechill and in some cases the extra digits are wrong!
07:36 willthechill #   Failed test 'TNVAVRV40 number_arrayref__typetest1(5) returns correct value'
07:36 willthechill #   at t/05_type_array.t line 342.
07:36 willthechill #     Structures begin differing at:
07:36 willthechill #          $got->[1] = '5.12345678899999957'
07:36 willthechill #     $expected->[1] = '5.123456789'
07:36 willthechill ...
07:37 rurban_ joined #perl11
07:44 willthechill rurban_: please help   https://github.com/wbraswell/rperl/issues/24
07:45 willthechill the floating point number accuracy does not match
07:45 willthechill <willthechill> in some cases it gives more digits which are legitimate:
07:45 willthechill <willthechill> Failed test 'TNV08 number_to_string(3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679) returns correct value'
07:45 willthechill <willthechill> #   at t/04_type_scalar.t line 324.
07:45 willthechill <willthechill> #          got: '3.141_592_653_589_793_24'
07:45 willthechill <willthechill> #     expected: '3.141_592_653_589_79'
07:45 willthechill and in some cases the extra digits are wrong!
07:45 willthechill #   Failed test 'TNVAVRV40 number_arrayref__typetest1(5) returns correct value'
07:45 willthechill #   at t/05_type_array.t line 342.
07:45 willthechill #     Structures begin differing at:
07:45 willthechill #          $got->[1] = '5.12345678899999957'
07:45 willthechill #     $expected->[1] = '5.123456789'
07:46 willthechill it only happens in PERLOPS_PERLTYPES
07:46 willthechill it is in the stringification "$number" operator
07:46 willthechill how can Perl give different output for the stringification operator?
07:47 willthechill is it because the Perl is compiled different or wrongly?
08:42 basiliscos joined #perl11
09:27 travis-ci RPerl build passed. Will Braswell says 'CPAN Release, v1.000005; Parser, Disable Perl::Critic PodSpelling To Avoid Aspell Error "No word lists can be found for the language"'
09:27 travis-ci https://travis-ci.org/wbraswell/rperl/builds/70027866 https://github.com/wbraswell/rperl/compare/6c1fc92f3bb0...6a6cad0ce348
09:52 travis-ci RPerl build passed. Will Braswell says 'README, Trim Content & Split THANKS'
09:52 travis-ci https://travis-ci.org/wbraswell/rperl/builds/70030181 https://github.com/wbraswell/rperl/compare/6a6cad0ce348...67bd0e8cfa92
09:53 willthechill cool
12:07 willthechill joined #perl11
14:48 rurban_ joined #perl11
15:53 basiliscos joined #perl11
16:45 Mikey joined #perl11
20:57 basiliscos joined #perl11
21:43 willthechill joined #perl11
21:52 willthechill joined #perl11
21:52 willthechill bulk88: any thoughts on the floating point error issue?
21:53 bulk88 floating point math is not reproducable
21:53 bulk88 *1.0 adds imprecision
21:53 bulk88 the CC's optimizer produces different results
21:53 bulk88 every non power of 2 FP operation adds imprecision
21:54 bulk88 you will have to do ($a - 5.0) < 0.0000000005 or something
21:54 bulk88 different GCC might optimize FPs different
21:55 bulk88 also the CC has to decide if intermediate operations are doing at 80 bits precision or 64 bit
21:55 bulk88 if the FP num is stored to C stack, it gets stuffed into 64 bits and looses digits, if the FP number is kept in a x87 FP register many more 80 bit ops can be done on it
21:56 bulk88 if your CC is set to ONLY use SSE math, all intermediate results are at 64 bits
21:58 bulk88 floating point math should not be used for life critical systems, or else http://www5.in.tum.de/lehre/seminare/semsoft/unterlagen_02/ariane/website/Img/Ariane-Explosion2.jpg will happen
21:59 willthechill yes I will be implementing rational numbers soon
21:59 willthechill but in the meantime I need to handle this bug
21:59 willthechill :/
22:04 bulk88 there is no other way http://grep.cpan.me/?q=%3C%200\.00000&page=1
22:06 willthechill *sigh*
22:06 willthechill okay
22:06 bulk88 https://metacpan.org/source/TOMFA/AI-Calibrate-1.5/t/AI-Calibrate-NB.t#L88
22:07 willthechill yes I will create my own version of epsilon error-checking
22:07 willthechill I was hoping Perl would be better
22:08 bulk88 file a bug ticket with your C compiler vendor and get laughed out of the room if you dont like that FP math is not reproducable
22:08 bulk88 Perl probably just does whatever the CC does
22:08 bulk88 64 vs 80 bit intermediate calculations
22:09 bulk88 and somewhere in perl there is the digits cutoff, again dervided from 64 or 80 bits
22:09 bulk88 i dont think anyone ever compiled perl with 32 bit NVs
22:09 bulk88 (aka C float)
22:10 bulk88 your choices are 64 bit doubles, 80 bit long doubles (x87), or 128 bit quads (software synthesized by GCC)
22:10 willthechill yeah this is kindof a "core bug" in modern computing...
22:11 willthechill I guess we need to switch ALL math to rational numbers and ONLY cast to float for printing
22:11 bulk88 powerpc and sparc have hardware 128 bit floats according to google, nobody else does
22:11 willthechill that should solve the problem
22:12 bulk88 radtional numbers mean infinite precision math/CAS libraries and now each math op can take 0 to end of universe nanoseconds to execute
22:13 bulk88 oh and infinite memory is needed too
22:13 willthechill OKAY FINE we'll figure out a way to make it work with a finite-memory system
22:13 willthechill ;)

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary