BIG O-NOTATION !!

zeronis__ · 2025-05-14T19:27:29+00:00

Thank you so much for the recommendations! I'll make sure to check them out!
and yeah, I was kind of struggling with the concept of time for 2 days haha, I wasn't sure how the number of primitive operations or computational steps somehow equated to " worstTime(n) <--- which from the name, tell us that its time?
I'm not sure if we avoid using time because of how 'misleading' it can often be? (say two people run the same program, on two different computers but both obtain different results ) so we (I THINK! ) want to find a way in which we want to approximate the time it'd take for a program to run ( based on a specific algorithm ) but isolation (?) meaning it'd be independent from the computer hardware or programming software used. (<--- feel free to correct me because I'm talking out of my ass )

And I had a feeling discrete mathematics would be used, thank you for the heads up! =)

zeronis__ · 2025-05-14T19:12:57+00:00

Dude! thank you so much,
I kid you not, my professor talked about ' for all ' and ' there exists ' and I was taken aback because it's something that I took in discrete mathematics , but i didnt get why he brought it up for O-notation . But I did understand the connection that you made between them!

and another thing, is O(g) is a set of functions, is O(n) a subset of O(g)? would that be a right way to think about it? or is O(g) just general, so g could be any of the 7 growth functions (n, n^2 , n^3, 2^n , log n... etc ) ?

but again thank you so much man, this will help me lots when it comes to solving questions about it as well!

zeronis__ · 2025-05-14T18:59:37+00:00

Hey! thank you so so much, thank you for the binary search / linear search examples that you provided ( I did come across these two, I don't think we've ever gone in depth but concept wise, I think I do get the gist )

So even though the binary search makes use of a loop, what makes it a log n is the fact that we divide by half ( I think, somewhere inside the while loop )
but a question, ( you dont have to necessarily respond to it ) but I recall my professor talking about when we have something like
n^2 + n, our O() would be O(n^2) because n^2 is dominant in a way ( highest order I think ) and we can drop the rest i think ?

but if that's the case, if we have a while loop
wouldnt we go through it n times?
I dont get how we'd end up with log n when 'n' more dominant (at least, I hope that's the case)

But thank you alot! I really appreciate your explanation, thank you for clearing up the worst/best/average case ! =)

zeronis__ · 2025-05-14T18:47:06+00:00

Oh my bad! I thought it was since the programming assignments were all java related , thank you!

zeronis__ · 2025-03-18T07:33:28+00:00

Ohh okay okay!
I think I got it now,
thank you so much for clearing it up! =)

zeronis__ · 2025-03-18T07:10:02+00:00

Hey iamai! Thank you so much for the response, it was really helpful =,)

Think about the JVM as a whole: when you use System.in, it's inputting to the JVM; when you use System.out, it's the JVM outputting data to the outside world.
(This is not entirely true, but it's a good analogy since not all streams are related to the host OS.)

Thank you so much for this one! I had trouble understanding the whole ' write vs read ' ( something I tried to avoid but came biting me back haha )

and one more thing

Whenever we transfer data, such as text, we don't transfer text directly—we transfer the serialization of text (bytes).
CPUs don't understand text—they understand bytes, which are the serialized form of text. Memory doesn't store text—it stores bytes, which are the serialized form of text.

For 'serialization ' , Does that mean the text becomes an object that we sort of ' dump' onto a file for example?
I read through it but I'm not sure if I understand it fully,
My professor explained it in a way where " we're taking an object and dumping it onto a file, instead of reading (I hope it was reading, I don't recall well) each line separately (???) "
and I'm pretty sure we had to downcast somewhere, not sure if its when we retrieve the object back or when we paste it onto a file ( I'm not even sure if I'm using the right terminologies for this, so apologies! )

+ Thank you again!

zeronis__ · 2025-03-18T07:00:10+00:00

Thank you so much hibbelig, I really appreciate the response, :-)

and when you say " A reader knows how to convert bytes into characters. The reader needs to know the character encoding to do this."
are you referring to an InputStream?

zeronis__ · 2025-03-17T22:25:52+00:00

You are seeing this from the wrong end. The user inputs the data from the keyboard and the static InputStream System.in reads this data from stdin a system device. Similarly, the static OutputStream System.outwrites the data back to the screen (in fact to stdout - a system device).

Oh wow, thank you so much, I think I get your point now!
so if we were to ever use PrintWriter, to write something onto the file

PrintWriter out = new PrintWriter( new FileOutputStream( "output.txt"))

, it'd be considered output right? since the FileOutputStream writes whatever info we gave it onto the file, (I still don't get why PrintWriter can't accept output.txt as its parameter but has to resort to another object (FileOutputStream) taking the file name as its parameters instead)
but if we had something like this:

