Mysql est atteind de noobisme... [by suri]

Mysql est atteind de noobisme... [by suri] - SQL/NoSQL - Programmation

Marsh Posté le 30-07-2003 à 21:11:41    

suri ayant des problemes avec ses navigateurs c'est moi qui post son probleme:
 
 
une simple addition avec bc nous donne:
$>bc
1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 + 256 + 512 + 1024 + 2048 + 4096 + 8192 + 16384 + 32768 + 65536 + 131072 + 262144 + 524288 + 1048576 + 2097152 + 4194304 + 8388608 + 16777216 + 33554432 + 67108864 + 134217728 + 268435456 + 536870912 + 1073741824 + 2147483648 + 4294967296 + 8589934592 + 17179869184 + 34359738368 + 68719476736 + 137438953472 + 274877906944 + 549755813888 + 1099511627776 + 2199023255552 + 4398046511104 + 8796093022208 + 17592186044416 + 35184372088832 + 70368744177664 + 140737488355328 + 281474976710656 + 562949953421312 + 1125899906842624 + 2251799813685248 + 4503599627370496 + 9007199254740992 + 18014398509481984
 
36028797018963967
quit
$>
 
jusque la c bon
ensuite ds mysql:
 

Code :
  1. CREATE TABLE masks (
  2.   id bigint(20) NOT NULL auto_increment,
  3.   mask bigint(20) NOT NULL default '0',
  4.   PRIMARY KEY  (id)
  5. ) TYPE=MyISAM;
  7. INSERT INTO masks VALUES (1, 1);
  8. INSERT INTO masks VALUES (2, 2);
  9. INSERT INTO masks VALUES (3, 4);
  10. INSERT INTO masks VALUES (4, 8);
  11. INSERT INTO masks VALUES (5, 16);
  12. INSERT INTO masks VALUES (6, 32);
  13. INSERT INTO masks VALUES (7, 64);
  14. INSERT INTO masks VALUES (8, 128);
  15. INSERT INTO masks VALUES (9, 256);
  16. INSERT INTO masks VALUES (10, 512);
  17. INSERT INTO masks VALUES (11, 1024);
  18. INSERT INTO masks VALUES (12, 2048);
  19. INSERT INTO masks VALUES (13, 4096);
  20. INSERT INTO masks VALUES (14, 8192);
  21. INSERT INTO masks VALUES (15, 16384);
  22. INSERT INTO masks VALUES (16, 32768);
  23. INSERT INTO masks VALUES (17, 65536);
  24. INSERT INTO masks VALUES (18, 131072);
  25. INSERT INTO masks VALUES (19, 262144);
  26. INSERT INTO masks VALUES (20, 524288);
  27. INSERT INTO masks VALUES (21, 1048576);
  28. INSERT INTO masks VALUES (22, 2097152);
  29. INSERT INTO masks VALUES (23, 4194304);
  30. INSERT INTO masks VALUES (24, 8388608);
  31. INSERT INTO masks VALUES (25, 16777216);
  32. INSERT INTO masks VALUES (26, 33554432);
  33. INSERT INTO masks VALUES (27, 67108864);
  34. INSERT INTO masks VALUES (28, 134217728);
  35. INSERT INTO masks VALUES (29, 268435456);
  36. INSERT INTO masks VALUES (30, 536870912);
  37. INSERT INTO masks VALUES (31, 1073741824);
  38. INSERT INTO masks VALUES (32, 2147483648);
  39. INSERT INTO masks VALUES (33, 4294967296);
  40. INSERT INTO masks VALUES (34, 8589934592);
  41. INSERT INTO masks VALUES (35, 17179869184);
  42. INSERT INTO masks VALUES (36, 34359738368);
  43. INSERT INTO masks VALUES (37, 68719476736);
  44. INSERT INTO masks VALUES (38, 137438953472);
  45. INSERT INTO masks VALUES (39, 274877906944);
  46. INSERT INTO masks VALUES (40, 549755813888);
  47. INSERT INTO masks VALUES (41, 1099511627776);
  48. INSERT INTO masks VALUES (42, 2199023255552);
  49. INSERT INTO masks VALUES (43, 4398046511104);
  50. INSERT INTO masks VALUES (44, 8796093022208);
  51. INSERT INTO masks VALUES (45, 17592186044416);
  52. INSERT INTO masks VALUES (46, 35184372088832);
  53. INSERT INTO masks VALUES (47, 70368744177664);
  54. INSERT INTO masks VALUES (48, 140737488355328);
  55. INSERT INTO masks VALUES (49, 281474976710656);
  56. INSERT INTO masks VALUES (50, 562949953421312);
  57. INSERT INTO masks VALUES (51, 1125899906842624);
  58. INSERT INTO masks VALUES (52, 2251799813685248);
  59. INSERT INTO masks VALUES (53, 4503599627370496);
  60. INSERT INTO masks VALUES (54, 9007199254740992);
  61. INSERT INTO masks VALUES (55, 18014398509481984);


 
