{"action":"created","issue":{"url":"https://api.github.com/repos/boostorg/spirit/issues/421","repository_url":"https://api.github.com/repos/boostorg/spirit","labels_url":"https://api.github.com/repos/boostorg/spirit/issues/421/labels{/name}","comments_url":"https://api.github.com/repos/boostorg/spirit/issues/421/comments","events_url":"https://api.github.com/repos/boostorg/spirit/issues/421/events","html_url":"https://github.com/boostorg/spirit/issues/421","id":383196721,"node_id":"MDU6SXNzdWUzODMxOTY3MjE=","number":421,"title":"Floating point real parser policy rejecting fixed format","user":{"login":"mwpowellhtx","id":1824187,"node_id":"MDQ6VXNlcjE4MjQxODc=","avatar_url":"https://avatars2.githubusercontent.com/u/1824187?v=4","gravatar_id":"","url":"https://api.github.com/users/mwpowellhtx","html_url":"https://github.com/mwpowellhtx","followers_url":"https://api.github.com/users/mwpowellhtx/followers","following_url":"https://api.github.com/users/mwpowellhtx/following{/other_user}","gists_url":"https://api.github.com/users/mwpowellhtx/gists{/gist_id}","starred_url":"https://api.github.com/users/mwpowellhtx/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mwpowellhtx/subscriptions","organizations_url":"https://api.github.com/users/mwpowellhtx/orgs","repos_url":"https://api.github.com/users/mwpowellhtx/repos","events_url":"https://api.github.com/users/mwpowellhtx/events{/privacy}","received_events_url":"https://api.github.com/users/mwpowellhtx/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":12,"created_at":"2018-11-21T16:24:56Z","updated_at":"2018-11-23T00:16:34Z","closed_at":null,"author_association":"NONE","body":"Literally, I want the real parser policy to support a format something like this, in regular expression: ``(\\d*\\.\\d+)|(\\d+\\.\\d*)``. Something like that.\r\n\r\nLiterally, I've got the following v2 Protocol Buffer statement which is being rejected by Boost Spirit:\r\n\r\n```\r\nsyntax = 'proto2';option a =    933252761176835091419019014852578134454945897134240121039056292642745934626544776679309792643426912681734775655456099849022472225507009671635655261635494179939591695082743337844489696175391517474159955183289891072214770215979051082304343590361421008538352849939802258131368544983961387362613078430270357504.000000;\r\n```\r\n\r\nThis *Floating Point* number is well within the range of maximum ``double``: ``179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000000000000000``.\r\n\r\n```C++\r\nnamespace ast {\r\n    enum num_sign_t {\r\n        sign_none\r\n        /// '-'\r\n        , sign_minus\r\n        /// '+'\r\n        , sign_plus\r\n    };\r\n    // ...\r\n    using float_t = double;\r\n}\r\n```\r\n\r\n```C++\r\nqi::rule<It, ast::num_sign_t()> num_lit_sign;\r\n// ...\r\nqi::rule<It, ast::float_t()> float_lit;\r\nqi::rule<It, ast::floating_point_t()> floating_point_lit;\r\n``\r\n\r\n```C++\r\n// For use with both Integer and Floating Point Literals.\r\nnum_lit_sign %= ('-' >> qi::attr(ast::num_sign_t::sign_minus))\r\n    | ('+' >> qi::attr(ast::num_sign_t::sign_plus))\r\n    ;\r\n// ...\r\n// Floating-point literals\r\nfloat_lit %= real_parser<ast::float_t, strict_ureal_policies<ast::float_t>>{};\r\nfloating_point_lit %= -num_lit_sign >> float_lit;\r\n```\r\n\r\nThe parser works fine with scientific notation, as far as I can tell. But it rejects fixed point format. According to the [documentation](http://www.boost.org/doc/libs/1_68_0/libs/spirit/doc/html/spirit/qi/reference/numeric/real.html#spirit.qi.reference.numeric.real._code__phrase_role__identifier__realpolicies__phrase___code_), IMO it should be accepting fixed point format, but it is rejecting that.\r\n\r\nI'm not doing anything special for test cases, just generating some randomly distributed data, binary split, recursive, depth ~3 or so, count ~5 or so per depth. In other words, I generate some random values in the range, split the range in half, and call recursively for both halves, rinse and repeat. Like I said, nothing fancy for random test case generation.\r\n\r\nHowever, I'm concerned that the policy is a \"hard coded\" strategy, literally does not use Qi rules, etc. So, I do not know if that's a thing. Or if there are any traits, etc, I need to specify in order for fixed point to be properly supported."},"comment":{"url":"https://api.github.com/repos/boostorg/spirit/issues/comments/441136533","html_url":"https://github.com/boostorg/spirit/issues/421#issuecomment-441136533","issue_url":"https://api.github.com/repos/boostorg/spirit/issues/421","id":441136533,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0MTEzNjUzMw==","user":{"login":"Kojoley","id":2743474,"node_id":"MDQ6VXNlcjI3NDM0NzQ=","avatar_url":"https://avatars3.githubusercontent.com/u/2743474?v=4","gravatar_id":"","url":"https://api.github.com/users/Kojoley","html_url":"https://github.com/Kojoley","followers_url":"https://api.github.com/users/Kojoley/followers","following_url":"https://api.github.com/users/Kojoley/following{/other_user}","gists_url":"https://api.github.com/users/Kojoley/gists{/gist_id}","starred_url":"https://api.github.com/users/Kojoley/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Kojoley/subscriptions","organizations_url":"https://api.github.com/users/Kojoley/orgs","repos_url":"https://api.github.com/users/Kojoley/repos","events_url":"https://api.github.com/users/Kojoley/events{/privacy}","received_events_url":"https://api.github.com/users/Kojoley/received_events","type":"User","site_admin":false},"created_at":"2018-11-23T00:16:34Z","updated_at":"2018-11-23T00:16:34Z","author_association":"COLLABORATOR","body":"Thanks Joel. I am going to dig into the particular issue on the weekend as I expect it is not easy to debug and fix. I will appreciate any help on it, if it is a regression and was working somewhere in the past we should probably start with `git blame` and hopefully it will reveal the particular change that introduced the regression."}}
{"actor":{"display_login":"Kojoley"}}