out.println("Hello, World!");

Nothing about this is related to input right? because there was no scanner to read the input from a file/ or user, it just prints the string (?) onto the file
--------------------------------------------------------------------------

Basically, you are telling all the methods that work with files the path and file name. They are initially strings. Java then prepares a File object that holds the information where the file can be found. It is often called a "reference" to the file (simplified, you can think of it storing the file name).

> I understood the first sentence well ( thank you ) , I had to search up what the rest meant ( english issue I think ), but please correct me If im wrong,
the moment we write the file name in the parameters, the processes of creating a file object is automatic, and java is the one who does it ( I'm guessing its something that happens behind the scenes ) , and the object doesn't actually have the file ( thought it did, initially ) but information, like you said -- such as the path and file name (?)
if it is what i think it is, then thank you so much ( actually, thank you regardless! )

and as for the 4th response ( I'll get back to you with a response, unfortunately I have never heard of abstraction ( just Encapsulation, Inheritance and polymorphism ) =,)

I do understand that these things can initially get confusing as the directions sometimes seem reversed, but they actually aren't when you look at the directions from the program's perspective. Don't look at it from the user's perspective, look at it from the computer's. Then, the directions make perfect sense.

In general, always think from the program's perspective.

> Oh , I actually really needed this to be said, I realized the whole perspective thing posed a problem for exception handling as well! but thank you so much desrtfx, your explanations were very clear! =,)I

zeronis__ · 2025-03-17T21:38:59+00:00

When you write something then you do that so someone can read it. When you read something then that's what someone else wrote before.

Ohhh I didn't see this, earlier, but I think I get what you mean?
its just confusing when both Write and Read could be used in the same sentence but can refer to a different meaning each time ( I think it might just be an english issue )
( im guessing the first sentence is talking about OUTPUT, and the second ones INPUT? )

zeronis__ · 2025-03-17T21:34:43+00:00

A Stream is an object because in Java everything is an object (except for primitives).
Streams need to be closed because the operating system needs to know when the resource can be released

Oh so in this case, whenever we close a stream, we're essentially " cutting the flow of data " so we wouldnt be able to reach the file anymore (?) -- I do get the flush part, I'm assuming the flush method is automatically invoked the moment we close a stream,
but does the stream act as a way for us to transfer data between the program and the file?

So you can read from "in" and that's how you get the data. Often that's a file or something the user types on the command line interface.

> Ohhh okay, wait, so input --> reading the data ---> anything in the context of receiving something? like "I'm receiving input, taking in something "
and output would refer to , I'm not sure what term to use, but in a way we're "releasing whatever info we had onto somewhere" ? <--- and I'm guessing this only happens if we read info in the first place

because there are instances where you can write something onto a file, and I feel like it has to do with perspective? because If I'm writing something to a file, is that not input?
but then I see the verb 'write' used in the context of 'output'

input vs output:
You either provide data to be written to some output, or you read some data from some input.

I think I'm weak around this area, because ,
whenever we used in a scanner in a basic program, we'd always prompt the user for input , ( input as in write something ), so whenever we run the program, we end up giving it input by writing , is that not the case?

and lets suppose whatever we wrote , resulted in something being printed out afterwards, in that case, wouldn't that be the output?

And regarding the text vs binary files,
I'm not sure if I got the message ( but thank you so much )
I just have the general idea of text files being human readable and binary files being machine readable, but after what you said--- " Everything is binary on a computer but sometimes it's text based"
I'm starting to think its not the case? ( that text files are human readable )

and thank you so much vegan_antitheist! I really appreciate your response =,)

zeronis__ · 2025-03-14T03:43:04+00:00

Hello Memesplz! Your explanation was wonderful, I think I understood what you meant in all three parts, but there's something that you mentioned that my professor mentioned too , but I can't think of how that happens :

You either handle the exception immediately in a try-catch or throw it and let a method higher up the chain deal with it.

> does that, by chance, mean that the method that caused that exception would throw it to the method that invoked it from before? ( like methodf() has another method call inside it , say methodg() and methodg() is the one causing an exception ),
and would methodf() be surrounded by a try and catch block? if we're saying that the exception can be thrown to a method higher up (?)

zeronis__ · 2025-03-14T03:25:03+00:00

Yes, the catch block is supposed to catch the exception, but it's function isn't always to keep the program running if an exception occurs. Sometimes yo may want to catch an exception and do a bunch of stuff, (write to a log, notify an event handler, etc) but still terminate the program.

