I was playing with the oop library and i made this
I had to smile at you checking to make sure the initial value is a number. Were you once bitten by a computer science teacher, or something? :~) (And actually, checking that it’s a number isn’t good enough. The proper domain of your function is positive integers!)
I know some people, including Jens, are really enthusiastic about oop, but I grew up on functional (stateless) programming, and so to me using oop to compute a function seems like elephant guns and mice. That’s not to say that you shouldn’t do it! Just sharing that it feels a little bizarre to me.
But I get that playing with the oop library was the point of the exercise, rather than computing the Collatz function.
yes, that’s why the title of the project is the way it is.
Side Note
i am certified in python by freecodecamp, so i just did something like a method in an object lol because thats what you do in python
i am certified in python by freecodecamp
Ah, so you were bitten by a computer science teacher! ;~)
i think error handling should be abolished tbh just let the program crash if the user uses a malformed input
i think error handling should be abolished tbh just let the program crash if the user uses a malformed input
Well, it depends on the context. If you’re writing life-critical software for medical equipment or a self-driving car, you don’t want to just let the program crash. This is why computer science teachers typically overemphasize (imho) error checking.
But my point was that if you’re going to do error checking at all, you should do it correctly! Checking hardware types (“number”) isn’t good enough.
But I agree with you that in the context of a Snap! project there’s generally no need for error checking.
I was joking; but yeah, I agree. I usually just do blanket checks for efficiency, but at the sacrifice of precise error messages.
The reason I’m sensitive on this point is that some teachers want Snap! to do type enforcement with respect to the primitive types, like those grownup languages, but I say that’s either too much (no error checking needed at all) or not enough (because the user giving an input that’s in the right hardware type but not in the domain of the particular function, such as a negative or non-integer input to the Collatz function, is more likely than giving the wrong hardware type, such as a string instead of a number).
Actually, modern practice is to try to extend the domains of functions as much as possible. For example, if a program deals with lists of numbers, and some functions expect a list as input while others expect a number, it’s a common student error to get those types mixed up. Used to be, we signalled an error in those cases. But now we have hyperblocks, so all the functions that take individual numbers as input now also take lists of numbers. That’s a very useful capability, but it also means we sometimes don’t catch actual errors. In such a world it’s even stupider than before to fetishize type checking.
I made it so that it only accepts positive integers, but again this was to play with the oop library
I made it so that it only accepts positive integers, but again this was to play with the oop library
Well again :~) I don’t think it needs error checking at all. But half-hearted error checking is a bad compromise.
The negative Collatz function is really interesting, and I don’t think you should take that away from the user for the sake of sticking to the original problem.
The negative Collatz function is really interesting, and I don’t think you should take that away from the user for the sake of sticking to the original problem.
Oh! I didn’t know there was a negative Collatz function. Sorry. Okay, then just think about non-integer inputs in what I said.
There is a negative Collatz function, but the program isn’t set up to detect any final pattern except the positive one, so it just infinite loops.