=>  SELECT SUM(mask) FROM masks LIMIT 0, 30
36028797018963968
 
soit le resultat de bc + 1  :heink:  
 
mais keskidi?
   
 :??:  

Reply

Marsh Posté le 30-07-2003 à 21:11:41   

Reply

Marsh Posté le 30-07-2003 à 21:12:55    

Reply

Marsh Posté le 30-07-2003 à 21:17:56    

En tout cas, SQL Server merde pas :D
 
Avec un pauvre numeric de précision 10.
 
PS: j'ai fait un simple copier/coller de tes requêtes, en ne changeant que le type des champs.


Message édité par MagicBuzz le 30-07-2003 à 21:19:07
Reply

Marsh Posté le 30-07-2003 à 21:31:11    

[:drapo]
 :??: Je veux avoir le fin mot de cette histoire

Reply

Marsh Posté le 30-07-2003 à 21:33:20    

J'ai trouvé, problème de conversion connu :jap:  
 
tiré de la doc MySQL:
 
http://www.mysql.com/doc/en/Column_types.html
 

Citation :

All arithmetic is done using signed BIGINT or DOUBLE values, so you shouldn't use unsigned big integers larger than 9223372036854775807 (63 bits) except with bit functions! If you do that, some of the last digits in the result may be wrong because of rounding errors when converting the BIGINT to a DOUBLE


 
Edit : en fait nan, on dépasse pas le range :/, mais bon, je pense que je suis pas loin du truc


Message édité par THE REAL SMILEY le 30-07-2003 à 21:35:46
Reply

Marsh Posté le 30-07-2003 à 21:35:25    

sauf que la le nombre max est de 53 et quelques bits si je me souviens bien


---------------
Suri.morkitu.org : Balades au coeur de la ville...
Reply

Marsh Posté le 30-07-2003 à 21:36:27    

Suri a écrit :

sauf que la le nombre max est de 53 et quelques bits si je me souviens bien


ben oui, j'avais édité :/, c'est fou ce truc :??:

Reply

Marsh Posté le 30-07-2003 à 21:39:01    

THE REAL SMILEY a écrit :


ben oui, j'avais édité :/, c'est fou ce truc :??:  


en fait ils disent 63bits mais bon  :whistle:  un peu moins koi :D
 
enfin ca fout la merde qd meme...


---------------
Suri.morkitu.org : Balades au coeur de la ville...
Reply

Marsh Posté le 30-07-2003 à 21:51:10    

Suri a écrit :

sauf que la le nombre max est de 53 et quelques bits si je me souviens bien

D'ailleurs, ca fonctionne bien en additionnant les 53 premiers nombres (jusqu'à 4503599627370496 compris) [:figti]  
C'est après que ca pose problème :pt1cable:

Reply

Marsh Posté le 30-07-2003 à 22:12:04    