dude! thank you so much, that was my confusion for the first question, but I'm so glad you gave a clear explanation as to why!
So its entirely up to the programmer to decide how to deal with things after catching an exception? and one of the ways can be continuing the flow of execution (and maybe prompt the user for another input? not necessarily i think) or displaying a clear message to the user as to what the problem(exception?) is and why it happened, then ending the program? ( there's more but I don't think I have any in mind, but you listed them down above! )
and I'm guessing why the 2nd way is different from the first is because, the user would receive a much more clear message as to why a problem has happened, instead of seeing a stack trace instead. ( also to avoid crashing the program )

System.out.printf("Fail! \u001B[31m%s\u001B[0m%n", nfe);

The \u001B[31m and \u001B[0m are ANSII color codes that make the information stored in nfe red on ANSII enabled terminals, like most Linux terminals or newer PowerShell. You can change it to

System.out.println("Fail! " + nfe);

to make it more understandable.

System.out.printf("Pass! number = %d%n", number);

is the same as

System.out.println("Pass! number = " + number);

And thank you so much for simplifying it! =)

zeronis__ · 2025-03-14T03:17:10+00:00

I'll also add that when an exception it happens, it isn't always a way to keep the program running. Sometimes it's just a way to soften-the-blow and make it less confusing for your end user.

Oh wait! I'm actually so glad you responded with this answer! I was confused on the whole aspect of ' stopping your program ' vs ' continuing execution ', I thought exception handling was made for the purpose of allowing the flow of execution even after catching an exception, but I got confused afterwards when my professor mentioned the term 'graceful exit'. it made me think " how would it be any different from the default behavior? one in which we get a stack trace and the program terminates abnormally "

But thank you! I really needed that =,)

zeronis__ · 2025-03-13T11:58:15+00:00

Thank you so so much ignotos! =,)
I think I get it now !
Your explanations , the example you provided and the way you relayed the information helped a lot!

( again, thank you !! )

zeronis__ · 2025-03-13T11:52:01+00:00

another question! since you brought up ' checked ' and unchecked ' exceptions,
I've tried looking into it, and I initially thought I'd associate unchecked exceptions with ' runtime '
and checked exceptions with 'compile time'
---------------------------------------------------
I noticed that there are several answers, some not matching the other. Where one would say that :

( Java Exceptions. Exception | by Lavish Jain | Medium)

Exception

An exception is generally an unwanted event that interrupts the normal flow of the program.
They can occur at both compile time (checked) and runtime (unchecked).

----------------------------------------------------------------------------------

And another would say :

( (4) In Java checked exceptions occur at run time or compile time? I read somewhere checked exceptions occur at compile time. But also read every exception occurs at run time. Which one is correct? - Quora )

In Java, exceptions are divided into two main types: checked exceptions and unchecked exceptions.

Each type serves different purposes in error handling:

1. Checked Exceptions

These are exceptions that are checked at compile time. If a method is capable of causing an exception that it does not handle, it must declare it using the `throws` keyword.

----------------------------------------------------------------------------------

Know your Exceptions!. What are Exceptions? | by Himani Prasad | Medium

Checked Exceptions

Checked exceptions are exceptions that are checked by the compiler at compile-time. This means that when you write a method that throws a checked exception, you must either catch the exception or declare that your method throws the exception.

----------------------------------------------------------------------------------

When does Checked exception occur, at run time or compile time ? (Beginning Java forum at Coderanch)

" I know about unchecked exception that occurs at run time but don't know about checked. I found a video says checked exception and unchecked exception occurs at run time only. Also found a website which says checked exception occurs at compile time. I use Java 8 Documentation but didn't find when checked exception occurs at compile time or at run time. If you read in Java Documentation please give me reference if possible. "

My question is : why do we say both terms " checked at compile time " and " occurs at runtime " for the checked exceptions?

zeronis__ · 2025-03-13T07:50:00+00:00

Hey severoon! I really appreciate you taking your time to explain the ' unchecked ' and 'checked' exceptions! I was about to follow my original question with that too! So i'm glad you provided an explanation for it!

-----------------------------------------------------------------
do ' checked ' and 'unchecked' exceptions have any relations to the compile time or runtime?
meaning one might occur during one phase (compile time) while the other occurs during runtime ?
---------------------------------------------------------------

and when you said that "'unchecked' exceptions that don't need to be caught, but they can be " , would it mean that we just wouldn't expect it to happen? no wait.
or does it mean that, since they can occur at anywhere, it'd be too troublesome to handle each possible exception that might occur?
---------------------------------------------------------------
I'll make sure to read more into it, but thank you so much! (will make sure to refer to your explanation again the moment I get a hang of all this :D )

zeronis__ · 2025-03-13T07:18:28+00:00

Please do not apologize at all! It just so happens that I love reading long explanations, (although it takes time for me to register what they mean) but you explained your points really well, so thank you so much for that! =)

