• (cs)

    Hey masklinn your avatar makes me think WTF!? :-)

  • (cs) in reply to dance2die

    dance2die:
    I don't think i could come up with any responses for that funtion until I get to know what the values for "_dateFormat", & "_dfpi" are...

    Or do i?

    Anyways, I demand for the values for those two unknown (possible  properties[with bad naming convention] or a private member vars)!!!

    Using _ to prefix private variables isn't a bad naming convention, it's a Python naming convention to denote a variable as private.

    It doesn't enforce it as private, (Python: We're All Consenting Adults) so you can violate it at will, but it's considered bad form to do so.

     

     

  • (cs)

    This code is so awesome that I actually find myself offended... Yet still strangly turned on...

  • (cs) in reply to gondalez
    gondalez:

    Hey masklinn your avatar makes me think WTF!? :-)

    Hehe. It's an interpretation of "Firefox" I'm quite fond of, by ToyBoxArts's Toy, check out the "full" version, it's really nice

    Cyresse:

    dance2die:
    I don't think i could come up with any responses for that funtion until I get to know what the values for "_dateFormat", & "_dfpi" are...

    Or do i?

    Anyways, I demand for the values for those two unknown (possible  properties[with bad naming convention] or a private member vars)!!!

    Using _ to prefix private variables isn't a bad naming convention, it's a Python naming convention to denote a variable as private.

    It doesn't enforce it as private, (Python: We're All Consenting Adults) so you can violate it at will, but it's considered bad form to do so.

     

     

    Private python is dual underscores ;) and although it can be violated you still have some name mangling done.

  • (cs) in reply to Omnifarious
    Omnifarious:

    I find the effort and cleverness put into the blurb much more interesting than the code itself. The twisty maze of little casts, all alike isn't even bad in some inspired way that pushes the boundaries of badness.



    That's "Maze of twisty little casts, all alike"...

    And I, for one, find it quite inspiring. It's one of those "once you've seen it, it's obvious" things. We've all seen (and probably, at some point, done) our share of  pointless casts and conversions, and once you've seen this, you could obviously do much better (or rather, worse)... But the original idea, to use no less than FIVE conversions for a methode that does nothing else... and on top of that, shouldn't even exist because the input type is totally unfit to represent a date... I couldn't have come up with that.
  • (cs) in reply to ammoQ
    ammoQ:

    Other things still missing in C# would be the ability to use BigInts for switch statements, array indexing, casting etc.

    Wow... imagine the sort of WTFs you could write if you were not limited to 2^64 cases in a switch statement!

    (I wonder if this will quote correctly now that there's no preview button. It never worked for me before, even though I didn't click the button. Oh cool... I love the error I get when I forget to delete one of the inner quote tags... 'Something didn't quite work out ... ')

  • (cs) in reply to NSCoder
    NSCoder:
    Wow... imagine the sort of WTFs you could write if you were not limited to 2^64 cases in a switch statement!


    You could quickly implement calculations based on atom positions in the entire galaxy.

    That rules.

    Imagine an array of stars information, storing the visible universe!
  • lp344 (unregistered)

    did somebody already say "brillant"?

  • Toni (unregistered) in reply to triso
    triso:
    redtetrahedron:

    [:|]

    OMG... Convert has a ToDateTime method that takes a float... good grief



    You can thank microsoft excel for putting date and time into a float.   That is the first place I saw it, about 16 years ago.



    Delphi uses floats for representing DateTimes too. But truely I don't really see a problem with it?
  • Justin (unregistered) in reply to masklinn
    masklinn:


    Oh, and Java types are still types even though they're not primitive types. From the Java tutorial itself, Java has two categories of data types, primitives (which you define as "native") and references which are still types. Integer, String or Bignum may not be primitive types, but they're still types (or do you consider that Java doesn't have any String type?)



    Give this man a carrot.

    Think about the phrase 'type checking'.  Does it include object types as well as primitive types?  I think it does.

    Just because the syntax isn't c-like doesn't mean it isn't part of the language.  *Any* arbitrary-length integer must be behaving as a structure in memory terms anyway.  It can't be zero-terminated like a string, can it?

    J.
  • (cs) in reply to Toni
    Anonymous:
    triso:
    redtetrahedron:

    [:|]

    OMG... Convert has a ToDateTime method that takes a float... good grief



    You can thank microsoft excel for putting date and time into a float.   That is the first place I saw it, about 16 years ago.



    Delphi uses floats for representing DateTimes too. But truely I don't really see a problem with it?

    The lack of precision inherent to floating point arithmetics and representation in computers?

  • Alan (unregistered) in reply to masklinn

    You can store about 15 digits of information in a double before it clips, while in integer you would not be able to store but 11 digits. It's the integers that suffer from "lack of precision", in this case.

    There's nothing inherently imprecise about floating point values. The perception arises simply because floats that are based on base-2 system hold other values exact than humans, who use base-10 system. Humans are not impressed to discover that floats can't represent a value such as 0.1 exactly but end up with something like

    repr(0.1)
    '0.10000000000000001'


    However, think about this: if we were using a base-3 system we'd have no trouble to represent 1/3 exactly. The value would be written as simply 0.1. So what's happening here, could it be that the decimal system is "inherently imprecise", too, because it doesn't have accurate representation for 0.333...
  • (cs) in reply to Arachnid

    Anonymous:

    Anyway, it [Python] is still not 'any sane modern language'.

    There is an unwritten rule here to not exceed the initial WTF. It makes you look very silly. Go maintain a Perl script, you 'Python is not any sane modern language'-ist!

  • (cs) in reply to Alan

    Anonymous:
    However, think about this: if we were using a base-3 system we'd have no trouble to represent 1/3 exactly. The value would be written as simply 0.1. So what's happening here, could it be that the decimal system is "inherently imprecise", too, because it doesn't have accurate representation for 0.333...

    I'm no mathematician, but compared to base-2, a base-3 system wouldn't really fare better when representing, say, 1/7 right?

  • Rubinho (unregistered) in reply to joost
    joost:

    Anonymous:
    However, think about this: if we were using a base-3 system we'd have no trouble to represent 1/3 exactly. The value would be written as simply 0.1. So what's happening here, could it be that the decimal system is "inherently imprecise", too, because it doesn't have accurate representation for 0.333...

    I'm no mathematician, but compared to base-2, a base-3 system wouldn't really fare better when representing, say, 1/7 right?



    That was his point, no number base system is perfect.  Base-10 also wouldn't do any better with 1/7 than base-2 or base-3.  However in base-7 1/7 could be exactly represented as 0.1.  That said, base-7 would have real problems with 1/2. 

    We just take for granted that base-10 cannot and does not represent some fractions exactly.  When base-2 comes in and represents some precisely and others not we take offence that they're different from the ones that base-10 does. 
  • (cs) in reply to NSCoder
    NSCoder:
    ammoQ:

    Other things still missing in C# would be the ability to use BigInts for switch statements, array indexing, casting etc.
    Wow... imagine the sort of WTFs you could write if you were not limited to 2^64 cases in a switch statement!

    now if we only had computers with infinite memory, we could do a brillant implementation of natural numbers.

      bigint Successor(bigint n) {
        bigint s;
        switch(n) {
           case 0: s=1; break;
           case 1: s=2; break;
           case 2: s=3; break;
           case 3: s=4; break;
    ...
        }
        return s;
      }
    
  • (cs) in reply to Alan
    Anonymous:
    You can store about 15 digits of information in a double before it clips, while in integer you would not be able to store but 11 digits. It's the integers that suffer from "lack of precision", in this case.

    Uh, no, 11 digits in an integer are stored exactly as they've been inputted, and 20ish digits in int64, while you can't be sure (unless you do all the calculations to get the precise mapping of your float and only input floats that will match with your platform's floats representation) that the memory representation of a given float will be exactly what you inputted.

    There's nothing inherently imprecise about floating point values.

    Yes there is, floats represent Real numbers, they're discrete values trying to emulate continuous data sets, can't match, imprecision. Integers are discrete values storing discrete data sets, exact match, precision.

  • (cs) in reply to Arachnid

    Speaking of bignum functionality, I recently learned the .NET framework has (to my knowledge) no built-in functionality for bignum math. Looking through a couple of forums revealed people taking Java BigInteger-code and converting it to C# to get the desired functionality. WTF!?

  • (cs) in reply to azaris

     All this talk of base-2 and base-10 not being perfect is why I've always advocated we switch to base-9699690.  Not only is it pretty cool looking, but it easily represents such numbers as 1/3, 1/7 and even 1/19th perfectly.  Honestly, its the only sane solution to the whole base issue.  It cannot handle 1/23rd exactly, but to do so would require base-223092870 which would just be plain silly.

  • (cs) in reply to masklinn
    masklinn:
    Anonymous:
    You can store about 15 digits of information in a double before it clips, while in integer you would not be able to store but 11 digits. It's the integers that suffer from "lack of precision", in this case.

    Uh, no, 11 digits in an integer are stored exactly as they've been inputted, and 20ish digits in int64, while you can't be sure (unless you do all the calculations to get the precise mapping of your float and only input floats that will match with your platform's floats representation) that the memory representation of a given float will be exactly what you inputted.

    There's nothing inherently imprecise about floating point values.

    Yes there is, floats represent Real numbers, they're discrete values trying to emulate continuous data sets, can't match, imprecision. Integers are discrete values storing discrete data sets, exact match, precision.


    I know you're trying to be smart and edgy, but floats have no precision problems as a date storage - they only need 7+8 digits of precision. (3652500 days in the epoch, 86400000 msec a day.) Doubles have a 17 digit precision before calculations even start to break down, which is quite a ways from the 15 dates use. They won't have the sub-microsecond precision of a 64-bit DateTime of course.

    And whether they're the most efficient, and whether directly adding days is worth it, is another story entirely.
  • (cs) in reply to JoeS

    I think I'm gonna patent this base-1 idea I've just had.

  • (cs) in reply to JoeS
    JoeS:
     All this talk of base-2 and base-10 not being perfect is why I've always advocated we switch to base-9699690.  Not only is it pretty cool looking, but it easily represents such numbers as 1/3, 1/7 and even 1/19th perfectly.  Honestly, its the only sane solution to the whole base issue.  It cannot handle 1/23rd exactly, but to do so would require base-223092870 which would just be plain silly.


    Use fractions structs (consisting of numerator and denominator, of course using arbitrary length bigints) instead of floating points and you have perfect representation for all rational numbers.
  • (cs) in reply to Tony Morris
    Anonymous:
    It is one of the many unfortunate flaws of Java that the J2SE API Specification and Java Language Specification are heavily bound in an ad hoc manner. One cannot talk about one without inadvertantly talking about the other, or at least, to do so makes little sense. The dependency pointed here is one of many. I know of one such language currently underway that takes advantage of the relative unbrokenness of the JVM Specification while completely rewriting the language and API specification "properly". In fact, I do this in my spare time however, while I'm at work, I implement the J2SE specification itself, which some might argue is competing against my employer, but that's another story.

    --
    Tony Morris


    So what's the down side to "inadvertantly talking about the other" or even that the flaw<o:p></o:p> exists?  Have you been burned by this coupling?
  • (cs) in reply to joost
    joost:
    I think I'm gonna patent this base-1 idea I've just had.

    while you're at it you should get this date converting "algorithm" patended :)
  • (cs) in reply to Mung Kee
    Mung Kee:
    Anonymous:
    It is one of the many unfortunate flaws of Java that the J2SE API Specification and Java Language Specification are heavily bound in an ad hoc manner. One cannot talk about one without inadvertantly talking about the other, or at least, to do so makes little sense. The dependency pointed here is one of many. I know of one such language currently underway that takes advantage of the relative unbrokenness of the JVM Specification while completely rewriting the language and API specification "properly". In fact, I do this in my spare time however, while I'm at work, I implement the J2SE specification itself, which some might argue is competing against my employer, but that's another story.

    --
    Tony Morris


    So what's the down side to "inadvertantly talking about the other" or even that the flaw<o:p></o:p> exists?  Have you been burned by this coupling?


    ...or rather that it's done in an ad hoc manner.  I can see that it would create confusion for language implementors but like most certifications, for a specification or technical skills certification, it doesn't provide the value you would hope while in the process obtaining it.  I have received a couple Java certifications over the years and don't believe I have received any jobs as a direct result of them.  Likewise, if an platform isn't Java version x certified, it's likely not going to significantly influence my decision to use it or not.
  • (cs) in reply to foxyshadis
    foxyshadis:

    I know you're trying to be smart and edgy, but floats have no precision problems as a date storage - they only need 7+8 digits of precision. (3652500 days in the epoch, 86400000 msec a day.) Doubles have a 17 digit precision before calculations even start to break down, which is quite a ways from the 15 dates use.


    double, yes. but float only has slightly less than 7 digit precision, and this therefore inadequate. And float is what  the WTF code uses.

  • (cs) in reply to ammoQ
    ammoQ:

    Use fractions structs (consisting of numerator and denominator, of course using arbitrary length bigints) instead of floating points and you have perfect representation for all rational numbers.


    Certainly not all of them, since "arbitrary length" bigints are limited as well, e.g. java.math.BigInteger internally uses an array of regular ints, which has a maximum size of 2^31.

    It all boils down to us (and our hardware) living in a finite universe, while there is an infinite number of rational (or even just integer) numbers.
  • (cs) in reply to foxyshadis

    Maybe someone has already mentioned this, but using floating point numbers for dates actually has some advantages over ints/longs.

    For example, Unix timestamps are measured in the number of seconds since an epoch.  As computers got faster, we got code that would care what millisecond the code is executed in. You can't measure that with a system that has only the granularity of seconds.  Java uses something very similar to a Unix timestamp, the number of milliseconds since the same epoch (think of it as (Unix_timestamp)*1000L).  But there's no way of getting the current time down to the nanosecond with a date stored this way.  Using doubles, you'd have the ability to easily expand granularity (until you hit 17 digits).

    I suspect that this is a very good thing for games and multimedia applications, that have to do things in real time.

    But then again, I've never really researched this so my whole post here could be a WTF itself. :)

  • (cs) in reply to ammoQ
    ammoQ:
    JoeS:
     All this talk of base-2 and base-10 not being perfect is why I've always advocated we switch to base-9699690.  Not only is it pretty cool looking, but it easily represents such numbers as 1/3, 1/7 and even 1/19th perfectly.  Honestly, its the only sane solution to the whole base issue.  It cannot handle 1/23rd exactly, but to do so would require base-223092870 which would just be plain silly.


    Use fractions structs (consisting of numerator and denominator, of course using arbitrary length bigints) instead of floating points and you have perfect representation for all rational numbers.


    But, what happens to irrational numbers like sqrt(2) and pi?
  • (cs) in reply to Mike R

    Irrational? They go work for management.

  • (cs) in reply to wtfer
    Anonymous:
    masklinn:
    loneprogrammer:
    Hey um... where did the Preview button go?
    Send out the search parties, it's missing!

    Since it was completely buggy and more than likely wouldn't've been fixed, it was merely removed.

    If you want some kind of preview, write in HTML and switch to design view .



    Why don't we start peeking at this forum's software code? Must have a dozen WTFs. Why look elsewhere..

    By all means -- it can be downloaded at CommunityServer.org. I was really hoping removing the PREVIEW button would stop those "html" posts, but I guess not.

    I may upgrade to V1.2 one of these days. Doubt it'll fix most things though.

  • (cs) in reply to Alex Papadimoulis

    Alex, wouldn't it be possible to just switch to another, more stable, less crappyJavascript ridden softwares?

    I mean, most people here probably don't need the fancy editor (that doesn't work) and would more like... prefer a software that works as a whole, and allows you to middle click, and all that.

    PunBB, for example, is a very lightweight forum which looks like it can behave the way TDF behaves (only better), has a quite clean frontend code allowing for a lot of CSS tuning, and is blazingly fast...

    I don't know if you can post raw HTML in it though.

  • (cs) in reply to Mike R
    Mike R:
    ammoQ:
    JoeS:
     All this talk of base-2 and base-10 not being perfect is why I've always advocated we switch to base-9699690.  Not only is it pretty cool looking, but it easily represents such numbers as 1/3, 1/7 and even 1/19th perfectly.  Honestly, its the only sane solution to the whole base issue.  It cannot handle 1/23rd exactly, but to do so would require base-223092870 which would just be plain silly.


    Use fractions structs (consisting of numerator and denominator, of course using arbitrary length bigints) instead of floating points and you have perfect representation for all rational numbers.


    But, what happens to irrational numbers like sqrt(2) and pi?


    I don't care. There's not that many of them.
  • Arachnid (unregistered) in reply to joost
    joost:

    Anonymous:

    Anyway, it [Python] is still not 'any sane modern language'.

    There is an unwritten rule here to not exceed the initial WTF. It makes you look very silly. Go maintain a Perl script, you 'Python is not any sane modern language'-ist!



    You're misinterpreting my statement. I was stating that even though python has unlimited length integers, you still can't say that "any sane modern language" does.
  • Arachnid (unregistered) in reply to ammoQ
    Anonymous:
    There's nothing inherently imprecise about floating point values. The perception arises simply because floats that are based on base-2 system hold other values exact than humans, who use base-10 system. Humans are not impressed to discover that floats can't represent a value such as 0.1 exactly but end up with something like


    Calculate 100000000 + 0.000000001 in a double and tell me floating point numbers aren't imprecise.


    Anonymous:
    masklinn:


    Oh, and Java types are still types even though they're not primitive types. From the Java tutorial itself, Java has two categories of data types, primitives (which you define as "native") and references which are still types. Integer, String or Bignum may not be primitive types, but they're still types (or do you consider that Java doesn't have any String type?)



    Give this man a carrot.


    Think about the phrase 'type checking'.  Does it include object types as well as primitive types?  I think it does.


    Just because the syntax isn't c-like doesn't mean it isn't part of the language.  Any arbitrary-length integer must be behaving as a structure in memory terms anyway.  It can't be zero-terminated like a string, can it?


    J.



    BigInt is not part of the Java language, it's part of the Java standard library. Take J2ME, for example: it's still Java, but it doesn't have parts of the standard library, including BigInt.


    ammoQ:

    But, what happens to irrational numbers like sqrt(2) and pi?


    I don't care. There's not that many of them.


    Just in case you're _not_ joking: No, there's an infinite number of them.
  • entropy (unregistered) in reply to ammoQ
    ammoQ:
    Mike R:
    ammoQ:
    JoeS:
     All this talk of base-2 and base-10 not being perfect is why I've always advocated we switch to base-9699690.  Not only is it pretty cool looking, but it easily represents such numbers as 1/3, 1/7 and even 1/19th perfectly.  Honestly, its the only sane solution to the whole base issue.  It cannot handle 1/23rd exactly, but to do so would require base-223092870 which would just be plain silly.


    Use fractions structs (consisting of numerator and denominator, of course using arbitrary length bigints) instead of floating points and you have perfect representation for all rational numbers.


    But, what happens to irrational numbers like sqrt(2) and pi?


    I don't care. There's not that many of them.


    Uh.. You're joking right?
  • (cs) in reply to masklinn
    masklinn:
    gondalez:

    Hey masklinn your avatar makes me think WTF!? :-)

    Hehe. It's an interpretation of "Firefox" I'm quite fond of, by ToyBoxArts's Toy, check out the "full" version, it's really nice

    Cyresse:

    dance2die:
    I don't think i could come up with any responses for that funtion until I get to know what the values for "_dateFormat", & "_dfpi" are...

    Or do i?

    Anyways, I demand for the values for those two unknown (possible  properties[with bad naming convention] or a private member vars)!!!

    Using _ to prefix private variables isn't a bad naming convention, it's a Python naming convention to denote a variable as private.

    It doesn't enforce it as private, (Python: We're All Consenting Adults) so you can violate it at will, but it's considered bad form to do so.

     

     

    Private python is dual underscores ;) and although it can be violated you still have some name mangling done.

     

    Yeah, just read PEP 800 and found that out. I never knew! [:O]

    *cough* gammy smilies *cough*

  • (cs) in reply to Arachnid
    Anonymous:


    ammoQ:

    But, what happens to irrational numbers like sqrt(2) and pi?


    I don't care. There's not that many of them.


    Just in case you're _not_ joking: No, there's an infinite number of them.


    <joking>Oh really? How do you know? Have you counted them?</joking>
  • (cs) in reply to Mike R
    Mike R:

    But, what happens to irrational numbers like sqrt(2) and pi?


    The serious answer is: a program running on a digital computer will never ever encounter an irrational number in finite time, so unless you do symbolic calculations, there is no need to consider them.
  • (cs) in reply to wtfer
    Anonymous:
    masklinn:
    loneprogrammer:
    Hey um... where did the Preview button go?
    Send out the search parties, it's missing!

    Since it was completely buggy and more than likely wouldn't've been fixed, it was merely removed.

    If you want some kind of preview, write in HTML and switch to design view .



    Why don't we start peeking at this forum's software code? Must have a dozen WTFs. Why look elsewhere..

    It's nice to see I'm not the only one who feels the DailyWTF forum code IS a wtf.

    1. Preview buttons removed

    2. font settings barely work correctly

    3. no way to edit posts that YOU own, not even within a given grace period

  • entropy (unregistered) in reply to ammoQ
    ammoQ:
    Mike R:

    But, what happens to irrational numbers like sqrt(2) and pi?


    The serious answer is: a program running on a digital computer will never ever encounter an irrational number in finite time, so unless you do symbolic calculations, there is no need to consider them.


    Sorry man, figured you were joking, just hard to tell sometimes
  • :Piki (unregistered) in reply to entropy

    Well,
    if type is "native" to a language, one can use in as a const in source and compiler magic does the rest. Like

    const int A = 5;
    const double B = 10;

    Now, please show me how one could write constants like that for "native" bigints in Java (or, C#, for that matter)?

    LP,
    :Piki

  • (cs) in reply to :Piki
    Anonymous:
    Well,
    if type is "native" to a language, one can use in as a const in source and compiler magic does the rest. Like

    const int A = 5;
    const double B = 10;

    Now, please show me how one could write constants like that for "native" bigints in Java (or, C#, for that matter)?


    final BigInteger A = new BigInteger("100000000000000000000000000000");

    Not sure what your point about "compiler magic" here is, though.
  • :Piki (unregistered) in reply to brazzy

    That's not a constant.
    It's instance being created dynamically at runtime.

    LP,
    :Piki

  • (cs) in reply to :Piki
    Anonymous:
    That's not a constant.
    It's instance being created dynamically at runtime.


    So why do you think the difference is so important?
  • (cs) in reply to :Piki
    Anonymous:
    That's not a constant.
    It's instance being created dynamically at runtime.

    LP,
    :Piki

    The final keyword actually does create a constant value in Java, the constkeyword has been reserved in Java5 (never had been before) but it's not used yet...

    So what Brazzy said is perfectly true, to get a constant Bigint in Java you just declare it as "final BigInteger".

    Oh, and btw you can't create any language enforced constant in Python, though you can trick the language into creating "somewhat constants" with recipes such as this one. Does that mean that Python actually has 0 native types?

  • (cs) in reply to masklinn
    masklinn:
    Anonymous:
    That's not a constant.
    It's instance being created dynamically at runtime.

    LP,
    :Piki

    The final keyword actually does create a constant value in Java, the constkeyword has been reserved in Java5 (never had been before) but it's not used yet...

    So what Brazzy said is perfectly true, to get a constant Bigint in Java you just declare it as "final BigInteger".

    Oh, and btw you can't create any language enforced constant in Python, though you can trick the language into creating "somewhat constants" with recipes such as this one. Does that mean that Python actually has 0 native types?



    I think when he  said "constant" he meant "literal"

Leave a comment on “It's a Float. It's a Long. It's SUPERDATE!”

Log In or post as a guest

Replying to comment #43182:

« Return to Article