Re: [PHP-DEV] [PATCH] double to long conversion change
Hi Daniel, >> But, for what you're testing, that's the behavior I'd expect -- once >> you've reached the precision of a double, you'll only get the closest >> representation possible (and of course a 64-bit long is more precise than >> a double since there's no floating point to represent). Also, I assume >> what can be represented by a double is the same across platforms, if it's >> IEEE 754. > > Yes. But I was expecting that since long on 64-bit machines holds 64 > bits in PHP (et al), that PHP would use C's long double type for floats > on 64-bit platforms rather than plain old doubles. It seems like the > user-friendly, PHP way to handle the situation, particularly as 64-bit > computers are commonplace these days. If you talk about 64 bit platforms, the 64 bit refers only to integers - not floats. There is no difference between the supported floating point types and operations of the most recent "32 bit" x86 processors and the newer "64 bit" x86_64 counterparts. Both have an i387 compatible FPU and both implement the SSE standard for vectorized floating point operations. SSE only supports single precision (23 + 8 + 1 = 32 bit) and double precision (52 + 11 + 1 = 64 bit) data types for vectorized operaitons. The i387 FPU supports single precision, double precision and a proprietary Intel "double extended" precision data type which uses 80 bits (actually only 79 are really necessary). Other processor architectures may only support single and double precision data types, yet others support some kind of "double double" precision which is a combination of two double precision values (total 128 bits) to support higher mantissa (but not higher exponent) and yet others support a real quad precision data type which has a larger mantissa and exponent. Some compilers allow the use of any of the above data types (Intel "double extended", "double-double", quad) via the »long double« C data type. Others (ESPECIALLY ALL the Microsoft compilers!) do not support »long double« but rather make »long double« be a normal double value. And for double-double data types the calculations are nearly always done with software emulation. So basically the situation is the following: You have 4 different possible data types for "long double" in C. Each with different mantissa and different exponent and 3 different sizes (64, 80 and 128 bit). To me, this sounds like hell. One of the changes I made in PHP 5.3 was actually to make sure *all* platforms use the normal IEEE double data type also for calculations. (there is something like "internal precision" in x87 compatible FPUs which makes life very complicated) This was done to ensure portability of the code. Because with floating point operations, even "simple" numbers (such as 0.01 or 1.0/3.0) cannot be exactly represented by a computer and thus every bit of the mantissa is required to approximate the number. If you then have different precisions on different platforms or even with different compilers, life gets complicated. For example, if you check that $a + $b >= $c on one system, this need not be true on another system if the precisions don't match - there are examples in both ways! So please, please, please: Don't complicate life and introduce "long double" in PHP. At least as long as there is no standardized >64 bit floating point data type that works across platforms and compilers. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserved namespaces
On 31.03.2009, at 08:51, Hannes Magnusson wrote: On Tue, Mar 31, 2009 at 04:47, Greg Beaver wrote: Lukas Kahwe Smith wrote: So where are we at here? If nobody proposes something, this will just slide by .. I propose reserving PHP. extensions can be PHP\extname (i.e. class PHP\Phar, or for extensions with multiple levels of hierarchy PHP\PDO\mysql etc.) +1 I don't think we should magically raise errors if someone tries to declare such namespace, but updating the userland naming guide would be good. That being said; Would it be possible to enforce the PHP\ internally? Otherwise extension authors will simply ignore the rule and come up with their own conventions... Ok, is this settled now? Anyone working a patch? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
On 02.04.2009, at 19:33, Johannes Schlüter wrote: Hi, On Wed, 2009-04-01 at 20:47 -0700, Justin Martin wrote: The update I'd like to propose is to the Zend Highlighter for PHP, specifically related to the highlight_file and highlight_string functions, as well as the php -s command. I don't see the need for a rush (or in other words: 5.3 can happily live without it imo) and for the general consideration there's still my patch from 2005 using a to have line numbers and adding id's so lines can directly be accessed by an URL. http://schlueters.de/~johannes/php/zend_highlight_20050312_1.diff About ini settings: We should avoid adding them as much as possible, making this an ini setting gives you trouble in case the admin plays with them for some reason and you don't overwrite them in the script, on the other hand it's the only way to make it work with "php -s" and the apache sapi's application/x-httpd-php-source. So in summary: Let's think carefully about this before committing the first idea which comes to mind. +1 .. lets get this sorted out in HEAD. Both the styling and the optional support for line numbers and anchors. As for Chris Stockton's proposal for simply having an array parameter with predefined keys, is this the first time we are starting to feel the need for named parameters in a real world example of something to be added to core? I know that several users have proposed such a feature before, but imho before we start adding arrays as a poor mans named parameter support, we might want to open that pandoras box again. Again nothing for 5.3 .. HEAD is where its at. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] double to long conversion change
Hi Matt, and everyone: On Mon, Apr 06, 2009 at 01:00:47PM -0500, Matt Wilmas wrote: > unless I'm missing something, > you're talking about converting long/int to double/float. That's the > opposite of this thread subject, which is how to convert a double to a > long when it's out of the range of a long. :-) It's a two way street. If the floats don't have enough precision, things get jumbled when converting the floats back to integers. > But, for what you're testing, that's the behavior I'd expect -- once > you've reached the precision of a double, you'll only get the closest > representation possible (and of course a 64-bit long is more precise than > a double since there's no floating point to represent). Also, I assume > what can be represented by a double is the same across platforms, if it's > IEEE 754. Yes. But I was expecting that since long on 64-bit machines holds 64 bits in PHP (et al), that PHP would use C's long double type for floats on 64-bit platforms rather than plain old doubles. It seems like the user-friendly, PHP way to handle the situation, particularly as 64-bit computers are commonplace these days. > Just curious though, you're saying that all whole numbers (from long) > below 2^53 are representable? (Powers of 2 should always be OK.) When > writing a big literal number on a 32-bit system, I'm seeing much lower > than that (around 2^40) I'm talking about 64-bit machines. > Like I said, I figure a double type should > behave the same everywhere. Unless the shell/bash uses a *long* double > type (twice as big as a regular double)? *shrug* Exactly. The test scripts in question are now available for download from http://www.analysisandsolutions.com/php/intfloat/ Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] when will PHP 5.3 RC2 be out?
On 07.04.2009, at 19:09, Kinch Zhang wrote: Just a question: when will PHP 5.3 RC2 be out? we're waiting for it so it would be good to know the schedule. I was hoping for a release this week on Thursday. At this time it seems unlikely that we will even release it Thursday next week. But surely the week after that at the latest .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] when will PHP 5.3 RC2 be out?
hi, list: Just a question: when will PHP 5.3 RC2 be out? we're waiting for it so it would be good to know the schedule. Regards, Kinch Zhang -- "Unix is simple. It just takes a genius to understand its simplicity." "Simplicity is the essence of happiness." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closure serialization.
Hi, On Tue, 2009-04-07 at 10:38 +0200, Lukas Kahwe Smith wrote: > > Currently you cannot serialize a closure. That certainly makes sense. [...] > I guess its a dont go there thing, as you also run into trouble with > "use"-d variables. In the long run, I guess, we should try to reach it. Ignoring the use stuff there were some ideas floating in the past, like storing the source or using APC or ... but not with 5.3. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: olafurw
vouched! He will be contributing to the benchmark creation project. Can someone please take care of his account + karma for the 'php-benchmarks' module? Done Thank you Derick! Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: olafurw
On Tue, 7 Apr 2009, Nuno Lopes wrote: > vouched! He will be contributing to the benchmark creation project. > Can someone please take care of his account + karma for the 'php-benchmarks' > module? Done Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: derickrethans -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: olafurw
vouched! He will be contributing to the benchmark creation project. Can someone please take care of his account + karma for the 'php-benchmarks' module? Thanks, Nuno - Original Message - Contributing benchmarks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compile-time hash value calculation (was: Patch for the php bug 47815)
On 31.03.2009, at 20:36, Dmitry Stogov wrote: Hi Basant, I've updated you patch for 5.3 (attached, don't forget to regenerate zend_vm_execute.h). 5.2 is closed for such changes anyway and I don't think the patch should be applied into 5.3 too, because it is in RC stage. I got ~10% speed-up on very synthetic benchmarks (b.php attached). The speed difference on real-life applications without opcode caches is invisible. I wasn't able to test it with caches. In general the idea is very interesting, but as I mentioned before I don't like extension of zend_opcode and tricky usage of object handlers. It should be done in some more general way. Anyway, please check if my changes didn't make your patch slower. May be someone would like to play with patch and make it better... Ok, stuff like this indeed too late for 5.3, so please if at all .. work on this in HEAD. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC2 and integer/float handling in 5.3
Hi, @Matt: thx for getting back to me on this. In general all the technical details are way over my head. What worries me is that we are going back and forth with these changes. It seems there is a pretty large "trail and error" part to these changes. So for the most part at this stage I do not care all that much about fixing things that were broken in 5.2 and when in doubt I would rather stick with behavior form 5.2, than continue messing around with a better approach for 5.3. At this stage the best service we can do our users is to release 5.3 ASAP. So please everybody working on these changes, keep the above in mind. As soon as you can give me some more details on when all of this will be completed I would appreciate it, at which stage I will make a release plan for RC2. I know that there are still some issues on the windows side. I am waiting for details on that, but do note that RC2 will not wait for windows todo items that are not spelled out at this point. even then it will be decided on a case by case basis .. again .. if something was broken in 5.2 and will remain broken in 5.3 .. so be it .. we have enough improvements for a couple of minor releases at this point, that are waiting to be released with 5.3. Aside from this nobody raised their hands, so I will not wait for any thing else. I would also appreciate it if people would refrain from committing anything but clear bug fixes at this point. Anything with any level of a BC break should be brought to the list first. Keep in mind that HEAD is for development. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closure serialization.
Although this may open a lot of pitfalls, I'd support the idea to serialize Closures. My concern is about recovering a Closure from a user-persisted state. People are able to do weird things, and we should be aware of that. Just need to keep in mind of a dictate that says: "Never underestimate the ignorance of a person". Cheers, On Tue, Apr 7, 2009 at 10:38 AM, Lukas Kahwe Smith wrote: > > On 07.04.2009, at 09:55, Richard Quadling wrote: > >> Hi. >> >> Currently you cannot serialize a closure. That certainly makes sense. >> >> But would it be possible/feasible that a closure could be serialized >> if the value returned was the byte code used by the engine to execute >> the compiled closure? >> >> Or is this one of the "don't go there" ideas I sometimes get? > > > I guess its a dont go there thing, as you also run into trouble with "use"-d > variables. > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closure serialization.
On 07.04.2009, at 09:55, Richard Quadling wrote: Hi. Currently you cannot serialize a closure. That certainly makes sense. But would it be possible/feasible that a closure could be serialized if the value returned was the byte code used by the engine to execute the compiled closure? Or is this one of the "don't go there" ideas I sometimes get? I guess its a dont go there thing, as you also run into trouble with "use"-d variables. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Closure serialization.
Hi. Currently you cannot serialize a closure. That certainly makes sense. But would it be possible/feasible that a closure could be serialized if the value returned was the byte code used by the engine to execute the compiled closure? Or is this one of the "don't go there" ideas I sometimes get? Regards, Richard Quadling. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
