Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm trying to implement an Auto-encoder by my own in Java. From the theory, I understood that auto-encoder is basically a symmetric network.
So, if I chose to have 5 layers in total, do I have to use 9 layers in training (back propagation) phase or 5 layers enough?
I've been reading theory but they are too abstract and full of math formulas, I could not get any implementation details via google.
What's the usual way of doing this?
An Auto-encoder, in training phase, using back propagation, tries to get the output similar to the input with a goal to minimize the error. It is shown above. The number of layers in the above image are 7 while the actual layers are 4 after the training. So, while training can I implement the back-propagation with just 4? If so, how can I do this?
Simple backpropagation won't work with so many layers. Due to so called vanishing gradient pehenomen, networks having more than two hidden layers won't learn anything reasonable. In fact, best results are obtained with one hidden layer. So in case of autoencoder you should have INPUT layer, HIDDEN layer and OUTPUT layer. No need for more, the Universal Approximation Theorem clearly shows, that this is enough for any problem.
From the OOP point of view it depends whether you plan to reuse this code with different types of neurons, and by type of neuron I mean something deeper than just different activation function - different behaviour (stochastic neurons?); different topologies (not fully connected networks). If not - modeling each neuron as a separate object is completely redundant.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a monolithic app that does the following logics:
Get a list A (Customer) from database
Validate data in A using some criteria, if it's not validated, throw an error
Do some operations on A to get a list B (e.g. Regional customers)
Do sth with B
Now I am transforming my app using microservices, but I have trouble in designing the calls.
As B can be deduced from A entirely, I want to just make a single micro service getCustomerA that returns all the dataset A. That means a single database access is needed. That will be a performance plus.
But the problem is, the operations on A to retrieve list B is also part of the business code. So it's more logical to put these codes in Customer microservice side, if we follow domain driven design, in microservice Customer, maybe getRegionalCustomer.
So I want to know, what is the best practice in this case ? Should we priotize the single database call (first case) or it's better to do two calls (but in this case, 2 database calls) ?
Since this is mainly opinion based I can only give you that :-)
From my experience splitting the app into microservices just for the sake of doing it puts technical dogma over technical simplicity and often introduces a lot of unnecessary overhead.
With regard to the database calls I can also tell you from experience that quite often you win performance when doing two simple calls over doing one overly complex one. Especially if you start introducing big joins over many tables or - ouch - subselects in the on clause.
See if the most simple solution works and keeps the code tidy. Constantly improve quality and optimize when the need for it arises. If you have a piece of logic that warrants to be split of into a microservice (e.g. because you want to use a different language, framework or want to offload some calculations) then go for it.
Domain driven design does not tell that each boundle context only can contains one entity, in fact, a bounded context (or microservice) can contains more than one entity when these entites are clearly related, in other words, when they need to be persisted transactionally.
In your case, due to the tight relation between the two entites, the best way is to build only one microservice that do both operations
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have three micro services MSA, MSB and MSC. The micro service MSA creates a partial object O1 and sends to MSB only through a dedicated message topic. After receiving the partial object O1 from MSA, MSB populates few more attributes in O1 and shares in the common message bus from which MSC consumes the object O1.
Question is that, is this a good approach where the object building is shared across multiple micro services?
Here it's your response:
In object-oriented programming, a God object is an object that knows too much or does too much. The God object is an example of an anti-pattern.
A common programming technique is to separate a large problem into several smaller problems (a divide and conquer strategy) and create solutions for each of them. Once the smaller problems are solved, the big problem as a whole has been solved. Therefore a given object for a small problem need only know about itself. Likewise, there is only one set of problems an object needs to solve: its own problems.
So you have a microservice Ordering and a microservice Pricing. Both of the microservices need information about the Product entity.
You should ask yourself:
Do those two different worlds realize the Product entity in the same way? Both of them need the same information?
Will the product information change for the same reasons for both of the microservices?
If no (which is likely the case), you have to add an abstract layer between them, so that you are sure that they use the same language.
If yes, you can keep on sharing the same object.
By the way, these concerns that you have is not a new thing.
Here is Martin Fowler's article about bounded contexts
So instead DDD divides up a large system into Bounded Contexts, each
of which can have a unified model - essentially a way of structuring
MultipleCanonicalModels.
keywords for further research: DDD, context map, bounded context, anticorruption layer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I currently have several "manager" classes in a project I am working on but have seen a lot of things that advise you to not use manager classes but don't seem to provide any alternatives in my situation. I have a ClickManager which contains a map of "clickable" objects and a ConfigManager which is responsible for loading and saving config files as the config class comes from an API I am using and is too stupid to load itself.
What are some alternatives to using "manager" in these cases?
Ward Cunningham once said (1) that every programmer should have a dictionary and a thesaurus on his or her desk. There's also a saying that there are only two hard problems in computer science: cache invalidation and naming things. (2)
The point is that naming things is important, and it's hard, and it's often neglected. This is why there are classes named Data and Manager littered around many code bases.
There are at least two potential things going on here. One is that the class is doing something reasonable, and it just needs to have a good, concise, descriptive name applied to it. For example, with ClickManager, does it dispatch events to the clickable objects? If so, maybe it's a Dispatcher. Does it lay out the clickable objects? Maybe it's a Positioner. Does it contain the clickable objects (as Erwin Bolwidt suggested)? Maybe it's a Container. Does it execute something in response to a click? Maybe it's an InteractiveCommand. It's sometimes helpful to think more specifically about what a class is doing in order to come up with a good name.
Another possibility is that the class has too many responsibilities, that is, it violates the Single Responsibility Principle. This is often the reason that something is hard to name, because it does a bunch of different stuff. Suppose the class simultaneously contains clickable objects, dispatches events to them, positions them, and executes commands. It's no wonder that it's hard to come up with a name other than Manager because it's doing all of these related, but independent functions. (Note that in many UI toolkits, these responsibilities have been separated into different classes.)
If this is the case it might be advisable to do some refactoring of a big Manager class into smaller classes, each of which has fewer (or one) responsibilities. It should be easier to come up with better names for those classes.
(1) I think it was at an OOPSLA about ten years ago.
(2) And off-by-one errors.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am looking into finding algorithm within the area of clustering or machine learning which will facilitate or creating a typical data reading for a group of readings. The issue is that it must facilitate time series data; thus some traditional (k-means) techniques are not as useful.
Can anyone recommend places to look or particular algorithms that would provide a typical reading and relatively simple to implement (in Java), manipulate and understand?
As an idea. Try to convert all data types into time, then you will have vectors of the same type (time), then any clustering strategy will work fine.
By converting to time I actually mean that any measurement or data type we know about has a time in its nature. Time is not a 4-th dimension, as many think! Time is actually 0-dimension. Even a point of no physical dimensions which may not exist in space, exists in time.
Distance, weight, temperature, pressure, directions, speed... all measures we do can be converted into certain functions of time.
I have tried this approach on several projects and it payed back with really nice solutions.
Hope, this might help you here as well.
For most machine learning problems in Java, weka usually works pretty well.
See, for example: http://facweb.cs.depaul.edu/mobasher/classes/ect584/weka/k-means.html
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have to determine if a package can be delivered based on rules as follows...
If packageWeight > 70 and below 100
AND
If destinationState is in the special list of allowed state {MA, PA, NY, NJ, LA,....}
AND
contentType is any of the following {ACD, FDY, PRZ, QUO, ..... }
AND
CarrierName is any of the following {FXD, USPS....}
if the above conditions are true then we can deliver the package
and in addition there are 3 flags with 15x16x8 possibilities?
what is the best way to avoid a if else cluster ?
hash map?
any other suggestions ?
You can break down different group of conditions in different functions. For. e.g. Define a function isCarrierSupported that returns true if carrier is one of FXD, USPS etc. Similarly you can define multiple functions like isWeightCorrect etc. Then later in main program, you can just call these functions and get final result.
This does not avoid ifs and elses but neatly organizes the program to make it more readable.
What are looking for a is a rules engine, then just use one that already exists.
This isn't a trivial domain to be trying to create something from scratch. Just like you should not be writing your own caching system or your own ORM or your own threading framework.
Don't make the mistake of rolling your own it will end in tears.
Since you are using Java, go look at Drools. Save yourself and your company a bunch of money and use something that is already built for you.
HashMap would work or You could convert whole flag-state into 11-bit mask (15-4 bits, 16 - 4 bits, 8 - 3 bits, or leave more bits for further growth) and use true/false array by 11-bit index.
The downside is - You'll anyway have to code same if/else logic to fill the map/array or to define a constant describing all deliver (or don't-deliver) states.
P.S. switch/case looks more appropriate then if/else here...