Y'a pas un type "numeric" ou "decimal" avec MySQL ? (Ca n'a AUCUN rapport avec des float, on peut stocker des entiers sans perte de précision) Il me semble que si.
 
L'avantage de ce type, c'est que les chiffres sont manipulés sous forme de chaîne de caractères, et on peut monter à des valeurs bien plus importantes (dépasser allègrement les 64 bits), sans perdre la moindre précision.
 
Extrait de la doc de SQL Server 2000 :
 

decimal and numeric
Numeric data types with fixed precision and scale.
 
decimal[(p[, s])] and numeric[(p[, s])]
 
Fixed precision and scale numbers. When maximum precision is used, valid values are from - 10^38 +1 through 10^38 - 1. The SQL-92 synonyms for decimal are dec and dec(p, s).
 
p (precision)
 
Specifies the maximum total number of decimal digits that can be stored, both to the left and to the right of the decimal point. The precision must be a value from 1 through the maximum precision. The maximum precision is 38.
 
s (scale)
 
Specifies the maximum number of decimal digits that can be stored to the right of the decimal point. Scale must be a value from 0 through p. The default scale is 0; therefore, 0 <= s <= p. Maximum storage sizes vary, based on the precision.
 
Precision Storage bytes  
1 - 9 5  
10-19 9  
20-28 13  
29-38 17


 
On dépasse donc TRES largement les 64 bits (17 * 8 = 136 bits) et on peux manipuler des nombres à 38 chiffres sans perte de précision.


Message édité par MagicBuzz le 30-07-2003 à 22:14:22
Reply

Marsh Posté le 30-07-2003 à 22:12:04   

Reply

Marsh Posté le 30-07-2003 à 23:41:43    

en convertissant en decimal 20,0 (jsais pas si c bon)
j'ai toujours le meme pb avec SUM... :/
 
(enfin j'ai contourné le pb de facon porc hein.. mais ca m'intrigue cette histoire :D)
 


---------------
Suri.morkitu.org : Balades au coeur de la ville...
Reply

Marsh Posté le 31-07-2003 à 00:11:43    

Ca m'intrigue aussi, parceque normalement, en decimal ça devrait passer, puisque ta précision est plus grande que tes chiffres :heink: Là j'ai l'impression que MySQL a fumé grave la moquette avec la colle et tout...

Reply

Marsh Posté le 13-08-2003 à 17:58:11    

bon c'est quoi le fin mot de cette histoire :D

Reply

Marsh Posté le 13-08-2003 à 18:15:39    

 CREATE TABLE masks (  
    id bigint(20) NOT NULL auto_increment,  
    mask bigint(20) NOT NULL default '0',  
    PRIMARY KEY  (id)  
  ) TYPE=MyISAM;


 
pour commencer, déclarer les champs en 'unsigned' .....;)  
edit : j'ai pas trop lu le topik quand même .. j'esper que je dis pas de connerie  :whistle:


Message édité par simogeo le 13-08-2003 à 18:16:47

---------------
from here and there -- \o__________________________________ -- la révolution de la terre, en silence
Reply

Marsh Posté le 13-08-2003 à 18:27:48    

simogeo a écrit :

 CREATE TABLE masks (  
    id bigint(20) NOT NULL auto_increment,  
    mask bigint(20) NOT NULL default '0',  
    PRIMARY KEY  (id)  
  ) TYPE=MyISAM;


 
pour commencer, déclarer les champs en 'unsigned' .....;)  
edit : j'ai pas trop lu le topik quand même .. j'esper que je dis pas de connerie  :whistle:  


T'as pas dit de connerie, ça n'a juste aucun rapport ;)
 
PS: de toute façon, rien ne vaut le type number, avec, pas de problème, et "pas" de limitation de nombre...
 
PS²: Par contre, pour faire un masque binaire, c'est pas très approprié :D

Reply

Marsh Posté le 10-06-2004 à 16:04:06    

up ?

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed