Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Vlastimil Brom Newsgroups: comp.lang.python Subject: Re: math.frexp Date: Sun, 17 Jul 2016 01:18:30 +0200 Lines: 65 Message-ID: References: <5788cb76$0$1599$c3e8da3$5496439d@news.astraweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: news.uni-berlin.de WCE8JAIUF4JHvSJki7pSAwRioUbqUA8NxdPv1PCIOhFw== Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'else:': 0.03; 'operator': 0.03; 'root': 0.04; 'float': 0.05; '-*-': 0.07; 'extracted': 0.07; 'overflow': 0.07; 'utf-8': 0.07; '"""return': 0.09; 'arg': 0.09; 'coding:': 0.09; 'literal': 0.09; 'notation.': 0.09; 'output,': 0.09; 'python': 0.10; 'def': 0.13; 'args:': 0.16; 'downside': 0.16; 'fallback': 0.16; 'naive': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'tests': 0.18; 'proposed': 0.20; 'fraction': 0.22; 'skip:= 20': 0.22; 'accuracy': 0.23; 'import': 0.24; 'implemented': 0.24; 'header:In-Reply-To:1': 0.24; 'scale': 0.27; 'message-id:@mail.gmail.com': 0.27; 'fine': 0.28; "i'm": 0.30; 'url:mailman': 0.30; 'code': 0.30; 'compared': 0.30; 'another': 0.32; 'computing': 0.32; 'url:python': 0.33; "d'aprano": 0.33; 'ones,': 0.33; 'steven': 0.33; 'url:listinfo': 0.34; 'add': 0.34; 'received:google.com': 0.35; 'expected': 0.35; 'instead': 0.36; 'url:org': 0.36; 'possible.': 0.36; 'possible': 0.36; 'to:addr:python-list': 0.36; 'subject:: ': 0.37; 'support,': 0.37; 'thought': 0.37; 'version': 0.38; 'building': 0.38; 'skip:p 20': 0.38; 'hi,': 0.38; 'easily': 0.39; 'url:mail': 0.40; 'to:addr:python.org': 0.40; 'where': 0.40; 'back': 0.62; 'due': 0.65; 'fall': 0.66; 'power': 0.72; 'enhances': 0.84; 'float,': 0.84; 'to:name:python': 0.84 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=fdiE7GQYSodZQZDkUnsnY7EOq9W5WCHSOY9NhEBvcyI=; b=Tq7+Vv8Ej5clM0p2TFxe0CC7wze6ovfGtqgi76yVNQ+kzn9dxuoPMjw5AjAT+Cb36f rxO58qHSvS5jnz3UyhdSlBeLPD03VRvYNoOWwkyzdIL1HmGCggvXHoBZegXozyeeAAr+ 1MIx9H3WF+jpT5nAWxhyRSG7/Njd1/hPG+pdr46Mxs6AStkKEahTzOSKdZkn140ZUVo6 FGuGPUDpCk5uwZtRvjQaVYaDDD6/KtxZm8v+H6Ljtm7jjbwdzsMj2rhKUeFE4wic5Law zlV2HKqyrEAe927gHJEyTAcoUIBdWF/EWTAXPgiBqHQA5PDcSVMzv6lbOWDgE3XClmJi 26TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=fdiE7GQYSodZQZDkUnsnY7EOq9W5WCHSOY9NhEBvcyI=; b=Vq8CzGgCb+GGHHv/Hsyfe/UNZ8TRVS4r+6mvJuvZLzAZhPfLLRkh5PVHnfvvz9WDYk lX1qU1Qx+HbUlpBEknN8StyupcbfBPwgr+wy9WjZDKhuCLGyELbiBt76CDPAwR+TcJAK njcmoKV50Lsyi1Bt0QYwIYwYDug1AkB7XSnZDAYv7sPAXn98ng9SCNzulqiREhIdJ1N9 L20Cqe3t2gJNVOiE9QmDtezR+DgPyUrna8BFoJ+kywBwmKFWNeE+iF7tfLzQmYDmi96G 5xexHtBgH0B6vfBH8VvVobnPP3fwjIoK7vjJ+7e3mhrMdbP9rOW8IVFE6+oVmu83GMgD 8V6Q== X-Gm-Message-State: ALyK8tInmMLh58Ikgwiv6TifIHo0Xk7sG7O9KlI3zIQeCyqLN0X3QSNjk3E2J8R01zbO2yxktCriJHNpqCTn/w== X-Received: by 10.25.24.233 with SMTP id 102mr11990356lfy.187.1468711111568; Sat, 16 Jul 2016 16:18:31 -0700 (PDT) In-Reply-To: <5788cb76$0$1599$c3e8da3$5496439d@news.astraweb.com> X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <5788cb76$0$1599$c3e8da3$5496439d@news.astraweb.com> Xref: csiph.com comp.lang.python:111529 2016-07-15 13:39 GMT+02:00 Steven D'Aprano : > I'm experimenting with various implementations of product(values). Here's a > naive version that easily suffers from overflow: > > from functools import reduce > from operator import mul > > def product_naive(values): > return reduce(mul, values) >... > -- > Steven > -- > https://mail.python.org/mailman/listinfo/python-list Hi, just to add another approach to already proposed ones, I thought about using fractions for computations instead of floats where possible. The accuracy shoud be better, - it works fine for my tests with multiplying however, the downside is - for computing fractional power the fractions fall back to float, as irrational numbers are expected in the output, hence the float overflow is also possible (unless an individual implementation of the root computation would be used in gmean...). The hackish code in adapt_float_exp enhances the accuracy compared to directly building Fractions from large floats in exponential notation. (I can realise, that this approach might be insufficient for the scale you intend to support, due to the mentioned fallback to floats.) Regards, vbr ======================== #! Python # -*- coding: utf-8 -*- from fractions import Fraction def adapt_float_exp(flt): """Return Fraction extracted from float literal in exponential notation.""" if "e" not in str(flt).lower(): return Fraction(flt) else: mant_str, exp_str = str(flt).lower().split("e") return Fraction(mant_str) * 10 ** Fraction(exp_str) def prod_fract(*args): prod = 1 for arg in args: if isinstance(arg, float): arg = adapt_float_exp(arg) prod *= arg return prod def gmean(*args): prod = prod_fract(*args) root = Fraction(prod) ** Fraction(1, len(args)) # fractional power ** - irrational - implemented via floats !! - overflow ... return root print(repr(prod_fract(2.0, 1e200, 1e200, 1e-200, 1e-200, 3.0))) print(repr(gmean(2.0, 1e200, 1e200, 1e-200, 1e-200, 3.0)))