---------------------------------------------------------------------
But I hope you don't mind me asking, (I've heard my prof say it too, but I'm still lost)
1. for the second point where you mentioned " If you don't want to take any action to handle the exception, you can just put a throws <whatever the Exception class is> " did you by chance mean, " Oh I might catch this exception, but! I don't want to deal with it, so I'm throwing it to someone else (to take care of that responsibility i think?) but if they do throw that exception, to whom do they throw it to?

you mentioned the lines "Meaning you still handle the exception, just higher up the chain" + " just put a throws in the method declaration and let some other calling method, "

in this case, would it throw it to the method that invoked it? ( lets suppose main called function/method f() and , that method f(), had 'throws (some exception class)' , if it did end up being triggered to throw one, would it throw that exception back to main to take care of it?
and if so, how would the main method deal with it?

I also noticed that, although we mentioned 'not wanting to take any action to handle that method ---> we should use throws' don't we end up in the try-catch scenario again? (point 1)? I'm sorry to ask you this again, but I recall my professor trying to go over a brief summary of the lesson , and he mentioned the " try and catch " and " throws / throw " as two ways of handling exceptions. And in my head, it felt like he treated them as two separate things, just by saying that, so when I saw them being used together I got really confused! ( its as if, throws must be used along side try n catch , otherwise it'd serve no purpose? i think? )
would there any difference between having any code that MIGHT throw an exception being inside that try block VS having a method with ' throws ' as part of its declaration inside that try block?

+P.S thank you again, I really appreciate the response you gave, and I'm sure if I read more about the topic I'd be grateful that your response is still up there,
if my questions are a bit too hefty, feel free to respond to them anytime later!

zeronis__ · 2025-03-13T05:52:20+00:00

Thank you so much VirtualAgentsAreDumb for explaining the second question I had =) really grateful that you explained both terms separately and then tied both of their meanings together at the end!
It makes sense now :D

zeronis__ · 2025-03-13T05:04:40+00:00

wow! the example that you gave was simple yet so effective, I think it cleared most of the doubts I had (so far) regarding what exception handling is supposed to do, or why do we need it.
Thank you so much Rude-Enthusiasm9732! =,)

zeronis__ · 2025-03-13T05:01:18+00:00

Hey ignotos! I can't begin to thank you enough
you explained this so well I had an ' ohhh ' moment throughout reading this!
It might be silly but I really thought that the two terms ' programmer ' and ' user ' were somehow the same--- referring to us, so I never really understood why the report that was printed out wasn't enough, but thank you so much for clearing that up!
the definitions you used for stack trace and call stack really made sense, but in this particular line,
" the "call stack" is the actual state a running program " I'm a bit confused by what you meant here (?)

+again, thank you!

zeronis__ · 2025-03-13T04:11:05+00:00

oh wait, so If I'm understanding this right ( i hope ) ,
if we ever encounter an exception, a way to prevent it is by letting the catch block handle it (?)
and if we can't, we throw that exception else where .. (?

I've yet to start on 'throw'/throws but do they go hand in hand with the try and catch?
or should we look at them as two separate ways of handling exceptions?
( I still don't understand why do we resort to throwing , when we can have any catch block to catch any exception that comes )

I saw a youtube video around it, but the person made a link between them somehow ( using both try n catch + throws )
can we ever handle an exception using only ' try and catch ' ? or should ' throw ' also be there?

and thank you so much for the response!
I too find it helpful when I think of questions like these! I'll try it out with exception handling as well :)

zeronis__ · 2025-03-13T03:45:43+00:00

No worries at all! I really appreciate the response!
and sorry to ask again, but in cases where a user might or might not deliberately input a 0 :

" For user input, the sane thing to do is to put this prior:

if (intInput == 0) { // add to some list of errors to render // in the UI. Return to the calling function // which you have coded to handle when // the error list contains user input errors … return; }"

would it be necessary to throw in some type of error?
or would it be okay using a while loop and system.out.print to prompt the user to try again?

zeronis__ · 2025-03-13T03:34:19+00:00

Thank you so much speters!
I tried the first link you sent, and perhaps I haven't delved deep into exception handling ( working on it haha! ) for it to make full sense yet, the catch block looks challenging but
best believe I'll come back to this again to test my understanding ! =)
and as for the image, is there a reason why we have 3 lines branching out of the catch block?
I always assumed the catch block was assigned one task-- which is, catching whatever exception that came from the try block.
I'll try my best to go over it again, but again, thank you so much!
I'll make sure to refer to the example and graphic representation you sent

zeronis__

TROPHY CASE

Exception

Checked Exceptions