Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Putnam]

...what's 0.1+0.1 in not-float? you saying fixed point or?

As a constant, 0.1 should be translated into Rational(1, 10).  (Printed, it should be 0.1, though its repr could be 1/10.)  Two of those added together would be Rational(2, 10), which could be reduced to Rational(1, 5).

That, uh, looks almost exactly like floating point to me, with an arbitrary exponent size rather than just using two. Is that faster, somehow?

[jaked122]

...what's 0.1+0.1 in not-float? you saying fixed point or?

As a constant, 0.1 should be translated into Rational(1, 10).  (Printed, it should be 0.1, though its repr could be 1/10.)  Two of those added together would be Rational(2, 10), which could be reduced to Rational(1, 5).

That, uh, looks almost exactly like floating point to me, with an arbitrary exponent size rather than just using two. Is that faster, somehow?

The rational? No, it's just exact and can represent numbers more precisely in circumstances where floating point numbers can't represent numbers precisely.

It prevents things like 0.000000001 or 4.999999999999 or similar things.

It also doesn't lose significant digits as it grows larger.

[Mesa]

[stuff about my bad Python code]

Thanks, though a lot of what you just said confuses me to a rather large extent..._{I guess that's a problem with my mind being wired in a very non-technical way, which is why a lot of what I make would cause any programmer worth more than me to scream internally. Sorry if this sounds like self-loathing but it is not false.}

For what it's worth, I've since updated the script to actually work (before you made your post though), even if it still violates a lot of the Pythonic rules. (though I'd imagine it's less bad than it used to)

Code: (Python 3) [Select]

import random

"""Random post-apocalyptic name generator
Generates a random name out of concatenated strings pulled from thematic pools and returns it as a string
nameTypeId corresponds to what theme of the name is supposed to be:
        0 - desert
        1 - jungle
        2 - tundra/iceland/glacier
        3 - city
        4 - spaceship
        5 - hell
"""
names_front = [
["Rock","Sand","Dust","Rocky","Sandy","Dusty","Flat","Dry","Storm","Cracked","Stone","Oasis","Sun","Skull","Drought","Red","Brown","Yellow","Orange","Hazel","Rolling"],
["Toxic","Vine","Acid","Dark","Black","Sher","Muta","Savage","Wild","Great","Rotten","Green"],
["Cold","Frozen","Frost","Cool","White","Ice","Snow","Blizzard","Hail","Cryo","Blue","Chill","Freeze","Winter","Aurora"],
["Break","Kalash","Dead","Remington","Crushed","Steel","Iron","Fallen","Killer","Ruined","Nuke","Gray","Sky","Scrap","Bolt","Nut","Gun","New","Red","Blue","Grey","White","Black","Orange"],
["Red","Blue","Purple","Star","Great","Colossal","Space","Fallen","Green","Astral","Phantom","Mother"],
["Hot","Boiling","Scorched","Damned","Burned","Burning","Hell's","Melting","Molten","Lava","Magma","Sulfur","Fire","Brimstone","Abaddon","Soul","Devil","Devil's","Demon","Cursed"]
]
names_back = [
["Lands","Land","Valley","Plain","Plains","Rocks","Peaks","Pit","Canyon","Straits","Stones","Stone"],
["Jungle","Woods","Valley","Wood","Log","Trees","Bushes","Bush","Safari"],
["Borealis","Wastes","Plains","Glacier","Wall"],
["Town","City","York","Angeles","Peaks","Burg","Fort","Huts","Towers","Yard","Valley","Marino","Maria","Meltdown"],["Conqueror","Explorer","Empress","Odyssey","Scout","Comet","Storm","Hammer","Sword","Axe","Sun","Queen","Princess","Priestess","Mother"],
["Pit","Hole","Caves","Rocks","Mountain","Graves","Hive","Tunnels","Circle","Terror","Tremor","Quake","Dimension","Land"]]
def generateName(nameTypeId): 
        # pulls the appropriate name pool via the getNamePool fuction as a list and stores them in the nameBack and nameFront which are then concatenated to create the desired name
        if nameTypeId not in range(0,6):
                return print("Yo, this ain't gonna work. bud.")

        nameFront = getNamePool("frontPart",nameTypeId)
        nameBack = getNamePool("backPart",nameTypeId)
        nameFront = random.choice(nameFront)
        nameBack = random.choice(nameBack)
        return nameFront+" "+nameBack

def getNamePool(part,nameTypeId):
               
        if part == "frontPart": # Front adjectives
                if nameTypeId == 0:
                        return names_front[0] #Desert
                elif nameTypeId == 1:
                        return names_front[1] #Jungle
                elif nameTypeId == 2:
                        return names_front[2] #Glacier
                elif nameTypeId == 3:
                        return names_front[3] #City
                elif nameTypeId == 4:
                        return names_front[4] #Spaceship
                elif nameTypeId == 5:
                        return names_front[5] #Hell
        elif part == "backPart": # Back adjectives
                if nameTypeId == 0:
                        return names_back[0] #Desert
                elif nameTypeId == 1:
                        return names_back[1] #Jungle
                elif nameTypeId == 2:
                        return names_back[2] #Glacier
                elif nameTypeId == 3:
                        return names_back[3] #City
                elif nameTypeId == 4:
                        return names_back[4] #Spaceship
                elif nameTypeId == 5:
                        return names_back[5] #Hell     


[TheBiggerFish]

AAABGBLGBL PATH VARIABLE Y U NO WORK.

Help, anyone?

(Java, Windows, I can't figure out what the darn problem is.)

[jaked122]

What's the issue in particular? Would you mind posting a bit of code that causes or suffers from this issue?

[Reelya]

elif nameTypeId == 1:
                        return names_front[1] #Jungle

Can't you replace every occurrence of this type of line with "return names_front[nameTypeId]"

And then you could also probably make the outer part an outer array index, and reduce about 80% of your program to something like "return names[type][id]"

[TheBiggerFish]

What's the issue in particular? Would you mind posting a bit of code that causes or suffers from this issue?

Code?
I think you misunderstand the problem.
I cannot get Windows, or at least Eclipse, to recognize the existence of the JDK on my system.
I can use Netbeans just fine though...
Weird.

[Skyrunner]

...what's 0.1+0.1 in not-float? you saying fixed point or?

As a constant, 0.1 should be translated into Rational(1, 10).  (Printed, it should be 0.1, though its repr could be 1/10.)  Two of those added together would be Rational(2, 10), which could be reduced to Rational(1, 5).

That, uh, looks almost exactly like floating point to me, with an arbitrary exponent size rather than just using two. Is that faster, somehow?

IMO breadman created rational numbers :v

Kinda like arbitrary precision. The main problem with this is that it'd be slower, because floating point numbers are supported by CPU operator codes while the Rational object would have to find the correct GCD every time it does Reduce()

[jaked122]

What's the issue in particular? Would you mind posting a bit of code that causes or suffers from this issue?

Code?
I think you misunderstand the problem.
I cannot get Windows, or at least Eclipse, to recognize the existence of the JDK on my system.
I can use Netbeans just fine though...
Weird.

Ah. That's odd. I've found that reinstalling the JDK tends to make this issue go away.

This often seems to coincide with a normal Java update which screws up the java configuration and removes the JDK entry... At least that's my working hypothesis.

[TheBiggerFish]

Well, I managed to figure out how to get Netbeans to use jar files, so the problem is papered over until I need to use Eclipse for something at least.  Woo.

[Antsan]

As a constant, 0.1 should be translated into Rational(1, 10).  (Printed, it should be 0.1, though its repr could be 1/10.)  Two of those added together would be Rational(2, 10), which could be reduced to Rational(1, 5).

That, uh, looks almost exactly like floating point to me, with an arbitrary exponent size rather than just using two. Is that faster, somehow?

It's very much not the same as floating point. It is not faster, but you can represent any rational number exactly, which is impossible with floating point numbers. The idea is to use rationals for any exact, rational and use floating point for irrational and imprecise numbers.

IMO breadman created rational numbers :v

Kinda like arbitrary precision. The main problem with this is that it'd be slower, because floating point numbers are supported by CPU operator codes while the Rational object would have to find the correct GCD every time it does Reduce()

Some languages contain rational numbers in their standard. One of those is Common Lisp and dividing two non-floats (of whatever precision) always yields a rational number there (the integer type is a subtype of the rational type).

[jaked122]

Have any of you messed around with Inform 7?

 It's interesting because I've found that the action override/behavior handling methods resemble those in the Common Lisp Object system for overriding post-handlers for specific objects.

It looks almost like it might have advanced object orientation until you realize that it's basically englishified prolog and everything is handled through DFS.

[Putnam]

As a constant, 0.1 should be translated into Rational(1, 10).  (Printed, it should be 0.1, though its repr could be 1/10.)  Two of those added together would be Rational(2, 10), which could be reduced to Rational(1, 5).

That, uh, looks almost exactly like floating point to me, with an arbitrary exponent size rather than just using two. Is that faster, somehow?

It's very much not the same as floating point. It is not faster, but you can represent any rational number exactly, which is impossible with floating point numbers. The idea is to use rationals for any exact, rational and use floating point for irrational and imprecise numbers.

I don't see how floating point is more accurate than rationals for irrational numbers. Both are only capable of representing approximations.

[breadman]

It's very much not the same as floating point. It is not faster, but you can represent any rational number exactly, which is impossible with floating point numbers. The idea is to use rationals for any exact, rational and use floating point for irrational and imprecise numbers.

Exactly.  Perhaps 1/3 would have been a better example, since it can't be expressed exactly in either decimal or binary as a floating point number, but can be stored as a rational number by keeping the numerator and denominator separate.  New programmers expect 1/3 + 1/3 + 1/3 to equal 1, but that's not guaranteed when using floating point.  Indeed, Python claims that 1/3 * 5 != 5/3, due to floating-point rounding errors.

Some languages contain rational numbers in their standard. One of those is Common Lisp and dividing two non-floats (of whatever precision) always yields a rational number there (the integer type is a subtype of the rational type).

Ooh, nice.  It turns out that Python does have an implementation in fraction.Fraction, but it's not used for native divisions.  The the real issue is speed, particularly when adding or subtracting, but it would be much nicer to use float() or // when that's really important than to use Decimal() or Fraction() all over the place when correctness is important.  Using float by default is premature optimization.

I don't see how floating point is more accurate than rationals for irrational numbers. Both are only capable of representing approximations.

The reason for switching to floating point for irrational numbers is for speed, not accuracy.  Rationals are incapable of expressing irrational numbers directly, because they store their numerator and denominator as integers.  Yes, it's possible to approximate an irrational number with a sufficiently large denominator, but that doesn't buy you any correctness, so you can switch to a faster floating point representation without surprising your users.  At that point, using a different type can also let the program know, if it cares, whether a given number is exact.

[MagmaMcFry]

Rationals have another huge disadvantage that nobody's mentioned yet: If you calculate with rational numbers enough, suddenly you get a fraction with huge numerators and denominators, and that's potentially horrible. Rational number formats therefore have very limited application, such as situations where is explicitly guaranteed that your denominators don't explode, and even in those situations it is usually easy to use integers instead. For situations where you would only need the exact value to test for equality or ordering, it is usually better to use floating-point numbers, then consider sufficiently close values equal (up to a small constant epsilon).